idnits 2.17.1 draft-xu-idr-neighbor-autodiscovery-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 : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 1 instance 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 (April 22, 2018) is 2167 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) == Unused Reference: 'RFC8279' is defined on line 559, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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. Bi 5 Expires: October 24, 2018 Huawei 6 J. Tantsura 7 Nuage Networks 8 N. Triantafillis 9 LinkedIn 10 K. Talaulikar 11 Cisco 12 April 22, 2018 14 BGP Neighbor Autodiscovery 15 draft-xu-idr-neighbor-autodiscovery-06 17 Abstract 19 BGP has been used as the underlay routing protocol in many hyper- 20 scale data centers. This document proposes a BGP neighbor 21 autodiscovery mechanism that greatly simplifies BGP deployments. 22 This mechanism is very useful for those hyper-scale data centers 23 where BGP is used as the underlay routing protocol. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 24, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. BGP Hello Message Format . . . . . . . . . . . . . . . . . . 3 68 4. Hello Message Procedure . . . . . . . . . . . . . . . . . . . 10 69 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 7.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 11 73 7.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 12 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 9.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 BGP has been used as the underlay routing protocol instead of IGP in 83 many hyper-scale data centers [RFC7938]. Furthermore, there is an 84 ongoing effort to leverage BGP link-state distribution mechanism to 85 achieve BGP-SPF [I-D.keyupate-lsvr-bgp-spf]. However, BGP is not 86 good as an IGP from the perspective of deployment automation and 87 simplicity. For instance, the IP address and the Autonomous System 88 Number (ASN) of each and every BGP neighbor have to be manually 89 configured on BGP routers although these BGP peers are directly 90 connected. Furthermore, for those BGP routers with multiple physical 91 links being connected, it's usually not ideal to establish BGP 92 sessions over their directly connected interface addresses because 93 the BGP update volume would be unnecessarily increased, meanwhile, it 94 may not be suitable to configure those links as a Link Aggregation 95 Group (LAG) due to some reasons. As a result, it's more common that 96 loopback interface addresses of those directly connected BGP peers 97 are used for BGP session establishment purpose. To make those 98 loopback addresses of directly connected BGP peers reachable from one 99 another, either static routes have to be configured or some kind of 100 IGP has to be enabled. The former is not good from the network 101 automation perspective while the latter is not good from the network 102 simplification perspective (i.e., running less routing protocols). 104 This draft specifies a BGP neighbor autodiscovery mechanism by 105 borrowing some ideas from the Label Distribution Protocol (LDP) 106 [RFC5036] . More specifically, directly connected BGP routers could 107 automatically discovery each other through the exchange of the to-be- 108 defined BGP Hello messages. The BGP session establishment process as 109 defined in [RFC4271] could be triggered once directly connected BGP 110 neighbors are discovered from one another. Note that the BGP session 111 should be established over the discovered the peering address of the 112 BGP neighbor and in most cases the peering address is a loopback 113 address. In addition, to eliminate the need of configuring static 114 routes or enabling IGP for the loopback addresses, a certain type of 115 routes towards the BGP neighbor's loopback addresses as advertised as 116 peering addresses are dynamically instantiated once the BGP neighbor 117 has been discovered. The administrative distance of such type of 118 routes MUST be smaller than their equivalents that are learnt by the 119 regular BGP update messages . Otherwise, circular dependency would 120 occur once these loopback addresses are advertised via the regular 121 BGP updates. 123 2. Terminology 125 This memo makes use of the terms defined in [RFC4271]. 127 3. BGP Hello Message Format 129 To automatically discover directly connected BGP neighbors, a BGP 130 router periodically sends BGP HELLO messages out those interfaces on 131 which BGP neighbor autodiscovery are enabled. The BGP HELLO message 132 MUST sent as a UDP packet with a destination port of TBD (179 is the 133 preferred port number value) addressed for the "all routers on this 134 subnet" group multicast address (i.e., 224.0.0.2 in the IPv4 case and 135 FF02::2 in the IPv6 case). The IP source address is set to the 136 address of the interface over which the message is sent out. 138 The HELLO message contains the following fields: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Version | Type | Message Length | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | AS number | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | BGP Identifier | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Hold Time | Reserved | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | TLVs | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Figure 1: BGP Hello Message 155 Version: This 1-octet unsigned integer indicates the protocol 156 version number of the message. The current BGP version number is 157 4. 159 Type: The type of BGP message (Hello - TBD value from BGP Message 160 Types Registry) 162 Message Length: This 2-octet unsigned integer specifies the length 163 in octets of the TLVs field. 165 AS number: AS Number of the Hello message sender. 167 BGP Identifier: BGP Identifier of the Hello message sender. 169 Hold Time: Hello hold timer in seconds. Hello Hold Time specifies 170 the time the receiving BGP peer will maintain its record of Hellos 171 from the sending BGP peer without receipt of another Hello. The 172 RECOMMENDED default value is 15 seconds. A value of 0 means that 173 the receiving BGP peer should maintain its record until the link 174 is UP. 176 Reserved: SHOULD be set to 0 by sender and MUST be ignored by 177 receiver. 179 TLVs: This field contains one or more TLVs as described below. 181 The Accepted ASN List TLV is an optional TLV that is used to signal 182 the AS numbers from which the router would accept BGP sessions. When 183 not signaled, it indicates that the router will accept BGP peering 184 from any ASN from its neighbors. Only a single instance of this TLV 185 is included and its format is shown below. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Type | Length | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Accepted ASN List(variable) | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 2: Accepted ASN List TLV 196 Type: TBD1 198 Length:Specifies the length of the Value field in octets. 200 Accepted ASN-List: This variable-length field contains one or more 201 accepted 4-octet ASNs. 203 The Peering Address TLV is used to indicate to the neighbor the 204 address to which they should establish BGP session. For each peering 205 address, the router can specify its supported AFI/SAFI(s). When the 206 AFI/SAFI values are specified as 0/0, then it indicates that the 207 neighbor can attempt for negotiation of any AFI/SAFIs. The 208 indication of AFI/SAFI(s) in the Peering Address TLV is not intended 209 as an alternative for the MP capabilities negotiation mechanism. 211 The Peering Address TLV format is shown below and at least one 212 instance of this TLV MUST be present. 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 | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Flags | No. AFI/SAFI | Reserved | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Address (4-octet or 16-octet) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | AFI | SAFI | ... 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | sub-TLVs ... 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 3: Peering Address TLV 233 Type: TBD2 234 Length:Specifies the length of the Value field in octets. 236 Flags : Current defined bits are as follows. All other bits 237 SHOULD be cleared by sender and MUST be ignored by receiver. 239 Bit 0x1 - address is IPv6 when set and IPv4 when clear 241 Number of AFI/SAFI: indicates the number of AFI/SAFI pairs that 242 the router supports on the given peering address. 244 Reserved: sender SHOULD set to 0 and receiver MUST ignore. 246 Address: This 4 or 16 octect field indicates the IPv4 or IPv6 247 address which is used for establishing BGP sessions. 249 AFI/SAFI : one or more pairs of these values that indicate the 250 supported capabilities on the peering address. 252 Sub-TLVs : currently none defined 254 When the Peering Address used is not the directly connected interface 255 address (e.g. when it is a loopback address) then local prefix(es) 256 that cover the peering address(es) MUST be signaled by the router. 257 This allows the neighbor to learn these local prefix(es) and to 258 program routes for them over the directly connected interfaces over 259 which they are being signalled. The Local Prefixes TLV is used to 260 only signal prefixes that are locally configured on the router and 261 its format is as shown below. 263 0 1 2 3 264 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type | Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | No. of IPv4 Prefixes | No. of IPv6 Prefixes | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | IPv4 Prefix | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Prefix Mask | ... 275 +-+-+-+-+-+-+-+-+ 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | IPv6 Prefix | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Prefix Mask | ... 281 +-+-+-+-+-+-+-+-+ 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | sub-TLVs ... 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 4: Local Prefixes TLV 289 Type: TBD3 291 Length:Specifies the length of the Value field in octets 293 No. of IPv4 Prefixes : specifies the number of IPv4 prefixes. 294 When value is 0, then it indicates no IPv4 Prefixes are present. 296 No. of IPv6 Prefixes : specifies the number of IPv6 prefixes. 297 When value is 0, then it indicates no IPv6 Prefixes are present. 299 IPv4 Prefix Address & Prefix Mask: Zero or more pairs of IPv4 300 prefix address and their mask. 302 IPv6 Prefix Address & Prefix Mask: Zero or more pairs of IPv6 303 prefix address and their mask. 305 Sub-TLVs : currently none defined 307 The Link Attributes TLV is a mandatory TLV that signals to the 308 neighbor the link attributes of the interface on the local router. A 309 single instance of this TLV MUST be present in the message. The Link 310 Attributes TLV is as shown below. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type | Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Local Interface ID | Flags | Reserved | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | No. of IPv4 Addresses | No. of IPv6 Addresses | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | IPv4 Local Address | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Prefix Mask | ... 326 +-+-+-+-+-+-+-+-+ 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | IPv6 Local Address | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Prefix Mask | ... 332 +-+-+-+-+-+-+-+-+ 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | sub-TLVs ... 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 5: Link Attributes TLV 340 Type: TBD4 342 Length:Specifies the length of the Value field in octets 344 Local Interface ID : the local interface ID of the interface (e.g. 345 the MIB-2 ifIndex) 347 Flags : Currently defined bits are as follows. Other bits SHOULD 348 be cleared by sender and MUST be ignored by receiver. 350 Bit 0x1 - indicates link is enabled for IPv4 352 Bit 0x2 - indicates link is enabled for IPv6 354 Reserved: SHOULD be set to 0 by sender and MUST be ignored by 355 receiver. 357 No. of IPv4 Addresses : specifies the number of IPv4 local 358 addresses on the interface. When value is 0, then it indicates no 359 IPv4 Prefixes are present or the interface is IP unnumbered. 361 No. of IPv6 Addresses : specifies the number of IPv6 Global 362 addresses on the interface. When value is 0, then it indicates no 363 IPv6 Global Prefixes are present or the interface is only 364 configured with IPv6 link-local addresses 366 IPv4 Address & Mask: Zero or more pairs of IPv4 address and their 367 mask. 369 IPv6 Address & Mask: Zero or more pairs of IPv6 address and their 370 mask. 372 Sub-TLVs : currently none defined 374 The Neighbor TLV is used by a BGP router to indicate the peering 375 address and information about the neighbors that have been discovered 376 by the router on the specific link and their status. The BGP session 377 establishment process begins when both the neighbors accept each 378 other over at least one underlying inter-connecting link between 379 them. The Neighbor TLV format is as shown below. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type | Length | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Flags | Status | Reserved | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Neighbor Peering Address (4-octet or 16-octet) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | sub-TLVs ... 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 6: Neighbor TLV 395 Type: TBD5 397 Length:Specifies the length of the Value field in octets 399 Flags : Currently defined 0x1 bit is clear when Peering Address is 400 IPv4 and set when IPv6. Other bits SHOULD be clear by sender and 401 MUST be ignored by receiver. 403 Status : Indicates the status code of the peering for the 404 particular session over this link. The following codes are 405 currently defined 406 0 - Indicates 1-way detection of the peer 408 1 - Indicates rejection of the peer due to local policy reasons 409 (i.e. local router would not be initiating or accepting session 410 to this neighbor) 412 2 - Indicates 2-way detection of the peering by both neighbors 414 3 - Indicates that the BGP peering session has been established 415 between the neighbors and that this link would be utilized for 416 forwarding to the peer BGP nexthop 418 Reserved: SHOULD be set to 0 by sender and MUST be ignored by 419 receiver. 421 Neighbor Peering Address: This 4 or 16 octect field indicates the 422 IPv4 or IPv6 peering address of the neighbor for which peering 423 status is being reported. 425 Sub-TLVs : currently none defined 427 4. Hello Message Procedure 429 A BGP peer receiving Hellos from another peer maintains a Hello 430 adjacency corresponding to the Hellos. The peer maintains a hold 431 timer with the Hello adjacency, which it restarts whenever it 432 receives a Hello that matches the Hello adjacency. If the hold timer 433 for a Hello adjacency expires the peer discards the Hello adjacency. 435 We recommend that the interval between Hello transmissions be at most 436 one third of the Hello hold time. 438 A BGP session with a peer has one or more Hello adjacencies. 440 A BGP session has multiple Hello adjacencies when a pair of BGP peers 441 is connected by multiple links that have the same connection address 442 (e.g., multiple point-to-point links between a pair of routers). In 443 this situation, the Hellos a BGP peer sends on each such link carry 444 the same Peering Address. In addition, to eliminate the need of 445 configuring static routes or enabling IGP for advertising the 446 loopback addresses, a certain type of routes towards the BGP 447 neighbor's loopback addresses (i.e. carried in the Local Prefixes 448 TLV) could be dynamically created once the BGP neighbor has been 449 discovered. The administrative distance of such type of routes MUST 450 be smaller than their equivalents which are learnt via the normal BGP 451 update messages. Otherwise, circular dependency problem would occur 452 once these loopback addresses are advertised via the normal BGP 453 update messages as well. 455 BGP uses the regular receipt of BGP Hellos to indicate a peer's 456 intent to keep BGP session identified by the Hello. A BGP peer 457 maintains a hold timer with each Hello adjacency that it restarts 458 when it receives a Hello that matches the adjacency. If the timer 459 expires without receipt of a matching Hello from the peer, BGP 460 concludes that the peer no longer wishes to keep BGP session for that 461 link or that the peer has failed. The BGP peer then deletes the 462 Hello adjacency. The route towards the BGP neighbor's loopback 463 address that had been dynamically created due to that BGP Hello 464 adjacency SHOULD be deleted accordingly. When the last Hello 465 adjacency for an BGP session is deleted, the BGP peer terminates the 466 BGP session and closing the transport connection. 468 5. Contributors 470 Satya Mohanty 471 Cisco 472 Email: satyamoh@cisco.com 474 Shunwan Zhuang 475 Huawei 476 Email: zhuangshunwan@huawei.com 478 6. Acknowledgements 480 The authors would like to thank Enke Chen for his valuable comments 481 and suggestions on this document. 483 7. IANA Considerations 485 7.1. BGP Hello Message 487 This document requests IANA to allocate a new UDP port (179 is the 488 preferred number ) and a BGP message type code for BGP Hello message. 490 Value TLV Name Reference 491 ----- ------------------------------------ ------------- 492 Service Name: BGP-HELLO 493 Transport Protocol(s): UDP 494 Assignee: IESG 495 Contact: IETF Chair . 496 Description: BGP Hello Message. 497 Reference: This document -- draft-xu-idr-neighbor-autodiscovery. 498 Port Number: TBD1 (179 is the preferred value) -- To be assigned by IANA. 500 7.2. TLVs of BGP Hello Message 502 This document requests IANA to create a new registry "TLVs of BGP 503 Hello Message" with the following registration procedure: 505 Registry Name: TLVs of BGP Hello Message. 507 Value TLV Name Reference 508 ------- ------------------------------------------ ------------- 509 0 Reserved This document 510 1 Accepted ASN List This document 511 2 Peering Address This document 512 3 Local Prefixes This document 513 4 Link Attributes This document 514 5 Neighbor This document 515 6-65500 Unassigned 516 65501-65534 Experimental This document 517 65535 Reserved This document 519 8. Security Considerations 521 For security purposes, BGP speakers usually only accept TCP 522 connection attempts to port 179 from the specified BGP peers or those 523 within the configured address range. With the BGP neighbor auto- 524 discovery mechanism, it's configurable to enable or disable sending/ 525 receiving BGP hello messages on the per-interface basis and BGP hello 526 messages are only exchanged between physically connected peers that 527 are trustworthy. Therefore, the BGP neighbor auto-discovery 528 mechanism doesn't introduce additional security risks associated with 529 BGP. 531 In addition, for the BGP sessions with the automatically discovered 532 peers via the BGP hello messages, the TTL of the TCP/BGP messages 533 (dest port=179) MUST be set to 255. Any received TCP/BGP message 534 with TTL being less than 254 MUST be dropped according to [RFC5082]. 536 9. References 538 9.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, 542 DOI 10.17487/RFC2119, March 1997, 543 . 545 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 546 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 547 DOI 10.17487/RFC4271, January 2006, 548 . 550 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 551 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 552 October 2007, . 554 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 555 Pignataro, "The Generalized TTL Security Mechanism 556 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 557 . 559 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 560 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 561 Explicit Replication (BIER)", RFC 8279, 562 DOI 10.17487/RFC8279, November 2017, 563 . 565 9.2. Informative References 567 [I-D.keyupate-lsvr-bgp-spf] 568 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, 569 "Shortest Path Routing Extensions for BGP Protocol", 570 draft-keyupate-lsvr-bgp-spf-00 (work in progress), March 571 2018. 573 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 574 BGP for Routing in Large-Scale Data Centers", RFC 7938, 575 DOI 10.17487/RFC7938, August 2016, 576 . 578 Authors' Addresses 580 Xiaohu Xu 581 Alibaba Inc 583 Email: xiaohu.xxh@alibaba-inc.com 585 Kunyang Bi 586 Huawei 588 Email: bikunyang@huawei.com 589 Jeff Tantsura 590 Nuage Networks 592 Email: jefftant.ietf@gmail.com 594 Nikos Triantafillis 595 LinkedIn 597 Email: nikos@linkedin.com 599 Ketan Talaulikar 600 Cisco 602 Email: ketant@cisco.com