L2VPN Workgroup J. Rabadan Internet Draft W. Henderickx Intended status: Standards Track S. Sathappan S. Palislamovic Alcatel-Lucent F. Balus Nuage Networks Expires: January 16, 2014 July 15, 2013 Data Center Interconnect Solution for E-VPN Overlay networks draft-rabadan-l2vpn-dci-evpn-overlay-00.txt Abstract This document describes how Network Virtualization Overlay networks (NVO3) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution will analyze the interaction between NVO3 networks running E-VPN and other technologies used in the WAN, such as VPLS/PBB-VPLS or E-VPN/PBB-EVPN. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 16, 2014. Rabadan et al. Expires January 16, 2014 [Page 1] Internet-Draft DCI for E-VPN Overlays July 15, 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. VPLS/PBB-VPLS based DCI for E-VPN overlay networks . . . . . . 3 2.1. VPLS/PBB-VPLS DCI Solution Overview . . . . . . . . . . . . 3 2.2. VPLS/PBB-VPLS DCI options . . . . . . . . . . . . . . . . . 4 2.2.1. VPLS DCI with VLAN-based hand-off . . . . . . . . . . . 4 2.2.2. VPLS DCI with Pseudowire-based hand-off . . . . . . . . 5 2.2.3. VPLS DCI with integrated Gateway and WAN Edge functions . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.4. PBB-VPLS DCI . . . . . . . . . . . . . . . . . . . . . 6 2.3. Unknown MAC route on the DC GWs . . . . . . . . . . . . . . 7 2.4. Disabling unknown unicast flooding in a DC with VPLS DCI . 8 2.5. ARP-flooding control . . . . . . . . . . . . . . . . . . . 9 2.6. Multi-homing solution for VPLS DCI . . . . . . . . . . . . 9 2.6.1. Multi-homing solution requirements for VPLS DCI . . . . 9 2.6.2. Multi-homing solution description . . . . . . . . . . . 10 2.6.2.1. Multi-homed Ethernet Segment Auto-Discovery . . . . 11 2.6.2.2. Designated Forwarder (DF) election and forwarding . 11 2.6.2.3. Fast Convergence using the Unknown MAC Route . . . 11 3. E-VPN DCI for E-VPN overlay networks . . . . . . . . . . . . . 13 4. PBB-EVPN DCI for E-VPN overlay networks . . . . . . . . . . . . 13 5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Rabadan et al. Expires January 16, 2014 [Page 2] Internet-Draft DCI for E-VPN Overlays July 15, 2013 1. Introduction [E-VPN-Overlays] discusses the use of E-VPN as the control plane for Network Virtualization Overlay (NVO) networks, where VXLAN, NVGRE or MPLS over GRE can be used as possible data plane encapsulation options. While this model provides a scalable and efficient multi-tenant solution within the Data Center, it might not be easily extended to the WAN in some cases due to the existing deployed technologies. For instance, a Service Provider might have an already deployed VPLS network that must be used to interconnect Data Centers. This document describes a Data Center Interconnect (DCI) solution for E-VPN overlay Data Center networks, assuming that the L2VPN technology deployed in the WAN can be based on: 1. VPLS as defined in [RFC4761][RFC4762][RFC6074] or even PBB-VPLS, as defined in [PBB-VPLS] 2. E-VPN as defined in [E-VPN] 3. PBB-EVPN as defined in [PBB-EVPN] Each of these DCI models is analyzed in the following sections. 2. VPLS/PBB-VPLS based DCI for E-VPN overlay networks VPLS and PBB-VPLS are deployed in many Service Providers as the multi-point L2VPN service technology in the WAN. Those Service Providers will require integrating the new virtualized data center services with the L2VPN technology existing in the WAN, so that there is a minimum impact on the Service Provider operations. By implementing the Data Center Gateway (DC GW) functions described in this section, a Service Provider PE will be able to connect a DC tenant segment to an existing VPLS or PBB-VPLS service, for DC-to-DC layer-2 extension and for user-to-DC layer-2 connectivity. 2.1. VPLS/PBB-VPLS DCI Solution Overview Figure 1 depicts the reference model described in this section. Rabadan et al. Expires January 16, 2014 [Page 3] Internet-Draft DCI for E-VPN Overlays July 15, 2013 +--+ |CE| +--+ | +----+ +----| PE |----+ +---------+ | +----+ | +---------+ +----+ | +---+ +----+ +----+ +---+ | +----+ |NVE1|--| |DC | |WAN | |WAN | |DC | |--|NVE3| +----+ | |GW1|--|Edge| |Edge|--|GW3| | +----+ | +---+ +----+ +----+ +---+ | | DC1 | | WAN | | DC2 | | +---+ +----+ +----+ +---+ | | |DC | |WAN | |WAN | |DC | | +----+ | |GW2|--|Edge| |Edge|--|GW4| | +----+ |NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4| +----+ +---------+ | | +---------+ +----+ +--------------+ |<--E-VPN/Overlay-->|<-----VPLS/PBB-VPLS------>|<--E-VPN/Overlay-->| Figure 1 VPLS DCI model In this model, the WAN Service Provider requires the use of its existing VPLS procedures to extend the layer-2 connectivity for the tenants. There are four potential options in this model: o VPLS DCI with VLAN-based hand-off o VPLS DCI with Pseudowire-based hand-off o VPLS DCI with integrated Gateway and WAN Edge functions o PBB-VPLS DCI Section 2.2 describes each specific option. 2.2. VPLS/PBB-VPLS DCI options 2.2.1. VPLS DCI with VLAN-based hand-off In this option, the hand-off between the DC GWs and the WAN Edge routers is based on 802.1Q VLANs. Each E-VPN Instance (EVI) in the DC GW is connected to a different VPLS Instance (VSI) in the WAN Edge router by using a different C-TAG VLAN ID or a different combination of S-TAG/C-TAG VLAN IDs that match at both sides. In this use-case, the WAN Edge router becomes a VPLS PE with regular VLAN-based Attachment Circuits. Rabadan et al. Expires January 16, 2014 [Page 4] Internet-Draft DCI for E-VPN Overlays July 15, 2013 This option is required in those cases where the WAN and DC networks are operated by different entities and a secure demarcation between both is needed (no control plane protocols are run between DC GW and WAN Edge router, and each network can apply its own security and QoS policies independently based on the incoming/outgoing VLAN ID). The disadvantages of this model are the provisioning overhead and the reduced scalability (limited to the VLAN-ID space). The provisioning in the DC GWs can be automated though by the cloud management system. In this model, the DC GW acts as a regular Network Virtualization Edge (NVE) towards the D. Its control plane, data plane procedures and interactions are described in [E-VPN-Overlays]. From an E-VPN perspective, the connectivity to the WAN Edge routers is treated as VLAN-based service interfaces, therefore there is a 1:1 relation between DCI VLAN ID and EVI. If the data plane encapsulation in the NVO network supports VLAN tags in the encapsulated frames, a VLAN Bundle Service interface is possible in the DCI. As described in [E- VPN-Overlays] this interface type is possible if VXLAN is used and not for NVGRE. NVGRE only supports VLAN-based service interfaces. The WAN Edge router acts as a VPLS PE. Its functions are described in [RFC4761][RFC4762][RFC6074]. The DC GW multi-homing functions for this model are described in section 2.6. 2.2.2. VPLS DCI with Pseudowire-based hand-off If MPLS can be enabled between the DC GW and the WAN Edge router, a more scalable DCI solution can be deployed. In this option the hand- off between both routers is based on FEC128-based pseudowires or, alternatively, FEC129-based pseudowires for a greater level of network automation. Note that this model still provides a clear demarcation boundary between DC and WAN, and security/QoS policies may be applied on a per pseudowire basis. In this model, besides the usual MPLS procedures between DC GW and WAN Edge router, the DC GW MUST support an interworking function in each EVI that requires extension to the WAN: o If a FEC128-based pseudowire is used between the EVI (DC GW) and the VSI (WAN Edge), the provisioning of the VCID for such pseudowire MUST be supported on the EVI and must match the VCID used in the peer VSI at the WAN Edge router. o If BGP Auto-discovery [RFC6074] and FEC129-based pseudowires are used between the DC GW EVI and the WAN Edge VSI, the provisioning of the VPLS-ID MUST be supported on the EVI and must match the Rabadan et al. Expires January 16, 2014 [Page 5] Internet-Draft DCI for E-VPN Overlays July 15, 2013 VPLS-ID used in the WAN Edge VSI. Note that the Route Distinguisher (RD) and Route Target (RT) already provisioned for its use in E-VPN, can be re-used for VPLS. The WAN Edge VSI will have to be configured with two different RT extended communities. For example, if EVI-1 in DC GW-1 (figure 1) uses RT1, the peer WAN Edge VSI will use RT1 to import/export routes from/to the DC GW and RT2 to import/export routes from/to the remote WAN Edge VSIs. The WAN Edge router will import RT1 and RT2 in two different split-horizon groups, so that traffic to/from the DC GW can be switched to/from the WAN. The DC GW multi-homing functions for this model are described in section 2.6. 2.2.3. VPLS DCI with integrated Gateway and WAN Edge functions When the DC and the WAN are operated by the same administrative entity, the Service Provider can decide to integrate the DC GW and WAN Edge PE functions in the same router for obvious CAPEX and OPEX saving reasons. In the example depicted in figure 1 that would mean the WAN Edge routers would be P routers and will not maintain any tenant state. Note that this model does not provide an explicit demarcation between DC and WAN anymore, and ACLs or QoS policies between both networks become a very complex task. In this option, any EVI instance in the DC GW requiring layer-2 extension to the WAN MUST support an interworking function to VPLS. The EVI will become a VSI from the WAN perspective and will setup a full mesh of pseudowires to all the remote PEs and DC GWs (except to the DC GW of its own DC) and according to the procedures described in [RFC4761][RFC4762][RFC6074]. The DC GW multi-homing functions for this model are described in section 2.6. 2.2.4. PBB-VPLS DCI This case is a variation of the one described in section 2.2.3. When the DC GW and WAN Edge PE functions can be integrated, PBB-VPLS can also be used as the DCI technology of choice. In this case, the DC GW EVIs will become I-components multiplexed into a B-component that will be connected to the WAN. Since many EVIs can be multiplexed into the same B-component, this option provides significant savings in terms of pseudowires to be maintained in the WAN. The DC GW multi-homing functions for this model are described in Rabadan et al. Expires January 16, 2014 [Page 6] Internet-Draft DCI for E-VPN Overlays July 15, 2013 section 2.6. 2.3. Unknown MAC route on the DC GWs The use of E-VPN, as the control plane of Network Virtualization Networks in the DC, brings a significant number of benefits as described in [E-VPN-Overlays]. There are however two potential issues that SHOULD be addressed when a VPLS DCI is used for a NVO3 DC: o All the MAC addresses learnt from the WAN side of the VSI must be advertised by BGP E-VPN updates. Even if optimized BGP techniques like RT-constraint are used, the amount of MAC addresses to advertise or withdraw (in case of failure) from the DC GWs can be difficult to control and overwhelming for the DC network, especially when the NVEs reside in the hypervisors. o As described in [E-VPN-Overlays], when the NVEs reside in the hypervisors, the E-VPN BGP routes and attributes associated with multi-homing are no longer required. The simple reason is the fact that, in a hypervisor environment, there is no need for multi- homing between VMs and NVEs since both, VMs and NVEs, are part of the same hardware. This reduces the required routes to be generated and processed to only two: the MAC Advertisement Route and the Inclusive Multicast Ethernet Tag Route. While this simplification greatly helps the implementation of E-VPN in the DC, it brings back some of the issues related to Multi-Homing that were solved by the removed procedures and that are still applicable for the specific use-case of the DC, since Multi-Homing is required at the DC GWs. The solution suggested in this document for the VPLS DCI use case is based on the use of an "Unknown MAC route" that is advertised by the two DC GWs. By using this Unknown MAC Route advertisement the user may optionally turn off the advertisement of WAN MAC addresses in the DC GW, hence reducing the control plane overhead and the size of the FDB tables in the NVEs. In addition to this, the Unknown MAC Route may provide a fast convergence solution valid for TORs and hypervisor NVEs, even if they do not support the Ethernet A-D route procedures. If this procedure is used, when an EVI is created in the DC GWs and the Designated Forwarder (DF) is elected, the DF will send a BGP update containing an "Unknown MAC" address. The Unknown MAC address will be conveyed in an "Unknown MAC" Advertisement Route: Rabadan et al. Expires January 16, 2014 [Page 7] Internet-Draft DCI for E-VPN Overlays July 15, 2013 +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ |Ethernet Segment Identifier (10 octets)| +---------------------------------------+ | VNI/VSID (4 octets) | +---------------------------------------+ | MAC Address Length (1 octet) | +---------------------------------------+ | Unknown MAC Address (6 octets) | +---------------------------------------+ | IP Address Length (1 octet) | +---------------------------------------+ | IP Address (4 or 16 octets) | +---------------------------------------+ | MPLS Label (3 octets) | +---------------------------------------+ Where the ESI identifies the WAN Ethernet Segment, the VNI/VSID is encoded in the Ethernet Tag Field as explained in [E-VPN-Overlays], the MAC address length is set to 48 and the Unknown MAC address value will be set to 00:00:00:00:00:00. The IP address length will be zero, the IP address value omitted and the MPLS label will be set to zero. If the DC GW is DF for more than one ES within the same EVI, it will advertise an Unknown MAC route per ES, each one tagged with its corresponding ESI. As outlined before, there are two main functions that can be carried out by using this Unknown MAC Route: fast convergence for hypervisor NVEs (described in section 2.6.2.3) and disabling unknown unicast flooding in the DC (described in section 2.4). 2.4. Disabling unknown unicast flooding in a DC with VPLS DCI In DCs where MAC addresses are learnt through the control plane, the use of flooding for unknown destination MAC addresses can be disabled. However, when we use a VPLS DCI, the DC GW will normally learn the WAN MAC addresses in the data plane, therefore, even if the rest of the NVEs in the DC do control plane learning, disabling the unknown unicast flooding is no longer an administrative choice. The use of the Unknown MAC route in DC GWs allows two configuration options: a) Disable the unknown flooding in all the NVEs in the DC (except on the DC GWs) if Data Center MACs are learnt through the Rabadan et al. Expires January 16, 2014 [Page 8] Internet-Draft DCI for E-VPN Overlays July 15, 2013 control/management plane. b) Disable the advertisement of the WAN MAC addresses from the DC GWs, so that the control plane overhead and the forwarding table sizes in the NVEs are both reduced. Both options SHOULD be an administrative configuration choice supported on the DC GWs. If option b) is enabled, the DC GW will advertise only the Unknown MAC Route for the EVIs on which it is the Designated Forwarder (DF). The NVEs will learn their local MACs through the control/management plane and advertise them in BGP. If any NVE receives a packet to an unknown destination MAC address, and option a) is enabled, the NVE will send the packet to the next-hop associated to the Unknown MAC Route (for each ESI if there is more than one), since the packet is assumed to be destined to the WAN. This assumption is valid since all the DC MACs are learnt in the control/management plane. The DC GW will receive the packet and will do an FDB lookup to find out what VPLS pseudowire or attachment circuit it has to send the packet to. If the destination MAC is unknown for the DC GW, it will flood the packet to the WAN, following standard VPLS procedures. 2.5. ARP-flooding control The use of the Unknown MAC route may eliminate the unknown flooding within the DC and provide an extra security protection mechanism against an excessive explosion of MAC addresses in the WAN that would trigger the advertisement of a significant number of MAC addresses in the DC. Another security mechanism, naturally provided by E-VPN in the DC GWs, is the Proxy ARP function. The DC GWs SHOULD build a Proxy ARP table with the IP and MAC address information coded in the MAC advertisement routes coming from the DC NVEs. When the active DC GW receives an ARP request coming from the WAN, the DC GW should check the Proxy ARP table for the EVI and reply to the ARP request as long as the information is available. This mechanism is specially recommended when VPLS DCI is used on the DC GWs since it protects the DC network from external ARP-flooding. 2.6. Multi-homing solution for VPLS DCI 2.6.1. Multi-homing solution requirements for VPLS DCI As it can be easily inferred from the scenario in figure 1, a multi- homing solution MUST be provided in the DC. The Multi-homing Rabadan et al. Expires January 16, 2014 [Page 9] Internet-Draft DCI for E-VPN Overlays July 15, 2013 requirements on the DC GWs are listed here: o A Multi-homing solution MUST be supported by the DC GWs independently of the capabilities of the WAN Edge routers (since they can be managed by a different Service Provider). o The Multi-homing solution MUST support service-based (EVI) load- balancing. No flow-based load-balancing is required when VPLS DCI is used. o The Multi-homing solution MUST support single-active redundancy mode per E-VPN on the DC GWs, as per [E-VPN]. All-active multi- homing is neither possible if VPLS is used in the DCI nor required since the number of EVIs on the DC GWs is supposed to be large enough so that the traffic between DC and WAN can be fairly distributed. 2.6.2. Multi-homing solution description When the DCI model is the one described in the section 2.1, a single- active Multi-homing solution is required. Note that, since all-active Multi-homing is not required, only a subset of E-VPN routes and extended communities will be needed to be generated from the DC GWs: o Ethernet Segment route and ES-Import route target: required for the Ethernet Segment Auto-Discovery and Designated Forwarder (DF) election between the DC GWs. The DC GWs MUST generate an ES route per WAN network to which they are directly connected, and MUST be able to process the inbound ES routes as per [E-VPN]. o Ethernet Auto-Discovery (A-D) route per ESI: required for fast convergence and back-up path. The DC GWs MUST generate an A-D route per ESI with an ESI Label extended community. The active-standby flag will be always set and the label field will be zero (no Split- Horizon procedures are required on the DC GWs as per [E-VPN]). The DC GWs will be able to process the received A-D routes per ESI. o Ethernet Auto-Discovery (A-D) route per EVI: the DC GWs will NOT generate A-D routes per EVI, since no aliasing functions are required for single-active Multi-homing. The DC GWs however MUST support processing A-D routes per EVI, since there might be some TORs in the DC supporting all-active Multi-homing. o MAC Advertisement route and MAC Mobility extended community: they MUST be supported at generation and reception as per [E-VPN- Overlays]. o Inclusive Multicast Ethernet Tag route and PMSI Tunnel attribute: Rabadan et al. Expires January 16, 2014 [Page 10] Internet-Draft DCI for E-VPN Overlays July 15, 2013 they MUST be supported at generation and reception as per [E-VPN- Overlays]. The above routes and communities will be used for the following Multi-homing functions: 2.6.2.1. Multi-homed Ethernet Segment Auto-Discovery The DC GWs will advertise an Ethernet Segment route per WAN Ethernet Segment (ES), with the corresponding ES-Import extended community. There will be a single ESI per WAN network, i.e. DC GW1 and DC GW2 will only advertise one ESI in the example of figure 1, and only the DC GWs of the DC will import the ES route for the WAN ESI, as per [E- VPN]. 2.6.2.2. Designated Forwarder (DF) election and forwarding The DF election will be carried out as described in [E-VPN]. Service carving is recommended so that there can be per EVI load-balancing to/from the WAN. Assuming DC GW1 is elected as DF for a given EVI1, DC GW1 will be the only DC GW sending/receiving traffic to/from the WAN for EVI1. DC GW2 will block the transmission and reception of any traffic (including unicast and multi-destination traffic) to/from the WAN for EVI1. The use of OAM is recommended from the non-DF to the VPLS network, so that the VPLS PEs do not send any traffic to the non-DF DC GW for the EVI in which the DC GW is non-DF: o If the VPLS DCI solution is based on a VLAN hand-off, 802.1ag/Y.1731 Ethernet-CFM can be used by the non-DF DC GW so that the peer WAN Edge router do not send any traffic to the DC GW for that particular EVI. o If the VPLS DCI solution is based on a pseudowire hand-off, the LDP PW Status bits TLV can be used by the non-DF to signal "Standby status" to the WAN Edge router for that particular EVI. o If the VPLS DCI is based on an integrated DC GW and WAN Edge router solution where the EVI is part of the VPLS full mesh of pseudowires, the non-DF DC GW can also make use of the LDP PW Status bits TLV to let the remote PEs know that it is not forwarding traffic for that EVI/VSI. 2.6.2.3. Fast Convergence using the Unknown MAC Route [E-VPN] proposes a Fast Convergence mechanism, so that when there is an ES failure on the DF router, the failover time can be uniform and Rabadan et al. Expires January 16, 2014 [Page 11] Internet-Draft DCI for E-VPN Overlays July 15, 2013 independent of the number of MACs and EVI services in the DC GWs. This is done by having the DC GWs advertising an A-D route per WAN Ethernet Segment. Upon a failure in connectivity to the WAN, the DF withdraws the Ethernet A-D route for the WAN Ethernet Segment so that the NVEs in the DC receiving the BGP withdraw can update their FDB for all the MAC addresses associated to the WAN ES. This mechanism is valid as long as the NVEs in the DC support the Ethernet A-D route per ESI. However, as described in [E-VPN- Overlays], in the Data Center there will be a mix of NVEs supporting Ethernet A-D routes (TORs with dual-homed servers) and NVEs NOT supporting Ethernet A-D routes (hypervisors), hence a complementary fast convergence mechanism is required for those. While the existing E-VPN Mass Withdraw procedure will be used for NVEs supporting the processing of Ethernet A-D routes, this document describes a complementary procedure for NVEs not supporting the processing of Ethernet A-D routes. The new procedure does not require the addition of any new route or extended community. It is just based on the interpretation of the Unknown MAC Route described in section 2.3 which will be sent by the DC GWs in regular MAC advertisement routes. The user MAY decide whether the Unknown MAC Route procedure is used only by the hypervisors or by the hypervisors and the TORs too. Only one of the DC GWs will advertise the Unknown MAC Route per EVI and per WAN ESI. The DF will also advertise all the MAC addresses being learnt from the WAN Ethernet Segment (assuming option b in section 2.4 is not turned on). The hypervisor NVEs will import the Unknown MAC route as well as the rest of the WAN MAC addresses associated to the active DC GW. The Unknown MAC route is used by the active DC GW as a way of signaling that it owns the reachability to the WAN Ethernet Segment (ES) for a given EVI. The Unknown MAC address (00:...:00/48) conveyed in the Unknown MAC route will be added to the corresponding EVI forwarding table at the remote NVE. When the WAN Ethernet Segment active path fails (due to a port or link failure), the DC GW will withdraw the Unknown MAC route on all the EVIs for which it is the DF. This triggers all the hypervisor NVEs that receive the withdraw advertisement to immediately invalidate all the MAC addresses associated to the Ethernet Segment, as opposed to having to wait for each individual MAC to be withdrawn. This function is compatible with the E-VPN Fast Convergence procedure carried out by the use of the Ethernet A-D route. The Ethernet A-D route can still be used for TOR NVEs supporting all the E-VPN routes. Rabadan et al. Expires January 16, 2014 [Page 12] Internet-Draft DCI for E-VPN Overlays July 15, 2013 Note that while the E-VPN mass withdraw provides a fast convergence mechanism independent of the number of services and MACs, the Unknown MAC withdraw provides a fast convergence mechanism per service, independent of the number of MACs in each service, i.e. convergence is not expected to be uniform for all the services, but uniform for all the hosts within a service. The use of the Unknown MAC route can significantly speed up the convergence in hypervisor NVEs, especially in services with a fair amount of MACs. 3. E-VPN DCI for E-VPN overlay networks Another potential DCI technology that can be used in the WAN is E- VPN. Assuming E-VPN for MPLS tunnels is used in the WAN, the use of a DC GW is required if the overlay tunneling technology deployed within the DC is not MPLS over GRE, i.e. if VXLAN or NVGRE are used. Figure 2 illustrates this E-VPN DCI model. +--+ |CE| +--+ | +----+ +----| PE |----+ +---------+ | +----+ | +---------+ +----+ | +---+ +---+ | +----+ |NVE1|--| |DC | |DC | |--|NVE3| +----+ | |GW | |GW | | +----+ | +---+ +---+ | | DC1 | WAN | DC2 | | +---+ +---+ | | |DC | |DC | | +----+ | |GW | |GW | | +----+ |NVE2|--| +---+ +---+ |--|NVE4| +----+ +---------+ | | +---------+ +----+ +--------------+ |<--E-VPN/Overlay-->|<-E-VPN/MPLS->|<--E-VPN/Overlay-->| Figure 2 E-VPN DCI model More information will be added in future versions of this document. 4. PBB-EVPN DCI for E-VPN overlay networks [PBB-EVPN] is yet another DCI option. It requires the use of DC GWs where the multiplexing of I-components into the B-component is carried out. E-VPN will run in both components. Rabadan et al. Expires January 16, 2014 [Page 13] Internet-Draft DCI for E-VPN Overlays July 15, 2013 More information will be added in future versions of this document. 5. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. DF: Designated Forwarder DC GW: Data Center Gateway DCI: Data Center Interconnect ES: Ethernet Segment ESI: Ethernet Segment Identifier EVI: E-VPN Instance NVE: Network Virtualization Edge TOR: Top-Of-Rack switch VNI/VSID: refers to VXLAN/NVGRE virtual identifiers 6. Security Considerations 7. IANA Considerations 8. References 8.1. Normative References [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Rabadan et al. Expires January 16, 2014 [Page 14] Internet-Draft DCI for E-VPN Overlays July 15, 2013 Signaling", RFC 4762, January 2007. [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. 8.2. Informative References [E-VPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- l2vpn-evpn-03.txt, work in progress, February, 2013 [E-VPN-OVERLAYS] Sajassi-Drake et al., "A Network Virtualization Overlay Solution using E-VPN", draft-sd-l2vpn-evpn-overlay-01.txt, work in progress, February, 2013 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 10. Authors' Addresses Jorge Rabadan Alcatel-Lucent 777 E. Middlefield Road Mountain View, CA 94043 USA Email: jorge.rabadan@alcatel-lucent.com Wim Henderickx Alcatel-Lucent Email: wim.henderickx@alcatel-lucent.com Florin Balus Nuage Networks Email: florin@nuagenetworks.net Senthil Sathappan Alcatel-Lucent Email: senthil.sathappan@alcatel-lucent.com Senad Palislamovic Alcatel-Lucent Rabadan et al. Expires January 16, 2014 [Page 15] Internet-Draft DCI for E-VPN Overlays July 15, 2013 Email: senad.palislamovic@alcatel-lucent.com Rabadan et al. Expires January 16, 2014 [Page 16]