idnits 2.17.1 draft-acee-idr-lldp-peer-discovery-06.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 (November 21, 2019) is 1612 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 128, but not defined == Missing Reference: 'TCP-MD5' is mentioned on line 307, but not defined == Missing Reference: 'TCP-AO' is mentioned on line 310, but not defined == Missing Reference: 'GTSM' is mentioned on line 313, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP' -- 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 (==), 5 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: May 24, 2020 Arrcus, Inc 6 S. Zandi 7 LinkedIn 8 J. Haas 9 Juniper Networks, Inc 10 X. Xu 11 Alibaba 12 November 21, 2019 14 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery 15 draft-acee-idr-lldp-peer-discovery-06 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 May 24, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 12 74 3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 12 75 3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 12 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 5.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 14 79 5.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 14 80 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 7.2. Informative References . . . . . . . . . . . . . . . . . 16 84 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 Link Layer Discovery Protocol (LLDP) [LLDP] or IEEE Std 802.1AB is 90 implemented in networking equipment from many vendors. It is natural 91 for IETF protocols to avail this protocol for simple discovery tasks. 92 This document describes how BGP [RFC4271] would use LLDP to discover 93 directly connected and 2-hop peers when peering is based on loopback 94 addresses. 96 1.1. Requirements Notation 98 1.1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2. LLDP Extensions 108 2.1. LLDP IETF Organizationally Specific TLV Format 110 The format of the LLDP IETF Organizationally Specific TLV (OS-TLV) is 111 defined in [LLDP]. It is shown below for completeness. 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Type (127) | Length | OUI (3 Octets) 00-00-5E | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | OUI Continued | Subtype | Value | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | ... (Up to 507 Octets) | 122 Type IETF Organizationally Specific TLV type value, 127. 124 Length The length of the remainder of the TLV. 126 OUI IETF Organizationally unique identifier for the 127 organization's OUI. For IANA, this is value is 128 00-00-5E as specified in [IEEE-802-IANA]. 130 Subtype IETF specific subtype 132 Value Value for organizationally specific TLV. The Length of 133 the value is 4 octets less than the TLV length. 135 LLDP IETF Organizationally Specific TLV 137 The OUI for IANA was allocated in section 1.4 of [RFC7042]. This 138 document requests creation of a registry for IETF specific sub-types 139 for LLDP IETF Organizationally Specific TLVs. 141 2.2. BGP Config OS-TLV Format 143 The BGP Config IETF Organizationally Specific TLV (OS-TLV) will be 144 used to advertise BGP configuration information. The configuration 145 information will be composed of Sub-TLVs. Since the length is 146 limited to 507 octets, multiple BGP Config OS-TLVs could be included 147 in a single LLDP advertisement. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type (127) | Length | OUI (3 Octets) 00-5E-00 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 |OUI Continued | 1 | BGP Config Sub-TLVs ... | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | ... (Up to 507 Octets) | 158 Length The length of the BGP TLV. 160 Subtype IETF specific subtype for BGP Config OS-TLV. The 161 value shall be 1. 163 Value BGP Config Sub-TLVs each with a 1 byte Type and 164 Length. The Length will include solely the value 165 portion of the TLV and not the Type and Length 166 fields themselves. 168 2.2.1. BGP Config OS-TLV - Peering Address Sub-TLV 170 The BGP OS-TLV Peering Address Sub-TLV will be used to advertise the 171 local IP addresses used for BGP sessions and the associated address 172 families specified by AFI/SAFI tuples. The AFI/SAFI tuple, 0/0, 173 indicates to use the associated peering address for all locally 174 configured address families without an explicit peering address 175 specification. As always, the address families supported for a given 176 BGP session will be determined during capabilities negotiation 177 [RFC4760]. It is RECOMMENDED that the wildcard AFI/SAFI be used in 178 deployments with fairly homogenous address family usage. 180 The format of the BGP Peering Address Sub-TLV is shown below. 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type (1) | Length | Address Family| IPv4/IPv6 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 ~ IPv4/IPv6 Peering Address ... ~ 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | AFI | SAFI | o o o 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Type The Sub-TLV Type value shall be 1. 194 Length The Sub-TLV length in octets will be 4 for IPv4 or 16 195 for IPv6 plus 3 times the number of AFI/SAFI tuples. 197 Address IANA Address family (1 for IPv4 or 2 for IPv6) 198 Family 200 Peering An IPv4 address (4 octets) or an IPv6 address (16 octets) 201 Address 203 AFI/SAFI One or more AFI/SAFI tuples for BGP session using this 204 Pairs peering address. The AFI/SAFI tuple, 0/0, is a wildcard 205 indicating to attempt negotiation for all AFI/SAFIs. 207 2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV 209 The BGP Config OS-TLV Local AS Sub-TLV will be used to advertise the 210 4-octet local Autonomous System (AS) number(s). For AS transitions, 211 a second local AS number may be specified. The format of the BGP 212 Local AS Sub-TLV is shown below. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type (2) |Length (4 or 8)| Local AS | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Local AS | Optional Second Local AS | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Optional Second Local AS | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Type The Sub-TLV Type value shall be 2. 226 Length The Sub-TLV Length will be 4 or 8 octets. 228 Local AS Local Autonomous System (AS) 230 Second Local AS Local Autonomous System (AS) 232 2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV 234 The BGP Config OS-TLV BGP Identifier Sub-TLV will be used to 235 advertise the 4-octet local BGP Identifier. The BGP Identifier is 236 used for debugging purposes and possibly to reduce the likelihood of 237 BGP connection collisions. The format of the BGP Identifier Sub-TLV 238 is shown below. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type (3) | Length (4) | BGP Identifier | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | BGP Identifier | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Type The Sub-TLV Type value shall be 3. 250 Length The Sub-TLV Length will be 4 octets. 252 BGP Identifier Local BGP Identifier (aka, BGP Router ID) 254 2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV 256 The BGP Config OS-TLV Session Group-ID Sub-TLV is an opaque 4-octet 257 value that is used to represent a category of BGP session that is 258 supported on the interface. The format of the Session Group-ID Sub- 259 TLV is shown below. 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type (4) | Length (4) | Session Group-ID | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Session Group-ID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Type The Sub-TLV Type value shall be 4. 271 Length The Sub-TLV Length will be 4 octets. 273 Session Group-ID The session group-id used to indicate a 274 class or category of BGP session supported on 275 the interface. 277 2.2.5. BGP Config OS-TLV - BGP Session Capabilities Sub-TLV 279 The BGP Config OS-TLV Session Capabilities Sub-TLV will be used to 280 advertise an 8-octet Session Capabilities field. The session 281 capabilities are represented as bit flags identifying the supported 282 BGP session capabilities. The format of the BGP Session Capabilities 283 Sub-TLV is shown below. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Type (5) | Length (8) | Session Capabilities | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Session Capabilities | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Session Capabilities | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Type The Sub-TLV Type value shall be 5. 297 Length The Sub-TLV Length will be 8 octets. 299 Session Bit fields identify BGP session capabilities 300 Capabilities 302 The BGP Session Capabilities is an 8-octet bit field. The most 303 significant bit is the first bit (Bit 1) of the Session Capabilities. 304 The following bits are defined: 306 Bit 1: This bit indicates support for TCP MD5 307 authentication [TCP-MD5]. 309 Bit 2: This bit indicates support for TCP-AO 310 authentication [TCP-AO]. 312 Bit 3: This bit indicates support for Generalized TTL 313 Security Mechanism (GTSM) [GTSM] with a 314 configured TTL range of 254-255. 316 TCP MD5 authentication is described in [RFC2385]. The TCP 317 Authentication Option (TCP-AO) is described in [RFC5925]. The 318 Generalized TTL Security Mechanism (GTSM) is described in [RFC5082]. 319 If both TCP MD5 authentication and TCP-AO authentication are 320 specified and TCP-AO is supported, it will take precedence. 322 2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV 324 The BGP Config OS-TLV Key Chain Sub-TLV is a string specifying the 325 name for the key chain used for session authentication. Key chains 326 [RFC8177] are a commonly used for protocol authentication and 327 encryption key specification. Given the limited length of all BGP 328 configuration information, the key chain name will be limited to 64 329 characters and will not include a trailing string delimiter. The 330 format of the Session Group-ID Sub-TLV is shown below. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type (6) |Length (1 - 64)| Key Chain Name | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Key Chain Name (Up to 64 Octets) | 338 O 339 O 340 O 341 | Key Chain Name | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Type The Sub-TLV Type value shall be 6. 346 Length The Sub-TLV Length will be 1 - 64 octets. 348 Key Chain Name The name of a key chain to be used for 349 MD5 or TCP-AO authentication. 351 2.2.7. BGP Config OS-TLV - Local Address Sub-TLV 353 The BGP OS-TLV Local Address Sub-TLV will be used to advertise a 354 local IP addresses used for BGP next-hops. Advertising a local 355 interface address is useful when the address family is different from 356 the advertised BGP peering address. 358 The format of the BGP Local Interface Address Sub-TLV is shown below. 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type (7) | Length | Address Family| IPv4/IPv6 | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 ~ IPv4/IPv6 Local Address ... ~ 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Type The Sub-TLV Type value shall be 7. 370 Length The Sub-TLV length in octets will be 4 for IPv4 or 16 371 for IPv6 plus 3 times the number of AFI/SAFI tuples. 373 Address IANA Address family (1 for IPv4 or 2 for IPv6) 374 Family 376 Local An IPv4 address (4 octets) or an IPv6 address (16 octets) 377 Address 379 3. BGP LLDP Peer Discovery Operations 381 The simple use case is to just use the peer address advertised in the 382 LLDP Packet Data Unit (PDU) to establish a 1-hop BGP peer session. 383 This can be used in data centers using BGP as described in [RFC7938]. 384 The use case where a loopback address or other local address is 385 advertised as the peering address is also supported. However, 386 reachabiliy to a peering address other than the interface address is 387 beyond the scope of this document. 389 3.1. Advertising BGP Speaker 391 A BGP speaker MAY advertise its BGP peering address in an LLDP PDU 392 for a link using the BGP Local Address Sub-TLV of the BGP-OS TLV. 393 This can be an IPv4 or IPv6 local address associated with the LLDP 394 link for 1-hop peering. For 2-hop peering, it could be a loopback 395 address or any other address that is local to the node but not the 396 LLDP link. As noted above, reachability to the loopback address is 397 beyond the scope of this document. 399 A BGP speaker MAY advertise its local AS number using the BGP Local 400 AS Sub-TLV of the BGP-OS TLV. During AS transitions, a second local 401 AS number may be included in the Local AS Sub-TLV. The local BGP 402 identifier may also be advertised using the BGP Identifier Sub-TLV of 403 the BGP-OS TLV. While not specifically required for session 404 establishment, the values may be used for validation, trouble- 405 shooting, and connection collision avoidance. A BGP speaker may also 406 announce a Session Group-ID indicating the class or category of 407 session(s) supported and/or mapping to a set of session parameters. 408 Additionally, a BGP speaker MAY also announce relevant capabilities 409 using BGP Session Capabilities Sub-TLV of the BGP-OS TLV. 411 If TCP MD5 authentication [RFC2385] or TCP Authentication Option 412 (TCP-AO) [RFC5925] is to be used on the session, the Key Chain Sub- 413 TLV of the BGP-OS TLV MAY be used to specify the key chain name. 415 3.2. Receiving BGP Speaker 417 A BGP speaker configured for LLDP peer discovery WILL attempt to 418 establish BGP sessions using the address in the BGP Local Address 419 Sub-TLV of BGP-OS TLV format. If the peering address is directly 420 accessible over the link on which the LLDP PDU is received, the BGP 421 speaker will attempt to establish a 1-hop BGP session with the peer. 423 If the received BGP Peering Address is not directly accessible over 424 the link, the peer must be reachable for the session to be 425 established and the mechanisms for establishing reachability are 426 beyond the scope of this specification. If the BGP speaker receives 427 the same BGP peering address in LLDP PDUs received on multiple links, 428 it will not establish multiple sessions. Rather, a single 2-hop 429 session will be established. 431 When the deployment of address families is fairly homogenous across 432 the deployment, the wildcard AFI/SAFI can be utilized to simplify 433 LLDP advertisement. When there is variance in the address families 434 supported, usage of the wildcard could result in session 435 establishment delay due to capabilities negotiation [RFC5492]. 437 A BGP speaker MAY receive a remote neighbor's local AS number(s) in 438 an LLDP PDU in the BGP Local AS Sub-TLV of the BGP-OS TLV. A BGP 439 speaker MAY use the received local AS number(s) to perform validation 440 checking of the AS received in the OPEN message. A BGP speaker MAY 441 receive a remote neighbor's BGP Identifier in the BGP Identifier Sub- 442 TLV of the BGP-OS TLV. This can be used to avoid connection 443 collisions by delaying session establishment if the remote BGP 444 Identifier is greater than the receiving speaker's BGP Identifier. 446 A BGP speaker MAY receive a Session Group-ID Sub-TLV in the LLDP BGP- 447 OS TLV. This Session Group-ID may be used for validation and/or 448 mapping the session to a particular set of session parameters. For 449 example, the Session Group-ID could be mapped to a spine, leaf, or 450 Top-of-Rack (ToR) session in a data center deployment and can be used 451 to detect cabling problems when an unexpected Session Group-ID is 452 received. 454 Additionally, A BGP speaker MAY receive a remote neighbor's 455 capabilities in LLDP in the BGP Session Capabilities Sub-TLV of the 456 BGP-OS TLV. A BGP speaker MAY use the received capabilities to 457 ensure appropriate local neighbor configuration in order to 458 facilitate session establishment. 460 If TCP MD5 authentication [RFC2385]. or TCP Authentication Option 461 (TCP-AO) [RFC5925] is to be used on the session as determined either 462 via the Session Capabilities Sub-TLV, Session Group-ID, or local 463 policy, the key chain name in the Key Chain Sub-TLV of the BGP-OS TLV 464 MAY be used to identify the correct key chain [RFC8177]. 466 4. Security Considerations 468 This security considerations for BGP [RFC4271] apply equally to this 469 extension. 471 Additionally, BGP peering address discovery should only be done on 472 trusted links (e.g., in a data center network) since LLDP packets are 473 not authenticated or encrypted [LLDP]. 475 5. IANA Considerations 477 5.1. IANA Assigned LLDP Subtype 479 IANA is requested to create a registry for IANA assigned subtypes in 480 the IETF Organizationally Specific TLV assigned to IANA (OUI of 481 000-00-53 [RFC7042]. Assignment is requested for 1 for the BGP 482 Config OS-TLV. 484 +-------------+-----------------------------------+ 485 | Range | Assignment Policy | 486 +-------------+-----------------------------------+ 487 | 0 | Reserved (not to be assigned) | 488 | | | 489 | 1 | BGP Configuration | 490 | | | 491 | 2-127 | Unassigned (IETF Review) | 492 | | | 493 | 128-254 | Reserved (Not to be assigned now) | 494 | | | 495 | 255 | Reserved (not to be assigned) | 496 +-------------+-----------------------------------+ 498 IANA LLDP IETF Organizationally Specific TLV Sub-Types 500 o Types in the range 2-127 are to be assigned subject to IETF 501 Review. New values are assigned only through RFCs that have been 502 shepherded through the IESG as AD-Sponsored or IETF WG Documents 503 [RFC5226]. 505 o Types in the range 128-254 are reserved and not to be assigned at 506 this time. Before any assignments can be made in this range, 507 there MUST be a Standards Track RFC that specifies IANA 508 Considerations that covers the range being assigned. 510 5.2. BGP Config LLDP OS-TLV Sub-TLVs 512 IANA is requested to create a registry for Sub-TLVs of the BGP Config 513 LLDP OS-TLV. Assignment is requested for 1 for the BGP Peering 514 Address Sub-TLV. Assignment is also requested for 2 for the Local AS 515 Sub-TLV. Additionally, assignment is requested for 3 for the BGP 516 Identifier Sub-TLV, 4 for the BGP Session Group-ID, 5 for the Session 517 Capabilities Sub-TLV, and 6 for the Key Chain Name. 519 +-------------+-----------------------------------+ 520 | Range | Assignment Policy | 521 +-------------+-----------------------------------+ 522 | 0 | Reserved (not to be assigned) | 523 | | | 524 | 1 | Peering Address | 525 | | | 526 | 2 | Local AS | 527 | | | 528 | 3 | BGP Identifier | 529 | | | 530 | 4 | Session Group-ID | 531 | | | 532 | 5 | Session Capabilities | 533 | | | 534 | 6 | Key Chain Name | 535 | | | 536 | 7 | Local Address | 537 | | | 538 | 8-127 | Unassigned (IETF Review) | 539 | | | 540 | 128-254 | Reserved (Not to be assigned now) | 541 | | | 542 | 255 | Reserved (not to be assigned) | 543 +-------------+-----------------------------------+ 545 LLDP BGP Config OS-TLV Types 547 o Types in the range 8-127 are to be assigned subject to IETF 548 Review. New values are assigned only through RFCs that have been 549 shepherded through the IESG as AD-Sponsored or IETF WG Documents 550 [RFC5226]. 552 o Types in the range 128-254 are reserved and not to be assigned at 553 this time. Before any assignments can be made in this range, 554 there MUST be a Standards Track RFC that specifies IANA 555 Considerations that covers the range being assigned. 557 6. Contributors 559 Contributors' Addresses 561 7. References 562 7.1. Normative References 564 [LLDP] IEEE, "IEEE Standard for Local and metropolitan area 565 networks-- Station and Media Access Control Connectivity 566 Discovery Corrigendum 2: Technical and Editorial 567 Corrections", IEEE 802.1AB-2009/Cor 2-2015, 568 DOI 10.1109/ieeestd.2015.7056401, March 2015. 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, 572 DOI 10.17487/RFC2119, March 1997, 573 . 575 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 576 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 577 DOI 10.17487/RFC4271, January 2006, 578 . 580 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 581 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 582 May 2017, . 584 7.2. Informative References 586 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 587 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 588 1998, . 590 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 591 "Multiprotocol Extensions for BGP-4", RFC 4760, 592 DOI 10.17487/RFC4760, January 2007, 593 . 595 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 596 Pignataro, "The Generalized TTL Security Mechanism 597 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 598 . 600 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 601 IANA Considerations Section in RFCs", RFC 5226, 602 DOI 10.17487/RFC5226, May 2008, 603 . 605 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 606 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 607 2009, . 609 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 610 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 611 June 2010, . 613 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 614 IETF Protocol and Documentation Usage for IEEE 802 615 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 616 October 2013, . 618 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 619 BGP for Routing in Large-Scale Data Centers", RFC 7938, 620 DOI 10.17487/RFC7938, August 2016, 621 . 623 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 624 Zhang, "YANG Data Model for Key Chains", RFC 8177, 625 DOI 10.17487/RFC8177, June 2017, 626 . 628 Appendix A. Acknowledgments 630 Thanks to Sujay Gupta and Paul Congdon for review and comments. 632 The RFC text was produced using Marshall Rose's xml2rfc tool. 634 Authors' Addresses 636 Acee Lindem 637 Cisco Systems 638 301 Midenhall Way 639 Cary, NC 27513 640 USA 642 Email: acee@cisco.com 644 Keyur Patel 645 Arrcus, Inc 647 Email: keyur@arrcus.com 648 Shawn Zandi 649 LinkedIn 650 222 2nd Street 651 San Francisco, CA 94105 652 USA 654 Email: szandi@linkedin.com 656 Jeff Haas 657 Juniper Networks, Inc 658 1133 Innovation, Inc. 659 Sunnyvale, CA 94089 660 USA 662 Email: jhaas@juniper.net 664 Xiaohu Xu 665 Alibaba 667 Email: xiaohu.xxh@alibaba-inc.com