idnits 2.17.1 draft-xu-idr-neighbor-autodiscovery-02.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 (July 3, 2017) is 2490 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 (-04) exists of draft-keyupate-idr-bgp-spf-03 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 K. Bi 4 Intended status: Standards Track Huawei 5 Expires: January 4, 2018 J. Tantsura 6 Individual 7 July 3, 2017 9 BGP Neighbor Autodiscovery 10 draft-xu-idr-neighbor-autodiscovery-02 12 Abstract 14 BGP has been used as the routing protocol in many hyper-scale data 15 centers. This document proposes a BGP neighbor autodiscovery 16 mechanism that greatly simplifies BGP deployments. This mechanism is 17 very useful for those hyper-scale data centers where BGP is used as 18 the routing protocol. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 4, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. BGP Hello Message Format . . . . . . . . . . . . . . . . . . 3 58 4. Hello Message Procedure . . . . . . . . . . . . . . . . . . . 5 59 5. HELLO Message Error Handling . . . . . . . . . . . . . . . . 6 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. BGP Hello Message . . . . . . . . . . . . . . . . . . . . 6 63 7.2. TLVs of BGP Hello Message . . . . . . . . . . . . . . . . 7 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 BGP has been used as the routing protocol instead of IGP in many 73 hyper-scale data centers [RFC7938]. Furthermore, there is an ongoing 74 effort to leverages BGP Link-State distribution and the Shortest Path 75 First algorithm similar to Internal Gateway Protocols (IGPs) such as 76 OSPF [I-D.keyupate-idr-bgp-spf]. In a word, there is a strong 77 motivation to replace IGP's by BGP in hyper-scale data centers. 79 However, BGP is not good as an IGP from the perspective of deployment 80 automation and simplicity. For instance, the IP address and the 81 Autonomous System Number (ASN) of each and every BGP neighbor have to 82 be manually configured on BGP routers although these BGP peers are 83 directly connected. In addition, for those directly connected BGP 84 routers, it's usually not ideal to establish BGP sessions over their 85 directly connected interface addresses due to the following reasons: 86 1) it's not convient to do trouble-shooting; 2) the BGP update volume 87 is unnecessarily increased when there are multiple physical links 88 between them and those links couldn't be configured as a Link 89 Aggregtion Group (LAG) due to whatever reason (e.g., diffferent link 90 type or speed). As a result, it's more common that loopback 91 interface addresses of those directly connected BGP peers are used 92 for BGP session establishment. To make those loopback addresses of 93 directly connected BGP peers reachable from one another, either 94 static routes have to be configured or some kind of IGP has to be 95 enabled. The former is not good from the automation perspective 96 while the latter is in conflict with the original intention of using 97 BGP as an IGP. 99 This draft specifies a BGP neighbor autodiscovery mechanism by 100 borrowing some ideas from the Label Distribution Protocol (LDP) 101 [RFC5036] . More specifically, directly connected BGP routers could 102 automatically discovery the loopback address and the ASN of one other 103 through the exchange of the to-be-defined BGP messages. The BGP 104 session establishment process as defined in [RFC4271] is triggered 105 once directly connected BGP neighbors are discovered from one 106 another. Note that the BGP session should be established over the 107 discovered loopback address of the BGP neighbor. In addition, to 108 elimnate the need of configuring static routes or enabling IGP for 109 the loopback addresses, a certain type of routes towards the BGP 110 neighbor's loopback addresses are dynatically instantiated once the 111 BGP neighbor has been discovered. The administritive distance of 112 such type of routes MUST be smaller than their equivalents that are 113 learnt by the regular BGP update messages . Otherwise, circular 114 dependency would occur once these loopback addresses are advertised 115 via the regular BGP updates. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 is a new BGP message which has the same fixed-size BGP header as the 133 exiting BGP messages. However, the HELLO message MUST sent as UDP 134 packets addressed to the to-be-assigned BGP discovery port (179 is 135 the suggested port value) for the "all routers on this subnet" group 136 multicast address (i.e., 224.0.0.2 in the IPv4 case and FF02::2 in 137 the IPv6 case). The IP source address is set to the address of the 138 interface over which the message is sent out. 140 In addition to the fixed-size BGP header, the HELLO message contains 141 the following fields: 143 0 1 2 3 144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Version | Hold Time | Message Length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | AS number | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | TLVs | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1: BGP Hello Message 154 Version: This 1-octet unsigned integer indicates the protocol 155 version number of the message. The current BGP version number is 156 4. 158 Hold Time: Hello hold timer in seconds. Hello Hold Time specifies 159 the time the sending BGP peer will maintain its record of Hellos 160 from the receiving BGP peer without receipt of another Hello. A 161 pair of BGP peers negotiates the hold times they use for Hellos 162 from each other. Each proposes a hold time. The hold time used 163 is the minimum of the hold times proposed in their Hellos. A 164 value of 0 means use the default 15 seconds. 166 Message Length: This 2-octet unsigned integer specifies the length 167 in octects of the Connection Address TLV and other TLVs. 169 AS number: AS Number of the Hello message sender. 171 TLVs: This field contains Connection Address TLV and other TLVs. 173 The Accepted ASN List TLV format is shown as follows: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type=TBD1 | Length | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Accepted ASN List(variable) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 2: Accepted ASN List TLV 184 Type: TBD1 186 Length:Specifies the length of the Value field in octets. 188 Accepted ASN-List: This variable-length field contains one or more 189 accepted 4-octet ASNs. 191 The Connection Address TLV format is shown as follows: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type=TBD2 | Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Connection Address (4-octet or 16-octet) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 3: Connection Address TLV 202 Type: TBD2 204 Length:Specifies the length of the Value field in octets. 206 Connection Address: This variable-length field indicates the IPv4 207 or IPv6 loopback address which is used for establishing BGP 208 sessions. 210 The Router ID TLV format is shown as follows: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Type=TBD3 | Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Router ID (4-octet or 16-octet) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 4: Router ID TLV 221 Type: TBD3 223 Length:Specifies the length of the Value field in octets and it's 224 set to 4 for the IPv4-address-formatted BGP Router ID. 226 Router ID: This variable-length field indicates the BGP router ID 227 which is used for performing the BGP-SPF algorithm as described in 228 [I-D.keyupate-idr-bgp-spf]. 230 4. Hello Message Procedure 232 A BGP peer receiving Hellos from another peer maintains a Hello 233 adjacency corresponding to the Hellos. The peer maintains a hold 234 timer with the Hello adjacency, which it restarts whenever it 235 receives a Hello that matches the Hello adjacency. If the hold timer 236 for a Hello adjacency expires the peer discards the Hello adjacency. 238 We recommend that the interval between Hello transmissions be at most 239 one third of the Hello hold time. 241 A BGP session with a peer has one or more Hello adjacencies. 243 A BGP session has multiple Hello adjacencies when a pair of BGP peers 244 is connected by multiple links that have the same connection address; 245 for example, multiple PPP links between a pair of routers. In this 246 situation, the Hellos a BGP peer sends on each such link carry the 247 same Connection Address. In addition, to elimnate the need of 248 configing static routes or enabling IGP for the loopback addresses, a 249 certain type of routes towards the BGP neighbor's loopback addresses 250 (e.g., carried in the Connection Address TLV) are dymatically created 251 once the BGP neighbor has been discovered. The administritive 252 distance of such type of routes MUST be smaller than their 253 equivalents which are learnt via the normal BGP update messages. 254 Otherwise, circular dependency problem would occur once these 255 loopback addresses are advertised via the normal BGP update messages 256 as well. 258 BGP uses the regular receipt of BGP Discovery Hellos to indicate a 259 peer's intent to keep BGP session identified by the Hello. A BGP 260 peer maintains a hold timer with each Hello adjacency that it 261 restarts when it receives a Hello that matches the adjacency. If the 262 timer expires without receipt of a matching Hello from the peer, BGP 263 concludes that the peer no longer wishes to keep BGP session for that 264 link or that the peer has failed. The BGP peer then deletes the 265 Hello adjacency. When the last Hello adjacency for an BGP session is 266 deleted, the BGP peer terminates the BGP session by sending a 267 Notification message and closing the transport connection. 269 5. HELLO Message Error Handling 271 TBD 273 6. Acknowledgements 275 The authors would like to thank Enke Chen and Nikos Triantafillis for 276 their valuable comments and suggestions on this document. 278 7. IANA Considerations 280 7.1. BGP Hello Message 282 This document requests IANA to allocate a new UDP port for BGP Hello 283 message. 285 Value TLV Name Reference 286 ----- ------------------------------------ ------------- 287 Service Name: BGP-HELLO 288 Transport Protocol(s): UDP 289 Assignee: IESG 290 Contact: IETF Chair . 291 Description: BGP Hello Message. 292 Reference: This document -- draft-xu-idr-neighbor-autodiscovery. 293 Port Number: TBD1 (179 is the suggested value) -- To be assigned by IANA. 295 7.2. TLVs of BGP Hello Message 297 This document requests IANA to create a new registry "TLVs of BGP 298 Hello Message" with the following registration procedure: 300 Registry Name: TLVs of BGP Hello Message. 302 Value TLV Name Reference 303 ------- ------------------------------------------ ------------- 304 0 Reserved This document 305 1 Accepted ASN List This document 306 2 Connection Address This document 307 3 Router ID This document 308 4-65500 Unassigned 309 65501-65534 Experimental This document 310 65535 Reserved This document 312 8. Security Considerations 314 For security purposes, BGP speakers usually only accept TCP 315 connection attempts to port 179 from the specified BGP peers or those 316 within the configured address range. With the BGP auto-discovery 317 mechanism, it's configurable to enable or disable sending/receiving 318 BGP hello messages on the per-interface basis and BGP hello messages 319 are only exchanged between physically connected peers that are 320 trustworthy. Therefore, the BGP auto-discovery mechanism doesn't 321 introduce additional security risks associated with BGP. 323 In addition, for the BGP sessions with the automatically discovered 324 peers via the BGP hello messages, the TTL of the TCP/BGP messages 325 (dest port=179) MUST be set to 255. Any received TCP/BGP message 326 with TTL being less than 254 MUST be dropped according to [RFC5082]. 328 9. References 329 9.1. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, 333 DOI 10.17487/RFC2119, March 1997, 334 . 336 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 337 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 338 DOI 10.17487/RFC4271, January 2006, 339 . 341 9.2. Informative References 343 [I-D.keyupate-idr-bgp-spf] 344 Patel, K., Lindem, A., Zandi, S., and G. Velde, "Shortest 345 Path Routing Extensions for BGP Protocol", draft-keyupate- 346 idr-bgp-spf-03 (work in progress), June 2017. 348 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 349 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 350 October 2007, . 352 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 353 Pignataro, "The Generalized TTL Security Mechanism 354 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 355 . 357 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 358 BGP for Routing in Large-Scale Data Centers", RFC 7938, 359 DOI 10.17487/RFC7938, August 2016, 360 . 362 Authors' Addresses 364 Xiaohu Xu 365 Huawei 367 Email: xuxiaohu@huawei.com 369 Kunyang Bi 370 Huawei 372 Email: bikunyang@huawei.com 373 Jeff Tantsura 374 Individual 376 Email: jefftant.ietf@gmail.com