idnits 2.17.1 draft-ietf-bess-evpn-modes-interop-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 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 (May 26, 2021) is 1059 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 124, but not defined == Missing Reference: 'RFC8174' is mentioned on line 124, but not defined == Missing Reference: 'EVPN-IRB' is mentioned on line 761, but not defined == Unused Reference: 'KEYWORDS' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 816, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 837, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 841, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 845, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-13 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT L. Krattiger, Ed. 3 Intended Status: Informational A. Sajassi, Ed. 4 Expires: November 27, 2021 S. Thoria 5 Cisco Systems 7 J. Rabadan 8 Nokia 10 J. Drake 11 Juniper 13 May 26, 2021 15 EVPN Interoperability Modes 16 draft-ietf-bess-evpn-modes-interop-00 18 Abstract 20 Ethernet VPN (EVPN) provides different functional modes in the area 21 of Service Interface, Integrated Route and Bridge (IRB) and IRB Core 22 connectivity. This document specifies how the different EVPN 23 functional modes and types can interoperate with each other. This 24 document doesn't aim to redefine the existing functional modes but 25 extend them for interoperability. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 3 67 2. Valid Combinations for Interoperability . . . . . . . . . . . 3 68 3. Service Interface Interoperability . . . . . . . . . . . . . . 5 69 3.1. VLAN-Aware Bundle and VLAN-Based . . . . . . . . . . . . . 5 70 3.1.1. VLAN-Aware Bundle Service PE . . . . . . . . . . . . . 6 71 3.1.2. VLAN-Based Service PE . . . . . . . . . . . . . . . . 7 72 3.2. Service Interface Interop Mode of Operation . . . . . . . . 7 73 4. Interoperability for different IRB Types . . . . . . . . . . . 8 74 4.1. Asymmetric IRB and Symmetric IRB . . . . . . . . . . . . . 8 75 4.1.1. Asymmetric IRB PE . . . . . . . . . . . . . . . . . . 10 76 4.1.2. Symmetric IRB PE . . . . . . . . . . . . . . . . . . . 10 77 4.2. IRB Interop Mode of Operation . . . . . . . . . . . . . . . 11 78 5. Interoperability for different IRB Core Connectivity Modes . . 12 79 5.1. Interface-Less and Interface-Ful Unnumbered IRB . . . . . 12 80 5.1.1. Interface-Less PE . . . . . . . . . . . . . . . . . . 15 81 5.1.2. Interface-Ful Unnumbered IRB . . . . . . . . . . . . . 15 82 5.2. Tunnel Encapsulation Consideration . . . . . . . . . . . . 17 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 88 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 9.1. Demonstration of Applicability . . . . . . . . . . . . . . 19 90 9.1.1. Service Interface Interoperability . . . . . . . . . . 19 91 9.1.2. IRB Types . . . . . . . . . . . . . . . . . . . . . . 19 92 9.1.3. IRB Core Connectivity Types . . . . . . . . . . . . . 19 94 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 96 1. Introduction 98 Ethernet VPN (EVPN) provides different functional modes in the area 99 of Service Interface, Integrated Route and Bridge (IRB) and IRB 100 connection model. It is understood that the different modes are 101 defined with different use-cases in mind. Even with the specific use- 102 cases and the resulting mode definition, the aim of interoperability 103 is critical. 104 The following EVPN modes are considered for interoperability. It is 105 limited to most pertinent interop modes as oppose to all 106 permutations. In the future if other modes are identified, it will be 107 addressed in future revisions. 109 - For Service Interfaces, the VLAN Aware Bundle and VLAN Based types. 111 - In Integrated Routing and Bridging (IRB) the Asymmetric IRB and 112 Symmetric IRB type. 114 - Within the IRB connectivity types, interface-less and the 115 interface-ful Unnumbered IRB. 117 1.1 Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 2. Valid Combinations for Interoperability 127 The tables below provide an overview of the valid combinations for 128 interoperability described in this Internet-Draft. 130 For the Service Interface Types as described in [RFC7432] section 6 131 and [RFC8365] section 5.1.2. Interoperability considerations are 132 provided for the VLAN-Based Service interface ([RFC7432], section 133 6.1) and the VLAN-Aware Bundle Service Interface type ([RFC7432] 134 section 6.3). The VLAN Bundle Service Interface ([RFC7432] section 135 6.2) is not considered at this time. 137 Table 1 represent the considered Service Interface Types 138 interoperability: 140 +-------------------+------------+-------------+--------------------+ 141 | | VLAN-Based | VLAN Bundle | VLAN-Aware Bundle | 142 +-------------------+------------+-------------+--------------------+ 143 | VLAN-Based | YES | NO | YES | 144 +-------------------+------------+-------------+--------------------+ 145 | VLAN Bundle | NO | YES | NO | 146 +-------------------+------------+-------------+--------------------+ 147 | VLAN-Aware Bundle | YES | NO | YES | 148 +-------------------+------------+-------------+--------------------+ 149 Table 1 151 In regards to Integrated Route and Bridge (IRB), two different modes 152 are defined in [EVPN-INTERSUBNET], with section 5 describing 153 Symmetric IRB and section 6 Asymmetric IRB: 155 The interoperability considerations for Asymmetric IRB and 156 Symmetric IRB mode are represented within this Internet-Draft. 158 For the IRB Core Connectivity, from all the available modes as 159 described in [EVPN-PREFIX], considered for interoperability is the 160 interface-less mode (section 4.4.1) in conjunction with only one of 161 the interface-ful modes, namely interface-ful IP-VRF-to-IP-VRF with 162 Unnumbered SBD IRB (section 4.4.3). With the implementation 163 proximation between the two interface-ful modes, considerations for 164 interoperability between interface-less and interface-ful Numbered 165 are currently not considered. Similarly, the interoperability between 166 the two interface-ful modes is currently not being considered, given 167 the already close relation and to limit permutations. Future 168 revisions of this Internet-Draft might address further variations of 169 interoperability. 171 Table 2 represent the considered IRB Core Connectivity 172 interoperability. 174 +-----------------+----------------+---------------+----------------+ 175 | | Interface-Less | Interface-Ful | Interface-Ful | 176 | | | Numbered IRB | Unnumbered IRB | 177 +-----------------+----------------+---------------+----------------+ 178 | Interface-Less | YES | NO | YES | 179 +-----------------+----------------+---------------+----------------+ 180 | Interface-Ful | NO | YES | NO | 181 | Numbered IRB | | | | 182 +-----------------+----------------+---------------+----------------+ 183 | Interface-Ful | YES | NO | YES | 184 | Unnumbered IRB | | | | 185 +-----------------+----------------+---------------+----------------+ 186 Table 2 188 3. Service Interface Interoperability 190 3.1. VLAN-Aware Bundle and VLAN-Based 192 [RFC7432] section 6 describes three different Service Interface 193 Types. The two modes in focus for interoperability are namely the 194 VLAN-Based Service Interface as defined in [RFC7432] section 6.1 and 195 the VLAN-Aware Bundle Service Interface as defined in [RFC7432] 196 section 6.3. The VLAN Bundle Service Interface is not considered. 198 The VLAN-Based Service Interface defines an EVPN instance consisting 199 of only a single broadcast domain or "Single Broadcast Domain per 200 EVI" as described in [RFC8365] section 5.1.2 Option 1. In this mode, 201 individual BGP Route Distinguisher (RD) and Route Target (RT) are 202 required for each EVI. Each EVI corresponds to a single MAC-VRF 203 identified by the RT, which provides the advantage of an BGP RT 204 constraint mechanisms in order to limit the propagation and import of 205 routes to only the PE that are interested. With VLAN-Based, the MAC- 206 VRF corresponds to only a single bridge table. The VLAN-Based Service 207 Interface uses the EVPN MAC/IP Advertisement route ([RFC7432], 208 section 7.2) with the MUST requirement of the Ethernet Tag ID being 209 set to zero. 211 Differently, the VLAN-Aware Bundle Service Interface follows a 212 bundling of multiple broadcast domains, with each having its own 213 bridge table, into a single EVI. This refers to the definition of 214 "Multiple Broadcast Domain per EVI" as described in [RFC8365] section 215 5.1.2 Option 2. The advantage of this model is that it doesn't 216 require the provisioning of an RD/RT per broadcast domain, which is a 217 moot point when VLAN-Base uses auto-derivation of RD/RT. With VLAN- 218 Aware Bundle Service, RT Constraint, as defined in [RFC4684], does 219 not help to reduce the dissemination of routes for a BD to the PEs 220 attached to that BD. This is given by the nature of the bundle 221 service where the RT is not sufficient to identify the MAC-VRF and 222 corresponding bridge table. The differences between the two modes of 223 Service Interfaces, namely VLAN-Based and VLAN-Aware Bundle Service 224 Interface, lie in the definition of the Ethernet Tag field in the 225 EVPN routes. While VLAN-Based Service Interface defines the EtherTag 226 as "must be set to zero", the VLAN-Aware Bundle Service interface 227 uses the VID within the EtherTag to identify the bridge table within 228 the MAC-VRF. These two requirements are orthogonal and as a result 229 make the interoperability of the two types mutually exclusive, an 230 interoperability is not achievable (Figure 1). 232 VLAN-Aware Bundle VLAN-Based 233 Service Interface Service Interface 234 +--------------------------+ +--------------------------+ 235 | PE1 | | PE2 | 236 | +---------+ +--------+ | | +--------+ +---------+ | 237 | | +-----+ | | | | | | | | | | 238 +-----| BD2 | +--+ | |--------| | +--+ |---+ 239 || | +-----+ | | | | | | | | | || 240 || | | | | | | | | | | || 241 || |MAC-VRF1 | |IP-VRF1 | | | |IP-VRF1 | |MAC-VRF1 | || 242 || +---------+ +--------+ | | +--------+ +---------+ || 243 || | | || 244 || +-----+ | | +-----+ || 245 || | BGP | | | | BGP | || 246 || +-----+ | | +-----+ || 247 |+--------------------------+ +--------------------------+| 248 | 2|EthTag [2]| -----><----- 2|EthTag [0]| | 249 | | 250 | +------+ +------+ | 251 +-|M1/IP1! |M2/IP2!-+ 252 +------+ +------+ 254 Figure 1: Interop of different Service Interface Types 256 As illustrated in Figure 1, the MAC/IP routes exchanged by PE1 and 257 PE2 contain Ethernet Tags 2 and 0 respectively. The receiving PE will 258 not process these routes and will normally discard them (treat-as- 259 withdraw)." 261 By extending the requirements currently present, an interoperability 262 is achievable. The adjustment would be as follows. 264 3.1.1. VLAN-Aware Bundle Service PE 266 In case of VLAN Aware Bundle Service Interface on the receiving PE 267 and with the consideration of VLAN Based Service Interface on the 268 advertising PE: 270 - MUST Operate in Single Broadcast Domain per EVI. 272 - Multiple Broadcast Domain per EVI case is not considered. 274 - Must allow to send and receive zero EtherTag. 276 - The import of routes is performed based on the import policy 277 (route-target). 279 - With single bridge table per MAC-VRF, additional evaluation of the 280 EtherTag field is not required; the bridge table is sufficiently 281 defined by the import route-target. Using a single MAC-VRF with per- 282 BD route-target would deviate from the VLAN-Based Service Interface 283 and would create a new interoperability permutation. 285 - No Change to data-plane operation, the MPLS label identifies MAC- 286 VRF + bridge-table, or the VNI identifies the MAC-VRF + the bridge- 287 table. 289 3.1.2. VLAN-Based Service PE 291 - Operates in Single Broadcast Domain per EVI. 293 In case of VLAN Based Service Interface on the receiving PE and with 294 the consideration of VLAN Based Service Interface on the advertising 295 PE: 297 - Operates in Single Broadcast Domain per EVI. 299 - MUST allow receiving of non-zero EtherTag. 301 - No Change in control-plane operation, the EVI import policy (route- 302 target) identifies the broadcast domain (bridge-table) within a MAC- 303 VRF. 305 - No Change to data-plane operation, the MPLS label identifies MAC- 306 VRF + bridge-table, or the VNI identifies the MAC-VRF + the bridge- 307 table. 309 While the expansion introduces additional configuration requirement 310 for the VLAN-Aware Bundle Service Interface, it also allows for 311 broader interoperability in the eventuality of Vendor "A" only 312 implemented VLAN-Based while Vendor "B" only implemented VLAN-Aware 313 Bundle Service Interface. 315 3.2. Service Interface Interop Mode of Operation 317 When Service Interface interoperability is required, a given PE 318 should follow this section's procedures for all its broadcast domains 319 (BDs) and not just the BDs that need interoperability. 321 For those BDs where interoperability between VLAN-Aware Bundle and 322 VLAN-Based Service Interface is needed, ignoring the presence of the 323 EVPN routes Ethernet Tag ID on the PEs supporting VLAN-Based mode is 324 not enough. Each PE needs to clearly signal what mode it supports, so 325 that all the PEs attached to the same EVI can understand in what mode 326 the EVI operates. 328 Consider a scenario where PE1 is attached to the BD range BD1-10 and 329 it operates in VLAN-Aware mode, whereas PE2 is attached to the BD 330 range BD7-20 and operates in VLAN-Based mode. Interoperability is 331 required for the intersecting BDs, I.e., BD7-10. 333 For PE1, this means BD7-10 need to be separated into a dedicated MAC- 334 VRF each. EVPN routes for each of these four MAC-VRFs MUST be 335 advertised by PE1 with an Ethernet Tag ID of zero. In this way, PE1 336 indicates the use of VLAN-Based mode for those BDs. On reception, PE1 337 imports the BD7-10 routes based on the Route Target and ignoring the 338 Ethernet Tag ID, as the Route Target alone is sufficient to identify 339 the correct MAC-VRF and Bridge Table. The remaining BDs on PE1 (range 340 BD1-6) continue operating in VLAN-Aware Bundle mode. 342 In the same example, other PEs attached to BD1-6 must still process 343 the received Ethernet Tag ID in the EVPN routes from PE1, so that 344 they can identify the correct Bridge Table in a given MAC-VRF. 346 PE2 operates in VLAN-Based mode for BD7-20, as per [RFC7432] and 347 [RFC8365]. PE2's EVPN route advertisements for BD7-20 will include 348 individual Route Targets per BD and an Ethernet Tag ID of zero. On 349 reception, PE2 identifies the MAC-VRF and Bridge Table solely based 350 on the Route Target. 352 4. Interoperability for different IRB Types 354 4.1. Asymmetric IRB and Symmetric IRB 356 The differences in the two inter-subnet forwarding modes, namely 357 Asymmetric IRB and Symmetric IRB, are beyond just the information 358 difference in the control-plane from an EVPN Route Type 2 359 perspective. The two IRB modes have significant differences in inter- 360 subnet forwarding behavior and as a result different operation during 361 label imposition or encapsulation. 363 With the Asymmetric IRB mode, the ingress PE performs a "bridge-and- 364 route" operation while the egress PE follows a "bridge-only" 365 approach. Differently, the forwarding behavior in Symmetric IRB mode 366 performs a "bridge-and-route" operation on the ingress PE followed by 367 a "route-and bridge" operation at the egress PE. The significance in 368 difference is not only in the forwarding behavior itself but also 369 around how the respective EVPN attribute are used for driving the 370 inter-subnet operation. More specifically, in the case of inter- 371 subnet forwarding with Asymmetric IRB, MPLS Label1 is used towards 372 the egress PE to specify the MAC-VRF and respective Bridge-Domain for 373 forwarding. In inter-subnet forwarding with Symmetric IRB, MPLS 374 Label2 associated with the IP-VRF is used for the inter-subnet 375 forwarding operation towards egress PE. 377 The respective forwarding behaviors are described in [EVPN- 378 INTERSUBNET]. The following steps are required to ensure the 379 interoperability between the Asymmetric and Symmetric IRB modes. 381 Asymmetric IRB Symmetric IRB 382 +--------------------------+ +--------------------------+ 383 | PE1 | | PE2 | 384 | +---------+ | | +---------+ | 385 | | +-----+ | | | | +-----+ | | 386 +-----| BD0 | +-IRB0-+ | | +-IRB0--+ | BD0 | | | 387 || | +-----+ | | | | | | +-----+ | | 388 || | | +---+----+ | | +---+----+ | | | 389 || |MAC-VRF1 | | | | | | | |MAC-VRF1 | | 390 || +---------+ |IP-VRF1 | |--------| |IP-VRF1 | +---------+ | 391 || | | | | | | | 392 || +---------+ +---+----+ | | +---+----+ +---------+ | 393 || | +-----+ | | | | | | +-----+ | | 394 || | | BD2 | +-IRB2-+ | | +-IRB2--+ | BD2 |-----+ 395 || | +-----+ | | | | +-----+ | || 396 || | | +-----+ | | +-----+ | | || 397 || |MAC-VRF2 | | BGP | | | | BGP | |MAC-VRF2 | || 398 || +---------+ +-----+ | | +-----+ +---------+ || 399 || | | || 400 |+--------------------------+ +--------------------------+| 401 | 2|MAC/IP, 1 Label| -----><----- 2|MAC/IP, 2 Label| | 402 | | 403 | +------+ +------+ | 404 +-|M1/IP1! |M2/IP2!-+ 405 +------+ +------+ 407 Figure 2: Asymmetric IRB and Symmetric IRB 409 Figure 2 illustrates the overview of and Asymmetric IRB PE (PE1) and 410 a Symmetric IRB PE (PE2) within a interoperability deployment 411 scenario. Attached to PE1, end-point M1/IP1 is attached to BD0 within 412 MAC-VRF1. Respectively, on PE2 end-point M2/IP2 is connected via 413 attachment circuit to BD2 positioned within MAC-VRF2. IRB0 and IRB2 414 represent the host-facing IRB interface for inter-subnet 415 communication between the different end-points located in the 416 different IP Subnet. The IRB interfaces for a common MAC-VRF/BD on 417 PE1 and PE2 use the same IP address. With the difference of the IRB 418 modes between PE1 (Asymmetric IRB) and PE2 (Symmetric IRB), there is 419 a difference in the MPLS Label presence as part of the MAC/IP routes 420 exchanged between the PEs. PE1s update contains a single label, 421 representing MPLS Label1 used for bridging purposes. PE2s 422 advertisement contains two labels, one for bridging and one for 423 routing, as part of the MAC/IP route. While PE1 receives all 424 information necessary from PE2, PE2 is missing information necessary 425 for its routing operation. As a result, Inter-Subnet routing between 426 PE1 and PE2 is not achieved. 428 By following the current existing forwarding behavior as described in 429 [EVPN-INTERSUBNET], interoperability is theoretically achievable 430 without changes in the control-plane format. Nevertheless, there are 431 steps required that involve predominantly the local behavior of the 432 PE with Symmetric IRB mode. 434 4.1.1. Asymmetric IRB PE 436 In case of Asymmetric IRB as the advertising PE and with Symmetric 437 IRB on the receiving PE: 439 - Asymmetric IRB PE MUST send MAC and IP information with MPLS Label1 440 as described in [EVPN-INTERSUBNET]. 442 In case of Symmetric IRB as the advertising PE and with Asymmetric 443 IRB on the receiving PE: 445 - Asymmetric IRB PE MUST be able to ignore MPLS Label2; [EVPN- 446 INTERSUBNET] already considers this. 448 4.1.2. Symmetric IRB PE 450 In case of Symmetric IRB as the advertising PE and with Asymmetric 451 IRB on the receiving PE: 453 - Symmetric IRB PE has no additional requirements. 455 In case of Asymmetric IRB as the advertising PE and with Symmetric 456 IRB on the receiving PE: 458 - Symmetric IRB PE requires to add the host-binding information, MAC 459 and IP, and associates them to the adjacency (ARP/ND) table facing 460 the PE with Asymmetric IRB; this is in addition of adding the MAC 461 address into the MAC-VRF table, using MPLS Label1. Since there is no 462 MPLS Label2 or Route-Target for the IP-VRF, the Host IP is not 463 specifically added to IP-VRF table. 465 4.2. IRB Interop Mode of Operation 467 Interoperability between the Asymmetric IRB and Symmetric IRB mode 468 follows specific defined behavior that is predominantly required on 469 the PE that operates in the Symmetric IRB mode. Nevertheless, in 470 support for the interoperability, the PE operating in Asymmetric IRB 471 must accommodate the following two minimal requirements (with 472 references to Figure 2): 1) The PE that operates in Asymmetric IRB 473 mode (PE1), MUST send the MAC/IP route including the Host IP address 474 and only MPLS Label1. 2) The PE with Asymmetric IRB (PE1) must accept 475 the MAC/IP routes sent from PE2 (Symmetric IRB), while ignoring the 476 additional information of MPLS Label2 and Route-Target of the IP-VRF. 478 In reference to 1), the PE MUST always send the end-point MAC 479 address, Host IP address and related MPLS Label1 as part of the 480 MAC/IP route towards the PE with Symmetric IRB (PE2). This route will 481 be sent only with MPLS Label1 and the Route-Target of the matching 482 MAC-VRF to achieve bridging. In reference to the illustration in 483 Figure 2, PE1 must generate and advertise an EVPN MAC/IP route using: 485 - MAC Length of 48 487 - MAC Address of M1 489 - IP Length of 32 / 128 491 - IP Address of IP1 493 - Label for MAC-VRF1 495 - Route-Target of MAC-VRF1 497 - Next-Hop PE1 499 For completeness of the requirements and in reference of 2), the 500 MAC/IP route advertised from the PE operating in Symmetric IRB (PE2) 501 is as follow: 503 - MAC Length of 48 505 - MAC Address of M2 507 - IP Length of 32 /128 509 - IP Address of IP2 511 - Label for MAC-VRF2, IP-VRF1 512 - Route-Target of MAC-VRF2, IP-VRF1 514 - Next-Hop PE2 516 As defined in 2), the Label and Route-Target information for IP-VRF1 517 MUST be ignored by PE1 (PE with Asymmetric IRB). 519 With PE2 operating in Symmetric IRB and with enabled interop mode, 520 the MAC/IP route from PE1 (Asymmetric IRB) is processed in the 521 respective bridging, routing and adjacency table. Based on the Route- 522 Target for MAC-VRF1, the MAC address M1 will be imported into MAC- 523 VRF1 respectively and placed within BD0. In addition, the host- 524 binding information M1/IP1 MUST be installed within PE2s adjacency 525 table. Subsequent, on PE2 the MAC address M1 and the host-binding 526 information (adjacency table entry) of M1/IP1 MUST point towards PE1 527 as the next-hop. With no presence of the Route-Target for IP-VRF1, 528 the IP address IP1 will not be specifically imported into IP-VRF1 and 529 is not associated with a MPLS Label2. As a result of the 530 interoperability, the additional efficiency provided by Symmetric IRB 531 in regards of preserving adjacency table exhaustion is reduced; this 532 is specifically when communicating with an Asymmetric IRB based 533 egress PE. In contrary, the interop mode allows for communication 534 between the different IRB modes. As a result, in the eventuality that 535 Vendor "A" only provides Asymmetric IRB, while Vendor "B" only has 536 Symmetric IRB available, interoperability for inter-subnet forwarding 537 can be seamlessly achieved. In addition, two further benefits are 538 present by implementing an Asymmetric/Symmetric Co-Existence on the 539 same PE (dual-mode PE). 541 - A dual-mode PE can seamlessly communicate with PE's that are either 542 in Asymmetric or in Symmetric IRB mode. 544 - A dual-mode PE can act as Anchor for interconnecting Symmetric IRB 545 and Asymmetric IRB based PE's (deployment restrictions might apply). 547 5. Interoperability for different IRB Core Connectivity Modes 549 5.1. Interface-Less and Interface-Ful Unnumbered IRB 551 The two modes, namely interface-less and interface-ful Unnumbered SBD 552 IRB, are closely related in regards to the information required in 553 the EVPN Route Type 5. While interface-less provides all information 554 for the IP prefix advertisement within the EVPN Route Type 5, in the 555 case of interface-ful Unnumbered SBD IRB, an additional EVPN Route 556 Type 2 is required for the next-hop recursive lookup. From a 557 forwarding behavior, both approaches are similar and follow a 558 symmetric routing approach but are not interoperable. Note as per 560 [EVPN-PREFIX] the interface-ful Unnumbered SBD IRB is an OPTIONAL 561 mode. 563 Interface-Ful 564 Interface-Less Unnumbered IRB 565 +--------------------------+ +--------------------------+ 566 | PE1 | | PE2 | 567 | +--------+ | | +--------+ | 568 | | | | | | | | 569 +----------------+ | |--------| | +----------------+ 570 || | | | | | | || 571 || | | | | | | || 572 || |IP-VRF1 | | | |IP-VRF1 | || 573 || +--------+ | | +--------+ || 574 || | | || 575 || +-----+ | | +-----+ || 576 || | BGP | | | | BGP | || 577 || +-----+ | | +-----+ || 578 |+--------------------------+ +--------------------------+| 579 | 2|None| -----> | 580 | <----- 5|No Label| | 581 | | 582 | +-------+ +-------+ | 583 +-|TS1/SN1| |TS2/SN2!-+ 584 +-------+ +-------+ 586 Figure 3: Interoperability of different IRB Core Connectivity Mode 587 (unnumbered) 589 The illustration in Figure 3 represents the possible deployment 590 scenario between two different Core IRB Connectivity modes. 591 Specifically, PE1 is operating with interface-less Core IRB Mode 592 while PE2 operates with the interface-ful Unnumbered SDB IRB mode; 593 both operate without interoperability capabilities. Attached to PE1 594 and PE2 respectively, Tenant System 1 (TS1) and Tenant System 2 (TS2) 595 with different IP Subnet are present. TS1 attached on PE1 as well as 596 TS2 attached to PE2 are represented in a common IP-VRF (IP-VRF1), 597 sharing a common Route-Target between the PEs. With the different IRB 598 Core Connectivity modes on PE1 and PE2 respectively, the differences 599 in IP prefix advertisements as described in [EVPN-PREFIX] are 600 present. PE1 advertises only a single EVPN Route Type 5 (IP Prefix 601 Route) for TS1 using the fields following the interface-less mode: 603 EVPN Route Type 5: 605 - IP Length of 0 to 32 / 0 to 128 606 - IP Address of SN1 608 - Label for IP-VRF1 610 - GW IP Address set to zero 612 - Route-Target of IP-VRF1 614 - Router's MAC Extended Community of PE1 616 - Next-Hop PE1 618 Differently, PE2 advertises an EVPN Route Type 2 (MAC/IP Route) next 619 to the EVPN Route Type 5 (IP Prefix Route). The MAC/IP Route supports 620 the requirement for recursive next-hop resolution for the next-hop 621 used in the IP Prefix Route. Below the fields used in the Route Type 622 5 and respective Route Type 2 according to the interface-ful 623 Unnumbered IRB mode: 625 EVPN Route Type 5: 627 - IP Length of 0 to 32 / 0 to 128 629 - IP Address of SN1 631 - Label SHOULD be set to 0 633 - GW IP Address SHOULD be set to zero 635 - Route-Target of IP-VRF1 637 - Router's MAC Extended Community of PE2 639 - Next-Hop PE2 641 EVPN Route Type 2: 643 - MAC Length of 48 645 - MAC Address of PE2 647 - IP Length of 0 649 - Label for IP-VRF1 651 - Route-Target of IP-VRF1 653 - Next-Hop PE2 654 While PE1 is missing the MPLS Label for the IP-VRF from PE2, PE2 is 655 missing the MPLS Label information and the necessary info for the 656 next-hop recursion. As a result, Routing with IP Prefix Advertisement 657 between PE1 and PE2 is not achieved. 659 By advertising an additional EVPN Route Type 2 from interface-less 660 (PE1) and by advertising the MPLS Label as part of EVPN Route Type 5 661 from PE2, interoperability is achievable. The specific mode of 662 operation would be as per the following two section and refers to 663 Figure 3 and Figure 4. 665 5.1.1. Interface-Less PE 667 In case of interface-less on the advertising PE and with the 668 consideration of interface-ful Unnumbered IRB as the receiving PE: 670 Shall generate and Advertise EVPN Route Type 2 for every IP-VRF 671 using. 673 - MAC Length of 48 675 - MAC Address with "Router MAC" 677 - IP Length of 0 679 - Label for IP-VRF 681 - Route-Target of IP-VRF 683 In case of interface-less on the receiving PE and with the 684 consideration of interface-ful Unnumbered IRB as the advertising PE: 686 - MUST ignore EVPN Route Type 2 with MPLS Label and route-target 687 matching the IP-VRF because there is no MAC-VRF defined matching 688 these information. 690 5.1.2. Interface-Ful Unnumbered IRB 692 In case of interface-ful Unnumbered on the advertising PE and with 693 the consideration of interface-less as the receiving PE: 695 - Shall advertise MPLS Label for IP-VRF in EVPN Route Type 5 with 696 matching route-target. 698 In case of interface-ful Unnumbered on the receiving PE and with the 699 consideration of interface-less as the advertising PE: 701 - No Additions Required. 703 Interface-Ful 704 Interface-Less Unnumbered IRB 705 +--------------------------+ +--------------------------+ 706 | PE1 | | PE2 | 707 | +--------+ | | +--------+ | 708 | | | | | | | | 709 +----------------+ | |--------| | +----------------+ 710 || | | | | | | || 711 || | | | | | | || 712 || | IP-VRF | | | | IP-VRF | || 713 || +--------+ | | +--------+ || 714 || | | || 715 || +-----+ | | +-----+ || 716 || | BGP | | | | BGP | || 717 || +-----+ | | +-----+ || 718 |+--------------------------+ +--------------------------+| 719 | 2|RMAC/RIP| -----> | 720 | <----- 5|Label| | 721 | | 722 | +-------+ +-------+ | 723 +-|TS1/SN1| |TS2/SN2!-+ 724 +-------+ +-------+ 726 Figure 4: Interop of different IRB Core Connectivity Types 727 (unnumbered) 729 Illustrated in Figure 4 are the additional requirements for 730 interface-less IRB Core Connectivity mode, specifically the MAC/IP 731 Route (EVPN Route Type 2) necessary for PE2s next-hop recursion. 732 Also, the MPLS Label addition within PE2s IP Prefix route (EVPN Route 733 Type 5) is represented, which is required for interface-ful 734 Unnumbered IRBs advertisement towards an interface-less PE (PE1) 736 The interop mode introduces additional control-plane advertisements 737 from an Interface-less perspective. This is necessary to allow 738 interface-ful Unnumbered SBD IRB to perform the recursive lookup 739 required. From a EVPN Type 5 perspective between the two types, most 740 of the fields are already equally defined and populated as per [EVPN- 741 PREFIX]. Exception is the IP-VRF Label, which is required to be added 742 in the interface-ful Unnumbered SBD IRB's EVPN Type 5. In addition, 743 the Interface-less addition allows the Co-Existence of both types on 744 the same PE (dual-mode PE). Such a dual-mode PE can communicate at 745 the same time with PE's that are in Interface-less or in interface- 746 ful Unnumbered SBD IRB mode. 748 The disadvantage of the additional advertisement has to be put into 749 relation to advantage of successful interoperability where eventualy 750 Vendor "A" only implemented interface-less while Vendor "B" only 751 implemented interface-ful Unnumbered SBD IRB. 753 5.2. Tunnel Encapsulation Consideration 755 In regards to IRB core connectivity both solutions, namely interface- 756 less and interface-ful, provide a solution for Layer 3 connectivity 757 among the IP-VRFs. Even as the functional result of both modes is the 758 same, there are important considerations in regards to tunnel 759 encapsulations. 761 [EVPN-IRB] section 4 considers the choice for the NVO tunnel should 762 be dictated by the tunnel capabilities. For example for the IP-VRF- 763 to-IP-VRF model with interface-less, the NVO tunnel for MPLS needs to 764 be IP NVO and for VXLAN needs to be Ethernet NVO. 766 With the "IP-VRF-to-IP-VRF" model that is used in interface-ful 767 (numbered or unnumbered), section 4.4.2 or 4.4.3 respectively 768 describe the solution to accommodate Ethernet NVO tunnels (VXLAN or 769 GPE, GENEVE, MPLS with MAC payload) only. In the case of interface- 770 ful unnumbered, the Router-MAC Extended Community is always signaled 771 via EVPN update message, which implies the presence of a MAC payload. 772 IP NVO Tunnel are not applicable to these two use-cases/models 774 Depending on the use of NVO tunnels, interoperability between 775 interface-les and interface-ful unnumbered requires additional 776 changes on the Tunnel Encapsulation mode. This Internet-Draft 777 considers the usage of a compatible NVO Tunnel mode between a PE 778 operating in interface-les and a PE operating nterface-ful unnumbered 779 mode. 781 6. Security Considerations 783 TBD. 785 7. IANA Considerations 787 TBD. 789 8. References 791 8.1. Normative References 793 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 794 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 795 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 796 2015, . 798 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 799 Uttaro, J., and W. Henderickx, "A Network Virtualization 800 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 801 10.17487/RFC8365, March 2018, . 804 [EVPN-INTERSUBNET] Sajassi et al., "Integrated Routing and Bridging 805 in EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-13, 806 work in progress, February, 2021. 808 [EVPN-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN", 809 draft-ietf-bess-evpn-prefix-advertisement-11, May 2018. 811 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, DOI 813 10.17487/RFC2119, March 1997, . 816 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, DOI 817 10.17487/RFC1776, April 1 1995, . 820 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 821 10.17487/RFC1925, April 1 1996, . 824 8.2. Informative References 826 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., 827 Patel, K., and J. Guichard, "Constrained Route 828 Distribution for Border Gateway Protocol/MultiProtocol 829 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 830 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 831 November 2006, . 833 [EANTC] EANTC, "Multi-Vendor Interoperability Test", February 2019, 834 . 837 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 838 RFC 3514, DOI 10.17487/RFC3514, April 1 2003, 839 . 841 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 842 Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 1 2009, 843 . 845 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, DOI 846 10.17487/RFC5514, April 1 2009, . 849 9. Conclusion 851 With minimal additions, the most common EVPN types for Virtual 852 Identifiers to EVI Mapping, Integrated Routing and Bridging and IP 853 Prefix Advertisement can be made interoperable. The aim for 854 interoperability doesn't remove the requirement for optimized types 855 for different use-cases but allows flexibility and basic 856 interoperability. 858 9.1. Demonstration of Applicability 860 Cisco, Juniper and Nokia demonstrated successfully the ability of 861 EVPN interoperability modes during EANTCs yearly "Multi-Vendor 862 Interoperability Test". The Whitepaper can be obtained through EANTC 863 with the latest version being available at [EANTC]. 865 9.1.1. Service Interface Interoperability 867 A proof of the benefit with this interoperability mode has already 868 been demonstrated during EVPN Multi-Vendor interoperability testing 869 and also, in production environments. Specifically, Cisco and Nokia's 870 VLAN-Based Service Interface successful proofed interoperability with 871 Junipers VLAN-Aware Bundle Service Interface. 873 9.1.2. IRB Types 875 A proof of the benefit with this interoperability mode has already 876 successfully demonstrated during EVPN Multi-Vendor interoperability 877 testing. Specifically, Cisco operated in a Hybrid IRB (Dual-Mode) 878 mode while other Vendor operated in an Asymmetric IRB mode. 879 Forwarding was achieved through dynamic detection of the alternate 880 Vendor PE's mode and adjustment to Asymmetric IRB for these specific 881 BDs. Communication for all other BDs continued to be Symmetric IRB. 883 9.1.3. IRB Core Connectivity Types 884 A proof of an interoperability mode between interface-less and 885 interface-ful Unnumbered SBD IRB has already been demonstrated in 886 production environments and during EVPN Multi-Vendor interoperability 887 testing. Specifically, Cisco's addition for Interface-less is 888 successfully deployed with Nokia's and Nuage's interface-ful 889 Unnumbered SBD IRB at customers 891 10. Authors' Addresses 893 Lukas Krattiger 894 Cisco 895 USA 896 EMail: lkrattig@cisco.com 898 Ali Sajassi 899 Cisco 900 USA 901 EMail: sajassi@cisco.com 903 Samir Thoria 904 Cisco 905 USA 906 EMail: sthoria@cisco.com 908 Jorge Rabadan 909 Nokia 910 777 E. Middlefield Road 911 Mountain View, CA 94043 USA 912 EMail: jorge.rabadan@nokia.com 914 John E. Drake 915 Juniper 916 EMail: jdrake@juniper.net