idnits 2.17.1 draft-dt-rtgwg-dcrouting-requirements-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 : ---------------------------------------------------------------------------- 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 30, 2017) is 2364 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG J. Tantsura 3 Internet-Draft Individual 4 Intended status: Informational D. Afanasiev 5 Expires: May 3, 2018 YANDEX 6 K. Patel 7 Arccus 8 P. Lapukhov 9 Facebook 10 P. Przygienda 11 Juniper 12 R. White 13 LinkedIn 14 Y. Qu 15 Huawei 16 J. Uttaro 17 ATT 18 October 30, 2017 20 Requirements for the DataCenter Routing 21 draft-dt-rtgwg-dcrouting-requirements-00 23 Abstract 25 This document describes list of functional requirments towards a 26 Routing Protocol for Data Center Networks. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 3, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Recommended Reading . . . . . . . . . . . . . . . . . . . . . 3 65 4. Goals and Requirements . . . . . . . . . . . . . . . . . . . 3 66 5. For further study . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Network Topologies . . . . . . . . . . . . . . . . . . . . . 5 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 71 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 5 74 11.2. Informative References . . . . . . . . . . . . . . . . . 5 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 It is common to host and build a network of more than tens of 80 thousands of end points inside a data center. Data Center Networks 81 of such size have unique set of requirements with emphasis on scale, 82 convergence, network stability and opertional simplicity. Existing 83 or new set of protocols and routing infrastructure needs to be 84 augmented to support higher scale, faster convergence with increased 85 optional simplicity in order to address the requirements of these 86 networks. 88 This document describes list of functional requirements that are 89 required towards addressing scale, convergence and operational 90 maintainance of such scaled networks. The requirements described in 91 this document can be used to augment existing solutions or used to 92 design a new set of solutions. 94 2. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119] only when 99 they appear in all upper case. They may also appear in lower or 100 mixed case as English words, without any normative meaning. 102 3. Recommended Reading 104 This document assumes knowledge of existing data center networks and 105 data center network topologies [CLOS],[RFC7938]. This document also 106 assumes knowledge of data center routing protocols like BGP 107 [RFC4271], OSPF [RFC2328] and BFD [RFC5880] as well as data center 108 layer 2 link layer protocols like LLDP [RFC4957]. 110 4. Goals and Requirements 112 Following are general requirements for the Data Center Network Fabric 113 and its Routing Protocols: 115 o The Fabric provides basic connectivity, with possibility to carry 116 one or more overlays. 117 The Fabric provides no domain separation, if needed, to be handled 118 by an overlay. 119 The Fabric MAY provide interconnect facility for other fabrics. 120 The Fabric MUST support non equidistant end-points. 122 o The Fabric MUST support Spine and Leaf [CLOS] + isomorphic 123 topologies within its network. 124 The Fabric MAY support non Spine and Leaf topologies 126 o The KPI's below are single-dimensional and expected to be changed, 127 as the document progresses, baseded on more feedback, we ask 128 community to communicate their views. Combination of # of routes 129 vs # of paths vs desired convergence time will be discussed in a 130 later version. 132 The Fabric SHOULD support 250k routes @ 5k fabric nodes with 133 convergence time below 250ms. 134 The Fabric SHOULD support 500k routes @ 7.5k fabric nodes with 135 convergence time below 500ms. 136 The Fabric SHOULD support 1M routes @ 10k fabric nodes with 137 convergence time below 1s. 139 o The Fabric routing protocol MUST support load balancing using 140 ECMP, wECMP and UCMP. 142 The Fabric routing protocol MAY support any custom or adaptive 143 load balancing algorithms. 144 The Fabric routing protocol MUST support and provide facility for 145 topology-specific algorithms that enable correct operations in 146 that specific topology. 148 o The Fabric routing protocol SHOULD support route scale and 149 convergence times of a Fabric mentioned above. 150 The Fabric routing protocol SHOULD support ECMP as wide as 256 151 paths. 153 o The Fabric routing protocol MUST support various address families 154 that covers IP as well as MPLS forwarding. 155 The Fabric routing protocol MUST support extensions to carry 3rd 156 party data and Opaque data. 158 o The Fabric routing protocol MUST support Traffic Engineering paths 159 that are host and/or router based paths. 160 The Fabric routing protocol MUST provide facility to address 161 constituents in an ECMP bundle. 163 o The Fabric routing protocol MUST support inband as well as out of 164 band management. 166 o The Fabric routing protocol MUST support Zero Touch Provisioning 167 (ZTP). 168 The Fabric routing protocol MUST support Neighbor Discovery to 169 facilitate ZTP. 171 o The Fabric routing protocol MUST be able to leverage BFD [RFC5880] 172 for neighbor state. 173 The Fabric routing protocol SHOULD be capable of bootstrapping a 174 BFD session [RFC5882]. 176 o The Fabric routing protocol MUST be able to support real time 177 state notifications of routes and its neighbors state to 178 facilitate control plane telemetry. 179 The Fabric routing protocol MUST be able to support on-demand 180 snapshots of protocol state and real time state notifications of 181 routes and its neighbors state to remote node(s) to facilitate 182 control plane telemetry. 184 o The Fabric routing protocol MUST be able handle commission/ 185 decommission of a node as well as any node restart with a minimal 186 data plane impact. 188 5. For further study 190 Following topics have been identified to be studied at a later time: 192 o gRPC/THRIFT/similar encodings. 194 o Ability to function as an overlay. 196 o Flowlets signaling. 198 o Multicast. 200 o State representation NB. 202 o Integration with PCE/SDNc. 204 6. Network Topologies 206 7. IANA Considerations 208 8. Security Considerations 210 This document describes list of functional requirements towards a 211 routing protocol for Data Center Networks. It does not raise any 212 security concerns or issues in addition to ones common to a routing 213 protocol for Data Center Networks. 215 9. Acknowledgements 217 10. Change Log 219 Initial Version: October 31 2017 221 11. References 223 11.1. Normative References 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, 227 DOI 10.17487/RFC2119, March 1997, 228 . 230 11.2. Informative References 232 [CLOS] "A Study of Non-Blocking Switching Networks", The Bell 233 System Technical Journal, Vol. 32(2), DOI 234 10.1002/j.1538-7305.1953.tb01433.x, March 1953. 236 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 237 DOI 10.17487/RFC2328, April 1998, 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 [RFC4957] Krishnan, S., Ed., Montavont, N., Njedjou, E., Veerepalli, 246 S., and A. Yegin, Ed., "Link-Layer Event Notifications for 247 Detecting Network Attachments", RFC 4957, 248 DOI 10.17487/RFC4957, August 2007, 249 . 251 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 252 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 253 . 255 [RFC5882] Katz, D. and D. Ward, "Generic Application of 256 Bidirectional Forwarding Detection (BFD)", RFC 5882, 257 DOI 10.17487/RFC5882, June 2010, 258 . 260 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 261 BGP for Routing in Large-Scale Data Centers", RFC 7938, 262 DOI 10.17487/RFC7938, August 2016, 263 . 265 Authors' Addresses 267 Jeff Tantsura 268 Individual 269 USA 271 Email: jefftant.ietf@gmail.com 273 Dmitry Afanasiev 274 YANDEX 275 RU 277 Email: dmitry.afanasiev@gmail.com 278 Keyur Patel 279 Arccus 280 San Jose 281 USA 283 Email: keyur@arrcus.com 285 Petr Lapukhov 286 Facebook 287 USA 289 Email: petr@fb.com 291 Tony Przygienda 292 Juniper 293 1137 Innovation Way 294 Sunnyvale, CA 295 USA 297 Email: prz@juniper.net 299 Russ White 300 LinkedIn 301 USA 303 Email: russ@riw.us 305 Yingzhen Qu 306 Huawei 307 Santa Clara 308 USA 310 Email: yingzhen.ietf@gmail.com 312 Jim Uttaro 313 ATT 314 USA 316 Email: juttaro@ieee.org