idnits 2.17.1 draft-ietf-bess-dci-evpn-overlay-09.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 are 16 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC7432]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 20, 2018) is 2255 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7041 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-08 == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-overlay-11 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan (Ed.) 3 Internet Draft S. Sathappan 4 Intended status: Standards Track W. Henderickx 5 Updates: 7432 Nokia 7 A. Sajassi 8 Cisco 10 J. Drake 11 Juniper 13 Expires: August 24, 2018 February 20, 2018 15 Interconnect Solution for EVPN Overlay networks 16 draft-ietf-bess-dci-evpn-overlay-09 18 Abstract 20 This document describes how Network Virtualization Overlays (NVO) can 21 be connected to a Wide Area Network (WAN) in order to extend the 22 layer-2 connectivity required for some tenants. The solution analyzes 23 the interaction between NVO networks running Ethernet Virtual Private 24 Networks (EVPN) and other L2VPN technologies used in the WAN, such as 25 Virtual Private LAN Services (VPLS), VPLS extensions for Provider 26 Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how 27 the existing technical specifications apply to the Interconnection 28 and extends the EVPN procedures needed in some cases. In particular, 29 this document describes how EVPN routes are processed on Gateways 30 (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well 31 as the Interconnect Ethernet Segment (I-ES) to provide multi-homing, 32 and the use of the Unknown MAC route to avoid MAC scale issues on 33 Data Center Network Virtualization Edge (NVE) devices. The document 34 updates [RFC7432]. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html 57 This Internet-Draft will expire on August 24, 2018. 59 Copyright Notice 61 Copyright (c) 2018 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 77 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Decoupled Interconnect solution for EVPN overlay networks . . . 6 79 3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 7 80 3.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 8 81 3.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 8 82 3.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 9 83 3.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 10 84 3.5.1. MAC Address Advertisement Control . . . . . . . . . . . 10 85 3.5.2. ARP/ND flooding control . . . . . . . . . . . . . . . . 11 86 3.5.3. Handling failures between GW and WAN Edge routers . . . 11 87 4. Integrated Interconnect solution for EVPN overlay networks . . 12 88 4.1. Interconnect requirements . . . . . . . . . . . . . . . . . 12 89 4.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 13 90 4.2.1. Control/Data Plane setup procedures on the GWs . . . . 13 91 4.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 14 92 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 14 93 4.3.1. Control/Data Plane setup procedures on the GWs . . . . 14 94 4.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 15 95 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 15 96 4.4.1. Control Plane setup procedures on the GWs . . . . . . . 15 97 4.4.2. Data Plane setup procedures on the GWs . . . . . . . . 17 98 4.4.3. Multi-homing procedure extensions on the GWs . . . . . 18 99 4.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 20 100 4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 21 101 4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 21 102 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 22 103 4.5.1. Control/Data Plane setup procedures on the GWs . . . . 22 104 4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 23 105 4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 23 106 4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 23 107 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 23 108 4.6.1. Globally unique VNIs in the Interconnect network . . . 24 109 4.6.2. Downstream assigned VNIs in the Interconnect network . 25 110 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 25 111 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26 112 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 113 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 114 7.2. Informative References . . . . . . . . . . . . . . . . . . 27 115 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28 116 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 117 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 119 1. Conventions and Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 AC: Attachment Circuit. 129 ARP: Address Resolution Protocol. 131 BUM: it refers to the Broadcast, Unknown unicast and Multicast 132 traffic. 134 CE: Customer Equipment. 136 CFM: Connectivity Fault Management. 138 DC and DCI: Data Center and Data Center Interconnect. 140 DC RR(s) and WAN RR(s): it refers to the Data Center and Wide Area 141 Network Route Reflectors, respectively. 143 DF and NDF: Designated Forwarder and Non-Designated Forwarder. 145 EVPN: Ethernet Virtual Private Network, as in [RFC7432]. 147 EVI: EVPN Instance. 149 EVPN Tunnel binding: it refers to a tunnel to a remote PE/NVE for a 150 given EVI. Ethernet packets in these bindings are encapsulated with 151 the Overlay or MPLS encapsulation and the EVPN label at the bottom of 152 the stack. 154 ES: Ethernet Segment. 156 ESI: Ethernet Segment Identifier. 158 GW: Gateway or Data Center Gateway. 160 I-ES and I-ESI: Interconnect Ethernet Segment and Interconnect 161 Ethernet Segment Identifier. An I-ES is defined on the GWs for multi- 162 homing to/from the WAN. 164 MAC-VRF: it refers to an EVI instance in a particular node. 166 MP2P and LSM tunnels: it refers to Multi-Point to Point and Label 167 Switched Multicast tunnels. 169 ND: Neighbor Discovery protocol. 171 NVE: Network Virtualization Edge. 173 NVGRE: Network Virtualization using Generic Routing Encapsulation. 175 NVO: refers to Network Virtualization Overlays. 177 OAM: Operations and Maintenance. 179 PBB: Provider Backbone Bridging. 181 PE: Provider Edge. 183 PW: Pseudowire. 185 RD: Route-Distinguisher. 187 RT: Route-Target. 189 S/C-TAG: It refers to a combination of Service Tag and Customer Tag 190 in a 802.1Q frame. 192 TOR: Top-Of-Rack switch. 194 UMR: Unknown MAC Route. 196 VNI/VSID: refers to VXLAN/NVGRE virtual identifiers. 198 VPLS: Virtual Private LAN Service. 200 VSI: Virtual Switch Instance or VPLS instance in a particular PE. 202 VXLAN: Virtual eXtensible LAN. 204 2. Introduction 206 [EVPN-Overlays] discusses the use of Ethernet Virtual Private 207 Networks (EVPN) [RFC7432] as the control plane for Network 208 Virtualization Overlays (NVO), where VXLAN [RFC7348], NVGRE [RFC7637] 209 or MPLS over GRE [RFC4023] can be used as possible data plane 210 encapsulation options. 212 While this model provides a scalable and efficient multi-tenant 213 solution within the Data Center, it might not be easily extended to 214 the Wide Area Network (WAN) in some cases due to the requirements and 215 existing deployed technologies. For instance, a Service Provider 216 might have an already deployed Virtual Private LAN Service (VPLS) 217 [RFC4761][RFC4762], VPLS extensions for Provider Backbone Bridging 218 (PBB-VPLS) [RFC7041], EVPN [RFC7432] or PBB-EVPN [RFC7623] network 219 that has to be used to interconnect Data Centers and WAN VPN users. A 220 Gateway (GW) function is required in these cases. In fact, [EVPN- 221 Overlays] discusses two main Data Center Interconnect solution 222 groups: "DCI using GWs" and "DCI using ASBRs". This document 223 specifies the solutions that correspond to the "DCI using GWs" group. 225 This document describes a Interconnect solution for EVPN overlay 226 networks, assuming that the NVO Gateway (GW) and the WAN Edge 227 functions can be decoupled in two separate systems or integrated into 228 the same system. The former option will be referred as "Decoupled 229 Interconnect solution" throughout the document, whereas the latter 230 one will be referred as "Integrated Interconnect solution". 232 The specified procedures are local to the redundant GWs connecting a 233 DC to the WAN. The document does not preclude any combination across 234 different DCs for the same tenant. For instance, a "Decoupled" 235 solution can be used in GW1 and GW2 (for DC1) and an "Integrated" 236 solution can be used in GW3 and GW4 (for DC2). 238 While the Gateways and WAN PEs use existing specifications in some 239 cases, the document also defines extensions so that the requirements 240 of the Interconnection can be met. In particular, the document 241 updates [RFC7432] on several aspects: 243 o The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that 244 can be associated not only to a set of Ethernet links, as in 245 [RFC7432], but also to a set of PWs or other tunnels. 247 o The use of the Unknown MAC route in a DCI scenario. 249 o The processing of EVPN routes on Gateways with MAC-VRFs connecting 250 EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN- 251 Overlay networks. 253 3. Decoupled Interconnect solution for EVPN overlay networks 255 This section describes the interconnect solution when the GW and WAN 256 Edge functions are implemented in different systems. Figure 1 depicts 257 the reference model described in this section. Note that, although 258 not shown in Figure 1, GWs may have local ACs (Attachment Circuits). 260 +--+ 261 |CE| 262 +--+ 263 | 264 +----+ 265 +----| PE |----+ 266 +---------+ | +----+ | +---------+ 267 +----+ | +---+ +----+ +----+ +---+ | +----+ 268 |NVE1|--| | | |WAN | |WAN | | | |--|NVE3| 269 +----+ | |GW1|--|Edge| |Edge|--|GW3| | +----+ 270 | +---+ +----+ +----+ +---+ | 271 | NVO-1 | | WAN | | NVO-2 | 272 | +---+ +----+ +----+ +---+ | 273 | | | |WAN | |WAN | | | | 274 +----+ | |GW2|--|Edge| |Edge|--|GW4| | +----+ 275 |NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4| 276 +----+ +---------+ | | +---------+ +----+ 277 +--------------+ 279 |<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->| 280 hand-off hand-off 282 Figure 1 Decoupled Interconnect model 284 The following section describes the interconnect requirements for 285 this model. 287 3.1. Interconnect requirements 289 The Decoupled Interconnect architecture is intended to be deployed in 290 networks where the EVPN-Overlay and WAN providers are different 291 entities and a clear demarcation is needed. This solution solves the 292 following requirements: 294 o A simple connectivity hand-off between the EVPN-Overlay network 295 provider and the WAN provider so that QoS and security enforcement 296 is easily accomplished. 298 o Independence of the Layer Two VPN (L2VPN) technology deployed in 299 the WAN. 301 o Multi-homing between GW and WAN Edge routers, including per-service 302 load balancing. Per-flow load balancing is not a strong requirement 303 since a deterministic path per service is usually required for an 304 easy QoS and security enforcement. 306 o Support of Ethernet OAM and Connectivity Fault Management (CFM) 307 [802.1AG][Y.1731] functions between the GW and the WAN Edge router 308 to detect individual AC failures. 310 o Support for the following optimizations at the GW: 311 + Flooding reduction of unknown unicast traffic sourced from the DC 312 Network Virtualization Edge devices (NVEs). 313 + Control of the WAN MAC addresses advertised to the DC. 314 + Address Resolution Protocol (ARP) and Neighbor Discovery (ND) 315 flooding control for the requests coming from the WAN. 317 3.2. VLAN-based hand-off 319 In this option, the hand-off between the GWs and the WAN Edge routers 320 is based on VLANs [802.1Q-2014]. This is illustrated in Figure 1 321 (between the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in 322 the GW is connected to a different VSI/MAC-VRF instance in the WAN 323 Edge router by using a different C-TAG VLAN ID or a different 324 combination of S/C-TAG VLAN IDs that matches at both sides. 326 This option provides the best possible demarcation between the DC and 327 WAN providers and it does not require control plane interaction 328 between both providers. The disadvantage of this model is the 329 provisioning overhead since the service has to be mapped to a C-TAG 330 or S/C-TAG VLAN ID combination at both GW and WAN Edge routers. 332 In this model, the GW acts as a regular Network Virtualization Edge 333 (NVE) towards the DC. Its control plane, data plane procedures and 334 interactions are described in [EVPN-Overlays]. 336 The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with 337 attachment circuits (ACs) to the GWs. Its functions are described in 338 [RFC4761], [RFC4762], [RFC6074] or [RFC7432], [RFC7623]. 340 3.3. PW-based (Pseudowire-based) hand-off 342 If MPLS between the GW and the WAN Edge router is an option, a PW- 343 based Interconnect solution can be deployed. In this option the 344 hand-off between both routers is based on FEC128-based PWs [RFC4762] 345 or FEC129-based PWs (for a greater level of network automation) 346 [RFC6074]. Note that this model still provides a clear demarcation 347 boundary between DC and WAN (since there is a single PW between each 348 MAC-VRF and peer VSI), and security/QoS policies may be applied on a 349 per PW basis. This model provides better scalability than a C-TAG 350 based hand-off and less provisioning overhead than a combined C/S-TAG 351 hand-off. The PW-based hand-off interconnect is illustrated in Figure 352 1 (between the NVO-2 GWs and the WAN Edge routers). 354 In this model, besides the usual MPLS procedures between GW and WAN 355 Edge router [RFC3031], the GW MUST support an interworking function 356 in each MAC-VRF that requires extension to the WAN: 358 o If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI 359 (WAN Edge), the corresponding VCID MUST be provisioned on the MAC- 360 VRF and match the VCID used in the peer VSI at the WAN Edge router. 362 o If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used 363 between the GW MAC-VRF and the WAN Edge VSI, the provisioning of 364 the VPLS-ID MUST be supported on the MAC-VRF and MUST match the 365 VPLS-ID used in the WAN Edge VSI. 367 If a PW-based handoff is used, the GW's AC (or point of attachment to 368 the EVPN Instance) uses a combination of a PW label and VLAN IDs, as 369 opposed to only VLAN IDs as in [RFC7432]. Therefore the [RFC7432] 370 mapping definitions of VLAN-based, VLAN-bundle or VLAN-aware bundle 371 service interfaces are updated in this document to include the PW 372 label as follows: 374 o VLAN-Based Service Interface: the AC mapping to the MAC-VRF is 375 given by a unique combination of (PW label, optional inner VLAN 376 ID). In this context "optional VLAN ID" means a unique combination 377 of S/C-TAG or no tag at all. In case of no-tag, the point of 378 attachment to the MAC-VRF is strictly based on the PW label and the 379 service interface may be referred to as PW-Based Service Interface. 380 The rest of the VLAN-Based service characteristics are as per 381 [RFC7432]. 383 o VLAN-Bundle Service Interface: the AC mapping to the MAC-VRF is 384 given by a unique combination of (PW label, VLAN ID range), where 385 VLAN ID range represents the S/C-TAG values included in a range. 386 The rest of the VLAN-Bundle service characteristics are as per 387 [RFC7432]. 389 o VLAN-Aware Bundle Service Interface: the AC mapping to the Bridge 390 Table is given by a unique combination of (PW VC label, VLAN ID). 391 In this service interface, there are multiple Bridge Tables per 392 MAC-VRF, and each point of attachment to a Bridge Table has a 393 different (PW label, VLAN ID) combination. The rest of the VLAN- 394 Aware Bundle service characteristics are as per [RFC7432]. 396 3.4. Multi-homing solution on the GWs 398 EVPN single-active multi-homing, i.e. per-service load-balancing 399 multi-homing is required in this type of interconnect. 401 The GWs will be provisioned with a unique ES per WAN interconnect, 402 and the hand-off attachment circuits or PWs between the GW and the 403 WAN Edge router will be assigned an ESI for such ES. The ESI will be 404 administratively configured on the GWs according to the procedures in 405 [RFC7432]. This Interconnect ES will be referred as "I-ES" hereafter, 406 and its identifier will be referred as "I-ESI". [RFC7432] describes 407 different ESI Types. The use of Type 0 for the I-ESI is RECOMMENDED 408 in this document. 410 The solution (on the GWs) MUST follow the single-active multi-homing 411 procedures as described in [EVPN-Overlays] for the provisioned I-ESI, 412 i.e. Ethernet A-D routes per ES and per EVI will be advertised to the 413 DC NVEs for the multi-homing functions, ES routes will be advertised 414 so that ES discovery and Designated Forwarder (DF) procedures can be 415 followed. The MAC addresses learned (in the data plane) on the hand- 416 off links will be advertised with the I-ESI encoded in the ESI field. 418 3.5. Gateway Optimizations 420 The following GW features are optional and optimize the control plane 421 and data plane in the DC. 423 3.5.1. MAC Address Advertisement Control 425 The use of EVPN in NVO networks brings a significant number of 426 benefits as described in [EVPN-Overlays]. However, if multiple DCs 427 are interconnected into a single EVI, each DC will have to import all 428 of the MAC addresses from each of the other DCs. 430 Even if optimized BGP techniques like RT-constraint [RFC4684] are 431 used, the number of MAC addresses to advertise or withdraw (in case 432 of failure) by the GWs of a given DC could overwhelm the NVEs within 433 that DC, particularly when the NVEs reside in the hypervisors. 435 The solution specified in this document uses the 'Unknown MAC Route' 436 (UMR) which is advertised into a given DC by each of the DC's GWs. 437 This route is defined in [RFC7543] and is a regular EVPN MAC/IP 438 Advertisement route in which the MAC Address Length is set to 48, the 439 MAC address is set to 0, and the ESI field is set to the DC GW's I- 440 ESI. 442 An NVE within that DC that understands and process the UMR will send 443 unknown unicast frames to one of the DCs GWs, which will then forward 444 that packet to the correct egress PE. Note that, because the ESI is 445 set to the DC GW's I-ESI, all-active multi-homing can be applied to 446 unknown unicast MAC addresses. An NVE that does not understand the 447 Unknown MAC route will handle unknown unicast as described in 448 [RFC7432]. 450 This document proposes that local policy determines whether MAC 451 addresses and/or the UMR are advertised into a given DC. As an 452 example, when all the DC MAC addresses are learned in the 453 control/management plane, it may be appropriate to advertise only the 454 UMR. Advertising all the DC MAC addresses in the control/management 455 plane is usually the case when the NVEs reside in hypervisors. Refer 456 to [EVPN-Overlays] section 7. 458 It is worth noting that the UMR usage in [RFC7543] and the UMR usage 459 in this document are different. In the former, a Virtual Spoke (V- 460 spoke) does not necessarily learn all the MAC addresses pertaining to 461 hosts in other V-spokes of the same network. The communication 462 between two V-spokes is done through the DMG, until the V-spokes 463 learn each other's MAC addresses. In this document, two leaf switches 464 in the same DC are recommended to learn each other's MAC addresses 465 for the same EVI. The leaf to leaf communication is always direct and 466 does not go through the GW. 468 3.5.2. ARP/ND flooding control 470 Another optimization mechanism, naturally provided by EVPN in the 471 GWs, is the Proxy ARP/ND function. The GWs should build a Proxy 472 ARP/ND cache table as per [RFC7432]. When the active GW receives an 473 ARP/ND request/solicitation coming from the WAN, the GW does a Proxy 474 ARP/ND table lookup and replies as long as the information is 475 available in its table. 477 This mechanism is especially recommended on the GWs, since it 478 protects the DC network from external ARP/ND-flooding storms. 480 3.5.3. Handling failures between GW and WAN Edge routers 482 Link/PE failures are handled on the GWs as specified in [RFC7432]. 483 The GW detecting the failure will withdraw the EVPN routes as per 484 [RFC7432]. 486 Individual AC/PW failures may be detected by OAM mechanisms. For 487 instance: 489 o If the Interconnect solution is based on a VLAN hand-off, Ethernet- 490 CFM [802.1AG][Y.1731] may be used to detect individual AC failures 491 on both, the GW and WAN Edge router. An individual AC failure will 492 trigger the withdrawal of the corresponding A-D per EVI route as 493 well as the MACs learned on that AC. 495 o If the Interconnect solution is based on a PW hand-off, the Label 496 Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be 497 used to detect individual PW failures on both, the GW and WAN Edge 498 router. 500 4. Integrated Interconnect solution for EVPN overlay networks 502 When the DC and the WAN are operated by the same administrative 503 entity, the Service Provider can decide to integrate the GW and WAN 504 Edge PE functions in the same router for obvious CAPEX and OPEX 505 saving reasons. This is illustrated in Figure 2. Note that this model 506 does not provide an explicit demarcation link between DC and WAN 507 anymore. Although not shown in Figure 2, note that the GWs may have 508 local ACs. 510 +--+ 511 |CE| 512 +--+ 513 | 514 +----+ 515 +----| PE |----+ 516 +---------+ | +----+ | +---------+ 517 +----+ | +---+ +---+ | +----+ 518 |NVE1|--| | | | | |--|NVE3| 519 +----+ | |GW1| |GW3| | +----+ 520 | +---+ +---+ | 521 | NVO-1 | WAN | NVO-2 | 522 | +---+ +---+ | 523 | | | | | | 524 +----+ | |GW2| |GW4| | +----+ 525 |NVE2|--| +---+ +---+ |--|NVE4| 526 +----+ +---------+ | | +---------+ +----+ 527 +--------------+ 529 |<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->| 530 |<--PBB-VPLS-->| 531 Interconnect -> |<-EVPN-MPLS-->| 532 options |<--EVPN-Ovl-->|* 533 |<--PBB-EVPN-->| 535 Figure 2 Integrated Interconnect model 537 * EVPN-Ovl stands for EVPN-Overlay (and it's an Interconnect option). 539 4.1. Interconnect requirements 541 The Integrated Interconnect solution meets the following 542 requirements: 544 o Control plane and data plane interworking between the EVPN-overlay 545 network and the L2VPN technology supported in the WAN, irrespective 546 of the technology choice, i.e. (PBB-)VPLS or (PBB-)EVPN, as 547 depicted in Figure 2. 549 o Multi-homing, including single-active multi-homing with per-service 550 load balancing or all-active multi-homing, i.e. per-flow load- 551 balancing, as long as the technology deployed in the WAN supports 552 it. 554 o Support for end-to-end MAC Mobility, Static MAC protection and 555 other procedures (e.g. proxy-arp) described in [RFC7432] as long as 556 EVPN-MPLS is the technology of choice in the WAN. 558 o Independent inclusive multicast trees in the WAN and in the DC. 559 That is, the inclusive multicast tree type defined in the WAN does 560 not need to be the same as in the DC. 562 4.2. VPLS Interconnect for EVPN-Overlay networks 564 4.2.1. Control/Data Plane setup procedures on the GWs 566 Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN 567 PEs and RRs as per [RFC4761], [RFC4762], [RFC6074] and overlay 568 tunnels and EVPN will be setup as per [EVPN-Overlays]. Note that 569 different route-targets for the DC and for the WAN are normally 570 required (unless [RFC4762] is used in the WAN, in which case no WAN 571 route-target is needed). A single type-1 RD per service may be used. 573 In order to support multi-homing, the GWs will be provisioned with an 574 I-ESI (see section 3.4), that will be unique per interconnection. The 575 I-ES in this case will represent the group of PWs to the WAN PEs and 576 GWs. All the [RFC7432] procedures are still followed for the I-ES, 577 e.g. any MAC address learned from the WAN will be advertised to the 578 DC with the I-ESI in the ESI field. 580 A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have 581 two different types of tunnel bindings instantiated in two different 582 split-horizon-groups: 584 o VPLS PWs will be instantiated in the "WAN split-horizon-group". 586 o Overlay tunnel bindings (e.g. VXLAN, NVGRE) will be instantiated 587 in the "DC split-horizon-group". 589 Attachment circuits are also supported on the same MAC-VRF (although 590 not shown in Figure 2), but they will not be part of any of the above 591 split-horizon-groups. 593 Traffic received in a given split-horizon-group will never be 594 forwarded to a member of the same split-horizon-group. 596 As far as BUM flooding is concerned, a flooding list will be composed 597 of the sub-list created by the inclusive multicast routes and the 598 sub-list created for VPLS in the WAN. BUM frames received from a 599 local Attachment Circuit (AC) will be forwarded to the flooding list. 600 BUM frames received from the DC or the WAN will be forwarded to the 601 flooding list observing the split-horizon-group rule described above. 603 Note that the GWs are not allowed to have an EVPN binding and a PW to 604 the same far-end within the same MAC-VRF, so that loops and packet 605 duplication are avoided. In case a GW can successfully establish 606 both, an EVPN binding and a PW to the same far-end PE, the EVPN 607 binding will prevail and the PW will be brought operationally down. 609 The optimizations procedures described in section 3.5 can also be 610 applied to this model. 612 4.2.2. Multi-homing procedures on the GWs 614 This model supports single-active multi-homing on the GWs. All-active 615 multi-homing is not supported by VPLS, therefore it cannot be used on 616 the GWs. 618 In this case, for a given EVI, all the PWs in the WAN split-horizon- 619 group are assigned to I-ES. All the single-active multi-homing 620 procedures as described by [EVPN-Overlays] will be followed for the 621 I-ES. 623 The non-DF GW for the I-ES will block the transmission and reception 624 of all the PWs in the "WAN split-horizon-group" for BUM and unicast 625 traffic. 627 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks 629 4.3.1. Control/Data Plane setup procedures on the GWs 631 In this case, there is no impact on the procedures described in 632 [RFC7041] for the B-component. However the I-component instances 633 become EVI instances with EVPN-Overlay bindings and potentially local 634 attachment circuits. A number of MAC-VRF instances can be multiplexed 635 into the same B-component instance. This option provides significant 636 savings in terms of PWs to be maintained in the WAN. 638 The I-ESI concept described in section 4.2.1 will also be used for 639 the PBB-VPLS-based Interconnect. 641 B-component PWs and I-component EVPN-overlay bindings established to 642 the same far-end will be compared. The following rules will be 643 observed: 645 o Attempts to setup a PW between the two GWs within the B- 646 component context will never be blocked. 648 o If a PW exists between two GWs for the B-component and an 649 attempt is made to setup an EVPN binding on an I-component linked 650 to that B-component, the EVPN binding will be kept operationally 651 down. Note that the BGP EVPN routes will still be valid but not 652 used. 654 o The EVPN binding will only be up and used as long as there is no 655 PW to the same far-end in the corresponding B-component. The EVPN 656 bindings in the I-components will be brought down before the PW in 657 the B-component is brought up. 659 The optimizations procedures described in section 3.5 can also be 660 applied to this Interconnect option. 662 4.3.2. Multi-homing procedures on the GWs 664 This model supports single-active multi-homing on the GWs. All-active 665 multi-homing is not supported by this scenario. 667 The single-active multi-homing procedures as described by [EVPN- 668 Overlays] will be followed for the I-ES for each EVI instance 669 connected to the B-component. Note that in this case, for a given 670 EVI, all the EVPN bindings in the I-component are assigned to the I- 671 ES. The non-DF GW for the I-ES will block the transmission and 672 reception of all the I-component EVPN bindings for BUM and unicast 673 traffic. When learning MACs from the WAN, the non-DF MUST NOT 674 advertise EVPN MAC/IP routes for those MACs. 676 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks 678 If EVPN for MPLS tunnels, EVPN-MPLS hereafter, is supported in the 679 WAN, an end-to-end EVPN solution can be deployed. The following 680 sections describe the proposed solution as well as the impact 681 required on the [RFC7432] procedures. 683 4.4.1. Control Plane setup procedures on the GWs 685 The GWs MUST establish separate BGP sessions for sending/receiving 686 EVPN routes to/from the DC and to/from the WAN. Normally each GW will 687 setup one BGP EVPN session to the DC RR (or two BGP EVPN sessions if 688 there are redundant DC RRs) and one session to the WAN RR (or two 689 sessions if there are redundant WAN RRs). 691 In order to facilitate separate BGP processes for DC and WAN, EVPN 692 routes sent to the WAN SHOULD carry a different route-distinguisher 693 (RD) than the EVPN routes sent to the DC. In addition, although 694 reusing the same value is possible, different route-targets are 695 expected to be handled for the same EVI in the WAN and the DC. Note 696 that the EVPN service routes sent to the DC RRs will normally include 697 a [TUNNEL-ENCAP] BGP encapsulation extended community with a 698 different tunnel type than the one sent to the WAN RRs. 700 As in the other discussed options, an I-ES and its assigned I-ESI 701 will be configured on the GWs for multi-homing. This I-ES represents 702 the WAN EVPN-MPLS PEs to the DC but also the DC EVPN-Overlay NVEs to 703 the WAN. Optionally, different I-ESI values are configured for 704 representing the WAN and the DC. If different EVPN-Overlay networks 705 are connected to the same group of GWs, each EVPN-Overlay network 706 MUST get assigned a different I-ESI. 708 Received EVPN routes will never be reflected on the GWs but consumed 709 and re-advertised (if needed): 711 o Ethernet A-D routes, ES routes and Inclusive Multicast routes 712 are consumed by the GWs and processed locally for the 713 corresponding [RFC7432] procedures. 715 o MAC/IP advertisement routes will be received, imported and if 716 they become active in the MAC-VRF, the information will be re- 717 advertised as new routes with the following fields: 719 + The RD will be the GW's RD for the MAC-VRF. 721 + The ESI will be set to the I-ESI. 723 + The Ethernet-tag value will be kept from the received NLRI. 725 + The MAC length, MAC address, IP Length and IP address values 726 will be kept from the received NLRI. 728 + The MPLS label will be a local 20-bit value (when sent to the 729 WAN) or a DC-global 24-bit value (when sent to the DC for 730 encapsulations using a VNI). 732 + The appropriate Route-Targets (RTs) and [TUNNEL-ENCAP] BGP 733 Encapsulation extended community will be used according to 734 [EVPN-Overlays]. 736 The GWs will also generate the following local EVPN routes that will 737 be sent to the DC and WAN, with their corresponding RTs and [TUNNEL- 738 ENCAP] BGP Encapsulation extended community values: 740 o ES route(s) for the I-ESI(s). 742 o Ethernet A-D routes per ES and EVI for the I-ESI(s). The A-D 743 per-EVI routes sent to the WAN and the DC will have consistent 744 Ethernet-Tag values. 746 o Inclusive Multicast routes with independent tunnel type value 747 for the WAN and DC. E.g. a P2MP LSP may be used in the WAN 748 whereas ingress replication may be used in the DC. The routes 749 sent to the WAN and the DC will have a consistent Ethernet-Tag. 751 o MAC/IP advertisement routes for MAC addresses learned in local 752 attachment circuits. Note that these routes will not include the 753 I-ESI, but ESI=0 or different from 0 for local multi-homed 754 Ethernet Segments (ES). The routes sent to the WAN and the DC 755 will have a consistent Ethernet-Tag. 757 Assuming GW1 and GW2 are peer GWs of the same DC, each GW will 758 generate two sets of the above local service routes: Set-DC will be 759 sent to the DC RRs and will include A-D per EVI, Inclusive Multicast 760 and MAC/IP routes for the DC encapsulation and RT. Set-WAN will be 761 sent to the WAN RRs and will include the same routes but using the 762 WAN RT and encapsulation. GW1 and GW2 will receive each other's set- 763 DC and set-WAN. This is the expected behavior on GW1 and GW2 for 764 locally generated routes: 766 o Inclusive multicast routes: when setting up the flooding lists 767 for a given MAC-VRF, each GW will include its DC peer GW only in 768 the EVPN-MPLS flooding list (by default) and not the EVPN- 769 Overlay flooding list. That is, GW2 will import two Inclusive 770 Multicast routes from GW1 (from set-DC and set-WAN) but will 771 only consider one of the two, having the set-WAN route higher 772 priority. An administrative option MAY change this preference so 773 that the set-DC route is selected first. 775 o MAC/IP advertisement routes for local attachment circuits: as 776 above, the GW will select only one, having the route from the 777 set-WAN a higher priority. As with the Inclusive multicast 778 routes, an administrative option MAY change this priority. 780 4.4.2. Data Plane setup procedures on the GWs 782 The procedure explained at the end of the previous section will make 783 sure there are no loops or packet duplication between the GWs of the 784 same EVPN-Overlay network (for frames generated from local ACs) since 785 only one EVPN binding per EVI (or per Ethernet Tag in case of VLAN- 786 aware bundle services) will be setup in the data plane between the 787 two nodes. That binding will by default be added to the EVPN-MPLS 788 flooding list. 790 As for the rest of the EVPN tunnel bindings, they will be added to 791 one of the two flooding lists that each GW sets up for the same MAC- 792 VRF: 794 o EVPN-overlay flooding list (composed of bindings to the remote 795 NVEs or multicast tunnel to the NVEs). 797 o EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the 798 remote PEs) 800 Each flooding list will be part of a separate split-horizon-group: 801 the WAN split-horizon-group or the DC split-horizon-group. Traffic 802 generated from a local AC can be flooded to both 803 split-horizon-groups. Traffic from a binding of a split-horizon-group 804 can be flooded to the other split-horizon-group and local ACs, but 805 never to a member of its own split-horizon-group. 807 When either GW1 or GW2 receive a BUM frame on an MPLS tunnel 808 including an ESI label at the bottom of the stack, they will perform 809 an ESI label lookup and split-horizon filtering as per [RFC7432] in 810 case the ESI label identifies a local ESI (I-ESI or any other non- 811 zero ESI). 813 4.4.3. Multi-homing procedure extensions on the GWs 815 This model supports single-active as well as all-active multi-homing. 817 All the [RFC7432] multi-homing procedures for the DF election on I- 818 ES(s) as well as the backup-path (single-active) and aliasing (all- 819 active) procedures will be followed on the GWs. Remote PEs in the 820 EVPN-MPLS network will follow regular [RFC7432] aliasing or backup- 821 path procedures for MAC/IP routes received from the GWs for the same 822 I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP routes 823 received with the same I-ESI. 825 As far as the forwarding plane is concerned, by default, the EVPN- 826 Overlay network will have an analogous behavior to the access ACs in 827 [RFC7432] multi-homed Ethernet Segments. 829 The forwarding behavior on the GWs is described below: 831 o Single-active multi-homing; assuming a WAN split-horizon-group 832 (comprised of EVPN-MPLS bindings), a DC split-horizon-group 833 (comprised of EVPN-Overlay bindings) and local ACs on the GWs: 835 + Forwarding behavior on the non-DF: the non-DF MUST block 836 ingress and egress forwarding on the EVPN-Overlay bindings 837 associated to the I-ES. The EVPN-MPLS network is considered to 838 be the core network and the EVPN-MPLS bindings to the remote 839 PEs and GWs will be active. 841 + Forwarding behavior on the DF: the DF MUST NOT forward BUM or 842 unicast traffic received from a given split-horizon-group to a 843 member of his own split-horizon group. Forwarding to other 844 split-horizon-groups and local ACs is allowed (as long as the 845 ACs are not part of an ES for which the node is non-DF). As 846 per [RFC7432] and for split-horizon purposes, when receiving 847 BUM traffic on the EVPN-Overlay bindings associated to an I- 848 ES, the DF GW SHOULD add the I-ESI label when forwarding to 849 the peer GW over EVPN-MPLS. 851 + When receiving EVPN MAC/IP routes from the WAN, the non-DF 852 MUST NOT re-originate the EVPN routes and advertise them to 853 the DC peers. In the same way, EVPN MAC/IP routes received 854 from the DC MUST NOT be advertised to the WAN peers. This is 855 consistent with [RFC7432] and allows the remote PE/NVEs know 856 who the primary GW is, based on the reception of the MAC/IP 857 routes. 859 o All-active multi-homing; assuming a WAN split-horizon-group 860 (comprised of EVPN-MPLS bindings), a DC split-horizon-group 861 (comprised of EVPN-Overlay bindings) and local ACs on the GWs: 863 + Forwarding behavior on the non-DF: the non-DF follows the same 864 behavior as the non-DF in the single-active case but only for 865 BUM traffic. Unicast traffic received from a split-horizon- 866 group MUST NOT be forwarded to a member of its own split- 867 horizon-group but can be forwarded normally to the other 868 split-horizon-groups and local ACs. If a known unicast packet 869 is identified as a "flooded" packet, the procedures for BUM 870 traffic MUST be followed. 872 + Forwarding behavior on the DF: the DF follows the same 873 behavior as the DF in the single-active case but only for BUM 874 traffic. Unicast traffic received from a split-horizon-group 875 MUST NOT be forwarded to a member of its own split-horizon- 876 group but can be forwarded normally to the other split- 877 horizon-group and local ACs. If a known unicast packet is 878 identified as a "flooded" packet, the procedures for BUM 879 traffic MUST be followed. As per [RFC7432] and for split- 880 horizon purposes, when receiving BUM traffic on the EVPN- 881 Overlay bindings associated to an I-ES, the DF GW MUST add the 882 I-ESI label when forwarding to the peer GW over EVPN-MPLS. 884 + Contrary to the single-active multi-homing case, both DF and 885 non-DF re-originate and advertise MAC/IP routes received from 886 the WAN/DC peers, adding the corresponding I-ESI so that the 887 remote PE/NVEs can perform regular aliasing as per [RFC7432]. 889 The example in Figure 3 illustrates the forwarding of BUM traffic 890 originated from an NVE on a pair of all-active multi-homing GWs. 892 |<--EVPN-Overlay--->|<--EVPN-MPLS-->| 894 +---------+ +--------------+ 895 +----+ BUM +---+ | 896 |NVE1+----+----> | +-+-----+ | 897 +----+ | | DF |GW1| | | | 898 | | +-+-+ | | ++--+ 899 | | | | +--> |PE1| 900 | +--->X +-+-+ | ++--+ 901 | NDF| | | | 902 +----+ | |GW2<-+ | 903 |NVE2+--+ +-+-+ | 904 +----+ +--------+ | +------------+ 905 v 906 +--+ 907 |CE| 908 +--+ 910 Figure 3 Multi-homing BUM forwarding 912 GW2 is the non-DF for the I-ES and blocks the BUM forwarding. GW1 is 913 the DF and forwards the traffic to PE1 and GW2. Packets sent to GW2 914 will include the ESI-label for the I-ES. Based on the ESI-label, GW2 915 identifies the packets as I-ES-generated packets and will only 916 forward them to local ACs (CE in the example) and not back to the 917 EVPN-Overlay network. 919 4.4.4. Impact on MAC Mobility procedures 921 MAC Mobility procedures described in [RFC7432] are not modified by 922 this document. 924 Note that an intra-DC MAC move still leaves the MAC attached to the 925 same I-ES, so under the rules of [RFC7432] this is not considered a 926 MAC mobility event. Only when the MAC moves from the WAN domain to 927 the DC domain (or from one DC to another) the MAC will be learned 928 from a different ES and the MAC Mobility procedures will kick in. 930 The sticky bit indication in the MAC Mobility extended community MUST 931 be propagated between domains. 933 4.4.5. Gateway optimizations 935 All the Gateway optimizations described in section 3.5 MAY be applied 936 to the GWs when the Interconnect is based on EVPN-MPLS. 938 In particular, the use of the Unknown MAC Route, as described in 939 section 3.5.1, solves some transient packet duplication issues in 940 cases of all-active multi-homing, as explained below. 942 Consider the diagram in Figure 2 for EVPN-MPLS Interconnect and all- 943 active multi-homing, and the following sequence: 945 a) MAC Address M1 is advertised from NVE3 in EVI-1. 947 b) GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN 948 with I-ESI-2 in the ESI field. 950 c) GW1 and GW2 learn M1 and install GW3/GW4 as next-hops following 951 the EVPN aliasing procedures. 953 d) Before NVE1 learns M1, a packet arrives at NVE1 with 954 destination M1. If the Unknown MAC Route had not been 955 advertised into the DC, NVE1 would have flooded the packet 956 throughout the DC, in particular to both GW1 and GW2. If the 957 same VNI/VSID is used for both known unicast and BUM traffic, 958 as is typically the case, there is no indication in the packet 959 that it is a BUM packet and both GW1 and GW2 would have 960 forwarded it, creating packet duplication. However, because the 961 Unknown MAC Route had been advertised into the DC, NVE1 will 962 unicast the packet to either GW1 or GW2. 964 e) Since both GW1 and GW2 know M1, the GW receiving the packet 965 will forward it to either GW3 or GW4. 967 4.4.6. Benefits of the EVPN-MPLS Interconnect solution 969 The [EVPN-Overlays] "DCI using ASBRs" solution and the GW solution 970 with EVPN-MPLS Interconnect may be seen similar since they both 971 retain the EVPN attributes between Data Centers and throughout the 972 WAN. However the EVPN-MPLS Interconnect solution on the GWs has 973 significant benefits compared to the "DCI using ASBRs" solution: 975 o As in any of the described GW models, this solution supports the 976 connectivity of local attachment circuits on the GWs. This is 977 not possible in a "DCI using ASBRs" solution. 979 o Different data plane encapsulations can be supported in the DC 980 and the WAN, while a uniform encapsulation is needed in the "DCI 981 using ASBRs" solution. 983 o Optimized multicast solution, with independent inclusive 984 multicast trees in DC and WAN. 986 o MPLS Label aggregation: for the case where MPLS labels are 987 signaled from the NVEs for MAC/IP Advertisement routes, this 988 solution provides label aggregation. A remote PE MAY receive a 989 single label per GW MAC-VRF as opposed to a label per NVE/MAC- 990 VRF connected to the GW MAC-VRF. For instance, in Figure 2, PE 991 would receive only one label for all the routes advertised for a 992 given MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF. 994 o The GW will not propagate MAC mobility for the MACs moving 995 within a DC. Mobility intra-DC is solved by all the NVEs in the 996 DC. The MAC Mobility procedures on the GWs are only required in 997 case of mobility across DCs. 999 o Proxy-ARP/ND function on the DC GWs can be leveraged to reduce 1000 ARP/ND flooding in the DC or/and in the WAN. 1002 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks 1004 PBB-EVPN [RFC7623] is yet another Interconnect option. It requires 1005 the use of GWs where I-components and associated B-components are 1006 part of EVI instances. 1008 4.5.1. Control/Data Plane setup procedures on the GWs 1010 EVPN will run independently in both components, the I-component MAC- 1011 VRF and B-component MAC-VRF. Compared to [RFC7623], the DC C-MACs are 1012 no longer learned in the data plane on the GW but in the control 1013 plane through EVPN running on the I-component. Remote C-MACs coming 1014 from remote PEs are still learned in the data plane. B-MACs in the B- 1015 component will be assigned and advertised following the procedures 1016 described in [RFC7623]. 1018 An I-ES will be configured on the GWs for multi-homing, but its I-ESI 1019 will only be used in the EVPN control plane for the I-component EVI. 1020 No non-reserved ESIs will be used in the control plane of the B- 1021 component EVI as per [RFC7623], that is, the I-ES will be represented 1022 to the WAN PBB-EVPN PEs using shared or dedicated B-MACs. 1024 The rest of the control plane procedures will follow [RFC7432] for 1025 the I-component EVI and [RFC7623] for the B-component EVI. 1027 From the data plane perspective, the I-component and B-component EVPN 1028 bindings established to the same far-end will be compared and the I- 1029 component EVPN-overlay binding will be kept down following the rules 1030 described in section 4.3.1. 1032 4.5.2. Multi-homing procedures on the GWs 1034 This model supports single-active as well as all-active multi-homing. 1036 The forwarding behavior of the DF and non-DF will be changed based on 1037 the description outlined in section 4.4.3, only replacing the "WAN 1038 split-horizon-group" for the B-component, and using [RFC7623] 1039 procedures for the traffic sent or received on the B-component. 1041 4.5.3. Impact on MAC Mobility procedures 1043 C-MACs learned from the B-component will be advertised in EVPN within 1044 the I-component EVI scope. If the C-MAC was previously known in the 1045 I-component database, EVPN would advertise the C-MAC with a higher 1046 sequence number, as per [RFC7432]. From a Mobility perspective and 1047 the related procedures described in [RFC7432], the C-MACs learned 1048 from the B-component are considered local. 1050 4.5.4. Gateway optimizations 1052 All the considerations explained in section 4.4.5 are applicable to 1053 the PBB-EVPN Interconnect option. 1055 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks 1057 If EVPN for Overlay tunnels is supported in the WAN and a GW function 1058 is required, an end-to-end EVPN solution can be deployed. While 1059 multiple Overlay tunnel combinations at the WAN and the DC are 1060 possible (MPLSoGRE, nvGRE, etc.), VXLAN is described here, given its 1061 popularity in the industry. This section focuses on the specific case 1062 of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the 1063 [RFC7432] procedures. 1065 The procedures described in section 4.4 apply to this section too, 1066 only replacing EVPN-MPLS for EVPN-VXLAN control plane specifics and 1067 using [EVPN-Overlays] "Local Bias" procedures instead of section 1068 4.4.3. Since there are no ESI-labels in VXLAN, GWs need to rely on 1069 "Local Bias" to apply split-horizon on packets generated from the I- 1070 ES and sent to the peer GW. 1072 This use-case assumes that NVEs need to use the VNIs or VSIDs as a 1073 globally unique identifiers within a data center, and a Gateway needs 1074 to be employed at the edge of the data center network to translate 1075 the VNI or VSID when crossing the network boundaries. This GW 1076 function provides VNI and tunnel IP address translation. The use-case 1077 in which local downstream assigned VNIs or VSIDs can be used (like 1078 MPLS labels) is described by [EVPN-Overlays]. 1080 While VNIs are globally significant within each DC, there are two 1081 possibilities in the Interconnect network: 1083 a) Globally unique VNIs in the Interconnect network: 1084 In this case, the GWs and PEs in the Interconnect network will 1085 agree on a common VNI for a given EVI. The RT to be used in the 1086 Interconnect network can be auto-derived from the agreed 1087 Interconnect VNI. The VNI used inside each DC MAY be the same 1088 as the Interconnect VNI. 1090 b) Downstream assigned VNIs in the Interconnect network. 1091 In this case, the GWs and PEs MUST use the proper RTs to 1092 import/export the EVPN routes. Note that even if the VNI is 1093 downstream assigned in the Interconnect network, and unlike 1094 option (a), it only identifies the pair and 1095 not the pair. The VNI used inside 1096 each DC MAY be the same as the Interconnect VNI. GWs SHOULD 1097 support multiple VNI spaces per EVI (one per Interconnect 1098 network they are connected to). 1100 In both options, NVEs inside a DC only have to be aware of a single 1101 VNI space, and only GWs will handle the complexity of managing 1102 multiple VNI spaces. In addition to VNI translation above, the GWs 1103 will provide translation of the tunnel source IP for the packets 1104 generated from the NVEs, using their own IP address. GWs will use 1105 that IP address as the BGP next-hop in all the EVPN updates to the 1106 Interconnect network. 1108 The following sections provide more details about these two options. 1110 4.6.1. Globally unique VNIs in the Interconnect network 1112 Considering Figure 2, if a host H1 in NVO-1 needs to communicate with 1113 a host H2 in NVO-2, and assuming that different VNIs are used in each 1114 DC for the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then 1115 the VNIs MUST be translated to a common Interconnect VNI (e.g. VNI- 1116 100) on the GWs. Each GW is provisioned with a VNI translation 1117 mapping so that it can translate the VNI in the control plane when 1118 sending BGP EVPN route updates to the Interconnect network. In other 1119 words, GW1 and GW2 MUST be configured to map VNI-10 to VNI-100 in the 1120 BGP update messages for H1's MAC route. This mapping is also used to 1121 translate the VNI in the data plane in both directions, that is, VNI- 1122 10 to VNI-100 when the packet is received from NVO-1 and the reverse 1123 mapping from VNI-100 to VNI-10 when the packet is received from the 1124 remote NVO-2 network and needs to be forwarded to NVO-1. 1126 The procedures described in section 4.4 will be followed, considering 1127 that the VNIs advertised/received by the GWs will be translated 1128 accordingly. 1130 4.6.2. Downstream assigned VNIs in the Interconnect network 1132 In this case, if a host H1 in NVO-1 needs to communicate with a host 1133 H2 in NVO-2, and assuming that different VNIs are used in each DC for 1134 the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs 1135 MUST be translated as in section 4.6.1. However, in this case, there 1136 is no need to translate to a common Interconnect VNI on the GWs. Each 1137 GW can translate the VNI received in an EVPN update to a locally 1138 assigned VNI advertised to the Interconnect network. Each GW can use 1139 a different Interconnect VNI, hence this VNI does not need to be 1140 agreed on all the GWs and PEs of the Interconnect network. 1142 The procedures described in section 4.4 will be followed, taking the 1143 considerations above for the VNI translation. 1145 5. Security Considerations 1147 This document applies existing specifications to a number of 1148 Interconnect models. The Security Considerations included in those 1149 documents, such as [RFC7432], [EVPN-Overlays], [RFC7623], [RFC4761] 1150 and [RFC4762] apply to this document whenever those technologies are 1151 used. 1153 As discussed, [EVPN-Overlays] discusses two main DCI solution groups: 1154 "DCI using GWs" and "DCI using ASBRs". This document specifies the 1155 solutions that correspond to the "DCI using GWs" group. It is 1156 important to note that the use of GWs provide a superior level of 1157 security on a per tenant basis, compared to the use of ASBRs. This is 1158 due to the fact that GWs need to perform a MAC lookup on the frames 1159 being received from the WAN, and they apply security procedures, such 1160 as filtering of undesired frames, filtering of frames with a source 1161 MAC that matches a protected MAC in the DC or application of MAC 1162 duplication procedures defined in [RFC7432]. On ASBRs though, traffic 1163 is forwarded based on a label or VNI swap and there is usually no 1164 visibility of the encapsulated frames, which can carry malicious 1165 traffic. 1167 In addition, the GW optimizations specified in this document, provide 1168 additional protection of the DC Tenant Systems. For instance, the MAC 1169 address advertisement control and Unknown MAC Route defined in 1170 section 3.5.1 protect the DC NVEs from being overwhelmed with an 1171 excessive number MAC/IP routes being learned on the GWs from the WAN. 1172 The ARP/ND flooding control described in 3.5.2 can reduce/suppress 1173 broadcast storms being injected from the WAN. 1175 Finally, the reader should be aware of the potential security 1176 implications of designing a DCI with the Decoupled Interconnect 1177 solution (section 3) or the Integrated Interconnect solution (section 1178 4). In the Decoupled Interconnect solution the DC is typically easier 1179 to protect from the WAN, since each GW has a single logical link to 1180 one WAN PE, whereas in the Integrated solution, the GW has logical 1181 links to all the WAN PEs that are attached to the tenant. In either 1182 model, proper control plane and data plane policies should be put in 1183 place in the GWs in order to protect the DC from potential attacks 1184 coming from the WAN. 1186 6. IANA Considerations 1188 This document has no IANA actions. 1190 7. References 1192 7.1. Normative References 1194 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private 1195 LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", 1196 RFC 4761, DOI 10.17487/RFC4761, January 2007, . 1199 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 1200 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1201 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1202 . 1204 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1205 "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual 1206 Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 1207 2011, . 1209 [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., 1210 "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge 1211 (PE) Model for Provider Backbone Bridging", RFC 7041, DOI 1212 10.17487/RFC7041, November 2013, . 1215 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1216 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 1217 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 1220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1221 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1222 1997, . 1224 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1225 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 1226 . 1228 [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation 1229 Attribute", draft-ietf-idr-tunnel-encaps-08, work in progress, 1230 January 11, 2018. 1232 [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with 1233 Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, . 1236 [EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization 1237 Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-11.txt, 1238 work in progress, January, 2018 1240 [RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, 1241 "Covering Prefixes Outbound Route Filter for BGP-4", RFC 7543, DOI 1242 10.17487/RFC7543, May 2015, . 1245 7.2. Informative References 1247 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1248 R., Patel, K., and J. Guichard, "Constrained Route Distribution for 1249 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 1250 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 1251 DOI 10.17487/RFC4684, November 2006, . 1254 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1255 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible 1256 Local Area Network (VXLAN): A Framework for Overlaying Virtualized 1257 Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 1258 10.17487/RFC7348, August 2014, . 1261 [RFC7637] Garg, P., et al., "NVGRE: Network Virtualization using 1262 Generic Routing Encapsulation", RFC 7637, September, 2015 1264 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 1265 "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", 1266 RFC 4023, DOI 10.17487/RFC4023, March 2005, . 1269 [Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms 1270 for Ethernet based networks", July 2011. 1272 [802.1AG] IEEE 802.1AG_2007, "IEEE Standard for Local and 1273 Metropolitan Area Networks - Virtual Bridged Local Area Networks 1274 Amendment 5: Connectivity Fault Management", January 2008. 1276 [802.1Q-2014] IEEE 802.1Q-2014, "IEEE Standard for Local and 1277 metropolitan area networks--Bridges and Bridged Networks", December 1278 2014. 1280 [RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire 1281 Preferential Forwarding Status Bit", RFC 6870, DOI 10.17487/RFC6870, 1282 February 2013, . 1284 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1285 Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, 1286 January 2001, . 1288 8. Acknowledgments 1290 The authors would like to thank Neil Hart, Vinod Prabhu and Kiran 1291 Nagaraj for their valuable comments and feedback. We would also like 1292 to thank Martin Vigoureux and Alvaro Retana for his detailed review 1293 and comments. 1295 9. Contributors 1297 In addition to the authors listed on the front page, the following 1298 co-authors have also contributed to this document: 1300 Ravi Shekhar 1301 Anil Lohiya 1302 Wen Lin 1303 Juniper Networks 1305 Florin Balus 1306 Patrice Brissette 1307 Cisco 1309 Senad Palislamovic 1310 Nokia 1312 Dennis Cai 1313 Alibaba 1315 10. Authors' Addresses 1317 Jorge Rabadan 1318 Nokia 1319 777 E. Middlefield Road 1320 Mountain View, CA 94043 USA 1321 Email: jorge.rabadan@nokia.com 1323 Senthil Sathappan 1324 Nokia 1325 Email: senthil.sathappan@nokia.com 1327 Wim Henderickx 1328 Nokia 1329 Email: wim.henderickx@nokia.com 1331 Ali Sajassi 1332 Cisco 1333 Email: sajassi@cisco.com 1335 John Drake 1336 Juniper 1337 Email: jdrake@juniper.net