idnits 2.17.00 (12 Aug 2021) /tmp/idnits60653/draft-acee-idr-lldp-peer-discovery-11.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 document date (15 February 2022) is 88 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 131, but not defined == Missing Reference: 'TCP-MD5' is mentioned on line 310, but not defined == Missing Reference: 'TCP-AO' is mentioned on line 313, but not defined == Missing Reference: 'GTSM' is mentioned on line 316, 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) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 6 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: 19 August 2022 Arrcus, Inc 6 S. Zandi 7 LinkedIn 8 J. Haas 9 Juniper Networks, Inc 10 X. Xu 11 Capitalonline 12 15 February 2022 14 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery 15 draft-acee-idr-lldp-peer-discovery-11 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 19 August 2022. 43 Copyright Notice 45 Copyright (c) 2022 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 61 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3 62 2. LLDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. LLDP IETF Organizationally Specific TLV Format . . . . . 3 64 2.2. BGP Config OS-TLV Format . . . . . . . . . . . . . . . . 4 65 2.2.1. BGP Config OS-TLV - Peering Address Sub-TLV . . . . . 4 66 2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV . . . . . . 5 67 2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV . . . . . 6 68 2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV . . . . 7 69 2.2.5. BGP Config OS-TLV - BGP Session Capabilities 70 Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV . . . . . . . . 8 72 2.2.7. BGP Config OS-TLV - Local Address Sub-TLV . . . . . . 9 73 2.2.8. BGP Config OS-TLV - BGP State Version Sub-TLV . . . . 10 74 3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 11 75 3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 11 76 3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 12 77 3.3. Updating or Deleting Auto-Discovery Parameters . . . . . 13 78 4. LLDP Authentication/Encryption . . . . . . . . . . . . . . . 13 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 6.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 14 82 6.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 15 83 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 8.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Link Layer Discovery Protocol (LLDP) [LLDP] or IEEE Std 802.1AB is 93 implemented in networking equipment from many vendors. It is natural 94 for IETF protocols to avail this protocol for simple discovery tasks. 95 This document describes how BGP [RFC4271] would use LLDP to discover 96 directly connected and 2-hop peers when peering is based on loopback 97 addresses. 99 1.1. Requirements Notation 101 1.1.1. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. LLDP Extensions 111 2.1. LLDP IETF Organizationally Specific TLV Format 113 The format of the LLDP IETF Organizationally Specific TLV (OS-TLV) is 114 defined in [LLDP]. It is shown below for completeness. 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Type (127) | Length | OUI (3 Octets) 00-00-5E | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | OUI Continued | Subtype | Value | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | ... (Up to 507 Octets) | 125 Type IETF Organizationally Specific TLV type value, 127. 127 Length The length of the remainder of the TLV. 129 OUI IETF Organizationally unique identifier for the 130 organization's OUI. For IANA, this is value is 131 00-00-5E as specified in [IEEE-802-IANA]. 133 Subtype IETF specific subtype 135 Value Value for organizationally specific TLV. The Length of 136 the value is 4 octets less than the TLV length. 138 Figure 1: LLDP IETF Organizationally Specific TLV 140 The OUI for IANA was allocated in section 1.4 of [RFC7042]. This 141 document requests creation of a registry for IETF specific sub-types 142 for LLDP IETF Organizationally Specific TLVs. 144 2.2. BGP Config OS-TLV Format 146 The BGP Config IETF Organizationally Specific TLV (OS-TLV) will be 147 used to advertise BGP configuration information. The configuration 148 information will be composed of Sub-TLVs. Since the length is 149 limited to 507 octets, multiple BGP Config OS-TLVs could be included 150 in a single LLDP advertisement. 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type (127) | Length | OUI (3 Octets) 00-5E-00 | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 |OUI Continued | 1 | BGP Config Sub-TLVs ... | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | ... (Up to 507 Octets) | 161 Length The length of the BGP TLV. 163 Subtype IETF specific subtype for BGP Config OS-TLV. The 164 value shall be 1. 166 Value BGP Config Sub-TLVs each with a 1 byte Type and 167 Length. The Length will include solely the value 168 portion of the TLV and not the Type and Length 169 fields themselves. 171 2.2.1. BGP Config OS-TLV - Peering Address Sub-TLV 173 The BGP OS-TLV Peering Address Sub-TLV will be used to advertise the 174 local IP addresses used for BGP sessions and the associated address 175 families specified by AFI/SAFI tuples. The AFI/SAFI tuple, 0/0, 176 indicates to use the associated peering address for all locally 177 configured address families without an explicit peering address 178 specification. As always, the address families supported for a given 179 BGP session will be determined during capabilities negotiation 180 [RFC4760]. It is RECOMMENDED that the wildcard AFI/SAFI be used in 181 deployments with fairly homogenous address family usage. 183 The format of the BGP Peering Address Sub-TLV is shown below. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type (1) | Length | Address Family| IPv4/IPv6 | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 ~ IPv4/IPv6 Peering Address ... ~ 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | AFI | SAFI | o o o 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Type The Sub-TLV Type value shall be 1. 197 Length The Sub-TLV length in octets will be 4 for IPv4 or 16 198 for IPv6 plus 3 times the number of AFI/SAFI tuples. 200 Address IANA Address family (1 for IPv4 or 2 for IPv6) 201 Family 203 Peering An IPv4 address (4 octets) or an IPv6 address (16 octets) 204 Address 206 AFI/SAFI One or more AFI/SAFI tuples for BGP session using this 207 Pairs peering address. The AFI/SAFI tuple, 0/0, is a wildcard 208 indicating to attempt negotiation for all AFI/SAFIs. 210 2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV 212 The BGP Config OS-TLV Local AS Sub-TLV will be used to advertise the 213 4-octet local Autonomous System (AS) number(s). For AS transitions, 214 a second local AS number may be specified. The format of the BGP 215 Local AS Sub-TLV is shown below. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Type (2) |Length (4 or 8)| Local AS | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Local AS | Optional Second Local AS | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Optional Second Local AS | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Type The Sub-TLV Type value shall be 2. 229 Length The Sub-TLV Length will be 4 or 8 octets. 231 Local AS Local Autonomous System (AS) 233 Second Local AS Local Autonomous System (AS) 235 2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV 237 The BGP Config OS-TLV BGP Identifier Sub-TLV will be used to 238 advertise the 4-octet local BGP Identifier. The BGP Identifier is 239 used for debugging purposes and possibly to reduce the likelihood of 240 BGP connection collisions. The format of the BGP Identifier Sub-TLV 241 is shown below. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type (3) | Length (4) | BGP Identifier | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | BGP Identifier | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Type The Sub-TLV Type value shall be 3. 253 Length The Sub-TLV Length will be 4 octets. 255 BGP Identifier Local BGP Identifier (aka, BGP Router ID) 257 2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV 259 The BGP Config OS-TLV Session Group-ID Sub-TLV is an opaque 4-octet 260 value that is used to represent a category of BGP session that is 261 supported on the interface. The format of the Session Group-ID Sub- 262 TLV is shown below. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type (4) | Length (4) | Session Group-ID | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Session Group-ID | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Type The Sub-TLV Type value shall be 4. 274 Length The Sub-TLV Length will be 4 octets. 276 Session Group-ID The session group-id used to indicate a 277 class or category of BGP session supported on 278 the interface. 280 2.2.5. BGP Config OS-TLV - BGP Session Capabilities Sub-TLV 282 The BGP Config OS-TLV Session Capabilities Sub-TLV will be used to 283 advertise an 8-octet Session Capabilities field. The session 284 capabilities are represented as bit flags identifying the supported 285 BGP session capabilities. The format of the BGP Session Capabilities 286 Sub-TLV is shown below. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type (5) | Length (8) | Session Capabilities | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Session Capabilities | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Session Capabilities | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Type The Sub-TLV Type value shall be 5. 300 Length The Sub-TLV Length will be 8 octets. 302 Session Bit fields identify BGP session capabilities 303 Capabilities 305 The BGP Session Capabilities is an 8-octet bit field. The most 306 significant bit is the first bit (Bit 1) of the Session Capabilities. 307 The following bits are defined: 309 Bit 1: This bit indicates support for TCP MD5 310 authentication [TCP-MD5]. 312 Bit 2: This bit indicates support for TCP-AO 313 authentication [TCP-AO]. 315 Bit 3: This bit indicates support for Generalized TTL 316 Security Mechanism (GTSM) [GTSM] with a 317 configured TTL range of 254-255. 319 TCP MD5 authentication is described in [RFC2385]. The TCP 320 Authentication Option (TCP-AO) is described in [RFC5925]. The 321 Generalized TTL Security Mechanism (GTSM) is described in [RFC5082]. 322 If both TCP MD5 authentication and TCP-AO authentication are 323 specified and TCP-AO is supported, it will take precedence. 325 2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV 327 The BGP Config OS-TLV Key Chain Sub-TLV is a string specifying the 328 name for the key chain used for session authentication. Key chains 329 [RFC8177] are a commonly used for protocol authentication and 330 encryption key specification. Given the limited length of all BGP 331 configuration information, the key chain name will be limited to 64 332 characters and will not include a trailing string delimiter. The 333 format of the Session Group-ID Sub-TLV is shown below. 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type (6) |Length (1 - 64)| Key Chain Name | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Key Chain Name (Up to 64 Octets) | 341 O 342 O 343 O 344 | Key Chain Name | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Type The Sub-TLV Type value shall be 6. 349 Length The Sub-TLV Length will be 1 - 64 octets. 351 Key Chain Name The name of a key chain to be used for 352 MD5 or TCP-AO authentication. 354 2.2.7. BGP Config OS-TLV - Local Address Sub-TLV 356 The BGP OS-TLV Local Address Sub-TLV will be used to advertise a 357 local IP addresses used for BGP next-hops. Advertising a local 358 interface address is useful when the address family is different from 359 the advertised BGP peering address. 361 The format of the BGP Local Interface Address Sub-TLV is shown below. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type (7) | Length | Address Family| IPv4/IPv6 | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 ~ IPv4/IPv6 Local Address ... ~ 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Type The Sub-TLV Type value shall be 7. 373 Length The Sub-TLV length in octets will be 4 for IPv4 or 16 374 for IPv6 plus 3 times the number of AFI/SAFI tuples. 376 Address IANA Address family (1 for IPv4 or 2 for IPv6) 377 Family 379 Local An IPv4 address (4 octets) or an IPv6 address (16 octets) 380 Address 382 2.2.8. BGP Config OS-TLV - BGP State Version Sub-TLV 384 The BGP OS-TLV Version Sub-TLV will be used to advertise a 385 monotonically increasing version. This version will indicate if any 386 local BGP state that may impact BGP session establishment has 387 changed. Changes can range from anything as obvious a change in 388 local peering address to more indirect changes such as the 389 modification of the key-chain being advertised. 391 The format of the BGP State Version Sub-TLV is shown below. 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type (3) | Length (4) | BGP State Version | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | BGP State Version | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Type The Sub-TLV Type value shall be 8. 403 Length The Sub-TLV Length will be 4 octets. 405 BGP State Version BGP State Version - Monotonically increasing 406 version number indicating if any local state 407 that may effect BGP session establishment has 408 changed. 410 3. BGP LLDP Peer Discovery Operations 412 The simple use case is to just use the peer address advertised in the 413 LLDP Packet Data Unit (PDU) to establish a 1-hop BGP peer session. 414 This can be used in data centers using BGP as described in [RFC7938]. 415 The use case where a loopback address or other local address is 416 advertised as the peering address is also supported. However, 417 reachabiliy to a peering address other than the interface address is 418 beyond the scope of this document. 420 3.1. Advertising BGP Speaker 422 A BGP speaker MAY advertise its BGP peering address in an LLDP PDU 423 for a link using the BGP Local Address Sub-TLV of the BGP-OS TLV. 424 This can be an IPv4 or IPv6 local address associated with the LLDP 425 link for 1-hop peering. For 2-hop peering, it could be a loopback 426 address or any other address that is local to the node but not the 427 LLDP link. As noted above, reachability to the loopback address is 428 beyond the scope of this document. 430 A BGP speaker MAY advertise its local AS number using the BGP Local 431 AS Sub-TLV of the BGP-OS TLV. During AS transitions, a second local 432 AS number may be included in the Local AS Sub-TLV. The local BGP 433 identifier may also be advertised using the BGP Identifier Sub-TLV of 434 the BGP-OS TLV. While not specifically required for session 435 establishment, the values may be used for validation, trouble- 436 shooting, and connection collision avoidance. A BGP speaker may also 437 announce a Session Group-ID indicating the class or category of 438 session(s) supported and/or mapping to a set of session parameters. 439 Additionally, a BGP speaker MAY also announce relevant capabilities 440 using BGP Session Capabilities Sub-TLV of the BGP-OS TLV. 442 If TCP MD5 authentication [RFC2385] or TCP Authentication Option 443 (TCP-AO) [RFC5925] is to be used on the session, the Key Chain Sub- 444 TLV of the BGP-OS TLV MAY be used to specify the key chain name. 446 3.2. Receiving BGP Speaker 448 A BGP speaker configured for LLDP peer discovery WILL attempt to 449 establish BGP sessions using the address in the BGP Local Address 450 Sub-TLV of BGP-OS TLV format. If the peering address is directly 451 accessible over the link on which the LLDP PDU is received, the BGP 452 speaker will attempt to establish a 1-hop BGP session with the peer. 454 If the received BGP Peering Address is not directly accessible over 455 the link, the peer must be reachable for the session to be 456 established and the mechanisms for establishing reachability are 457 beyond the scope of this specification. If the BGP speaker receives 458 the same BGP peering address in LLDP PDUs received on multiple links, 459 it will not establish multiple sessions. Rather, a single 2-hop 460 session will be established. 462 When the deployment of address families is fairly homogenous across 463 the deployment, the wildcard AFI/SAFI can be utilized to simplify 464 LLDP advertisement. When there is variance in the address families 465 supported, usage of the wildcard could result in session 466 establishment delay due to capabilities negotiation [RFC5492]. 468 A BGP speaker MAY receive a remote neighbor's local AS number(s) in 469 an LLDP PDU in the BGP Local AS Sub-TLV of the BGP-OS TLV. A BGP 470 speaker MAY use the received local AS number(s) to perform validation 471 checking of the AS received in the OPEN message. A BGP speaker MAY 472 receive a remote neighbor's BGP Identifier in the BGP Identifier Sub- 473 TLV of the BGP-OS TLV. This can be used to avoid connection 474 collisions by delaying session establishment if the remote BGP 475 Identifier is greater than the receiving speaker's BGP Identifier. 477 A BGP speaker MAY receive a Session Group-ID Sub-TLV in the LLDP BGP- 478 OS TLV. This Session Group-ID may be used for validation and/or 479 mapping the session to a particular set of session parameters. For 480 example, the Session Group-ID could be mapped to a spine, leaf, or 481 Top-of-Rack (ToR) session in a data center deployment and can be used 482 to detect cabling problems when an unexpected Session Group-ID is 483 received. 485 Additionally, A BGP speaker MAY receive a remote neighbor's 486 capabilities in LLDP in the BGP Session Capabilities Sub-TLV of the 487 BGP-OS TLV. A BGP speaker MAY use the received capabilities to 488 ensure appropriate local neighbor configuration in order to 489 facilitate session establishment. 491 If TCP MD5 authentication [RFC2385]. or TCP Authentication Option 492 (TCP-AO) [RFC5925] is to be used on the session as determined either 493 via the Session Capabilities Sub-TLV, Session Group-ID, or local 494 policy, the key chain name in the Key Chain Sub-TLV of the BGP-OS TLV 495 MAY be used to identify the correct key chain [RFC8177]. 497 The BGP State Version associated with the LLDP peer SHOULD be 498 retained to determine whether anything impacting BGP session 499 establishment has changed. When session establishment fails, this 500 can be used to avoid back-off on attempting to establish a BGP 501 session when nothing has changed on the peer or locally. 503 3.3. Updating or Deleting Auto-Discovery Parameters 505 A BGP speaker MAY change or delete any BGP LLDP auto-discovery 506 parameter by simply updating or removing the corresponding Sub-TLV 507 previously advertised in the BGP-OS TLV. Additionally, the BGP State 508 Version Sub-TLV should be advertised with the version incremented 509 from the previous version. The BGP speaker(s) receiving the 510 advertisement will update or delete the changed or deleted auto- 511 discovery parameters. However, there will be no change to existing 512 BGP sessions with the advertising BGP Speaker. Changes to existing 513 BGP sessions are the purview of the BGP protocol and are beyond the 514 scope of this document. 516 Since LLDP information is cumulative, reception of an LLDP PDU 517 without the BGP-OS TLV indicates that BGP LLDP auto-discovery has 518 been disabled for the BGP speaker and all parameters learnt during 519 BGP LLDP auto-discovery SHOULD be deleted. As above, changes to 520 existing BGP sessions are beyond the scope of this document. 522 4. LLDP Authentication/Encryption 524 The IEEE 802.1AE [MACsec] standard can be used for encryption and/or 525 authentication to provide privacy and integrity. MACsec utilizes the 526 Galois/Counter Mode Advanced Encryption Standard (AES-GCM) for 527 authenticated encryption and Galois Message Authentication Code 528 (GMAC) if only authentication, but not encryption is required. 530 The MACsec Key Agreement (MKA) is included as part of the IEEE 531 802.1X-20200 Port-Based Network Access Control Standard [MKA]. The 532 purpose of MKA is to provide a method for discovering MACsec peers 533 and negotiating the security keys needed to secure the link. 535 5. Security Considerations 537 This security considerations for BGP [RFC4271] apply equally to this 538 extension. 540 Additionally, BGP peering address discovery should only be done on 541 trusted links (e.g., in a data center network) since LLDP packets are 542 not authenticated or encrypted [LLDP]. 544 LLDP Authentication and/or encryption can provided as described in 545 section Section 4. 547 6. IANA Considerations 549 6.1. IANA Assigned LLDP Subtype 551 IANA is requested to create a registry for IANA assigned subtypes in 552 the IETF Organizationally Specific TLV assigned to IANA (OUI of 553 000-00-53 [RFC7042]. Assignment is requested for 1 for the BGP 554 Config OS-TLV. 556 +-------------+-----------------------------------+ 557 | Range | Assignment Policy | 558 +-------------+-----------------------------------+ 559 | 0 | Reserved (not to be assigned) | 560 | | | 561 | 1 | BGP Configuration | 562 | | | 563 | 2-127 | Unassigned (IETF Review) | 564 | | | 565 | 128-254 | Reserved (Not to be assigned now) | 566 | | | 567 | 255 | Reserved (not to be assigned) | 568 +-------------+-----------------------------------+ 570 Figure 2: IANA LLDP IETF Organizationally Specific TLV Sub-Types 572 * Types in the range 2-127 are to be assigned subject to IETF 573 Review. New values are assigned only through RFCs that have been 574 shepherded through the IESG as AD-Sponsored or IETF WG Documents 575 [RFC5226]. 577 * Types in the range 128-254 are reserved and not to be assigned at 578 this time. Before any assignments can be made in this range, 579 there MUST be a Standards Track RFC that specifies IANA 580 Considerations that covers the range being assigned. 582 6.2. BGP Config LLDP OS-TLV Sub-TLVs 584 IANA is requested to create a registry for Sub-TLVs of the BGP Config 585 LLDP OS-TLV. Assignment is requested for 1 for the BGP Peering 586 Address Sub-TLV. Assignment is also requested for 2 for the Local AS 587 Sub-TLV. Additionally, assignment is requested for 3 for the BGP 588 Identifier Sub-TLV, 4 for the BGP Session Group-ID, 5 for the Session 589 Capabilities Sub-TLV, and 6 for the Key Chain Name. 591 +-------------+-----------------------------------+ 592 | Range | Assignment Policy | 593 +-------------+-----------------------------------+ 594 | 0 | Reserved (not to be assigned) | 595 | | | 596 | 1 | Peering Address | 597 | | | 598 | 2 | Local AS | 599 | | | 600 | 3 | BGP Identifier | 601 | | | 602 | 4 | Session Group-ID | 603 | | | 604 | 5 | Session Capabilities | 605 | | | 606 | 6 | Key Chain Name | 607 | | | 608 | 7 | Local Address | 609 | | | 610 | 8 | BGP State Version | 611 | | | 612 | 9-127 | Unassigned (IETF Review) | 613 | | | 614 | 128-254 | Reserved (Not to be assigned now) | 615 | | | 616 | 255 | Reserved (not to be assigned) | 617 +-------------+-----------------------------------+ 619 Figure 3: LLDP BGP Config OS-TLV Types 621 * Types in the range 9-127 are to be assigned subject to IETF 622 Review. New values are assigned only through RFCs that have been 623 shepherded through the IESG as AD-Sponsored or IETF WG Documents 624 [RFC5226]. 626 * Types in the range 128-254 are reserved and not to be assigned at 627 this time. Before any assignments can be made in this range, 628 there MUST be a Standards Track RFC that specifies IANA 629 Considerations that covers the range being assigned. 631 7. Contributors 633 Contributors' Addresses 635 8. References 637 8.1. Normative References 639 [LLDP] IEEE, "IEEE Standard for Local and metropolitan area 640 networks-- Station and Media Access Control Connectivity 641 Discovery Corrigendum 2: Technical and Editorial 642 Corrections", IEEE 802.1AB-2009/Cor 2-2015, 643 DOI 10.1109/ieeestd.2015.7056401, 9 March 2015, 644 . 646 [MACsec] IEEE, "IEEE Standard for Local and metropolitan area 647 networks - Media Access Control (MAC) Security", 648 IEEE Standard 802.1AE-2018, 27 September 2018. 650 [MKA] IEEE, "IEEE Standard for Local and metropolitan area 651 networks - Port Based Network Access Control", 652 IEEE Standard 802.1X-2020, 30 January 2020. 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, 656 DOI 10.17487/RFC2119, March 1997, 657 . 659 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 660 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 661 DOI 10.17487/RFC4271, January 2006, 662 . 664 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 665 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 666 May 2017, . 668 8.2. Informative References 670 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 671 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 672 1998, . 674 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 675 "Multiprotocol Extensions for BGP-4", RFC 4760, 676 DOI 10.17487/RFC4760, January 2007, 677 . 679 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 680 Pignataro, "The Generalized TTL Security Mechanism 681 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 682 . 684 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 685 IANA Considerations Section in RFCs", RFC 5226, 686 DOI 10.17487/RFC5226, May 2008, 687 . 689 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 690 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 691 2009, . 693 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 694 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 695 June 2010, . 697 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 698 IETF Protocol and Documentation Usage for IEEE 802 699 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 700 October 2013, . 702 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 703 BGP for Routing in Large-Scale Data Centers", RFC 7938, 704 DOI 10.17487/RFC7938, August 2016, 705 . 707 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 708 Zhang, "YANG Data Model for Key Chains", RFC 8177, 709 DOI 10.17487/RFC8177, June 2017, 710 . 712 Appendix A. Acknowledgments 714 Thanks to Sujay Gupta and Paul Congdon for review and comments. 716 The RFC text was produced using Marshall Rose's xml2rfc tool. 718 Authors' Addresses 719 Acee Lindem 720 Cisco Systems 721 301 Midenhall Way 722 Cary, NC 27513 723 United States of America 725 Email: acee@cisco.com 727 Keyur Patel 728 Arrcus, Inc 730 Email: keyur@arrcus.com 732 Shawn Zandi 733 LinkedIn 734 222 2nd Street 735 San Francisco, CA 94105 736 United States of America 738 Email: szandi@linkedin.com 740 Jeff Haas 741 Juniper Networks, Inc 742 1133 Innovation, Inc. 743 Sunnyvale, CA 94089 744 United States of America 746 Email: jhaas@juniper.net 748 Xiaohu Xu 749 Capitalonline 751 Email: xiaohu.xu@capitalonline.net