idnits 2.17.1 draft-acee-idr-lldp-peer-discovery-01.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 (July 3, 2017) is 2482 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP' -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-GUIDE') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7042 (ref. 'IEEE-802-IANA') (Obsoleted by RFC 9542) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. 'TCP-MD5') (Obsoleted by RFC 5925) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: January 4, 2018 Arrcus, Inc 6 S. Zandi 7 LinkedIn 8 J. Haas 9 Juniper Networks, Inc 10 X. Xu 11 Huawei 12 July 3, 2017 14 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery 15 draft-acee-idr-lldp-peer-discovery-01.txt 17 Abstract 19 Link Layer Discovery Protocol (LLDP) or IEEE 802.1AB is implemented 20 in networking equipment from many vendors. It is natural for IETF 21 protocols to avail this protocol for simple discovery tasks. This 22 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 http://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 January 4, 2018. 43 Copyright Notice 45 Copyright (c) 2017 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 (http://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 2. LLDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. LLDP 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 . . . . . 5 66 2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV . . . . . . 6 67 2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV . . . . . 7 68 2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV . . . . 8 69 2.2.5. BGP Config OS-TLV - BGP Session Capabilities Sub-TLV 9 70 2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV . . . . . . . . 10 71 3. BGP LLDP Peer Discovery Operations . . . . . . . . . . . . . 11 72 3.1. Advertising BGP Speaker . . . . . . . . . . . . . . . . . 11 73 3.2. Receiving BGP Speaker . . . . . . . . . . . . . . . . . . 11 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 5.1. IANA Assigned LLDP Subtype . . . . . . . . . . . . . . . 13 77 5.2. BGP Config LLDP OS-TLV Sub-TLVs . . . . . . . . . . . . . 13 78 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 7.2. Informative References . . . . . . . . . . . . . . . . . 15 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 Link Layer Discovery Protocol (LLDP) [LLDP] or IEEE 802.1AB is 88 implemented in networking equipment from many vendors. It is natural 89 for IETF protocols to avail this protocol for simple discovery tasks. 90 This document describes how BGP [BGP] would use LLDP to discover 91 directly connected and 2-hop peers when peering is based on loopback 92 addresses. 94 1.1. Requirements Notation 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC-KEYWORDS]. 100 2. LLDP Extensions 102 2.1. LLDP Organizationally Specific TLV Format 104 The format of the LLDP Basic Organizationally Specific TLV (OS-TLV) 105 is defined in [LLDP]. It is shown below for completeness. 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Type (127) | Length | OUI (3 Octets) 00-00-5E | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | OUI Continued | Subtype | Value | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | ... (Up to 507 Octets) | 116 Type Organizationally Specific TLV type value, 127. 118 Length The length of the remainder of the TLV. 120 OUI Organizationally unique identifier for the 121 organization's OUI. For IANA, this is value is 122 00-00-5E as specified in [IEEE-802-IANA]. 124 Subtype IETF specific subtype 126 Value Value for organizationally specific TLV. The Length of 127 the value is 4 octets less than the TLV length. 129 LLDP Organizationally Specific TLV 131 The OUI for IANA was allocated in section 1.4 of [IEEE-802-IANA]. 132 This document requests creation of a registry for IETF specific sub- 133 types for LLDP Organizationally Specific TLVs. 135 2.2. BGP Config OS-TLV Format 137 The BGP Config Organizationally Specific TLV (OS-TLV) will be used to 138 advertise BGP configuration information. The configuration 139 information will be composed of Sub-TLVs. Since the length is 140 limited to 507 octets, multiple BGP Config OS-TLVs could be included 141 in a single LLDP advertisement. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type (127) | Length | OUI (3 Octets) 00-00-5E | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 |OUI Continued | 1 | BGP Config Sub-TLVs ... | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | ... (Up to 507 Octets) | 152 Length The length of the BGP TLV. 154 Subtype IETF specific subtype for BGP Config OS-TLV. The 155 value shall be 1. 157 Value BGP Config Sub-TLVs each with a 1 byte Type and 158 Length. The Length will include solely the value 159 portion of the TLV and not the Type and Length 160 fields themselves. 162 2.2.1. BGP Config OS-TLV - Peering Address Sub-TLV 164 The BGP OS-TLV Peering Address Sub-TLV will be used to advertise the 165 local IP addresses used for BGP sessions and the associated address 166 families specified by AFI/SAFI tuples. The AFI/SAFI tuple, 0/0, 167 indicates to use the associated peering address for all locally 168 configured address families without an explicit peering address 169 specification. As always, the address families supported for a given 170 BGP session will be determined during capabilities negotiation 171 [MP-BGP]. It is RECOMMENDED that the wildcard AFI/SAFI be used in 172 deployments with fairly homogenous address family usage. 174 The format of the BGP Peering Address Sub-TLV is shown below. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type (1) | Length | Address Family| IPv4/IPv6 | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 ~ IPv4/IPv6 Peering Address ... ~ 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | AFI | SAFI | o o o 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Type The Sub-TLV Type value shall be 1. 188 Length The Sub-TLV length in octets will be 4 for IPv4 or 16 189 for IPv6 plus 3 times the number of AFI/SAFI tuples. 191 Address IANA Address family (1 for IPv4 or 2 for IPv6) 192 Family 194 Peering An IPv4 address (4 octets) or an IPv6 address (16 octets) 195 Address 197 AFI/SAFI One or more AFI/SAFI tuples for BGP session using this 198 Pairs peering address. The AFI/SAFI tuple, 0/0, is a wildcard 199 indicating to attempt negotiation for all AFI/SAFIs. 201 2.2.2. BGP Config OS-TLV - BGP Local AS Sub-TLV 203 The BGP Config OS-TLV Local AS Sub-TLV will be used to advertise the 204 4-octet local Autonomous System (AS) number(s). For AS transitions, 205 a second local AS number may be specified. The format of the BGP 206 Local AS Sub-TLV is shown below. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type (2) |Length (4 or 8)| Local AS | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Local AS | Optional Second Local AS | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Optional Second Local AS | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Type The Sub-TLV Type value shall be 2. 220 Length The Sub-TLV Length will be 4 or 8 octets. 222 Local AS Local Autonomous System (AS) 224 Second Local AS Local Autonomous System (AS) 226 2.2.3. BGP Config OS-TLV - BGP Identifier Sub-TLV 228 The BGP Config OS-TLV BGP Identifier Sub-TLV will be used to 229 advertise the 4-octet local BGP Identifier. The BGP Identifier is 230 used for debugging purposes and possibly to reduce the likelihood of 231 BGP connection collisions. The format of the BGP Identifier Sub-TLV 232 is shown below. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type (3) | Length (4) | BGP Identifier | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | BGP Identifier | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Type The Sub-TLV Type value shall be f32. 244 Length The Sub-TLV Length will be 4 octets. 246 BGP Identifier Local BGP Identifier (aka, BGP Router ID) 248 2.2.4. BGP Config OS-TLV - Session Group-ID Sub-TLV 250 The BGP Config OS-TLV Session Group-ID Sub-TLV is an opaque 4-octet 251 value that is used to represent a category of BGP session that is 252 supported on the interface. The format of the Session Group-ID Sub- 253 TLV is shown below. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type (4) | Length (4) | Session Group-ID | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Session Group-ID | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Type The Sub-TLV Type value shall be 4. 265 Length The Sub-TLV Length will be 4 octets. 267 Session Group-ID The session group-id used to indicate a 268 class or category of BGP session supported on 269 the interface. 271 2.2.5. BGP Config OS-TLV - BGP Session Capabilities Sub-TLV 273 The BGP Config OS-TLV Session Capabilities Sub-TLV will be used to 274 advertise an 8-octet Session Capabilities field. The session 275 capabilities are represented as bit flags identifying the supported 276 BGP session capabilities. The format of the BGP Session Capabilities 277 Sub-TLV is shown below. 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type (5) | Length (8) | Session Capabilities | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Session Capabilities | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Session Capabilities | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Type The Sub-TLV Type value shall be 5. 291 Length The Sub-TLV Length will be 8 octets. 293 Session Bit fields identify BGP session capabilities 294 Capabilities 296 The BGP Session Capabilities is an 8-octet bit field. The most 297 significant bit is the first bit (Bit 1) of the Session Capabilities. 298 The following bits are defined: 300 Bit 1: This bit indicates support for TCP MD5 301 authentication [TCP-MD5]. 303 Bit 2: This bit indicates support for TCP-AO 304 authentication [TCP-AO]. 306 Bit 3: This bit indicates support for Generalized TTL 307 Security Mechanism (GTSM) [GTSM] with a 308 configured TTL range of 254-255. 310 TCP MD5 authentication is described in [TCP-MD5]. The TCP 311 Authentication Option (TCP-AO) is described in [TCP-AO]. The 312 Generalized TTL Security Mechanism (GTSM) is described in [GTSM]. If 313 both TCP MD5 authentication and TCP-AO authentication are specified 314 and TCP-AO is supported, it will take precedence. 316 2.2.6. BGP Config OS-TLV - Key Chain Sub-TLV 318 The BGP Config OS-TLV Key Chain Sub-TLV is a string specifying the 319 name for the key chain used for session authentication. Key chains 320 [YANG-KEY-CHAIN] are a commonly used for protocol authentication and 321 encryption key specification. Given the limited length of all BGP 322 configuration information, the key chain name will be limited to 64 323 characters and will not include a trailing string delimiter. The 324 format of the Session Group-ID Sub-TLV is shown below. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type (6) |Length (1 - 64)| Key Chain Name | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Key Chain Name (Up to 64 Octets) | 332 O 333 O 334 O 335 | Key Chain Name | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Type The Sub-TLV Type value shall be 6. 340 Length The Sub-TLV Length will be 1 - 64 octets. 342 Key Chain Name The name of a key chain to be used for 343 MD5 or TCP-AO authentication. 345 3. BGP LLDP Peer Discovery Operations 347 The simple use case is to just use the peer address advertised in the 348 LLDP Packet Data Unit (PDU) to establish a 1-hop BGP peer session. 349 This can be used in data centers using BGP as described in [BGP-DC]. 350 The use case where a loopback address or other local address is 351 advertised as the peering address is also supported. However, 352 reachabiliy to a peering address other than the interface address is 353 beyond the scope of this document. 355 3.1. Advertising BGP Speaker 357 A BGP speaker MAY advertise its BGP peering address in an LLDP PDU 358 for a link using the BGP Local Address Sub-TLV of the BGP-OS TLV. 359 This can be an IPv4 or IPv6 local address associated with the LLDP 360 link for 1-hop peering. For 2-hop peering, it could be a loopback 361 address or any other address that is local to the node but not the 362 LLDP link. As noted above, reachability to the loopback address is 363 beyond the scope of this document. 365 A BGP speaker MAY advertise its local AS number using the BGP Local 366 AS Sub-TLV of the BGP-OS TLV. During AS transitions, a second local 367 AS number may be included in the Local AS Sub-TLV. The local BGP 368 identifier may also be advertised using the BGP Identifier Sub-TLV of 369 the BGP-OS TLV. While not specifically required for session 370 establishment, the values may be used for validation, trouble- 371 shooting, and connection collision avoidance. A BGP speaker may also 372 announce a Session Group-ID indicating the class or category of 373 session(s) supported and/or mapping to a set of session parameters. 374 Additionally, a BGP speaker MAY also announce relevant capabilities 375 using BGP Session Capabilities Sub-TLV of the BGP-OS TLV. 377 If TCP MD5 authentication [TCP-MD5] or TCP Authentication Option 378 (TCP-AO) [TCP-AO] is to be used on the session, the Key Chain Sub-TLV 379 of the BGP-OS TLV MAY be used to specify the key chain name. 381 3.2. Receiving BGP Speaker 383 A BGP speaker configured for LLDP peer discovery WILL attempt to 384 establish BGP sessions using the address in the BGP Local Address 385 Sub-TLV of BGP-OS TLV format. If the peering address is directly 386 accessible over the link on which the LLDP PDU is received, the BGP 387 speaker will attempt to establish a 1-hop BGP session with the peer. 389 If the received BGP Peering Address is not directly accessible over 390 the link, the peer must be reachable for the session to be 391 established and the mechanisms for establishing reachability are 392 beyond the scope of this specification. If the BGP speaker receives 393 the same BGP peering address in LLDP PDUs received on multiple links, 394 it will not establish multiple sessions. Rather, a single 2-hop 395 session will be established. 397 When the deployment of address families is fairly homogenous across 398 the deployment, the wildcard AFI/SAFI can be utilized to simplify 399 LLDP advertisement. When there is variance in the address families 400 supported, usage of the wildcard could result in session 401 establishment delay due to capabilities negotiation [BGP-CAP]. 403 A BGP speaker MAY receive a remote neighbor's local AS number(s) in 404 an LLDP PDU in the BGP Local AS Sub-TLV of the BGP-OS TLV. A BGP 405 speaker MAY use the received local AS number(s) to perform validation 406 checking of the AS received in the OPEN message. A BGP speaker MAY 407 receive a remote neighbor's BGP Identifier in the BGP Identifier Sub- 408 TLV of the BGP-OS TLV. This can be used to avoid connection 409 collisions by delaying session establishment if the remote BGP 410 Identifier is greater than the receiving speaker's BGP Identifier. 412 A BGP speaker MAY receive a Session Group-ID Sub-TLV in the LLDP BGP- 413 OS TLV. This Session Group-ID may be used for validation and/or 414 mapping the session to a particular set of session parameters. For 415 example, the Session Group-ID could be mapped to a spine, leaf, or 416 Top-of-Rack (ToR) session in a data center deployment and can be used 417 to detect cabling problems when an unexpected Session Group-ID is 418 received. 420 Additionally, A BGP speaker MAY receive a remote neighbor's 421 capabilities in LLDP in the BGP Session Capabilities Sub-TLV of the 422 BGP-OS TLV. A BGP speaker MAY use the received capabilities to 423 ensure appropriate local neighbor configuration in order to 424 facilitate session establishment. 426 If TCP MD5 authentication [TCP-MD5]. or TCP Authentication Option 427 (TCP-AO) [TCP-AO] is to be used on the session as determined either 428 via the Session Capabilities Sub-TLV, Session Group-ID, or local 429 policy, the key chain name in the Key Chain Sub-TLV of the BGP-OS TLV 430 MAY be used to identify the correct key chain [YANG-KEY-CHAIN]. 432 4. Security Considerations 434 This security considerations for BGP [BGP] apply equally to this 435 extension. 437 Additionally, BGP peering address discovery should only be done on 438 trusted links (e.g., in a data center network) since LLDP packets are 439 not authenticated or encrypted [LLDP]. 441 5. IANA Considerations 443 5.1. IANA Assigned LLDP Subtype 445 IANA is requested to create a registry for IANA assigned subtypes in 446 the Organizationally Specific TLV assigned to IANA (OUI of 000-00-53 447 [IEEE-802-IANA]. Assignment is requested for 1 for the BGP Config 448 OS-TLV. 450 +-------------+-----------------------------------+ 451 | Range | Assignment Policy | 452 +-------------+-----------------------------------+ 453 | 0 | Reserved (not to be assigned) | 454 | | | 455 | 1 | BGP Configuration | 456 | | | 457 | 2-127 | Unassigned (IETF Review) | 458 | | | 459 | 128-254 | Reserved (Not to be assigned now) | 460 | | | 461 | 255 | Reserved (not to be assigned) | 462 +-------------+-----------------------------------+ 464 IANA LLDP Organizationally Specific TLV Sub-Types 466 o Types in the range 2-127 are to be assigned subject to IETF 467 Review. New values are assigned only through RFCs that have been 468 shepherded through the IESG as AD-Sponsored or IETF WG Documents 469 [IANA-GUIDE]. 471 o Types in the range 128-254 are reserved and not to be assigned at 472 this time. Before any assignments can be made in this range, 473 there MUST be a Standards Track RFC that specifies IANA 474 Considerations that covers the range being assigned. 476 5.2. BGP Config LLDP OS-TLV Sub-TLVs 478 IANA is requested to create a registry for Sub-TLVs of the BGP Config 479 LLDP OS-TLV. Assignment is requested for 1 for the BGP Peering 480 Address Sub-TLV. Assignment is also requested for 2 for the Local AS 481 Sub-TLV. Additionally, assignment is requested for 3 for the BGP 482 Identifier Sub-TLV, 4 for the BGP Session Group-ID, 5 for the Session 483 Capabilities Sub-TLV, and 6 for the Key Chain Name. 485 +-------------+-----------------------------------+ 486 | Range | Assignment Policy | 487 +-------------+-----------------------------------+ 488 | 0 | Reserved (not to be assigned) | 489 | | | 490 | 1 | Peering Address | 491 | | | 492 | 2 | Local AS | 493 | | | 494 | 3 | BGP Identifier | 495 | | | 496 | 4 | Session Group-ID | 497 | | | 498 | 5 | Session Capabilities | 499 | | | 500 | 6 | Key Chain Name | 501 | | | 502 | 7-127 | Unassigned (IETF Review) | 503 | | | 504 | 128-254 | Reserved (Not to be assigned now) | 505 | | | 506 | 255 | Reserved (not to be assigned) | 507 +-------------+-----------------------------------+ 509 LLDP BGP Config OS-TLV Types 511 o Types in the range 7-127 are to be assigned subject to IETF 512 Review. New values are assigned only through RFCs that have been 513 shepherded through the IESG as AD-Sponsored or IETF WG Documents 514 [IANA-GUIDE]. 516 o Types in the range 128-254 are reserved and not to be assigned at 517 this time. Before any assignments can be made in this range, 518 there MUST be a Standards Track RFC that specifies IANA 519 Considerations that covers the range being assigned. 521 6. Contributors 523 Contributors' Addresses 525 7. References 527 7.1. Normative References 529 [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 530 Protocol 4 (BGP-4)", RFC 4271, January 2006. 532 [LLDP] IEEE, "IEEE Standard for Local and metropolitan area 533 networks-- Station and Media Access Control Connectivity 534 Discovery Corrigendum 2: Technical and Editorial 535 Corrections", IEEE 802.1AB-2009/Cor 2-2015, 536 DOI 10.1109/ieeestd.2015.7056401, March 2015. 538 [RFC-KEYWORDS] 539 Bradner, S., "Key words for use in RFC's to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 7.2. Informative References 544 [BGP-CAP] Scudder, J. and R. Chandra, "Capabilities Advertisement 545 with BGP-4", RFC 5492, February 2009. 547 [BGP-DC] Lapukhov, P., Premji, A., and J. Mitchell, "BGP Routing in 548 Data Centers", RFC 7938, August 2016. 550 [GTSM] Gill, V., Heasley, J., Savola, P., and C. Pignataro, "The 551 Generalized TTL Security Mechanism", RFC 5082, October 552 2007. 554 [IANA-GUIDE] 555 Narten, T. and H. Alvestrand, "Guidelines for Writing an 556 IANA Considerations Section in RFCs", RFC 5226, May 2008. 558 [IEEE-802-IANA] 559 Eastlake, D. and J. Abley, "IANA Considerations and IETF 560 Protocol and Documentation Usage for IEEE 802 Parameters", 561 RFC 7042, October 2013. 563 [MP-BGP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 564 "Multiprotocol Extensions for BGP-4", RFC 4760, January 565 2007. 567 [TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP 568 Authentication Option", RFC 5925, June 2010. 570 [TCP-MD5] Heffernan, A., "TCP MD5 Signature Option", RFC 2385, 571 August 1998. 573 [YANG-KEY-CHAIN] 574 Lindem, A., Qu, Y., Yeung, D., Chen, I., and J. Zhang, 575 "YANG Data Model for Key Chains", RFC 8177, June 2017. 577 Appendix A. Acknowledgments 579 The RFC text was produced using Marshall Rose's xml2rfc tool. 581 Authors' Addresses 583 Acee Lindem 584 Cisco Systems 585 301 Midenhall Way 586 Cary, NC 27513 587 USA 589 Email: acee@cisco.com 591 Keyur Patel 592 Arrcus, Inc 594 Email: keyur@arrcus.com 596 Shawn Zandi 597 LinkedIn 598 222 2nd Street 599 San Francisco, CA 94105 600 USA 602 Email: szandi@linkedin.com 604 Jeff Haas 605 Juniper Networks, Inc 606 1133 Innovation, Inc. 607 Sunnyvale, CA 94089 608 USA 610 Email: jhaas@juniper.net 612 Xiaohu Xu 613 Huawei 615 Email: xuxiaohu@huawei.com