idnits 2.17.00 (12 Aug 2021) /tmp/idnits1090/draft-xu-idr-neighbor-autodiscovery-04.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 15 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 7, 2018) is 1505 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 362, 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 9, 2018 Huawei 6 J. Tantsura 7 Nuage Networks 8 N. Triantafillis 9 Linked-in 10 K. Talaulikar 11 Cisco 12 April 7, 2018 14 BGP Neighbor Autodiscovery 15 draft-xu-idr-neighbor-autodiscovery-04 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 9, 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 . . . . . . . . . . . . . . . . . . . 5 69 5. HELLO Message Error Handling . . . . . . . . . . . . . . . . 6 70 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 7 74 8.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 7 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 10.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 BGP has been used as the underlay routing protocol instead of IGP in 84 many hyper-scale data centers [RFC7938]. Furthermore, there is an 85 ongoing effort to leverage BGP link-state distribution mechanism to 86 achieve BGP-SPF [I-D.keyupate-lsvr-bgp-spf]. However, BGP is not 87 good as an IGP from the perspective of deployment automation and 88 simplicity. For instance, the IP address and the Autonomous System 89 Number (ASN) of each and every BGP neighbor have to be manually 90 configured on BGP routers although these BGP peers are directly 91 connected. In addition, for those directly connected BGP routers, 92 it's usually not ideal to establish BGP sessions over their directly 93 connected interface addresses due to the following reasons: 1) it's 94 not convient to do trouble-shooting; 2) the BGP update volume is 95 unnecessarily increased when there are multiple physical links 96 between them and those links couldn't be configured as a Link 97 Aggregtion Group (LAG) due to whatever reason (e.g., diffferent link 98 type or speed). As a result, it's more common that loopback 99 interface addresses of those directly connected BGP peers are used 100 for BGP session establishment. To make those loopback addresses of 101 directly connected BGP peers reachable from one another, either 102 static routes have to be configured or some kind of IGP has to be 103 enabled. The former is not good from the automation perspective 104 while the latter is in conflict with the original intention of using 105 BGP as an IGP. 107 This draft specifies a BGP neighbor autodiscovery mechanism by 108 borrowing some ideas from the Label Distribution Protocol (LDP) 109 [RFC5036] . More specifically, directly connected BGP routers could 110 automatically discovery the loopback address and the ASN of one other 111 through the exchange of the to-be-defined BGP messages. The BGP 112 session establishment process as defined in [RFC4271] could be 113 triggered once directly connected BGP neighbors are discovered from 114 one another. Note that the BGP session should be established over 115 the discovered loopback address of the BGP neighbor. In addition, to 116 elimnate the need of configuring static routes or enabling IGP for 117 the loopback addresses, a certain type of routes towards the BGP 118 neighbor's loopback addresses are dynatically instantiated once the 119 BGP neighbor has been discovered. The administritive distance of 120 such type of routes MUST be smaller than their equivalents that are 121 learnt by the regular BGP update messages . Otherwise, circular 122 dependency would occur once these loopback addresses are advertised 123 via the regular BGP updates. 125 2. Terminology 127 This memo makes use of the terms defined in [RFC4271]. 129 3. BGP Hello Message Format 131 To automatically discover directly connected BGP neighbors, a BGP 132 router periodically sends BGP HELLO messages out those interfaces on 133 which BGP neighbor autodiscovery are enabled. The BGP HELLO message 134 is a new BGP message which has the same fixed-size BGP header as the 135 exiting BGP messages. However, the HELLO message MUST sent as UDP 136 packets addressed to the to-be-assigned BGP discovery port (179 is 137 the suggested port value) for the "all routers on this subnet" group 138 multicast address (i.e., 224.0.0.2 in the IPv4 case and FF02::2 in 139 the IPv6 case). The IP source address is set to the address of the 140 interface over which the message is sent out. 142 In addition to the fixed-size BGP header, the HELLO message contains 143 the following fields: 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Version | Hold Time | Message Length | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | AS number | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | TLVs | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 1: BGP Hello Message 156 Version: This 1-octet unsigned integer indicates the protocol 157 version number of the message. The current BGP version number is 158 4. 160 Hold Time: Hello hold timer in seconds. Hello Hold Time specifies 161 the time the sending BGP peer will maintain its record of Hellos 162 from the receiving BGP peer without receipt of another Hello. A 163 pair of BGP peers negotiates the hold times they use for Hellos 164 from each other. Each proposes a hold time. The hold time used 165 is the minimum of the hold times proposed in their Hellos. A 166 value of 0 means use the default 15 seconds. 168 Message Length: This 2-octet unsigned integer specifies the length 169 in octects of the Connection Address TLV and other TLVs. 171 AS number: AS Number of the Hello message sender. 173 TLVs: This field contains Connection Address TLV and other TLVs. 175 The Accepted ASN List TLV format is shown as follows: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type=TBD1 | Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Accepted ASN List(variable) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 2: Accepted ASN List TLV 186 Type: TBD1 188 Length:Specifies the length of the Value field in octets. 190 Accepted ASN-List: This variable-length field contains one or more 191 accepted 4-octet ASNs. 193 The Connection Address TLV format is shown as follows: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type=TBD2 | Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Connection Address (4-octet or 16-octet) | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 3: Connection Address TLV 204 Type: TBD2 206 Length:Specifies the length of the Value field in octets. 208 Connection Address: This variable-length field indicates the IPv4 209 or IPv6 loopback address which is used for establishing BGP 210 sessions. 212 The Router ID TLV format is shown as follows: 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=TBD3 | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Router ID (4-octet or 16-octet) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 4: Router ID TLV 223 Type: TBD3 225 Length:Specifies the length of the Value field in octets and it's 226 set to 4 for the IPv4-address-formatted BGP Router ID. 228 Router ID: This variable-length field indicates the BGP router ID 229 which could be used for performing the BGP-SPF algorithm as 230 described in [I-D.keyupate-lsvr-bgp-spf]. 232 4. Hello Message Procedure 234 A BGP peer receiving Hellos from another peer maintains a Hello 235 adjacency corresponding to the Hellos. The peer maintains a hold 236 timer with the Hello adjacency, which it restarts whenever it 237 receives a Hello that matches the Hello adjacency. If the hold timer 238 for a Hello adjacency expires the peer discards the Hello adjacency. 240 We recommend that the interval between Hello transmissions be at most 241 one third of the Hello hold time. 243 A BGP session with a peer has one or more Hello adjacencies. 245 A BGP session has multiple Hello adjacencies when a pair of BGP peers 246 is connected by multiple links that have the same connection address 247 (e.g., multiple PPP links between a pair of routers). In this 248 situation, the Hellos a BGP peer sends on each such link carry the 249 same Connection Address. In addition, to elimnate the need of 250 configuring static routes or enabling IGP for advertising the 251 loopback addresses, a certain type of routes towards the BGP 252 neighbor's loopback addresses (e.g., carried in the Connection 253 Address TLV) could be dymatically created once the BGP neighbor has 254 been discovered. The administritive distance of such type of routes 255 MUST be smaller than their equivalents which are learnt via the 256 normal BGP update messages. Otherwise, circular dependency problem 257 would occur once these loopback addresses are advertised via the 258 normal BGP update messages as well. 260 BGP uses the regular receipt of BGP Hellos to indicate a peer's 261 intent to keep BGP session identified by the Hello. A BGP peer 262 maintains a hold timer with each Hello adjacency that it restarts 263 when it receives a Hello that matches the adjacency. If the timer 264 expires without receipt of a matching Hello from the peer, BGP 265 concludes that the peer no longer wishes to keep BGP session for that 266 link or that the peer has failed. The BGP peer then deletes the 267 Hello adjacency. When the last Hello adjacency for an BGP session is 268 deleted, the BGP peer terminates the BGP session by sending a 269 Notification message and closing the transport connection. 270 Meanwhile, the routes towards the BGP neighbor's loopback addresses 271 that had been dynamically created due to the BGP Hello adjacency 272 SHOULD be deleted accordingly. 274 5. HELLO Message Error Handling 276 TBD 278 6. Contributors 280 Satya Mohanty 281 Cisco 282 Email: satyamoh@cisco.com 284 7. Acknowledgements 286 The authors would like to thank Enke Chen for his valuable comments 287 and suggestions on this document. 289 8. IANA Considerations 291 8.1. BGP Hello Message 293 This document requests IANA to allocate a new UDP port for BGP Hello 294 message. 296 Value TLV Name Reference 297 ----- ------------------------------------ ------------- 298 Service Name: BGP-HELLO 299 Transport Protocol(s): UDP 300 Assignee: IESG 301 Contact: IETF Chair . 302 Description: BGP Hello Message. 303 Reference: This document -- draft-xu-idr-neighbor-autodiscovery. 304 Port Number: TBD1 (179 is the suggested value) -- To be assigned by IANA. 306 8.2. TLVs of BGP Hello Message 308 This document requests IANA to create a new registry "TLVs of BGP 309 Hello Message" with the following registration procedure: 311 Registry Name: TLVs of BGP Hello Message. 313 Value TLV Name Reference 314 ------- ------------------------------------------ ------------- 315 0 Reserved This document 316 1 Accepted ASN List This document 317 2 Connection Address This document 318 3 Router ID This document 319 4-65500 Unassigned 320 65501-65534 Experimental This document 321 65535 Reserved This document 323 9. Security Considerations 325 For security purposes, BGP speakers usually only accept TCP 326 connection attempts to port 179 from the specified BGP peers or those 327 within the configured address range. With the BGP auto-discovery 328 mechanism, it's configurable to enable or disable sending/receiving 329 BGP hello messages on the per-interface basis and BGP hello messages 330 are only exchanged between physically connected peers that are 331 trustworthy. Therefore, the BGP auto-discovery mechanism doesn't 332 introduce additional security risks associated with BGP. 334 In addition, for the BGP sessions with the automatically discovered 335 peers via the BGP hello messages, the TTL of the TCP/BGP messages 336 (dest port=179) MUST be set to 255. Any received TCP/BGP message 337 with TTL being less than 254 MUST be dropped according to [RFC5082]. 339 10. References 341 10.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 349 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 350 DOI 10.17487/RFC4271, January 2006, 351 . 353 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 354 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 355 October 2007, . 357 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 358 Pignataro, "The Generalized TTL Security Mechanism 359 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 360 . 362 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 363 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 364 Explicit Replication (BIER)", RFC 8279, 365 DOI 10.17487/RFC8279, November 2017, 366 . 368 10.2. Informative References 370 [I-D.keyupate-lsvr-bgp-spf] 371 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, 372 "Shortest Path Routing Extensions for BGP Protocol", 373 draft-keyupate-lsvr-bgp-spf-00 (work in progress), March 374 2018. 376 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 377 BGP for Routing in Large-Scale Data Centers", RFC 7938, 378 DOI 10.17487/RFC7938, August 2016, 379 . 381 Authors' Addresses 383 Xiaohu Xu 384 Alibaba Inc. 386 Email: xiaohu.xxh@alibaba-inc.com 388 Kunyang Bi 389 Huawei 391 Email: bikunyang@huawei.com 393 Jeff Tantsura 394 Nuage Networks 396 Email: jefftant.ietf@gmail.com 398 Nikos Triantafillis 399 Linked-in 401 Fax: Nikos Triantafillis 403 Ketan Talaulikar 404 Cisco 406 Email: ketant@cisco.com