idnits 2.17.1 draft-xu-idr-neighbor-autodiscovery-00.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 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 (December 24, 2016) is 2680 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-02 Summary: 0 errors (**), 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: June 27, 2017 December 24, 2016 7 BGP Neighbor Autodiscovery 8 draft-xu-idr-neighbor-autodiscovery-00 10 Abstract 12 BGP has been used as an underlay routing protocol in many hyper-scale 13 data centers. This document proposes a BGP neighbor autodiscovery 14 mechanism which can be used to simplify the BGP deployment greatly. 15 This mechanism is very useful for those hyper-scale data centers 16 where BGP is used as an underlay routing protocol. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 27, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. BGP Hello Message Format . . . . . . . . . . . . . . . . . . 3 56 4. Hello Message Procedure . . . . . . . . . . . . . . . . . . . 5 57 5. HELLO Message Error Handling . . . . . . . . . . . . . . . . 6 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 9.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 BGP has been used as an underlay routing protocol instead of IGP in 69 many hyper-scale data centers [RFC7938]. Furthermore, there is an 70 attempt to leverages BGP Link-State distribution and the Shortest 71 Path First algorithm similar to Internal Gateway Protocols (IGPs) 72 such as OSPF [I-D.keyupate-idr-bgp-spf]. In a word, there is a 73 strong motivation to replace IGP by BGP in hyper-scale data centers. 75 However, BGP is not good as IGP from the perspective of deployment 76 automation and simplicity. For instance, the IP address and 77 Autonomous System Number (ASN) of each BGP neighbor have to be 78 manually configured on BGP routers although these BGP peers are 79 directly connected. In addition, for those directly connected BGP 80 routers, it's usually not ideal to establish BGP sessions over their 81 directly connected interface addresses due to the following reasons: 82 1) it's not convient to do trouble-shooting; 2) the BGP update volume 83 is unnecessarily increased when there are multiple physical links 84 between them and those links couldn't be configured as a Link 85 Aggregtion Group (LAG) due to whatever reason (e.g., diffferent link 86 type or speed). As a result, it's more common that loopback 87 interface addresses of those directly connected BGP peers are used 88 for BGP session establishment. To make those loopback addresses of 89 directly connected BGP peers reachable from one another, either 90 static routes have to be configured or some kind of IGP has to be 91 enabled. The former is not good from the automation perspective 92 while the latter is in conflict with the original intention of using 93 BGP as IGP. 95 This draft specifies a BGP neighbor autodiscovery mechanism by 96 borrowing some ideas from the Label Distribution Protocol (LDP) 97 [RFC5036] . More specifically, directly connected BGP routers could 98 automatically discovery the loopback address and the ASN of one other 99 through the exchange of the to-be-defined BGP HELLO messages. The 100 BGP session establishment process as defined in [RFC4271] is 101 triggered once directly connected BGP neighbors are discovered from 102 one another. Note that the BGP session should be established over 103 the discovered loopback address of the BGP neighbor. In addition, to 104 elimnate the need of configing static routes or enabling IGP for the 105 loopback addresses, a certain type of routes towards the BGP 106 neighbor's loopback addresses are dymatically created once the BGP 107 neighbor has been discovered. The administritive distance of such 108 type of routes MUST be smaller than their equivalents which are 109 learnt via the normal BGP update messages . Otherwise, circular 110 dependency problem would occur once these loopback addresses are 111 advertised via the normal BGP update messages as well. 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. Terminology 121 This memo makes use of the terms defined in [RFC4271]. 123 3. BGP Hello Message Format 125 To automatically discover directly connected BGP neighbors, a BGP 126 router periodically sends BGP HELLO messages out those interfaces on 127 which BGP neighbor autodiscovery are enabled. The BGP HELLO message 128 is a new BGP message which has the same fixed-size BGP header as the 129 exiting BGP messages. However, the HELLO message MUST sent as UDP 130 packets addressed to the to-be-assigned BGP discovery port (179 is 131 the suggested port value) for the "all routers on this subnet" group 132 multicast address (i.e., 224.0.0.2 in the IPv4 case and FF02::2 in 133 the IPv6 case. The IP source address is set to the address of the 134 interface over which the message is sent out. 136 In addition to the fixed-size BGP header, the HELLO message contains 137 the following fields: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Version | Hold Time | Message Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | TLVs | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: BGP Hello Message 148 Version: This 1-octet unsigned integer indicates the protocol 149 version number of the message. The current BGP version number is 150 4. 152 Hold Time: Hello hold timer in seconds. Hello Hold Time specifies 153 the time the sending BGP peer will maintain its record of Hellos 154 from the receiving BGP peer without receipt of another Hello. A 155 pair of BGP peers negotiates the hold times they use for Hellos 156 from each other. Each proposes a hold time. The hold time used 157 is the minimum of the hold times proposed in their Hellos. A 158 value of 0 means use the default 15 seconds. 160 Message Length: This 2-octet unsigned integer specifies the length 161 in octects of the ASN TLV, Connection Address TLV and other TLVs. 163 TLVs: This field contains ASN TLV, Connection Address TLV and 164 other TLVs. 166 The ASN TLV format is show as follows: 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type=TBD2 | Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | AS Number (2-octet or 4-octet) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 2: ASN TLV 177 Type: TBD2. 179 Length: Specifies the length of the Value field in octets. 181 AS Number: This variable-length field indicates the 2-octet or 182 4-octet ASN of the sender. 184 The Connection Address TLV format is shown as follows: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type=TBD3 | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Connection Address (4-octet or 16-octet) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 3: Connection Address TLV 195 Type: TBD3 197 Length:Specifies the length of the Value field in octets. 199 Connection Address: This variable-length field indicates the IPv4 200 or IPv6 loopback address which is used for establishing BGP 201 sessions. 203 4. Hello Message Procedure 205 A BGP peer receiving Hellos from another peer maintains a Hello 206 adjacency corresponding to the Hellos. The peer maintains a hold 207 timer with the Hello adjacency, which it restarts whenever it 208 receives a Hello that matches the Hello adjacency. If the hold timer 209 for a Hello adjacency expires the peer discards the Hello adjacency. 211 We recommend that the interval between Hello transmissions be at most 212 one third of the Hello hold time. 214 A BGP session with a peer has one or more Hello adjacencies. 216 A BGP session has multiple Hello adjacencies when a pair of BGP peers 217 is connected by multiple links that have the same connection address; 218 for example, multiple PPP links between a pair of routers. In this 219 situation, the Hellos a BGP peer sends on each such link carry the 220 same Connection Address. In addition, to elimnate the need of 221 configing static routes or enabling IGP for the loopback addresses, a 222 certain type of routes towards the BGP neighbor's loopback addresses 223 (e.g., carried in the Connection Address TLV) are dymatically created 224 once the BGP neighbor has been discovered. The administritive 225 distance of such type of routes MUST be smaller than their 226 equivalents which are learnt via the normal BGP update messages. 227 Otherwise, circular dependency problem would occur once these 228 loopback addresses are advertised via the normal BGP update messages 229 as well. 231 BGP uses the regular receipt of BGP Discovery Hellos to indicate a 232 peer's intent to keep BGP session identified by the Hello. A BGP 233 peer maintains a hold timer with each Hello adjacency that it 234 restarts when it receives a Hello that matches the adjacency. If the 235 timer expires without receipt of a matching Hello from the peer, BGP 236 concludes that the peer no longer wishes to keep BGP session for that 237 link or that the peer has failed. The BGP peer then deletes the 238 Hello adjacency. When the last Hello adjacency for an BGP session is 239 deleted, the BGP peer terminates the BGP session by sending a 240 Notification message and closing the transport connection. 242 5. HELLO Message Error Handling 244 TBD 246 6. Acknowledgements 248 The authors would like to thank 250 7. IANA Considerations 252 TBD. 254 8. Security Considerations 256 TBD 258 9. References 260 9.1. Normative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, 264 DOI 10.17487/RFC2119, March 1997, 265 . 267 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 268 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 269 DOI 10.17487/RFC4271, January 2006, 270 . 272 9.2. Informative References 274 [I-D.keyupate-idr-bgp-spf] 275 Patel, K., Lindem, A., Zandi, S., and G. Velde, "Shortest 276 Path Routing Extensions for BGP Protocol", draft-keyupate- 277 idr-bgp-spf-02 (work in progress), December 2016. 279 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 280 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 281 October 2007, . 283 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 284 BGP for Routing in Large-Scale Data Centers", RFC 7938, 285 DOI 10.17487/RFC7938, August 2016, 286 . 288 Authors' Addresses 290 Xiaohu Xu 291 Huawei 293 Email: xuxiaohu@huawei.com 295 Kunyang Bi 296 Huawei 298 Email: bikunyang@huawei.com