BESS Working Group A. Sajassi Internet Draft S. Thoria Category: Standard Track N. Fazlollahi Cisco A. Gupta Avi Networks Expires: January 2, 2017 July 2, 2017 Seamless Multicast Interoperability between EVPN and MVPN PEs draft-sajassi-bess-evpn-mvpn-seamless-interop-00.txt Abstract Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC) networks and as the next generation VPN services in service provider (SP) networks. As service providers transform their networks in their COs toward next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including multicast VPN (MVPN) service between their existing network and their new SPDC network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. This document describes a unified solution based on RFC 6513 for seamless interoperability of multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with EVPN-IRB PEs per [EVPN-IRB]. Status of this Memo This Internet-Draft is submitted to IETF 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." Patel, et al. Expires January 2, 2017 [Page 1] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Optimum Forwarding . . . . . . . . . . . . . . . . . . . . 6 4.2. Optimum Replication . . . . . . . . . . . . . . . . . . . . 6 4.3. All-Active and Single-Active Multi-Homing . . . . . . . . . 6 4.4. Inter-AS Tree Stitching . . . . . . . . . . . . . . . . . . 6 4.5. EVPN Service Interfaces . . . . . . . . . . . . . . . . . . 7 4.6. Distributed Anycast Gateway . . . . . . . . . . . . . . . . 7 4.7. Selective & Aggregate Selective Tunnels . . . . . . . . . . 7 4.8. Tenants' (S,G) or (*,G) states . . . . . . . . . . . . . . 7 5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Operational Model for Homogenous EVPN IRB NVEs . . . . . . 8 5.1.1 Control Plane Operation . . . . . . . . . . . . . . . . 10 5.1.2 Data Plane Operation . . . . . . . . . . . . . . . . . 12 5.1.2.1 Sender and Receiver in same MAC-VRF . . . . . . . . 12 5.1.2.2 Sender and Receiver in different MAC-VRF . . . . . . 13 5.2. Operational Model for Heterogeneous EVPN IRB PEs . . . . . 13 5.3. All-Active Multi-Homing . . . . . . . . . . . . . . . . . 13 5.3.1. Source and receivers in same ES but on different subnets . . . . . . . . . . . . . . . . . . . . . . . 14 5.3.2. Source and some receivers in same ES and on same Patel, et al. Expires January 2, 2017 [Page 2] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 subnet . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Mobility for Tenant's sources and receivers . . . . . . . 15 5.5. Single-Active Multi-Homing . . . . . . . . . . . . . . . . 15 6. DCs with only EVPN NVEs . . . . . . . . . . . . . . . . . . . 15 6.1 Setup of overlay multicast delivery . . . . . . . . . . . . 16 6.3 Data plane considerations . . . . . . . . . . . . . . . . . 17 7 Handling of different encapsulations . . . . . . . . . . . . . . 17 7.1 MPLS Encapsulation . . . . . . . . . . . . . . . . . . . . 18 7.2 VxLAN Encapsulation . . . . . . . . . . . . . . . . . . . . 18 7.3 Other Encapsulation . . . . . . . . . . . . . . . . . . . . 18 8. DCI with MPLS in WAN and VxLAN in DCs . . . . . . . . . . . . 18 8.1 Control plane inter-connect . . . . . . . . . . . . . . . . 18 8.2 Data plane inter-connect . . . . . . . . . . . . . . . . . . 20 8.3 Multi-homing among DCI gateways . . . . . . . . . . . . . . 20 9. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 20 10. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1 DCs with only IGMP/MLD hosts w/o tenant router . . . . . . 20 10.2 DCs with mixed of IGMP/MLD hosts & multicast routers running PIM-SSM . . . . . . . . . . . . . . . . . . . . . 21 10.3 DCs with mixed of IGMP/MLD hosts & multicast routers running PIM-ASM . . . . . . . . . . . . . . . . . . . . . 21 10.4 DCs with mixed of IGMP/MLD hosts & multicast routers running PIM-Bidir . . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 15.2. Informative References . . . . . . . . . . . . . . . . . 23 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 Patel, et al. Expires January 2, 2017 [Page 3] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 1. Introduction Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC) networks and as the next generation VPN services in service provider (SP) networks. As service providers transform their networks in their COs toward next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including multicast VPN (MVPN) service between their existing network and their new SPDC network seamlessly without the use of gateway devices. There are several reasons for having such seamless interoperability between their new DCs and their existing networks: - Lower Cost: gateway devices need to have very high scalability to handle VPN services for their DCs and as such need to handle large number of VPN instances (in tens or hundreds of thousands) and very large number of routes (e.g., in millions). For the same speed and feed, these high scale gateway boxes are relatively much more expensive than their TOR devices that support much lower number of routes and VPN instances. - Optimum Forwarding: in a given CO, both EVPN PEs and MVPN PEs can be connected to the same network (e.g., same IGP domain). In such scenarios, the service providers want to have optimum forwarding among these PE devices without the use of gateway devices. Because if gateway devices are used, then the multicast traffic between an EVPN and MVPN PEs can no longer be optimum and is some case, it may even get tromboned. Furthermore, when an SPDC network spans across multiple LATA (multiple geographic areas) and gateways are used between EVPN and MVPN PEs, then with respect to multicast traffic, only one GW can be designated forwarder (DF) between EVPN and MVPN PEs. Such scenarios not only results in non-optimum forwarding but also it can result in tromboing of multicast traffic between the two LATAs when both source and destination PEs are in the same LATA and the DF gateway is elected to be in a different LATA. - Less Provisioning: If gateways are used, then the operator need to configure per-tenant info. In other words, for each tenant that is configured, one (or maybe two) additional touch points are needed. This document describes a unified solution based on [RFC6513] and [RFC6514] for seamless interoperability of multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution for EVPN-only applications in Patel, et al. Expires January 2, 2017 [Page 4] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 data centers (e.g., routed multicast VPN only among EVPN PEs). 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without any normative meaning. 3. Terminology ARP: Address Resolution Protocol BEB: Backbone Edge Bridge B-MAC: Backbone MAC Address CE: Customer Edge C-MAC: Customer/Client MAC Address ES: Ethernet Segment ESI: Ethernet Segment Identifier IRB: Integrated Routing and Bridging LSP: Label Switched Path MP2MP: Multipoint to Multipoint MP2P: Multipoint to Point ND: Neighbor Discovery NA: Neighbor Advertisement P2MP: Point to Multipoint P2P: Point to Point PE: Provider Edge EVPN: Ethernet VPN EVI: EVPN Instance RT: Route Target Single-Active Redundancy Mode: When only a single PE, among a group of PEs attached to an Ethernet segment, is allowed to forward traffic to/from that Ethernet Segment, then the Ethernet segment is defined to be operating in Single-Active redundancy mode. All-Active Redundancy Mode: When all PEs attached to an Ethernet segment are allowed to forward traffic to/from that Ethernet Segment, then the Ethernet segment is defined to be operating in All-Active redundancy mode. 4. Requirements This section describes the requirements specific in providing Patel, et al. Expires January 2, 2017 [Page 5] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 seamless multicast VPN service between MVPN and EVPN capable networks. 4.1. Optimum Forwarding The solution SHALL support optimum multicast forwarding between EVPN and MVPN PEs within a network. The network can be confined to a CO or it can span across multiple LATAs. The solution SHALL support optimum multicast forwarding with both ingress replication tunnels and P2MP tunnels. 4.2. Optimum Replication For EVPN PEs with IRB capability, the solution SHALL use only a single multicast tunnel among EVPN and MVPN PEs for IP multicast traffic. Multicast tunnels can be either ingress replication tunnels or P2MP tunnels. The solution MUST support optimum replication for both Intra-subnet and Inter-subnet IP multicast traffic: - Non-IP traffic SHALL be forwarded per EVPN baseline [RFC7432] or [OVERLAY] - If a Multicast VPN spans across both Intra and Inter subnets, then for Ingress replication regardless of whether the traffic is Intra or Inter subnet, only a single copy of multicast traffic SHALL be sent from the source PE to the destination PE. - If a Multicast VPN spans across both Intra and Inter subnets, then for P2MP tunnels regardless of whether the traffic is Intra or Inter subnet, only a single copy of multicast data SHALL be transmitted by the source PE. Source PE can be either EVPN or MVPN PE and receiving PEs can be a mix of EVPN and MVPN PEs - i.e., a multicast VPN can be spread across both EVPN and MVPN PEs. 4.3. All-Active and Single-Active Multi-Homing The solution MUST support multi-homing of source devices and receivers that are sitting in the same subnet (e.g., VLAN) and are multi-homed to EVPN PEs. The solution SHALL allow for both Single- Active and All-Active multi-homing. The solution MUST prevent loop during steady and transient states just like EVPN baseline solution [RFC7432] and [OVERLAY] for all multi-homing types. 4.4. Inter-AS Tree Stitching The solution SHALL support multicast tree stitching when the tree spans across multiple Autonomous Systems. Patel, et al. Expires January 2, 2017 [Page 6] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 4.5. EVPN Service Interfaces The solution MUST support all EVPN service interfaces listed in section 6 of [RFC7432]: - VLAN-based service interface - VLAN-bundle service interface - VLAN-aware bundle service interface 4.6. Distributed Anycast Gateway The solution SHALL support distributed anycast gateways for tenant workloads on NVE devices operating in EVPN-IRB mode. 4.7. Selective & Aggregate Selective Tunnels The solution SHALL support selective and aggregate selective P- tunnels as well as inclusive and aggregate inclusive P-tunnels. When selective tunnels are used, then multicast traffic SHOULD only be forwarded to the remote PE which have receivers - i.e., if there are no receivers at a remote PE, the multicast traffic SHOULD NOT be forwarded to that PE and if there are no receivers on any remote PEs, then the multicast traffic SHOULD NOT be forwarded to the core. 4.8. Tenants' (S,G) or (*,G) states The solution SHUOLD store (C-S,C-G) and (C-*,C-G) states only on PE devices that have interest in such states hence reducing memory and processing requirements - i.e., PE devices that have sources and/or receivers interested in such multicast groups. 5. Solution [EVPN-IRB] describes the operation for EVPN PEs in IRB mode for unicast traffic. The same EVPN PE model, where an IP-VRF is attached to one or more MAC-VRF via virtual IRB interfaces, is also applicable here. However, there are some noticeable differences between the IRB mode operation for unicast traffic described in [EVPN-IRB] versus for multicast traffic described here. For unicast traffic, the intra- subnet traffic, is bridged within the MAC-VRF associated with that subnet (i.e., a lookup based on MAC-DA is performed); whereas, the inter-subnet traffic is routed in the corresponding IP-VRF (ie, a lookup based on IP-DA is performed). A given tenant can have one or more IP-VRFs; however, without loss of generality, this document assumes one IP-VRF per tenant. For multicast traffic, the intra- subnet traffic is bridged for non-IP traffic and it is Layer-2 Patel, et al. Expires January 2, 2017 [Page 7] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 switched for IP traffic. The differentiation between bridging and L2- switching for multicast traffic is that the former uses MAC-DA lookup for forwarding the traffic; whereas, the latter uses IP-DA lookup for forwarding the multicast traffic where the forwarding states are built using IGMP/MLD snooping. The inter-subnet multicast traffic is always routed in the corresponding IP-VRF. This section describes a multicast VPN solution based on [MVPN] for EVPN PEs operating in IRB mode that want to perform seamless interoperability with their counterparts MVPN PEs. 5.1. Operational Model for Homogenous EVPN IRB NVEs In this section, we consider the scenario where all EVPN PEs have IRB capability and operating in IRB mode for both unicast and multicast traffic (e.g., all EVPN PEs are homogenous in terms of their capabilities and operational modes). In this scenario, the EVPN PEs terminate IGMP/MLD messages from tenant host devices or PIM messages from tenant routers on their IRB interfaces, thus avoid sending these messages over MPLS/IP core. A tenant virtual/physical router (e.g., CE) attached to an EVPN PE becomes a multicast routing adjacency of that PE and the multicast routing protocol on the PE-CE link link is presumed to be PIM-SM with both the ASM and the SSM service models per [RFC6513]. Furthermore, the PE uses MVPN BGP protocol and procedures per [RFC6513] and [RFC6514]. With respect to tenant PIM protocol, PIM-SM with Any Source Multicast (ASM) mode, PIM-SM with Source Specific Multicast (SSM) mode, and PIM Bidirectional (BIDIR) mode are all supported per [RFC6513]. Support of PIM-DM (Dense Mode) is excluded in this document per [RFC6513]. The EVPN PEs use MVPN BGP routes [RFC 6514] to convey tenant (S,G) or (*,G) states to other MVPN or EVPN PEs and to set up overlay trees (inclusive or selective) for a given MVPN. The leaves and roots of these overlay trees are composed of Provider Multicast Service Interface (PMSI) and it can be Inclusive-PMSI (I-PMSI) or Selective- PMSI (S-PMSI) per [RFC6513]. A given PMSI is associated with a single IP-VRF of an EVPN PE and/or a MVPN PE for that MVPN - e.g., a MVPN PMSI is never associated with a MAC-VRF of an EVPN PE. Overlay-trees are instantiated by underlay provider tunnels (P-tunnels) - e.g., P2MP, MP2MP, or unicast tunnels per [RFC 6513]. When there are many- to-one mapping of PMSIs to a P-tunnel (e.g. mapping many S-PMSIs or many I-PMSI to a single P-tunnel), the tunnel is referred to as aggregate tunnel. Figure-1 below depicts a scenario where a tenant's MVPN spans across both EVPN and MVPN PEs; where all EVPN PEs have IRB capability. An EVPN PE (with IRB capability) can be modeled as a MVPN PE where the virtual IRB interface of an EVPN PE (virtual interface between MAC- Patel, et al. Expires January 2, 2017 [Page 8] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 VRF and IP-VRF) can be considered as an attachment circuit (AC) for the MVPN PE. In other words, an EVPN PE can be modeled as a PE that consists of a MVPN PE whose ACs are replaced with IRB interfaces connecting each IP-VRF of the MVPN PE to a set of MAC-VRFs. Similar to a MVPN PE where an attachment circuit serves as a routed multicast interface for an IP-VRF associated with a MVPN instance, an IRB interface serves as a routed multicast interface for the IP-VRF associated with the MVPN instance. Since EVPN PEs run MVPN protocols (e.g., [RFC6513] and [RFC6514]), for all practical purposes, they look just like MVPN PEs to other PE devices. Such modeling of EVPN PEs, transforms the multicast VPN operation of EVPN PEs to that of [MVPN] and thus simplifies the interoperability between EVPN and MVPN PEs to that of running a single unified solution based on [MVPN]. EVPN PE1 +------------+ Src1 +----|(MAC-VRF1) | MVPN PE1 Rcvr1 +----| \ | +---------+ +--------+ | (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr5 | / | | | +--------+ Rcvr2 +---|(MAC-VRF2) | | | +------------+ | | | MPLS/ | EVPN PE2 | IP | +------------+ | | Rcvr3 +---|(MAC-VRF1) | | | MVPN PE2 | \ | | | +--------+ | (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr6 | / | +---------+ +--------+ Rcvr4 +---|(MAC-VRF3) | +------------+ Figure-1: Homogenous EVPN NVEs Although modeling an EVPN PE as a MVPN PE, conceptually simplifies the operation to that of a solution based on [MVPN], the following operational aspects of EVPN are impacted and needs to be factored in the solution: 1) All-Active multi-homing of IP multicast sources and receivers 2) Mobility for Tenant's sources and receivers 3) Unicast route advertisements for IP multicast source 4) non-IP multicast traffic handling Patel, et al. Expires January 2, 2017 [Page 9] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 The first bullet, All-Active multi-homing of IP multicast source and receivers, is described in section 5.3. The second bullet is described in section 5.4. Third and fourth bullets are described next. When an IP multicast source is attached to an EVPN PE, the unicast route for that IP multicast source needs to be advertised. This unicast route is advertised with VRF Route Import extended community which in turn is used as the Route Target for Join (S,G) messages sent toward the source PE by the remote MVPN PEs. The EVPN PE advertises this unicast route using EVPN route type 5 or IPVPN unicast route or both along with VRF Route Import extended community. When unicast routes are advertised by MVPN PEs, they are advertised using IPVPN unicast route along with VRF Route Import extended community per [RFC6514]. Link local multicast traffic (e.g. addressed to 224.0.0.x in case of IPv4) as well as IP protocols such as OSPF, and non-IP multicast/broadcast traffic are sent per EVPN [RF7432] BUM procedures and does not get routed via IP-VRF for multicast addresses. So, such BUM traffic will be limited to a given EVI/VLAN (e.g., a give subnet); whereas, IP multicast traffic, will be locally switched for local interfaces attached on the same subnet and will be routed for local interfaces attached on a different subnet or for forwarding traffic to other EVPN PEs (refer to section 5.1.1 for data plane operation). 5.1.1 Control Plane Operation Just like a MVPN PE, an EVPN PE runs a separate tenant multicast routing instance (VPN-specific) per MVPN instance and the following tenant multicast routing instances are supported: - PIM Sparse Mode (PIM-SM) with the ASM service model - PIM Sparse Mode with the SSM service model - PIM Bidirectional Mode (BIDIR-PIM), which uses bidirectional tenant-trees to support the ASM service model A given tenant's PIM join messages, (C-*, C-G) or (C-S, C-G), are processed by the corresponding tenant multicast routing protocol and they are advertised over MPLS/IP network using Shared Tree Join route (route type 6) and Source Tree Join route (route type 7) respectively of MCAST-VPN NLRI per [RFC6514]. The following NLRIs from [RFC6514] SHOULD be used for forming Underlay/Core tunnels inside a data center. Patel, et al. Expires January 2, 2017 [Page 10] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 Intra-AS I-PMSI A-D route is used to form default tunnel (also called inclusive tunnel) for a tenant VRF. The tunnel attributes are indicated using PMSI attribute with this route. S-PMSI A-D route is used to form Customer flow specific underlay tunnels. This enables selective delivery of data to PEs having active receivers and optimizes fabric bandwidth utilization. The tunnel attributes are indicated using PMSI attribute with this route. Source Active A-D route is used by source connected PE in order to announce active multicast source. This enables PEs having active receivers for the flow to join the tunnels and switch to Shortest Path tree. Each EVPN PE supporting a specific MVPN discovers the set of other PEs in its AS that are attached to sites of that MVPN using Intra-AS I-PMSI A-D route (route type 1) per [RFC6514]. It can also discover the set of other ASes that have PEs attached to sites of that MVPN using Inter-AS I-PMSI A-D route (route type 2) per [RFC6514]. After the discovery of PEs that are attached to sites of the MVPN, an inclusive overlay tree (I-PMSI) can be setup for carrying tenant multicast flows for that MVPN; however, this is not a requirement per [RFC6514] and it is possible to adopt a policy in which all tenant flows are carried on S-PMSIs. An EVPN PE also sets up a multipoint-to-multipoint (MP2MP) tree per EVI using Inclusive Multicast Ethernet Tag route (route type 3) of EVPN NLRI per [RFC7432]. This MP2MP tree can be instantiated using unicast tunnels or P2MP tunnels. In [RFC7432], this tree is used for transmission of all BUM traffic including IP multicast traffic. However, for multicast traffic handling in EVPN-IRB PEs, this tree is used for all broadcast, unknown-unicast and non-IP multicast traffic - i.e., it is used for all BUM traffic except IP multicast user traffic. Therefore, an EVPN-IRB PE sends a customer IP multicast flow only on a single tunnel that is instantiated for MVPN I-PMSI or S- PMSI. In other words, IP multicast traffic sent over MPLS/IP network are not sent off of MAC-VRF but rather IP-VRF. If a tenant host device is multi-homed to two or more EVPN PEs using All-Active multi-homing, then IGMP join and leave messages are synchronized between these EVPN PEs using EVPN IGMP Join Synch route (route type 7) and EVPN IGMP Leave Synch route (route type 8). There is no need to use EVPN Selective Multicast Tag route (SMET route) because the IGMP messages are terminated by the EVPN-IRB PE and tenant (S,G) or (*,G) join messages are sent via MVPN Source/Shared Tree Join messages. Patel, et al. Expires January 2, 2017 [Page 11] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 5.1.2 Data Plane Operation When an EVPN-IRB PE receives an IGMP/MLD join message over one of its Attachment Circuits (ACs), it adds that AC to its Layer-2 (L2) OIF list. This L2 OIF list is associated with the MAC-VRF corresponding to the subnet of the tenant device that sent the IGMP/MLD join. Therefore, tenant (S,G) or (*,G) forwarding entries are created/updated for the corresponding MAC-VRF based on these source and group IP addresses. Furthermore, the IGMP/MLD join message is propagated over the corresponding IRB interface and it is processed by the tenant multicast routing instance which creates the corresponding tenant (S,G) or (*,G) Layer-3 (L3) forwarding entries. It adds this IRB interface to the L3 OIF list. An IRB is removed as a L3 OIF when all L2 tenant (S,G) or (*,G) forwarding states is removed for the MAC-VRF associated with that IRB. Furthermore, tenant (S,G) or (*,G) L3 forwarding state is removed when all of its L3 OIFs are removed - i.e., all the IRB interfaces associated with that tenant (S,G) or (*,G) are removed. When an EVPN-IRB PE receives IP multicast traffic, if it has any attached receivers for that subnet, it does L2 switching for such intra-subnet traffic. It then sends the multicast traffic over the corresponding IRB interface. The multicast traffic then gets routed over IRB interfaces that are included in the OIF list for that multicast traffic (and TTL gets decremented). When the multicast traffic is received on an IRB interface by the MAC-VRF corresponding to that interface, it gets L2 switched and sent over ACs that belong to the L2 OIF list. Furthermore, the multicast traffic gets sent over I-PMSI or S-PMSI associated with that multicast flow to other PE devices that are participating in that MVPN. 5.1.2.1 Sender and Receiver in same MAC-VRF Rcvr1 in Figure 1 is connected to PE1 in MAC-VRF1 (same as Src1) and sends IGMP join for (C-S, C-G), IGMP snooping will record this state in local bridging entry. A routing entry will be formed as well which will point to MAC-VRF1 as RPF for Src1. We assume that Src1 is known via ARP or similar procedures. Rcvr1 will get a locally bridged copy of multicast traffic from Src1. Rcvr3 is also connected in MAC-VRF1 but to PE2 and hence would send IGMP join which will be recorded at PE2. PE2 will also form routing entry and RPF will be assumed as Tenant Tunnel "Tenant1" formed beforehand using MVPN procedures. Also this would cause multicast control plane to initiate a BGP MCAST-VPN type 7 route which would include VRI for PE1 and hence be accepted on PE1. PE1 will include Tenant1 tunnel as Outgoing Interface (OIF) in the routing entry. Now, since it has knowledge of remote receivers via MVPN control plane it will encapsulate original multicast traffic in Tenant1 tunnel towards Patel, et al. Expires January 2, 2017 [Page 12] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 core. On PE2, since C-S falls in the MAC-VRF1 subnet, MAC-VRF1 Outgoing interface is treated as Ingress MAC-VRF bridging. Hence no rewrite is performed on the received customer data packet while forwarding towards Rcvr3. 5.1.2.2 Sender and Receiver in different MAC-VRF Rcvr2 in Figure 1 is connected to PE1 in MAC-VRF2 and hence PE2 will record its membership in MAC-VRF2. Since MAC-VRF2 is enabled with IRB, it gets added as another OIF to routing entry formed for (C-S, C-G). Rcvr3 and Rcvr4 are also in different MAC-VRFs than multicast speaker Src1 and hence need Inter-subnet forwarding. PE2 will form local bridging entry in MAC-VRF2 due to IGMP joins received from Rcvr3 and Rcvr4 respectively. PE2 now adds another OIF 'MAC-VRF2' to its existing routing entry. But there is no change in control plane states since its already sent MVPN route and no further signaling is required. Also since Src1 is not part of MAC-VRF2 subnet, it is treated as routing OIF and hence MAC header gets modified as per normal procedures for routing. PE3 forms routing entry very similar to PE2. It is to be noted that PE3 does not have MAC-VRF1 configured locally but still can receive the multicast data traffic over Tenant1 tunnel formed due to MVPN procedures 5.2. Operational Model for Heterogeneous EVPN IRB PEs 5.3. All-Active Multi-Homing EVPN solution [RFC7432] uses ESI MPLS label for split-horizon filtering of Broadcast/Unknown unicast/multicast (BUM) traffic from an All-Active multi-homing Ethernet Segment to ensure that BUM traffic doesn't get loop back to the same Ethernet Segment that it came from. In MVPN, there is no concept of ESI label and split- horizon filtering because there is no support for All-Active multi- homing; however, EVPN NVEs rely on this function to prevent loop for an access Ethernet Segment. Figure-2 depicts a source sitting behind an All-Active dual-homing Ethernet Segment. The following scenarios needs special considerations: Patel, et al. Expires January 2, 2017 [Page 13] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 EVPN PE1 +------------+ Rcvr1 +----|(MAC-VRF1) | MVPN PE1 | \ | +---------+ +--------+ | (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr4 | / | | | +--------+ +---|(MAC-VRF2) | | | Src1 | +------------+ | | (ES1) | | MPLS/ | Rcvr6 | EVPN PE2 | IP | (*,G) | +------------+ | | +---|(MAC-VRF2) | | | MVPN PE2 | \ | | | +--------+ | (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr5 | / | +---------+ +--------+ Rcvr2 +----|(MAC-VRF3) | +------------+ Figure-2: Multi-homing 5.3.1. Source and receivers in same ES but on different subnets If the tenant multicast source sits on a different subnet than its receivers, then EVPN DF election procedure for multi-homing ES is sufficient and there will be no need to do any split-horizon filtering for that Ethernet Segment because with IGMP/MLD snooping enabled on VLANs for the multi-homing ES, only the VLANs for which IGMP/MLD join have been received are placed in OIF list for that (S,G) or (*,G) on that ES. Therefore, multicast traffic will not be loop backed on the source subnet (because there is no receiver on that subnet) and for other subnets that the multicast traffic is loop backed, the DF election ensures only a single copy of the multicast traffic is sent on that subnet. 5.3.2. Source and some receivers in same ES and on same subnet If the tenant multicast source sits on the same subnet and the same ES as some of its receivers and those receivers have interest in (*,G), then Besides DF election mechanism, there needs to be split- horizon filtering to ensure that the multicast traffic originated from that is not loop backed to itself. The existing split-horizon filtering as specified in [RFC7432] cannot be used because the received VPN label identifies the multicast IP-VRF and not MAC-VRF. Therefore, egress PE doesn't know for which EVI/BD it needs to perform split-horizon filtering and for which EVI/BDs Patel, et al. Expires January 2, 2017 [Page 14] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 belonging to the the same ES, it needs not to perform split-horizon filtering. This issue is resolved by extending the local-bias solution per [OVERLAY] to MPLS tunnels. There are two cases to consider here: a) Ingress-replication tunnels used for the multicast traffic and b) P2MP tunnels used for the multicast traffic. If ingress-replication tunnels are used, then each PE in the multi- homing group instead of advertising an ESI label, it advertises to each PE in the multi-homing group a downstream assigned label identifying that PE, so that when it receives a packet with this label, it know who the originating PE is. Once the egress PE can identify the originating PE for a packet, then it can execute local- bias procedure per [OVERLAY] for each of its EVI/BDs corresponding to that IP-VRF. If P2MP tunnels are used (e.g., mLDP, RSVP-TE, or BIER), the tunnel label identifies the tunnel and thus the originating PE. Since the originating PE can be identified, the local-bias procedure per [OVERLAY] is applied to prevent multicast data to be sent on the Ethernet Segments in common with the originating PE. The difference between the local-bias procedure in here versus the one described in [OVERLAY] is that the multicast traffic in [OVERLAY] is only intended for one subnet (and thus one BD) whereas the multicast traffic in Figure-2 can span across multiple subnets (and thus multiple BDs). Therefore, local-bias procedure in [OVERLAY] is expanded to perform local bias across all the BDs of that tenant. In other words, the same local-bias procedure is applied to all BDs of that tenant in both the originating EVPN NVE as well as all other EVPN NVEs that share the Ethernet Segment with the originating EVPN NVE. 5.4. Mobility for Tenant's sources and receivers 5.5. Single-Active Multi-Homing 6. DCs with only EVPN NVEs As mentioned earlier, the proposed solution can be used as a routed multicast solution for EVPN-only applications in data centers (e.g., routed multicast VPN only among EVPN PEs). It should be noted that the scope of intra-subnet, forwarding for the solution described in this document, is limited to a single EVPN-IRB PE. In other words, the IP multicast traffic that needs to be forwarded from one PE to another is always routed (L3 forwarded) regardless of whether the traffic is intra-subnet or inter-subnet. As the result, the TTL value for intra-subnet traffic that spans across two or more PEs get Patel, et al. Expires January 2, 2017 [Page 15] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 decremented. Based on past experiences with MVPN over last dozen years for supported IP multicast applications, layer-3 forwarding of intra-subnet multicast traffic should be fine. However, if there are applications that require intra-subnet multicast traffic to be L2 forwarded (e.g., without decrementing TTL value), then [EVPN-IRB- MCAST] proposes a solution to accommodate such applications. 6.1 Setup of overlay multicast delivery It must be emphasized that this solution poses no restriction on the setup of the tenant BDs and that neither the source PE, nor the receiver PEs do not need to know/learn about the BD configuration on other PEs in the MVPN. The Reverse Path Forwarder (RPF) is selected per the tenant multicast source and the IP-VRF in compliance with the procedures in [RFC6514], using the incoming IP Prefix route (route type 5) of EVPN NLRI per [RFC7432]. The VRF Route Import (VRI) extended community that is carried with the IP-VPN routes in [RFC6514] MUST be carried via the EVPN unicast routes instead. The construction and processing of the VRI are consistent with [RFC6514]. The VRI MUST uniquely identify the PE which is advertising a multicast source and the IP-VRF it resides in. VRI is constructed as following: - The 4-octet Global Administrator field MUST be set to an IP address of the PE. This address SHOULD be common for all the IP-VRFs on the PE (e.g., this address may be the PE's loopback address). - The 2-octet Local Administrator field associated with a given IP-VRF contains a number that uniquely identifies that IP-VRF within the PE that contains the IP-VRF. Every PE which detects a local receiver via a local IGMP join or a local PIM join for a specific source (overlay SSM mode) MUST terminate the IGMP/PIM signaling at the IP-VRF and generate a (C-S,C- G) via the BGP MCAST-VPN route type 7 per [RFC6514] if and only if the RPF for the source points to the fabric. If the RPF points to a local multicast source on the same MAC-VRF or a different MAC-VRF on that PE, the MCAST-VPN MUST NOT be advertised and data traffic will be locally routed/bridged to the receiver as detailed in section 6.2. The VRI received with EVPN route type 5 NLRI from source PE will be appended as an export route-target extended community. More details about handling of various types of local receivers are in section 10. The PE which has advertised the unicast route with VRI, will import the incoming MCAST-VPN NLRI in the IP-VRF with the same import route- Patel, et al. Expires January 2, 2017 [Page 16] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 target extended-community and other PEs SHOULD ignore it. Following such procedure the source PE learns about the existence of at least one remote receiver in the tenant overlay and programs data plane accordingly so that a single copy of multicast data is forwarded into the core VRF using tenant VRF tunnel. If the multicast source is unknown (overlay ASM mode), the MCAST-VPN route type 6 (C-*,C-G) join SHOULD be targeted towards the designated overlay Rendezvous Point (RP) by appending the received RP VRI as an export route-target extended community. Every PE which detects a local source, registers with its RP PE. That is how the RP learns about the tenant source(s) and group(s) within the MVPN. Once the overlay RP PE receives either the first remote (C-RP,C-G) join or a local IGMP join or a local PIM join, it will trigger an MCAST-VPN route type 7 (C-S,C-G) towards the actual source PE for which it has received PIM register message in full compliance with regular PIM procedures. This involves the source PE to advertise the MCAST-VPN Source Active A-D route (MCAST-VPN route-type 5) towards all PEs. The Source Active A-D route is used to inform the active multicast source to all PEs in the Overlay so they can potentially switch from RP-Shared-Tree to Shortest-Path-Tree. The above procedure is optional per [RFC6514], and user SHALL enable an auto-discovery mode where the temporary RP-Shared-Tree is not involved. In this mode, the source PE MUST advertise the MCAST-VPN Source Active A-D route (type 5) as soon as it detects data traffic from the local tenant multicast source. Hence the PEs at different sites of the same MVPN will directly join the Shortest-Path-Tree once they receive the MCAST-VPN Source Active A-D route. 6.3 Data plane considerations Data-center fabrics are implemented using variety of core technologies but predominant ones are IP/VXLAN Ingress Replication, IP/VXLAN PIM and MPLS LSM. IP and MPLS have been predominant choice for MVPN core as well hence all existing procedures for forming tunnels for these technologies are applicable in EVPN as well. Also as described in earlier section, each PE acts as PIM DR in its locally connected Bridge Domain, we MUST NOT forward post-routed traffic out of IRB interfaces towards the core. 7 Handling of different encapsulations Just as in [RFC6514] the A-D routes are used to form the overlay multicast tunnels and signal the tunnel type using the P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute. Patel, et al. Expires January 2, 2017 [Page 17] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 7.1 MPLS Encapsulation The [RFC6514] assumes MPLS/IP core and there is no modification to the signaling procedures and encoding for PMSI tunnel formation therein. Also, there is no need for a gateway to inter-operate with non-EVPN PEs supporting [RFC6514] based MVPN over IP/MPLS. 7.2 VxLAN Encapsulation In order to signal VXLAN, the corresponding BGP encapsulation extended community [TUNNEL-ENCAP] SHOULD be appended to the A-D routes. The MPLS label in the PMSI Tunnel Attribute MUST be the Virtual Network Identifier (VNI) associated with the customer MVPN. The supported PMSI tunnel types with VXLAN encapsulation are: PIM-SSM Tree, PIM-SM Tree, BIDIR-PIM Tree, Ingress Replication [RFC6514]. Further details are in [OVERLAY]. In this case, a gateway is needed for inter-operation between the EVPN-IRB PEs and non-EVPN MVPN PEs. The gateway should re-originate the control plane signaling with the relevant tunnel encapsulation on either side. In the data plane, the gateway terminates the tunnels formed on either side and performs the relevant stitching/re- encapsulation on data packets. 7.3 Other Encapsulation In order to signal a different tunneling encapsulation such as NVGRE, VXLAN-GPE or MPLSoGRE the corresponding BGP encapsulation extended community [TUNNEL-ENCAP] SHOULD be appended to the A-D routes. If the Tunnel Type field in the encapsulation extended-community is set to a type which requires Virtual Network Identifier (VNI), e.g., VXLAN-GPE or NVGRE [TUNNEL-ENCAP], then the MPLS label in the PMSI Tunnel Attribute MUST be the VNI associated with the customer MVPN. Same as in VXLAN case, a gateway is needed for inter-operation between the EVPN-IRB PEs and non-EVPN MVPN PEs. 8. DCI with MPLS in WAN and VxLAN in DCs This section describers the inter-operation between MVPN MPLS WAN with MVPN-EVPN in a data-center which runs on VxLAN. Since the tunnel encapsulation between these networks are different, we must have at least one gateway in between. Usually, two or more are required for redundancy and load balancing purpose. Some aspects of the multi- homing between VxLAN DC networks and MPLS WAN is in common with [INTERCON-EVPN]. Herein, only the differences are described. 8.1 Control plane inter-connect Patel, et al. Expires January 2, 2017 [Page 18] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 The gateway(s) MUST be setup with the inclusive set of all the IP- VRFs that span across the two domains. On each gateway, there will be at least two BGP sessions: one towards the DC side and the other towards the WAN side. Usually for redundancy purpose, more sessions are setup on each side. The unicast route propagation follows the exact same procedures in [INTERCON-EVPN]. Hence, a multicast host located in either domain, is advertised with the gateway IP address as the next-hop to the other domain. As a result, PEs view the hosts in the other domain as directly attached to the gateway and all inter-domain multicast signaling is directed towards the gateway(s). Received MVPN routes type 1-7 from either side of the gateway(s), MUST NOT be reflected back to the same side but processed locally and re-advertised (if needed) to the other side: - Intra-AS I-PMSI A-D Route: these are distributed within each domain to form the overlay tunnels which terminate at gateway(s). They are not passed to the other side of the gateway(s). - C-Multicast Route: joins are imported into the corresponding IP-VRF on each gateway and advertised as a new route to the other side with the following modifications (the rest of NLRI fields and path attributes remain on-touched): * Route-Distinguisher is set to that of the IP-VRF * Route-target is set to the exported route-target list on IP-VRF * The PMSI tunnel attribute and BGP Encapsulation extended community will be modified according to section 8 * Next-hop will be set to the IP address which represents the gateway on either domain - Source Active A-D Route: same as joins - S-PMSI A-D Route: these are passed to the other side to form selective PMSI tunnels per every (C-S,C-G) from the gateway to the PEs in the other domain provided it contains receivers for the given (C-S, C-G). Similar modifications made to joins are made to the newly originated S-PMSI. In addition, the Originating Router's IP address is set to GW's IP address. Multicast signaling from/to hosts on local ACs on the gateway(s) are generated and propagated in both domains (if needed) per the procedures in section 7 in this document and in [RFC6514] with no change. It must be noted that for a locally attached source, the gateway will program an OIF per every domain from which it receives a remote join in its forwarding plane and different Patel, et al. Expires January 2, 2017 [Page 19] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 encapsulation will be used on the data packets. Other point to notice is that if there are multiple gateways in an ESI which peer with each other, each one will receive two sets of the local MCAST-VPN routes from the other gateway: 1) the WAN set 2) the DC set. Following the same procedure as in [INTERCON-EVPN], the WAN set SHALL be given a higher priority. 8.2 Data plane inter-connect Traffic forwarding procedures on gateways are same as those described for PEs in section 5 and 6 except that, unlike a non-border leaf PE, the gateway will not only route or bridge the incoming traffic from one side to its local receivers, but will also send it to the remote receivers in the the other domain after de-capsulation and appending the right encapsulation. The OIF and IIF are programmed in FIB based on the received joins from either side and the RPF calculation to the source or RP. The de-capsulation and encapsulation actions are programmed based on the received I-PMSI or S-PMSI A-D routes from either sides. If there are more than one gateway between two domains, the multi- homing procedures described in the following section must be considered so that incoming traffic from one side is not looped back to the other gateway. The multicast traffic from local hosts on each gateway flows to the other gateway with the preferred encapsulation (WAN encapsulation is preferred as described in previous section). 8.3 Multi-homing among DCI gateways Just as in [INTERCON-EVPN] every set of multi-homed gateways between the WAN and a given DC are assigned a unique ESI. 9. Inter-AS Operation 10. Use Cases 10.1 DCs with only IGMP/MLD hosts w/o tenant router In a EVPN network consisting of only IGMP/MLD hosts, PE's will receive IGMP (*, G) or (S, G) joins from their locally attached host and would originate MVPN C-Multicast Route Type 6 and 7 NLRI's respectively. As described in RFC 6514 these NLRI's are directed towards RP-PE for Type 6 or Source-PE for Type 7. In case of (*, G) join a Shared-Path Tree will be built in the core from RP-PE towards Patel, et al. Expires January 2, 2017 [Page 20] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 all Receiver-PE's. Once a Source starts to send Multicast data to specified multicast-group, the PE directly connected to Source will do PIM-registration with RP. Since there are existing receivers for the Group, RP will originate a PIM (S, G) join towards Source. This will be converted to MVPN Type 7 NLRI by RP-PE. Please note that since there are no other routers RP-PE would be the PE configured as RP using static configuration or by using BSR or Auto-RP procedures. The detailed working of such protocols is beyond the scope of this document. Upon receiving Type 7 NLRI, Source-PE will include MVPN Tunnel in its Outgoing Interface List. Furthermore, Source-PE will follow the procedures in RFC-6514 to originate MVPN SA-AD route (RT 5) to avoid duplicate traffic and allow all Receiver-PE's to shift from Share-Tree to Shortest-Path-Tree rooted at Source-PE. Section 13 of RFC6514 describes it. However a network operator can chose to have only Shortest-Path-Tree built in MVPN core as described in RFC6513. To achieve this, all PE's can act as RP for its locally connected hosts and thus avoid sending any Shared-Tree Join (MVPN Type 6) into the core. In this scenario, there will be no PIM registration needed since all PE's are first-hop router as well as acting RP. One a source starts to send multicast data, the PE directly connected to it originates Source-Active AD (RT 5) to all other PE's in network. Upon Receiving Source-Active AD route a PE must cache it in its local database and also look for any matching interest for (*, G) where G is the multicast group described in received Source-Active AD route. If it finds any such matching entry, it must originate a C-Multicast route (RT 7) in order to start receiving traffic from Source-PE. This procedure must be repeated on reception of any further Source-Active AD routes. 10.2 DCs with mixed of IGMP/MLD hosts & multicast routers running PIM- SSM This scenario has multicast routers which can send PIM SSM (S, G) joins. Upon receiving these joins and if source described in join is learnt to be behind a MVPN peer PE, local PE will originate C- Multicast Join (RT 7) towards Source-PE. It is expected that PIM SSM group ranges are kept separate from ASM range for which IGMP hosts can send (*, G) joins. Hence both ASM and SSM groups shall operate without any overlap. There is no RP needed for SSM range groups and Shortest Path tree rooted at Source is built once a receiver interest is known. 10.3 DCs with mixed of IGMP/MLD hosts & multicast routers running PIM- ASM This scenario includes reception of PIM (*, G) joins on PE's local AC. These joins are handled similar to IGMP (*, G) join as explained Patel, et al. Expires January 2, 2017 [Page 21] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 in sections above. Another interesting case can arise here is when one of the tenant routers can act as RP for some of the ASM Groups. In such scenario, a Upstream Multicast Hop (UMH) will be elected by other PE's in order to send C-Multicast Routes (RT 6). All procedures described in RFC 6513 with respect to UMH should be used to avoid traffic duplication due to incoherent selection of RP-PE by different Receiver-PE's. 10.4 DCs with mixed of IGMP/MLD hosts & multicast routers running PIM- Bidir Creating Bidirectional (*, G) trees is useful when a customer wants least amount of control state in network. But on downside all receivers for a particular multicast group receive traffic from all sources sending to that group. However for the purpose of this document, all procedures as described in RFC 6513 and RFC 6514 apply when PIM-Bidir is used. 11. IANA Considerations There is no additional IANA considerations for PBB-EVPN beyond what is already described in [RFC7432]. 12. Security Considerations All the security considerations in [RFC7432] apply directly to this document because this document leverages [RFC7432] control plane and their associated procedures. 13. Acknowledgements The authors would like to thank Samir Thoria, Ashutosh Gupta, Niloofar Fazlollahi, and Aamod Vyavaharkar for their discussions and contributions. 14. References 14.1. Normative References [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS VPNs", RFC 7024, October 2013. Patel, et al. Expires January 2, 2017 [Page 22] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 [RFC7432] A. Sajassi, et al., "BGP MPLS Based Ethernet VPN", RFC 7432 , February 2015. 15.2. Informative References [RFC7080] A. Sajassi, et al., "Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges", RFC 7080, December 2013. [RFC7209] D. Thaler, et al., "Requirements for Ethernet VPN (EVPN)", RFC 7209, May 2014. [RFC4389] A. Sajassi, et al., "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006. [RFC4761] K. Kompella, et al., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, Jauary 2007. [OVERLAY] A. Sajassi, et al., "A Network Virtualization Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-01, work in progress, February 2015. [RFC6514] R. Aggarwal, et al., "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC6514, February 2012. [RFC6513] E. Rosen, et al., "Multicast in MPLS/BGP IP VPNs", RFC6513, February 2012. [INTERCON-EVPN] J. Rabadan, et al., "Interconnect Solution for EVPN Overlay networks", https://tools.ietf.org/html/draft-ietf- bess-dci-evpn-overlay-04, September 2016 [TUNNEL-ENCAPS] E. Rosen, et al. "The BGP Tunnel Encapsulation Attribute", https://tools.ietf.org/html/draft-ietf-idr- tunnel-encaps-06, work in progress, June 2017. 15. Authors' Addresses Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: sajassi@cisco.com Patel, et al. Expires January 2, 2017 [Page 23] INTERNET DRAFT Seamless Interop between EVPN & MVPN PEs July 2, 2017 Samir Thoria Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: sthoria@cisco.com Niloofar Fazlollahi Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: nifazlol@cisco.com Ashutosh Gupta Avi Networks Email: ashutosh@avinetworks.com Patel, et al. Expires January 2, 2017 [Page 24]