idnits 2.17.1 draft-ietf-bess-dci-evpn-overlay-06.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2018) is 2283 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) == Missing Reference: 'RFC8174' is mentioned on line 125, but not defined ** 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 -- No information found for draft-ietf-bess-evpn-vpls-integration - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 Nokia 7 A. Sajassi 8 Cisco 10 J. Drake 11 Juniper 13 Expires: July 26, 2018 January 22, 2018 15 Interconnect Solution for EVPN Overlay networks 16 draft-ietf-bess-dci-evpn-overlay-06 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. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 This Internet-Draft will expire on July 26, 2018. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Decoupled Interconnect solution for EVPN overlay networks . . . 5 78 3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 6 79 3.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 7 80 3.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 7 81 3.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 8 82 3.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 8 83 3.5.1. MAC Address Advertisement Control . . . . . . . . . . . 8 84 3.5.2. ARP/ND flooding control . . . . . . . . . . . . . . . . 9 85 3.5.3. Handling failures between GW and WAN Edge routers . . . 9 86 4. Integrated Interconnect solution for EVPN overlay networks . . 10 87 4.1. Interconnect requirements . . . . . . . . . . . . . . . . . 10 88 4.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 11 89 4.2.1. Control/Data Plane setup procedures on the GWs . . . . 11 90 4.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 12 91 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 12 92 4.3.1. Control/Data Plane setup procedures on the GWs . . . . 12 93 4.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 13 94 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 13 95 4.4.1. Control Plane setup procedures on the GWs . . . . . . . 13 96 4.4.2. Data Plane setup procedures on the GWs . . . . . . . . 15 97 4.4.3. Multi-homing procedure extensions on the GWs . . . . . 16 98 4.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 18 99 4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 18 100 4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 19 101 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 20 102 4.5.1. Control/Data Plane setup procedures on the GWs . . . . 20 103 4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 20 104 4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 21 105 4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 21 106 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 21 107 4.6.1. Globally unique VNIs in the Interconnect network . . . 22 108 4.6.2. Downstream assigned VNIs in the Interconnect network . 22 109 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 23 110 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 111 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 112 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 113 7.2. Informative References . . . . . . . . . . . . . . . . . . 24 114 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 25 115 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 116 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 118 1. Conventions and Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 AC: Attachment Circuit. 128 ARP: Address Resolution Protocol. 130 BUM: it refers to the Broadcast, Unknown unicast and Multicast 131 traffic. 133 CFM: Connectivity Fault Management. 135 DC and DCI: Data Center and Data Center Interconnect. 137 DC RR(s) and WAN RR(s): it refers to the Data Center and Wide Area 138 Network Route Reflectors, respectively. 140 DF and NDF: Designated Forwarder and Non-Designated Forwarder. 142 EVI: EVPN Instance. 144 ES: Ethernet Segment. 146 ESI: Ethernet Segment Identifier. 148 GW: Gateway or Data Center Gateway. 150 I-ESI: Interconnect ESI defined on the GWs for multi-homing to/from 151 the WAN. 153 MAC-VRF: it refers to an EVI instance in a particular node. 155 MP2P and LSM tunnels: it refers to Multi-Point to Point and Label 156 Switched Multicast tunnels. 158 ND: Neighbor Discovery protocol. 160 NVE: Network Virtualization Edge. 162 NVGRE: Network Virtualization using Generic Routing Encapsulation. 164 NVO: refers to Network Virtualization Overlays. 166 OAM: Operations and Maintenance. 168 PBB: Provider Backbone Bridging. 170 PW: Pseudowire. 172 RD: Route-Distinguisher. 174 RT: Route-Target. 176 S/C-TAG: It refers to a combination of Service Tag and Customer Tag 177 in a 802.1Q frame. 179 TOR: Top-Of-Rack switch. 181 VNI/VSID: refers to VXLAN/NVGRE virtual identifiers. 183 VPLS: Virtual Private LAN Service. 185 VSI: Virtual Switch Instance or VPLS instance in a particular PE. 187 VXLAN: Virtual eXtensible LAN. 189 2. Introduction 191 [EVPN-Overlays] discusses the use of Ethernet Virtual Private 192 Networks (EVPN) [RFC7432] as the control plane for Network 193 Virtualization Overlays (NVO), where VXLAN [RFC7348], NVGRE [RFC7637] 194 or MPLS over GRE [RFC4023] can be used as possible data plane 195 encapsulation options. 197 While this model provides a scalable and efficient multi-tenant 198 solution within the Data Center, it might not be easily extended to 199 the Wide Area Network (WAN) in some cases due to the requirements and 200 existing deployed technologies. For instance, a Service Provider 201 might have an already deployed Virtual Private LAN Service (VPLS) 202 [RFC4761][RFC4762], VPLS extensions for Provider Backbone Bridging 203 (PBB-VPLS) [RFC7041], EVPN [RFC7432] or PBB-EVPN [RFC7623] network 204 that has to be used to interconnect Data Centers and WAN VPN users. A 205 Gateway (GW) function is required in these cases. [EVPN-Overlays] 206 refers to the architectures described in this document as "DCI using 207 GWs". 209 This document describes a Interconnect solution for EVPN overlay 210 networks, assuming that the NVO Gateway (GW) and the WAN Edge 211 functions can be decoupled in two separate systems or integrated into 212 the same system. The former option will be referred as "Decoupled 213 Interconnect solution" throughout the document, whereas the latter 214 one will be referred as "Integrated Interconnect solution". 216 While the Gateways and WAN PEs use existing Technical Specifications 217 in some cases, the document also defines extensions to these 218 Technical Specifications so that the requirements of the 219 Interconnection can be met. In particular, the following EVPN 220 extensions are described: 222 o The Interconnect Ethernet Segment (I-ES). 224 o The use of the Unknown MAC route in a DCI scenario. 226 o The processing of EVPN routes on Gateways with MAC-VRFs connecting 227 EVPN-Overlay to EVPN-MPLS networks. 229 3. Decoupled Interconnect solution for EVPN overlay networks 231 This section describes the interconnect solution when the GW and WAN 232 Edge functions are implemented in different systems. Figure 1 depicts 233 the reference model described in this section. 235 +--+ 236 |CE| 237 +--+ 238 | 239 +----+ 240 +----| PE |----+ 241 +---------+ | +----+ | +---------+ 242 +----+ | +---+ +----+ +----+ +---+ | +----+ 243 |NVE1|--| | | |WAN | |WAN | | | |--|NVE3| 244 +----+ | |GW1|--|Edge| |Edge|--|GW3| | +----+ 245 | +---+ +----+ +----+ +---+ | 246 | NVO-1 | | WAN | | NVO-2 | 247 | +---+ +----+ +----+ +---+ | 248 | | | |WAN | |WAN | | | | 249 +----+ | |GW2|--|Edge| |Edge|--|GW4| | +----+ 250 |NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4| 251 +----+ +---------+ | | +---------+ +----+ 252 +--------------+ 254 |<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->| 255 hand-off hand-off 257 Figure 1 Decoupled Interconnect model 259 The following section describes the interconnect requirements for 260 this model. 262 3.1. Interconnect requirements 264 The Decoupled Interconnect architecture is intended to be deployed in 265 networks where the EVPN-Overlay and WAN providers are different 266 entities and a clear demarcation is needed. This solution solves the 267 following requirements: 269 o A simple connectivity hand-off between the EVPN-Overlay network 270 provider and the WAN provider so that QoS and security enforcement 271 is easily accomplished. 273 o Independence of the Layer Two VPN (L2VPN) technology deployed in 274 the WAN. 276 o Multi-homing between GW and WAN Edge routers, including per-service 277 load balancing. Per-flow load balancing is not a strong requirement 278 since a deterministic path per service is usually required for an 279 easy QoS and security enforcement. 281 o Support of Ethernet OAM and Connectivity Fault Management (CFM) 282 [802.1AG][Y.1731] functions between the EVPN-Overlay network and 283 the WAN network. 285 o Support for the following optimizations at the GW: 286 + Flooding reduction of unknown unicast traffic sourced from the DC 287 Network Virtualization Edge devices (NVEs). 288 + Control of the WAN MAC addresses advertised to the DC. 289 + Address Resolution Protocol (ARP) and Neighbor Discovery (ND) 290 flooding control for the requests coming from the WAN. 292 3.2. VLAN-based hand-off 294 In this option, the hand-off between the GWs and the WAN Edge routers 295 is based on VLANs [802.1Q-2014]. This is illustrated in Figure 1 296 (between the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in 297 the GW is connected to a different VSI/MAC-VRF instance in the WAN 298 Edge router by using a different C-TAG VLAN ID or a different 299 combination of S/C-TAG VLAN IDs that matches at both sides. 301 This option provides the best possible demarcation between the DC and 302 WAN providers and it does not require control plane interaction 303 between both providers. The disadvantage of this model is the 304 provisioning overhead since the service has to be mapped to a C-TAG 305 or S/C-TAG VLAN ID combination at both GW and WAN Edge routers. 307 In this model, the GW acts as a regular Network Virtualization Edge 308 (NVE) towards the DC. Its control plane, data plane procedures and 309 interactions are described in [EVPN-Overlays]. 311 The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with 312 attachment circuits (ACs) to the GWs. Its functions are described in 313 [RFC4761], [RFC4762], [RFC6074] or [RFC7432], [RFC7623]. 315 3.3. PW-based (Pseudowire-based) hand-off 317 If MPLS between the GW and the WAN Edge router is an option, a PW- 318 based Interconnect solution can be deployed. In this option the 319 hand-off between both routers is based on FEC128-based PWs [RFC4762] 320 or FEC129-based PWs (for a greater level of network automation) 321 [RFC6074]. Note that this model still provides a clear demarcation 322 boundary between DC and WAN (since there is a single PW between each 323 MAC-VRF and peer VSI), and security/QoS policies may be applied on a 324 per PW basis. This model provides better scalability than a C-TAG 325 based hand-off and less provisioning overhead than a combined C/S-TAG 326 hand-off. The PW-based hand-off interconnect is illustrated in Figure 327 1 (between the NVO-2 GWs and the WAN Edge routers). 329 In this model, besides the usual MPLS procedures between GW and WAN 330 Edge router [RFC3031], the GW MUST support an interworking function 331 in each MAC-VRF that requires extension to the WAN: 333 o If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI 334 (WAN Edge), the corresponding VCID MUST be provisioned on the MAC- 335 VRF and match the VCID used in the peer VSI at the WAN Edge router. 337 o If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used 338 between the GW MAC-VRF and the WAN Edge VSI, the provisioning of 339 the VPLS-ID MUST be supported on the MAC-VRF and MUST match the 340 VPLS-ID used in the WAN Edge VSI. 342 3.4. Multi-homing solution on the GWs 344 Single-active multi-homing, i.e. per-service load-balancing multi- 345 homing is required in this type of interconnect. 347 The GWs will be provisioned with a unique ESI per WAN interconnect 348 and the hand-off attachment circuits or PWs between the GW and the 349 WAN Edge router will be assigned to such ESI. The ESI will be 350 administratively configured on the GWs according to the procedures in 351 [RFC7432]. This Interconnect ESI will be referred as "I-ESI" 352 hereafter. 354 The solution (on the GWs) MUST follow the single-active multi-homing 355 procedures as described in [EVPN-Overlays] for the provisioned I-ESI, 356 i.e. Ethernet A-D routes per ESI and per EVI will be advertised to 357 the DC NVEs for the multi-homing functions, ES routes will be 358 advertised so that ES discovery and Designated Forwarder (DF) 359 procedures can be followed. The MAC addresses learned (in the data 360 plane) on the hand-off links will be advertised with the I-ESI 361 encoded in the ESI field. 363 3.5. Gateway Optimizations 365 The following GW features are optional and optimize the control plane 366 and data plane in the DC. 368 3.5.1. MAC Address Advertisement Control 370 The use of EVPN in the NVO networks brings a significant number of 371 benefits as described in [EVPN-Overlays]. However, if multiple DCs 372 are interconnected into a single EVI, each DC will have to import all 373 of the MAC addresses from each of the other DCs. 375 Even if optimized BGP techniques like RT-constraint [RFC4684] are 376 used, the number of MAC addresses to advertise or withdraw (in case 377 of failure) by the GWs of a given DC could overwhelm the NVEs within 378 that DC, particularly when the NVEs reside in the hypervisors. 380 The solution specified in this document uses the 'Unknown MAC' route 381 which is advertised into a given DC by each of the DC's GWs. This 382 route is a regular EVPN MAC/IP Advertisement route in which the MAC 383 Address Length is set to 48, the MAC address is set to 384 00:00:00:00:00:00, the IP length is set to 0, and the ESI field is 385 set to the DC GW's I-ESI. 387 An NVE within that DC that understands and process the Unknown MAC 388 route will send unknown unicast frames to one of the DCs GWs, which 389 will then forward that packet to the correct egress PE. Note that, 390 because the ESI is set to the DC GW's I-ESI, all-active multi-homing 391 can be applied to unknown unicast MAC addresses. 393 This document proposes that local policy determines whether MAC 394 addresses and/or the Unknown MAC route are advertised into a given 395 DC. As an example, when all the DC MAC addresses are learned in the 396 control/management plane, it may be appropriate to advertise only the 397 Unknown MAC route. 399 3.5.2. ARP/ND flooding control 401 Another optimization mechanism, naturally provided by EVPN in the 402 GWs, is the Proxy ARP/ND function. The GWs should build a Proxy 403 ARP/ND cache table as per [RFC7432]. When the active GW receives an 404 ARP/ND request/solicitation coming from the WAN, the GW does a Proxy 405 ARP/ND table lookup and replies as long as the information is 406 available in its table. 408 This mechanism is especially recommended on the GWs, since it 409 protects the DC network from external ARP/ND-flooding storms. 411 3.5.3. Handling failures between GW and WAN Edge routers 413 Link/PE failures are handled on the GWs as specified in [RFC7432]. 414 The GW detecting the failure will withdraw the EVPN routes as per 415 [RFC7432]. 417 Individual AC/PW failures may be detected by OAM mechanisms. For 418 instance: 420 o If the Interconnect solution is based on a VLAN hand-off, Ethernet- 421 CFM [802.1AG][Y.1731] may be used to detect individual AC failures 422 on both, the GW and WAN Edge router. An individual AC failure will 423 trigger the withdrawal of the corresponding A-D per EVI route as 424 well as the MACs learned on that AC. 426 o If the Interconnect solution is based on a PW hand-off, the Label 427 Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be 428 used to detect individual PW failures on both, the GW and WAN Edge 429 router. 431 4. Integrated Interconnect solution for EVPN overlay networks 433 When the DC and the WAN are operated by the same administrative 434 entity, the Service Provider can decide to integrate the GW and WAN 435 Edge PE functions in the same router for obvious CAPEX and OPEX 436 saving reasons. This is illustrated in Figure 2. Note that this model 437 does not provide an explicit demarcation link between DC and WAN 438 anymore. 440 +--+ 441 |CE| 442 +--+ 443 | 444 +----+ 445 +----| PE |----+ 446 +---------+ | +----+ | +---------+ 447 +----+ | +---+ +---+ | +----+ 448 |NVE1|--| | | | | |--|NVE3| 449 +----+ | |GW1| |GW3| | +----+ 450 | +---+ +---+ | 451 | NVO-1 | WAN | NVO-2 | 452 | +---+ +---+ | 453 | | | | | | 454 +----+ | |GW2| |GW4| | +----+ 455 |NVE2|--| +---+ +---+ |--|NVE4| 456 +----+ +---------+ | | +---------+ +----+ 457 +--------------+ 459 |<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->| 460 |<--PBB-VPLS-->| 461 Interconnect -> |<-EVPN-MPLS-->| 462 options |<--EVPN-Ovl-->|* 463 |<--PBB-EVPN-->| 465 Figure 2 Integrated Interconnect model 467 * EVPN-Ovl stands for EVPN-Overlay (and it's an Interconnect option). 469 4.1. Interconnect requirements 471 The Integrated Interconnect solution meets the following 472 requirements: 474 o Control plane and data plane interworking between the EVPN-overlay 475 network and the L2VPN technology supported in the WAN, irrespective 476 of the technology choice, i.e. (PBB-)VPLS or (PBB-)EVPN, as 477 depicted in Figure 2. 479 o Multi-homing, including single-active multi-homing with per-service 480 load balancing or all-active multi-homing, i.e. per-flow load- 481 balancing, as long as the technology deployed in the WAN supports 482 it. 484 o Support for end-to-end MAC Mobility, Static MAC protection and 485 other procedures (e.g. proxy-arp) described in [RFC7432] as long as 486 EVPN-MPLS is the technology of choice in the WAN. 488 o Independent inclusive multicast trees in the WAN and in the DC. 489 That is, the inclusive multicast tree type defined in the WAN does 490 not need to be the same as in the DC. 492 4.2. VPLS Interconnect for EVPN-Overlay networks 494 4.2.1. Control/Data Plane setup procedures on the GWs 496 Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN 497 PEs and RRs as per [RFC4761], [RFC4762], [RFC6074] and overlay 498 tunnels and EVPN will be setup as per [EVPN-Overlays]. Note that 499 different route-targets for the DC and for the WAN are normally 500 required. A single type-1 RD per service may be used. 502 In order to support multi-homing, the GWs will be provisioned with an 503 I-ESI (see section 3.4), that will be unique per interconnection. All 504 the [RFC7432] procedures are still followed for the I-ESI, e.g. any 505 MAC address learned from the WAN will be advertised to the DC with 506 the I-ESI in the ESI field. 508 A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have 509 two different types of tunnel bindings instantiated in two different 510 split-horizon-groups: 512 o VPLS PWs will be instantiated in the "WAN split-horizon-group". 514 o Overlay tunnel bindings (e.g. VXLAN, NVGRE) will be instantiated 515 in the "DC split-horizon-group". 517 Attachment circuits are also supported on the same MAC-VRF, but they 518 will not be part of any of the above split-horizon-groups. 520 Traffic received in a given split-horizon-group will never be 521 forwarded to a member of the same split-horizon-group. 523 As far as BUM flooding is concerned, a flooding list will be composed 524 of the sub-list created by the inclusive multicast routes and the 525 sub-list created for VPLS in the WAN. BUM frames received from a 526 local Attachment Circuit (AC) will be forwarded to the flooding list. 527 BUM frames received from the DC or the WAN will be forwarded to the 528 flooding list observing the split-horizon-group rule described above. 530 Note that the GWs are not allowed to have an EVPN binding and a PW to 531 the same far-end within the same MAC-VRF in order to avoid loops and 532 packet duplication. This is described in [EVPN-VPLS-INTEGRATION] and, 533 in case a GW can successfully establish both, an EVPN binding and a 534 PW to the same far-end PE, the EVPN binding will prevail and the PW 535 will be brought operationally down. 537 The optimizations procedures described in section 3.5 can also be 538 applied to this model. 540 4.2.2. Multi-homing procedures on the GWs 542 This model supports single-active multi-homing on the GWs. All-active 543 multi-homing is not supported by VPLS, therefore it cannot be used on 544 the GWs. 546 All the single-active multi-homing procedures as described by [EVPN- 547 Overlays] will be followed for the I-ESI. 549 The non-DF GW for the I-ESI will block the transmission and reception 550 of all the bindings in the "WAN split-horizon-group" for BUM and 551 unicast traffic. 553 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks 555 4.3.1. Control/Data Plane setup procedures on the GWs 557 In this case, there is no impact on the procedures described in 558 [RFC7041] for the B-component. However the I-component instances 559 become EVI instances with EVPN-Overlay bindings and potentially local 560 attachment circuits. A number of MAC-VRF instances can be multiplexed 561 into the same B-component instance. This option provides significant 562 savings in terms of PWs to be maintained in the WAN. 564 The I-ESI concept described in section 4.2.1 will also be used for 565 the PBB-VPLS-based Interconnect. 567 B-component PWs and I-component EVPN-overlay bindings established to 568 the same far-end will be compared. The following rules will be 569 observed: 571 o Attempts to setup a PW between the two GWs within the B- 572 component context will never be blocked. 574 o If a PW exists between two GWs for the B-component and an 575 attempt is made to setup an EVPN binding on an I-component linked 576 to that B-component, the EVPN binding will be kept operationally 577 down. Note that the BGP EVPN routes will still be valid but not 578 used. 580 o The EVPN binding will only be up and used as long as there is no 581 PW to the same far-end in the corresponding B-component. The EVPN 582 bindings in the I-components will be brought down before the PW in 583 the B-component is brought up. 585 The optimizations procedures described in section 3.5 can also be 586 applied to this Interconnect option. 588 4.3.2. Multi-homing procedures on the GWs 590 This model supports single-active multi-homing on the GWs. All-active 591 multi-homing is not supported by this scenario. 593 All the single-active multi-homing procedures as described by [EVPN- 594 Overlays] will be followed for the I-ESI for each EVI instance 595 connected to B-component. 597 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks 599 If EVPN for MPLS tunnels, EVPN-MPLS hereafter, is supported in the 600 WAN, an end-to-end EVPN solution can be deployed. The following 601 sections describe the proposed solution as well as the impact 602 required on the [RFC7432] procedures. 604 4.4.1. Control Plane setup procedures on the GWs 606 The GWs MUST establish separate BGP sessions for sending/receiving 607 EVPN routes to/from the DC and to/from the WAN. Normally each GW will 608 setup one BGP EVPN session to the DC RR (or two BGP EVPN sessions if 609 there are redundant DC RRs) and one session to the WAN RR (or two 610 sessions if there are redundant WAN RRs). 612 In order to facilitate separate BGP processes for DC and WAN, EVPN 613 routes sent to the WAN SHOULD carry a different route-distinguisher 614 (RD) than the EVPN routes sent to the DC. In addition, although 615 reusing the same value is possible, different route-targets are 616 expected to be handled for the same EVI in the WAN and the DC. Note 617 that the EVPN service routes sent to the DC RRs will normally include 618 a [TUNNEL-ENCAP] BGP encapsulation extended community with a 619 different tunnel type than the one sent to the WAN RRs. 621 As in the other discussed options, an I-ESI will be configured on the 622 GWs for multi-homing. This I-ESI represents the WAN to the DC but 623 also the DC to the WAN. Optionally, different I-ESI values are 624 configured for representing the WAN and the DC. If different EVPN- 625 Overlay networks are connected to the same group of GWs, each EVPN- 626 Overlay network MUST get assigned a different I-ESI. 628 Received EVPN routes will never be reflected on the GWs but consumed 629 and re-advertised (if needed): 631 o Ethernet A-D routes, ES routes and Inclusive Multicast routes 632 are consumed by the GWs and processed locally for the 633 corresponding [RFC7432] procedures. 635 o MAC/IP advertisement routes will be received, imported and if 636 they become active in the MAC-VRF, the information will be re- 637 advertised as new routes with the following fields: 639 + The RD will be the GW's RD for the MAC-VRF. 641 + The ESI will be set to the I-ESI. 643 + The Ethernet-tag value will be kept from the received NLRI. 645 + The MAC length, MAC address, IP Length and IP address values 646 will be kept from the received NLRI. 648 + The MPLS label will be a local 20-bit value (when sent to the 649 WAN) or a DC-global 24-bit value (when sent to the DC). 651 + The appropriate Route-Targets (RTs) and [TUNNEL-ENCAP] BGP 652 Encapsulation extended community will be used according to 653 [EVPN-Overlays]. 655 The GWs will also generate the following local EVPN routes that will 656 be sent to the DC and WAN, with their corresponding RTs and [TUNNEL- 657 ENCAP] BGP Encapsulation extended community values: 659 o ES route(s) for the I-ESI(s). 661 o Ethernet A-D routes per ESI and EVI for the I-ESI(s). The A-D 662 per-EVI routes sent to the WAN and the DC will have consistent 663 Ethernet-Tag values. 665 o Inclusive Multicast routes with independent tunnel type value 666 for the WAN and DC. E.g. a P2MP LSP may be used in the WAN 667 whereas ingress replication may be used in the DC. The routes 668 sent to the WAN and the DC will have a consistent Ethernet-Tag. 670 o MAC/IP advertisement routes for MAC addresses learned in local 671 attachment circuits. Note that these routes will not include the 672 I-ESI, but ESI=0 or different from 0 for local multi-homed 673 Ethernet Segments (ES). The routes sent to the WAN and the DC 674 will have a consistent Ethernet-Tag. 676 Assuming GW1 and GW2 are peer GWs of the same DC, each GW will 677 generate two sets of local service routes: Set-DC will be sent to the 678 DC RRs and will include A-D per EVI, Inclusive Multicast and MAC/IP 679 routes for the DC encapsulation and RT. Set-WAN will be sent to the 680 WAN RRs and will include the same routes but using the WAN RT and 681 encapsulation. GW1 and GW2 will receive each other's set-DC and set- 682 WAN. This is the expected behavior on GW1 and GW2 for locally 683 generated routes: 685 o Inclusive multicast routes: when setting up the flooding lists 686 for a given MAC-VRF, each GW will include its DC peer GW only in 687 the EVPN-MPLS flooding list (by default) and not the EVPN- 688 Overlay flooding list. That is, GW2 will import two Inclusive 689 Multicast routes from GW1 (from set-DC and set-WAN) but will 690 only consider one of the two, having the set-WAN route higher 691 priority. An administrative option MAY change this preference so 692 that the set-DC route is selected first. 694 o MAC/IP advertisement routes for local attachment circuits: as 695 above, the GW will select only one, having the route from the 696 set-WAN a higher priority. As with the Inclusive multicast 697 routes, an administrative option MAY change this priority. 699 Note that, irrespective of the encapsulation, EVPN routes always have 700 higher priority than VPLS AD routes as indicated in [EVPN-VPLS- 701 INTEGRATION]. 703 4.4.2. Data Plane setup procedures on the GWs 705 The procedure explained at the end of the previous section will make 706 sure there are no loops or packet duplication between the GWs of the 707 same EVPN-Overlay network (for frames generated from local ACs) since 708 only one EVPN binding per EVI (or per Ethernet Tag in case of VLAN- 709 aware bundle services) will be setup in the data plane between the 710 two nodes. That binding will by default be added to the EVPN-MPLS 711 flooding list. 713 As for the rest of the EVPN tunnel bindings, they will be added to 714 one of the two flooding lists that each GW sets up for the same MAC- 715 VRF: 717 o EVPN-overlay flooding list (composed of bindings to the remote 718 NVEs or multicast tunnel to the NVEs). 720 o EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the 721 remote PEs) 723 Each flooding list will be part of a separate split-horizon-group: 724 the WAN split-horizon-group or the DC split-horizon-group. Traffic 725 generated from a local AC can be flooded to both 726 split-horizon-groups. Traffic from a binding of a split-horizon-group 727 can be flooded to the other split-horizon-group and local ACs, but 728 never to a member of its own split-horizon-group. 730 When either GW1 or GW2 receive a BUM frame on an MPLS tunnel 731 including an ESI label at the bottom of the stack, they will perform 732 an ESI label lookup and split-horizon filtering as per [RFC7432] in 733 case the ESI label identifies a local ESI (I-ESI or any other non- 734 zero ESI). 736 4.4.3. Multi-homing procedure extensions on the GWs 738 This model supports single-active as well as all-active multi-homing. 740 All the [RFC7432] multi-homing procedures for the DF election on I- 741 ESI(s) as well as the backup-path (single-active) and aliasing (all- 742 active) procedures will be followed on the GWs. Remote PEs in the 743 EVPN-MPLS network will follow regular [RFC7432] aliasing or backup- 744 path procedures for MAC/IP routes received from the GWs for the same 745 I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP routes 746 received with the same I-ESI. 748 As far as the forwarding plane is concerned, by default, the EVPN- 749 Overlay network will have an analogous behavior to the access ACs in 750 [RFC7432] multi-homed Ethernet Segments. 752 The forwarding behavior on the GWs is described below: 754 o Single-active multi-homing; assuming a WAN split-horizon-group 755 (comprised of EVPN-MPLS bindings), a DC split-horizon-group 756 (comprised of EVPN-Overlay bindings) and local ACs on the GWs: 758 + Forwarding behavior on the non-DF: the non-DF MUST block 759 ingress and egress forwarding on the EVPN-Overlay bindings 760 associated to the I-ESI. The EVPN-MPLS network is considered 761 to be the core network and the EVPN-MPLS bindings to the 762 remote PEs and GWs will be active. 764 + Forwarding behavior on the DF: the DF MUST NOT forward BUM or 765 unicast traffic received from a given split-horizon-group to a 766 member of his own split-horizon group. Forwarding to other 767 split-horizon-groups and local ACs is allowed (as long as the 768 ACs are not part of an ES for which the node is non-DF). As 769 per [RFC7432] and for split-horizon purposes, when receiving 770 BUM traffic on the EVPN-Overlay bindings associated to an I- 771 ESI, the DF GW SHOULD add the I-ESI label when forwarding to 772 the peer GW over EVPN-MPLS. 774 + When receiving EVPN MAC/IP routes from the WAN, the non-DF 775 MUST NOT re-originate the EVPN routes and advertise them to 776 the DC peers. In the same way, EVPN MAC/IP routes received 777 from the DC MUST NOT be advertised to the WAN peers. This is 778 consistent with [RFC7432] and allows the remote PE/NVEs know 779 who the primary GW is, based on the reception of the MAC/IP 780 routes. 782 o All-active multi-homing; assuming a WAN split-horizon-group 783 (comprised of EVPN-MPLS bindings), a DC split-horizon-group 784 (comprised of EVPN-Overlay bindings) and local ACs on the GWs: 786 + Forwarding behavior on the non-DF: the non-DF follows the same 787 behavior as the non-DF in the single-active case but only for 788 BUM traffic. Unicast traffic received from a split-horizon- 789 group MUST NOT be forwarded to a member of its own split- 790 horizon-group but can be forwarded normally to the other 791 split-horizon-groups and local ACs. If a known unicast packet 792 is identified as a "flooded" packet, the procedures for BUM 793 traffic MUST be followed. 795 + Forwarding behavior on the DF: the DF follows the same 796 behavior as the DF in the single-active case but only for BUM 797 traffic. Unicast traffic received from a split-horizon-group 798 MUST NOT be forwarded to a member of its own split-horizon- 799 group but can be forwarded normally to the other split- 800 horizon-group and local ACs. If a known unicast packet is 801 identified as a "flooded" packet, the procedures for BUM 802 traffic MUST be followed. As per [RFC7432] and for split- 803 horizon purposes, when receiving BUM traffic on the EVPN- 804 Overlay bindings associated to an I-ESI, the DF GW MUST add 805 the I-ESI label when forwarding to the peer GW over EVPN-MPLS. 807 + Contrary to the single-active multi-homing case, both DF and 808 non-DF re-originate and advertise MAC/IP routes received from 809 the WAN/DC peers, adding the corresponding I-ESI so that the 810 remote PE/NVEs can perform regular aliasing as per [RFC7432]. 812 The example in Figure 3 illustrates the forwarding of BUM traffic 813 originated from an NVE on a pair of all-active multi-homing GWs. 815 |<--EVPN-Overlay--->|<--EVPN-MPLS-->| 817 +---------+ +--------------+ 818 +----+ BUM +---+ | 819 |NVE1+----+----> | +-+-----+ | 820 +----+ | | DF |GW1| | | | 821 | | +-+-+ | | ++--+ 822 | | | | +--> |PE1| 823 | +--->X +-+-+ | ++--+ 824 | NDF| | | | 825 +----+ | |GW2<-+ | 826 |NVE2+--+ +-+-+ | 827 +----+ +--------+ | +------------+ 828 v 829 +--+ 830 |CE| 831 +--+ 833 Figure 3 Multi-homing BUM forwarding 835 GW2 is the non-DF for the I-ESI and blocks the BUM forwarding. GW1 is 836 the DF and forwards the traffic to PE1 and GW2. GW2 will only forward 837 the packets to local ACs (CE in the example). 839 4.4.4. Impact on MAC Mobility procedures 841 MAC Mobility procedures described in [RFC7432] are not modified by 842 this document. 844 Note that an intra-DC MAC move still leaves the MAC attached to the 845 same I-ESI, so under the rules of [RFC7432] this is not considered a 846 MAC mobility event. Only when the MAC moves from the WAN domain to 847 the DC domain (or from one DC to another) the MAC will be learned 848 from a different ES and the MAC Mobility procedures will kick in. 850 The sticky bit indication in the MAC Mobility extended community MUST 851 be propagated between domains. 853 4.4.5. Gateway optimizations 855 All the Gateway optimizations described in section 3.5 MAY be applied 856 to the GWs when the Interconnect is based on EVPN-MPLS. 858 In particular, the use of the Unknown MAC route, as described in 859 section 3.5.1, solves some transient packet duplication issues in 860 cases of all-active multi-homing, as explained below. 862 Consider the diagram in Figure 2 for EVPN-MPLS Interconnect and all- 863 active multi-homing, and the following sequence: 865 a) MAC Address M1 is advertised from NVE3 in EVI-1. 867 b) GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN 868 with I-ESI-2 in the ESI field. 870 c) GW1 and GW2 learn M1 and install GW3/GW4 as next-hops following 871 the EVPN aliasing procedures. 873 d) Before NVE1 learns M1, a packet arrives at NVE1 with 874 destination M1. If the Unknown MAC route had not been 875 advertised into the DC, NVE1 would have flooded the packet 876 throughout the DC, in particular to both GW1 and GW2. If the 877 same VNI/VSID is used for both known unicast and BUM traffic, 878 as is typically the case, there is no indication in the packet 879 that it is a BUM packet and both GW1 and GW2 would have 880 forwarded it. However, because the Unknown MAC route had been 881 advertised into the DC, NVE1 will unicast the packet to either 882 GW1 or GW2. 884 e) Since both GW1 and GW2 know M1, the GW receiving the packet 885 will forward it to either GW3 or GW4. 887 4.4.6. Benefits of the EVPN-MPLS Interconnect solution 889 Besides retaining the EVPN attributes between Data Centers and 890 throughout the WAN, the EVPN-MPLS Interconnect solution on the GWs 891 has some benefits compared to pure BGP EVPN RR or Inter-AS model B 892 solutions without a gateway: 894 o The solution supports the connectivity of local attachment 895 circuits on the GWs. 897 o Different data plane encapsulations can be supported in the DC 898 and the WAN. 900 o Optimized multicast solution, with independent inclusive 901 multicast trees in DC and WAN. 903 o MPLS Label aggregation: for the case where MPLS labels are 904 signaled from the NVEs for MAC/IP Advertisement routes, this 905 solution provides label aggregation. A remote PE MAY receive a 906 single label per GW MAC-VRF as opposed to a label per NVE/MAC- 907 VRF connected to the GW MAC-VRF. For instance, in Figure 2, PE 908 would receive only one label for all the routes advertised for a 909 given MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF. 911 o The GW will not propagate MAC mobility for the MACs moving 912 within a DC. Mobility intra-DC is solved by all the NVEs in the 913 DC. The MAC Mobility procedures on the GWs are only required in 914 case of mobility across DCs. 916 o Proxy-ARP/ND function on the DC GWs can be leveraged to reduce 917 ARP/ND flooding in the DC or/and in the WAN. 919 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks 921 PBB-EVPN [RFC7623] is yet another Interconnect option. It requires 922 the use of GWs where I-components and associated B-components are 923 part of EVI instances. 925 4.5.1. Control/Data Plane setup procedures on the GWs 927 EVPN will run independently in both components, the I-component MAC- 928 VRF and B-component MAC-VRF. Compared to [RFC7623], the DC C-MACs are 929 no longer learned in the data plane on the GW but in the control 930 plane through EVPN running on the I-component. Remote C-MACs coming 931 from remote PEs are still learned in the data plane. B-MACs in the B- 932 component will be assigned and advertised following the procedures 933 described in [RFC7623]. 935 An I-ESI will be configured on the GWs for multi-homing, but it will 936 only be used in the EVPN control plane for the I-component EVI. No 937 non-reserved ESIs will be used in the control plane of the B- 938 component EVI as per [RFC7623]. 940 The rest of the control plane procedures will follow [RFC7432] for 941 the I-component EVI and [RFC7623] for the B-component EVI. 943 From the data plane perspective, the I-component and B-component EVPN 944 bindings established to the same far-end will be compared and the I- 945 component EVPN-overlay binding will be kept down following the rules 946 described in section 4.3.1. 948 4.5.2. Multi-homing procedures on the GWs 950 This model supports single-active as well as all-active multi-homing. 952 The forwarding behavior of the DF and non-DF will be changed based on 953 the description outlined in section 4.4.3, only replacing the "WAN 954 split-horizon-group" for the B-component. 956 4.5.3. Impact on MAC Mobility procedures 958 C-MACs learned from the B-component will be advertised in EVPN within 959 the I-component EVI scope. If the C-MAC was previously known in the 960 I-component database, EVPN would advertise the C-MAC with a higher 961 sequence number, as per [RFC7432]. From a Mobility perspective and 962 the related procedures described in [RFC7432], the C-MACs learned 963 from the B-component are considered local. 965 4.5.4. Gateway optimizations 967 All the considerations explained in section 4.4.5 are applicable to 968 the PBB-EVPN Interconnect option. 970 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks 972 If EVPN for Overlay tunnels is supported in the WAN and a GW function 973 is required, an end-to-end EVPN solution can be deployed. This 974 section focuses on the specific case of EVPN for VXLAN (EVPN-VXLAN 975 hereafter) and the impact on the [RFC7432] procedures. 977 This use-case assumes that NVEs need to use the VNIs or VSIDs as a 978 globally unique identifiers within a data center, and a Gateway needs 979 to be employed at the edge of the data center network to translate 980 the VNI or VSID when crossing the network boundaries. This GW 981 function provides VNI and tunnel IP address translation. The use-case 982 in which local downstream assigned VNIs or VSIDs can be used (like 983 MPLS labels) is described by [EVPN-Overlays]. 985 While VNIs are globally significant within each DC, there are two 986 possibilities in the Interconnect network: 988 a) Globally unique VNIs in the Interconnect network: 989 In this case, the GWs and PEs in the Interconnect network will 990 agree on a common VNI for a given EVI. The RT to be used in the 991 Interconnect network can be auto-derived from the agreed 992 Interconnect VNI. The VNI used inside each DC MAY be the same 993 as the Interconnect VNI. 995 b) Downstream assigned VNIs in the Interconnect network. 996 In this case, the GWs and PEs MUST use the proper RTs to 997 import/export the EVPN routes. Note that even if the VNI is 998 downstream assigned in the Interconnect network, and unlike 999 option B, it only identifies the pair and 1000 not the pair. The VNI used inside 1001 each DC MAY be the same as the Interconnect VNI. GWs SHOULD 1002 support multiple VNI spaces per EVI (one per Interconnect 1003 network they are connected to). 1005 In both options, NVEs inside a DC only have to be aware of a single 1006 VNI space, and only GWs will handle the complexity of managing 1007 multiple VNI spaces. In addition to VNI translation above, the GWs 1008 will provide translation of the tunnel source IP for the packets 1009 generated from the NVEs, using their own IP address. GWs will use 1010 that IP address as the BGP next-hop in all the EVPN updates to the 1011 Interconnect network. 1013 The following sections provide more details about these two options. 1015 4.6.1. Globally unique VNIs in the Interconnect network 1017 Considering Figure 2, if a host H1 in NVO-1 needs to communicate with 1018 a host H2 in NVO-2, and assuming that different VNIs are used in each 1019 DC for the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then 1020 the VNIs MUST be translated to a common Interconnect VNI (e.g. VNI- 1021 100) on the GWs. Each GW is provisioned with a VNI translation 1022 mapping so that it can translate the VNI in the control plane when 1023 sending BGP EVPN route updates to the Interconnect network. In other 1024 words, GW1 and GW2 MUST be configured to map VNI-10 to VNI-100 in the 1025 BGP update messages for H1's MAC route. This mapping is also used to 1026 translate the VNI in the data plane in both directions, that is, VNI- 1027 10 to VNI-100 when the packet is received from NVO-1 and the reverse 1028 mapping from VNI-100 to VNI-10 when the packet is received from the 1029 remote NVO-2 network and needs to be forwarded to NVO-1. 1031 The procedures described in section 4.4 will be followed, considering 1032 that the VNIs advertised/received by the GWs will be translated 1033 accordingly. 1035 4.6.2. Downstream assigned VNIs in the Interconnect network 1037 In this case, if a host H1 in NVO-1 needs to communicate with a host 1038 H2 in NVO-2, and assuming that different VNIs are used in each DC for 1039 the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs 1040 MUST be translated as in section 4.6.1. However, in this case, there 1041 is no need to translate to a common Interconnect VNI on the GWs. Each 1042 GW can translate the VNI received in an EVPN update to a locally 1043 assigned VNI advertised to the Interconnect network. Each GW can use 1044 a different Interconnect VNI, hence this VNI does not need to be 1045 agreed on all the GWs and PEs of the Interconnect network. 1047 The procedures described in section 4.4 will be followed, taking the 1048 considerations above for the VNI translation. 1050 5. Security Considerations 1052 This document applies existing Technical Specifications to a number 1053 of Interconnect models. The Security Considerations included in those 1054 documents, such as [RFC7432], [EVPN-Overlays], [RFC7623], [RFC4761] 1055 and [RFC4762] apply to this document whenever those technologies are 1056 used. 1058 [EVPN-Overlays] discusses two main DCI solution groups: "DCI using 1059 GWs" and "DCI using ASBRs". This document specifies the solutions 1060 that correspond to the "DCI using GWs" group. It is important to note 1061 that use of GWs provide a superior level of security on a per tenant 1062 basis, compared to the use of ASBRs. This is due to the fact that GWs 1063 need to perform a MAC lookup on the frames being received from the 1064 WAN, and they apply security procedures, such as filtering of 1065 undesired frames, filtering of frames with a source MAC that matches 1066 a protected MAC in the DC or application of MAC duplication 1067 procedures defined in [RFC7432]. On ASBRs though, traffic is 1068 forwarded based on a label or VNI swap and there is usually no 1069 visibility of the encapsulated frames, which can carry malicious 1070 traffic. 1072 In addition, the GW optimizations specified in this document, provide 1073 additional protection of the DC Tenant Systems. For instance, the MAC 1074 address advertisement control and Unknown MAC route defined in 1075 section 3.5.1 protect the DC NVEs from being overwhelmed with an 1076 excessive number MAC/IP routes being learned on the GWs from the WAN. 1077 The ARP/ND flooding control described in 3.5.2 can reduce/suppress 1078 broadcast storms being injected from the WAN. 1080 Finally, the reader should be aware of the potential security 1081 implications of designing a DCI with the Decoupled Interconnect 1082 solution (section 2) or the Integrated Interconnect solution (section 1083 3). In the Decoupled Interconnect solution the DC is typically easier 1084 to protect from the WAN, since each GW has a single logical link to 1085 one WAN PE, whereas in the Integrated solution, the GW has logical 1086 links to all the WAN PEs that are attached to the tenant. In either 1087 model, proper control plane and data plane policies should be put in 1088 place in the GWs in order to protect the DC from potential attacks 1089 coming from the WAN. 1091 6. IANA Considerations 1093 This document has no IANA actions. 1095 7. References 1096 7.1. Normative References 1098 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private 1099 LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", 1100 RFC 4761, DOI 10.17487/RFC4761, January 2007, . 1103 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 1104 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1105 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1106 . 1108 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1109 "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual 1110 Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 1111 2011, . 1113 [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., 1114 "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge 1115 (PE) Model for Provider Backbone Bridging", RFC 7041, DOI 1116 10.17487/RFC7041, November 2013, . 1119 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1120 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 1121 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 1124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1125 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1126 1997, . 1128 [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation 1129 Attribute", draft-ietf-idr-tunnel-encaps-08, work in progress, 1130 January 11, 2018. 1132 [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with 1133 Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, . 1136 [EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization 1137 Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-11.txt, 1138 work in progress, January, 2018 1140 7.2. Informative References 1142 [EVPN-VPLS-INTEGRATION] Sajassi et al., "(PBB-)EVPN Seamless 1143 Integration with (PBB-)VPLS", draft-ietf-bess-evpn-vpls-integration- 1144 00.txt, work in progress, February, 2015. 1146 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1147 R., Patel, K., and J. Guichard, "Constrained Route Distribution for 1148 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 1149 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 1150 DOI 10.17487/RFC4684, November 2006, . 1153 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1154 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible 1155 Local Area Network (VXLAN): A Framework for Overlaying Virtualized 1156 Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 1157 10.17487/RFC7348, August 2014, . 1160 [RFC7637] Garg, P., et al., "NVGRE: Network Virtualization using 1161 Generic Routing Encapsulation", RFC 7637, September, 2015 1163 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 1164 "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", 1165 RFC 4023, DOI 10.17487/RFC4023, March 2005, . 1168 [Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms 1169 for Ethernet based networks", July 2011. 1171 [802.1AG] IEEE 802.1AG_2007, "IEEE Standard for Local and 1172 Metropolitan Area Networks - Virtual Bridged Local Area Networks 1173 Amendment 5: Connectivity Fault Management", January 2008. 1175 [802.1Q-2014] IEEE 802.1Q-2014, "IEEE Standard for Local and 1176 metropolitan area networks--Bridges and Bridged Networks", December 1177 2014. 1179 [RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire 1180 Preferential Forwarding Status Bit", RFC 6870, DOI 10.17487/RFC6870, 1181 February 2013, . 1183 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1184 Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, 1185 January 2001, . 1187 8. Acknowledgments 1188 The authors would like to thank Neil Hart, Vinod Prabhu and Kiran 1189 Nagaraj for their valuable comments and feedback. We would also like 1190 to thank Martin Vigoureux for his detailed review and comments. 1192 9. Contributors 1194 In addition to the authors listed on the front page, the following 1195 co-authors have also contributed to this document: 1197 Ravi Shekhar 1198 Anil Lohiya 1199 Wen Lin 1200 Juniper Networks 1202 Florin Balus 1203 Patrice Brissette 1204 Cisco 1206 Senad Palislamovic 1207 Nokia 1209 Dennis Cai 1210 Alibaba 1212 10. Authors' Addresses 1214 Jorge Rabadan 1215 Nokia 1216 777 E. Middlefield Road 1217 Mountain View, CA 94043 USA 1218 Email: jorge.rabadan@nokia.com 1220 Senthil Sathappan 1221 Nokia 1222 Email: senthil.sathappan@nokia.com 1224 Wim Henderickx 1225 Nokia 1226 Email: wim.henderickx@nokia.com 1228 Ali Sajassi 1229 Cisco 1230 Email: sajassi@cisco.com 1232 John Drake 1233 Juniper 1234 Email: jdrake@juniper.net