idnits 2.17.1 draft-ymbk-lsvr-discovery-req-01.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 (September 1, 2018) is 2036 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-02 ** 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: March 5, 2019 Arrcus 6 September 1, 2018 8 BGP Topology Discovery Requirements 9 draft-ymbk-lsvr-discovery-req-01 11 Abstract 13 For wide scale routing protocols to build their topology and 14 reachability databases they need link neighbor discovery, link 15 encapsulation data, and layer two liveness. BGP-LS and its 16 enhancements provide an API to present much of these data to BGP 17 protocols, but do not actually collect these data. This document 18 explores the needs and criteria for the data needed. 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 https://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 March 5, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 (https://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 2. Architectural Considerations . . . . . . . . . . . . . . . . 2 56 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 7.2. Informative References . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 In a massive scale datacenter or similar environment BGP([RFC4271]) 68 and BGP-like protocols, e.g. BGP-SPF (see [I-D.ietf-lsvr-bgp-spf]), 69 provide massive scale-out without centralization using a tried and 70 tested scalable distributed control plane transport, offering a 71 scalable routing solution. But BGP4 and BGP-SPF need topology 72 discovery, link state liveness, and link addressing data from the 73 network to build and maintain the routing topology. 75 BGP-LS [RFC7752] and its extensions provide an API which BGP4 and 76 BGP-SPF can use to get the and distribute topology data. But BGP-LS 77 itself does not gather the data, it merely presents it. So the 78 topology data must be gathered. 80 What topology data do BGP-like protocols actually need? What level 81 of freshness is needed? What are the requirements for scale, 82 extensibility, security, etc? 84 2. Architectural Considerations 86 Massive Data Centers (MDCs) have on the order of 10,000 racks, often 87 with two Top Of Rack (TOR) devices per rack. To provide this level 88 of scaling reliably, stably, and securely imposes architectural 89 constraints on any discovery protocol. 91 o Simple - If it isn't simple, it will not scale. Simplicity 92 requires restraint in design. 'Union Protocols' which are the sum 93 of everyone's desires are complex disasters waiting to happen. 94 Often they do not wait. Prefer 'Intersection Protocols' which 95 include only those things which everyone absolutely needs. 97 o Securable - Security properties should be analysed. Again, 98 simplicity is key; complex protocols increase in complexity over 99 time, and security vulnerabilities increase exponentially with 100 complexity. As [RFC5218] 2.2.3 says "The more successful a 101 protocol becomes, the more attractive a target it will be." 103 o Extensible - As [RFC5218] Section 2.2.1 said, successful protocols 104 are extensible beyond the original expectation. MDC and similar 105 needs are expanding and we are still learning about the space. 106 Simplicity and extensibility should go a long way to adaptability; 107 complex protocols are hard to extend, especially when they are 108 poorly understood. 110 o Implementable - It must be reasonably easy to implement and 111 deploy. Some implications are: 113 * Packet formats should be easy to generate and easily parsable. 114 Type/length/Value (TLV) formats are preferred. 116 * The protocols should be free to use and deploy; i.e. not be 117 constrained by Intellectual Property Right (IPR) claims. 119 * Again, simpler protocols are simpler to implement, deploy, 120 measure, monitor, etc. 122 * Performance Problems arise if the protocol was not designed to 123 scale. 125 o Protocol Control - It is mandatory that the IETF have full control 126 over the protocol definition. This should not preclude 127 cooperation with other Standards Development Organisations (SDOs); 128 but the final control must rest with the IETF. 130 3. Requirements 132 The target for the discovery protocol(s) is a massive datacenter 133 scale deployment using BGP or similar routing, e.g. BGP4 or 134 [I-D.ietf-lsvr-bgp-spf]; but should be generally usable by other 135 routing protocols in other environments. 137 The IETF is very good at finding corner cases which expand needs and 138 complicate protocols. This effort should resist this tendency. 140 It would be easiest for the BGP-like protocols to consume the data if 141 they are presented via the BGP-LS [RFC7752] API as used in 142 [I-D.ietf-lsvr-bgp-spf] Section 4. 144 BGP-like protocols will need at least the following information about 145 the topology: 147 Node Identity: Each node in the topology must have an identity/ 148 identifier which must be unique in the topology. 150 A node must have one or more links to other nodes or it is, ab 151 definito, not in the topology. 153 Link Identity: A link is between two nodes. Each end of a link is a 154 node/device interface. 156 Each link in the topology must be uniquely identified and the 157 identities of the nodes on the link must be identified. 159 L2 Liveness: Because adjacencies and topology changes must be 160 quickly detected, Layer-2 stability of each link should be 161 monitored and reported. 163 Encapsulations: The encapsulation(s) (IPv4, IPv6, ...) on each link 164 must be known. One or more of the common AFI/SAFIs must be 165 supported on each link, IPv4, IPv6, MPLS, etc. 167 It is assumed that the set of encapsulations is the same across 168 the entire topology. 170 Addresses: The available addresses on the node interfaces for each 171 encapsulation must be known. More than one address for an 172 encapsulation must be supported. 174 As BGP-like protocols will be peering between the nodes, there may 175 be a preferred encapsulation and address on an link, or a loopback 176 interface may be used. 178 4. Security Considerations 180 While this document has no security considerations per se, it does 181 make a plea for securability in protocol design. 183 Mis-wires, malicious devices being plugged into ports, and monkey in 184 the middle attacks should be considered. 186 5. IANA Considerations 188 This document has no IANA considerations. 190 6. Acknowledgments 192 The authors thank Victor Kuarsingh and Gunter Van De Velde for 193 reviews. 195 7. References 197 7.1. Normative References 199 [I-D.ietf-lsvr-bgp-spf] 200 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, 201 "Shortest Path Routing Extensions for BGP Protocol", 202 draft-ietf-lsvr-bgp-spf-02 (work in progress), August 203 2018. 205 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 206 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 207 DOI 10.17487/RFC4271, January 2006, 208 . 210 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 211 S. Ray, "North-Bound Distribution of Link-State and 212 Traffic Engineering (TE) Information Using BGP", RFC 7752, 213 DOI 10.17487/RFC7752, March 2016, 214 . 216 7.2. Informative References 218 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 219 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 220 . 222 Authors' Addresses 224 Randy Bush 225 Arrcus & IIJ 226 5147 Crystal Springs 227 Bainbridge Island, WA 98110 228 United States of America 230 Email: randy@psg.com 231 Keyur Patel 232 Arrcus 233 2077 Gateway Place, Suite #250 234 San Jose, CA 95119 235 United States of America 237 Email: keyur@arrcus.com