idnits 2.17.1 draft-raszuk-idr-bgp-auto-session-setup-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 2 instances 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 16, 2018) is 2110 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: 'RFC4271' is defined on line 240, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group R. Raszuk, Ed. 3 Internet-Draft Bloomberg LP 4 Intended status: Standards Track July 16, 2018 5 Expires: January 17, 2019 7 BGP Automated Session Setup (BGP-ASS) 8 draft-raszuk-idr-bgp-auto-session-setup-00 10 Abstract 12 This document proposes a solution for BGP deployments in some 13 specific environments to automatically establish BGP sessions without 14 need for manual peer configuration. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 17, 2019. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Definitions of Terms Used in This Memo . . . . . . . . . . . 2 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 2 53 4. Loopbacks reachability bootstrapping . . . . . . . . . . . . 3 54 5. ECMP routes recursion . . . . . . . . . . . . . . . . . . . . 4 55 6. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 7. Advantages to alternative proposals . . . . . . . . . . . . . 4 57 8. Changes to BGP Finite State Machine . . . . . . . . . . . . . 5 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 61 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 12.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 12.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Definitions of Terms Used in This Memo 68 NLRI - Network Layer Reachability Information. 70 RIB - Routing Information Base. 72 AS - Autonomous System number. 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 76 "OPTIONAL" in this document are to be interpreted as described in BCP 77 14 [RFC2119] [RFC8174] when, and only when, they appear in all 78 capitals, as shown here. 80 2. Introduction 82 The popularity of use of BGP in number of data centers or campus 83 deployments where BGP is being used as/instead of IGP brings 84 operational challenges associated with setup of BGP peering relations 86 This proposal aims on automating the BGP session bring-up without 87 aprior knowledge of the peer's IP addresses by use of existing BGP 88 protocol. 90 3. Proposed Solution 92 When BGP attempts to establish the EBGP sessions with unknown peers 93 router will start sending BGP Session Explorer (BSE) packets which 94 are to be regular BGP session establishment packets containing plain 95 BGP OPEN Message except instead of regular peer address a multicast 96 address will be used 224.0.0.2 "All Routers on this Subnet" as UDP 97 destination address. Destination port of this UDP packets is to be 98 assigned by IANA. Source address will be selected by the operator 99 either local interface address (when establishing plain p2p relation) 100 or loopback address (when establishing peering between loopback 101 addresses). 103 Authors leave this as open discussion point to use instead of well 104 known multicast address of 224.0.0.2 a new IANA assigned multicast 105 address dedicated for the purpose of BGP Auto Session Setup. 107 Unidirectional reception of BGP Session Explorers will allow for peer 108 to respond with standard unicast TCP BGP OPEN Message using 109 destination address indicated previously as source address of BSE 110 packets. Source address in the BGP OPEN Message attempt will be 111 peer's local operator's selected source address. 113 The above procedure will allow for automated BGP session bring-up 114 without aprior knowledge of the peer's BGP peering address for any 115 AFI/SAFI. 117 BGP Sessions Explorers are unidirectional and only are to be sent out 118 on those interfaces where there is no direct EBGP session established 119 on or which would be otherwise used as recursive members of L3 group 120 of parallel links with already recursive routes installed to 121 corresponding EBGP session between loopback addresses. 123 4. Loopbacks reachability bootstrapping 125 Upon reception of BGP Session Explorer packet on a BGP designated 126 port BGP will parse the BGP OPEN Message in an informational mode to 127 record peer's interest in EBGP session establishment. However at 128 this point there is an assumption that loopback addresses are 129 unreachable on both sides. When session is p2p session over 130 connected interface the reachability to session endpoints is by 131 default in place and no further work is needed. 133 In the case of loopbacks after successful parsing of BGP Session 134 Explorer packets BGP is to install in RIB BGP reachability towards 135 the source address of the BSE source address with the outgoing 136 interface BSE packet arrived on. 138 Such reachability is of temporary nature till BGP session is 139 established between peers and peers exchange in their corresponding 140 BGP UPDATE Messages loopback reachability with at least one next hop 141 belonging to local connected address. 143 It is recommended that in the event of no session being established 144 such temporary reachability will time out after configurable timer 145 interval (default 180 seconds). 147 5. ECMP routes recursion 149 The described session establishment process will result in either 150 point to point EBGP sessions or EBGP sessions between loopback 151 addresses. 153 In the former case the direct point to point connected subnet is used 154 as peering address and there is no need for any additional 155 procedures. 157 In the case however when peering is established between loopbacks - 158 typically the case in the ECMP based deployments when multiple L3 159 interface interconnect given pair of routers the loopback address 160 used both as peering address and next hop of advertised routes need 161 to recursively resolve via all directly connected subnets in order to 162 effectively perform load balancing of traffic. For this task authors 163 recommend regular BGP UPDATE Message to be used along with new BGP 164 ATTRIBUTE MULTIPLE_HOP containing the list of all connected local 165 addresses configured to be used as ECMP paths towards non connected 166 next hop. The detailed proposal for this attribute has been 167 described in the former work: draft-bhatia-bgp-multiple-next-hops 168 [I-D.bhatia-bgp-multiple-next-hops]. 170 An alternative methods for learning connected addresses towards not 171 connected next hop can also be used. The choice of methods of 172 accomplishing this reachability propagation is purposely made out of 173 scope of this specification allowing both operator's choice as well 174 as technology evolution in this space. 176 6. Scalability 178 Parsing received to port 179 TCP packets and fixed size BGP OPEN 179 Messages from all potential EBGP peers in applicable deployment 180 scenarios of the target space of this proposal may result in very 181 limited and contained need for additional processing. When port 179 182 is not open BGP OPEN Messages will be dropped. Upon establishing BGP 183 session no new BGP OPEN Messages will be send on a given subnet. 185 7. Advantages to alternative proposals 187 The solutions described does not require any new message on the wire 188 other then standard BGP OPEN Message already defined in other 189 documents. 191 The proposed solution does not require any extra efforts for route 192 installation in RIB and FIB other then via standard BGP route 193 insertion and deletion procedures. 195 The proposed solutions reuses all of the existing BGP mechanisms in 196 the space of session establishment and session maintenance and does 197 not result in any race conditions or conflicts between existing and 198 new procedures. 200 The proposed solution by its design does not allow any additional 201 functionality like interface_ids or node/link topology discovery as 202 it is authors believe that there are much better methods to 203 accomplish those tasks outside of BGP protocol. 205 8. Changes to BGP Finite State Machine 207 The following changes to BGP FSM are proposed: 209 To be completed when/if document gets traction in the WG. 211 9. Security Considerations 213 No new security issues are introduced to the BGP protocol by this 214 specification. 216 All operational security procedures which are applicable to standard 217 BGP operation apply here. 219 It is highly recommended that TCP authentication when establishing 220 unicast TCP sessions is used. 222 10. IANA Considerations 224 This document request IANA to allocate UDP port number for BGP 225 Session Explorer messages. 227 11. Acknowledgments 229 Authors would like to thank ... for their valuable input. 231 12. References 233 12.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, 237 DOI 10.17487/RFC2119, March 1997, 238 . 240 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 241 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 242 DOI 10.17487/RFC4271, January 2006, 243 . 245 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 246 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 247 May 2017, . 249 12.2. Informative References 251 [I-D.bhatia-bgp-multiple-next-hops] 252 Bhatia, M., "Advertising Multiple NextHop Routes in BGP", 253 draft-bhatia-bgp-multiple-next-hops-01 (work in progress), 254 August 2006. 256 Author's Address 258 Robert Raszuk (editor) 259 Bloomberg LP 260 731 Lexington Ave 261 New York City, NY 10022 262 USA 264 Email: robert@raszuk.net