Inter-Domain Routing K. Ananthamurthy Internet-Draft M. Mishra Intended status: Standards Track L. Krattiger Expires: 11 May 2025 Cisco K. Patel Arrcus J. Haas Juniper Networks 7 November 2024 BGP Route Type Capability draft-kriswamy-idr-route-type-capability-01 Abstract BGP supports different route types, which define the encoding of Network Layer Reachability Information (NLRI) for some of the Address Family Identifier (AFI)/Subsequent Address Family Identifier (SAFI), like Ethernet VPN (EVPN), Multicast VPN(MVPN) and so on. BGP speaker MAY reset the BGP session if a given route type in an NLRI is not supported instead of treat-as-withdraw. This document defines Optional Capabilities pertaining to the exchange of route types that are supported for a particular AFI and SAFI. This framework facilitates the maintenance of sessions without necessitating resets or the inadvertent dropping of updates. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Ananthamurthy, et al. Expires 11 May 2025 [Page 1] Internet-Draft BGP Route Type Capability November 2024 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 May 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Route Type Capability . . . . . . . . . . . . . . . . . . . . 3 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction BGP Ethernet VPN (EVPN), Multicast VPN (MVPN), and other address families are designed to accommodate multiple route types. Each route type possesses distinct key lengths that consist of several fields, which together form a BGP Route Key. In instances where a specific route type is unsupported by a BGP speaker, there is a possibility that the session may be reset. This occurs due to the inability to ascertain the key; alternatively, the speaker might interpret the update as a withdrawal and subsequently discard it. The sending BGP speaker remains unaware when a peer drops an Update due to an unsupported route type. Ananthamurthy, et al. Expires 11 May 2025 [Page 2] Internet-Draft BGP Route Type Capability November 2024 This document defines an optional capability exchange for route types linked to each AFI/SAFI and BGP speakers can signal the supported route types. Send a specific route type in the MP_REACH_NLRI attribute only if they have received confirmation from their peers that the route type is supported. This process reduces the risk of unsupported route type exchanges, improving the efficiency and reliability of routing between network peers. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Route Type Capability The Route Type Capability is a new optional BGP capability [RFC5492] that can be used by BGP speaker to indicate the route types of a given AF/SAFI supported. This capability is defined as follows: * Capability code: To be assigned by IANA * Capability length: Variable * Capability value: Consists of 0 to 63 of the tuples "AFI, SAFI, Route Type length and Route Type values for address family" +----------------------------------------------------------+ | Address Family Identifier (2 octets) | +----------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +----------------------------------------------------------+ | Route Type length (1 cotet) | +----------------------------------------------------------+ | Route Types (variable length) | +----------------------------------------------------------+ * The AFI and SAFI, taken in combination, indicate that Route Types supported for routes that are advertised with the same AFI and SAFI. Route Types may be explicitly associated with a AFI and SAFI using the encoding of [RFC4760]. Ananthamurthy, et al. Expires 11 May 2025 [Page 3] Internet-Draft BGP Route Type Capability November 2024 * Route Type length: This field specifies the total length in octets ranging from 1 to 32, of Route Types field. * Route Type: This field specifies the route types and consists of a bit-string, with each bit set to indicate that the corresponding route type that can be accepted by the BGP Speaker advertising this capability. Example encoding for Capability Value: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bit 0 set to 0, while bits 1 through 15 are all set to 1, which indicates that the speaker supports route types 1 through 15. This indicates that the speaker has the capability to support route types ranging from 1 to 15 for a particular AFI and SAFI. Each of these bits corresponds to a specific route type, and setting them to 1 signifies that the speaker can successfully exchange route information of these types with its peers. Thus, the configuration effectively communicates the speaker's readiness to handle various route types within the designated AFI/SAFI. A speaker that supports multiple "AFI, SAFI" tuples that requires route type capability exchanges includes them as multiple capabilities in the Capabilities Optional Parameter. If route type capabilities are exchanged between BGP speakers for a specific AFI/SAFI, and the BGP peer does not support a particular route type, that route should not be advertised to the peer. 4. Operation When the Route Type Capability is advertised, any route type bits that are not included in the encoded bit-string will be interpreted as if they were transmitted with a value of zero for the corresponding bit. The Route Type length specifies the octets required to represent the Route Type Bits. Although the complete representation of all possible route types only demands 32 octets, it is recommended that implementations limit the number of octets transmitted to those essential for encoding the final one-bit. This practice helps optimize data transmission. Furthermore, in certain implementations, the available capacity for BGP Route Type may be limited due to the Ananthamurthy, et al. Expires 11 May 2025 [Page 4] Internet-Draft BGP Route Type Capability November 2024 need to convey multiple route type capabilities, potentially affecting the overall size and efficiency of the routing information exchanged. (See [I-D.ietf-idr-ext-opt-param] for discussion on a feature to address this point.) Bit-values 0 and 255 SHOULD be set to zero as they are RESERVED. A BGP Speaker that has received the Route Type Capability Bits MUST ensure it does not originate or propagate any BGP Route Type encoded NLRI containing a route type that is absent from the received bit- string. A BGP Speaker that has received an AFI/SAFI without Route Type Capability MUST treat the absence as equivalent to having received the Route Type Capability Bits covered by the base or relevant specification for that address family. The Route Type Capability MAY be dynamically updated through the use of the Dynamic Capability capability and associated mechanisms defined in [I-D.ietf-idr-dynamic-cap]. 5. Error Handling If a BGP Speaker sends BGP Route Type Capability Bits for a given AFI/SAFI and receives a BGP NLRI with an unadvertised route type, it MUST discard those routes unless specified otherwise for that address family. 6. Security Considerations This extension to BGP does not change the underlying security issues inherent in the existing BGP. 7. IANA Considerations IANA is requested to assign a new BGP Capability to the Capability Codes registry from the First Come, First Served pool. The Reference for the registration is this document. The Change Controller is IETF. 8. Normative References [I-D.ietf-idr-dynamic-cap] Chen, E. and S. R. Sangli, "Dynamic Capability for BGP-4", Work in Progress, Internet-Draft, draft-ietf-idr-dynamic- cap-16, 21 October 2021, . Ananthamurthy, et al. Expires 11 May 2025 [Page 5] Internet-Draft BGP Route Type Capability November 2024 [I-D.ietf-idr-ext-opt-param] Chen, E. and J. Scudder, "Extended Optional Parameters Length for BGP OPEN Message", Work in Progress, Internet- Draft, draft-ietf-idr-ext-opt-param-13, 22 April 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Contributors In addition to the authors listed on the front page, the following coauthors have also contributed to this document: Satya Mohanty Authors' Addresses Krishnaswamy Ananthamurthy Cisco 170 W. Tasman Drive San Jose, CA 95134 United States of America Email: kriswamy@cisco.com Mankamana Mishra Cisco 170 W. Tasman Drive San Jose, CA 95134 United States of America Email: mankamis@cisco.com Ananthamurthy, et al. Expires 11 May 2025 [Page 6] Internet-Draft BGP Route Type Capability November 2024 Lukas Krattiger Cisco 170 W. Tasman Drive San Jose, CA 95134 United States of America Email: lkrattig@cisco.com Keyur Patel Arrcus Email: keyur@arrcus.com Jeffrey Haas Juniper Networks Email: jhaas@juniper.net Ananthamurthy, et al. Expires 11 May 2025 [Page 7]