idnits 2.17.1 draft-xu-idr-neighbor-autodiscovery-09.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2018) is 2104 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) == Outdated reference: A later version (-29) exists of draft-ietf-lsvr-bgp-spf-01 == Outdated reference: A later version (-05) exists of draft-ketant-idr-bgp-ls-bgp-only-fabric-00 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Alibaba Inc 4 Intended status: Standards Track K. Talaulikar 5 Expires: January 17, 2019 Cisco Systems 6 K. Bi 7 Huawei 8 J. Tantsura 9 Nuage Networks 10 N. Triantafillis 11 July 16, 2018 13 BGP Neighbor Auto-Discovery 14 draft-xu-idr-neighbor-autodiscovery-09 16 Abstract 18 BGP is being used as the underlay routing protocol in some large- 19 scaled data centers (DCs). Most popular design followed is to do 20 hop-by-hop external BGP (eBGP) session configurations between 21 neighboring routers on a per link basis. The provisioning of BGP 22 neighbors in routers across such a DC brings its own operational 23 complexity. 25 This document introduces a BGP neighbor discovery mechanism that 26 greatly simplifies BGP operations in such DC and other networks by 27 automatic setup of BGP sessions between neighbor routers using this 28 mechanism. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 17, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. UDP Message Header . . . . . . . . . . . . . . . . . . . . . 5 74 5. Hello Message Format . . . . . . . . . . . . . . . . . . . . 6 75 6. Hello Message TLVs . . . . . . . . . . . . . . . . . . . . . 8 76 6.1. Accepted ASN List TLV . . . . . . . . . . . . . . . . . . 8 77 6.2. Peering Address TLV . . . . . . . . . . . . . . . . . . . 9 78 6.3. Local Prefix TLV . . . . . . . . . . . . . . . . . . . . 10 79 6.4. Link Attributes TLV . . . . . . . . . . . . . . . . . . . 12 80 6.5. Neighbor TLV . . . . . . . . . . . . . . . . . . . . . . 14 81 6.6. Cryptographic Authentication TLV . . . . . . . . . . . . 15 82 7. Neighbor Discovery Procedure . . . . . . . . . . . . . . . . 17 83 7.1. Interface State . . . . . . . . . . . . . . . . . . . . . 17 84 7.2. Adjacency State Machine . . . . . . . . . . . . . . . . . 18 85 7.3. Peering Route . . . . . . . . . . . . . . . . . . . . . . 19 86 8. Interactions with Base BGP Protocol . . . . . . . . . . . . . 20 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 10. Manageability Considerations . . . . . . . . . . . . . . . . 22 89 10.1. Operational Considerations . . . . . . . . . . . . . . . 22 90 10.2. Management Considerations . . . . . . . . . . . . . . . 23 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 92 11.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . 24 93 11.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . 24 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 95 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 25 98 14.2. Informative References . . . . . . . . . . . . . . . . . 26 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 BGP is being used as the underlay routing protocol instead of link- 104 state routing protocols like IS-IS and OSPF in some large-scale data 105 centers (DCs). [RFC7938] describes the design, configuration and 106 operational aspects of using BGP in such networks. The most popular 107 design scheme involves the setup of external BGP (eBGP) sessions over 108 individual links between directly connected routers using their 109 interface addresses. Such BGP neighbor provisioning requires 110 provisioning of the neighbor IP address and Autonomous System (AS) 111 Number (ASN) for each and every BGP neighbor on every link address. 112 As a DC fabric comprising of topology described in [RFC7938] grows 113 with addition of new leafs, spines and links between them, the BGP 114 provisioning needs to be carefully setup. Unlike with the link-state 115 protocols, there is no automatic discovery of neighbors simply by 116 adding links and nodes in the fabric and route exchange over them 117 getting enabled seamlessly in the case of BGP. 119 In some DC designs with BGP, multiple links are added between a leaf 120 and spine to add additional bandwidth. Use of link-aggregation at 121 Layer 2 level may not be desirable in such cases due to the risk of 122 flow polarization on account of a mix of ECMP at Layer 2 and Layer 3 123 levels. In such cases, one option is for a eBGP sessions to be setup 124 between two BGP neighbors over each of the links between them. In 125 such a case, the BGP session scale and the resultant increase in 126 update processing may pose scalability challenges. A second option 127 is for a single eBGP session to be setup between the loopback IP 128 addresses between the neighbor and then configure some static routes 129 for it pointing over the underlying links as ECMP. In this option 130 there is an additional provisioning task introduced in the form of 131 static routing. 133 Furthermore, there is also a need for BGP to be able to describe its 134 links and its neighbors on its directly connected links and export 135 this information via BGP-LS [RFC7752] to provide a detail link-level 136 topology view using a standards based mechanism of a data center 137 running only BGP. The ability of BGP in discovering its neighbors 138 over its links, monitoring their liveliness and learning the link 139 attributes (such as addresses) is required for the conveying the 140 link-state topology in a BGP network. This information can be 141 leveraged by the BGP-SPF proposal [I-D.ietf-lsvr-bgp-spf] which 142 introduces link-state routing capabilities in BGP. This information 143 can also be leveraged to convey the link-state topology in a network 144 running traditional BGP routing using BGP-LS as described in 145 [I-D.ketant-idr-bgp-ls-bgp-only-fabric] and to enabled end to end 146 traffic engineering use-cases spanning across DCs and the core/access 147 networks. 149 2. Terminology 151 This memo makes use of the terms defined in [RFC4271] and [RFC7938] . 153 3. Overview 155 At a high level, this specification introduces the use of UDP based 156 BGP Hello messages to be exchanged between directly connected BGP 157 routers for neighbor discovery. 159 1. Information is exchanged between BGP routers on a per link basis 160 leading to discovery of each others peering address and other 161 information. 163 2. The TCP session establishment for the BGP protocol operation and 164 the BGP routing exchange over these sessions can then follow 165 without any change/modification from the existing BGP protocol 166 operations as specified in [RFC4271]. 168 3. As part of the neighbor information exchange the route to a 169 neighbor's peering address is also automatically setup pointing 170 over the links over which the neighbor is discovered. 172 4. This route is used for both the BGP TCP session establishment as 173 well as for resolution of the BGP next-hop (NH) for the routes 174 learnt via the neighbor instead of an underlying IGP or static 175 route. 177 Auto-discovery of BGP neighbors and their liveness detection may be 178 performed via different mechanisms. This document prefers the use of 179 an extension to BGP protocol since the deployments and use-cases 180 targeted (i.e. large-scale DCs) are already running BGP as their 181 routing protocol. Extending BGP with neighbor discovery capabilities 182 is operationally and implementation wise a simpler approach than 183 requiring a new or an additional protocol to be first extended to do 184 this functionality (to exchange BGP-specific parameters) and then 185 also integrated its operations with BGP protocol operations. 187 Following are the key objectives and goals of the BGP neighbor 188 discovery mechanism proposed in this document: 190 o Existing BGP update processing is unchanged 191 o Minimal changes for integration of the neighbor discovery state 192 machine with the existing BGP Peer state machine for auto- 193 discovered neighbors only 195 o Auto-discovery mechanism is restricted to directly connected BGP 196 speakers only and uses link-local multicast addresses only for the 197 hello messaging 199 o Liveness detection is used for monitoring the BGP adjacency status 200 for directly connected BGP routers over individual links and is 201 BGP specific. It is not intended to replace the functionality for 202 existing generic mechanisms like BFD and LLDP. 204 o Hello processing is separate from the core BGP protocol operations 205 such that BGP route processing scale and performance is not 206 impacted 208 The BGP neighbor discovery mechanism defined in this document borrows 209 ideas from the Label Distribution Protocol (LDP) [RFC5036]. However, 210 most importantly, only the concept of link-local signaling based 211 neighbor discovery is borrow while the discovery aspect for targeted 212 LDP sessions does not apply to this BGP neighbor discovery mechanism. 214 The further sections in this document first describe the newly 215 introduced message formats and TLVs and then go on to describe the 216 procedures of the BGP neighbor discovery mechanism and its 217 integration with the base BGP protocol mechanism as specified in 218 [RFC4271]. 220 The operational and management aspects of the BGP neighbor discovery 221 mechanism are described in Section 10. 223 4. UDP Message Header 225 The BGP neighbor discovery mechanism will operate using UDP messages. 226 The UDP port of TBD (179 is the preferred port number to be assigned 227 as specified in Section 11) is used which is same as the TCP port 179 228 used by BGP. The BGP UDP message common header format is specified 229 as follows: 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Version | Type | Message Length | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | AS number | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | BGP Identifier | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 1: BGP UDP Message Header 243 Version: This 1-octet unsigned integer indicates the protocol 244 version number of the message. The current BGP version number is 245 4. 247 Type: The type of BGP message 249 Message Length: This 2-octet unsigned integer specifies the length 250 in octets of the entire BGP UDP message including the header. 252 AS number: AS Number of the UDP message sender. 254 BGP Identifier: BGP Identifier of the UDP message sender. 256 BGP UDP messages can be sent using either IPv4 or IPv6 depending on 257 the address used for session establishment and provisioned on the 258 interfaces over which these messages are sent. 260 5. Hello Message Format 262 A BGP router uses UDP based Hello messages to automatically discover 263 directly connected BGP neighbors and to check their liveliness. The 264 Hello messages and the BGP neighbor discovery mechanism operates only 265 on those interfaces where it is specifically enabled on. The BGP 266 neighbor discovery mechanism is intend for link-local signaling 267 between directly connected BGP nodes and hence the BGP Hello messages 268 MUST be addressed to the "all routers on this subnet" group multicast 269 address (i.e., 224.0.0.2 in the IPv4 case and FF02::2 in the IPv6 270 case) and the TTL for the IP packets SHOULD be set to 1. The IP 271 source address MUST be set to the address of the interface over which 272 the message is sent out which would be the primary interface address 273 or unnumbered address in the IPv4 case and the IPv6 link-local 274 address on the interface in the IPv6 case. 276 The Hello message format is as follows: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Version | Type | Message Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | AS number | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | BGP Identifier | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Adjacency Hold Time | Reserved | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | TLVs | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 2: BGP Hello Message 294 Version: This 1-octet unsigned integer indicates the protocol 295 version number of the message. The current BGP version number is 296 4. 298 Type: The type of BGP message (Hello - TBD value from BGP Message 299 Types Registry) 301 Message Length: This 2-octet unsigned integer specifies the length 302 in octets of the TLVs field. 304 AS number: AS Number of the Hello message sender. 306 BGP Identifier: BGP Identifier of the Hello message sender. 308 Adjacency Hold Time: Hello adjacency hold timer in seconds. 309 Adjacency Hold Time specifies the time the receiving BGP neighbor 310 router SHOULD maintain its neighbor adjacency state without 311 receipt of another Hello. A value of 0 means that the receiving 312 BGP peer should immediately mark that the sender is going down. 314 Reserved: SHOULD be set to 0 by sender and MUST be ignored by 315 receiver. 317 TLVs: This field contains one or more TLVs as described below. 319 BGP HELLO messages can be sent using either IPv4 or IPv6 addresses 320 depending on the addressing used for session establishment and 321 provisioned on the interfaces over which these messages are sent. 322 Either IPv4 or IPv6 address (but never both on the same link) are 323 used for the BGP Hello message exchange and the neighbor discovery 324 mechanism based on the local configuration policy. 326 In a BGP DC network that is using IPv6 only in the fabric underlay, 327 it is possible that no IPv6 global addresses are assigned to the 328 interfaces between the nodes and the IPv6 Global address(es) are 329 assigned only to the loopback interfaces of these nodes. Such a 330 design could ease introducing of nodes in the fabric and links 331 between them from a provisioning aspect. The BGP neighbor discovery 332 mechanism described in this document works on links between routers 333 having only IPv6 link-local addresses and setting up BGP sessions 334 between them using their loopback IPv6 Global addresses in an 335 automatic manner. 337 The neighbor discovery procedure using the Hello message is described 338 in Section 7 and its relation with the BGP Keepalives and Hold Timer 339 for the TCP session is described in Section 8. 341 6. Hello Message TLVs 343 The BGP Hello message carries TLVs as described in this section that 344 enable exchange of information on a per interface basis between 345 directly connected BGP neighbors. These messages enable the neighbor 346 discovery process. 348 6.1. Accepted ASN List TLV 350 The Accepted ASN List TLV is an optional TLV that is used to signal 351 the AS numbers from which the BGP router would accept BGP sessions. 352 When not signaled, it indicates that the router will accept BGP 353 peering from any ASN from its neighbors. Indicating the list of ASNs 354 from which a router will accept BGP sessions helps avoid the neighbor 355 discovery process getting stuck in a 1-way state where one side keeps 356 attempting to setup adjacency while the other does not accept it due 357 to incorrect ASN. 359 The operational and management aspects of this ASN based policy 360 control for BGP neighbor discovery are described further in 361 Section 10. 363 Only a single instance of this TLV is included and its format is 364 shown below. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type | Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Accepted ASN List(variable) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Figure 3: Accepted ASN List TLV 376 Type: TBD1 378 Length:Specifies the length of the Value field in octets (in 379 multiple of 4) 381 Accepted ASN-List: This variable-length field contains one or more 382 accepted 4-octet ASNs. 384 6.2. Peering Address TLV 386 The Peering Address TLV is used to indicate to the neighbor the 387 address to which they should establish the BGP TCP session. For each 388 peering address, the router can specify its supported AFI/SAFI(s). 389 When the AFI/SAFI values are specified as 0/0, then it indicates that 390 the neighbor can attempt for negotiation of any AFI/SAFIs. The 391 indication of AFI/SAFI(s) in the Peering Address TLV is not intended 392 as an alternative for the MP capabilities negotiation mechanism done 393 as part of the BGP TCP session establishment. 395 This is a mandatory TLV and at least one instance of this TLV MUST be 396 present. Multiple instances of this TLV MAY be present one for each 397 peering address (e.g. IPv4 and IPv6 or multiple IPv4 addresses for 398 different AFI/SAFI sessions). 400 The Peering Address TLV format is shown below. 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type | Length | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Flags | No. AFI/SAFI | Reserved | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Address (4-octet or 16-octet) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | AFI | SAFI | ... 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | sub-TLVs ... 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 4: Peering Address TLV 422 Type: TBD2 424 Length:Specifies the length of the Value field in octets. 426 Flags : Current defined bits are as follows. All other bits 427 SHOULD be cleared by sender and MUST be ignored by receiver. 429 Bit 0x1 - address is IPv6 when set and IPv4 when clear 431 Number of AFI/SAFI: indicates the number of AFI/SAFI pairs that 432 the router supports on the given peering address. 434 Reserved: sender SHOULD set to 0 and receiver MUST ignore. 436 Address: This 4 or 16 octet field indicates the IPv4 or IPv6 437 address which is used for establishing BGP sessions. 439 AFI/SAFI : one or more pairs of these values that indicate the 440 supported capabilities on the peering address. 442 Sub-TLVs : currently none defined 444 6.3. Local Prefix TLV 446 When the Peering Address to be used for the BGP TCP session 447 establishment is not the directly connected interface address (e.g. 448 when using loopback address) then local prefix(es) that cover its 449 peering address(es) MUST be signaled by a BGP router to its neighbor 450 as part of the Hello message. This allows the neighbor to learn 451 these local prefix(es) and to program routes for them over the 452 directly connected interfaces over which they are being signaled. 453 The Local Prefix TLV is this an optional TLV and it MUST be used to 454 only signal prefixes that are locally configured on the router. The 455 procedure for resolving the peering address signaled via the Peering 456 Address TLV over the local prefixes signaled is described in 457 Section 7.3. 459 The Local Prefix TLV format is as shown below. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type | Length | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | No. of IPv4 Prefixes | No. of IPv6 Prefixes | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | IPv4 Prefix | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Prefix Mask | ... 473 +-+-+-+-+-+-+-+-+ 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | IPv6 Prefix | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Prefix Mask | ... 479 +-+-+-+-+-+-+-+-+ 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | sub-TLVs ... 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Figure 5: Local Prefix TLV 487 Type: TBD3 489 Length: Specifies the length of the Value field in octets 491 No. of IPv4 Prefixes : specifies the number of IPv4 prefixes. 492 When value is 0, then it indicates no IPv4 Prefixes are present. 494 No. of IPv6 Prefixes : specifies the number of IPv6 prefixes. 495 When value is 0, then it indicates no IPv6 Prefixes are present. 497 IPv4 Prefix Address & Prefix Mask: Zero or more pairs of IPv4 498 prefix address and their mask. 500 IPv6 Prefix Address & Prefix Mask: Zero or more pairs of IPv6 501 prefix address and their mask. 503 Sub-TLVs : currently none defined 505 6.4. Link Attributes TLV 507 The Link Attributes TLV is a mandatory TLV that signals to the 508 neighbor the link attributes of the interface on the local router. A 509 single instance of this TLV MUST be present in the message. This TLV 510 enables a BGP router to learn all its neighbors IP addresses on the 511 specific link as well as its link identifiers. All the IPv4 512 addresses configured on the interface are signaled to the neighbor. 513 When the interface has IPv4 unnumbered address then that is not 514 included in this TLV. Only the IPv6 global addresses configured on 515 the interface are signaled to the neighbor. In case of an interface 516 running dual stack, both IPv4 and IPv6 addresses are signaled in a 517 single TLV irrespective of which one is used for UDP message 518 exchange. 520 More sub-TLVs may be defined in the future to exchange other link 521 attributes between BGP neighbors. 523 The Link Attributes TLV format is as shown below. 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Type | Length | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Local Interface ID | Flags | Reserved | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | No. of IPv4 Addresses | No. of IPv6 Addresses | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | IPv4 Interface Address | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Prefix Mask | ... 539 +-+-+-+-+-+-+-+-+ 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | IPv6 Global Interface Address | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Prefix Mask | ... 545 +-+-+-+-+-+-+-+-+ 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | sub-TLVs ... 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Figure 6: Link Attributes TLV 553 Type: TBD4 555 Length: Specifies the length of the Value field in octets 557 Local Interface ID : the local interface ID of the interface (e.g. 558 the MIB-2 ifIndex). This helps uniquely identify the link even 559 when there are multiple links between two neighbors using IPv4 560 unnumbered address or only having IPv6 link-local addresses. 562 Flags : Currently defined bits are as follows. Other bits SHOULD 563 be cleared by sender and MUST be ignored by receiver. 565 Bit 0x1 - indicates link is enabled for IPv4 567 Bit 0x2 - indicates link is enabled for IPv6 569 Reserved: SHOULD be set to 0 by sender and MUST be ignored by 570 receiver. 572 No. of IPv4 Addresses : specifies the number of IPv4 addresses on 573 the interface. When value is 0, then it indicates no IPv4 574 Prefixes are present or the interface is IPv4 unnumbered if it is 575 enabled for IPv4 577 No. of IPv6 Addresses : specifies the number of IPv6 global 578 addresses on the interface. When value is 0, then it indicates no 579 IPv6 Global Prefixes are present and the interface is only 580 configured with IPv6 link-local addresses if it is enabled for 581 IPv6. 583 IPv4 Address & Mask: Zero or more pairs of IPv4 address and their 584 mask. 586 IPv6 Address & Mask: Zero or more pairs of IPv6 address and their 587 mask. 589 Sub-TLVs : currently none defined 591 6.5. Neighbor TLV 593 The Neighbor TLV is used by a BGP router to indicate its hello 594 adjacency status with its neighboring router(s) on the specific link. 595 The neighbor is identified by its Peering Address which has been 596 accepted. The BGP TCP session establishment process begins when the 597 hello adjacency is formed between the two neighbors over at least one 598 directly connected link between them. Multiple instances of this TLV 599 MAY be present in a Hello message - one for each peering address of 600 each of its neighbor on that particular interface. 602 The Neighbor TLV format is as shown below. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Type | Length | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Flags | Status | Reserved | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Neighbor Peering Address (4-octet or 16-octet) | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | sub-TLVs ... 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Figure 7: Neighbor TLV 618 Type: TBD5 619 Length: Specifies the length of the Value field in octets 621 Flags : Currently defined 0x1 bit is clear when Peering Address is 622 IPv4 and set when IPv6. Other bits SHOULD be clear by sender and 623 MUST be ignored by receiver. 625 Status : Indicates the status code of the peering for the 626 particular session over this link. The following codes are 627 currently defined 629 0 - Indicates 1-way detection of the peer 631 1 - Indicates rejection of the peer due to local policy reasons 632 (i.e. local router would not be initiating or accepting session 633 to this neighbor). 635 2 - Indicates 2-way detection of the peering by both neighbors 637 3 - Indicates that the BGP TCP peering session has been 638 established between the neighbors 640 Reserved: SHOULD be set to 0 by sender and MUST be ignored by 641 receiver. 643 Neighbor Peering Address: This 4 or 16 octet field indicates the 644 IPv4 or IPv6 peering address of the neighbor for which peering 645 status is being reported. 647 Sub-TLVs : currently none defined 649 6.6. Cryptographic Authentication TLV 651 The Cryptographic Authentication TLV is an optional TLV that is used 652 to introduce an authentication mechanism for BGP Hello message by 653 securing against spoofing attacks. It also introduces a 654 cryptographic sequence number carried in the Hello messages that can 655 be used to protect against replay attacks. Using this Cryptographic 656 Authentication TLV, one or more secret keys (with corresponding 657 Security Association (SA) IDs) are configured on each BGP router. 658 For each BGP Hello message, the key is used to generate and verify an 659 HMAC Hash that is stored in the BGP Hello message. For the 660 cryptographic hash function, this document proposes to use SHA-1, 661 SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard 662 (SHS) [FIPS-180-4]. The HMAC authentication mode defined in 663 [RFC2104] is used. Of the above, implementations MUST include 664 support for at least HMAC-SHA-256, SHOULD include support for HMAC- 665 SHA-1, and MAY include support for HMAC-SHA-384 and HMAC-SHA-512. 667 Further details for ensuring the security of the BGP Hello UDP 668 messages are described in Section 9. 670 The Cryptographic Authentication TLV format is as shown below. 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Type | Length | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Security Association ID | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Cryptographic Sequence Number (High-Order 32 Bits) | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Cryptographic Sequence Number (Low-Order 32 Bits) | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Authentication Data (Variable) // 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Figure 8: Cryptographic Authentication TLV 688 Type: TBD6 690 Length: Specifies the length of the Value field in octets 692 Security Association ID: The 32-bit field that maps to the 693 authentication algorithm and the secret key used to create the 694 message digest carried in Hello message payload. 696 Cryptographic Sequence Number: The 64-bit, strictly increasing 697 sequence number that is used to guard against replay attacks. The 698 64-bit sequence number MUST be incremented for every BGP Hello 699 message sent by the BGP router. Upon reception, the sequence 700 number MUST be greater than the sequence number in the last BGP 701 Hello message accepted from the sending BGP neighbor. Otherwise, 702 the BGP hello message is considered a replayed packet and is 703 dropped. The Cryptographic Sequence Number is a single space per 704 BGP router. 706 Authentication Data: This field carries the digest computed by the 707 Cryptographic Authentication algorithm in use. The length of the 708 Authentication Data varies based on the cryptographic algorithm in 709 use, which is shown below: 711 HMAC-SHA1 20 bytes 713 HMAC-SHA-256 32 bytes 715 HMAC-SHA-384 48 bytes 717 HMAC-SHA-512 64 bytes 719 7. Neighbor Discovery Procedure 721 The neighbor discovery mechanism in BGP is implemented with the 722 introduction of an Interface state in BGP and an Adjacency Finite 723 State Machine (FSM). This section describes the states, FSM and 724 procedures involved. 726 7.1. Interface State 728 In order to perform neighbor discovery over its connected interfaces, 729 BGP needs to maintain state for all its connected interfaces over 730 which neighbor discovery is enabled. Once the neighbor discovery is 731 enabled and the link is UP, then BGP starts sending its Hello 732 messages with the TLVs listed in Section 6. The Neighbor TLV 733 described in Section 6.5 is, however, not included until after a 734 neighbor is learnt as part of the discovery process described in 735 further sections. 737 These Hello messages are originated periodically at an interval which 738 is less than or equal to one third of the Adjacency Hold Time 739 specified in the message. The RECOMMENDED default value for the 740 Adjacency Hold Time is 45 seconds and this makes the hello message 741 interval to be 15 seconds. A Hello message SHOULD also be generated 742 in a triggered manner during the neighbor discovery process as a 743 change in the router's own or neighbor's Hello message is detected 744 which results in change in adjacency state or parameters. 746 When a router does not receive a Hello message from its neighbor for 747 a period equal to Adjacency Hold Time, then it MUST clean up its 748 adjacency to this neighbor. The relationship of the Adjacency Hold 749 Timer with the BGP Hold Timer at the TCP session level is described 750 further in Section 8. 752 Before the interface is shut or the neighbor discovery is disabled on 753 it, the router SHOULD attempt to send out triggered Hello messages 754 with Adjacency Hold Time set to 0 and without including any Neighbor 755 TLV in it to indicate that the neighbor discovery is being turned OFF 756 on that router's interface. A router receiving a Hello message with 757 Adjacency Hold Time set to 0 MUST clean up its adjacency to the 758 originating router. 760 7.2. Adjacency State Machine 762 On a per interface basis, BGP needs to maintain an adjacency state 763 for each neighbor that it discovers. The adjacency state is 764 maintained as a FSM and it has the following states: 766 1. Init : This is the initial state that is setup when the router 767 detects a hello message from a new neighbor that it has not seen 768 previously. This is also the state to which the adjacency 769 transitions to when the router no longer sees itself in a 770 Neighbor TLV in the hello message from a neighbor. 772 2. 1-way : This is the state immediately after the Init when the 773 router sends its Hello message with inclusion of the neighbor's 774 Peering Address in a Neighbor TLV with the status set to 1-way. 776 3. Reject : This is the state (generally after Init) when the router 777 detects that the neighbor cannot be accepted due to subnet 778 mismatch on the addresses on either end of the link or a 779 discrepancy in its Accepted ASN List TLV or due to some other 780 local policy. The router then sends its Hello message with 781 inclusion of this neighbor's Peering Address in a Neighbor TLV 782 with the status set to rejection. 784 4. 2-way : This is the state after 1-way when the router detects its 785 own Peering Address in a Neighbor TLV in the neighbor's hello 786 message with the status set to 1-way or 2-way. It then updates 787 the neighbor's status to 2-way in the Neighbor TLV in its own 788 Hello message and sends it out. At this stage, both neighbors 789 have accepted each other. On transition to this state, the 790 router also installs peering route(s) in its own routing table 791 corresponding to the prefix(es) received from the neighbor in its 792 Local Prefix TLV so that reachability is established for the TCP 793 session formation. Next the TCP session formation can be 794 initialized via the BGP Peer FSM. If there is already a peering 795 route to the same address on another interfaces, then this new 796 interface is added as an ECMP path to it. If the BGP TCP session 797 is already initialized (established or connection in progress) 798 towards the same peering address then no further action is 799 required on this BGP Peer FSM. 801 5. Established : This is the state after 2-way when the router has 802 successfully setup its BGP TCP session with the neighbor's 803 Peering Address. It then updates the neighbor's status to 804 established in the Neighbor TLV in its own Hello message and 805 sends it out. 807 Any downward transition from Established or 2-way state to a lower 808 state results in removal of that interface from the peering route(s) 809 for that neighbor and the deletion of the route itself when the last 810 path is deleted. The deletion of the route may bring down the BGP 811 TCP session. 813 A BGP TCP session with an auto-discovered neighbor may have one or 814 more Hello adjacencies corresponding to it - one over each 815 interconnecting link between them. 817 7.3. Peering Route 819 BGP auto-discovered neighbors MAY setup their BGP TCP session over a 820 loopback address instead of using the directly connected interface 821 address between them. When this is desired, the neighbors also 822 advertise the loopback address host prefix (or optionally a prefix 823 which covers more than a single loopback address when multiple are 824 used for different peering sessions) in their Local Prefix TLV. 825 Before the TCP session can be established, the reachability needs to 826 be setup in both direction by each neighbor by programming their 827 local prefixes in their forwarding plane. These routes that are 828 programmed by BGP automatically using the prefixes advertised via the 829 Local Prefix TLV are called Peering Routes. 831 Peering Routes serve two purposes. First, they enable reachability 832 between the Peering Addresses (generally loopbacks) of the two 833 neighbors so that the BGP TCP session may come up between them. 834 Second, for the BGP routes learnt over the TCP session, where the 835 next-hop is the neighbor, they also provide the BGP NH resolution. 837 Unlike other BGP routes, these are not recursive routes as in they 838 point to the neighbor's interface and IP address. These routes that 839 are setup as part of the neighbor discovery procedure are hence 840 different from the regular iBGP and eBGP routes. These routes also 841 MUST have a better administrative distance as compared to the iBGP 842 and eBGP routes to ensure that they do not get displaced from the 843 forwarding by BGP routes learnt over the same session that was 844 established over these peering routes. 846 When there are multiple interconnecting links between two BGP 847 neighbors, a single BGP TCP session may be setup between them over 848 which routes are then exchanged. However, in the forwarding, the 849 peering route will have multiple paths - one for each of these 850 interconnecting links. So the BGP routes learnt over the session 851 actually end up getting resolved over the peering route and in turn 852 get the ECMP load balancing even with a single BGP session. 854 8. Interactions with Base BGP Protocol 856 The BGP Finite State Machine (FSM) as specified in [RFC4271] is 857 unchanged and the BGP TCP session establishment, route updates and 858 processing continues to follow the BGP protocol specifications. 860 BGP peering addresses along with their respective ASNs have 861 traditionally been explicitly provisioned on both the BGP neighbors. 862 The difference that neighbor discovery mechanism brings about is in 863 elimination of this configuration as these parameters are learnt via 864 the neighbor discovery procedure. Once BGP router learns its 865 neighbor's peering address and ASN and has accepted it for peering 866 based on its local policy configuration, then its initializes the BGP 867 Peer FSM for this neighbor in the Idle State - just as if this 868 neighbor was configured. From thereon, the BGP Peer FSM actions 869 follows. 871 The BGP Keepalives and Hold Timer for the session over TCP apply 872 unchanged and they govern the operations of the BGP TCP session and 873 when it is brought down. While the BGP Keepalive works at the TCP 874 session level, the BGP Adjacency Hold Timer monitors the liveliness 875 on one or more underlying interconnecting link between the neighbors. 876 The reachability for the BGP TCP session may be over more than one 877 adjacency. The loss of BGP Hello messages on the UDP transport or 878 some link failure can result in the expiry of the Adjacency Hold 879 Timer. However, this does not result in bringing down of the BGP TCP 880 session for an auto-discovered BGP neighbor by default. An 881 implementation MAY provide an option to bring a BGP TCP session down 882 when the Adjacency Hold Timer expiry brings down the last adjacency 883 between neighbors very similar to how BFD down brings the session 884 down. 886 When the BGP Peer FSM for an auto-discovered neighbor (i.e. one that 887 is not provisioned explicitly), is in the Idle or Connect state then 888 the adjacency state for that neighbor needs to be monitored to check 889 if its BGP TCP session context needs to be cleaned-up. When there is 890 no adjacency state for an auto-discovered neighbor in 2-way or 891 Established state, then the BGP TCP session FSM state for such a 892 neighbor MUST be cleaned-up when in Idle or Connect state. This is 893 similar to when the configuration for a provisioned BGP neighbor is 894 deleted from a BGP router. 896 Since the BGP neighbor discovery mechanism runs over a UDP socket, it 897 is isolated from the core BGP protocol working which is TCP based. 898 Implementations SHOULD ensure that the hello processing does not 899 affect the base BGP operations and scalability. One option may be to 900 run the BGP neighbor discovery mechanism in a separate thread from 901 the rest of BGP processing. These implementation details, however, 902 are outside the scope of this document. 904 It is not generally expected that BGP sessions are explicitly 905 provisioned along with the neighbor discovery mechanism. However, in 906 such an event, the neighbor discovery mechanism MUST NOT affect or 907 result in any changes to provisioned BGP neighbors and their 908 operations. Specifically, BGP peering to auto-discovered neighbors 909 MUST NOT be instantiated using the procedures described in this 910 document when the same BGP neighbor is already provisioned. The 911 configured BGP neighbor parameters take precedence and the auto- 912 discovered values and parameters are not used for such configured BGP 913 sessions. 915 Mechanisms like BFD monitoring and Fast External Failover that are 916 currently used for eBGP sessions may still continue to be used where 917 necessary and are not affected by the neighbor discovery mechanism. 919 9. Security Considerations 921 BGP routers accept TCP connection attempts to port 179 only from the 922 provisioned BGP neighbors or, in some implementations, those from 923 within a configured address range. With the BGP neighbor auto- 924 discovery mechanism, it is now possible for BGP to automatically 925 learn neighbors and initiate/receive TCP connections from them. This 926 introduces the need for specific considerations to be taken care of 927 to ensure security of the BGP protocol operations. 929 This document introduces UDP messages in BGP for the neighbor 930 discovery mechanism using the BGP Hello messages. For security 931 purposes, implementations MUST exchange the Hello messages only on 932 interfaces specifically enabled for neighbor discovery. Hello 933 messages MUST NOT be accepted on other than the 224.0.0.2 or FF02::2 934 addresses. Optionally, implementations MAY set TTL to 255 when 935 originating the Hello messages and receivers check specifically for 936 the TLV to be 254 and discard the packet when this is not the case. 937 This ensures that the Hello packets signaling happens between 938 directly connected BGP routers only. 940 The BGP neighbor discovery mechanism is expected to be run typically 941 in DCs and between physically connected routers that are trustworthy. 942 The Cryptographic Authentication TLV (as described in Section 6.6) 943 SHOULD be used in deployments where this assumption of 944 trustworthiness is not valid. This mechanism is similar to one 945 defined for LDP Hello messages that are also UDP based as specified 946 in [RFC7349]. An updated future version of this document will 947 describe similar procedures for BGP hello in more details. 949 Once the BGP hello messages and the neighbor discovery mechanism is 950 secured, then the security considerations for BGP protocol operations 951 apply for the auto-discovered neighbor sessions. Specifically, for 952 the BGP TCP sessions with the automatically discovered directly 953 connected neighbors, the TTL of the BGP TCP messages (dest port=179) 954 MUST be set to 255. Any received BGP TCP message with TTL being less 955 than 254 MUST be dropped according to [RFC5082]. 957 10. Manageability Considerations 959 This section is structured as recommended in [RFC5706]. 961 10.1. Operational Considerations 963 The BGP neighbor discovery mechanism introduced by this document is 964 not applicable to general BGP deployments and is specifically meant 965 for DC networks where BGP is used as a hop-by-hop routing protocol as 966 described in [RFC7938]. The neighbor discovery mechanism hence 967 SHOULD NOT be enabled by default in BGP. 969 Implementations SHOULD provide configuration methods that allow 970 enablement of BGP neighbor discovery on specific local interfaces. 971 In a DC network, it is expected that the operator selects the 972 appropriate links on which to enable this e.g. on a Tier 2 node it is 973 enabled on all links towards the Tier 1 and Tier 3 nodes while on a 974 Tier 3 node, it may be only enabled on the links towards the Tier 2 975 node. The details of this enablement are outside the scope of this 976 document since it varies based on the DC design and may be 977 implementation specific. 979 Implementations SHOULD provide configuration methods that enable the 980 setup of BGP neighbor templates that enables operator to setup BGP 981 neighbor discovery parameters on the BGP router. Some of the aspects 982 to be considered in such a template are: 984 o Local address to be used for the BGP TCP session peering along 985 with the local ASN and the AFI/SAFI enabled for the auto- 986 discovered sessions 988 o BGP policies to be enabled for the auto-discovered sessions 990 o Optionally specify the list of ASNs with which auto-discovered 991 sessions should be brought up. This is to ensure that when links 992 between different Tier nodes are not used by BGP when they get 993 connected wrongly due to accidents (e.g. say a Tier 3 node is 994 connected to a Tier 1 node). 996 o Authentication methods that are need to be enabled in an 997 environment which is not secure 999 o Local interfaces over which the specific template needs to be 1000 applied for BGP neighbor discovery 1002 o Other parameters like the Adjacency Hold Timer value to be used or 1003 other optional features 1005 This mechanism does not impose any restrictions on the way ASNs or 1006 addresses are assigned to the nodes. Various automatic provisioning, 1007 auto-configuration or zero-touch-provisioning mechanisms may be used. 1009 Implementations SHOULD report the state of the BGP operations over 1010 each link enabled for neighbor discovery including the status of all 1011 adjacencies learnt over it. Implementations SHOULD also report the 1012 operations of the auto-discovered BGP TCP peering sessions similar to 1013 the provisioned BGP neighbors. 1015 Implementations SHOULD support logging of events like discovery of an 1016 adjacency using neighbor discovery including peering route updates 1017 and events like triggering of BGP TCP session establishment for them. 1018 Errors and alarms related to loss of adjacencies and tear down of BGP 1019 TCP peering sessions SHOULD also be generated so they could be 1020 monitored. 1022 10.2. Management Considerations 1024 This document introduces UDP based messaging in BGP protocol and 1025 therefore the necessary fault management mechanisms are required to 1026 be implemented for the same. Implementations MUST discard 1027 unsupported message types or version types other than 4 received over 1028 a UDP session. Such messages MUST NOT affect the neighbor discovery 1029 mechanism in operation using the Hello messages. Unknown TLVs 1030 received via the Hello messages MUST be ignored and the rest of the 1031 Hello message MUST be processed. Implementations SHOULD discard 1032 Hello messages with malformed TLVs and this should be logged as an 1033 error. 1035 11. IANA Considerations 1037 This documents requests IANA for updates to the BGP Parameters 1038 registry as described in this section. 1040 11.1. BGP Hello Message 1042 This document requests IANA to allocate a new UDP port (179 is the 1043 preferred number ) and a BGP message type code for BGP Hello message. 1045 Value TLV Name Reference 1046 ----- ------------------------------------ ------------- 1047 Service Name: BGP-HELLO 1048 Transport Protocol(s): UDP 1049 Assignee: IESG 1050 Contact: IETF Chair . 1051 Description: BGP Hello Message. 1052 Reference: This document -- draft-xu-idr-neighbor-autodiscovery. 1053 Port Number: 179 (preferred value) -- To be assigned by IANA. 1055 11.2. TLVs of BGP Hello Message 1057 This document requests IANA to create a new registry "TLVs of BGP 1058 Hello Message" with the following registration procedure: 1060 Registry Name: TLVs of BGP Hello Message. 1062 Value TLV Name Reference 1063 ------- ---------------------------------- ------------- 1064 0 Reserved This document 1065 1 Accepted ASN List This document 1066 2 Peering Address This document 1067 3 Local Prefix This document 1068 4 Link Attributes This document 1069 5 Neighbor This document 1070 6 Cryptographic Authentication This document 1071 7-65500 Unassigned 1072 65501-65534 Experimental This document 1073 65535 Reserved This document 1075 12. Acknowledgements 1077 The authors would like to thank Enke Chen for his valuable comments 1078 and suggestions on this document. 1080 13. Contributors 1081 Satya Mohanty 1082 Cisco 1083 Email: satyamoh@cisco.com 1085 Shunwan Zhuang 1086 Huawei 1087 Email: zhuangshunwan@huawei.com 1089 Chao Huang 1090 Alibaba Inc 1091 Email: jingtan.hc@alibaba-inc.com 1093 Guixin Bao 1094 Alibaba Inc 1095 Email: guixin.bgx@alibaba-inc.com 1097 Jinghui Liu 1098 Ruijie Networks 1099 Email: liujh@ruijie.com.cn 1101 Zhichun Jiang 1102 Tencent 1103 Email: zcjiang@tencent.com 1105 Shaowen Ma 1106 Juniper Networks 1107 mashaowen@gmail.com 1109 14. References 1111 14.1. Normative References 1113 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1114 Requirement Levels", BCP 14, RFC 2119, 1115 DOI 10.17487/RFC2119, March 1997, 1116 . 1118 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1119 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1120 DOI 10.17487/RFC4271, January 2006, 1121 . 1123 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1124 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1125 October 2007, . 1127 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 1128 Pignataro, "The Generalized TTL Security Mechanism 1129 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 1130 . 1132 14.2. Informative References 1134 [FIPS-180-4] 1135 "Secure Hash Standard (SHS), FIPS PUB 180-4", March 2012. 1137 [I-D.ietf-lsvr-bgp-spf] 1138 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, 1139 "Shortest Path Routing Extensions for BGP Protocol", 1140 draft-ietf-lsvr-bgp-spf-01 (work in progress), May 2018. 1142 [I-D.ketant-idr-bgp-ls-bgp-only-fabric] 1143 Talaulikar, K., Filsfils, C., ananthamurthy, k., and S. 1144 Zandi, "BGP Link-State Extensions for BGP-only Fabric", 1145 draft-ketant-idr-bgp-ls-bgp-only-fabric-00 (work in 1146 progress), March 2018. 1148 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1149 Hashing for Message Authentication", RFC 2104, 1150 DOI 10.17487/RFC2104, February 1997, 1151 . 1153 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1154 Management of New Protocols and Protocol Extensions", 1155 RFC 5706, DOI 10.17487/RFC5706, November 2009, 1156 . 1158 [RFC7349] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello 1159 Cryptographic Authentication", RFC 7349, 1160 DOI 10.17487/RFC7349, August 2014, 1161 . 1163 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1164 S. Ray, "North-Bound Distribution of Link-State and 1165 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1166 DOI 10.17487/RFC7752, March 2016, 1167 . 1169 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 1170 BGP for Routing in Large-Scale Data Centers", RFC 7938, 1171 DOI 10.17487/RFC7938, August 2016, 1172 . 1174 Authors' Addresses 1176 Xiaohu Xu 1177 Alibaba Inc 1179 Email: xiaohu.xxh@alibaba-inc.com 1181 Ketan Talaulikar 1182 Cisco Systems 1184 Email: ketant@cisco.com 1186 Kunyang Bi 1187 Huawei 1189 Email: bikunyang@huawei.com 1191 Jeff Tantsura 1192 Nuage Networks 1194 Email: jefftant.ietf@gmail.com 1196 Nikos Triantafillis 1198 Email: ntriantafillis@gmail.com