RFC 5492

Capabilities Advertisement with BGP-4 🦋

Okay bestie, let's do the paperwork first 📄✨ This is RFC 5492, and it's a Standards Track document from February 2009. It came from the Network Working Group and was written by J. Scudder of Juniper Networks and R. Chandra of Sonoa Systems. It obsoletes RFC 3392, which the Abstract also says, so this is the newer version to read. 💅

Status of This Memo 📌

This is an Internet standards track protocol doc for the whole Internet community, and it's asking for discussion and suggestions to make it better 🫶 For where this protocol sits in standardization and its current status, check the current edition of "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited, so share away 🌸

Copyright Notice ⚖️

Copyright (c) 2009 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, as they stand on the date this document was published (http://trustee.ietf.org/license-info). Read these carefully, because they spell out your rights and restrictions for this document 🙈

This document might include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow changes outside the IETF Standards Process. So unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be made outside the IETF Standards Process either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈

Abstract 💜

This document defines an Optional Parameter, called Capabilities. It's expected to make it easier to introduce new capabilities in the Border Gateway Protocol (BGP), because it provides graceful capability advertisement without requiring that BGP peering be terminated ✨

This document obsoletes RFC 3392.

1. Introduction ✨

Okay so, the base BGP-4 specification [RFC4271] says that when a BGP speaker gets an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate the BGP peering. Honestly that makes adding new capabilities to BGP way harder 😭

So this specification defines an Optional Parameter and some processing rules that let BGP speakers share their capabilities in an OPEN message. A pair of BGP speakers that supports this specification can set up peering even when they run into unrecognized capabilities, as long as all the capabilities required to support the peering are supported. It's giving flexibility 👑

2. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Translation: these words are the official vocabulary, so pay close attention whenever you see them 🔥

3. Overview of Operations 🦋

Here's the big picture. When a BGP speaker [RFC4271] that supports capabilities advertisement sends an OPEN message to its BGP peer, the message MAY include an Optional Parameter, called Capabilities. That parameter lists the capabilities the speaker supports 💖

A BGP speaker figures out what its peer supports by looking at the list of capabilities in the Capabilities Optional Parameter that the OPEN message from the peer carries 👀

A BGP speaker that supports a particular capability may use it with its peer once the speaker has worked out (as described above) that the peer supports it too. Simply put, a capability can be used on a peering only if both peers advertised it. If either peer didn't advertise it, the capability cannot be used. No cap, that's the whole rule 💅

Now, a BGP speaker decides its peer doesn't support capabilities advertisement if, after it sends an OPEN message carrying the Capabilities Optional Parameter, it gets back a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. (This is a consequence of the base BGP-4 specification [RFC4271] and not a new requirement, so don't panic.) In that case the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending the Capabilities Optional Parameter to it 🌸

If a BGP speaker that supports a certain capability decides its peer doesn't support it, the speaker MAY send a NOTIFICATION message to the peer and terminate peering (see Section "Extensions to Error Handling" for more details). For example, a BGP speaker may need to terminate peering if it set up peering to exchange IPv6 routes and finds out that its peer doesn't support Multiprotocol Extensions for BGP-4 [RFC4760]. In that case the Error Subcode in the NOTIFICATION message is set to Unsupported Capability. The message MUST contain the capability or capabilities that caused the speaker to send it. The decision to send the message and terminate the peering is local to the speaker. If peering gets terminated, it SHOULD NOT be re-established automatically 😤

Heads up: a speaker that gets a capability it doesn't support or recognize MUST ignore that capability. Full stop, no drama. Specifically, the Unsupported Capability NOTIFICATION MUST NOT be generated, and the BGP session MUST NOT be terminated, just because of receiving a capability the local speaker doesn't support.

If a BGP speaker receives a capability from its peer that it doesn't itself support or recognize, it MUST ignore that capability. In particular, the Unsupported Capability NOTIFICATION message MUST NOT be generated and the BGP session MUST NOT be terminated in response to reception of a capability that is not supported by the local speaker 🙅‍♀️

4. Capabilities Optional Parameter (Parameter Type 2): 🎀

This is the Optional Parameter a BGP speaker uses to tell its BGP peer which capabilities it supports. The encoding of BGP Optional Parameters is specified in Section 4.2 of [RFC4271]. The parameter type of the Capabilities Optional Parameter is 2 💜

The parameter holds one or more triples <Capability Code, Capability Length, Capability Value>, and each triple is encoded like this:

          +------------------------------+
          | Capability Code (1 octet)    |
          +------------------------------+
          | Capability Length (1 octet)  |
          +------------------------------+
          | Capability Value (variable)  |
          ~                              ~
          +------------------------------+

So here's what each field does 🧚

• Capability Code: a one-octet unsigned binary integer that uniquely identifies individual capabilities. It's the ID card for each capability 🪪
• Capability Length: a one-octet unsigned binary integer that holds the length of the Capability Value field, in octets 📏
• Capability Value: a variable-length field, interpreted according to the value of the Capability Code field. It's the flexible bit 🌈

BGP speakers SHOULD NOT include more than one instance of a capability with the same Capability Code, Capability Length, and Capability Value. But, tea 🫖, processing multiple instances of that kind doesn't need any special handling, since extra copies don't change the meaning of the announced capability. So a BGP speaker MUST be prepared to accept such multiple instances. Chill, it's fine 🫶

BGP speakers MAY include more than one instance of a capability (identified by the Capability Code) that has a non-zero Capability Length field, as long as the Capability Value is different and the Capability Length is either the same or different. How these instances get processed is specific to the Capability Code, and the document introducing the new capability MUST describe it 🦋

The Capabilities Optional Parameter (OPEN Optional Parameter Type 2) SHOULD only be included in the OPEN message once. If the BGP speaker wants to include multiple capabilities in the OPEN message, it SHOULD do so as discussed above, by listing all of them as TLVs within a single Capabilities Optional Parameter. However, for backward compatibility, a BGP speaker MUST be prepared to receive an OPEN message that contains multiple Capabilities Optional Parameters, each holding one or more capabilities TLVs. The set of capabilities should be processed the same way either way, whether it's listed in a single Capabilities Optional Parameter of the OPEN message or split across several of them. It's giving consistency 👑

Appendix B. Comparison between RFC 3392 and This Document ✨

okay so bestie, this last appendix is the little changelog 🧾💅 it's basically saying what got tweaked between the older RFC 3392 and this new one 🦋

The main glow-ups:

• minor editorial changes plus updated references 📚
• the Unsupported Optional Parameter NOTIFICATION message got clarified 🔔
• the bit about what happens when the Capabilities Parameter shows up in an OPEN message more than once got clarified too 👯
• and a bunch of SHOULDs were upgraded to MUSTs 💪 (no cap, that's the big one, it makes the requirements way stricter 🔥)

Authors' Addresses 🎀

John G. Scudder Juniper Networks

EMail: jgs@juniper.net

Ravi Chandra Sonoa Systems

EMail: rchandra@sonoasystems.com

🫶 and that's the whole doc, periodt! 💖