idnits 2.17.1 draft-acee-idr-lldp-peer-discovery-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 8, 2021) is 985 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE-802-IANA' is mentioned on line 130, but not defined == Missing Reference: 'TCP-MD5' is mentioned on line 309, but not defined == Missing Reference: 'TCP-AO' is mentioned on line 312, but not defined == Missing Reference: 'GTSM' is mentioned on line 315, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MACsec' -- Possible downref: Non-RFC (?) normative reference: ref. 'MKA' -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track K. Patel 5 Expires: February 9, 2022 Arrcus, Inc 6 S. Zandi 7 LinkedIn 8 J. Haas 9 Juniper Networks, Inc 10 X. Xu 11 Capitalonline 12 August 8, 2021 14 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery 15 draft-acee-idr-lldp-peer-discovery-10 17 Abstract 19 Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is 20 implemented in networking equipment from many vendors. It is natural 21 for IETF protocols to avail this protocol for simple discovery tasks. 22 This document describes how BGP would use LLDP to discover directly 23 connected and 2-hop peers when peering is based on loopback 24 addresses. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 9, 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 62 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3 63 2. LLDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. LLDP IETF Organizationally Specific TLV Format . . . . . 3 65 2.2. BGP Config OS-TLV Format . . . . . . . . . . . . . . . . 4 66 2.2.1. BGP Config OS-TLV - Peering Address Sub-TLV . . . . . 5 67 2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV . . . . . . 6 68 2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV . . . . . 7 69 2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV . . . . 8 70 2.2.5. BGP Config OS-TLV - BGP Session Capabilities Sub-TLV 9 71 2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV . . . . . . . . 10 72 2.2.7. BGP Config OS-TLV - Local Address Sub-TLV . . . . . . 11 73 2.2.8. BGP Config OS-TLV - BGP State Version Sub-TLV . . . . 12 74 3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 13 75 3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 13 76 3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 13 77 4. LLDP Authentication/Encryption . . . . . . . . . . . . . . . 15 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 6.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 15 81 6.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 16 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 85 8.2. Informative References . . . . . . . . . . . . . . . . . 18 86 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 Link Layer Discovery Protocol (LLDP) [LLDP] or IEEE Std 802.1AB is 92 implemented in networking equipment from many vendors. It is natural 93 for IETF protocols to avail this protocol for simple discovery tasks. 94 This document describes how BGP [RFC4271] would use LLDP to discover 95 directly connected and 2-hop peers when peering is based on loopback 96 addresses. 98 1.1. Requirements Notation 100 1.1.1. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 2. LLDP Extensions 110 2.1. LLDP IETF Organizationally Specific TLV Format 112 The format of the LLDP IETF Organizationally Specific TLV (OS-TLV) is 113 defined in [LLDP]. It is shown below for completeness. 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Type (127) | Length | OUI (3 Octets) 00-00-5E | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | OUI Continued | Subtype | Value | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | ... (Up to 507 Octets) | 124 Type IETF Organizationally Specific TLV type value, 127. 126 Length The length of the remainder of the TLV. 128 OUI IETF Organizationally unique identifier for the 129 organization's OUI. For IANA, this is value is 130 00-00-5E as specified in [IEEE-802-IANA]. 132 Subtype IETF specific subtype 134 Value Value for organizationally specific TLV. The Length of 135 the value is 4 octets less than the TLV length. 137 LLDP IETF Organizationally Specific TLV 139 The OUI for IANA was allocated in section 1.4 of [RFC7042]. This 140 document requests creation of a registry for IETF specific sub-types 141 for LLDP IETF Organizationally Specific TLVs. 143 2.2. BGP Config OS-TLV Format 145 The BGP Config IETF Organizationally Specific TLV (OS-TLV) will be 146 used to advertise BGP configuration information. The configuration 147 information will be composed of Sub-TLVs. Since the length is 148 limited to 507 octets, multiple BGP Config OS-TLVs could be included 149 in a single LLDP advertisement. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type (127) | Length | OUI (3 Octets) 00-5E-00 | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 |OUI Continued | 1 | BGP Config Sub-TLVs ... | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | ... (Up to 507 Octets) | 160 Length The length of the BGP TLV. 162 Subtype IETF specific subtype for BGP Config OS-TLV. The 163 value shall be 1. 165 Value BGP Config Sub-TLVs each with a 1 byte Type and 166 Length. The Length will include solely the value 167 portion of the TLV and not the Type and Length 168 fields themselves. 170 2.2.1. BGP Config OS-TLV - Peering Address Sub-TLV 172 The BGP OS-TLV Peering Address Sub-TLV will be used to advertise the 173 local IP addresses used for BGP sessions and the associated address 174 families specified by AFI/SAFI tuples. The AFI/SAFI tuple, 0/0, 175 indicates to use the associated peering address for all locally 176 configured address families without an explicit peering address 177 specification. As always, the address families supported for a given 178 BGP session will be determined during capabilities negotiation 179 [RFC4760]. It is RECOMMENDED that the wildcard AFI/SAFI be used in 180 deployments with fairly homogenous address family usage. 182 The format of the BGP Peering Address Sub-TLV is shown below. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type (1) | Length | Address Family| IPv4/IPv6 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 ~ IPv4/IPv6 Peering Address ... ~ 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | AFI | SAFI | o o o 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Type The Sub-TLV Type value shall be 1. 196 Length The Sub-TLV length in octets will be 4 for IPv4 or 16 197 for IPv6 plus 3 times the number of AFI/SAFI tuples. 199 Address IANA Address family (1 for IPv4 or 2 for IPv6) 200 Family 202 Peering An IPv4 address (4 octets) or an IPv6 address (16 octets) 203 Address 205 AFI/SAFI One or more AFI/SAFI tuples for BGP session using this 206 Pairs peering address. The AFI/SAFI tuple, 0/0, is a wildcard 207 indicating to attempt negotiation for all AFI/SAFIs. 209 2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV 211 The BGP Config OS-TLV Local AS Sub-TLV will be used to advertise the 212 4-octet local Autonomous System (AS) number(s). For AS transitions, 213 a second local AS number may be specified. The format of the BGP 214 Local AS Sub-TLV is shown below. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type (2) |Length (4 or 8)| Local AS | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Local AS | Optional Second Local AS | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Optional Second Local AS | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Type The Sub-TLV Type value shall be 2. 228 Length The Sub-TLV Length will be 4 or 8 octets. 230 Local AS Local Autonomous System (AS) 232 Second Local AS Local Autonomous System (AS) 234 2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV 236 The BGP Config OS-TLV BGP Identifier Sub-TLV will be used to 237 advertise the 4-octet local BGP Identifier. The BGP Identifier is 238 used for debugging purposes and possibly to reduce the likelihood of 239 BGP connection collisions. The format of the BGP Identifier Sub-TLV 240 is shown below. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type (3) | Length (4) | BGP Identifier | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | BGP Identifier | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Type The Sub-TLV Type value shall be 3. 252 Length The Sub-TLV Length will be 4 octets. 254 BGP Identifier Local BGP Identifier (aka, BGP Router ID) 256 2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV 258 The BGP Config OS-TLV Session Group-ID Sub-TLV is an opaque 4-octet 259 value that is used to represent a category of BGP session that is 260 supported on the interface. The format of the Session Group-ID Sub- 261 TLV is shown below. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type (4) | Length (4) | Session Group-ID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Session Group-ID | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Type The Sub-TLV Type value shall be 4. 273 Length The Sub-TLV Length will be 4 octets. 275 Session Group-ID The session group-id used to indicate a 276 class or category of BGP session supported on 277 the interface. 279 2.2.5. BGP Config OS-TLV - BGP Session Capabilities Sub-TLV 281 The BGP Config OS-TLV Session Capabilities Sub-TLV will be used to 282 advertise an 8-octet Session Capabilities field. The session 283 capabilities are represented as bit flags identifying the supported 284 BGP session capabilities. The format of the BGP Session Capabilities 285 Sub-TLV is shown below. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type (5) | Length (8) | Session Capabilities | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Session Capabilities | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Session Capabilities | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Type The Sub-TLV Type value shall be 5. 299 Length The Sub-TLV Length will be 8 octets. 301 Session Bit fields identify BGP session capabilities 302 Capabilities 304 The BGP Session Capabilities is an 8-octet bit field. The most 305 significant bit is the first bit (Bit 1) of the Session Capabilities. 306 The following bits are defined: 308 Bit 1: This bit indicates support for TCP MD5 309 authentication [TCP-MD5]. 311 Bit 2: This bit indicates support for TCP-AO 312 authentication [TCP-AO]. 314 Bit 3: This bit indicates support for Generalized TTL 315 Security Mechanism (GTSM) [GTSM] with a 316 configured TTL range of 254-255. 318 TCP MD5 authentication is described in [RFC2385]. The TCP 319 Authentication Option (TCP-AO) is described in [RFC5925]. The 320 Generalized TTL Security Mechanism (GTSM) is described in [RFC5082]. 321 If both TCP MD5 authentication and TCP-AO authentication are 322 specified and TCP-AO is supported, it will take precedence. 324 2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV 326 The BGP Config OS-TLV Key Chain Sub-TLV is a string specifying the 327 name for the key chain used for session authentication. Key chains 328 [RFC8177] are a commonly used for protocol authentication and 329 encryption key specification. Given the limited length of all BGP 330 configuration information, the key chain name will be limited to 64 331 characters and will not include a trailing string delimiter. The 332 format of the Session Group-ID Sub-TLV is shown below. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type (6) |Length (1 - 64)| Key Chain Name | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Key Chain Name (Up to 64 Octets) | 340 O 341 O 342 O 343 | Key Chain Name | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Type The Sub-TLV Type value shall be 6. 348 Length The Sub-TLV Length will be 1 - 64 octets. 350 Key Chain Name The name of a key chain to be used for 351 MD5 or TCP-AO authentication. 353 2.2.7. BGP Config OS-TLV - Local Address Sub-TLV 355 The BGP OS-TLV Local Address Sub-TLV will be used to advertise a 356 local IP addresses used for BGP next-hops. Advertising a local 357 interface address is useful when the address family is different from 358 the advertised BGP peering address. 360 The format of the BGP Local Interface Address Sub-TLV is shown below. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type (7) | Length | Address Family| IPv4/IPv6 | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 ~ IPv4/IPv6 Local Address ... ~ 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Type The Sub-TLV Type value shall be 7. 372 Length The Sub-TLV length in octets will be 4 for IPv4 or 16 373 for IPv6 plus 3 times the number of AFI/SAFI tuples. 375 Address IANA Address family (1 for IPv4 or 2 for IPv6) 376 Family 378 Local An IPv4 address (4 octets) or an IPv6 address (16 octets) 379 Address 381 2.2.8. BGP Config OS-TLV - BGP State Version Sub-TLV 383 The BGP OS-TLV Version Sub-TLV will be used to advertise a 384 monotonically increasing version. This version will indicate if any 385 local BGP state that may impact BGP session establishment has 386 changed. Changes can range from anything as obvious a change in 387 local peering address to more indirect changes such as the 388 modification of the key-chain being advertised. 390 The format of the BGP State Version Sub-TLV is shown below. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Type (3) | Length (4) | BGP State Version | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | BGP State Version | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Type The Sub-TLV Type value shall be 8. 402 Length The Sub-TLV Length will be 4 octets. 404 BGP State Version BGP State Version - Monotonically increasing 405 version number indicating if any local state 406 that may effect BGP session establishment has 407 changed. 409 3. BGP LLDP Peer Discovery Operations 411 The simple use case is to just use the peer address advertised in the 412 LLDP Packet Data Unit (PDU) to establish a 1-hop BGP peer session. 413 This can be used in data centers using BGP as described in [RFC7938]. 414 The use case where a loopback address or other local address is 415 advertised as the peering address is also supported. However, 416 reachabiliy to a peering address other than the interface address is 417 beyond the scope of this document. 419 3.1. Advertising BGP Speaker 421 A BGP speaker MAY advertise its BGP peering address in an LLDP PDU 422 for a link using the BGP Local Address Sub-TLV of the BGP-OS TLV. 423 This can be an IPv4 or IPv6 local address associated with the LLDP 424 link for 1-hop peering. For 2-hop peering, it could be a loopback 425 address or any other address that is local to the node but not the 426 LLDP link. As noted above, reachability to the loopback address is 427 beyond the scope of this document. 429 A BGP speaker MAY advertise its local AS number using the BGP Local 430 AS Sub-TLV of the BGP-OS TLV. During AS transitions, a second local 431 AS number may be included in the Local AS Sub-TLV. The local BGP 432 identifier may also be advertised using the BGP Identifier Sub-TLV of 433 the BGP-OS TLV. While not specifically required for session 434 establishment, the values may be used for validation, trouble- 435 shooting, and connection collision avoidance. A BGP speaker may also 436 announce a Session Group-ID indicating the class or category of 437 session(s) supported and/or mapping to a set of session parameters. 438 Additionally, a BGP speaker MAY also announce relevant capabilities 439 using BGP Session Capabilities Sub-TLV of the BGP-OS TLV. 441 If TCP MD5 authentication [RFC2385] or TCP Authentication Option 442 (TCP-AO) [RFC5925] is to be used on the session, the Key Chain Sub- 443 TLV of the BGP-OS TLV MAY be used to specify the key chain name. 445 3.2. Receiving BGP Speaker 447 A BGP speaker configured for LLDP peer discovery WILL attempt to 448 establish BGP sessions using the address in the BGP Local Address 449 Sub-TLV of BGP-OS TLV format. If the peering address is directly 450 accessible over the link on which the LLDP PDU is received, the BGP 451 speaker will attempt to establish a 1-hop BGP session with the peer. 453 If the received BGP Peering Address is not directly accessible over 454 the link, the peer must be reachable for the session to be 455 established and the mechanisms for establishing reachability are 456 beyond the scope of this specification. If the BGP speaker receives 457 the same BGP peering address in LLDP PDUs received on multiple links, 458 it will not establish multiple sessions. Rather, a single 2-hop 459 session will be established. 461 When the deployment of address families is fairly homogenous across 462 the deployment, the wildcard AFI/SAFI can be utilized to simplify 463 LLDP advertisement. When there is variance in the address families 464 supported, usage of the wildcard could result in session 465 establishment delay due to capabilities negotiation [RFC5492]. 467 A BGP speaker MAY receive a remote neighbor's local AS number(s) in 468 an LLDP PDU in the BGP Local AS Sub-TLV of the BGP-OS TLV. A BGP 469 speaker MAY use the received local AS number(s) to perform validation 470 checking of the AS received in the OPEN message. A BGP speaker MAY 471 receive a remote neighbor's BGP Identifier in the BGP Identifier Sub- 472 TLV of the BGP-OS TLV. This can be used to avoid connection 473 collisions by delaying session establishment if the remote BGP 474 Identifier is greater than the receiving speaker's BGP Identifier. 476 A BGP speaker MAY receive a Session Group-ID Sub-TLV in the LLDP BGP- 477 OS TLV. This Session Group-ID may be used for validation and/or 478 mapping the session to a particular set of session parameters. For 479 example, the Session Group-ID could be mapped to a spine, leaf, or 480 Top-of-Rack (ToR) session in a data center deployment and can be used 481 to detect cabling problems when an unexpected Session Group-ID is 482 received. 484 Additionally, A BGP speaker MAY receive a remote neighbor's 485 capabilities in LLDP in the BGP Session Capabilities Sub-TLV of the 486 BGP-OS TLV. A BGP speaker MAY use the received capabilities to 487 ensure appropriate local neighbor configuration in order to 488 facilitate session establishment. 490 If TCP MD5 authentication [RFC2385]. or TCP Authentication Option 491 (TCP-AO) [RFC5925] is to be used on the session as determined either 492 via the Session Capabilities Sub-TLV, Session Group-ID, or local 493 policy, the key chain name in the Key Chain Sub-TLV of the BGP-OS TLV 494 MAY be used to identify the correct key chain [RFC8177]. 496 The BGP State Version associated with the LLDP peer SHOULD be 497 retained to determine whether anything impacting BGP session 498 establishment has changed. When session establishment fails, this 499 can be used to avoid back-off on attempting to establish a BGP 500 session when nothing has changed on the peer or locally. 502 4. LLDP Authentication/Encryption 504 The IEEE 802.1AE [MACsec] standard can be used for encryption and/or 505 authentication to provide privacy and integrity. MACsec utilizes the 506 Galois/Counter Mode Advanced Encryption Standard (AES-GCM) for 507 authenticated encryption and Galois Message Authentication Code 508 (GMAC) if only authentication, but not encryption is required. 510 The MACsec Key Agreement (MKA) is included as part of the IEEE 511 802.1X-20200 Port-Based Network Access Control Standard [MKA]. The 512 purpose of MKA is to provide a method for discovering MACsec peers 513 and negotiating the security keys needed to secure the link. 515 5. Security Considerations 517 This security considerations for BGP [RFC4271] apply equally to this 518 extension. 520 Additionally, BGP peering address discovery should only be done on 521 trusted links (e.g., in a data center network) since LLDP packets are 522 not authenticated or encrypted [LLDP]. 524 LLDP Authentication and/or encryption can provided as described in 525 section Section 4. 527 6. IANA Considerations 529 6.1. IANA Assigned LLDP Subtype 531 IANA is requested to create a registry for IANA assigned subtypes in 532 the IETF Organizationally Specific TLV assigned to IANA (OUI of 533 000-00-53 [RFC7042]. Assignment is requested for 1 for the BGP 534 Config OS-TLV. 536 +-------------+-----------------------------------+ 537 | Range | Assignment Policy | 538 +-------------+-----------------------------------+ 539 | 0 | Reserved (not to be assigned) | 540 | | | 541 | 1 | BGP Configuration | 542 | | | 543 | 2-127 | Unassigned (IETF Review) | 544 | | | 545 | 128-254 | Reserved (Not to be assigned now) | 546 | | | 547 | 255 | Reserved (not to be assigned) | 548 +-------------+-----------------------------------+ 550 IANA LLDP IETF Organizationally Specific TLV Sub-Types 552 o Types in the range 2-127 are to be assigned subject to IETF 553 Review. New values are assigned only through RFCs that have been 554 shepherded through the IESG as AD-Sponsored or IETF WG Documents 555 [RFC5226]. 557 o Types in the range 128-254 are reserved and not to be assigned at 558 this time. Before any assignments can be made in this range, 559 there MUST be a Standards Track RFC that specifies IANA 560 Considerations that covers the range being assigned. 562 6.2. BGP Config LLDP OS-TLV Sub-TLVs 564 IANA is requested to create a registry for Sub-TLVs of the BGP Config 565 LLDP OS-TLV. Assignment is requested for 1 for the BGP Peering 566 Address Sub-TLV. Assignment is also requested for 2 for the Local AS 567 Sub-TLV. Additionally, assignment is requested for 3 for the BGP 568 Identifier Sub-TLV, 4 for the BGP Session Group-ID, 5 for the Session 569 Capabilities Sub-TLV, and 6 for the Key Chain Name. 571 +-------------+-----------------------------------+ 572 | Range | Assignment Policy | 573 +-------------+-----------------------------------+ 574 | 0 | Reserved (not to be assigned) | 575 | | | 576 | 1 | Peering Address | 577 | | | 578 | 2 | Local AS | 579 | | | 580 | 3 | BGP Identifier | 581 | | | 582 | 4 | Session Group-ID | 583 | | | 584 | 5 | Session Capabilities | 585 | | | 586 | 6 | Key Chain Name | 587 | | | 588 | 7 | Local Address | 589 | | | 590 | 8 | BGP State Version | 591 | | | 592 | 9-127 | Unassigned (IETF Review) | 593 | | | 594 | 128-254 | Reserved (Not to be assigned now) | 595 | | | 596 | 255 | Reserved (not to be assigned) | 597 +-------------+-----------------------------------+ 599 LLDP BGP Config OS-TLV Types 601 o Types in the range 9-127 are to be assigned subject to IETF 602 Review. New values are assigned only through RFCs that have been 603 shepherded through the IESG as AD-Sponsored or IETF WG Documents 604 [RFC5226]. 606 o Types in the range 128-254 are reserved and not to be assigned at 607 this time. Before any assignments can be made in this range, 608 there MUST be a Standards Track RFC that specifies IANA 609 Considerations that covers the range being assigned. 611 7. Contributors 613 Contributors' Addresses 615 8. References 617 8.1. Normative References 619 [LLDP] IEEE, "IEEE Standard for Local and metropolitan area 620 networks-- Station and Media Access Control Connectivity 621 Discovery Corrigendum 2: Technical and Editorial 622 Corrections", IEEE 802.1AB-2009/Cor 2-2015, 623 DOI 10.1109/ieeestd.2015.7056401, March 2015. 625 [MACsec] IEEE, "IEEE Standard for Local and metropolitan area 626 networks - Media Access Control (MAC) Security", 627 IEEE Standard 802.1AE-2018, September 2018. 629 [MKA] IEEE, "IEEE Standard for Local and metropolitan area 630 networks - Port Based Network Access Control", 631 IEEE Standard 802.1X-2020, January 2020. 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, 635 DOI 10.17487/RFC2119, March 1997, 636 . 638 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 639 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 640 DOI 10.17487/RFC4271, January 2006, 641 . 643 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 644 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 645 May 2017, . 647 8.2. Informative References 649 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 650 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 651 1998, . 653 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 654 "Multiprotocol Extensions for BGP-4", RFC 4760, 655 DOI 10.17487/RFC4760, January 2007, 656 . 658 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 659 Pignataro, "The Generalized TTL Security Mechanism 660 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 661 . 663 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 664 IANA Considerations Section in RFCs", RFC 5226, 665 DOI 10.17487/RFC5226, May 2008, 666 . 668 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 669 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 670 2009, . 672 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 673 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 674 June 2010, . 676 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 677 IETF Protocol and Documentation Usage for IEEE 802 678 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 679 October 2013, . 681 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 682 BGP for Routing in Large-Scale Data Centers", RFC 7938, 683 DOI 10.17487/RFC7938, August 2016, 684 . 686 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 687 Zhang, "YANG Data Model for Key Chains", RFC 8177, 688 DOI 10.17487/RFC8177, June 2017, 689 . 691 Appendix A. Acknowledgments 693 Thanks to Sujay Gupta and Paul Congdon for review and comments. 695 The RFC text was produced using Marshall Rose's xml2rfc tool. 697 Authors' Addresses 699 Acee Lindem 700 Cisco Systems 701 301 Midenhall Way 702 Cary, NC 27513 703 USA 705 Email: acee@cisco.com 706 Keyur Patel 707 Arrcus, Inc 709 Email: keyur@arrcus.com 711 Shawn Zandi 712 LinkedIn 713 222 2nd Street 714 San Francisco, CA 94105 715 USA 717 Email: szandi@linkedin.com 719 Jeff Haas 720 Juniper Networks, Inc 721 1133 Innovation, Inc. 722 Sunnyvale, CA 94089 723 USA 725 Email: jhaas@juniper.net 727 Xiaohu Xu 728 Capitalonline 730 Email: xiaohu.xu@capitalonline.net