idnits 2.17.1 draft-head-rift-auto-evpn-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 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 February 2021) is 1157 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) == Outdated reference: A later version (-21) exists of draft-ietf-rift-rift-12 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 W. Lin 5 Expires: 26 August 2021 Juniper Networks 6 22 February 2021 8 RIFT Auto-EVPN 9 draft-head-rift-auto-evpn-00 11 Abstract 13 This document specifies procedures that allow an EVPN overlay to be 14 fully and automatically provisioned when using RIFT as underlay and 15 leveraging its 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 26 August 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2. Design Considerations . . . . . . . . . . . . . . . . . . . . 4 53 3. System ID . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Fabric ID . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Auto-EVPN Device Roles . . . . . . . . . . . . . . . . . . . 5 56 5.1. All Participating Nodes . . . . . . . . . . . . . . . . . 5 57 5.2. ToF Nodes as Route Reflectors . . . . . . . . . . . . . . 5 58 5.3. Leaf Nodes . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Auto-EVPN Variable Derivation . . . . . . . . . . . . . . . . 7 60 6.1. Auto-EVPN Version . . . . . . . . . . . . . . . . . . . . 8 61 6.2. MAC-VRF ID . . . . . . . . . . . . . . . . . . . . . . . 8 62 6.3. Loopback Address . . . . . . . . . . . . . . . . . . . . 8 63 6.3.1. Leaf Nodes as Gateways . . . . . . . . . . . . . . . 8 64 6.3.2. ToF Nodes as Route Reflectors . . . . . . . . . . . . 9 65 6.3.2.1. Route Reflector Election Procedures . . . . . . . 9 66 6.4. Autonomous System Number . . . . . . . . . . . . . . . . 9 67 6.5. Cluster ID . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.6. Router ID . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.7. Route Target . . . . . . . . . . . . . . . . . . . . . . 10 70 6.8. Route Distinguisher . . . . . . . . . . . . . . . . . . . 10 71 6.9. EVPN MAC-VRF Services . . . . . . . . . . . . . . . . . . 10 72 6.9.1. Untagged Traffic in Multiple Fabrics . . . . . . . . 11 73 6.9.1.1. VLAN . . . . . . . . . . . . . . . . . . . . . . 11 74 6.9.1.2. VNI . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.9.1.3. MAC Address . . . . . . . . . . . . . . . . . . . 11 76 6.9.1.4. IPv6 IRB Gateway Address . . . . . . . . . . . . 11 77 6.9.1.5. IPv4 IRB Gateway Address . . . . . . . . . . . . 11 78 6.9.2. Tagged Traffic in Multiple Fabrics . . . . . . . . . 11 79 6.9.2.1. VLAN . . . . . . . . . . . . . . . . . . . . . . 12 80 6.9.2.2. VNI . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.9.2.3. MAC Address . . . . . . . . . . . . . . . . . . . 12 82 6.9.2.4. IPv6 IRB Gateway Address . . . . . . . . . . . . 12 83 6.9.2.5. IPv4 IRB Gateway Address . . . . . . . . . . . . 12 84 6.9.3. Tagged Traffic in a Single Fabric . . . . . . . . . . 12 85 6.9.3.1. VLAN . . . . . . . . . . . . . . . . . . . . . . 12 86 6.9.3.2. VNI . . . . . . . . . . . . . . . . . . . . . . . 13 87 6.9.3.3. MAC Address . . . . . . . . . . . . . . . . . . . 13 88 6.9.3.4. IPv6 IRB Gateway Address . . . . . . . . . . . . 13 89 6.9.3.5. IPv4 IRB Gateway Address . . . . . . . . . . . . 13 90 6.9.4. Traffic Routed to External Destinations . . . . . . . 13 91 6.9.4.1. Route Distinguisher . . . . . . . . . . . . . . . 13 92 6.9.4.2. Route Target . . . . . . . . . . . . . . . . . . 13 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 97 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 14 98 A.1. RIFT LIE Schema . . . . . . . . . . . . . . . . . . . . . 14 99 A.1.1. Auto-EVPN Version . . . . . . . . . . . . . . . . . . 14 100 A.1.2. Fabric ID . . . . . . . . . . . . . . . . . . . . . . 14 101 A.2. RIFT Node-TIE Schema . . . . . . . . . . . . . . . . . . 15 102 A.2.1. Auto-EVPN Version . . . . . . . . . . . . . . . . . . 15 103 A.2.2. Fabric ID . . . . . . . . . . . . . . . . . . . . . . 15 104 A.3. Variable Derivation . . . . . . . . . . . . . . . . . . . 15 105 A.3.1. Random Seed Values . . . . . . . . . . . . . . . . . 15 106 A.3.2. Fabric ID . . . . . . . . . . . . . . . . . . . . . . 15 107 A.3.3. Loopback Address . . . . . . . . . . . . . . . . . . 15 108 A.3.4. Autonomous System Number . . . . . . . . . . . . . . 15 109 A.3.5. Cluster ID . . . . . . . . . . . . . . . . . . . . . 15 110 A.3.6. Router ID . . . . . . . . . . . . . . . . . . . . . . 15 111 A.3.7. Route Target . . . . . . . . . . . . . . . . . . . . 15 112 A.3.8. Route Distinguisher . . . . . . . . . . . . . . . . . 16 113 A.3.9. VLAN . . . . . . . . . . . . . . . . . . . . . . . . 16 114 A.3.10. VNI . . . . . . . . . . . . . . . . . . . . . . . . . 16 115 A.3.11. Gateway (MAC) . . . . . . . . . . . . . . . . . . . . 16 116 A.3.12. Gateway (IPv6) . . . . . . . . . . . . . . . . . . . 16 117 A.3.13. Gateway (IPv4) . . . . . . . . . . . . . . . . . . . 16 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 120 1. Introduction 122 RIFT is a protocol that focuses heavily on operational simplicity. 123 [RIFT] natively supports Zero Touch Provisioning (ZTP) functionality 124 that allows each node in an underlay network to automatically derive 125 its place in the topology and configure itself accordingly when 126 properly cabled. RIFT can also disseminate Key-Value information 127 contained in Key-Value Topology Information Elements (KV-TIEs). 128 These KV-TIEs can contain any information and therefore be used for 129 any purpose. Leveraging RIFT to provision EVPN overlays without any 130 need for configuration and leveraging KV capabilities to easily 131 validate correct operation of such overlay without a single point of 132 failure would provide significant benefit to operators in terms of 133 simplicity and robustness of such a solution. 135 1.1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 2. Design Considerations 143 EVPN supports various service models, this document defines a method 144 for the VLAN-Aware service model defined in [RFC7432]. Other service 145 models may be considered in future revisions of this document. 147 Each model has its own set of requirements for deployment. For 148 example, a functional BGP overlay is necessary to exchange EVPN NLRI 149 regardless of the service model. Furthermore, the requirements are 150 made up of individual variables, such as each node's loopback address 151 and AS number for the BGP session. Some of these variables may be 152 coordinated across each node in a network, but are ultimately locally 153 significant (e.g. route distinguishers). Similarly, calculation of 154 some variables will be local only to each device. RIFT contains 155 currently enough topology information in each node to calculate all 156 those necessary variables automatically. 158 Once the EVPN overlay is configured and becomes operational KV TIEs 159 can be used to distribute state information to allow for validation 160 of basic operational correctness without need for further tooling. 162 3. System ID 164 The 64-bit RIFT System ID that uniquely identifies a node as defined 165 in [RIFT]. 167 4. Fabric ID 169 RIFT operates on variants of Clos substrate which are commonly called 170 an IP Fabric. Since EVPN VLANs can be either contained within one 171 fabric or span them, Auto-EVPN introduces the concept of a Fabric ID 172 into RIFT. 174 This section describes an optional extension to LIE packet schema in 175 the form of a 16-bit Fabric ID that identifies a nodes membership 176 within a particular fabric. Auto-EVPN capable nodes MUST support 177 this extension but MAY not advertise it when not participating in 178 Auto-EVPN. A non-present Fabric ID and value of 0 is reserved as 179 ANY_FABRIC and MUST NOT be used for any other purpose. 181 Fabric ID MUST be considered in existing adjacency FSM rules so nodes 182 that support Auto-EVPN can interoperate with nodes that do not. The 183 LIE validation is extended with following clause and if it is not 184 met, miscabling should be declared: 186 (if fabric_id is not advertised by either node OR 187 if fabric_id is identical on both nodes) 188 AND 189 (if auto_evpn_version is not advertised by either node OR 190 if auto_evpn_version is identical on both nodes) 192 The appendix details LIE (Appendix A.1.2) and Node-TIE 193 (Appendix A.2.2) schema changes. 195 5. Auto-EVPN Device Roles 197 Auto-EVPN requires that each node understand its given role within 198 the scope of the EVPN implementation so each node derives the 199 necessary variables and provides the necessary overlay configuration. 200 For example, a leaf node performing VXLAN gateway functions does not 201 need to derive its own Cluster ID or learn one from the route 202 reflector that it peers with. 204 5.1. All Participating Nodes 206 Not all nodes have to participate in Auto-EVPN but when they do they 207 do assume EVPN roles and MUST derive according variables: 209 *IPv6 Loopback Address* 210 Unique IPv6 loopback address used in BGP sessions. 212 *Router ID* 213 The BGP Router ID. 215 *Autonomous System Number* 216 The ASN for IBGP sessions. 218 *Cluster ID* 219 The Cluster ID for Top-of-Fabric IBGP route reflection. 221 5.2. ToF Nodes as Route Reflectors 223 This section defines an Auto-EVPN role whereby some Top-of-Fabric 224 nodes act as EVPN route reflectors. It is expected that route 225 reflectors would establish IBGP sessions with leaf nodes in the same 226 fabric. The typical route reflector requirements do not change, 227 however determining which specific values to use requires further 228 consideration. ToF nodes performing route reflector functionality 229 MUST derive the following variables: 231 *IPv6 RR Loopback Address* 232 The source address for IBGP sessions with leaf nodes in case 233 ToF won election for one of the route reflectors in the fabric. 235 *IPv6 RR Acceptable Prefix Range* 236 Range of addresses acceptable by the route reflector to form a 237 IBGP session. This range covers ALL possible IPv6 Loopback 238 Addresses derived by other Auto EVPN nodes in the current 239 fabric and other Auto-EVPN RRs addresses. 241 5.3. Leaf Nodes 243 Leaf nodes derive their role from realizing they are at the bottom of 244 the fabric, i.e. not having any southbound adjacencies. Alternately, 245 a node can assume a leaf node if it has only southbound adjacencies 246 to nodes with explicit LEAF_LEVEL to allow for scenarios where RIFT 247 leaves do NOT participate in Auto-EVPN. 249 Leaf nodes MUST derive the following variables: 251 *IPv6 RR Loopback Adresses* 252 Addresses of the RRs present in the fabric. Those addresses 253 are used to build BGP sessions to the RR. 255 *EVIs* 256 Leaf node derives all the necessary variables to instantiate 257 EVIs with layer-2 and optionally layer-3 functionality. 259 If a leaf node is required to perform layer-2 VXLAN gateway 260 functions, it MUST be capable of deriving the following types of 261 variables: 263 *Route Distinguisher* 264 The route distinguisher corresponding to a MAC-VRF that 265 uniquely identifies each node. 267 *Route Target* 268 The route target that corresponds to a MAC-VRF. 270 *MAC VRF name* 271 This is an optional variable to provide a common MAC VRF name 272 across all leaves. 274 *Set of VLANs* 275 Those are VLANs provisioned either within the fabric or 276 allowing to stretch across fabrics. 278 For each VLAN derived in an EVI the following variables MUST be 279 derived: 281 *VLAN* 282 The VLAN ID. 284 *name* 285 This is an optional variable to provide a common VLAN name 286 across all leaves. 288 *VNI* 289 The VNI that corresponds to the VLAN ID. This will contribute 290 to the EVPN Type-2 route. 292 *IRB* 293 Optional variables of the IRB for the VLAN if the leaf performs 294 layer-3 gateway function. 296 If a leaf node is required to perform layer-3 VXLAN gateway 297 functions, it MUST additionally be capable of deriving the following 298 types of variables: 300 *IP Gateway MAC Address* 301 The MAC address associated with IP gateway. 303 *IP Gateway Subnetted Address* 304 The IPv4 and/or IPv6 gateway address including its subnet 305 length. 307 Type-5 EVPN IP Prefix with ToFs performing gateway functionality can 308 also be derived and will be described in a future version of this 309 document. 311 6. Auto-EVPN Variable Derivation 313 As previously mentioned, not all nodes are required to derive all 314 variables in a given network (e.g. a transit spine node may not need 315 to derive any or participate in Auto-EVPN). Additionally, all 316 derived variables are derived from RIFT's FSM or ZTP mechanism so no 317 additional flooding beside RIFT flooding is necessary for the 318 functionality. 320 It is also important to mention that all variable derivation is in 321 some way based on combinations of System ID, MAC-VRF ID, Fabric ID, 322 EVI and VLAN and MUST comply precisely with calculation methods 323 specified in the Appendix section to allow interoperability between 324 different implementations. 326 6.1. Auto-EVPN Version 328 This section describes extensions to both the RIFT LIE packet and 329 Node-TIE schemas in the form of a 16-bit value that identifies the 330 Auto-EVPN Version. Auto-EVPN capable nodes MUST support this 331 extension, but MAY choose not to advertise it in LIEs and Node-TIEs 332 when Auto-EVPN is not being utilized. The appendix describes LIE 333 (Appendix A.1.1) and Node-TIE (Appendix A.2.1) schema changes in 334 detail. 336 6.2. MAC-VRF ID 338 This section describes a variable MAC-VRF ID that uniquely identifies 339 an instance of EVPN instance (EVI) and is used in variable derivation 340 procedures. Each EVPN EVI MUST be associated with a unique MAC-VRF 341 ID, this document does not specify a method for making that 342 association or ensuring that they are coordinated properly across 343 fabric(s). 345 6.3. Loopback Address 347 First and foremost, RIFT does not advertise anything more specific 348 than the fabric default route in the southbound direction by default. 349 However, Auto-EVPN nodes MUST advertise specific loopback addresses 350 southbound to all other Auto-EVPN nodes so to establish MP-BGP 351 reachability correctly in all scenarios. 353 Auto-EVPN nodes MUST derive a ULA-scoped IPv6 loopback address to be 354 used as both the IBGP source address, as well as the VTEP source when 355 VXLAN gateways are required. Calculation is done using the 6-bytes 356 of reserved ULA space, the 2-byte Fabric ID, and the node's 8-byte 357 System ID. Derivation of the System ID varies slightly depending 358 upon the node's location/role in the fabric and will be described in 359 subsequent sections. 361 IPv4 addresses MAY be supported, but it should be noted that they 362 have a higher likelihood of collision. 364 The required algorithm can be found in the appendix (Appendix A.3.3). 366 6.3.1. Leaf Nodes as Gateways 368 Calculation is done using the 6-bytes of reserved ULA space, the 369 2-byte Fabric ID, and the node's 8-byte System ID. 371 6.3.2. ToF Nodes as Route Reflectors 373 ToF nodes acting as route reflectors MUST derive their loopback 374 address according to the specific section describing the algorithm. 375 Calculation is done using the 6-bytes of reserved ULA space, the 376 2-byte Fabric ID, and the 8-byte System ID of each elected route 377 reflector. 379 6.3.2.1. Route Reflector Election Procedures 381 Four Top-of-Fabric nodes MUST be elected as an IBGP route reflector. 382 Each ToF performs the election independently based on system IDs of 383 other ToFs in the fabric obtained via southbound reflection. The 384 route reflector election procedures are defined as follows: 386 1. ToF node with the highest System ID. 388 2. ToF node with the lowest System ID. 390 3. ToF node with the 2nd highest System ID. 392 4. ToF node with the 2nd lowest System ID. 394 This ordering is necessary to prevent a single node with either the 395 highest or lowest System ID from triggering changes to route 396 reflector loopback addresses as it would result in all BGP sessions 397 dropping. 399 For example, if two nodes, ToF01 and ToF02 with System IDs 400 002c6af5a281c000 and 002c6bf5788fc000 respectively, ToF02 would be 401 elected due to it having the highest System ID of the ToFs 402 (002c6bf5788fc000). If a ToF determines that it is elected as route 403 reflector, it uses the knowledge of its position in the list to 404 derive route reflector v6 loopback address. 406 Considerations for multiplane route reflector elections will be 407 included in future revisions. 409 6.4. Autonomous System Number 411 Nodes in each fabric MUST derive a private autonomous system number 412 based on its Fabric ID so that it is unique across the fabric. 414 The required algorithm for 2-byte ASNs can be found in the appendix 415 (Appendix A.3.4). 417 6.5. Cluster ID 419 Route reflector nodes in each fabric MUST derive a cluster ID that is 420 based on its Fabric ID so that it is unique across the fabric. 421 Implementations MAY choose to simply use the AS number as the cluster 422 ID. 424 The required algorithm can be found in the appendix (Appendix A.3.5). 426 6.6. Router ID 428 Nodes MUST drive a Router ID that is based on both its System ID and 429 Fabric ID so that it is unique to both. 431 The required algorithm can be found in the appendix (Appendix A.3.6). 433 6.7. Route Target 435 Nodes hosting EVPN EVIs MUST derive a route target extended community 436 based on the MAC-VRF ID for each EVI so that it is unique across the 437 network. Route targets MUST be of type 0 as per RFC4360. 439 For example, if given a MAC-VRF ID of 1, the derived route target 440 would be "target:1" 442 The required algorithm can be found in the appendix (Appendix A.3.7). 444 6.8. Route Distinguisher 446 Nodes hosting EVPN EVIs MUST derive a type-0 route distinguisher 447 based on its System ID and Fabric ID so that it is unique per MAC-VRF 448 and per node. 450 The required algorithm can be found in the appendix (Appendix A.3.8). 452 6.9. EVPN MAC-VRF Services 454 It's obvious that applications utilizing Auto-EVPN overlay services 455 may require a variety of layer-2 and/or layer-3 traffic 456 considerations. Variables supporting these services are also derived 457 based on some combination of MAC-VRF ID, Fabric ID, and other 458 constant values. Integrated Routing and Bridging (IRB) gateway 459 address derivation also leverages a set of constant "random seed" 460 values to provide additional entropy. 462 The required derivation procedures can be found in the appendix 463 (Appendix A.3). 465 6.9.1. Untagged Traffic in Multiple Fabrics 467 This section defines a methods to derive unique VLAN, VNI, MAC, and 468 gateway address values for deployments where untagged traffic is 469 stretched across multiple fabrics. 471 6.9.1.1. VLAN 473 Untagged traffic stretched across multiple fabrics MUST derive VLAN 474 tags based on MAC-VRF ID in conjunction with a constant value of 1 475 (i.e. MAC-VRF ID + 1). 477 6.9.1.2. VNI 479 Untagged traffic stretched across multiple fabrics MUST derive VNIs 480 based on MAC-VRF ID and Fabric ID in conjunction with a constant 481 value. These VNIs MUST correspond to EVPN Type-2 routes. 483 6.9.1.3. MAC Address 485 The MAC address MUST be a unicast address and also MUST be identical 486 for any IRB gateways that belong to an individual bridge-domain 487 across fabrics. The last 5-bytes MUST be a hash of the MAC-VRF ID 488 and a constant value of 1 that is calculated using the previously 489 mentioned random seed values. 491 6.9.1.4. IPv6 IRB Gateway Address 493 The derived IPv6 gateway address MUST be from a ULA-scoped range that 494 will account for the first 6-bytes. The next 5-bytes MUST be the 495 last bytes of the derived MAC address. Finally, the remaining 496 7-bytes MUST be ::0001. 498 6.9.1.5. IPv4 IRB Gateway Address 500 The derived IPv4 gateway address MUST be from a RFC1918 range, which 501 accounts for the first octet. The next octet MUST a hash of the MAC- 502 VRF ID and a constant value of 1 that is calculated using the 503 previously mentioned random seed values. Finally, the remaining 2 504 octets MUST be 0 and 1 respectively. 506 6.9.2. Tagged Traffic in Multiple Fabrics 508 This section defines a methods to derive unique VLAN, VNI, MAC, and 509 gateway address values for deployments where tagged traffic is 510 stretched across multiple fabrics. 512 6.9.2.1. VLAN 514 Tagged traffic stretched across multiple fabrics MUST derive VLAN 515 tags based on MAC-VRF ID in conjunction with a constant value of 16 516 (i.e. MAC-VRF ID + 16). 518 6.9.2.2. VNI 520 Tagged traffic stretched across multiple fabrics MUST derive VNIs 521 based on MAC-VRF ID and Fabric ID in conjunction with a constant 522 value. These VNIs MUST correspond to EVPN Type-2 routes. 524 6.9.2.3. MAC Address 526 The MAC address MUST be a unicast address and also MUST be identical 527 for any IRB gateways that belong to an individual bridge-domain 528 across fabrics. The last 5-bytes MUST be a hash of the MAC-VRF ID 529 and a constant value of 1 that is calculated using the previously 530 mentioned random seed values. 532 6.9.2.4. IPv6 IRB Gateway Address 534 The derived IPv6 gateway address MUST be from a ULA-scoped range that 535 will account for the first 6-bytes. The next 5-bytes MUST be the 536 last bytes of the derived MAC address. Finally, the remaining 537 7-bytes MUST be ::0001. 539 6.9.2.5. IPv4 IRB Gateway Address 541 The derived IPv4 gateway address MUST be from a RFC1918 range, which 542 accounts for the first octet. The next octet MUST a hash of the MAC- 543 VRF ID and a constant value of 16 that is calculated using the 544 previously mentioned random seed values. Finally, the remaining 2 545 octets MUST be 0 and 1 respectively. 547 6.9.3. Tagged Traffic in a Single Fabric 549 This section defines a methods to derive unique VLAN, VNI, MAC, and 550 gateway address values for deployments where untagged traffic is 551 contained within a single fabric. 553 6.9.3.1. VLAN 555 Tagged traffic contained to a single fabric MUST derive VLAN tags 556 based on MAC-VRF ID and Fabric ID in conjunction with a constant 557 value of 17 (i.e. MAC-VRF ID + Fabric ID + 17). 559 6.9.3.2. VNI 561 Tagged traffic contained to a single fabric MUST derive VNIs based on 562 MAC-VRF ID and Fabric ID in conjunction with a constant value. These 563 VNIs MUST correspond to EVPN Type-2 routes. 565 6.9.3.3. MAC Address 567 The MAC address MUST be a unicast address and also MUST be identical 568 for any IRB gateways that belong to an individual bridge-domain 569 across fabrics. The last 5-bytes MUST be a hash of the MAC-VRF ID 570 and a constant value of 1 that is calculated using the previously 571 mentioned random seed values. 573 6.9.3.4. IPv6 IRB Gateway Address 575 The derived IPv6 gateway address MUST be from a ULA-scoped range, 576 which accounts for the first 6-bytes. The next 5-bytes MUST be the 577 last bytes of the derived MAC address. Finally, the remaining 578 7-bytes MUST be ::0001. 580 6.9.3.5. IPv4 IRB Gateway Address 582 The derived IPv4 gateway address MUST be from a RFC1918 range, which 583 accounts for the first octet. The next octet MUST a hash of the MAC- 584 VRF ID and a constant value of 17 that is calculated using the 585 previously mentioned random seed values. Finally, the remaining 2 586 octets MUST be 0 and 1 respectively. 588 6.9.4. Traffic Routed to External Destinations 590 6.9.4.1. Route Distinguisher 592 Nodes hosting IP Prefix routes MUST derive a type-0 route 593 distinguisher based on its System ID and Fabric ID so that it is 594 unique per IP-VRF and per node. 596 The required algorithm can be found in the appendix (Appendix A.3.8). 598 6.9.4.2. Route Target 600 Nodes hosting IP prefix routes MUST derive a route target extended 601 community based on the MAC-VRF ID for each IP-VRF so that it is 602 unique across the network. Route targets MUST be of type 0. 604 The required algorithm can be found in the appendix (Appendix A.3.7). 606 7. Acknowledgements 608 TBD 610 8. Security Considerations 612 This document introduces no new security concerns to RIFT or other 613 specifications referenced in this document. 615 9. References 617 9.1. Normative References 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, 621 DOI 10.17487/RFC2119, March 1997, 622 . 624 [RFC7432] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, 625 J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 626 VPN", February 2015, 627 . 629 [RIFT] Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and 630 D. Afanasiev, "RIFT: Routing in Fat Trees", Work in 631 Progress, draft-ietf-rift-rift-12, May 2020. 633 Appendix A. Appendix 635 A.1. RIFT LIE Schema 637 A.1.1. Auto-EVPN Version 639 struct LIEPacket { 640 ... 641 /** It provides the optional ID of the configured fabric */ 642 25: optional common.FabricIDType fabric_id; 643 ... 645 A.1.2. Fabric ID 647 ... 648 struct LIEPacket { 649 ... 650 /** It provides optional version of EVPN ZTP as 256 * MAJOR + MINOR */ 651 26: optional i16 auto_evpn_version; 652 ... 654 A.2. RIFT Node-TIE Schema 656 A.2.1. Auto-EVPN Version 658 struct NodeTIEElement { 659 ... 660 /** It provides optional version of EVPN ZTP as 256 * MAJOR + MINOR */ 661 13: optional i16 auto_evpn_version; 663 A.2.2. Fabric ID 665 struct NodeTIEElement { 666 ... 667 /** It provides the optional ID of the Fabric configured */ 668 12: optional common.FabricIDType fabric_id; 670 A.3. Variable Derivation 672 A.3.1. Random Seed Values 674 To be provided in future version of this document. 676 A.3.2. Fabric ID 678 To be provided in future version of this document. 680 A.3.3. Loopback Address 682 To be provided in future version of this document. 684 A.3.4. Autonomous System Number 686 To be provided in future version of this document. 688 A.3.5. Cluster ID 690 To be provided in future version of this document. 692 A.3.6. Router ID 694 To be provided in future version of this document. 696 A.3.7. Route Target 698 To be provided in future version of this document. 700 A.3.8. Route Distinguisher 702 To be provided in future version of this document. 704 A.3.9. VLAN 706 To be provided in future version of this document. 708 A.3.10. VNI 710 To be provided in future version of this document. 712 A.3.11. Gateway (MAC) 714 To be provided in future version of this document. 716 A.3.12. Gateway (IPv6) 718 To be provided in future version of this document. 720 A.3.13. Gateway (IPv4) 722 To be provided in future version of this document. 724 Authors' Addresses 726 Jordan Head (editor) 727 Juniper Networks 728 1137 Innovation Way 729 Sunnyvale, CA 730 United States of America 732 Email: jhead@juniper.net 734 Tony Przygienda 735 Juniper Networks 736 1137 Innovation Way 737 Sunnyvale, CA 738 United States of America 740 Email: prz@juniper.net 741 Wen Lin 742 Juniper Networks 743 10 Technology Park Drive 744 Westford, MA 745 United States of America 747 Email: wlin@juniper.net