idnits 2.17.1 draft-krattiger-evpn-modes-interop-03.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 (January 25, 2021) is 1185 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 764, but not defined == Unused Reference: 'KEYWORDS' is defined on line 813, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 847, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-11 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: July 29, 2021 S. Thoria 5 Cisco Systems 7 J. Rabadan 8 Nokia 10 J. Drake 11 Juniper 13 January 25, 2021 15 EVPN Interoperability Modes 16 draft-krattiger-evpn-modes-interop-03 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . 20 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. 283 - No Change to data-plane operation, the MPLS label identifies MAC- 284 VRF + bridge-table, or the VNI identifies the MAC-VRF + the bridge- 285 table. 287 3.1.2. VLAN-Based Service PE 289 - Operates in Single Broadcast Domain per EVI. 291 In case of VLAN Based Service Interface on the receiving PE and with 292 the consideration of VLAN Based Service Interface on the advertising 293 PE: 295 - Operates in Single Broadcast Domain per EVI. 297 - MUST allow receiving of non-zero EtherTag. 299 - No Change in control-plane operation, the EVI import policy (route- 300 target) identifies the broadcast domain (bridge-table) within a MAC- 301 VRF. 303 - No Change to data-plane operation, the MPLS label identifies MAC- 304 VRF + bridge-table, or the VNI identifies the MAC-VRF + the bridge- 305 table. 307 While the expansion introduces additional configuration requirement 308 for the VLAN-Aware Bundle Service Interface, it also allows for 309 broader interoperability in the eventuality of Vendor "A" only 310 implemented VLAN-Based while Vendor "B" only implemented VLAN-Aware 311 Bundle Service Interface. 313 3.2. Service Interface Interop Mode of Operation 315 When Service Interface interoperability is required, a given PE 316 should follow this section's procedures for all its broadcast domains 317 (BDs) and not just the BDs that need interoperability. 319 For those BDs where interoperability between VLAN-Aware Bundle and 320 VLAN-Based Service Interface is needed, ignoring the presence of the 321 EVPN routes Ethernet Tag ID on the PEs supporting VLAN-Based mode is 322 not enough. Each PE needs to clearly signal what mode it supports, so 323 that all the PEs attached to the same EVI can understand in what mode 324 the EVI operates. 326 Consider a scenario where PE1 is attached to the BD range BD1-10 and 327 it operates in VLAN-Aware mode, whereas PE2 is attached to the BD 328 range BD7-20 and operates in VLAN-Based mode. Interoperability is 329 required for the intersecting BDs, I.e., BD7-10. 331 For PE1, this means BD7-10 need to be separated into a dedicated MAC- 332 VRF each. EVPN routes for each of these four MAC-VRFs MUST be 333 advertised by PE1 with an Ethernet Tag ID of zero. In this way, PE1 334 indicates the use of VLAN-Based mode for those BDs. On reception, PE1 335 imports the BD7-10 routes based on the Route Target and ignoring the 336 Ethernet Tag ID, as the Route Target alone is sufficient to identify 337 the correct MAC-VRF and Bridge Table. The remaining BDs on PE1 (range 338 BD1-6) continue operating in VLAN-Aware Bundle mode. 340 In the same example, other PEs attached to BD1-6 must still process 341 the received Ethernet Tag ID in the EVPN routes from PE1, so that 342 they can identify the correct Bridge Table in a given MAC-VRF. 344 PE2 operates in VLAN-Based mode for BD7-20, as per [RFC7432] and 345 [RFC8365]. PE2's EVPN route advertisements for BD7-20 will include 346 individual Route Targets per BD and an Ethernet Tag ID of zero. On 347 reception, PE2 identifies the MAC-VRF and Bridge Table solely based 348 on the Route Target. 350 4. Interoperability for different IRB Types 352 4.1. Asymmetric IRB and Symmetric IRB 354 The differences in the two inter-subnet forwarding modes, namely 355 Asymmetric IRB and Symmetric IRB, are beyond just the information 356 difference in the control-plane from an EVPN Route Type 2 357 perspective. The two IRB modes have significant differences in inter- 358 subnet forwarding behavior and as a result different operation during 359 label imposition or encapsulation. 361 With the Asymmetric IRB mode, the ingress PE performs a "bridge-and- 362 route" operation while the egress PE follows a "bridge-only" 363 approach. Differently, the forwarding behavior in Symmetric IRB mode 364 performs a "bridge-and-route" operation on the ingress PE followed by 365 a "route-and bridge" operation at the egress PE. The significance in 366 difference is not only in the forwarding behavior itself but also 367 around how the respective EVPN attribute are used for driving the 368 inter-subnet operation. More specifically, in the case of inter- 369 subnet forwarding with Asymmetric IRB, MPLS Label1 is used towards 370 the egress PE to specify the MAC-VRF and respective Bridge-Domain for 371 forwarding. In inter-subnet forwarding with Symmetric IRB, MPLS 372 Label2 associated with the IP-VRF is used for the inter-subnet 373 forwarding operation towards egress PE. 375 The respective forwarding behaviors are described in [EVPN- 376 INTERSUBNET]. The following steps are required to ensure the 377 interoperability between the Asymmetric and Symmetric IRB modes. 379 Asymmetric IRB Symmetric IRB 380 +--------------------------+ +--------------------------+ 381 | PE1 | | PE2 | 382 | +---------+ | | +---------+ | 383 | | +-----+ | | | | +-----+ | | 384 +-----| BD0 | +-IRB0-+ | | +-IRB0--+ | BD0 | | | 385 || | +-----+ | | | | | | +-----+ | | 386 || | | +---+----+ | | +---+----+ | | | 387 || |MAC-VRF1 | | | | | | | |MAC-VRF1 | | 388 || +---------+ |IP-VRF1 | |--------| |IP-VRF1 | +---------+ | 389 || | | | | | | | 390 || +---------+ +---+----+ | | +---+----+ +---------+ | 391 || | +-----+ | | | | | | +-----+ | | 392 || | | BD2 | +-IRB2-+ | | +-IRB2--+ | BD2 |-----+ 393 || | +-----+ | | | | +-----+ | || 394 || | | +-----+ | | +-----+ | | || 395 || |MAC-VRF2 | | BGP | | | | BGP | |MAC-VRF2 | || 396 || +---------+ +-----+ | | +-----+ +---------+ || 397 || | | || 398 |+--------------------------+ +--------------------------+| 399 | 2|MAC/IP, 1 Label| -----><----- 2|MAC/IP, 2 Label| | 400 | | 401 | +------+ +------+ | 402 +-|M1/IP1! |M2/IP2!-+ 403 +------+ +------+ 405 Figure 2: Asymmetric IRB and Symmetric IRB 407 Figure 2 illustrates the overview of and Asymmetric IRB PE (PE1) and 408 a Symmetric IRB PE (PE2) within a interoperability deployment 409 scenario. Attached to PE1, end-point M1/IP1 is attached to BD0 within 410 MAC-VRF1. Respectively, on PE2 end-point M2/IP2 is connected via 411 attachment circuit to BD2 positioned within MAC-VRF2. IRB0 and IRB2 412 represent the host-facing IRB interface for inter-subnet 413 communication between the different end-points located in the 414 different IP Subnet. The IRB interfaces for a common MAC-VRF/BD on 415 PE1 and PE2 use the same IP address. With the difference of the IRB 416 modes between PE1 (Asymmetric IRB) and PE2 (Symmetric IRB), there is 417 a difference in the MPLS Label presence as part of the MAC/IP routes 418 exchanged between the PEs. PE1s update contains a single label, 419 representing MPLS Label1 used for bridging purposes. PE2s 420 advertisement contains two labels, one for bridging and one for 421 routing, as part of the MAC/IP route. While PE1 receives all 422 information necessary from PE2, PE2 is missing information necessary 423 for its routing operation. As a result, Inter-Subnet routing between 424 PE1 and PE2 is not achieved. 426 By following the current existing forwarding behavior as described in 427 [EVPN-INTERSUBNET], interoperability is theoretically achievable 428 without changes in the control-plane format. Nevertheless, there are 429 steps required that involve predominantly the local behavior of the 430 PE with Symmetric IRB mode. 432 4.1.1. Asymmetric IRB PE 434 In case of Asymmetric IRB as the advertising PE and with Symmetric 435 IRB on the receiving PE: 437 - Asymmetric IRB PE MUST send MAC and IP information with MPLS 438 Label1. 440 In case of Symmetric IRB as the advertising PE and with Asymmetric 441 IRB on the receiving PE: 443 - Asymmetric IRB PE MUST be able to ignore MPLS Label2. 445 4.1.2. Symmetric IRB PE 447 In case of Symmetric IRB as the advertising PE and with Asymmetric 448 IRB on the receiving PE: 450 - Symmetric IRB PE has no additional requirements. 452 In case of Asymmetric IRB as the advertising PE and with Symmetric 453 IRB on the receiving PE: 455 - Symmetric IRB PE requires to add the host-binding information, MAC 456 and IP, and associates them to the adjacency (ARP/ND) table facing 457 the PE with Asymmetric IRB; this is in addition of adding the MAC 458 address into the MAC-VRF table. Since there is no MPLS Label2 or 459 Route-Target for the IP-VRF, the Host IP is not specifically added to 460 IP-VRF table. 462 4.2. IRB Interop Mode of Operation 464 Interoperability between the Asymmetric IRB and Symmetric IRB mode 465 follows specific defined behavior that is predominantly required on 466 the PE that operates in the Symmetric IRB mode. Nevertheless, in 467 support for the interoperability, the PE operating in Asymmetric IRB 468 MUST accommodate the following two minimal requirements (with 469 references to Figure 2): 1) The PE that operates in Asymmetric IRB 470 mode (PE1), MUST send the MAC/IP route including the Host IP address. 471 2) The PE with Asymmetric IRB (PE1) MUST accept the MAC/IP routes 472 sent from PE2 (Symmetric IRB), while ignoring the additional 473 information of MPLS Label2 and Route-Target of the IP-VRF. 475 In reference to 1), the PE MUST always send the end-point MAC 476 address, Host IP address and related MPLS Label1 as part of the 477 MAC/IP route towards the PE with Symmetric IRB (PE2). This route will 478 be sent only with MPLS Label1 and the Route-Target of the matching 479 MAC-VRF. In reference to the illustration in Figure 2, PE1 MUST 480 generate and advertise an EVPN MAC/IP route using: 482 - MAC Length of 48 484 - MAC Address of M1 486 - IP Length of 32 / 128 488 - IP Address of IP1 490 - Label for MAC-VRF1 492 - Route-Target of MAC-VRF1 494 - Next-Hop PE1 496 For completeness of the requirements and in reference of 2), the 497 MAC/IP route advertised from the PE operating in Symmetric IRB (PE2) 498 is as follow: 500 - MAC Length of 48 502 - MAC Address of M2 504 - IP Length of 32 /128 506 - IP Address of IP2 508 - Label for MAC-VRF2, IP-VRF1 509 - Route-Target of MAC-VRF2, IP-VRF1 511 - Next-Hop PE2 513 As defined in 2), the Label and Route-Target information for IP-VRF1 514 MUST be ignored by PE1 (PE with Asymmetric IRB). 516 With PE2 operating in Symmetric IRB and with enabled interop mode, 517 the MAC/IP route from PE1 (Asymmetric IRB) is processed in the 518 respective bridging, routing and adjacency table. Based on the Route- 519 Target for MAC-VRF1, the MAC address M1 will be imported into MAC- 520 VRF1 respectively and placed within BD0. In addition, the host- 521 binding information M1/IP1 MUST be installed within PE2s adjacency 522 table. Subsequent, on PE2 the MAC address M1 and the host-binding 523 information (adjacency table entry) of M1/IP1 MUST point towards PE1 524 as the next-hop. With no presence of the Route-Target for IP-VRF1, 525 the IP address IP1 will not be specifically imported into IP-VRF1 and 526 is not associated with a MPLS Label2. As a result of the 527 interoperability, the additional efficiency provided by Symmetric IRB 528 in regards of preserving adjacency table exhaustion is reduced; this 529 is specifically when communicating with an Asymmetric IRB based 530 egress PE. In contrary, the interop mode allows for communication 531 between the different IRB modes. As a result, in the eventuality that 532 Vendor "A" only provides Asymmetric IRB, while Vendor "B" only has 533 Symmetric IRB available, interoperability for inter-subnet forwarding 534 can be seamlessly achieved. In addition, two further benefits are 535 present by implementing an Asymmetric/Symmetric Co-Existence on the 536 same PE (dual-mode PE). 538 - A dual-mode PE can seamlessly communicate with PE's that are either 539 in Asymmetric or in Symmetric IRB mode. 541 - A dual-mode PE can act as Anchor for interconnecting Symmetric IRB 542 and Asymmetric IRB based PE's (deployment restrictions might apply). 544 5. Interoperability for different IRB Core Connectivity Modes 546 5.1. Interface-Less and Interface-Ful Unnumbered IRB 548 The two modes, namely interface-less and interface-ful Unnumbered SBD 549 IRB, are closely related in regards to the information required in 550 the EVPN Route Type 5. While interface-less provides all information 551 for the IP prefix advertisement within the EVPN Route Type 5, in the 552 case of interface-ful Unnumbered SBD IRB, an additional EVPN Route 553 Type 2 is required for the next-hop recursive lookup. From a 554 forwarding behavior, both approaches are similar and follow a 555 symmetric routing approach but are not interoperable. Note as per 557 [EVPN-PREFIX] the interface-ful Unnumbered SBD IRB is an OPTIONAL 558 mode. 560 Interface-Ful 561 Interface-Less Unnumbered IRB 562 +--------------------------+ +--------------------------+ 563 | PE1 | | PE2 | 564 | +--------+ | | +--------+ | 565 | | | | | | | | 566 +----------------+ | |--------| | +----------------+ 567 || | | | | | | || 568 || | | | | | | || 569 || |IP-VRF1 | | | |IP-VRF1 | || 570 || +--------+ | | +--------+ || 571 || | | || 572 || +-----+ | | +-----+ || 573 || | BGP | | | | BGP | || 574 || +-----+ | | +-----+ || 575 |+--------------------------+ +--------------------------+| 576 | 2|None| -----> | 577 | <----- 5|No Label| | 578 | | 579 | +-------+ +-------+ | 580 +-|TS1/SN1| |TS2/SN2!-+ 581 +-------+ +-------+ 583 Figure 3: Interoperability of different IRB Core Connectivity Mode 584 (unnumbered) 586 The illustration in Figure 3 represents the possible deployment 587 scenario between two different Core IRB Connectivity modes. 588 Specifically, PE1 is operating with interface-less Core IRB Mode 589 while PE2 operates with the interface-ful Unnumbered SDB IRB mode; 590 both operate without interoperability capabilities. Attached to PE1 591 and PE2 respectively, Tenant System 1 (TS1) and Tenant System 2 (TS2) 592 with different IP Subnet are present. TS1 attached on PE1 as well as 593 TS2 attached to PE2 are represented in a common IP-VRF (IP-VRF1), 594 sharing a common Route-Target between the PEs. With the different IRB 595 Core Connectivity modes on PE1 and PE2 respectively, the differences 596 in IP prefix advertisements as described in [EVPN-PREFIX] are 597 present. PE1 advertises only a single EVPN Route Type 5 (IP Prefix 598 Route) for TS1 using the fields following the interface-less mode: 600 EVPN Route Type 5: 602 - IP Length of 0 to 32 / 0 to 128 603 - IP Address of SN1 605 - Label for IP-VRF1 607 - GW IP Address set to zero 609 - Route-Target of IP-VRF1 611 - Router's MAC Extended Community of PE1 613 - Next-Hop PE1 615 Differently, PE2 advertises an EVPN Route Type 2 (MAC/IP Route) next 616 to the EVPN Route Type 5 (IP Prefix Route). The MAC/IP Route supports 617 the requirement for recursive next-hop resolution for the next-hop 618 used in the IP Prefix Route. Below the fields used in the Route Type 619 5 and respective Route Type 2 according to the interface-ful 620 Unnumbered IRB mode: 622 EVPN Route Type 5: 624 - IP Length of 0 to 32 / 0 to 128 626 - IP Address of SN1 628 - Label SHOULD be set to 0 630 - GW IP Address SHOULD be set to " 632 - Route-Target of IP-VRF1 634 - Router's MAC Extended Community of PE2 636 - Next-Hop PE2 638 EVPN Route Type 2: 640 - MAC Length of 48 642 - MAC Address of PE2 644 - IP Length of 32 / 128 646 - IP Address of PE2 648 - Label for IP-VRF1 650 - Route-Target of IP-VRF1 651 - Next-Hop PE2 653 While PE1 is missing the MPLS Label for the IP-VRF from PE2, PE2 is 654 missing the MPLS Label information and the necessary info for the 655 next-hop recursion. As a result, Routing with IP Prefix Advertisement 656 between PE1 and PE2 is not achieved. 658 By advertising an additional EVPN Route Type 2 from interface-less 659 (PE1) and by advertising the MPLS Label as part of EVPN Route Type 5 660 from PE2, interoperability is achievable. The specific mode of 661 operation would be as per the following two section and refers to 662 Figure 3 and Figure 4. 664 5.1.1. Interface-Less PE 666 In case of interface-less on the advertising PE and with the 667 consideration of interface-ful Unnumbered IRB as the receiving PE: 669 Shall generate and Advertise EVPN Route Type 2 for every IP-VRF 670 using. 672 - MAC Length of 48 674 - MAC Address with "Router MAC" 676 - IP Length of 32 678 - IP Address with NVE IP 680 - Label for IP-VRF 682 - Route-Target of IP-VRF 684 - Router-MAC Extended Community 686 In case of interface-less on the receiving PE and with the 687 consideration of interface-ful Unnumbered IRB as the advertising PE: 689 - MUST ignore EVPN Route Type 2 with MPLS Label and route-target 690 matching the IP-VRF because there is no MAC-VRF defined matching 691 these information. 693 5.1.2. Interface-Ful Unnumbered IRB 695 In case of interface-ful Unnumbered on the advertising PE and with 696 the consideration of interface-less as the receiving PE: 698 - Shall advertise MPLS Label for IP-VRF in EVPN Route Type 5 with 699 matching route-target. 701 In case of interface-ful Unnumbered on the receiving PE and with the 702 consideration of interface-less as the advertising PE: 704 - No Additions Required. 706 Interface-Ful 707 Interface-Less Unnumbered IRB 708 +--------------------------+ +--------------------------+ 709 | PE1 | | PE2 | 710 | +--------+ | | +--------+ | 711 | | | | | | | | 712 +----------------+ | |--------| | +----------------+ 713 || | | | | | | || 714 || | | | | | | || 715 || | IP-VRF | | | | IP-VRF | || 716 || +--------+ | | +--------+ || 717 || | | || 718 || +-----+ | | +-----+ || 719 || | BGP | | | | BGP | || 720 || +-----+ | | +-----+ || 721 |+--------------------------+ +--------------------------+| 722 | 2|RMAC/RIP| -----> | 723 | <----- 5|Label| | 724 | | 725 | +-------+ +-------+ | 726 +-|TS1/SN1| |TS2/SN2!-+ 727 +-------+ +-------+ 729 Figure 4: Interop of different IRB Core Connectivity Types 730 (unnumbered) 732 Illustrated in Figure 4 are the additional requirements for 733 interface-less IRB Core Connectivity mode, specifically the MAC/IP 734 Route (EVPN Route Type 2) necessary for PE2s next-hop recursion. 735 Also, the MPLS Label addition within PE2s IP Prefix route (EVPN Route 736 Type 5) is represented, which is required for interface-ful 737 Unnumbered IRBs advertisement towards an interface-less PE (PE1) 739 The interop mode introduces additional control-plane advertisements 740 from an Interface-less perspective. This is necessary to allow 741 interface-ful Unnumbered SBD IRB to perform the recursive lookup 742 required. From a EVPN Type 5 perspective between the two types, most 743 of the fields are already equally defined and populated as per [EVPN- 744 PREFIX]. Exception is the IP-VRF Label, which is required to be added 745 in the interface-ful Unnumbered SBD IRB's EVPN Type 5. In addition, 746 the Interface-less addition allows the Co-Existence of both types on 747 the same PE (dual-mode PE). Such a dual-mode PE can communicate at 748 the same time with PE's that are in Interface-less or in interface- 749 ful Unnumbered SBD IRB mode. 751 The disadvantage of the additional advertisement has to be put into 752 relation to advantage of successful interoperability where eventualy 753 Vendor "A" only implemented interface-less while Vendor "B" only 754 implemented interface-ful Unnumbered SBD IRB. 756 5.2. Tunnel Encapsulation Consideration 758 In regards to IRB core connectivity both solutions, namely interface- 759 less and interface-ful, provide a solution for Layer 3 connectivity 760 among the IP-VRFs. Even as the functional result of both modes is the 761 same, there are important considerations in regards to tunnel 762 encapsulations. 764 [EVPN-IRB] section 4 considers the choice for the NVO tunnel should 765 be dictated by the tunnel capabilities. For example for the IP-VRF- 766 to-IP-VRF model with interface-less, the NVO tunnel for MPLS needs to 767 be IP NVO and for VXLAN needs to be Ethernet NVO. 769 With the "IP-VRF-to-IP-VRF" model that is used in interface-ful 770 (numbered or unnumbered), section 4.4.2 or 4.4.3 respectively 771 describe the solution to accommodate Ethernet NVO tunnels (VXLAN or 772 GPE, GENEVE, MPLS with MAC payload) only. In the case of interface- 773 ful unnumbered, the Router-MAC Extended Community is always signaled 774 via EVPN update message, which implies the presence of a MAC payload. 775 IP NVO Tunnel are not applicable to these two use-cases/models 777 Depending on the use of NVO tunnels, interoperability between 778 interface-les and interface-ful unnumbered requires additional 779 changes on the Tunnel Encapsulation mode. This Internet-Draft 780 considers the usage of a compatible NVO Tunnel mode between a PE 781 operating in interface-les and a PE operating nterface-ful unnumbered 782 mode. 784 6. Security Considerations 786 TBD. 788 7. IANA Considerations 789 TBD. 791 8. References 793 8.1. Normative References 795 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 796 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 797 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 798 2015, . 800 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 801 Uttaro, J., and W. Henderickx, "A Network Virtualization 802 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 803 10.17487/RFC8365, March 2018, . 806 [EVPN-INTERSUBNET] Sajassi et al., "Integrated Routing and Bridging 807 in EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-11, 808 work in progress, October, 2020. 810 [EVPN-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN", 811 draft-ietf-bess-evpn-prefix-advertisement-11, May 2018. 813 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 814 Requirement Levels", BCP 14, RFC 2119, DOI 815 10.17487/RFC2119, March 1997, . 818 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, DOI 819 10.17487/RFC1776, April 1 1995, . 822 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 823 10.17487/RFC1925, April 1 1996, . 826 8.2. Informative References 828 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., 829 Patel, K., and J. Guichard, "Constrained Route 830 Distribution for Border Gateway Protocol/MultiProtocol 831 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 832 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 833 November 2006, . 835 [EANTC] EANTC, "Multi-Vendor Interoperability Test", February 2019, 836 . 839 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 840 RFC 3514, DOI 10.17487/RFC3514, April 1 2003, 841 . 843 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 844 Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 1 2009, 845 . 847 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, DOI 848 10.17487/RFC5514, April 1 2009, . 851 9. Conclusion 853 With minimal additions, the most common EVPN types for Virtual 854 Identifiers to EVI Mapping, Integrated Routing and Bridging and IP 855 Prefix Advertisement can be made interoperable. The aim for 856 interoperability doesn't remove the requirement for optimized types 857 for different use-cases but allows flexibility and basic 858 interoperability. 860 9.1. Demonstration of Applicability 862 Cisco, Juniper and Nokia demonstrated successfully the ability of 863 EVPN interoperability modes during EANTCs yearly "Multi-Vendor 864 Interoperability Test". The Whitepaper can be obtained through EANTC 865 with the latest version being available at [EANTC]. 867 9.1.1. Service Interface Interoperability 869 A proof of the benefit with this interoperability mode has already 870 been demonstrated during EVPN Multi-Vendor interoperability testing 871 and also, in production environments. Specifically, Cisco and Nokia's 872 VLAN-Based Service Interface successful proofed interoperability with 873 Junipers VLAN-Aware Bundle Service Interface. 875 9.1.2. IRB Types 877 A proof of the benefit with this interoperability mode has already 878 successfully demonstrated during EVPN Multi-Vendor interoperability 879 testing. Specifically, Cisco operated in a Hybrid IRB (Dual-Mode) 880 mode while other Vendor operated in an Asymmetric IRB mode. 881 Forwarding was achieved through dynamic detection of the alternate 882 Vendor PE's mode and adjustment to Asymmetric IRB for these specific 883 BDs. Communication for all other BDs continued to be Symmetric IRB. 885 9.1.3. IRB Core Connectivity Types 887 A proof of an interoperability mode between interface-less and 888 interface-ful Unnumbered SBD IRB has already been demonstrated in 889 production environments and during EVPN Multi-Vendor interoperability 890 testing. Specifically, Cisco's addition for Interface-less is 891 successfully deployed with Nokia's and Nuage's interface-ful 892 Unnumbered SBD IRB at customers 894 10. Authors' Addresses 896 Lukas Krattiger 897 Cisco 898 USA 899 EMail: lkrattig@cisco.com 901 Ali Sajassi 902 Cisco 903 USA 904 EMail: sajassi@cisco.com 906 Samir Thoria 907 Cisco 908 USA 909 EMail: sthoria@cisco.com 911 Jorge Rabadan 912 Nokia 913 777 E. Middlefield Road 914 Mountain View, CA 94043 USA 915 EMail: jorge.rabadan@nokia.com 916 John E. Drake 917 Juniper 918 EMail: jdrake@juniper.net