Skip to main content

BGP Route Type Capability
draft-kriswamy-idr-route-type-capability-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Krishnaswamy Ananthamurthy , Mankamana Prasad Mishra , Lukas Krattiger , Keyur Patel
Last updated 2024-10-21
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kriswamy-idr-route-type-capability-00
Inter-Domain Routing                                    K. Ananthamurthy
Internet-Draft                                                 M. Mishra
Intended status: Standards Track                            L. Krattiger
Expires: 24 April 2025                                             Cisco
                                                                K. Patel
                                                                  Arrcus
                                                         21 October 2024

                       BGP Route Type Capability
              draft-kriswamy-idr-route-type-capability-00

Abstract

   BGP supports different route types, which defines the encoding of
   Network Layer Reachability Information (NLRI) for a some of the
   Address Family Identifier (AFI)/Subsequent Address Family Identifier
   (SAFI) like Ethernet VPN (EVPN), Multicast VPN(MVPN) and so on.  BGP
   speaker will reset the BGP session if a given route type is not
   supported.  This document defines an Optional Capabilities to
   exchange the route types supported for a given AFI/SAFI such that
   session are not reset.

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/.

   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 24 April 2025.

Ananthamurthy, et al.     Expires 24 April 2025                 [Page 1]
Internet-Draft          BGP Route Type Capability           October 2024

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.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   BGP Ethernet VPN (EVPN), Multicast VPN(MVPN), and other address
   families support multiple route types.  Different route types will
   have different key lengths consisting of multiple fields which are
   used as a BGP Route Key.  If a particular route type is not supported
   on a BGP speaker then the session will be reset as there is no way to
   determine the key.

   When a new Route-type is added to EVPN, MVPN and any other address
   families that support route types, then all routers in the network to
   be updated to make sure that there is no session reset.  Resetting a
   BGP session is expensive as we have seen from deployments that
   multiple AFI/SAFI are negotiated between the BGP neighbors and
   resetting a session will impact the network adversely.

   This document defines an optional capability exchange of route types
   per AFI/SAFI such that BGP speakers negotiate the route types and
   only if the neighbor has advertised a particular route-type
   capability support then only advertise the given route-type in
   MP_REACH_NLRI.

Ananthamurthy, et al.     Expires 24 April 2025                 [Page 2]
Internet-Draft          BGP Route Type Capability           October 2024

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 Rout type capability is a new 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 [BGP-MP]

   *  Route-Type length: This field specifies the total length in
      octets, of Route-Types field.

   *  Route-Type: This field specifies the Route-Types.

   A speaker that supports multiple "AFI, SAFI" tuples that requires
   route-type capability exchanges includes them as multiple
   Capabilities in the Capabilities Optional Parameter.

Ananthamurthy, et al.     Expires 24 April 2025                 [Page 3]
Internet-Draft          BGP Route Type Capability           October 2024

   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.  Error Handling

   TBD

5.  Security Considerations

   TBD

6.  IANA Considerations

   This document defines a new optional route type capability dnd
   request the BGP optional capability registry:

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
              2009, <https://www.rfc-editor.org/info/rfc5492>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Contributors

   In addition to the authors listed on the front page, the following
   coauthors have also contributed to this document:

   Satya Mohanty

Ananthamurthy, et al.     Expires 24 April 2025                 [Page 4]
Internet-Draft          BGP Route Type Capability           October 2024

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

   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

Ananthamurthy, et al.     Expires 24 April 2025                 [Page 5]