idnits 2.17.1 draft-ymbk-lsvr-discovery-req-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2019) is 1647 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-29) exists of draft-ietf-lsvr-bgp-spf-06 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Arrcus & IIJ 4 Intended status: Informational K. Patel 5 Expires: April 23, 2020 Arrcus 6 October 21, 2019 8 BGP Topology Discovery Requirements 9 draft-ymbk-lsvr-discovery-req-03 11 Abstract 13 For wide scale routing protocols to build their topology and 14 reachability databases they need to discover the encapsulation data 15 on a link, link IP layer 3 attributes, attributes for IP layer 3 and 16 above protocols on that link, and link liveness. We refer to this as 17 neighbor discovery. BGP-LS and its enhancements provide an API to 18 present much of these data to BGP protocols, but do not directly 19 collect these data. This document explores the needs and criteria 20 for the data needed. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 23, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Architectural Considerations . . . . . . . . . . . . . . . . 2 58 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 In a massive scale datacenter or similar environment BGP([RFC4271]) 70 and BGP-like protocols, e.g. BGP-SPF (see [I-D.ietf-lsvr-bgp-spf]), 71 provide massive scale-out without centralization using a tried and 72 tested scalable distributed control plane transport, offering a 73 scalable routing solution. But BGP4, BGP-SPF, and similar protocols 74 need layer 3 topology discovery; meaning IP encapsulations on a link, 75 layer 3 IP addressing data on a link, attributes for IP layer 3 and 76 above protocols on that link, and assured link liveness from the 77 network to build and maintain the routing topology. 79 BGP-LS [RFC7752] and its extensions provide an API which BGP4 and 80 BGP-SPF can use to get the and distribute topology data. But BGP-LS 81 itself does not gather the data, it merely presents it. So the IP 82 topology data must be gathered. 84 What topology data do BGP-like protocols actually need? What level 85 of freshness is needed? What are the requirements for scale, 86 extensibility, security, etc? 88 2. Architectural Considerations 90 Massive Data Centers (MDCs) have on the order of 10,000 racks, often 91 with two Top Of Rack (TOR) devices per rack, on the order of 40 92 hardware servers per rack, each with order 100 virtual services or 93 machines, each with their own layer 3 IP address. Given service 94 mobility, any initial IP address aggregation fragments over time. To 95 provide this level of scaling reliably, stably, and security imposes 96 architectural constraints on any discovery protocol. 98 o Deployable - If it is not easily deployable, it is a pointless 99 exercise. To be deployable, it must be easy to provision (e.g. 100 zero touch provisioning, Open Config, YANG, et alia), easily 101 reconfigured, easily measured, and easily monitored. 103 o Simple - If it isn't simple, it will not scale. Simplicity 104 requires restraint in design. 'Union Protocols' which are the sum 105 of everyone's desires are complex disasters waiting to happen. 106 Often they do not wait. Prefer 'Intersection Protocols' which 107 include only those things which everyone absolutely needs. 109 o Securable - Security properties should be analyzed. Again, 110 simplicity is key; complex protocols increase in complexity over 111 time, and security vulnerabilities increase significantly with 112 complexity. As [RFC5218] 2.2.3 says "The more successful a 113 protocol becomes, the more attractive a target it will be." 115 o Extensible - As [RFC5218] Section 2.2.1 said, successful protocols 116 are extensible beyond the original expectation. MDC and similar 117 needs are expanding and we are still learning about the space. 118 Simplicity and extensibility should go a long way to adaptability; 119 complex protocols are hard to extend, especially when they are 120 poorly understood. 122 o Implementable - It must be reasonably easy to implement and 123 deploy. Some implications are: 125 * Packet formats should be easy to generate and easily parsable. 126 Type/length/Value (TLV) formats are preferred. 128 * The protocols should be free to use and deploy; i.e. not be 129 constrained by Intellectual Property Right (IPR) claims. 131 * Again, simpler protocols are simpler to implement, deploy, 132 measure, monitor, etc. 134 * Performance Problems arise if the protocol was not designed to 135 scale. 137 o Low Impact - The MDCs chose BGP for, among other reasons, it is 138 quiet and only transmits changes, not repeated flooding of the 139 same information. This allows great scale. The discovery 140 protocol should be similar in this regard, not flood or chatter 141 the same information repeatedly. It should support fast and quiet 142 session restoration in case of link failure and restoration when 143 there has been no actual change in end point attributes. 145 o Compatible - It must be compatible with the various routing 146 technologies used in MDCs. The new discovery protocol will 147 discover the IP layer 3 encapsulations, learn layer 3 addressing 148 data from the network, confirm link liveness, in order to allow 149 upper layer routing protocol(s), e..g. BGP4, BGP-SPF, and BGP-LS, 150 to build maintain and distribute the topology. 152 3. Requirements 154 The target for the discovery protocol(s) is a massive datacenter 155 scale deployment using BGP or similar routing, e.g. BGP4 or 156 [I-D.ietf-lsvr-bgp-spf]; but should be generally usable by other 157 routing protocols, e.g. EVPN, and in other similar environments. 159 The IETF is very good at finding corner cases which expand needs and 160 complicate protocols. This effort should resist this tendency. 162 It would be easiest for the BGP-like protocols to consume the data if 163 they are presented via the BGP-LS [RFC7752] API as used in 164 [I-D.ietf-lsvr-bgp-spf] Section 4. 166 BGP-like protocols will need at least the following information about 167 the topology: 169 Node Identity: Each node in the topology must have an identity/ 170 identifier which must be unique in the topology. 172 A node must have one or more links to other nodes or it is, ab 173 definito, not in the topology. 175 A node has IP layer 3 attributes such as encapsulations and IP 176 addresses. 178 Link Identity: A link is between two nodes. Each end of a link is a 179 node/device interface. 181 Each link in the topology must be uniquely identified and the 182 identities of the nodes on the link must be identified. This 183 includes LAGged links. 185 As MAC addresses are not unique in actual deployment, they may not 186 be assumed to uniquely identify a link. Multiple VLANs between a 187 port pair on two devices are a simple example of this. Link 188 Aggregation Groups (LAGs), Multi-Chassis LAGs etc. must be 189 accommodated. 191 A link might be on a tunnel interface; though the tunnel type may 192 be restricted.. 194 Link Liveness: Because adjacencies and topology changes must be 195 quickly detected, The stability of each link should be able to be 196 monitored and reported. As this can be noisy, it must be able to 197 be tuned by the operator, and expensive operations should be 198 minimized. 200 Encapsulations: The encapsulation(s) (IPv4, IPv6, ...) on each link 201 must be known. One or more of the common AFI/SAFIs must be 202 supported on each link, IPv4, IPv6, MPLS, etc. 204 It is assumed that the set of encapsulations is the same across 205 the entire topology. 207 Addresses: The available addresses on the node interfaces for each 208 encapsulation must be known. More than one address for an 209 encapsulation type must be supported. 211 As BGP-like protocols will be peering between the nodes, there may 212 be a preferred encapsulation and address on an link, or a loopback 213 interface may be used. 215 Upper Layer Protocol Parameters To facilitate peering of upper layer 216 protocols across a link, e.g. BGP, the protocol should support 217 signaling of the parameters for these protocols, e.g. peer AS 218 number, peering address(es), etc. 220 Mobility: Fast detection of [micro-]service mobility must be 221 supported. 223 EVPNs: EVPN end-point discovery must be supported. 225 4. Security Considerations 227 While this document has no security considerations per se, it does 228 make a plea for securability in protocol design. 230 Mis-wires, malicious devices being plugged into ports, and monkey in 231 the middle attacks should be considered. 233 There should at least be assurance that the end-point a device opened 234 a session with six months ago is the same one sending PDUs today. 236 5. IANA Considerations 238 This document has no IANA considerations. 240 6. Acknowledgments 242 The authors thank Victor Kuarsingh and Gunter Van De Velde for 243 reviews. 245 7. References 247 7.1. Normative References 249 [I-D.ietf-lsvr-bgp-spf] 250 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, 251 "Shortest Path Routing Extensions for BGP Protocol", 252 draft-ietf-lsvr-bgp-spf-06 (work in progress), September 253 2019. 255 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 256 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 257 DOI 10.17487/RFC4271, January 2006, 258 . 260 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 261 S. Ray, "North-Bound Distribution of Link-State and 262 Traffic Engineering (TE) Information Using BGP", RFC 7752, 263 DOI 10.17487/RFC7752, March 2016, 264 . 266 7.2. Informative References 268 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 269 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 270 . 272 Authors' Addresses 274 Randy Bush 275 Arrcus & IIJ 276 5147 Crystal Springs 277 Bainbridge Island, WA 98110 278 United States of America 280 Email: randy@psg.com 281 Keyur Patel 282 Arrcus 283 2077 Gateway Place, Suite 400 284 San Jose, CA 95119 285 United States of America 287 Email: keyur@arrcus.com