1.1.Requirements Notation

2.2.BGP Config OS-TLV Format

The BGP Config IETF Organizationally Specific TLV (OS-TLV) willbe used to advertise BGP configuration information. Theconfiguration information will be composed of Sub-TLVs. Sincethe length is limited to 507 octets, multiple BGP Config OS-TLVscould be included in a single LLDP advertisement.¶

    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type (127)  |    Length       |  OUI (3 Octets) 00-00-5E      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |OUI Continued  |      TBD      |   BGP Config Sub-TLVs  ...    |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                             ...   (Up to 507 Octets)          |    Length     The length of the BGP TLV.    Subtype    IETF specific subtype for BGP Config OS-TLV. The               value shall be TBD.    Value      BGP Config Sub-TLVs each with a 1 byte Type and               Length. The Length will include solely the value               portion of the TLV and not the Type and Length               fields themselves.

  0                   1                   2                   3  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   Type (1)    |     Length    | Address Family| IPv4/IPv6     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~    IPv4/IPv6 Peering Address ...                              ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |         AFI                   |     SAFI      |   o o o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Type      The Sub-TLV Type value shall be 1.  Length    The Sub-TLV length in octets will be 4 for IPv4 or 16            for IPv6 plus 3 times the number of AFI/SAFI tuples.  Address  IANA Address family (1 for IPv4 or 2 for IPv6)  Family  Peering   An IPv4 address (4 octets) or an IPv6 address (16 octets)  Address  AFI/SAFI  One or more AFI/SAFI tuples for BGP session using this  Pairs     peering address. The AFI/SAFI tuple, 0/0, is a wildcard            indicating to attempt negotiation for all AFI/SAFIs.

    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type (2)      |Length (4 or 8)|         Local AS              |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |   Local AS                    | Optional Second Local AS      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Optional Second Local AS      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Type             The Sub-TLV Type value shall be 2.    Length           The Sub-TLV Length will be 4 or 8 octets.    Local AS         Local Autonomous System (AS)    Second Local AS  Local Autonomous System (AS)

    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type (3)      | Length (4)    |       BGP Identifier          |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |      BGP Identifier           |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Type            The Sub-TLV Type value shall be 3.    Length          The Sub-TLV Length will be 4 octets.    BGP Identifier  Local BGP Identifier (aka, BGP Router ID)

    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type (4)      | Length (4)    |       Session Group-ID        |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |   Session Group-ID            |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Type              The Sub-TLV Type value shall be 4.    Length            The Sub-TLV Length will be 4 octets.    Session Group-ID  The session group-id used to indicate a                      class or category of BGP session supported on                      the interface.

    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type (5)      | Length (8)    |   Session Capabilities        |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                Session Capabilities                           |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |  Session Capabilities         |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Type          The Sub-TLV Type value shall be 5.    Length        The Sub-TLV Length will be 8 octets.    Session       Bit fields identify BGP session capabilities    Capabilities

     Bit 1:   This bit indicates support for TCP MD5              authentication [TCP-MD5].     Bit 2:   This bit indicates support for TCP-AO              authentication [TCP-AO].     Bit 3:   This bit indicates support for Generalized TTL              Security Mechanism (GTSM) [GTSM] with a              configured TTL range of 254-255.

    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type (6)      |Length (1 - 64)|       Key Chain Name          |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                     Key Chain Name (Up to 64 Octets)          |                                 O                                 O                                 O   |                             O                                 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Type              The Sub-TLV Type value shall be 6.    Length            The Sub-TLV Length will be 1 - 64 octets.    Key Chain Name    The name of a key chain to be used for                      MD5 or TCP-AO authentication.

  0                   1                   2                   3  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   Type (7)    |     Length    | Address Family| IPv4/IPv6     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~    IPv4/IPv6 Local Address ...                                ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Type      The Sub-TLV Type value shall be 7.  Length    The Sub-TLV length in octets will be 4 for IPv4 or 16            for IPv6 plus 3 times the number of AFI/SAFI tuples.  Address  IANA Address family (1 for IPv4 or 2 for IPv6)  Family  Local   An IPv4 address (4 octets) or an IPv6 address (16 octets)  Address

    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type (3)      | Length (4)    |       BGP State Version       |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |      BGP State Version        |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Type               The Sub-TLV Type value shall be 8.    Length             The Sub-TLV Length will be 4 octets.    BGP State Version  BGP State Version - Monotonically increasing                       version number indicating if any local state                       that may effect BGP session establishment has                       changed.

3.1.Advertising BGP Speaker

A BGP speaker MAY advertise its BGP peering address in an LLDP PDU fora link using the BGP Local Address Sub-TLV of the BGP-OS TLV. This can bean IPv4 or IPv6 local address associated with the LLDP link for 1-hop peering.For 2-hop peering, it could be a loopback address or any other address thatis local to the node but not the LLDP link. As noted above, reachabilityto the loopback address is beyond the scope of this document.¶

A BGP speaker MAY advertise its local AS number using the BGPLocal AS Sub-TLV of the BGP-OS TLV. During AS transitions, a secondlocal AS number may be included in the Local AS Sub-TLV.The local BGP identifier mayalso be advertised using the BGP Identifier Sub-TLV of the BGP-OS TLV.While not specifically required for session establishment, the valuesmay be used for validation, trouble-shooting, and connectioncollision avoidance. A BGP speaker may also announce a Session Group-IDindicating the class or category of session(s) supported and/or mappingto a set of session parameters. Additionally, a BGP speaker MAYalso announcerelevant capabilities using BGP Session Capabilities Sub-TLV ofthe BGP-OS TLV.¶

If TCP MD5 authentication[RFC2385]or TCP Authentication Option (TCP-AO)[RFC5925] is tobe used on the session, the Key Chain Sub-TLV of the BGP-OS TLV MAY beused to specify the key chain name.¶

3.2.Receiving BGP Speaker

A BGP speaker configured for LLDP peer discovery WILL attempt toestablish BGP sessions using the address in the BGP Local Address Sub-TLVof BGP-OS TLV format.If the peering address is directly accessible over the link onwhich the LLDP PDU is received, the BGP speaker willattempt to establish a 1-hop BGP session with the peer.¶

If the received BGP Peering Address is not directly accessibleover the link, the peer must be reachable for the session to beestablished and the mechanisms for establishing reachability arebeyond the scope of this specification.If the BGP speaker receives the same BGP peering address in LLDP PDUsreceived on multiple links, it will not establish multiple sessions.Rather, a single 2-hop session will be established.¶

When the deployment of address families is fairly homogenous acrossthe deployment, the wildcard AFI/SAFI can be utilized to simplifyLLDP advertisement. When there is variance in the address familiessupported, usage of the wildcard could result in session establishmentdelay due to capabilities negotiation[RFC5492].¶

A BGP speaker MAY receive a remote neighbor's local AS number(s) inan LLDP PDU in the BGP Local AS Sub-TLV of the BGP-OS TLV. A BGP speakerMAY use the received local AS number(s) to perform validation checkingof the AS received in the OPEN message. A BGP speaker MAY receive a remoteneighbor's BGP Identifier in the BGP Identifier Sub-TLV of theBGP-OS TLV. This can be used to avoid connection collisions bydelaying session establishment if the remote BGP Identifier isgreater than the receiving speaker's BGP Identifier.¶

A BGP speaker MAY receive a Session Group-ID Sub-TLV in the LLDPBGP-OS TLV. This Session Group-ID may be used for validation and/ormapping the session to a particular set of session parameters.For example, the Session Group-ID could be mapped to a spine,leaf, or Top-of-Rack (ToR) session in a data center deployment andcan be used to detect cabling problems when an unexpected SessionGroup-ID is received.¶

Additionally, A BGP speaker MAYreceive a remote neighbor's capabilities in LLDP in the BGPSession Capabilities Sub-TLV of the BGP-OS TLV. A BGP speaker MAY usethe received capabilities to ensure appropriate local neighborconfiguration in order to facilitate session establishment.¶

If TCP MD5 authentication[RFC2385].or TCP Authentication Option (TCP-AO)[RFC5925] is to beused on the session as determined either via the SessionCapabilities Sub-TLV, Session Group-ID, or local policy, thekey chain name in the Key Chain Sub-TLV of the BGP-OS TLV MAY beused to identify the correct key chain[RFC8177].¶

The BGP State Version associated with the LLDP peer SHOULD be retained to determine whether anything impacting BGP session establishment has changed. When session establishment fails, this can be used to avoid back-off on attempting to establish a BGP session when nothing has changed on the peer or locally.¶

3.3.Updating or Deleting Auto-Discovery Parameters

A BGP speaker MAY change or delete any BGP LLDP auto-discovery parameter by simply updating or removing the corresponding Sub-TLV previously advertised in the BGP-OS TLV. Additionally, the BGP State Version Sub-TLV should be advertised with the version incremented from the previous version. The BGP speaker(s) receiving the advertisement will update or delete the changed or deleted auto-discovery parameters. However, there will be no change to existing BGP sessions with the advertising BGP Speaker. Changes to existing BGP sessions are the purview of the BGP protocol and are beyond the scope of this document.¶

Since LLDP information is cumulative, reception of an LLDP PDU without the BGP-OS TLV indicates that BGP LLDP auto-discovery has been disabled for the BGP speaker and all parameters learnt during BGP LLDP auto-discovery SHOULD be deleted. As above, changes to existing BGP sessions are beyond the scope of this document.¶

The LLDP Multi-Frame extension[LLDP-MULTIFRAME] removes the limit on a LLDP PDU being fitting in a single layer 2 frame. This will increase the number of TLVs which can be contained in LLDP PDU and the applicablity of LLDP as a BGP discovery protocol. The specificaiton of the LLDP API for BGP and other applications is beyond the scope of this document. However, it is RECOMMENDED that the LLDP BGP TLVs only be delivered to BGP when a complete LLDP PDU is received.¶

6.1.IANA Assigned LLDP Subtype

IANA is requested to assign a code point in the IANA Link Layer Discovery Protocol (LLDP) TLV Sub-Types Registry for BGP configuration. The value is TBD.¶

6.2.BGP Config LLDP OS-TLV Sub-TLVs

IANA is requested to create a registry for Sub-TLVs of the BGP Config LLDP OS-TLV. Assignments are requested as specified in the table below.¶

        +-------------+-----------------------------------+        | Range       | Assignment Policy                 |        +-------------+-----------------------------------+        | 0           | Reserved (not to be assigned)     |        |             |                                   |        | 1           | Peering Address                   |        |             |                                   |        | 2           | Local AS                          |        |             |                                   |        | 3           | BGP Identifier                    |        |             |                                   |        | 4           | Session Group-ID                  |        |             |                                   |        | 5           | Session Capabilities              |        |             |                                   |        | 6           | Key Chain Name                    |        |             |                                   |        | 7           | Local Address                     |        |             |                                   |        | 8           | BGP State Version                 |        |             |                                   |        | 9-127       | Unassigned (IETF Review)          |        |             |                                   |        | 128-254     | Reserved (Not to be assigned now) |        |             |                                   |        | 255         | Reserved (not to be assigned)     |        +-------------+-----------------------------------+

• Types in the range 9-127 are to be assigned subject to IETF Review. New values are assigned only through RFCs that have been shepherded through the IESG as AD-Sponsored or IETF WG Documents[RFC5226].¶
• Types in the range 128-254 are reserved and not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.¶

8.1.Normative References

[LLDP]

IEEE,"IEEE Standard for Local and metropolitan area networks-- Station and Media Access Control Connectivity Discovery Corrigendum 2: Technical and Editorial Corrections",IEEE 802.1AB-2009/Cor 2-2015,DOI 10.1109/ieeestd.2015.7056401,9 March 2015,<https://doi.org/10.1109/ieeestd.2015.7056401>.

[LLDP-MULTIFRAME]

IEEE,"IEEE Standard for Local and metropolitan area networks-- Station and Media Access Control Connectivity Discovery Amendment 2: Support for Multiframe Protocol Data Units",IEEE 802.1ABdh-2021,DOI 10.1109/IEEESTD.2022.9760302,19 April 2022,<https://doi.org/10.1109/IEEESTD.2022.9760302>.

[MACsec]

IEEE,"IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Security",IEEE Standard 802.1AE-2018,27 September 2018.

[MKA]

IEEE,"IEEE Standard for Local and metropolitan area networks - Port Based Network Access Control",IEEE Standard 802.1X-2020,30 January 2020.

[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., andS. Hares, Ed.,"A Border Gateway Protocol 4 (BGP-4)",RFC 4271,DOI 10.17487/RFC4271,January 2006,<https://www.rfc-editor.org/info/rfc4271>.

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

8.2.Informative References

[RFC2385]

Heffernan, A.,"Protection of BGP Sessions via the TCP MD5 Signature Option",RFC 2385,DOI 10.17487/RFC2385,August 1998,<https://www.rfc-editor.org/info/rfc2385>.

[RFC4760]

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

[RFC5082]

Gill, V.,Heasley, J.,Meyer, D.,Savola, P., Ed., andC. Pignataro,"The Generalized TTL Security Mechanism (GTSM)",RFC 5082,DOI 10.17487/RFC5082,October 2007,<https://www.rfc-editor.org/info/rfc5082>.

[RFC5226]

Narten, T. andH. Alvestrand,"Guidelines for Writing an IANA Considerations Section in RFCs",RFC 5226,DOI 10.17487/RFC5226,May 2008,<https://www.rfc-editor.org/info/rfc5226>.

[RFC5492]

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

[RFC5925]

Touch, J.,Mankin, A., andR. Bonica,"The TCP Authentication Option",RFC 5925,DOI 10.17487/RFC5925,June 2010,<https://www.rfc-editor.org/info/rfc5925>.

[RFC7042]

Eastlake 3rd, D. andJ. Abley,"IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters",BCP 141,RFC 7042,DOI 10.17487/RFC7042,October 2013,<https://www.rfc-editor.org/info/rfc7042>.

[RFC7938]

Lapukhov, P.,Premji, A., andJ. Mitchell, Ed.,"Use of BGP for Routing in Large-Scale Data Centers",RFC 7938,DOI 10.17487/RFC7938,August 2016,<https://www.rfc-editor.org/info/rfc7938>.

[RFC8177]

Lindem, A., Ed.,Qu, Y.,Yeung, D.,Chen, I., andJ. Zhang,"YANG Data Model for Key Chains",RFC 8177,DOI 10.17487/RFC8177,June 2017,<https://www.rfc-editor.org/info/rfc8177>.