idnits 2.17.1 draft-krattiger-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 (July 21, 2019) is 1741 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 122, but not defined == Missing Reference: 'RFC8174' is mentioned on line 122, but not defined == Unused Reference: 'KEYWORDS' is defined on line 784, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 810, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 814, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 818, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-08 Summary: 1 error (**), 0 flaws (~~), 10 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: January 22, 2020 S. Thoria 5 Cisco Systems 7 J. Rabadan 8 Nokia 10 J. Drake 11 Juniper 13 July 21, 2019 15 EVPN Interoperability Modes 16 draft-krattiger-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 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 87 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 9.1. Demonstration of Applicability . . . . . . . . . . . . . . 19 89 9.1.1. Service Interface Interoperability . . . . . . . . . . 19 90 9.1.2. IRB Types . . . . . . . . . . . . . . . . . . . . . . 19 91 9.1.3. IRB Core Connectivity Types . . . . . . . . . . . . . 19 92 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 Ethernet VPN (EVPN) provides different functional modes in the area 97 of Service Interface, Integrated Route and Bridge (IRB) and IRB 98 connection model. It is understood that the different modes are 99 defined with different use-cases in mind. Even with the specific use- 100 cases and the resulting mode definition, the aim of interoperability 101 is critical. 102 The following EVPN modes are considered for interoperability. It is 103 limited to most pertinent interop modes as oppose to all 104 permutations. In the future if other modes are identified, it will be 105 addressed in future revisions. 107 - For Service Interfaces, the VLAN Aware Bundle and VLAN Based types. 109 - In Integrated Routing and Bridging (IRB) the Asymmetric IRB and 110 Symmetric IRB type. 112 - Within the IRB connectivity types, interface-less and the 113 interface-ful Unnumbered IRB. 115 1.1 Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 2. Valid Combinations for Interoperability 125 The tables below provide an overview of the valid combinations for 126 interoperability described in this Internet-Draft. 128 For the Service Interface Types as described in [RFC7432] section 6 129 and [RFC8365] section 5.1.2. Interoperability considerations are 130 provided for the VLAN-Based Service interface ([RFC7432], section 131 6.1) and the VLAN-Aware Bundle Service Interface type ([RFC7432] 132 section 6.3). The VLAN Bundle Service Interface ([RFC7432] section 133 6.2) is not considered at this time. 135 Table 1 represent the considered Service Interface Types 136 interoperability: 138 +-------------------+------------+-------------+--------------------+ 139 | | VLAN-Based | VLAN Bundle | VLAN-Aware Bundle | 140 +-------------------+------------+-------------+--------------------+ 141 | VLAN-Based | YES | NO | YES | 142 +-------------------+------------+-------------+--------------------+ 143 | VLAN Bundle | NO | YES | NO | 144 +-------------------+------------+-------------+--------------------+ 145 | VLAN-Aware Bundle | YES | NO | YES | 146 +-------------------+------------+-------------+--------------------+ 147 Table 1 149 In regards to Integrated Route and Bridge (IRB), two different modes 150 are defined in [EVPN-INTERSUBNET], with section 3.2 describing 151 Symmetric IRB and section 3.3 Asymmetric IRB: 153 The interoperability considerations for Asymmetric IRB and 154 Symmetric IRB mode are represented within this Internet-Draft. 156 For the IRB Core Connectivity, from all the available modes as 157 described in [EVPN-PREFIX], considered for interoperability is the 158 interface-less mode (section 4.4.1) in conjunction with only one of 159 the interface-ful modes, namely interface-ful IP-VRF-to-IP-VRF with 160 Unnumbered SBD IRB (section 4.4.3). With the implementation 161 proximation between the two interface-ful modes, considerations for 162 interoperability between interface-less and interface-ful Numbered 163 are currently not considered. Similarly, the interoperability between 164 the two interface-ful modes is currently not being considered, given 165 the already close relation and to limit permutations. Future 166 revisions of this Internet-Draft might address further variations of 167 interoperability. 169 Table 2 represent the considered IRB Core Connectivity 170 interoperability. 172 +-----------------+----------------+---------------+----------------+ 173 | | Interface-Less | Interface-Ful | Interface-Ful | 174 | | | Numbered IRB | Unnumbered IRB | 175 +-----------------+----------------+---------------+----------------+ 176 | Interface-Less | YES | NO | YES | 177 +-----------------+----------------+---------------+----------------+ 178 | Interface-Ful | NO | YES | NO | 179 | Numbered IRB | | | | 180 +-----------------+----------------+---------------+----------------+ 181 | Interface-Ful | YES | NO | YES | 182 | Unnumbered IRB | | | | 183 +-----------------+----------------+---------------+----------------+ 184 Table 2 186 3. Service Interface Interoperability 188 3.1. VLAN-Aware Bundle and VLAN-Based 190 [RFC7432] section 6 describes three different Service Interface 191 Types. The two modes in focus for interoperability are namely the 192 VLAN-Based Service Interface as defined in [RFC7432] section 6.1 and 193 the VLAN-Aware Bundle Service Interface as defined in [RFC7432] 194 section 6.3. The VLAN Bundle Service Interface is not considered. 196 The VLAN-Based Service Interface defines an EVPN instance consisting 197 of only a single broadcast domain or "Single Broadcast Domain per 198 EVI" as described in [RFC8365] section 5.1.2 Option 1. In this mode, 199 individual BGP Route Distinguisher (RD) and Route Target (RT) are 200 required for each EVI. Each EVI corresponds to a single MAC-VRF 201 identified by the RT, which provides the advantage of an BGP RT 202 constraint mechanisms in order to limit the propagation and import of 203 routes to only the PE that are interested. With VLAN-Based, the MAC- 204 VRF corresponds to only a single bridge table. The VLAN-Based Service 205 Interface uses the EVPN MAC/IP Advertisement route ([RFC7432], 206 section 7.2) with the MUST requirement of the Ethernet Tag ID being 207 set to zero. 209 Differently, the VLAN-Aware Bundle Service Interface follows a 210 bundling of multiple broadcast domains, with each having its own 211 bridge table, into a single EVI. This refers to the definition of 212 "Multiple Broadcast Domain per EVI" as described in [RFC8365] section 213 5.1.2 Option 2. The advantage of this model is that it doesn't 214 require the provisioning of an RD/RT per broadcast domain, which is a 215 moot point when VLAN-Base uses auto-derivation of RD/RT. With VLAN- 216 Aware Bundle Service, RT Constraint, as defined in [RFC4684], does 217 not help to reduce the dissemination of routes for a BD to the Pes 218 attached to that BD. This is given by the nature of the bundle 219 service where the RT is not sufficient to identify the MAC-VRF and 220 corresponding bridge table. The differences between the two modes of 221 Service Interfaces, namely VLAN-Based and VLAN-Aware Bundle Service 222 Interface, lie in the definition of the Ethernet Tag field in the 223 EVPN routes. While VLAN-Based Service Interface defines the EtherTag 224 as "must be set to zero", the VLAN-Aware Bundle Service interface 225 uses the VID within the EtherTag to identify the bridge table within 226 the MAC-VRF. These two requirements are orthogonal and as a result 227 make the interoperability of the two types mutually exclusive, an 228 interoperability is not achievable (Figure 1). 230 VLAN-Aware Bundle VLAN-Based 231 Service Interface Service Interface 232 +--------------------------+ +--------------------------+ 233 | PE1 | | PE2 | 234 | +---------+ +--------+ | | +--------+ +---------+ | 235 | | +-----+ | | | | | | | | | | 236 +-----| BD2 | +--+ | |--------| | +--+ |---+ 237 || | +-----+ | | | | | | | | | || 238 || | | | | | | | | | | || 239 || |MAC-VRF1 | |IP-VRF1 | | | |IP-VRF1 | |MAC-VRF1 | || 240 || +---------+ +--------+ | | +--------+ +---------+ || 241 || | | || 242 || +-----+ | | +-----+ || 243 || | BGP | | | | BGP | || 244 || +-----+ | | +-----+ || 245 |+--------------------------+ +--------------------------+| 246 | 2|EthTag [2]| -----><----- 2|EthTag [0]| | 247 | | 248 | +------+ +------+ | 249 +-|M1/IP1! |M2/IP2!-+ 250 +------+ +------+ 252 Figure 1: Interop of different Service Interface Types 254 As illustrated in Figure 1, the MAC/IP routes exchanged by PE1 and 255 PE2 contain Ethernet Tags 2 and 0 respectively. The receiving PE will 256 not process these routes and will normally discard them (treat-as- 257 withdraw)." 259 By extending the requirements currently present, an interoperability 260 is achievable. The adjustment would be as follows (Figure 2). 262 3.1.1. VLAN-Aware Bundle Service PE 264 In case of VLAN Aware Bundle Service Interface on the receiving PE 265 and with the consideration of VLAN Based Service Interface on the 266 advertising PE: 268 - MUST Operate in Single Broadcast Domain per EVI. 270 - Multiple Broadcast Domain per EVI case is not considered. 272 - MUST allow to receive zero EtherTag. 274 - The import of routes is performed based on the import policy 275 (route-target). 277 - With single bridge table per MAC-VRF, additional evaluation of the 278 EtherTag field is not required; the bridge table is sufficiently 279 defined by the import route-target. 281 - No Change to data-plane operation, the MPLS label identifies MAC- 282 VRF + bridge-table, or the VNI identifies the MAC-VRF + the bridge- 283 table. 285 3.1.2. VLAN-Based Service PE 287 - Operates in Single Broadcast Domain per EVI. 289 In case of VLAN Based Service Interface on the receiving PE and with 290 the consideration of VLAN Based Service Interface on the advertising 291 PE: 293 - Operates in Single Broadcast Domain per EVI. 295 - MUST allow receiving of non-zero EtherTag. 297 - No Change in control-plane operation, the EVI import policy (route- 298 target) identifies the broadcast domain (bridge-table) within a MAC- 299 VRF. 301 - No Change to data-plane operation, the MPLS label identifies MAC- 302 VRF + bridge-table, or the VNI identifies the MAC-VRF + the bridge- 303 table. 305 While the expansion introduces additional configuration requirement 306 for the VLAN-Aware Bundle Service Interface, it also allows for 307 broader interoperability in the eventuality of Vendor "A" only 308 implemented VLAN-Based while Vendor "B" only implemented VLAN-Aware 309 Bundle Service Interface. 311 3.2. Service Interface Interop Mode of Operation 313 When Service Interface interoperability is required, a given PE 314 should follow this section's procedures for all its broadcast domains 315 (BDs) and not just the BDs that need interoperability. 317 For those BDs where interoperability between VLAN-Aware Bundle and 318 VLAN-Based Service Interface is needed, ignoring the presence of the 319 EVPN routes Ethernet Tag ID on the PEs supporting VLAN-Based mode is 320 not enough. Each PE needs to clearly signal what mode it supports, so 321 that all the PEs attached to the same EVI can understand in what mode 322 the EVI operates. 324 Consider a scenario where PE1 is attached to the BD range BD1-10 and 325 it operates in VLAN-Aware mode, whereas PE2 is attached to the BD 326 range BD7-20 and operates in VLAN-Based mode. Interoperability is 327 required for the intersecting BDs, I.e., BD7-10. 329 For PE1, this means BD7-10 need to be separated into a dedicated MAC- 330 VRF each. EVPN routes for each of these three MAC-VRFs MUST be 331 advertised by PE1 with an Ethernet Tag ID of zero. In this way, PE1 332 indicates the use of VLAN-Based mode for those BDs. On reception, PE1 333 imports the BD7-10 routes based on the Route Target and ignoring the 334 Ethernet Tag ID, as the Route Target alone is sufficient to identify 335 the correct MAC-VRF and Bridge Table. The remaining BDs on PE1 (range 336 BD1-6) continue operating in VLAN-Aware Bundle mode. 338 In the same example, other PEs attached to BD1-6 must still process 339 the received Ethernet Tag ID in the EVPN routes from PE1, so that 340 they can identify the correct Bridge Table in a given MAC-VRF. 342 PE2 operates in VLAN-Based mode for BD7-20, as per [RFC7432] and 343 [RFC8365]. PE2's EVPN route advertisements for BD7-20 will include 344 individual Route Targets per BD and an Ethernet Tag ID of zero. On 345 reception, PE2 identifies the MAC-VRF and Bridge Table solely based 346 on the Route Target. 348 4. Interoperability for different IRB Types 350 4.1. Asymmetric IRB and Symmetric IRB 352 The differences in the two inter-subnet forwarding modes, namely 353 Asymmetric IRB and Symmetric IRB, are beyond just the information 354 difference in the control-plane from an EVPN Route Type 2 355 perspective. The two IRB modes have significant differences in inter- 356 subnet forwarding behavior and as a result different operation during 357 label imposition or encapsulation. 359 With the Asymmetric IRB mode, the ingress PE performs a "bridge-and- 360 route" operation while the egress PE follows a "bridge-only" 361 approach. Differently, the forwarding behavior in Symmetric IRB mode 362 performs a "bridge-and-route" operation on the ingress PE followed by 363 a "route-and bridge" operation at the egress PE. The significance in 364 difference is not only in the forwarding behavior itself but also 365 around how the respective EVPN attribute are used for driving the 366 inter-subnet operation. More specifically, in the case of inter- 367 subnet forwarding with Asymmetric IRB, MPLS Label1 is used towards 368 the egress PE to specify the MAC-VRF and respective Bridge-Domain for 369 forwarding. In inter-subnet forwarding with Symmetric IRB, MPLS 370 Label2 associated with the IP-VRF is used for the inter-subnet 371 forwarding operation towards egress PE. 373 The respective forwarding behaviors are described in [EVPN- 374 INTERSUBNET]. The following steps are required to ensure the 375 interoperability between the Asymmetric and Symmetric IRB modes. 377 Asymmetric IRB Symmetric IRB 378 +--------------------------+ +--------------------------+ 379 | PE1 | | PE2 | 380 | +---------+ | | +---------+ | 381 | | +-----+ | | | | +-----+ | | 382 +-----| BD0 | +-IRB0-+ | | +-IRB0--+ | BD0 | | | 383 || | +-----+ | | | | | | +-----+ | | 384 || | | +---+----+ | | +---+----+ | | | 385 || |MAC-VRF1 | | | | | | | |MAC-VRF1 | | 386 || +---------+ |IP-VRF1 | |--------| |IP-VRF1 | +---------+ | 387 || | | | | | | | 388 || +---------+ +---+----+ | | +---+----+ +---------+ | 389 || | +-----+ | | | | | | +-----+ | | 390 || | | BD2 | +-IRB2-+ | | +-IRB2--+ | BD2 |-----+ 391 || | +-----+ | | | | +-----+ | || 392 || | | +-----+ | | +-----+ | | || 393 || |MAC-VRF2 | | BGP | | | | BGP | |MAC-VRF2 | || 394 || +---------+ +-----+ | | +-----+ +---------+ || 395 || | | || 396 |+--------------------------+ +--------------------------+| 397 | 2|MAC/IP, 1 Label| -----><----- 2|MAC/IP, 2 Label| | 398 | | 399 | +------+ +------+ | 400 +-|M1/IP1! |M2/IP2!-+ 401 +------+ +------+ 403 Figure 2: Asymmetric IRB and Symmetric IRB 405 Figure 2 illustrates the overview of and Asymmetric IRB PE (PE1) and 406 a Symmetric IRB PE (PE2) within a interoperability deployment 407 scenario. Attached to PE1, end-point M1/IP1 is attached to BD0 within 408 MAC-VRF1. Respectively, on PE2 end-point M2/IP2 is connected via 409 attachment circuit to BD2 positioned within MAC-VRF2. IRB0 and IRB2 410 represent the host-facing IRB interface for inter-subnet 411 communication between the different end-points located in the 412 different IP Subnets. The IRB interfaces for a common MAC-VRF/BD on 413 PE1 and PE2 use the same IP address. With the difference of the IRB 414 modes between PE1 (Asymmetric IRB) and PE2 (Symmetric IRB), there is 415 a difference in the MPLS Label presence as part of the MAC/IP routes 416 exchanged between the PEs. PE1s update contains a single label, 417 representing MPLS Label1 used for bridging purposes. PE2s 418 advertisement contains two labels, one for bridging and one for 419 routing, as part of the MAC/IP route. While PE1 receives all 420 information necessary from PE2, PE2 is missing information necessary 421 for its routing operation. As a result, Inter-Subnet routing between 422 PE1 and PE2 is not achieved. 424 By following the current existing forwarding behavior as described in 425 [EVPN-INTERSUBNET], interoperability is theoretically achievable 426 without changes in the control-plane format. Nevertheless, there are 427 steps required that involve predominantly the local behavior of the 428 PE with Symmetric IRB mode. 430 4.1.1. Asymmetric IRB PE 432 In case of Asymmetric IRB as the advertising PE and with Symmetric 433 IRB on the receiving PE: 435 - Asymmetric IRB PE MUST send MAC and IP information with MPLS 436 Label1. 438 In case of Symmetric IRB as the advertising PE and with Asymmetric 439 IRB on the receiving PE: 441 - Asymmetric IRB PE MUST be able to ignore MPLS Label2. 443 4.1.2. Symmetric IRB PE 445 In case of Symmetric IRB as the advertising PE and with Asymmetric 446 IRB on the receiving PE: 448 - Symmetric IRB PE has no additional requirements. 450 In case of Asymmetric IRB as the advertising PE and with Symmetric 451 IRB on the receiving PE: 453 - Symmetric IRB PE requires to add the host-binding information, MAC 454 and IP, and associates them to the adjacency (ARP/ND) table facing 455 the PE with Asymmetric IRB; this is in addition of adding the MAC 456 address into the MAC-VRF table. Since there is no MPLS Label2 or 457 Route-Target for the IP-VRF, the Host IP is not specifically added to 458 IP-VRF table. 460 4.2. IRB Interop Mode of Operation 462 Interoperability between the Asymmetric IRB and Symmetric IRB mode 463 follows specific defined behavior that is predominantly required on 464 the PE that operates in the Symmetric IRB mode. Nevertheless, in 465 support for the interoperability, the PE operating in Asymmetric IRB 466 MUST accommodate the following two minimal requirements (with 467 references to Figure 2): 1) The PE that operates in Asymmetric IRB 468 mode (PE1), MUST send the MAC/IP route including the Host IP address. 469 2) The PE with Asymmetric IRB (PE1) MUST accept the MAC/IP routes 470 sent from PE2 (Symmetric IRB), while ignoring the additional 471 information of MPLS Label2 and Route-Target of the IP-VRF. 473 In reference to 1), the PE MUST always send the end-point MAC 474 address, Host IP address and related MPLS Label1 as part of the 475 MAC/IP route towards the PE with Symmetric IRB (PE2). This route will 476 be sent only with MPLS Label1 and the Route-Target of the matching 477 MAC-VRF. In reference to the illustration in Figure 2, PE1 MUST 478 generate and advertise an EVPN MAC/IP route using: 480 - MAC Length of 48 482 - MAC Address of M1 484 - IP Length of 32 / 128 486 - IP Address of IP1 488 - Label for MAC-VRF1 490 - Route-Target of MAC-VRF1 492 - Next-Hop PE1 494 For completeness of the requirements and in reference of 2), the 495 MAC/IP route advertised from the PE operating in Symmetric IRB (PE2) 496 is as follow: 498 - MAC Length of 48 500 - MAC Address of M2 502 - IP Length of 32 /128 504 - IP Address of IP2 506 - Label for MAC-VRF2, IP-VRF1 507 - Route-Target of MAC-VRF2, IP-VRF1 509 - Next-Hop PE2 511 As defined in 2), the Label and Route-Target information for IP-VRF1 512 MUST be ignored by PE1 (PE with Asymmetric IRB). 514 With PE2 operating in Symmetric IRB and with enabled interop mode, 515 the MAC/IP route from PE1 (Asymmetric IRB) is processed in the 516 respective bridging, routing and adjacency table. Based on the Route- 517 Target for MAC-VRF1, the MAC address M1 will be imported into MAC- 518 VRF1 respectively and placed within BD0. In addition, the host- 519 binding information M1/IP1 MUST be installed within PE2s adjacency 520 table. Subsequent, on PE2 the MAC address M1 and the host-binding 521 information (adjacency table entry) of M1/IP1 MUST point towards PE1 522 as the next-hop. With no presence of the Route-Target for IP-VRF1, 523 the IP address IP1 will not be specifically imported into IP-VRF1 and 524 is not associated with a MPLS Label2. As a result of the 525 interoperability, the additional efficiency provided by Symmetric IRB 526 in regards of preserving adjacency table exhaustion is reduced; this 527 is specifically when communicating with an Asymmetric IRB based 528 egress PE. In contrary, the interop mode allows for communication 529 between the different IRB modes. As a result, in the eventuality that 530 Vendor "A" only provides Asymmetric IRB, while Vendor "B" only has 531 Symmetric IRB available, interoperability for inter-subnet forwarding 532 can be seamlessly achieved. In addition, two further benefits are 533 present by implementing an Asymmetric/Symmetric Co-Existence on the 534 same PE (dual-mode PE). 536 - A dual-mode PE can seamlessly communicate with PE's that are either 537 in Asymmetric or in Symmetric IRB mode. 539 - A dual-mode PE can act as Anchor for interconnecting Symmetric IRB 540 and Asymmetric IRB based PE's (deployment restrictions might apply). 542 5. Interoperability for different IRB Core Connectivity Modes 544 5.1. Interface-Less and Interface-Ful Unnumbered IRB 546 The two modes, namely interface-less and interface-ful Unnumbered SBD 547 IRB, are closely related in regards to the information required in 548 the EVPN Route Type 5. While interface-less provides all information 549 for the IP prefix advertisement within the EVPN Route Type 5, in the 550 case of interface-ful Unnumbered SBD IRB, an additional EVPN Route 551 Type 2 is required for the next-hop recursive lookup. From a 552 forwarding behavior, both approaches are similar and follow a 553 symmetric routing approach but are not interoperable. Note as per 555 [EVPN-PREFIX] the interface-ful Unnumbered SBD IRB is an OPTIONAL 556 mode. 558 Interface-Ful 559 Interface-Less Unnumbered IRB 560 +--------------------------+ +--------------------------+ 561 | PE1 | | PE2 | 562 | +--------+ | | +--------+ | 563 | | | | | | | | 564 +----------------+ | |--------| | +----------------+ 565 || | | | | | | || 566 || | | | | | | || 567 || |IP-VRF1 | | | |IP-VRF1 | || 568 || +--------+ | | +--------+ || 569 || | | || 570 || +-----+ | | +-----+ || 571 || | BGP | | | | BGP | || 572 || +-----+ | | +-----+ || 573 |+--------------------------+ +--------------------------+| 574 | 2|None| -----> | 575 | <----- 5|No Label| | 576 | | 577 | +-------+ +-------+ | 578 +-|TS1/SN1| |TS2/SN2!-+ 579 +-------+ +-------+ 581 Figure 3: Interoperability of different IRB Core Connectivity Mode 582 (unnumbered) 584 The illustration in Figure 3 represents the possible deployment 585 scenario between two different Core IRB Connectivity modes. 586 Specifically, PE1 is operating with interface-less Core IRB Mode 587 while PE2 operates with the interface-ful Unnumbered SDB IRB mode; 588 both operate without interoperability capabilities. Attached to PE1 589 and PE2 respectively, Tenant System 1 (TS1) and Tenant System 2 (TS2) 590 with different IP Subnets are present. TS1 attached on PE1 as well as 591 TS2 attached to PE2 are represented in a common IP-VRF (IP-VRF1), 592 sharing a common Route-Target between the PEs. With the different IRB 593 Core Connectivity modes on PE1 and PE2 respectively, the differences 594 in IP prefix advertisements as described in [EVPN-PREFIX] are 595 present. PE1 advertises only a single EVPN Route Type 5 (IP Prefix 596 Route) for TS1 using the fields following the interface-less mode: 598 EVPN Route Type 5: 600 - IP Length of 0 to 32 / 0 to 128 601 - IP Address of SN1 603 - Label for IP-VRF1 605 - GW IP Address set to zero 607 - Route-Target of IP-VRF1 609 - Router's MAC Extended Community of PE1 611 - Next-Hop PE1 613 Differently, PE2 advertises an EVPN Route Type 2 (MAC/IP Route) next 614 to the EVPN Route Type 5 (IP Prefix Route). The MAC/IP Route supports 615 the requirement for recursive next-hop resolution for the next-hop 616 used in the IP Prefix Route. Below the fields used in the Route Type 617 5 and respective Route Type 2 according to the interface-ful 618 Unnumbered IRB mode: 620 EVPN Route Type 5: 622 - IP Length of 0 to 32 / 0 to 128 624 - IP Address of SN1 626 - Label SHOULD be set to 0 628 - GW IP Address SHOULD be set to " 630 - Route-Target of IP-VRF1 632 - Router's MAC Extended Community of PE2 634 - Next-Hop PE2 636 EVPN Route Type 2: 638 - MAC Length of 48 640 - MAC Address of PE2 642 - IP Length of 32 / 128 644 - IP Address of PE2 646 - Label for IP-VRF1 648 - Route-Target of IP-VRF1 649 - Next-Hop PE2 651 While PE1 is missing the MPLS Label for the IP-VRF from PE2, PE2 is 652 missing the MPLS Label information and the necessary info for the 653 next-hop recursion. As a result, Routing with IP Prefix Advertisement 654 between PE1 and PE2 is not achieved. 656 By advertising an additional EVPN Route Type 2 from interface-less 657 (PE1) and by advertising the MPLS Label as part of EVPN Route Type 5 658 from PE2, interoperability is achievable. The specific mode of 659 operation would be as per the following two section and refers to 660 Figure 3 and Figure 4. 662 5.1.1. Interface-Less PE 664 In case of interface-less on the advertising PE and with the 665 consideration of interface-ful Unnumbered IRB as the receiving PE: 667 Shall generate and Advertise EVPN Route Type 2 for every IP-VRF 668 using. 670 - MAC Length of 48 672 - MAC Address with "Router MAC" 674 - IP Length of 32 676 - IP Address with NVE IP 678 - Label for IP-VRF 680 - Route-Target of IP-VRF 682 - Router-MAC Extended Community 684 In case of interface-less on the receiving PE and with the 685 consideration of interface-ful Unnumbered IRB as the advertising PE: 687 - MUST ignore EVPN Route Type 2 with MPLS Label and route-target 688 matching the IP-VRF because there is no MAC-VRF defined matching 689 these information. 691 5.1.2. Interface-Ful Unnumbered IRB 693 In case of interface-ful Unnumbered on the advertising PE and with 694 the consideration of interface-less as the receiving PE: 696 - Shall advertise MPLS Label for IP-VRF in EVPN Route Type 5 with 697 matching route-target. 699 In case of interface-ful Unnumbered on the receiving PE and with the 700 consideration of interface-less as the advertising PE: 702 - No Additions Required. 704 Interface-Ful 705 Interface-Less Unnumbered IRB 706 +--------------------------+ +--------------------------+ 707 | PE1 | | PE2 | 708 | +--------+ | | +--------+ | 709 | | | | | | | | 710 +----------------+ | |--------| | +----------------+ 711 || | | | | | | || 712 || | | | | | | || 713 || | IP-VRF | | | | IP-VRF | || 714 || +--------+ | | +--------+ || 715 || | | || 716 || +-----+ | | +-----+ || 717 || | BGP | | | | BGP | || 718 || +-----+ | | +-----+ || 719 |+--------------------------+ +--------------------------+| 720 | 2|RMAC/RIP| -----> | 721 | <----- 5|Label| | 722 | | 723 | +-------+ +-------+ | 724 +-|TS1/SN1| |TS2/SN2!-+ 725 +-------+ +-------+ 727 Figure 4: Interop of different IRB Core Connectivity Types 728 (unnumbered) 730 Illustrated in Figure 4 are the additional requirements for 731 interface-less IRB Core Connectivity mode, specifically the MAC/IP 732 Route (EVPN Route Type 2) necessary for PE2s next-hop recursion. 733 Also, the MPLS Label addition within PE2s IP Prefix route (EVPN Route 734 Type 5) is represented, which is required for interface-ful 735 Unnumbered IRBs advertisement towards an interface-less PE (PE1) 737 The interop mode introduces additional control-plane advertisements 738 from an Interface-less perspective. This is necessary to allow 739 interface-ful Unnumbered SBD IRB to perform the recursive lookup 740 required. From a EVPN Type 5 perspective between the two types, most 741 of the fields are already equally defined and populated as per [EVPN- 742 PREFIX]. Exception is the IP-VRF Label, which is required to be added 743 in the interface-ful Unnumbered SBD IRB's EVPN Type 5. In addition, 744 the Interface-less plus addition allows the Co-Existence of both 745 types on the same PE (dual-mode PE). Such a dual-mode PE can 746 communicate at the same time with PE's that are in Interface-less or 747 in interface-ful Unnumbered SBD IRB mode. 749 The disadvantage of the additional advertisement has to be put into 750 relation to advantage of successful interoperability where 751 eventuality of Vendor "A" only implemented interface-less while 752 Vendor "B" only implemented interface-ful Unnumbered SBD IRB. 754 6. Security Considerations 756 TBD. 758 7. IANA Considerations 760 TBD. 762 8. References 764 8.1. Normative References 766 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 767 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 768 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 769 2015, . 771 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 772 Uttaro, J., and W. Henderickx, "A Network Virtualization 773 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 774 10.17487/RFC8365, March 2018, . 777 [EVPN-INTERSUBNET] Sajassi et al., "Integrated Routing and Bridging 778 in EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-08, 779 work in progress, March, 2019. 781 [EVPN-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN", 782 draft-ietf-bess-evpn-prefix-advertisement-11, May 2018. 784 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, DOI 786 10.17487/RFC2119, March 1997, . 789 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, DOI 790 10.17487/RFC1776, April 1 1995, . 793 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 794 10.17487/RFC1925, April 1 1996, . 797 8.2. Informative References 799 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., 800 Patel, K., and J. Guichard, "Constrained Route 801 Distribution for Border Gateway Protocol/MultiProtocol 802 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 803 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 804 November 2006, . 806 [EANTC] EANTC, "Multi-Vendor Interoperability Test", February 2019, 807 . 810 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 811 RFC 3514, DOI 10.17487/RFC3514, April 1 2003, 812 . 814 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 815 Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 1 2009, 816 . 818 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, DOI 819 10.17487/RFC5514, April 1 2009, . 822 9. Conclusion 824 With minimal additions, the most common EVPN types for Virtual 825 Identifiers to EVI Mapping, Integrated Routing and Bridging and IP 826 Prefix Advertisement can be made interoperable. The aim for 827 interoperability doesn't remove the requirement for optimized types 828 for different use-cases but allows flexibility and basic 829 interoperability. 831 9.1. Demonstration of Applicability 833 Cisco, Juniper and Nokia demonstrated successfully the ability of 834 EVPN interoperability modes during EANTCs yearly "Multi-Vendor 835 Interoperability Test". The Whitepaper can be obtained through EANTC 836 with the latest version being available at [EANTC]. 838 9.1.1. Service Interface Interoperability 840 A proof of the benefit with this interoperability mode has already 841 been demonstrated during EVPN Multi-Vendor interoperability testing 842 and also, in production environments. Specifically, Cisco and Nokia's 843 VLAN-Based Service Interface successful proofed interoperability with 844 Junipers VLAN-Aware Bundle Service Interface. 846 9.1.2. IRB Types 848 A proof of the benefit with this interoperability mode has already 849 successfully demonstrated during EVPN Multi-Vendor interoperability 850 testing. Specifically, Cisco operated in a Hybrid IRB (Dual-Mode) 851 mode while other Vendor operated in an Asymmetric IRB mode. 852 Forwarding was achieved through dynamic detection of the alternate 853 Vendor PE's mode and adjustment to Asymmetric IRB for these specific 854 BDs. Communication for all other BDs continued to be Symmetric IRB. 856 9.1.3. IRB Core Connectivity Types 858 A proof of an interoperability mode between interface-less and 859 interface-ful Unnumbered SBD IRB has already been demonstrated in 860 production environments and during EVPN Multi-Vendor interoperability 861 testing. Specifically, Cisco's addition for Interface-less is 862 successfully deployed with Nokia's and Nuage's interface-ful 863 Unnumbered SBD IRB at customers 865 10. Authors' Addresses 867 Lukas Krattiger 868 Cisco 869 USA 870 EMail: lkrattig@cisco.com 872 Ali Sajassi 873 Cisco 874 USA 875 EMail: sajassi@cisco.com 877 Samir Thoria 878 Cisco 879 USA 880 EMail: sthoria@cisco.com 882 Jorge Rabadan 883 Nokia 884 777 E. Middlefield Road 885 Mountain View, CA 94043 USA 886 EMail: jorge.rabadan@nokia.com 888 John E. Drake 889 Juniper 890 EMail: jdrake@juniper.net