idnits 2.17.1 draft-head-rift-auto-fr-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 : ---------------------------------------------------------------------------- ** 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.) ** There are 72 instances of too long lines in the document, the longest one being 50 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 560 has weird spacing: '...nceType aut...' == Line 597 has weird spacing: '...equired set<...' == Line 599 has weird spacing: '...equired comm...' -- The document date (29 December 2021) is 849 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 670 -- Looks like a reference, but probably isn't: '1' on line 671 -- Looks like a reference, but probably isn't: '2' on line 672 -- Looks like a reference, but probably isn't: '3' on line 673 -- Looks like a reference, but probably isn't: '4' on line 674 -- Looks like a reference, but probably isn't: '5' on line 674 -- Looks like a reference, but probably isn't: '6' on line 675 -- Looks like a reference, but probably isn't: '7' on line 675 == Unused Reference: 'RIFT-AUTO-EVPN' is defined on line 501, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-lsr-isis-flood-reflection-07 ** Downref: Normative reference to an Experimental draft: draft-ietf-lsr-isis-flood-reflection (ref. 'IS-IS-FR') == Outdated reference: A later version (-21) exists of draft-ietf-rift-rift-14 == Outdated reference: A later version (-07) exists of draft-ietf-rift-kv-registry-01 == Outdated reference: A later version (-05) exists of draft-ietf-rift-auto-evpn-01 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RIFT J. Head, Ed. 3 Internet-Draft T. Przygienda 4 Intended status: Standards Track C. Barth 5 Expires: 2 July 2022 Juniper Networks 6 29 December 2021 8 RIFT Auto-FR 9 draft-head-rift-auto-fr-00 11 Abstract 13 This document specifies procedures that allow IS-IS Flood Reflection 14 topologies to be fully and automatically provisioned when using RIFT 15 by leveraging RIFT's no-touch ZTP architecture. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 2 July 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 53 3. Auto-FR Device Roles . . . . . . . . . . . . . . . . . . . . 3 54 3.1. All Participating Nodes . . . . . . . . . . . . . . . . . 3 55 3.2. Flood Reflectors . . . . . . . . . . . . . . . . . . . . 4 56 3.3. Flood Reflectors Clients . . . . . . . . . . . . . . . . 4 57 4. Auto-FR Variable Derivation . . . . . . . . . . . . . . . . . 4 58 4.1. System ID . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Auto-FR Version . . . . . . . . . . . . . . . . . . . . . 5 60 4.3. Flood Reflector Cluster ID . . . . . . . . . . . . . . . 5 61 4.4. Loopback Address . . . . . . . . . . . . . . . . . . . . 5 62 4.4.1. Leaf Nodes as Flood Reflector Clients . . . . . . . . 6 63 4.4.2. ToF Nodes as Flood Reflectors . . . . . . . . . . . . 6 64 4.4.2.1. Flood Reflector Election Procedures . . . . . . . 6 65 5. Operational Considerations . . . . . . . . . . . . . . . . . 7 66 5.1. RIFT Underlay and IS-IS Flood Reflection Topology . . . . 7 67 5.2. Auto-FR Analytics . . . . . . . . . . . . . . . . . . . . 9 68 5.2.1. Auto-FR Global Analytics Key Type . . . . . . . . . . 10 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 8.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Thrift Models . . . . . . . . . . . . . . . . . . . 12 75 A.1. common.thrift . . . . . . . . . . . . . . . . . . . . . . 12 76 A.2. encoding.thrift . . . . . . . . . . . . . . . . . . . . . 12 77 A.3. auto_flood_reflection_kv.thrift . . . . . . . . . . . . . 13 78 Appendix B. Auto-FR Variable Derivation . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 IS-IS Flood Reflection [IS-IS-FR] is a mechanism that enables large 84 single-area Level 2 IS-IS networks to scale well beyond their typical 85 properties when deployed in Clos/Fat Tree topologies. 87 [RIFT] is a protocol that focuses heavily on operational simplicity. 88 It natively supports Zero Touch Provisioning (ZTP) functionality that 89 allows each node to automatically derive its place in the topology 90 and configure itself accordingly when properly cabled as a Clos, Fat 91 Tree, or other similarly structured variant. 93 This sense of topological hierarchy makes RIFT well-suited to 94 automatically provision IS-IS Flood Reflection with no additional 95 external interaction using its ZTP functionality. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 2. Design Considerations 105 IS-IS Flood Reflection operates using flood reflectors at the top of 106 the fabric and flood reflector clients at the bottom of the fabric. 107 Any nodes in the middle are not required to support flood reflection 108 functionality, nor do they need to support Auto-FR. 110 Nodes taking part in flood reflection require specific variables for 111 deployment. For example, a cluster ID that is unique to the 112 particular fabric or loopback addresses that are unique to a 113 particular node. RIFT has enough topological information to derive 114 these variables with the appropriate scope in a distributed fashion 115 automatically. 117 Once the Flood Reflection topology is built, RIFT Key-Value TIEs can 118 be used to distribute operational state information to allow for 119 basic validation without additional tooling. 121 3. Auto-FR Device Roles 123 Auto-FR requires that each node understands its given role within the 124 scope of the Flood Reflection deployment, so each node derives the 125 necessary variables and resulting configuration. 127 3.1. All Participating Nodes 129 Not all nodes have to participate in Auto-FR, however, if a node does 130 assume an Auto-FR role, it MUST derive the following variables: 132 *Flood Reflector Cluster ID* 133 The Flood Reflector Cluster ID us to distinguish reflection 134 domains, similar to that of a BGP Cluster ID for route 135 reflection. 137 *IPv6 Loopback Address* 138 Unique IPv6 loopback address. 140 *ISO System ID* 141 The ISO System Identifier used in IS-IS. 143 *ISO NET* 144 The ISO Network Entity Title used in IS-IS. 146 3.2. Flood Reflectors 148 This section defines an Auto-FR role whereby some Top-of-Fabric nodes 149 act as IS-IS flood reflectors. It is expected that flood reflectors 150 will establish Level 2 IS-IS adjacencies with flood reflector clients 151 in the same area in the same fabric. The typical flood reflector 152 requirements do not change, however, determining which specific 153 values to use requires further consideration. 155 ToF nodes performing flood reflector functionality MUST derive the 156 following variables: 158 *IPv6 Flood Reflector Loopback Address* 159 Unique IPv6 loopback address. 161 3.3. Flood Reflectors Clients 163 Although no specific variables for Flood Reflector Clients are 164 described at this time, the generic role is specified as a 165 placeholder for future enhancements. 167 *Future Consideration* 168 Future Consideration 170 4. Auto-FR Variable Derivation 172 As previously mentioned, not all nodes are required to derive all 173 variables in a network (e.g. a transit spine node may not need to 174 derive any or participate in Auto-FR at all). All variables are 175 derived from RIFT's FSM or ZTP mechanism, so no additional flooding 176 other than RIFT's typical flooding is necessary. 178 It is also important to mention that all variable derivation is in 179 some way based on System ID and/or Cluster ID and MUST comply 180 precisely with calculation methods specified in the Auto-FR Variable 181 Derivation section to allow interoperability between different 182 implementations. All foundational code elements are also mentioned 183 there. 185 4.1. System ID 187 The 64-bit RIFT System ID that uniquely identifies a node as defined 188 in [RIFT]. This not derived specifically for Auto-FR, but for all 189 RIFT nodes and is used in the derivation procedures described in this 190 section. 192 4.2. Auto-FR Version 194 This section describes extensions to both the RIFT LIE packet and 195 Node-TIE schemas in the form of a 16-bit value that identifies the 196 Auto-FR Version. Auto-FR capable nodes MUST support this extension, 197 but MAY choose not to advertise it in LIEs and Node-TIEs when Auto-FR 198 is not being utilized. 200 This section also describes an extension to the Node Capbilities 201 schema indicating whether a node supports Auto-FR. 203 Auto-FR Version MUST be considered in existing RIFT adjacency FSM 204 rules so that nodes that support Auto-FR can inter-operate with nodes 205 that do not. The LIE validation is extended with the following 206 clause: 208 (if auto_flood_reflection_version is not advertised by either node OR 209 if auto_flood_reflection_version is identical on both nodes) 211 Miscabling should be declared if this clause is not met. 213 The appendix (Appendix A) details necessary changes to the RIFT LIE, 214 Node-TIE, and Node Capabilities thrift schema. 216 4.3. Flood Reflector Cluster ID 218 This section describes extensions to both the RIFT LIE packet and 219 Node-TIE schemas in the form of a 32-bit value that identifies the 220 Auto-FR Cluster ID. Auto-FR capable nodes MUST support this 221 extension, but MAY choose not to advertise it in LIEs and Node-TIEs 222 when Auto-FR is not being utilized. 224 A Cluster ID with a value of 0 is considered invalid and MUST NOT be 225 used for any purpose. 227 The appendix (Appendix A) details necessary changes to the RIFT LIE 228 and Node-TIE thrift schema. 230 4.4. Loopback Address 232 Auto-FR nodes MUST derive a ULA-scoped IPv6 loopback address to be 233 used in IS-IS. Calculation is done using the 6-bytes of reserved ULA 234 space, the 4-byte Cluster ID and the node's 8-byte System ID. 235 Derivation of the System ID varies slightly depending upon the node's 236 location/role in the fabric and will be described in subsequent 237 sections. 239 4.4.1. Leaf Nodes as Flood Reflector Clients 241 Calculation is done using the 6-bytes of reserved ULA space, the 242 4-byte Cluster ID, and the node's 8-byte System ID. 244 In order for leaf nodes to derive IPv6 loopbacks, the following 245 algorithms are required - auto_fr_cidsidv6loopback (Figure 11) and 246 auto_fr_v6prefixcidsid2loopback (Figure 15). 248 IPv4 addresses MAY be supported, but it should be noted that they 249 have a higher likelihood of collision. The appendix contains the 250 required auto_fr_cidsid2v4loopback (Figure 10) algorithm to support 251 IPv4 loopback derivation. 253 4.4.2. ToF Nodes as Flood Reflectors 255 ToF nodes acting as flood reflectors MUST derive their loopback 256 address according to the specific section describing the algorithm. 257 Calculation is done using the 6-bytes of reserved ULA space, the 258 4-byte Cluster ID, and the 8-byte System ID of each elected route 259 reflector. 261 In order for ToF nodes to derive IPv6 loopbacks, the following 262 algorithms are required - auto_fr_cidsidv6loopback (Figure 11), 263 auto_fr_v6prefixcidsid2loopback (Figure 15), and 264 auto_fr_cidfrpref2frloopback (Figure 7). 266 IPv4 addresses MAY be supported, but it should be noted that they 267 have a higher likelihood of collision. The appendix contains the 268 required auto_fr_cidsid2v4loopback (Figure 10) algorithm to support 269 IPv4 loopback derivation. 271 A topology MUST elect at least 1 Top-of-Fabric node as an IS-IS flood 272 reflector, but SHOULD elect 3. 274 4.4.2.1. Flood Reflector Election Procedures 276 Each ToF performs the election independently based on system IDs of 277 other ToF nodes in the fabric obtained via southbound reflection. 278 The route reflector election procedures are defined as follows: 280 1. ToF node with the highest System ID. 282 2. ToF node with the lowest System ID. 284 3. ToF node with the 2nd highest System ID. 286 4. Etc. 288 This ordering is necessary to prevent a single node with either the 289 highest or lowest System ID from triggering changes to flood 290 reflector loopback addresses as it would result in all IS-IS 291 adjacencies flapping. 293 For example, if two nodes, ToF01 and ToF02 with System IDs 294 002c6af5a281c000 and 002c6bf5788fc000 respectively, ToF02 would be 295 elected due to it having the highest System ID of the ToFs 296 (002c6bf5788fc000). If a ToF determines that it is elected as flood 297 reflector, it uses the knowledge of its position in the list to 298 derive flood reflector IPv6 loopback address. 300 The algorithm shown in "auto_fr_sids2frs" (Figure 12) is required to 301 accomplish this. 303 5. Operational Considerations 305 To fully realize the benefits of Auto-FR, it may help to describe the 306 high-level method. Simply put, RIFT automatically provisions the 307 underlay and Auto-FR provisions the flood reflection topology. The 308 goal of this section is to draw simple lines between general fabric 309 concepts, RIFT, and Auto-FR and how they fit into current network 310 designs and practices. 312 This section also describes a set of optional Key-Value TIEs 313 [RIFT-KV] that leverages the variables that have already been derived 314 to provide further operational enhancement to the operator. 316 5.1. RIFT Underlay and IS-IS Flood Reflection Topology 317 +-----------------+ +-----------------+ 318 | ToF-01 | | ToF-02 | 319 | L1 / L2 | | L1 / L2 | ]----------------------+ 320 | Flood Reflector | | Flood Reflector | | 321 +-+--+------+--+--+ +-+--+------+--+--+ | 322 | | | | | | | | | 323 +---------------------+ | | | | | | | | 324 | | | | | | | +---------------------+ | 325 | +-----------)------)--)--------+ | | | | 326 | | | | | +-------+ | | | 327 | | | | | | | | | 328 | | | | +---)--------------)-----------+ | | 329 | | | | | | | | | 330 | | +--+ +------)----+ +--+ | | | 331 | | | | | | | | | 332 | | | +---+ | | | | | FR / FR Client 333 | | | | | | | | | IS-IS Level 2 334 +-+------------+-+ +-+------------+-+ +-+------------+-+ +-+------------+-+ | FR Adjacencies 335 | Spine-1-1 | | Spine-1-2 | | Spine-2-1 | | Spine-2-2 | | 336 | L1 | | L1 | | L1 | | L1 | | 337 | N/A | | N/A | | N/A | | N/A | | 338 +--+----------+--+ +--+----------+--+ +--+----------+--+ +--+----------+--+ | 339 | | | | | | | | | 340 | +----------)---+ | | +----------)---+ | | 341 | | | | | | | | | 342 | +----------+ | | | +----------+ | | | 343 | | | | | | | | | 344 +--+----------+--+ +------+------+--+ +--+----------+--+ +------+------+--+ | 345 | Leaf-1-1 | | Leaf-1-2 | | Leaf-2-1 | | Leaf-2-2 | | 346 | L1 / L2 | | L1 / L2 | | L1 / L2 | | L1 / L2 | ]-+ 347 | FR Client | | FR Client | | FR Client | | FR Client | 348 +--+-------------+ +--------------+-+ +--+-------------+ +----------------+ 349 | | 350 | | 351 | | 352 | | 353 +--+-------------+ +--+-----------+-+ 354 | Node A | | Node Z | 355 | L2 | | L2 | 356 +----------------+ +----------------+ 358 Figure 1: Auto-FR Example Topology 360 Figure 1 illustrates a typical 5-stage Clos IP fabric. Each node is 361 named and labelled in such a way that conveys: 363 1. The node's generic placement within the context of the RIFT 364 underlay 366 2. The node's level(s) within the IS-IS area. 368 3. The node's role within the IS-IS flood reflection topology. 370 It is important to remember that Auto-FR is not altering anything 371 specific to IS-IS Flood Reflection topologies, it takes existing 372 deployment scenarios and simplies the provisioning process. The 373 topology also illustrates the flood reflection adjacencies between 374 ToF and Leaf nodes. 376 Table 1 should help further align these concepts. 378 +----------------+-------------+------------------------+ 379 | RIFT Placement | IS-IS Level | IS-IS FR Role | 380 +================+=============+========================+ 381 | ToF Nodes | L1/L2 | Flood Reflector | 382 +----------------+-------------+------------------------+ 383 | Spine Nodes | L1 | N/A | 384 +----------------+-------------+------------------------+ 385 | Leaf Nodes | L1/L2 | Flood Reflector Client | 386 +----------------+-------------+------------------------+ 388 Table 1: Role Associations 390 5.2. Auto-FR Analytics 392 Leaf nodes MAY optionally advertise analytics information about the 393 Auto-FR fabric to ToF nodes using RIFT Key-Value TIEs. This may be 394 helpful in that validation and troubleshooting activities can be 395 performed on the ToF nodes. 397 This section requests suggested values from the RIFT Well-Known Key- 398 Type Registry and describes their use for Auto-FR. 400 +--------------------------+-------+-------------------------------+ 401 | Name | Value | Description | 402 +==========================+=======+===============================+ 403 | Auto-FR Analytics Global | 5 | Analytics describing an Auto- | 404 | | | FR node within a fabric. | 405 +--------------------------+-------+-------------------------------+ 407 Table 2: Requested RIFT Key Registry Values 409 The normative Thrift schema can be found in the appendix 410 (Appendix A.3). 412 5.2.1. Auto-FR Global Analytics Key Type 414 This Key Type describes node level information within the context of 415 the Auto-FR fabric. The System ID of the advertising leaf node MUST 416 be used to differentiate the node among other nodes in the fabric. 418 The Auto-FR Global Key Type MUST be advertised with the 3rd and 4th 419 bytes of the Key Identifier consisting of all 0s. 421 0 1 2 3 422 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Well-Known | Auto-FR (Global) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | (Auto-FR Role, | 427 | Flood Reflection Cluster ID, | 428 | Established IS-IS FR Adjacencies, | 429 | Established IS-IS FR L1 Shortcut Adjacencies, | 430 | Total IS-IS FR Adjacencies, | 431 | Total IS-IS FR L1 Shortcut Adjacencies,) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 2: Auto-FR Global Key-Value TIE 436 where: 438 *Auto-FR Role:* 439 The value indicating the node's Auto-FR role within the fabric. 441 0: Illegal value, MUST NOT be used. 443 1: Auto-FR Flood Reflector Client 445 2: Auto-FR Flood Reflector 447 *Auto-FR Cluster ID* 448 A 32-bit integer indicating the Auto-FR Cluster ID of the local 449 node. 451 *Functional IS-IS Flood Reflector Adjacency Count:* 452 A 16-bit integer indicating the number of IS-IS Level 2 Flood 453 Reflector adjacencies in the "Up" state on the local node. 455 *Functional IS-IS Level 1 Shortcut Count* 456 A 16-bit integer indicating the number of IS-IS Level 1 457 Shortcut adjacencies in the "Up" state on the local node. 459 *Total IS-IS Flood Reflector Adjacency Count:* 460 A 16-bit integer indicating the total number of IS-IS Level 2 461 Flood Reflector adjacencies on the local node regardless of 462 state. 464 *Total IS-IS Level 1 Shortcut Count* 465 A 16-bit integer indicating the total number of IS-IS Level 1 466 Shortcut adjacencies on the local node regardless of state. 468 6. Acknowledgements 470 This section will be used to acknowledge major contributors. 472 7. Security Considerations 474 This document introduces no new security concerns to RIFT or other 475 specifications referenced in this document as RIFT natively secures 476 LIE and TIE packets as described in [RIFT]. 478 8. References 480 8.1. Normative References 482 [IS-IS-FR] Przygienda, A., Bowers, C., Lee, Y., Sharma, A., and R. 483 White, "IS-IS Flood Reflection", Work in Progress, draft- 484 ietf-lsr-isis-flood-reflection-07, November 2021. 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RIFT] Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and 492 D. Afanasiev, "RIFT: Routing in Fat Trees", Work in 493 Progress, draft-ietf-rift-rift-14, July 2021. 495 [RIFT-KV] Head, J. and T. Przygienda, "RIFT Keys Structure and Well- 496 Known Registry in Key Value TIE", Work in Progress, draft- 497 ietf-rift-kv-registry-01, July 2021. 499 8.2. Informative References 501 [RIFT-AUTO-EVPN] 502 Head, J. and T. Przygienda, "RIFT Auto-EVPN", Work in 503 Progress, draft-ietf-rift-auto-evpn-01, October 2021. 505 Appendix A. Thrift Models 507 This section contains the normative Thrift models required to support 508 Auto-FR. Per the main [RIFT] specification, all signed values MUST 509 be interpreted as unsigned values. 511 A.1. common.thrift 513 This section specifies changes to main RIFT common.thrift model. 515 ... 516 enum AutoFRModel { 517 /** Full Mesh of L1 tunnel shortcuts, only model supported currently with auto FR */ 518 TunnelMode = 0, 519 NoTunnelMode = 1, 520 } 522 const AutoFRModel default_autofr_model = AutoFRModel.TunnelMode 524 typedef i32 FloodReflectionClusterIDType 526 /// preference to become FR, higher is better 527 typedef i32 FloodReflectionPreferenceType 528 ... 530 Figure 3: RIFT Auto-FR: common.thrift 532 A.2. encoding.thrift 534 This section specifies changes to main RIFT encoding.thrift model. 536 struct NodeCapabilities { 537 ... 538 /** indicates whether auto-flood-reflection feature is implemented on this node (but not necessarily enabled). */ 539 20: optional bool auto_flood_reflection_support = false; 540 ... 541 } 543 struct LIEPacket { 544 ... 545 /** It provides optional version of FR ZTP as 256 * MAJOR + MINOR, indicates support for auto FR */ 546 40: optional i16 auto_flood_reflection_version; 548 41: optional common.FloodReflectionClusterIDType auto_flood_reflection_cluster_id; 549 ... 550 } 552 struct NodeTIEElement { 553 ... 554 /** All Auto FR elements MUST be present in at least one TIE in each direction if auto FR is running. */ 555 /** It provides optional version of FR ZTP as 256 * MAJOR + MINOR, indicates support for auto FR */ 556 30: optional i16 auto_flood_reflection_version; 557 /** cluster ID of Auto FR */ 558 31: optional common.FloodReflectionClusterIDType auto_flood_reflection_cluster_id; 559 /** preference to become FR */ 560 32: optional common.FloodReflectionPreferenceType auto_flood_reflection_preference; 561 ... 562 } 564 Figure 4: RIFT Auto-FR: encoding.thrift 566 A.3. auto_flood_reflection_kv.thrift 568 This section contains the normative Auto-FR Analytics Thrift schema. 570 include "common.thrift" 572 namespace py auto_flood_reflection_kv 573 namespace rs models 575 const i8 AutoFRWellKnownKeyType = 2 576 typedef i16 AutoFRCounterType 577 typedef i32 AutoFRLongCounterType 579 const i8 GlobalAutoFRTelemetryKV = 5 581 /** We don't need the full role structure, only an indication of the node's basic role */ 582 enum AutoFRRole { 583 ILLEGAL = 0, 584 auto_fr_leaf = 1, 585 auto_fr_reflector = 2, 586 } 588 /** Per the according RIFT draft the key comes from the well known space. 589 Part of the key is used as Fabric-ID. 591 1st byte MUST be = "Well-Known" 592 2nd byte MUST be = "Global Auto-FR Telemetry KV", 593 3rd/4th bytes MUST be = all 0s 594 */ 595 struct AutoFRTelemetryGlobalKV { 596 /** Only values that the ToF cannot derive itself should be flooded. */ 597 1: required set auto_fr_roles, 599 2: required common.FloodReflectionClusterIDType cluster_id, 601 3: optional AutoFRCounterType established_isis_fr_adjacencies_count, 603 4: optional AutoFRCounterType established_isis_l1_shortcut_adjacencies_count, 605 5: optional AutoFRCounterType total_isis_fr_adjacencies_count, 607 6: optional AutoFRCounterType total_isis_l1_shortcut_adjacencies_count, 608 } 610 Figure 5: RIFT Auto-FR: auto_flood_reflection_kv.thrift 612 Appendix B. Auto-FR Variable Derivation 614 This section contains the normative Thrift models required to support 615 Auto-FR. Per the main [RIFT] specification, all signed values MUST 616 be interpreted as unsigned values. 618 /// indicates how many FRs we're computing in AUTO fR 619 pub const MAX_AUTO_FR_FRS: usize = 3; 621 /// indicates the cluster has no ID, used in computations to omit effects of cluster ID 622 pub const NO_CLUSTER_ID: FloodReflectionClusterIDType = 0; 624 /// unique v6 prefix for all nodes starts with this 625 pub fn auto_fr_v6pref(cid: FloodReflectionClusterIDType) -> String { 626 format!("FD00:{:04X}:B1", cid) 627 } 629 /// how many bytes in a v6pref for different purposes 630 pub const AUTO_FR_V6PREFLEN: usize = 8 * 5; 632 /// unique v6 prefix for flood reflector purposes starts like this 633 pub fn auto_fr_v6frpref(cid: FloodReflectionClusterIDType) -> String { 634 format!("FD00:{:04X}:B2", cid) 635 } 637 /// unique v4 prefix for IRB purposes 638 pub const AUTO_FR_V4LOOPBACKNET: u8 = 10; 639 pub const AUTO_FR_V4LOOPBACKMASK : usize = 8; 641 Figure 6: RIFT Auto-FR: auto_fr_const_structs_types 643 /// auto FR V6 loopback for FRs 644 pub fn auto_fr_cidfrpref2frloopback(cid: FloodReflectionClusterIDType, 645 preference: u8) -> Result { 646 auto_fr_v6prefixcidsid2loopback(&auto_fr_v6frpref(cid), cid, (1 + preference) as _) 647 } 649 Figure 7: RIFT Auto-FR: auto_fr_cidfrpref2frloopback 651 pub fn auto_fr_cidsid2isisnet(cid: FloodReflectionClusterIDType, sid: UnsignedSystemID) -> Vec { 652 let mut r = vec![0x49]; 654 r.extend(&cid.to_ne_bytes()); 655 r.extend(auto_fr_cidsid2isissid(cid, sid).into_iter()); 656 r.push(0); // magic end 658 assert!(r.len() == 10); 660 r 661 } 663 Figure 8: RIFT Auto-FR: auto_fr_cidsid2isisnet 665 /// ISIS system ID derivation 666 pub fn auto_fr_cidsid2isissid(cid: FloodReflectionClusterIDType, sid: UnsignedSystemID) -> Vec { 668 let sb = auto_fr_v6hash(cid, sid); 670 vec![sb[0], 671 sb[1], 672 sb[2], 673 sb[3], 674 sb[4] ^ sb[5], 675 sb[6] ^ sb[7], 676 ] 677 } 679 Figure 9: RIFT Auto-FR: auto_fr_cidsid2isissid 681 /// v4 loopback address derivation for every node in auto-fr, returns address and 682 /// subnet mask length. 683 pub fn auto_fr_cidsid2v4loopback(cid: FloodReflectionClusterIDType, sid: UnsignedSystemID) -> (IPv4Address, u8) { 684 let mut derived = sid.to_ne_bytes().iter() 685 .fold(0 as IPv4Address, |p, e| (p << 4) ^ (*e as IPv4Address)); 686 derived ^= cid as IPv4Address; 687 // use the byte we loose for entropy 688 derived ^= derived >> (32 - AUTO_FR_V4LOOPBACKMASK); 689 // and sanitize for loopback range, we nuke 8 bits out 690 derived &= (!U32MASKS[AUTO_FR_V4LOOPBACKMASK]) as IPv4Address; 692 let m = ((AUTO_FR_V4LOOPBACKNET as IPv4Address) << (32 - AUTO_FR_V4LOOPBACKMASK)) | derived; 693 (m as _, AUTO_FR_V4LOOPBACKMASK as _) 694 } 696 Figure 10: RIFT Auto-FR: auto_fr_cidsid2v4loopback 698 /// V6 loopback derivation for every node in auto fr 699 pub fn auto_fr_cidsidv6loopback(cid: FloodReflectionClusterIDType, 700 sid: UnsignedSystemID) -> Result { 701 auto_fr_v6prefixcidsid2loopback(&auto_fr_v6pref(cid), cid, sid) 702 } 704 Figure 11: RIFT Auto-FR: auto_fr_cidsidv6loopback 706 /// function sorts vector of systemIDs first, 707 /// followed by a shuffle taking largest/smallest/2nd largest/2nd smallest. 708 pub(crate) fn auto_fr_sids2frs(mut v: Vec) 709 -> Vec { 710 v.par_sort(); 711 if v.len() > 2 { 712 let mut s = v.split_off(v.len() / 2); 713 s.reverse(); 714 interleave(v.into_iter(), s.into_iter()) 715 .collect::>() 716 } else { 717 v 718 } 719 } 721 Figure 12: RIFT Auto-FR: auto_fr_sids2frs 723 pub(crate) fn auto_fr_v62octets(a: Ipv6Addr) -> Vec { 724 a.octets().iter().cloned().collect() 725 } 727 Figure 13: RIFT Auto-FR: auto_fr_v62octets 729 /// generic bytes derivation used for different purposes 730 pub fn auto_fr_v6hash(cid: FloodReflectionClusterIDType, sid: UnsignedSystemID) 731 -> [u8; 8] { 732 let sub = (cid as UnsignedSystemID) ^ sid; 734 sub.to_ne_bytes() 735 } 737 Figure 14: RIFT Auto-FR: auto_fr_v6hash 739 /// local address with encoded cluster ID and system ID for collision free identifiers. Basis 740 /// for several different prefixes. 741 pub fn auto_fr_v6prefixcidsid2loopback(v6pref: &str, cid: FloodReflectionClusterIDType, 742 sid: UnsignedSystemID) -> Result { 743 assert!(cid != ILLEGAL_CLUSTER_I_D); 744 let a = format!("{}00::{}", 745 v6pref, 746 sid.to_ne_bytes() 747 .iter() 748 .chunks(2) 749 .into_iter() 750 .map(|chunk| 751 chunk.fold(0u16, |v, n| (v << 8) | *n as u16)) 752 .map(|v| format!("{:04X}", v)) 753 .collect::>() 754 .into_iter() 755 .join(":") 756 ); 758 Ipv6Addr::from_str(&a) 759 .map_err(|_| ServiceErrorType::INTERNALRIFTERROR) 760 } 762 Figure 15: RIFT Auto-FR: auto_fr_v6prefixcidsid2loopback 764 /// cluster prefixes derived instead of advertising default on the cluster to allow 765 /// for default route on ToF or leaves 766 pub fn auto_fr_cid2cluster_prefixes(cid: FloodReflectionClusterIDType) -> Result, ServiceErrorType> { 767 vec![ 768 (auto_fr_cidsidv6loopback(cid, ILLEGAL_SYSTEM_I_D as _), AUTO_FR_V6PREFLEN), 769 (auto_fr_cidfrpref2frloopback(cid, 0 as _), AUTO_FR_V6PREFLEN), 770 ] 771 .into_iter() 772 .map(|(p, _)| 773 match p { 774 Ok(_) => Ok( 775 IPPrefixType::Ipv6prefix( 776 IPv6PrefixType { 777 address: auto_fr_v62octets(p?), 778 prefixlen: AUTO_FR_V6PREFLEN as _, 779 })), 780 Err(e) => Err(e), 781 } 782 ) 783 .collect::, _>>() 784 } 786 Figure 16: RIFT Auto-FR: auto_fr_cid2cluster_prefixes 788 Authors' Addresses 790 Jordan Head (editor) 791 Juniper Networks 792 1133 Innovation Way 793 Sunnyvale, CA 794 United States of America 796 Email: jhead@juniper.net 798 Tony Przygienda 799 Juniper Networks 800 1133 Innovation Way 801 Sunnyvale, CA 802 United States of America 804 Email: prz@juniper.net 806 Colby Barth 807 Juniper Networks 808 1133 Innovation Way 809 Sunnyvale, CA 810 United States of America 812 Email: cbarth@juniper.net