idnits 2.17.1 draft-xu-idr-neighbor-autodiscovery-05.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 2204 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 355, 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 LinkedIn 10 K. Talaulikar 11 Cisco 12 April 7, 2018 14 BGP Neighbor Autodiscovery 15 draft-xu-idr-neighbor-autodiscovery-05 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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 7 73 7.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 7 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 9.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 the loopback address and the ASN of one other 108 through the exchange of the to-be-defined BGP messages. The BGP 109 session establishment process as defined in [RFC4271] could be 110 triggered once directly connected BGP neighbors are discovered from 111 one another. Note that the BGP session should be established over 112 the discovered loopback address of the BGP neighbor. In addition, to 113 eliminate the need of configuring static routes or enabling IGP for 114 the loopback addresses, a certain type of routes towards the BGP 115 neighbor's loopback addresses are dynamically instantiated once the 116 BGP neighbor has been discovered. The administrative distance of 117 such type of routes MUST be smaller than their equivalents that are 118 learnt by the regular BGP update messages . Otherwise, circular 119 dependency would occur once these loopback addresses are advertised 120 via the regular BGP updates. 122 2. Terminology 124 This memo makes use of the terms defined in [RFC4271]. 126 3. BGP Hello Message Format 128 To automatically discover directly connected BGP neighbors, a BGP 129 router periodically sends BGP HELLO messages out those interfaces on 130 which BGP neighbor autodiscovery are enabled. The BGP HELLO message 131 is a new BGP message which has the same fixed-size BGP header as the 132 exiting BGP messages. However, the HELLO message MUST sent as UDP 133 packets addressed to the to-be-assigned BGP discovery port (179 is 134 the suggested port value) for the "all routers on this subnet" group 135 multicast address (i.e., 224.0.0.2 in the IPv4 case and FF02::2 in 136 the IPv6 case). The IP source address is set to the address of the 137 interface over which the message is sent out. 139 In addition to the fixed-size BGP header, the HELLO message contains 140 the following fields: 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Version | Hold Time | Message Length | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | AS number | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | TLVs | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1: BGP Hello Message 153 Version: This 1-octet unsigned integer indicates the protocol 154 version number of the message. The current BGP version number is 155 4. 157 Hold Time: Hello hold timer in seconds. Hello Hold Time specifies 158 the time the sending BGP peer will maintain its record of Hellos 159 from the receiving BGP peer without receipt of another Hello. A 160 pair of BGP peers negotiates the hold times they use for Hellos 161 from each other. Each proposes a hold time. The hold time used 162 is the minimum of the hold times proposed in their Hellos. A 163 value of 0 means use the default 15 seconds. 165 Message Length: This 2-octet unsigned integer specifies the length 166 in octets of the TLVs field. 168 AS number: AS Number of the Hello message sender. 170 TLVs: This field contains one or more TLVs as described below. 172 The Accepted ASN List TLV format is shown as follows: 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Type=TBD1 | Length | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Accepted ASN List(variable) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Figure 2: Accepted ASN List TLV 183 Type: TBD1 185 Length:Specifies the length of the Value field in octets. 187 Accepted ASN-List: This variable-length field contains one or more 188 accepted 4-octet ASNs. 190 The Connection Address TLV format is shown as follows: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Type=TBD2 | Length | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Connection Address (4-octet or 16-octet) | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 3: Connection Address TLV 201 Type: TBD2 203 Length:Specifies the length of the Value field in octets. 205 Connection Address: This variable-length field indicates the IPv4 206 or IPv6 loopback address which is used for establishing BGP 207 sessions. 209 The Router ID TLV format is shown as follows: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type=TBD3 | Length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Router ID (4-octet or 16-octet) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 4: Router ID TLV 220 Type: TBD3 222 Length:Specifies the length of the Value field in octets and it's 223 set to 4 for the IPv4-address-formatted BGP Router ID. 225 Router ID: This variable-length field indicates the BGP router ID 226 which could be used for performing the BGP-SPF algorithm as 227 described in [I-D.keyupate-lsvr-bgp-spf]. 229 4. Hello Message Procedure 231 A BGP peer receiving Hellos from another peer maintains a Hello 232 adjacency corresponding to the Hellos. The peer maintains a hold 233 timer with the Hello adjacency, which it restarts whenever it 234 receives a Hello that matches the Hello adjacency. If the hold timer 235 for a Hello adjacency expires the peer discards the Hello adjacency. 237 We recommend that the interval between Hello transmissions be at most 238 one third of the Hello hold time. 240 A BGP session with a peer has one or more Hello adjacencies. 242 A BGP session has multiple Hello adjacencies when a pair of BGP peers 243 is connected by multiple links that have the same connection address 244 (e.g., multiple PPP links between a pair of routers). In this 245 situation, the Hellos a BGP peer sends on each such link carry the 246 same Connection Address. In addition, to eliminate the need of 247 configuring static routes or enabling IGP for advertising the 248 loopback addresses, a certain type of routes towards the BGP 249 neighbor's loopback addresses (e.g., carried in the Connection 250 Address TLV) could be dynamically created once the BGP neighbor has 251 been discovered. The administrative distance of such type of routes 252 MUST be smaller than their equivalents which are learnt via the 253 normal BGP update messages. Otherwise, circular dependency problem 254 would occur once these loopback addresses are advertised via the 255 normal BGP update messages as well. 257 BGP uses the regular receipt of BGP Hellos to indicate a peer's 258 intent to keep BGP session identified by the Hello. A BGP peer 259 maintains a hold timer with each Hello adjacency that it restarts 260 when it receives a Hello that matches the adjacency. If the timer 261 expires without receipt of a matching Hello from the peer, BGP 262 concludes that the peer no longer wishes to keep BGP session for that 263 link or that the peer has failed. The BGP peer then deletes the 264 Hello adjacency. The route towards the BGP neighbor's loopback 265 address that had been dynamically created due to that BGP Hello 266 adjacency SHOULD be deleted accordingly. When the last Hello 267 adjacency for an BGP session is deleted, the BGP peer terminates the 268 BGP session and closing the transport connection. 270 5. Contributors 272 Satya Mohanty 273 Cisco 274 Email: satyamoh@cisco.com 276 6. Acknowledgements 278 The authors would like to thank Enke Chen for his valuable comments 279 and suggestions on this document. 281 7. IANA Considerations 283 7.1. BGP Hello Message 285 This document requests IANA to allocate a new UDP port for BGP Hello 286 message. 288 Value TLV Name Reference 289 ----- ------------------------------------ ------------- 290 Service Name: BGP-HELLO 291 Transport Protocol(s): UDP 292 Assignee: IESG 293 Contact: IETF Chair . 294 Description: BGP Hello Message. 295 Reference: This document -- draft-xu-idr-neighbor-autodiscovery. 296 Port Number: TBD1 (179 is the suggested value) -- To be assigned by IANA. 298 7.2. TLVs of BGP Hello Message 300 This document requests IANA to create a new registry "TLVs of BGP 301 Hello Message" with the following registration procedure: 303 Registry Name: TLVs of BGP Hello Message. 305 Value TLV Name Reference 306 ------- ------------------------------------------ ------------- 307 0 Reserved This document 308 1 Accepted ASN List This document 309 2 Connection Address This document 310 3 Router ID This document 311 4-65500 Unassigned 312 65501-65534 Experimental This document 313 65535 Reserved This document 315 8. Security Considerations 317 For security purposes, BGP speakers usually only accept TCP 318 connection attempts to port 179 from the specified BGP peers or those 319 within the configured address range. With the BGP neighbor auto- 320 discovery mechanism, it's configurable to enable or disable sending/ 321 receiving BGP hello messages on the per-interface basis and BGP hello 322 messages are only exchanged between physically connected peers that 323 are trustworthy. Therefore, the BGP neighbor auto-discovery 324 mechanism doesn't introduce additional security risks associated with 325 BGP. 327 In addition, for the BGP sessions with the automatically discovered 328 peers via the BGP hello messages, the TTL of the TCP/BGP messages 329 (dest port=179) MUST be set to 255. Any received TCP/BGP message 330 with TTL being less than 254 MUST be dropped according to [RFC5082]. 332 9. References 334 9.1. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 342 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 343 DOI 10.17487/RFC4271, January 2006, 344 . 346 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 347 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 348 October 2007, . 350 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 351 Pignataro, "The Generalized TTL Security Mechanism 352 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 353 . 355 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 356 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 357 Explicit Replication (BIER)", RFC 8279, 358 DOI 10.17487/RFC8279, November 2017, 359 . 361 9.2. Informative References 363 [I-D.keyupate-lsvr-bgp-spf] 364 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, 365 "Shortest Path Routing Extensions for BGP Protocol", 366 draft-keyupate-lsvr-bgp-spf-00 (work in progress), March 367 2018. 369 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 370 BGP for Routing in Large-Scale Data Centers", RFC 7938, 371 DOI 10.17487/RFC7938, August 2016, 372 . 374 Authors' Addresses 376 Xiaohu Xu 377 Alibaba Inc 379 Email: xiaohu.xxh@alibaba-inc.com 381 Kunyang Bi 382 Huawei 384 Email: bikunyang@huawei.com 386 Jeff Tantsura 387 Nuage Networks 389 Email: jefftant.ietf@gmail.com 391 Nikos Triantafillis 392 LinkedIn 394 Email: nikos@linkedin.com 396 Ketan Talaulikar 397 Cisco 399 Email: ketant@cisco.com