BGP Route Type Capability

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

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

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

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

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¶

6. IANA Considerations

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

Contributors

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

Satya Mohanty¶

Authors' Addresses