idnits 2.17.1 draft-wei-rift-applicability-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 19, 2019) is 1763 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 (-21) exists of draft-ietf-rift-rift-05 == Outdated reference: A later version (-04) exists of draft-white-distoptflood-00 ** Downref: Normative reference to an Informational draft: draft-white-distoptflood (ref. 'I-D.white-distoptflood') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589-Second-Edition' -- Possible downref: Non-RFC (?) normative reference: ref. 'TR-384' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RIFT WG Yuehua. Wei 3 Internet-Draft Zheng. Zhang 4 Intended status: Standards Track ZTE Corporation 5 Expires: December 21, 2019 Dmitry. Afanasiev 6 Yandex 7 Tom. Verhaeg 8 Interconnect Services B.V. 9 Jaroslaw. Kowalczyk 10 Orange Polska 11 June 19, 2019 13 RIFT Applicability 14 draft-wei-rift-applicability-01 16 Abstract 18 This document discusses the properties and applicability of RIFT in 19 different network topologies. It intends to provide a rough guide 20 how RIFT can be deployed to simplify routing operations in Clos 21 topologies and their variations. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 21, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Problem statement of a Fat Tree network in modern IP fabric . 2 59 3. Why ritf is chosen to address this use case . . . . . . . . . 3 60 3.1. Overview of RIFT . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Applicable Topologies . . . . . . . . . . . . . . . . . . 5 62 3.2.1. Horizontal Links . . . . . . . . . . . . . . . . . . 5 63 3.2.2. Vertical Shortcuts . . . . . . . . . . . . . . . . . 6 64 3.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3.1. DC Fabrics . . . . . . . . . . . . . . . . . . . . . 6 66 3.3.2. Metro Fabrics . . . . . . . . . . . . . . . . . . . . 6 67 3.3.3. Building Cabling . . . . . . . . . . . . . . . . . . 6 68 3.3.4. Internal Router Switching Fabrics . . . . . . . . . . 7 69 3.3.5. CloudCO . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Operational Simplifications and Considerations . . . . . . . 9 71 4.1. Automatic Disaggregation . . . . . . . . . . . . . . . . 10 72 4.1.1. South reflection . . . . . . . . . . . . . . . . . . 10 73 4.1.2. Suboptimal routing upon link failure use case . . . . 10 74 4.1.3. Black-holing upon link failure use case . . . . . . . 12 75 4.2. Usage of ZTP . . . . . . . . . . . . . . . . . . . . . . 13 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7. Normative References . . . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 This document intends to explain the properties and applicability of 84 RIFT [I-D.ietf-rift-rift] in different deployment scenarios and 85 highlight the operational simplicity of the technology compared to 86 traditional routing solutions. 88 2. Problem statement of a Fat Tree network in modern IP fabric 90 Clos and Fat-Tree topologies have gained prominence in today's 91 networking, primarily as result of the paradigm shift towards a 92 centralized data-center based architecture that is poised to deliver 93 a majority of computation and storage services in the future. 95 Today's current routing protocols were geared towards a network with 96 an irregular topology and low degree of connectivity originally. 97 When they are applied to Fat-Tree topologies: 99 o There are always extensive configuration or provisioning during 100 bring up and re-dimensioning. 102 o Both the spine node and the leaf node have the entire network 103 topology and routing information, but in fact, the leaf node does 104 not need so much complete information. 106 o There is significant Link State PDUs (LSPs) flooding duplication 107 between spine nodes and leaf nodes during network bring up and 108 topology update. It consumes both spine and leaf nodes' CPU and 109 link bandwidth resources. 111 o When a spine node advertises a topology change, every leaf node 112 connected to it will flood the update to all the other spine 113 nodes, and those spine nodes will further flood them to all the 114 leaf nodes, causing a O(n^2) flooding storm which is largely 115 redundant. 117 3. Why ritf is chosen to address this use case 119 Further content of this document assumes that the reader is familiar 120 with the terms and concepts used in OSPF [RFC2328] and IS-IS 121 [ISO10589-Second-Edition] link-state protocols and at least the 122 sections of RIFT [I-D.ietf-rift-rift] outlining the requirement of 123 routing in IP fabrics and RIFT protocol concepts. 125 3.1. Overview of RIFT 127 RIFT is a dynamic routing protocol for Clos and fat-tree network 128 topologies. It defines a link-state protocol when "pointing north" 129 and path-vector protocol when "pointing south". 131 It floods flat link-state information northbound only so that each 132 level obtains the full topology of levels south of it. That 133 information is never flooded East-West or back South again. So a top 134 tier node has full set of prefixes from the SPF calculation. 136 In the southbound direction the protocol operates like a "fully 137 summarizing, unidirectional" path vector protocol or rather a 138 distance vector with implicit split horizon whereas the information 139 propagates one hop south and is 're-advertised' by nodes at next 140 lower level, normally just the default route. 142 +-----------+ +-----------+ 143 | ToF | | ToF | LEVEL 2 144 + +-----+--+--+ +-+--+------+ 145 | | | | | | | | | ^ 146 + | | | +-------------------------+ | 147 Distance | +-------------------+ | | | | | 148 Vector | | | | | | | | + 149 South | | | | +--------+ | | | Link+State 150 + | | | | | | | | Flooding 151 | | | +-------------+ | | | North 152 v | | | | | | | | + 153 +-+--+-+ +------+ +-------+ +--+--+-+ | 154 |SPINE | |SPINE | | SPINE | | SPINE | | LEVEL 1 155 + ++----++ ++---+-+ +--+--+-+ ++----+-+ | 156 + | | | | | | | | | ^N 157 Distance | +-------+ | | +--------+ | | | E 158 Vector | | | | | | | | | +------> 159 South | +-------+ | | | +-------+ | | | | 160 + | | | | | | | | | + 161 v ++--++ +-+-++ ++-+-+ +-+--++ + 162 |LEAF| |LEAF| |LEAF| |LEAF | LEVEL 0 163 +----+ +----+ +----+ +-----+ 165 Figure 1: Rift overview 167 A middle tier node has only information necessary for its level, 168 which are all destinations south of the node based on SPF 169 calculation, default route and potential disaggregated routes. 171 RIFT combines the advantage of both Link-State and Distance Vector: 173 o Fastest Possible Convergence 175 o Automatic Detection of Topology 177 o Minimal Routes/Info on TORs 179 o High Degree of ECMP 181 o Fast De-commissioning of Nodes 183 o Maximum Propagation Speed with Flexible Prefixes in an Update 185 And RIFT eliminates the disadvantages of Link-State or Distance 186 Vector: 188 o Reduced and Balanced Flooding 189 o Automatic Neighbor Detection 191 So there are two types of link state database which are "north 192 representation" N-TIEs and "south representation" S-TIEs. The N-TIEs 193 contain a link state topology description of lower levels and S-TIEs 194 carry simply default routes for the lower levels. 196 There are a bunch of more advantages unique to RIFT listed below 197 which could be understood if you read the details of RIFT 198 [I-D.ietf-rift-rift]. 200 o True ZTP 202 o Minimal Blast Radius on Failures 204 o Can Utilize All Paths Through Fabric Without Looping 206 o Automatic Disaggregation on Failures 208 o Simple Leaf Implementation that Can Scale Down to Servers 210 o Key-Value Store 212 o Horizontal Links Used for Protection Only 214 o Supports Non-Equal Cost Multipath and Can Replace MC-LAG 216 o Optimal Flooding Reduction and Load-Balancing 218 3.2. Applicable Topologies 220 Albeit RIFT is specified primarily for "proper" Clos or "fat-tree" 221 structures, it already supports PoD concepts which are strictly 222 speaking not found in original Clos concepts. 224 Further, the specification explains and supports operations of multi- 225 plane Clos variants where the protocol relies on set of rings to 226 allow the reconciliation of topology view of different planes as most 227 desirable solution making proper disaggregation viable in case of 228 failures. This observations hold not only in case of RIFT but in the 229 generic case of dynamic routing on Clos variants with multiple planes 230 and failures in bi-sectional bandwidth, especially on the leafs. 232 3.2.1. Horizontal Links 234 RIFT is not limited to pure Clos divided into PoD and multi-planes 235 but supports horizontal links below the top of fabric level. Those 236 links are used however only as routes of last resort when a spine 237 loses all northbound links or cannot compute a default route through 238 them. 240 3.2.2. Vertical Shortcuts 242 Through relaxations of the specified adjacency forming rules RIFT 243 implementations can be extended to support vertical "shortcuts" as 244 proposed by e.g. [I-D.white-distoptflood]. The RIFT specification 245 itself does not provide the exact details since the resulting 246 solution suffers from either much larger blast radii with increased 247 flooding volumes or in case of maximum aggregation routing bow-tie 248 problems. 250 3.3. Use Cases 252 3.3.1. DC Fabrics 254 RIFT is largely driven by demands and hence ideally suited for 255 application in underlay of data center IP fabrics, vast majority of 256 which seem to be currently (and for the foreseeable future) Clos 257 architectures. It significantly simplifies operation and deployment 258 of such fabrics as described in Section 4 for environments compared 259 to extensive proprietary provisioning and operational solutions. 261 3.3.2. Metro Fabrics 263 The demand for bandwidth is increasing steadily, driven primarily by 264 environments close to content producers (server farms connection via 265 DC fabrics) but in proximity to content consumers as well. Consumers 266 are often clustered in metro areas with their own network 267 architectures that can benefit from simplified, regular Clos 268 structures and hence RIFT. 270 3.3.3. Building Cabling 272 Commercial edifices are often cabled in topologies that are either 273 Clos or its isomorphic equivalents. With many floors the Clos can 274 grow rather high and with that present a challenge for traditional 275 routing protocols (except BGP and by now largely phased-out PNNI) 276 which do not support an arbitrary number of levels which RIFT does 277 naturally. Moreover, due to limited sizes of forwarding tables in 278 active elements of building cabling the minimum FIB size RIFT 279 maintains under normal conditions can prove particularly cost- 280 effective in terms of hardware and operational costs. 282 3.3.4. Internal Router Switching Fabrics 284 It is common in high-speed communications switching and routing 285 devices to use fabrics when a crossbar is not feasible due to cost, 286 head-of-line blocking or size trade-offs. Normally such fabrics are 287 not self-healing or rely on 1:/+1 protection schemes but it is 288 conceivable to use RIFT to operate Clos fabrics that can deal 289 effectively with interconnections or subsystem failures in such 290 module. RIFT is neither IP specific and hence any link addressing 291 connecting internal device subnets is conceivable. 293 3.3.5. CloudCO 295 The Cloud Central Office (CloudCO) is a new stage of telecom Central 296 Office. It takes the advantage of Software Defined Networking (SDN) 297 and Network Function Virtualization (NFV) in conjunction with general 298 purpose hardware to optimize current networks. The following figure 299 illustrates this architecture at a high level. It describes a single 300 instance or macro-node of cloud CO. An Access I/O module faces a 301 Cloud CO Access Node, and the CPEs behind it. A Network I/O module 302 is facing the core network. The two I/O modules are interconnected 303 by a leaf and spine fabric. [TR-384] 304 +---------------------+ +----------------------+ 305 | Spine | | Spine | 306 | Switch | | Switch | 307 +------+---+------+-+-+ +--+-+-+-+-----+-------+ 308 | | | | | | | | | | | | 309 | | | | | +-------------------------------+ | 310 | | | | | | | | | | | | 311 | | | | +-------------------------+ | | | 312 | | | | | | | | | | | | 313 | | +----------------------+ | | | | | | | | 314 | | | | | | | | | | | | 315 | +---------------------------------+ | | | | | | | 316 | | | | | | | | | | | | 317 | | | +-----------------------------+ | | | | | 318 | | | | | | | | | | | | 319 | | | | | +--------------------+ | | | | 320 | | | | | | | | | | | | 321 | | | | | | | | | | | | 322 +--+ +-+---+--+ +-+---+--+ +--+----+--+ +-+--+--+ +--+ 323 |L | | Leaf | | Leaf | | Leaf | | Leaf | |L | 324 |S | | Switch | | Switch | | Switch | | Switch| |S | 325 ++-+ +-+-+-+--+ +-+-+-+--+ +--+-+--+--+ ++-+--+-+ +-++ 326 | | | | | | | | | | | | | | 327 | +-+-+-+--+ +-+-+-+--+ +--+-+--+--+ ++-+--+-+ | 328 | |Compute | |Compute | | Compute | |Compute| | 329 | |Node | |Node | | Node | |Node | | 330 | | | | | | | | | | 331 | +--------+ +--------+ +----------+ +-------+ | 332 | || VAS5 || || vDHCP|| || vRouter|| ||VAS1 || | 333 | |--------| |--------| |----------| |-------| | 334 | |--------| |--------| |----------| |-------| | 335 | || VAS6 || || VAS3 || || v802.1x|| ||VAS2 || | 336 | |--------| |--------| |----------| |-------| | 337 | |--------| |--------| |----------| |-------| | 338 | || VAS7 || || VAS4 || || vIGMP || ||BAA || | 339 | |--------| |--------| |----------| |-------| | 340 | +--------+ +--------+ +----------+ +-------+ | 341 | | 342 ++-----------+ +---------++ 343 |Network I/O | |Access I/O| 344 +------------+ +----------+ 346 Figure 2: An example of CloudCo architecture 348 The Spine-Leaf architectures deployed inside CloudCO meets the 349 network requirements of adaptable, agile, scalable and dynamic. 351 4. Operational Simplifications and Considerations 353 RIFT presents the opportunity for organizations building and 354 operating IP fabrics to simplify their operation and deployments 355 while achieving many desirable properties of a dynamic routing on 356 such a substrate: 358 o RIFT design follows minimum blast radius and minimum necessary 359 epistemological scope philosophy which leads to very good scaling 360 properties while delivering maximum reactiveness. 362 o RIFT allows for extensive Zero Touch Provisioning within the 363 protocol. In its most extreme version RIFT does not rely on any 364 specific addressing and for IP fabric can operate using IPv6 ND 365 [RFC4861] only. 367 o RIFT has provisions to detect common IP fabric mis-cabling 368 scenarios. 370 o RIFT negotiates automatically BFD per link allowing this way for 371 IP and micro-BFD [RFC7130] to replace LAGs which do hide bandwidth 372 imbalances in case of constituent failures. Further automatic 373 link validation techniques similar to [RFC5357] could be supported 374 as well. 376 o RIFT inherently solves many difficult problems associated with the 377 use of traditional routing topologies with dense meshes and high 378 degrees of ECMP by including automatic bandwidth balancing, flood 379 reduction and automatic disaggregation on failures while providing 380 maximum aggregation of prefixes in default scenarios. 382 o RIFT reduces FIB size towards the bottom of the IP fabric where 383 most nodes reside and allows with that for cheaper hardware on the 384 edges and introduction of modern IP fabric architectures that 385 encompass e.g. server multi-homing. 387 o RIFT provides valley-free routing and with that is loop free. 388 This allows the use of any such valley-free path in bi-sectional 389 fabric bandwidth between two destination irrespective of their 390 metrics which can be used to balance load on the fabric in 391 different ways. 393 o RIFT includes a key-value distribution mechanism which allows for 394 many future applications such as automatic provisioning of basic 395 overlay services or automatic key roll-overs over whole fabrics. 397 o RIFT is designed for minimum delay in case of prefix mobility on 398 the fabric. 400 o Many further operational and design points collected over many 401 years of routing protocol deployments have been incorporated in 402 RIFT such as fast flooding rates, protection of information 403 lifetimes and operationally easily recognizable remote ends of 404 links and node names. 406 4.1. Automatic Disaggregation 408 4.1.1. South reflection 410 South reflection is a mechanism that South Node TIEs are "reflected" 411 back up north to allow nodes in same level without E-W links to "see" 412 each other. 414 For example, Spine111\Spine112\Spine121\Spine122 reflects Node S-TIEs 415 from ToF21 to ToF22 separately. Spine111\Spine112\Spine121\Spine122 416 reflects Node S-TIEs from ToF22 to ToF21 separately. So ToF22 and 417 ToF21 knows each other as level 2 node. 419 As the result of the south reflection between 420 Spine121-Leaf121-Spine122 and Spine121-Leaf122-Spine122, Spine121 and 421 Spine 122 knows each other at level 1. 423 This is a use case to explain the deployment of a Fat-Tree and the 424 algorithm to achieve automatic disaggregation. 426 4.1.2. Suboptimal routing upon link failure use case 427 +--------+ +--------+ 428 | | | | 429 | ToF21 | | ToF22 | LEVEL 2 430 ++-+--+-++ ++-+--+-++ 431 | | | | | | | | 432 | | | | | | | linkTS8 433 | | | | | | | | 434 | | | | | | | | 435 +--------------+ | +--linkTS3--+ | | | +--------------+ 436 | | | | | | | | 437 | +-----------------------------+ | linkTS7 | 438 | | | | | | | | 439 | | | +--------linkTS4-------------+ | 440 | | | | | | | | 441 | | +-+ +---------------+ | | 442 | | | | | linkTS6 | | 443 +-+----++ +-+-----+ ++----+-+ ++-----++ 444 | | | | | | | | 445 |Spin111| |Spin112| |Spin121| |Spin122| LEVEL 1 446 +-+---+-+ ++----+-+ +-+---+-+ ++---+--+ 447 | | | | | | | | 448 | +---------------+ | | +-XX-linkSL6----+ | 449 | | | | linkSL5 | | linkSL8 450 | +-------------+ | | | +----linkSL7--+ | | 451 | | | | | | | | 452 +-+---+-+ +--+--+-+ +-+---+-+ +--+-+--+ 453 | | | | | | | | 454 |Leaf111| |Leaf112| |Leaf121| |Leaf122| LEVEL 0 455 +-+-----+ ++------+ +-----+-+ +-+-----+ 456 + + + + 457 Prefix111 Prefix112 Prefix121 Prefix122 459 Figure 3: Suboptimal routing upon link failure use case 461 As shown in figure above, as the result of the south reflection 462 between Spine121-Leaf121-Spine122 and Spine121-Leaf122-Spine122, 463 Spine121 and Spine 122 knows each other at level 1. 465 Without disaggregation mechanism, when linkSL6 fails, the packet from 466 leaf121 to prefix122 will probably go up through linkSL5 to linkTS3 467 then go down through linkTS4 to linkSL8 to Leaf122 or go up through 468 linkSL5 to linkTS6 then go down through linkTS4 and linkSL8 to 469 Leaf122 based on pure default route. It's the case of suboptimal 470 routing. 472 With disaggregation mechanism, when linkSL6 fails, Spine122 will 473 detect the failure according to the reflected node S-TIE from 474 Spine121. Based on the disaggregation algorithm provided by RITF, 475 Spine122 will explicitly advertise prefix122 in Prefix S-TIE 476 SouthPrefixesElement(prefix122, cost 1). The packet from leaf121 to 477 prefix122 will only be sent to linkSL7 following a longest-prefix 478 match to prefix 122 directly then go down through linkSL8 to Leaf122 479 . 481 4.1.3. Black-holing upon link failure use case 483 +--------+ +--------+ 484 | | | | 485 | ToF 21 | | ToF 22 | LEVEL 2 486 ++-+--+-++ ++-+--+-++ 487 | | | | | | | | 488 | | | | | | | linkTS8 489 | | | | | | | | 490 | | | | | | | | 491 +--------------+ | +--linkTS3-X+ | | | +--------------+ 492 linkTS1 | | | | | | | 493 | +-----------------------------+ | linkTS7 | 494 | | | | | | | | 495 | | linkTS2 +--------linkTS4-X-----------+ | 496 | | | | | | | | 497 | linkTS5 +-+ +---------------+ | | 498 | | | | | linkTS6 | | 499 +-+----++ +-+-----+ ++----+-+ ++-----++ 500 | | | | | | | | 501 |Spin111| |Spin112| |Spin121| |Spin122| LEVEL 1 502 +-+---+-+ ++----+-+ +-+---+-+ ++---+--+ 503 | | | | | | | | 504 | +---------------+ | | +----linkSL6----+ | 505 linkSL1 | | | linkSL5 | | linkSL8 506 | +---linkSL3---+ | | | +----linkSL7--+ | | 507 | | | | | | | | 508 +-+---+-+ +--+--+-+ +-+---+-+ +--+-+--+ 509 | | | | | | | | 510 |Leaf111| |Leaf112| |Leaf121| |Leaf122| LEVEL 0 511 +-+-----+ ++------+ +-----+-+ +-+-----+ 512 + + + + 513 Prefix111 Prefix112 Prefix121 Prefix122 515 Figure 4: Black-holing upon link failure use case 517 This scenario illustrates a case when double link failure occurs, 518 black-holing happens. 520 Without disaggregation mechanism, when linkTS3 and linkTS4 both fail, 521 the packet from leaf111 to prefix122 would suffer 50% black-holing 522 based on pure default route. The packet supposed to go up through 523 linkSL1 to linkTS1 then go down through linkTS3 or linkTS4 will be 524 dropped. The packet supposed to go up through linkSL3 to linkTS2 525 then go down through linkTS3 or linkTS4 will be dropped as well. 526 It's the case of black-holing. 528 With disaggregation mechanism, when linkTS3 and linkTS4 both fail, 529 ToF22 will detect the failure according to the reflected node S-TIE 530 of ToF21 from Spine111\Spine112\Spine121\Spine122. Based on the 531 disaggregation algorithm provided by RITF, ToF22 will explicitly 532 originate an S-TIE with prefix 121 and prefix 122, that is flooded to 533 spines 111, 112, 121 and 122. 535 The packet from leaf111 to prefix122 will not be routed to linkTS1 or 536 linkTS2. The packet from leaf111 to prefix122 will only be routed to 537 linkTS5 or linkTS7 following a longest-prefix match to prefix122. 539 4.2. Usage of ZTP 541 Each RIFT node may operate in zero touch provisioning (ZTP) mode. It 542 has no configuration (unless it is a Top-of-Fabric at the top of the 543 topology or the must operate in the topology as leaf and/or support 544 leaf-2-leaf procedures) and it will fully configure itself after 545 being attached to the topology. 547 The most import component for ZTP is the automatic level derivation 548 procedure. All the Top-of-Fabric nodes are explicitly marked with 549 TOP_OF_FABRIC flag which are initial 'seeds' needed for other ZTP 550 nodes to derive their level in the topology. 552 The derivation of the level of each node happens based on LIEs 553 received from its neighbors whereas each node (with possibly 554 exceptions of configured leafs) tries to attach at the highest 555 possible point in the fabric. 557 This guarantees that even if the diffusion front reaches a node from 558 "below" faster than from "above", it will greedily abandon already 559 negotiated level derived from nodes topologically below it and 560 properly peers with nodes above. 562 5. Acknowledgements 564 6. Contributors 566 The following people (listed in alphabetical order) contributed 567 significantly to the content of this document and should be 568 considered co-authors: 570 Tony Przygienda 571 Juniper Networks 573 1194 N. Mathilda Ave 575 Sunnyvale, CA 94089 577 US 579 Email: prz@juniper.net 581 7. Normative References 583 [I-D.ietf-rift-rift] 584 Team, T., "RIFT: Routing in Fat Trees", draft-ietf-rift- 585 rift-05 (work in progress), April 2019. 587 [I-D.white-distoptflood] 588 White, R. and S. Zandi, "IS-IS Optimal Distributed 589 Flooding for Dense Topologies", draft-white- 590 distoptflood-00 (work in progress), March 2019. 592 [ISO10589-Second-Edition] 593 International Organization for Standardization, 594 "Intermediate system to Intermediate system intra-domain 595 routeing information exchange protocol for use in 596 conjunction with the protocol for providing the 597 connectionless-mode Network Service (ISO 8473)", Nov 2002. 599 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 600 DOI 10.17487/RFC2328, April 1998, 601 . 603 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 604 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 605 DOI 10.17487/RFC4861, September 2007, 606 . 608 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 609 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 610 RFC 5357, DOI 10.17487/RFC5357, October 2008, 611 . 613 [RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., 614 Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional 615 Forwarding Detection (BFD) on Link Aggregation Group (LAG) 616 Interfaces", RFC 7130, DOI 10.17487/RFC7130, February 617 2014, . 619 [TR-384] Broadband Forum Technical Report, "TR-384 Cloud Central 620 Office Reference Architectural Framework", Jan 2018. 622 Authors' Addresses 624 Yuehua Wei 625 ZTE Corporation 626 No.50, Software Avenue 627 Nanjing 210012 628 P. R. China 630 Email: wei.yuehua@zte.com.cn 632 Zheng Zhang 633 ZTE Corporation 634 No.50, Software Avenue 635 Nanjing 210012 636 P. R. China 638 Email: zzhang_ietf@hotmail.com 640 Dmitry Afanasiev 641 Yandex 643 Email: fl0w@yandex-team.ru 645 Tom Verhaeg 646 Interconnect Services B.V. 648 Email: t.verhaeg@interconnect.nl 650 Jaroslaw Kowalczyk 651 Orange Polska 653 Email: jaroslaw.kowalczyk2@orange.com