draft-ietf-bess-evpn-mvpn-seamless-interop-00.txt   draft-ietf-bess-evpn-mvpn-seamless-interop-01.txt 
BESS Working Group A. Sajassi BESS WorkGroup A. Sajassi
Internet Draft K. Thiruvenkatasamy Internet-Draft K. Thiruvenkatasamy
Category: Standard Track S. Thoria Intended status: Standards Track S. Thoria
Cisco Expires: January 11, 2021 Cisco
A. Gupta A. Gupta
Avi Networks VMware
L. Jalil L. Jalil
Verizon Verizon
July 10, 2020
Expires: May 21, 2020 November 18, 2019
Seamless Multicast Interoperability between EVPN and MVPN PEs Seamless Multicast Interoperability between EVPN and MVPN PEs
draft-ietf-bess-evpn-mvpn-seamless-interop-00 draft-ietf-bess-evpn-mvpn-seamless-interop-01
Abstract Abstract
Ethernet Virtual Private Network (EVPN) solution is becoming Ethernet Virtual Private Network (EVPN) solution is becoming
pervasive for Network Virtualization Overlay (NVO) services in data pervasive for Network Virtualization Overlay (NVO) services in data
center (DC) networks and as the next generation VPN services in center (DC) networks and as the next generation VPN services in
service provider (SP) networks. service provider (SP) networks.
As service providers transform their networks in their COs toward As service providers transform their networks in their COs toward
next generation data center with Software Defined Networking (SDN) next generation data center with Software Defined Networking (SDN)
based fabric and Network Function Virtualization (NFV), they want to based fabric and Network Function Virtualization (NFV), they want to
be able to maintain their offered services including Multicast VPN be able to maintain their offered services including Multicast VPN
(MVPN) service between their existing network and their new Service (MVPN) service between their existing network and their new Service
Provider Data Center (SPDC) network seamlessly without the use of Provider Data Center (SPDC) network seamlessly without the use of
gateway devices. They want to have such seamless interoperability gateway devices. They want to have such seamless interoperability
between their new SPDCs and their existing networks for a) reducing between their new SPDCs and their existing networks for a) reducing
cost, b) having optimum forwarding, and c) reducing provisioning. cost, b) having optimum forwarding, and c) reducing provisioning.
This document describes a unified solution based on RFCs 6513 & 6514 This document describes a unified solution based on RFCs 6513 & 6514
for seamless interoperability of Multicast VPN between EVPN and MVPN for seamless interoperability of Multicast VPN between EVPN and MVPN
PEs. Furthermore, it describes how the proposed solution can be used PEs. Furthermore, it describes how the proposed solution can be used
as a routed multicast solution in data centers with only EVPN PEs. as a routed multicast solution in data centers with only EVPN PEs.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as working documents as Internet-Drafts. The list of current Internet-
Internet-Drafts. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 11, 2021.
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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Optimum Forwarding . . . . . . . . . . . . . . . . . . . . 7 4.1. Optimum Forwarding . . . . . . . . . . . . . . . . . . . 7
4.2. Optimum Replication . . . . . . . . . . . . . . . . . . . . 7 4.2. Optimum Replication . . . . . . . . . . . . . . . . . . . 7
4.3. All-Active and Single-Active Multi-Homing . . . . . . . . . 7 4.3. All-Active and Single-Active Multi-Homing . . . . . . . . 7
4.4. Inter-AS Tree Stitching . . . . . . . . . . . . . . . . . . 7 4.4. Inter-AS Tree Stitching . . . . . . . . . . . . . . . . . 8
4.5. EVPN Service Interfaces . . . . . . . . . . . . . . . . . . 8 4.5. EVPN Service Interfaces . . . . . . . . . . . . . . . . . 8
4.6. Distributed Anycast Gateway . . . . . . . . . . . . . . . . 8 4.6. Distributed Anycast Gateway . . . . . . . . . . . . . . . 8
4.7. Selective & Aggregate Selective Tunnels . . . . . . . . . . 8 4.7. Selective & Aggregate Selective Tunnels . . . . . . . . 8
4.8. Tenants' (S,G) or (*,G) states . . . . . . . . . . . . . . 8 4.8. Tenants' (S,G) or (*,G) states . . . . . . . . . . . . . 8
4.9. Zero Disruption upon BD/Subnet Addition . . . . . . . . . . 8 4.9. Zero Disruption upon BD/Subnet Addition . . . . . . . . . 8
4.10. No Changes to Existing EVPN Service Interface Models . . . 8 4.10. No Changes to Existing EVPN Service Interface Models . . 9
4.11. External source and receivers . . . . . . . . . . . . . . 9 4.11. External source and receivers . . . . . . . . . . . . . . 9
4.12. Tenant RP placement . . . . . . . . . . . . . . . . . . . 9 4.12. Tenant RP placement . . . . . . . . . . . . . . . . . . . 9
5. IRB Unicast versus IRB Multicast . . . . . . . . . . . . . . . 9 5. IRB Unicast versus IRB Multicast . . . . . . . . . . . . . . 9
5.1. Emulated Virtual LAN Service . . . . . . . . . . . . . . . 9 5.1. Emulated Virtual LAN Service . . . . . . . . . . . . . . 10
6. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10 6. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Operational Model for EVPN IRB PEs . . . . . . . . . . . . 10 6.1. Operational Model for EVPN IRB PEs . . . . . . . . . . . 10
6.2. Unicast Route Advertisements for IP multicast Source . . . 12 6.2. Unicast Route Advertisements for IP multicast Source . . 13
6.3. Multi-homing of IP Multicast Source and Receivers . . . . 13 6.3. Multi-homing of IP Multicast Source and Receivers . . . . 14
6.3.1. Single-Active Multi-Homing . . . . . . . . . . . . . . 14 6.3.1. Single-Active Multi-Homing . . . . . . . . . . . . . 14
6.3.2. All-Active Multi-Homing . . . . . . . . . . . . . . . 15 6.3.2. All-Active Multi-Homing . . . . . . . . . . . . . . . 15
6.4. Mobility for Tenant's Sources and Receivers . . . . . . . 17 6.4. Mobility for Tenant's Sources and Receivers . . . . . . . 17
6.5. Intra-Subnet BUM Traffic Handling . . . . . . . . . . . . 17 6.5. Intra-Subnet BUM Traffic Handling . . . . . . . . . . . . 18
6.6 EVPN and MVPN interworking with gateway model . . . . . . . 17 6.6. EVPN and MVPN interworking with gateway model . . . . . . 18
7. Control Plane Operation . . . . . . . . . . . . . . . . . . . 18 7. Control Plane Operation . . . . . . . . . . . . . . . . . . . 19
7.1. Intra-ES/Intra-Subnet IP Multicast Tunnel . . . . . . . . . 18 7.1. Intra-ES/Intra-Subnet IP Multicast Tunnel . . . . . . . . 19
7.2. Intra-Subnet BUM Tunnel . . . . . . . . . . . . . . . . . . 19 7.2. Intra-Subnet BUM Tunnel . . . . . . . . . . . . . . . . . 20
7.3. Inter-Subnet IP Multicast Tunnel . . . . . . . . . . . . . 20 7.3. Inter-Subnet IP Multicast Tunnel . . . . . . . . . . . . 20
7.4. IGMP Hosts as TSes . . . . . . . . . . . . . . . . . . . . 20 7.4. IGMP Hosts as TSes . . . . . . . . . . . . . . . . . . . 21
7.5. TS PIM Routers . . . . . . . . . . . . . . . . . . . . . . 21 7.5. TS PIM Routers . . . . . . . . . . . . . . . . . . . . . 22
8 Data Plane Operation . . . . . . . . . . . . . . . . . . . . . 21 8. Data Plane Operation . . . . . . . . . . . . . . . . . . . . 22
8.1 Intra-Subnet L2 Switching . . . . . . . . . . . . . . . . . 22 8.1. Intra-Subnet L2 Switching . . . . . . . . . . . . . . . . 23
8.2 Inter-Subnet L3 Routing . . . . . . . . . . . . . . . . . . 22 8.2. Inter-Subnet L3 Routing . . . . . . . . . . . . . . . . . 23
9. DCs with only EVPN PEs . . . . . . . . . . . . . . . . . . . . 23 9. DCs with only EVPN PEs . . . . . . . . . . . . . . . . . . . 23
9.1. Setup of overlay multicast delivery . . . . . . . . . . . . 23 9.1. Setup of overlay multicast delivery . . . . . . . . . . . 24
9.2. Handling of different encapsulations . . . . . . . . . . . 25 9.2. Handling of different encapsulations . . . . . . . . . . 26
9.2.1. MPLS Encapsulation . . . . . . . . . . . . . . . . . . 25 9.2.1. MPLS Encapsulation . . . . . . . . . . . . . . . . . 26
9.2.2 VxLAN Encapsulation . . . . . . . . . . . . . . . . . . 25 9.2.2. VxLAN Encapsulation . . . . . . . . . . . . . . . . . 26
9.2.3. Other Encapsulation . . . . . . . . . . . . . . . . . 26 9.2.3. Other Encapsulation . . . . . . . . . . . . . . . . . 26
10. DCI with MPLS in WAN and VxLAN in DCs . . . . . . . . . . . . 26 10. DCI with MPLS in WAN and VxLAN in DCs . . . . . . . . . . . . 27
10.1. Control plane inter-connect . . . . . . . . . . . . . . . 26 10.1. Control plane inter-connect . . . . . . . . . . . . . . 27
10.2. Data plane inter-connect . . . . . . . . . . . . . . . . . 27 10.2. Data plane inter-connect . . . . . . . . . . . . . . . . 28
11. Supporting application with TTL value 1 . . . . . . . . . . . 28 11. Supporting application with TTL value 1 . . . . . . . . . . . 29
11.1. Policy based model . . . . . . . . . . . . . . . . . . . . 28 11.1. Policy based model . . . . . . . . . . . . . . . . . . . 29
11.2. Exercising BUM procedure for VLAN/BD . . . . . . . . . . . 28 11.2. Exercising BUM procedure for VLAN/BD . . . . . . . . . . 29
11.3. Intra-subnet bridging . . . . . . . . . . . . . . . . . . 28 11.3. Intra-subnet bridging . . . . . . . . . . . . . . . . . 29
12. Interop with L2 EVPN PEs . . . . . . . . . . . . . . . . . . . 30 12. Interop with L2 EVPN PEs . . . . . . . . . . . . . . . . . . 31
13. Connecting external Multicast networks or PIM routers. . . . . 30 13. Connecting external Multicast networks or PIM routers. . . . 33
14. RP handling . . . . . . . . . . . . . . . . . . . . . . . . . 30 14. RP handling . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Various RP deployment options . . . . . . . . . . . . . . 30 14.1. Various RP deployment options . . . . . . . . . . . . . 33
14.1.1. RP-less mode . . . . . . . . . . . . . . . . . . . . . 30 14.1.1. RP-less mode . . . . . . . . . . . . . . . . . . . . 33
14.1.2. Fabric anycast RP . . . . . . . . . . . . . . . . . . 31 14.1.2. Fabric anycast RP . . . . . . . . . . . . . . . . . 33
14.1.3. Static RP . . . . . . . . . . . . . . . . . . . . . . 31 14.1.3. Static RP . . . . . . . . . . . . . . . . . . . . . 34
14.1.4. Co-existence of Fabric anycast RP and external RP . . 31 14.1.4. Co-existence of Fabric anycast RP and external RP . 34
14.2. RP configuration options . . . . . . . . . . . . . . . . . 31 14.2. RP configuration options . . . . . . . . . . . . . . . . 34
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 16. Security Considerations . . . . . . . . . . . . . . . . . . . 34
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
18.1. Normative References . . . . . . . . . . . . . . . . . . 32 18.1. Normative References . . . . . . . . . . . . . . . . . . 35
18.2. Informative References . . . . . . . . . . . . . . . . . 33 18.2. Informative References . . . . . . . . . . . . . . . . . 36
19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 34 A.1. DCs with only IGMP/MLD hosts w/o tenant router . . . . . 36
A.1. DCs with only IGMP/MLD hosts w/o tenant router . . . . . . 34 A.2. DCs with mixed of IGMP/MLD hosts & multicast routers
running PIM-SSM . . . . . . . . . . . . . . . . . . . . . 37
A.3. DCs with mixed of IGMP/MLD hosts & multicast routers
running PIM-ASM . . . . . . . . . . . . . . . . . . . . . 38
A.4. DCs with mixed of IGMP/MLD hosts & multicast routers
running PIM-Bidir . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Ethernet Virtual Private Network (EVPN) solution is becoming Ethernet Virtual Private Network (EVPN) solution is becoming
pervasive for Network Virtualization Overlay (NVO) services in data pervasive for Network Virtualization Overlay (NVO) services in data
center (DC) networks and as the next generation VPN services in center (DC) networks and as the next generation VPN services in
service provider (SP) networks. service provider (SP) networks.
As service providers transform their networks in their COs toward As service providers transform their networks in their COs toward
next generation data center with Software Defined Networking (SDN) next generation data center with Software Defined Networking (SDN)
based fabric and Network Function Virtualization (NFV), they want to based fabric and Network Function Virtualization (NFV), they want to
be able to maintain their offered services including Multicast VPN be able to maintain their offered services including Multicast VPN
(MVPN) service between their existing network and their new SPDC (MVPN) service between their existing network and their new SPDC
network seamlessly without the use of gateway devices. There are network seamlessly without the use of gateway devices. There are
several reasons for having such seamless interoperability between several reasons for having such seamless interoperability between
their new DCs and their existing networks: their new DCs and their existing networks:
- Lower Cost: gateway devices need to have very high scalability to - Lower Cost: gateway devices need to have very high scalability to
handle VPN services for their DCs and as such need to handle large 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 number of VPN instances (in tens or hundreds of thousands) and very
large number of routes (e.g., in tens of millions). For the same large number of routes (e.g., in tens of millions). For the same
speed and feed, these high scale gateway boxes are relatively much speed and feed, these high scale gateway boxes are relatively much
more expensive than the edge devices (e.g., PEs and TORs) that more expensive than the edge devices (e.g., PEs and TORs) that
support much lower number of routes and VPN instances. support much lower number of routes and VPN instances.
- Optimum Forwarding: in a given CO, both EVPN PEs and MVPN PEs can - Optimum Forwarding: in a given CO, both EVPN PEs and MVPN PEs can
be connected to the same fabric/network (e.g., same IGP domain). In be connected to the same fabric/network (e.g., same IGP domain). In
such scenarios, the service providers want to have optimum forwarding such scenarios, the service providers want to have optimum forwarding
among these PE devices without the use of gateway devices. Because if among these PE devices without the use of gateway devices. Because
gateway devices are used, then the IP multicast traffic between an if gateway devices are used, then the IP multicast traffic between an
EVPN and MVPN PEs can no longer be optimum and in some case, it may EVPN and MVPN PEs can no longer be optimum and in some case, it may
even get tromboned. Furthermore, when an SPDC network spans across even get tromboned. Furthermore, when an SPDC network spans across
multiple LATA (multiple geographic areas) and gateways are used multiple LATA (multiple geographic areas) and gateways are used
between EVPN and MVPN PEs, then with respect to IP multicast traffic, between EVPN and MVPN PEs, then with respect to IP multicast traffic,
only one GW can be designated forwarder (DF) between EVPN and MVPN only one GW can be designated forwarder (DF) between EVPN and MVPN
PEs. Such scenarios not only results in non-optimum forwarding but PEs. Such scenarios not only results in non-optimum forwarding but
also it can result in tromboing of IP multicast traffic between the also it can result in tromboing of IP multicast traffic between the
two LATAs when both source and destination PEs are in the same LATA 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. and the DF gateway is elected to be in a different LATA.
- Less Provisioning: If gateways are used, then the operator need to - Less Provisioning: If gateways are used, then the operator need to
configure per-tenant info on the gateways. In other words, for each configure per-tenant info on the gateways. In other words, for each
tenant that is configured, one (or maybe two) additional touch points tenant that is configured, one (or maybe two) additional touch points
are needed. are needed.
This document describes a unified solution based on [RFC6513] and This document describes a unified solution based on [RFC6513] and
[RFC6514] for seamless interoperability of multicast VPN between EVPN [RFC6514] for seamless interoperability of multicast VPN between EVPN
and MVPN PEs. Furthermore, it describes how the proposed solution can and MVPN PEs. Furthermore, it describes how the proposed solution
be used as a routed multicast solution in data centers with only EVPN can be used as a routed multicast solution in data centers with only
PEs (e.g., routed multicast VPN only among EVPN PEs). EVPN PEs (e.g., routed multicast VPN only among EVPN PEs).
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
be interpreted as described in [RFC2119] only when they appear in all 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 upper case. They may also appear in lower or mixed case as English
words, without any normative meaning. words, without any normative meaning.
3. Terminology 3. Terminology
skipping to change at page 5, line 36 skipping to change at page 5, line 37
VXLAN: Virtual Extensible LAN VXLAN: Virtual Extensible LAN
POD: Point of Delivery POD: Point of Delivery
NV: Network Virtualization NV: Network Virtualization
NVO: Network Virtualization Overlay NVO: Network Virtualization Overlay
NVE: Network Virtualization Endpoint NVE: Network Virtualization Endpoint
VNI: Virtual Network Identifier (for VXLAN) VNI: Virtual Network Identifier (for VXLAN)
EVPN: Ethernet VPN EVPN: Ethernet VPN
EVI: An EVPN instance spanning the Provider Edge (PE) devices EVI: An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN participating in that EVPN
MAC-VRF: A Virtual Routing and Forwarding table for Media Access MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE Control (MAC) addresses on a PE
IP-VRF: A Virtual Routing and Forwarding table for Internet Protocol IP-VRF: A Virtual Routing and Forwarding table for Internet Protocol
skipping to change at page 7, line 7 skipping to change at page 7, line 11
L3VNI: A VNI in the tenant VRF, which is associated with the core L3VNI: A VNI in the tenant VRF, which is associated with the core
facing interface. facing interface.
4. Requirements 4. Requirements
This section describes the requirements specific in providing This section describes the requirements specific in providing
seamless multicast VPN service between MVPN and EVPN capable seamless multicast VPN service between MVPN and EVPN capable
networks. networks.
4.1. Optimum Forwarding 4.1. Optimum Forwarding
The solution SHALL support optimum multicast forwarding between EVPN The solution SHALL support optimum multicast forwarding between EVPN
and MVPN PEs within a network. The network can be confined to a CO or and MVPN PEs within a network. The network can be confined to a CO
it can span across multiple LATAs. The solution SHALL support optimum or it can span across multiple LATAs. The solution SHALL support
multicast forwarding with both ingress replication tunnels and P2MP optimum multicast forwarding with both ingress replication tunnels
tunnels. and P2MP tunnels.
4.2. Optimum Replication 4.2. Optimum Replication
For EVPN PEs with IRB capability, the solution SHALL use only a For EVPN PEs with IRB capability, the solution SHALL use only a
single multicast tunnel among EVPN and MVPN PEs for IP multicast single multicast tunnel among EVPN and MVPN PEs for IP multicast
traffic, when both PEs use the same tunnel type. Multicast tunnels traffic, when both PEs use the same tunnel type. Multicast tunnels
can be either ingress replication tunnels or P2MP tunnels. The can be either ingress replication tunnels or P2MP tunnels. The
solution MUST support optimum replication for both Intra-subnet and solution MUST support optimum replication for both Intra-subnet and
Inter-subnet IP multicast traffic: Inter-subnet IP multicast traffic:
- Non-IP traffic SHALL be forwarded per EVPN baseline [RFC7432] or - Non-IP traffic SHALL be forwarded per EVPN baseline [RFC7432] or
[RFC8365] [RFC8365]
- If a Multicast VPN spans across both Intra and Inter subnets, then - If a Multicast VPN spans across both Intra and Inter subnets, then
for Ingress replication regardless of whether the traffic is Intra or for Ingress replication regardless of whether the traffic is Intra or
Inter subnet, only a single copy of IP multicast traffic SHALL be Inter subnet, only a single copy of IP multicast traffic SHALL be
sent from the source PE to the destination PE. sent from the source PE to the destination PE.
- If a Multicast VPN spans across both Intra and Inter subnets, then - If a Multicast VPN spans across both Intra and Inter subnets, then
for P2MP tunnels regardless of whether the traffic is Intra or Inter for P2MP tunnels regardless of whether the traffic is Intra or Inter
subnet, only a single copy of multicast data SHALL be transmitted by 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 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 PEs can be a mix of EVPN and MVPN PEs - i.e., a multicast VPN can be
spread across both EVPN and MVPN PEs. spread across both EVPN and MVPN PEs.
4.3. All-Active and Single-Active Multi-Homing 4.3. All-Active and Single-Active Multi-Homing
The solution MUST support multi-homing of source devices and The solution MUST support multi-homing of source devices and
receivers that are sitting in the same subnet (e.g., VLAN) and are 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- multi-homed to EVPN PEs. The solution SHALL allow for both Single-
Active and All-Active multi-homing. The solution MUST prevent loop Active and All-Active multi-homing. The solution MUST prevent loop
during steady and transient states just like EVPN baseline solution during steady and transient states just like EVPN baseline solution
[RFC7432] and [RFC8365] for all multi-homing types. [RFC7432] and [RFC8365] for all multi-homing types.
4.4. Inter-AS Tree Stitching 4.4. Inter-AS Tree Stitching
The solution SHALL support multicast tree stitching when the tree The solution SHALL support multicast tree stitching when the tree
spans across multiple Autonomous Systems. spans across multiple Autonomous Systems.
4.5. EVPN Service Interfaces 4.5. EVPN Service Interfaces
The solution MUST support all EVPN service interfaces listed in The solution MUST support all EVPN service interfaces listed in
section 6 of [RFC7432]: section 6 of [RFC7432]:
- VLAN-based service interface o VLAN-based service interface
- VLAN-bundle service interface
- VLAN-aware bundle service interface
4.6. Distributed Anycast Gateway o VLAN-bundle service interface
o VLAN-aware bundle service interface.
4.6. Distributed Anycast Gateway
The solution SHALL support distributed anycast gateways for tenant The solution SHALL support distributed anycast gateways for tenant
workloads on NVE devices operating in EVPN-IRB mode. workloads on NVE devices operating in EVPN-IRB mode..
4.7. Selective & Aggregate Selective Tunnels 4.7. Selective & Aggregate Selective Tunnels
The solution SHALL support selective and aggregate selective P- The solution SHALL support selective and aggregate selective P-
tunnels as well as inclusive and aggregate inclusive P-tunnels. When tunnels as well as inclusive and aggregate inclusive P-tunnels. When
selective tunnels are used, then multicast traffic SHOULD only be selective tunnels are used, then multicast traffic SHOULD only be
forwarded to the remote PE which have receivers - i.e., if there are 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 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, 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. then the multicast traffic SHOULD NOT be forwarded to the core.
4.8. Tenants' (S,G) or (*,G) states 4.8. Tenants' (S,G) or (*,G) states
The solution SHOULD store (C-S,C-G) and (C-*,C-G) states only on PE The solution SHOULD store (C-S,C-G) and (C-*,C-G) states only on PE
devices that have interest in such states hence reducing memory and devices that have interest in such states hence reducing memory and
processing requirements - i.e., PE devices that have sources and/or processing requirements - i.e., PE devices that have sources and/or
receivers interested in such multicast groups. receivers interested in such multicast groups.
4.9. Zero Disruption upon BD/Subnet Addition 4.9. Zero Disruption upon BD/Subnet Addition
In DC environments, various Bridge Domains are provisioned and In DC environments, various Bridge Domains are provisioned and
removed on regular basis due to host mobility, policy and tenant removed on regular basis due to host mobility, policy and tenant
changes. Such change in BD configuration should not affect existing changes. Such change in BD configuration should not affect existing
flows within the same BD or any other BD in the network. flows within the same BD or any other BD in the network.
4.10. No Changes to Existing EVPN Service Interface Models 4.10. No Changes to Existing EVPN Service Interface Models
VLAN-aware bundle service as defined in [RFC7432] typically does not VLAN-aware bundle service as defined in [RFC7432] typically does not
require any VLAN ID translation from one tenant site to another - require any VLAN ID translation from one tenant site to another -
i.e., the same set of VLAN IDs are configured consistently on all i.e., the same set of VLAN IDs are configured consistently on all
tenant segments. In such scenarios, EVPN-IRB multicast service MUST tenant segments. In such scenarios, EVPN-IRB multicast service MUST
maintain the same mode of operation and SHALL NOT require any VLAN ID maintain the same mode of operation and SHALL NOT require any VLAN ID
translation. translation.
4.11. External source and receivers 4.11. External source and receivers
The solution SHALL support sources and receivers external to the The solution SHALL support sources and receivers external to the
tenant domain. i.e., multicast source inside the tenant domain can tenant domain. i.e., multicast source inside the tenant domain can
have receiver outside the tenant domain and vice versa. have receiver outside the tenant domain and vice versa.
4.12. Tenant RP placement 4.12. Tenant RP placement
The solution SHALL support a tenant to have RP anywhere in the The solution SHALL support a tenant to have RP anywhere in the
network. RP can be placed inside the EVPN network or MVPN network or network. RP can be placed inside the EVPN network or MVPN network or
external domain. external domain.
5. IRB Unicast versus IRB Multicast 5. IRB Unicast versus IRB Multicast
[EVPN-IRB] describes the operation for EVPN PEs in IRB mode for [I-D.ietf-bess-evpn-inter-subnet-forwarding] describes the operation
unicast traffic. The same IRB model used for unicast traffic in for EVPN PEs in IRB mode for unicast traffic. The same IRB model
[EVPN-IRB], where an IP-VRF in an EVPN PE is attached to one or more used for unicast traffic in
bridge tables (BTs) via virtual IRB interfaces, is also applicable [I-D.ietf-bess-evpn-inter-subnet-forwarding] , where an IP-VRF in an
for multicast traffic. However, there are some noticeable differences EVPN PE is attached to one or more bridge tables (BTs) via virtual
between the IRB operation for unicast traffic described in [EVPN-IRB] IRB interfaces, is also applicable for multicast traffic. However,
versus for multicast traffic described in this document. For unicast there are some noticeable differences between the IRB operation for
traffic, the intra-subnet traffic, is bridged within the MAC-VRF unicast traffic described in
associated with that subnet (i.e., a lookup based on MAC-DA is [I-D.ietf-bess-evpn-inter-subnet-forwarding] versus for multicast
performed); whereas, the inter-subnet traffic is routed in the traffic described in this document. For unicast traffic, the intra-
corresponding IP-VRF (ie, a lookup based on IP-DA is performed). A subnet traffic, is bridged within the MAC-VRF associated with that
given tenant can have one or more IP-VRFs; however, without loss of subnet (i.e., a lookup based on MAC-DA is performed); whereas, the
generality, this document assumes one IP-VRF per tenant. In context inter-subnet traffic is routed in the corresponding IP-VRF (ie, a
of a given tenant's multicast traffic, the intra-subnet traffic is lookup based on IP-DA is performed). A given tenant can have one or
bridged for non-IP traffic and it is Layer-2 switched for IP traffic. more IP-VRFs; however, without loss of generality, this document
Whereas, the tenants's inter-subnet multicast traffic is always assumes one IP-VRF per tenant. In context of a given tenant's
routed in the corresponding IP-VRF. The difference between bridging multicast traffic, the intra-subnet traffic is bridged for non-IP
and L2-switching for multicast traffic is that the former uses MAC-DA traffic and it is Layer-2 switched for IP traffic. Whereas, the
tenants's inter-subnet multicast traffic is always routed in the
corresponding IP-VRF. The difference between bridging and
L2-switching for multicast traffic is that the former uses MAC-DA
lookup for forwarding the multicast traffic; whereas, the latter uses lookup for forwarding the multicast traffic; whereas, the latter uses
IP-DA lookup for such forwarding where the forwarding states are IP-DA lookup for such forwarding where the forwarding states are
built in the MAC-VRF using IGMP/MLD or PIM snooping. built in the MAC-VRF using IGMP/MLD or PIM snooping.
5.1. Emulated Virtual LAN Service 5.1. Emulated Virtual LAN Service
EVPN does not provide a Virtual LAN (VLAN) service per [IEEE802.1Q] EVPN does not provide a Virtual LAN (VLAN) service per [IEEE802.1Q]
but rather an emulated VLAN service. This VLAN service emulation is but rather an emulated VLAN service. This VLAN service emulation is
not only done for unicast traffic but also is extended for intra- not only done for unicast traffic but also is extended for intra-
subnet multicast traffic described in [EVPN-IGMP-PROXY] and [EVPN- subnet multicast traffic described in
PIM-PROXY]. For intra-subnet multicast, an EVPN PE builds multicast [I-D.ietf-bess-evpn-igmp-mld-proxy] and
forwarding states in its bridge table (BT) based on snooping of [I-D.skr-bess-evpn-pim-proxy]. For intra-subnet multicast, an EVPN
IGMP/MLD and/or PIM messages and the forwarding is performed based on PE builds multicast forwarding states in its bridge table (BT) based
destination IP multicast address of the Ethernet frame rather than on snooping of IGMP/MLD and/or PIM messages and the forwarding is
destination MAC address as noted above. In order to enable seamless performed based on destination IP multicast address of the Ethernet
integration of EVPN and MVPN PEs, this document extends the concept frame rather than destination MAC address as noted above. In order
of an emulated VLAN service for multicast IRB applications such that to enable seamless integration of EVPN and MVPN PEs, this document
the intra-subnet IP multicast traffic can get treated same as inter- extends the concept of an emulated VLAN service for multicast IRB
subnet IP multicast traffic which means intra-subnet IP multicast applications such that the intra-subnet IP multicast traffic can get
traffic destined to remote PEs gets routed instead of being L2- treated same as inter- subnet IP multicast traffic which means intra-
switched - i.e., TTL value gets decremented and the Ethernet header subnet IP multicast traffic destined to remote PEs gets routed
of the L2 frame is de-capsulated an encapsulated at both ingress and instead of being L2- switched - i.e., TTL value gets decremented and
egress PEs. It should be noted that the non-IP multicast or L2 the Ethernet header of the L2 frame is de-capsulated an encapsulated
broadcast traffic still gets bridged and frames get forwarded based at both ingress and egress PEs. It should be noted that the non-IP
on their destination MAC addresses. multicast or L2 broadcast traffic still gets bridged and frames get
forwarded based on their destination MAC addresses.
6. Solution Overview 6. Solution Overview
This section describes a multicast VPN solution based on [RFC6513] This section describes a multicast VPN solution based on [RFC6513]
and [RFC6514] for EVPN PEs operating in IRB mode that want to perform and [RFC6514] for EVPN PEs operating in IRB mode that want to perform
seamless interoperability with their counterparts MVPN PEs. seamless interoperability with their counterparts MVPN PEs.
6.1. Operational Model for EVPN IRB PEs 6.1. Operational Model for EVPN IRB PEs
Without the loss of generality, this section assumes that all EVPN Without the loss of generality, this section assumes that all EVPN
PEs have IRB capability and operating in IRB mode for both unicast 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 and multicast traffic (e.g., all EVPN PEs are homogenous in terms of
their capabilities and operational modes). As it will be seen later, their capabilities and operational modes). As it will be seen later,
an EVPN network can consist of a mix of PEs where some are capable of an EVPN network can consist of a mix of PEs where some are capable of
multicast IRB and some are not and the multicast operation of such multicast IRB and some are not and the multicast operation of such
heterogeneous EVPN network will be an extension of an EVPN homogenous heterogeneous EVPN network will be an extension of an EVPN homogenous
network. Therefore, we start with the multicast IRB solution network. Therefore, we start with the multicast IRB solution
description for the EVPN homogenous network. description for the EVPN homogenous network.
The EVPN PEs terminate IGMP/MLD messages from tenant host devices or The EVPN PEs terminate IGMP/MLD messages from tenant host devices or
PIM messages from tenant routers on their IRB interfaces, thus avoid PIM messages from tenant routers on their IRB interfaces, thus avoid
sending these messages over MPLS/IP core. A tenant virtual/physical sending these messages over MPLS/IP core. A tenant virtual/physical
router (e.g., CE) attached to an EVPN PE becomes a multicast routing router (e.g., CE) attached to an EVPN PE becomes a multicast routing
adjacency of that PE. Furthermore, the PE uses MVPN BGP protocol and adjacency of that PE. Furthermore, the PE uses MVPN BGP protocol and
procedures per [RFC6513] and [RFC6514]. With respect to multicast procedures per [RFC6513] and [RFC6514]. With respect to multicast
routing protocol between tenant's virtual/physical router and the PE routing protocol between tenant's virtual/physical router and the PE
that it is attached to, any of the following PIM protocols is that it is attached to, any of the following PIM protocols is
supported per [RFC6513]: PIM-SM with Any Source Multicast (ASM) mode, supported per [RFC6513]: PIM-SM with Any Source Multicast (ASM) mode,
PIM-SM with Source Specific Multicast (SSM) mode, and PIM PIM-SM with Source Specific Multicast (SSM) mode, and PIM
Bidirectional (BIDIR) mode. Support of PIM-DM (Dense Mode) is Bidirectional (BIDIR) mode. Support of PIM-DM (Dense Mode) is
excluded in this document per [RFC6513]. excluded in this document per [RFC6513].
The EVPN PEs use MVPN BGP routes defined in [RFC6514] to convey The EVPN PEs use MVPN BGP routes defined in [RFC6514] to convey
tenant (S,G) or (*,G) states to other MVPN or EVPN PEs and to set up 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 instance. The overlay trees (inclusive or selective) for a given MVPN instance.
root or a leaf of such an overlay tree is terminated on an EVPN or The root or a leaf of such an overlay tree is terminated on an EVPN
MVPN PE. Furthermore, this inclusive or selective overlay tree is or MVPN PE. Furthermore, this inclusive or selective overlay tree is
terminated on a single IP-VRF of the EVPN or MVPN PE. In case of EVPN terminated on a single IP-VRF of the EVPN or MVPN PE. In case of
PE, these overlay trees never get terminated on MAC-VRFs of that PE. EVPN PE, these overlay trees never get terminated on MAC-VRFs of that
PE.
Overlay trees are instantiated by underlay provider tunnels (P- Overlay trees are instantiated by underlay provider tunnels (P-
tunnels) - e.g., P2MP, MP2MP, or unicast tunnels per [RFC 6513]. When tunnels) - e.g., P2MP, MP2MP, or unicast tunnels per [RFC6513]. When
there are several overlay trees mapped to a single underlay P-tunnel, there are several overlay trees mapped to a single underlay P-tunnel,
the tunnel is referred to as an aggregate tunnel. the tunnel is referred to as an aggregate tunnel.
Figure-1 below depicts a scenario where a tenant's MVPN spans across Figure-1 below depicts a scenario where a tenant's MVPN spans across
both EVPN and MVPN PEs; where all EVPN PEs have multicast IRB both EVPN and MVPN PEs; where all EVPN PEs have multicast IRB
capability. An EVPN PE (with multicast IRB capability) can be modeled capability. An EVPN PE (with multicast IRB capability) can be
as a MVPN PE where the virtual IRB interface of an EVPN PE (virtual modeled as a MVPN PE where the virtual IRB interface of an EVPN PE
interface between a BT and IP-VRF) can be considered a routed (virtual interface between a BT and IP-VRF) can be considered a
interface for the MVPN PE. routed interface for the MVPN PE.
EVPN PE1 EVPN PE1
+------------+ +------------+
Src1 +----|(MAC-VRF1) | MVPN PE3 Src1 +----|(MAC-VRF1) | MVPN PE3
Rcvr1 +----| \ | +---------+ +--------+ Rcvr1 +----| \ | +---------+ +--------+
| (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr5 | (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr5
| / | | | +--------+ | / | | | +--------+
Rcvr2 +---|(MAC-VRF2) | | | Rcvr2 +---|(MAC-VRF2) | | |
+------------+ | | +------------+ | |
| MPLS/ | | MPLS/ |
EVPN PE2 | IP | EVPN PE2 | IP |
+------------+ | | +------------+ | |
Rcvr3 +---|(MAC-VRF1) | | | MVPN PE4 Rcvr3 +---|(MAC-VRF1) | | | MVPN PE4
| \ | | | +--------+ | \ | | | +--------+
| (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr6 | (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr6
| / | +---------+ +--------+ | / | +---------+ +--------+
Rcvr4 +---|(MAC-VRF3) | Rcvr4 +---|(MAC-VRF3) |
+------------+ +------------+
Figure-1: EVPN & MVPN PEs Seamless Interop Figure-1: EVPN & MVPN PEs Seamless Interop
Figure 2 depicts the modeling of EVPN PEs based on MVPN PEs where an Figure 2 depicts the modeling of EVPN PEs based on MVPN PEs where an
EVPN PE can be modeled as a PE that consists of a MVPN PE whose EVPN PE can be modeled as a PE that consists of a MVPN PE whose
routed interfaces (e.g., attachment circuits) are replaced with IRB routed interfaces (e.g., attachment circuits) are replaced with IRB
interfaces connecting each IP-VRF of the MVPN PE to a set of BTs. interfaces connecting each IP-VRF of the MVPN PE to a set of BTs.
Similar to a MVPN PE where an attachment circuit serves as a routed 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 multicast interface for an IP-VRF associated with a MVPN instance, an
IRB interface serves as a routed multicast interface for the IP-VRF IRB interface serves as a routed multicast interface for the IP-VRF
associated with the MVPN instance. Since EVPN PEs run MVPN protocols associated with the MVPN instance. Since EVPN PEs run MVPN protocols
(e.g., [RFC6513] and [RFC6514]), for all practical purposes, they (e.g., [RFC6513] and [RFC6514] ), for all practical purposes, they
look just like MVPN PEs to other PE devices. Such modeling of EVPN 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 PEs, transforms the multicast VPN operation of EVPN PEs to that of
MVPN and thus simplifies the interoperability between EVPN and MVPN MVPN and thus simplifies the interoperability between EVPN and MVPN
PEs to that of running a single unified solution based on MVPN. PEs to that of running a single unified solution based on MVPN.
EVPN PE1 EVPN PE1
+------------+ +------------+
Src1 +----|(MAC-VRF1) | Src1 +----|(MAC-VRF1) |
| \ | | \ |
Rcvr1 +----| +--------+| +---------+ +--------+ Rcvr1 +----| +--------+| +---------+ +--------+
| |MVPN PE1||----| |---|MVPN PE3|--- Rcvr5 | |MVPN PE1||----| |---|MVPN PE3|--- Rcvr5
| +--------+| | | +--------+ | +--------+| | | +--------+
| / | | | | / | | |
Rcvr2 +---|(MAC-VRF2) | | | Rcvr2 +---|(MAC-VRF2) | | |
+------------+ | | +------------+ | |
| MPLS/ | | MPLS/ |
EVPN PE2 | IP | EVPN PE2 | IP |
+------------+ | | +------------+ | |
Rcvr3 +---|(MAC-VRF1) | | | Rcvr3 +---|(MAC-VRF1) | | |
| \ | | | | \ | | |
| +--------+| | | +--------+ | +--------+| | | +--------+
| |MVPN PE2||----| |---|MVPN PE4|--- Rcvr6 | |MVPN PE2||----| |---|MVPN PE4|--- Rcvr6
| +--------+| | | +--------+ | +--------+| | | +--------+
| / | +---------+ | / | +---------+
Rcvr4 +---|(MAC-VRF3) | Rcvr4 +---|(MAC-VRF3) |
+------------+ +------------+
Figure-2: Modeling EVPN PEs as MVPN PEs Figure-2: Modeling EVPN PEs as MVPN PEs
Although modeling an EVPN PE as a MVPN PE, conceptually simplifies Although modeling an EVPN PE as a MVPN PE, conceptually simplifies
the operation to that of a solution based on MVPN, the following the operation to that of a solution based on MVPN, the following
operational aspects of EVPN need to be factored in when considering operational aspects of EVPN need to be factored in when considering
seamless integration between EVPN and MVPN PEs. seamless integration between EVPN and MVPN PEs.
1) Unicast route advertisements for IP multicast source o Unicast route advertisements for IP multicast source
2) Multi-homing of IP multicast sources and receivers
3) Mobility for Tenant's sources and receivers o Multi-homing of IP multicast sources and receivers
4) non-IP multicast traffic handling o Mobility for Tenant's sources and receivers
o non-IP multicast traffic handling
6.2. Unicast Route Advertisements for IP multicast Source 6.2. Unicast Route Advertisements for IP multicast Source
When an IP multicast source is attached to an EVPN PE, the unicast When an IP multicast source is attached to an EVPN PE, the unicast
route for that IP multicast source needs to be advertised. When the route for that IP multicast source needs to be advertised. When the
source is attached to a Single-Active multi-homed ES, then the EVPN source is attached to a Single-Active multi-homed ES, then the EVPN
DF PE is the PE that advertises a unicast route corresponding to the DF PE is the PE that advertises a unicast route corresponding to the
source IP address with VRF Route Import extended community which in source IP address with VRF Route Import extended community which in
turn is used as the Route Target for Join (S,G) messages sent toward turn is used as the Route Target for Join (S,G) messages sent toward
the source PE by the remote PEs. The EVPN PE advertises this unicast the source PE by the remote PEs. The EVPN PE advertises this unicast
route using EVPN route type 2 and IPVPN unicast route along with VRF route using EVPN route type 2 and IPVPN unicast route along with VRF
Route Import extended community. EVPN route type 2 is advertised with Route Import extended community. EVPN route type 2 is advertised
the Route Targets corresponding to both IP-VRF and MAC-VRF/BT; with the Route Targets corresponding to both IP-VRF and MAC-VRF/BT;
whereas, IPVPN unicast route is advertised with RT corresponding to whereas, IPVPN unicast route is advertised with RT corresponding to
the IP-VRF. When unicast routes are advertised by MVPN PEs, they are the IP-VRF. When unicast routes are advertised by MVPN PEs, they are
advertised using IPVPN unicast route along with VRF Route Import advertised using IPVPN unicast route along with VRF Route Import
extended community per [RFC6514]. extended community per [RFC6514].
When the source is attached to an All-Active multi-homed ES, then the When the source is attached to an All-Active multi-homed ES, then the
PE that learns the source advertises the unicast route for that PE that learns the source advertises the unicast route for that
source using EVPN route type 2 and IPVPN unicast route along with VRF source using EVPN route type 2 and IPVPN unicast route along with VRF
Route Import extended community. EVPN route type 2 is advertised with Route Import extended community. EVPN route type 2 is advertised
the Route Targets corresponding to both IP-VRF and MAC-VRF/BT; with the Route Targets corresponding to both IP-VRF and MAC-VRF/BT;
whereas, IPVPN unicast route is advertised with RT corresponding to whereas, IPVPN unicast route is advertised with RT corresponding to
the IP-VRF. When the other multi-homing EVPN PEs for that ES receive the IP-VRF. When the other multi-homing EVPN PEs for that ES receive
this unicast EVPN route, they import the route and check to see if this unicast EVPN route, they import the route and check to see if
they have learned the route locally for that ES, if they have, then they have learned the route locally for that ES, if they have, then
they do nothing. But if they have not, then they add the IP and MAC they do nothing. But if they have not, then they add the IP and MAC
addresses to their IP-VRF and MAC-VRF/BT tables respectively with the addresses to their IP-VRF and MAC-VRF/BT tables respectively with the
local interface corresponding to that ES as the corresponding route local interface corresponding to that ES as the corresponding route
adjacency. Furthermore, these PEs advertise an IPVPN unicast route adjacency. Furthermore, these PEs advertise an IPVPN unicast route
along with VRF Route Import extended community and Route Target along with VRF Route Import extended community and Route Target
corresponding to IP-VRF to other remote PEs for that MVPN. Therefore, corresponding to IP-VRF to other remote PEs for that MVPN.
the remote PEs learn the unicast route corresponding to the source Therefore, the remote PEs learn the unicast route corresponding to
from all multi-homing PEs associated with that All- Active Ethernet the source from all multi-homing PEs associated with that All- Active
Segment even though one of the multi-homing PEs may only have Ethernet Segment even though one of the multi-homing PEs may only
directly learned the IP address of the source. have directly learned the IP address of the source.
EVPN-PEs advertise unicast routes as host routes using EVPN route EVPN-PEs advertise unicast routes as host routes using EVPN route
type 2 for sources that are directly attached to a tenant BD that has type 2 for sources that are directly attached to a tenant BD that has
been extended in the EVPN fabric. EVPN-PE may summarize sources (IP been extended in the EVPN fabric. EVPN-PE may summarize sources (IP
networks) behind a router that are attached to EVPN-PE or sources networks) behind a router that are attached to EVPN-PE or sources
that are connected to a BD, which is not extended across EVPN fabric that are connected to a BD, which is not extended across EVPN fabric
and advertises those routes with EVPN route type 5. EVPN host-routes and advertises those routes with EVPN route type 5. EVPN host-routes
are advertised as IPVPN host-routes to MVPN-PEs only incase of are advertised as IPVPN host-routes to MVPN-PEs only incase of
seamless interop mode. seamless interop mode.
Section 6.6 discusses connecting EVPN and MVPN networks with gateway Section 6.6 discusses connecting EVPN and MVPN networks with gateway
model. Section 9 extends seamless interop procedures to EVPN only model. Section 9 extends seamless interop procedures to EVPN only
fabrics as an IRB solution for multicast. fabrics as an IRB solution for multicast.
EVPN-PEs only need to advertise unicast routes using EVPN route-type EVPN-PEs only need to advertise unicast routes using EVPN route-type
2 or route-type 5 and don't need to advertise IPVPN routes within 2 or route-type 5 and don't need to advertise IPVPN routes within
EVPN only fabric. No L3VPN provisioning is needed between EVPN-PEs. EVPN only fabric. No L3VPN provisioning is needed between EVPN-PEs.
In gateway model, EVPN-PE advertises unicast routes as IPVPN routes In gateway model, EVPN-PE advertises unicast routes as IPVPN routes
along with VRI extended community for all multicast sources attached along with VRI extended community for all multicast sources attached
behind EVPN-PEs. All IPVPN routes SHOULD be summarized while behind EVPN-PEs. All IPVPN routes SHOULD be summarized while
adverting to MVPN-PEs. adverting to MVPN-PEs.
6.3. Multi-homing of IP Multicast Source and Receivers 6.3. Multi-homing of IP Multicast Source and Receivers
EVPN [RFC7432] has extensive multi-homing capabilities that allows EVPN [RFC7432] has extensive multi-homing capabilities that allows
TSes to be multi-homed to two or more EVPN PEs in Single-Active or TSes to be multi-homed to two or more EVPN PEs in Single-Active or
All-Active mode. In Single-Active mode, only one of the multi-homing All-Active mode. In Single-Active mode, only one of the multi-homing
EVPN PEs can receive/transmit traffic for a given subnet (a given BD) EVPN PEs can receive/transmit traffic for a given subnet (a given BD)
for that multi-homed Ethernet Segment (ES). In All-Active mode, any for that multi-homed Ethernet Segment (ES). In All-Active mode, any
of the multi-homing EVPN PEs can receive/transmit unicast traffic but of the multi-homing EVPN PEs can receive/transmit unicast traffic but
only one of them (the DF PE) can send BUM traffic to the multi-homed only one of them (the DF PE) can send BUM traffic to the multi-homed
ES for a given subnet. ES for a given subnet.
The multi-homing mode (Single-Active versus All-Active) of a TS The multi-homing mode (Single-Active versus All-Active) of a TS
source can impact the MVPN procedures as described below. source can impact the MVPN procedures as described below.
6.3.1. Single-Active Multi-Homing 6.3.1. Single-Active Multi-Homing
When a TS source reside on an ES that is multi-homed to two or more When a TS source reside on an ES that is multi-homed to two or more
EVPN PEs operating in Single-Active mode, only one of the EVPN PEs EVPN PEs operating in Single-Active mode, only one of the EVPN PEs
can be active for the source subnet on that ES. Therefore, only one can be active for the source subnet on that ES. Therefore, only one
of the multi-homing PE learns the unicast route of the TS source and of the multi-homing PE learns the unicast route of the TS source and
advertises that using EVPN and IPVPN to other PEs as described advertises that using EVPN and IPVPN to other PEs as described
previously. previously.
A downstream PE that receives a Join/Prune message from a TS A downstream PE that receives a Join/Prune message from a TS host/
host/router, selects a Upstream Multicast Hop (UMH) which is the router, selects a Upstream Multicast Hop (UMH) which is the upstream
upstream PE that receives the IP multicast flow in case of Singe- PE that receives the IP multicast flow in case of Singe- Active
Active multi-homing. An IP multicast flow belongs to either a source- multi-homing. An IP multicast flow belongs to either a source-
specific tree (S,G) or to a shared tree (*,G). We use the notation specific tree (S,G) or to a shared tree (*,G). We use the notation
(X,G) to refer to either (S,G) or (*,G); where X refers to S in case (X,G) to refer to either (S,G) or (*,G); where X refers to S in case
of (S,G) and X refers to the Rendezvous Point (RP) for G in case of of (S,G) and X refers to the Rendezvous Point (RP) for G in case of
(*,G). Since the active PE (which is also the UMH PE) has advertised (*,G). Since the active PE (which is also the UMH PE) has advertised
unicast route for X along with the VRF Route Import EC, the unicast route for X along with the VRF Route Import EC, the
downstream PEs selects the UMH without any ambiguity based on MVPN downstream PEs selects the UMH without any ambiguity based on MVPN
procedures described in section 5.1 of [RFC6513]. Any of the three procedures described in section 5.1 of [RFC6513]. Any of the three
algorithms described in that section works fine. algorithms described in that section works fine.
The multi-homing PE that receives the IP multicast flow on its local The multi-homing PE that receives the IP multicast flow on its local
AC, performs the following tasks: AC, performs the following tasks:
- L2 switches the multicast traffic in its BT associated with the - L2 switches the multicast traffic in its BT associated with the
local AC over which it received the flow if there are any interested local AC over which it received the flow if there are any interested
receivers for that subnet. receivers for that subnet.
- L3 routes the multicast traffic to other BTs for other subnets if - L3 routes the multicast traffic to other BTs for other subnets if
there are any interested receivers for those subnets. there are any interested receivers for those subnets.
- L3 routes the multicast traffic to other PEs per MVPN procedures. - L3 routes the multicast traffic to other PEs per MVPN procedures.
The multicast traffic can be sent on Inclusive, Selective, or The multicast traffic can be sent on Inclusive, Selective, or
Aggregate-Selective tree. Regardless what type of tree is used, only Aggregate-Selective tree. Regardless what type of tree is used, only
a single copy of the multicast traffic is received by the downstream a single copy of the multicast traffic is received by the downstream
PEs and the multicast traffic is forwarded optimally from the PEs and the multicast traffic is forwarded optimally from the
upstream PE to the downstream PEs. upstream PE to the downstream PEs.
6.3.2. All-Active Multi-Homing 6.3.2. All-Active Multi-Homing
When a TS source reside on an ES that is multi-homed to two or more When a TS source reside on an ES that is multi-homed to two or more
EVPN PEs operating in All-Active mode, then any of the multi-homing EVPN PEs operating in All-Active mode, then any of the multi-homing
PEs can learn the TS source's unicast route; however, that PE may not PEs can learn the TS source's unicast route; however, that PE may not
be the same PE that receives the IP multicast flow. Therefore, the be the same PE that receives the IP multicast flow. Therefore, the
procedures for Single-Active Multi-homing need to be augmented for procedures for Single-Active Multi-homing need to be augmented for
All-Active scenario as below. All-Active scenario as below.
The multi-homing EVPN PE that receives the IP multicast flow on its The multi-homing EVPN PE that receives the IP multicast flow on its
local AC, needs to do the following task in additions to the ones local AC, needs to do the following task in additions to the ones
listed in the previous section for Single-Active multi-homing: L2 listed in the previous section for Single-Active multi-homing: L2
switch the multicast traffic to other multi-homing EVPN PEs for that switch the multicast traffic to other multi-homing EVPN PEs for that
ES via a multicast tunnel which it is called intra-ES tunnel. There ES via a multicast tunnel which it is called intra-ES tunnel. There
will be a dedicated tunnel for this purpose which is different from will be a dedicated tunnel for this purpose which is different from
inter-subnet overlay tree/tunnel setup by MVPN procedures. inter-subnet overlay tree/tunnel setup by MVPN procedures.
When the multi-homing EVPN PEs receive the IP multicast flow via this When the multi-homing EVPN PEs receive the IP multicast flow via this
tunnel, they treat it as if they receive the flow via their local tunnel, they treat it as if they receive the flow via their local ACs
ACs and thus perform the tasks mentioned in the previous section for and thus perform the tasks mentioned in the previous section for
Single-Active multi-homing. The tunnel type for this intra-ES tunnel Single-Active multi-homing. The tunnel type for this intra-ES tunnel
can be any of the supported tunnel types such as ingress-replication, can be any of the supported tunnel types such as ingress-replication,
P2MP tunnel, BIER, and Assisted Replication; however, given that vast P2MP tunnel, BIER, and Assisted Replication; however, given that vast
majority of multi-homing ESes are just dual-homing, a simple ingress majority of multi-homing ESes are just dual-homing, a simple ingress
replication tunnel can serve well. For a given ES, since multicast replication tunnel can serve well. For a given ES, since multicast
traffic that is locally received by one multi-homing PE is sent to traffic that is locally received by one multi-homing PE is sent to
other multi-homing PEs via this intra-ES tunnel, there is no need for other multi-homing PEs via this intra-ES tunnel, there is no need for
sending the multicast tunnel via MVPN tunnel to these multi-homing sending the multicast tunnel via MVPN tunnel to these multi-homing
PEs - i.e., MVPN multicast tunnels are used only for remote EVPN and PEs - i.e., MVPN multicast tunnels are used only for remote EVPN and
MVPN PEs. Multicast traffic sent over this intra-ES tunnel to other MVPN PEs. Multicast traffic sent over this intra-ES tunnel to other
multi-homing PEs (only one other in case of dual-homing) for a given multi-homing PEs (only one other in case of dual-homing) for a given
ES can be either fixed or on demand basis. If on-demand basis, then ES can be either fixed or on demand basis. If on-demand basis, then
one of the other multi-homing PEs that is selected as a UMH upon one of the other multi-homing PEs that is selected as a UMH upon
receiving a join message from a downstream PE, sends a request to receiving a join message from a downstream PE, sends a request to
receive this multicast flow from the source multi-homing PE over the receive this multicast flow from the source multi-homing PE over the
special intra-ES tunnel. special intra-ES tunnel.
By feeding IP multicast flow received on one of the EVPN multi-homing By feeding IP multicast flow received on one of the EVPN multi-homing
PEs to the interested EVPN PEs in the same multi-homing group, we PEs to the interested EVPN PEs in the same multi-homing group, we
have essentially enabled all the EVPN PEs in the multi-homing group have essentially enabled all the EVPN PEs in the multi-homing group
to serve as UMH for that IP multicast flow. Each of these UMH PEs to serve as UMH for that IP multicast flow. Each of these UMH PEs
advertises unicast route for X in (X,G) along with the VRF Route advertises unicast route for X in (X,G) along with the VRF Route
Import EC to all PEs for that MVPN instance. The downstream PEs build Import EC to all PEs for that MVPN instance. The downstream PEs
a candidate UMH set based on procedures described in section 5.1 of build a candidate UMH set based on procedures described in section
[RFC6513] and pick a UMH from the set. It should be noted that both 5.1 of [RFC6513] and pick a UMH from the set. It should be noted
the default UMH selection procedure based on highest UMH PE IP that both the default UMH selection procedure based on highest UMH PE
address and the UMH selection algorithm based on hash function IP address and the UMH selection algorithm based on hash function
specified in section 5.1.3 of [RFC6513] (which is also a MUST specified in section 5.1.3 of [RFC6513] (which is also a MUST
implement algorithm) result in the same UMH PE be selected by all implement algorithm) result in the same UMH PE be selected by all
downstream PEs running the same algorithm. However, in order to allow downstream PEs running the same algorithm. However, in order to
a form of "equal cost load balancing", the hash algorithm is allow a form of "equal cost load balancing", the hash algorithm is
recommended to be used among all EVPN and MVPN PEs. This hash recommended to be used among all EVPN and MVPN PEs. This hash
algorithm distributes UMH selection for different IP multicast flows algorithm distributes UMH selection for different IP multicast flows
among the multi-homing PEs for a given ES. among the multi-homing PEs for a given ES.
Since all downstream PEs (EVPN and MVPN) use the same hash-based Since all downstream PEs (EVPN and MVPN) use the same hash-based
algorithm for UMH determination, they all choose the same upstream PE algorithm for UMH determination, they all choose the same upstream PE
as their UMH for a given (X,G) flow and thus they all send their as their UMH for a given (X,G) flow and thus they all send their
(X,G) join message via BGP to the same upstream PE. This results in (X,G) join message via BGP to the same upstream PE. This results in
one of the multi-homing PEs to receive the join message and thus send one of the multi-homing PEs to receive the join message and thus send
the IP multicast flow for (X,G) over its associated overlay tree even the IP multicast flow for (X,G) over its associated overlay tree even
though all of the multi-homing PEs in the All-Active redundancy group though all of the multi-homing PEs in the All-Active redundancy group
have received the IP multicast flow (one of them directly via its have received the IP multicast flow (one of them directly via its
local AC and the rest indirectly via the associated intra-ES tunnel). local AC and the rest indirectly via the associated intra-ES tunnel).
Therefore, only a single copy of routed IP multicast flow is sent Therefore, only a single copy of routed IP multicast flow is sent
over the network regardless of overlay tree type supported by the PEs over the network regardless of overlay tree type supported by the PEs
- i.e., the overlay tree can be of type selective or aggregate - i.e., the overlay tree can be of type selective or aggregate
selective or inclusive tree. This gives the network operator the selective or inclusive tree. This gives the network operator the
maximum flexibility for choosing any overlay tree type that is maximum flexibility for choosing any overlay tree type that is
suitable for its network operation and still be able to deliver only suitable for its network operation and still be able to deliver only
a single copy of the IP multicast flows to the egress PEs. In other a single copy of the IP multicast flows to the egress PEs. In other
words, an egress PE only receives a single copy of the IP multicast words, an egress PE only receives a single copy of the IP multicast
flow over the network, because it either receives it via the EVPN flow over the network, because it either receives it via the EVPN
intra-ES tunnel or MVPN inter-subnet tunnel. Furthermore, if it intra-ES tunnel or MVPN inter-subnet tunnel. Furthermore, if it
receives it via MVPN inter-subnet tunnel, then only one of the multi- receives it via MVPN inter-subnet tunnel, then only one of the multi-
homing PEs associated with the source ES, sends the IP multicast homing PEs associated with the source ES, sends the IP multicast
traffic. traffic.
Since the network of interest for seamless interoperability between Since the network of interest for seamless interoperability between
EVPN and MVPN PEs is MPLS, the EVPN handling of BUM traffic for MPLS EVPN and MVPN PEs is MPLS, the EVPN handling of BUM traffic for MPLS
network needs to be considered. EVPN [RFC7432] uses ESI MPLS label network needs to be considered. EVPN [RFC7432] uses ESI MPLS label
for split-horizon filtering of Broadcast/Unknown unicast/multicast for split-horizon filtering of Broadcast/Unknown unicast/multicast
(BUM) traffic from an All-Active multi-homing Ethernet Segment to (BUM) traffic from an All-Active multi-homing Ethernet Segment to
ensure that BUM traffic doesn't get loop back to the same Ethernet ensure that BUM traffic doesn't get loop back to the same Ethernet
Segment that it came from. This split-horizon filtering mechanism Segment that it came from. This split-horizon filtering mechanism
applies as-is for multicast IRB scenario because of using the intra- applies as-is for multicast IRB scenario because of using the intra-
ES tunnel among multi-homing PEs. Since the multicast traffic ES tunnel among multi-homing PEs. Since the multicast traffic
received from a TS source on an All-Active ES by a multi-homing PE is received from a TS source on an All-Active ES by a multi-homing PE is
bridged to all other multi-homing PEs in that group, the standard bridged to all other multi-homing PEs in that group, the standard
EVPN split-horizon filtering described in [RFC7432] applies as-is. EVPN split-horizon filtering described in [RFC7432] applies as-is.
Split-horizon filtering for non-MPLS encapsulations such as VxLAN is Split-horizon filtering for non-MPLS encapsulations such as VxLAN is
described in section 9.2.2 that deals with a DC network that consists described in section 9.2.2 that deals with a DC network that consists
of only EVPN PEs. of only EVPN PEs.
6.4. Mobility for Tenant's Sources and Receivers 6.4. Mobility for Tenant's Sources and Receivers
When a tenant system (TS), source or receiver, is multi-homed behind When a tenant system (TS), source or receiver, is multi-homed behind
a group of multi-homing EVPN PEs, then TS mobility SHALL be supported a group of multi-homing EVPN PEs, then TS mobility SHALL be supported
among EVPN PEs. Furthermore, such TS mobility SHALL only cause an among EVPN PEs. Furthermore, such TS mobility SHALL only cause an
temporary disruption to the related multicast service among EVPN and temporary disruption to the related multicast service among EVPN and
MVPN PEs. If a source is moved from one EVPN PE to another one, then MVPN PEs. If a source is moved from one EVPN PE to another one, then
the EVPN mobility procedure SHALL discover this move and a new the EVPN mobility procedure SHALL discover this move and a new
unicast route advertisement (using both EVPN and IP-VPN routes) is unicast route advertisement (using both EVPN and IP-VPN routes) is
made by the EVPN PE where the source has moved to per section 6.3 made by the EVPN PE where the source has moved to per section 6.3
above and unicast route withdraw (for both EVPN and IP-VPN routes) is above and unicast route withdraw (for both EVPN and IP-VPN routes) is
performed by the EVPN PE where the source has moved from. performed by the EVPN PE where the source has moved from.
The move of a source results in disruption of the IP multicast flow The move of a source results in disruption of the IP multicast flow
for the corresponding (S,G) flow till the new unicast route for the corresponding (S,G) flow till the new unicast route
associated with the source is advertised by the new PE along with the associated with the source is advertised by the new PE along with the
VRF Route Import EC, the join messages sent by the egress PEs are VRF Route Import EC, the join messages sent by the egress PEs are
skipping to change at page 17, line 35 skipping to change at page 18, line 9
receiving that IP multicast flow. receiving that IP multicast flow.
The move of a receiver results in disruption of the IP multicast flow The move of a receiver results in disruption of the IP multicast flow
to that receiver only till the new PE for that receiver discovers the to that receiver only till the new PE for that receiver discovers the
source and joins the overlay tree for that flow. source and joins the overlay tree for that flow.
6.5. Intra-Subnet BUM Traffic Handling 6.5. Intra-Subnet BUM Traffic Handling
Link local IP multicast traffic consists IPv4 traffic with a Link local IP multicast traffic consists IPv4 traffic with a
destination address prefix of 224/8 and IPv6 traffic with a destination address prefix of 224/8 and IPv6 traffic with a
destination address prefix of FF02/16. Such IP multicast traffic as destination address prefix of FF02/16. Such IP multicast traffic as
well as non-IP multicast/broadcast traffic are sent per EVPN [RF7432] well as non-IP multicast/broadcast traffic are sent per EVPN
BUM procedures and does not get routed via IP-VRF for multicast [RFC7432] BUM procedures and does not get routed via IP-VRF for
addresses. So, such BUM traffic will be limited to a given EVI/VLAN multicast addresses. So, such BUM traffic will be limited to a given
(e.g., a give subnet); whereas, IP multicast traffic, will be locally EVI/VLAN (e.g., a give subnet); whereas, IP multicast traffic, will
L2 switched for local interfaces attached on the same subnet and will be locally L2 switched for local interfaces attached on the same
be routed for local interfaces attached on a different subnet or for subnet and will be routed for local interfaces attached on a
forwarding traffic to other EVPN PEs (refer to section 8 for data different subnet or for forwarding traffic to other EVPN PEs (refer
plane operation). to section 8 for data plane operation).
6.6 EVPN and MVPN interworking with gateway model 6.6. EVPN and MVPN interworking with gateway model
The procedures specified in this document offers optimal multicast The procedures specified in this document offers optimal multicast
forwarding within a data center and also enables seamless forwarding within a data center and also enables seamless
interoperability of multicast traffic between EVPN and MVPN networks, interoperability of multicast traffic between EVPN and MVPN networks,
when same tunnel types are used in the data plane. when same tunnel types are used in the data plane.
There are few other use cases in connecting MVPN networks in the EVPN There are few other use cases in connecting MVPN networks in the EVPN
fabric other than seamless interop model, where gateway model is used fabric other than seamless interop model, where gateway model is used
to interconnect both networks. to interconnect both networks.
Case1: All EVPN-PEs in the fabric can be made as MVPN exit points Case1: All EVPN-PEs in the fabric can be made as MVPN exit points
Case2: MVPN network can be attached behind a EVPN PE or subset of Case2: MVPN network can be attached behind a EVPN PE or subset of
EVPN-PEs EVPN-PEs
Case3: MVPN network (MVPN-PEs) which uses different tunnel model Case3: MVPN network (MVPN-PEs) which uses different tunnel model
can be directly attached to EVPN fabric. can be directly attached to EVPN fabric.
In gateway model, MVPN routes from one domain are terminated at the In gateway model, MVPN routes from one domain are terminated at the
gateway PE and re-originated for another domain. gateway PE and re-originated for another domain.
With use case 1 & 2, All PEs connected to an EVPN fabric can use one With use case 1 & 2, All PEs connected to an EVPN fabric can use one
data plane to send & receive traffic within the fabric/data center. data plane to send & receive traffic within the fabric/data center.
Also, IPVPN routes need not be advertised inside the fabric. Instead, Also, IPVPN routes need not be advertised inside the fabric.
PE where MVPN is terminated should advertise IPVPN as EVPN routes. Instead, PE where MVPN is terminated should advertise IPVPN as EVPN
routes.
With use case 3, Fabric will get two copies per multicast flow, if With use case 3, Fabric will get two copies per multicast flow, if
receivers exist both MVPN and EVPN networks. (Two different data receivers exist both MVPN and EVPN networks. (Two different data
planes are used to send the traffic in the fabric; one for EVPN planes are used to send the traffic in the fabric; one for EVPN
network and one for MVPN network). network and one for MVPN network).
7. Control Plane Operation 7. Control Plane Operation
In seamless interop between EVPN and MVPN PEs, the control plane may In seamless interop between EVPN and MVPN PEs, the control plane may
need to setup the following three types of multicast tunnels. The need to setup the following three types of multicast tunnels. The
first two are among EVPN PEs only but the third one is among EVPN and first two are among EVPN PEs only but the third one is among EVPN and
MVPN PEs. MVPN PEs.
1) Intra-ES IP multicast tunnel 1) Intra-ES IP multicast tunnel
2) Intra-subnet BUM tunnel 2) Intra-subnet BUM tunnel
3) Inter-subnet IP multicast tunnel 3) Inter-subnet IP multicast tunnel
7.1. Intra-ES/Intra-Subnet IP Multicast Tunnel 7.1. Intra-ES/Intra-Subnet IP Multicast Tunnel
As described in section 6.3.2, when a multicast source is sitting As described in section 6.3.2, when a multicast source is sitting
behind an All-Active ES, then an intra-subnet multicast tunnel is behind an All-Active ES, then an intra-subnet multicast tunnel is
needed among the multi-homing EVPN PEs for that ES to carry multicast needed among the multi-homing EVPN PEs for that ES to carry multicast
flow received by one of the multi-homing PEs to the other PEs in that flow received by one of the multi-homing PEs to the other PEs in that
ES. We refer to this multicast tunnel as Intra-ES/Intra-Subnet ES. We refer to this multicast tunnel as Intra-ES/Intra-Subnet
tunnel. Vast majority of All-Active multi-homing for TOR devices in tunnel. Vast majority of All-Active multi-homing for TOR devices in
DC networks are just dual-homing which means the multicast flow DC networks are just dual-homing which means the multicast flow
received by one of the dual-homing PE only needs to be sent to the received by one of the dual-homing PE only needs to be sent to the
other dual-homing PE. Therefore, a simple ingress replication tunnel other dual-homing PE. Therefore, a simple ingress replication tunnel
is all that is needed. In case of multi-homing to three or more EVPN is all that is needed. In case of multi-homing to three or more EVPN
PEs, then other tunnel types such as P2MP, MP2MP, BIER, and Assisted PEs, then other tunnel types such as P2MP, MP2MP, BIER, and Assisted
Replication can be considered. It should be noted that this intra-ES Replication can be considered. It should be noted that this intra-ES
tunnel is only needed for All-Active multi-homing and it is not tunnel is only needed for All-Active multi-homing and it is not
required for Single- Active multi-homing. required for Single- Active multi-homing.
The EVPN PEs belonging to a given All-Active ES discover each other The EVPN PEs belonging to a given All-Active ES discover each other
using EVPN Ethernet Segment route per procedures described in using EVPN Ethernet Segment route per procedures described in
[RFC7432]. These EVPN PEs perform DF election per [RFC7432], [EVPN- [RFC7432]. These EVPN PEs perform DF election per [RFC7432],
DF-Framework], or other DF election algorithms to decide who is a DF [I-D.ietf-bess-evpn-df-election-framework], or other DF election
for a given BD. If the BD belongs to a tenant that has IRB IP algorithms to decide who is a DF for a given BD. If the BD belongs
multicast enabled for it, then for fixed-mode, each PE sets up an to a tenant that has IRB IP multicast enabled for it, then for fixed-
intra-ES tunnel to forward IP multicast traffic received locally on mode, each PE sets up an intra-ES tunnel to forward IP multicast
that BD to other multi-homing PE(s) for that ES. Therefore, IP traffic received locally on that BD to other multi-homing PE(s) for
multicast traffic received via a local attachment circuit is sent on that ES. Therefore, IP multicast traffic received via a local
this tunnel and on the associated IRB interface for that BT and other attachment circuit is sent on this tunnel and on the associated IRB
local attachment circuits if there are interested receivers for them. interface for that BT and other local attachment circuits if there
The other multi-homing EVPN PEs treat this intra-ES tunnel just like are interested receivers for them. The other multi-homing EVPN PEs
their local ACs - i.e., the multicast traffic received over this treat this intra-ES tunnel just like their local ACs - i.e., the
tunnel is treated as if it is received via its local AC. Thus, the multicast traffic received over this tunnel is treated as if it is
multi-homing PEs cannot receive the same IP multicast flow from an received via its local AC. Thus, the multi-homing PEs cannot receive
MVPN tunnel (e.g., over an IRB interface for that BD) because between the same IP multicast flow from an MVPN tunnel (e.g., over an IRB
a source behind a local AC versus a source behind a remote PE, the PE interface for that BD) because between a source behind a local AC
always chooses its local AC. versus a source behind a remote PE, the PE always chooses its local
AC.
When ingress replication is used for intra-ES tunnel, every PE in the When ingress replication is used for intra-ES tunnel, every PE in the
All-Active multi-homing ES has all the information to setup these All-Active multi-homing ES has all the information to setup these
tunnels - i.e., a) each PE knows what are the other multi-homing PEs tunnels - i.e., a) each PE knows what are the other multi-homing PEs
for that ES via EVPN Ethernet Segment route and can use this for that ES via EVPN Ethernet Segment route and can use this
information to setup intra-ES/Intra-Subnet IP multicast tunnel among information to setup intra-ES/Intra-Subnet IP multicast tunnel among
themselves. themselves.
7.2. Intra-Subnet BUM Tunnel If a source exists behind inter-subnet tunnel, it is possible that
more than one multihomed PEs send MVPN join towards remote PE based
on incoming join on their local interfaces. When the traffic is
received on the inter-subnet tunnel, it is sent towards locally
attached receivers. Only DF sends traffic towards multihomed
ethernet segment. Traffic received on the inter-subnet tunnel,
should not be sent towards intra-ES tunnel.
7.2. Intra-Subnet BUM Tunnel
As the name implies, this tunnel is setup to carry BUM traffic for a As the name implies, this tunnel is setup to carry BUM traffic for a
given subnet/BD among EVNP PEs. In [RFC7432], this overlay tunnel is given subnet/BD among EVNP PEs. In [RFC7432] , this overlay tunnel
used for transmission of all BUM traffic including user IP multicast is used for transmission of all BUM traffic including user IP
traffic. However, for multicast traffic handling in EVPN-IRB PEs, multicast traffic. However, for multicast traffic handling in EVPN-
this tunnel is used for all broadcast, unknown-unicast, non-IP IRB PEs, this tunnel is used for all broadcast, unknown-unicast, non-
multicast traffic, and link-local IP multicast traffic - i.e., it is IP multicast traffic, and link-local IP multicast traffic - i.e., it
used for all BUM traffic except user IP multicast traffic. This is used for all BUM traffic except user IP multicast traffic. This
tunnel is setup using IMET route for a given EVI/BD. The composition tunnel is setup using IMET route for a given EVI/BD. The composition
and advertisement of IMET routes are exactly per [RFC7432]. It should and advertisement of IMET routes are exactly per [RFC7432] . It
be noted that when an EVPN All-Active multi-homing PE uses both this should be noted that when an EVPN All-Active multi-homing PE uses
tunnel as well as intra-ES tunnel, there SHALL be no duplication of both this tunnel as well as intra-ES tunnel, there SHALL be no
multicast traffic over the network because they carry different types duplication of multicast traffic over the network because they carry
of multicast traffic - i.e., intra-ES tunnel among multi-homing PEs different types of multicast traffic - i.e., intra-ES tunnel among
carries only user IP multicast traffic; whereas, intra-subnet BUM multi-homing PEs carries only user IP multicast traffic; whereas,
tunnel carries link-local IP multicast traffic and BUM traffic (w/ intra-subnet BUM tunnel carries link-local IP multicast traffic and
non-IP multicast). BUM traffic (w/ non-IP multicast).
7.3. Inter-Subnet IP Multicast Tunnel 7.3. Inter-Subnet IP Multicast Tunnel
As its name implies, this tunnel is setup to carry IP-only multicast As its name implies, this tunnel is setup to carry IP-only multicast
traffic for a given tenant across all its subnets (BDs) among EVPN traffic for a given tenant across all its subnets (BDs) among EVPN
and MVPN PEs. and MVPN PEs.
The following NLRIs from [RFC6514] is used for setting up this inter- The following NLRIs from [RFC6514] is used for setting up this inter-
subnet tunnel in the network. subnet tunnel in the network.
Intra-AS I-PMSI A-D route is used for the setup of default Intra-AS I-PMSI A-D route is used for the setup of default
underlay tunnel (also called inclusive tunnel) for a tenant IP- underlay tunnel (also called inclusive tunnel) for a tenant IP-
VRF. The tunnel attributes are indicated using PMSI attribute VRF. The tunnel attributes are indicated using PMSI attribute
with this route. with this route.
S-PMSI A-D route is used for the setup of Customer flow specific S-PMSI A-D route is used for the setup of Customer flow specific
underlay tunnels. This enables selective delivery of data to PEs underlay tunnels. This enables selective delivery of data to PEs
having active receivers and optimizes fabric bandwidth having active receivers and optimizes fabric bandwidth
utilization. The tunnel attributes are indicated using PMSI utilization. The tunnel attributes are indicated using PMSI
attribute with this route. attribute with this route.
Each EVPN PE supporting a specific MVPN instance discovers the set of Each EVPN PE supporting a specific MVPN instance discovers the set of
other PEs in its AS that are attached to sites of that MVPN using 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 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 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 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 [RFC6514]. After the discovery of PEs that are attached to sites of
the MVPN, an inclusive overlay tree (I-PMSI) can be setup for the MVPN, an inclusive overlay tree (I-PMSI) can be setup for
carrying tenant multicast flows for that MVPN; however, this is not a carrying tenant multicast flows for that MVPN; however, this is not a
requirement per [RFC6514] and it is possible to adopt a policy in requirement per [RFC6514] and it is possible to adopt a policy in
which all tenant flows are carried on S-PMSIs. which all tenant flows are carried on S-PMSIs.
An EVPN-IRB PE sends a user IP multicast flow to other EVPN and MVPN An EVPN-IRB PE sends a user IP multicast flow to other EVPN and MVPN
PEs over this inter-subnet tunnel that is instantiated using MVPN I- PEs over this inter-subnet tunnel that is instantiated using MVPN I-
PMSI or S-PMSI. This tunnel can be considered as being originated and PMSI or S-PMSI. This tunnel can be considered as being originated
terminated from/to among IP-VRFs of EVPN/MVPN PEs; whereas, intra- and terminated from/to among IP-VRFs of EVPN/MVPN PEs; whereas,
subnet tunnel is originated/terminated among MAC-VRFs of EVPN PEs. intra- subnet tunnel is originated/terminated among MAC-VRFs of EVPN
PEs.
7.4. IGMP Hosts as TSes 7.4. IGMP Hosts as TSes
If a tenant system which is an IGMP host is multi-homed to two or If a tenant system which is an IGMP host is multi-homed to two or
more EVPN PEs using All-Active multi-homing, then IGMP join and leave more EVPN PEs using All-Active multi-homing, then IGMP join and leave
messages are synchronized between these EVPN PEs using EVPN IGMP Join messages are synchronized between these EVPN PEs using EVPN IGMP Join
Synch route (route type 7) and EVPN IGMP Leave Synch route (route Synch route (route type 7) and EVPN IGMP Leave Synch route (route
type 8) per [IGMP-PROXY]. IGMP states are built in the corresponding type 8) per [I-D.ietf-bess-evpn-igmp-mld-proxy]. IGMP states are
BDs of the multi-homing EVPN PEs. In [IGMP-PROXY] the DF PE for that built in the corresponding BDs of the multi-homing EVPN PEs. In
BD originates an EVPN Selective Multicast Tag route (SMET route) [I-D.ietf-bess-evpn-igmp-mld-proxy] the DF PE for that BD originates
route to other EVPN PEs. However, in here there is no need to use an EVPN Selective Multicast Tag route (SMET route) route to other
SMET because the IGMP messages are terminated by the EVPN-IRB PE and EVPN PEs. However, in here there is no need to use SMET because the
tenant (*,G) or (S,G) join messages are sent via MVPN Shared Tree IGMP messages are terminated by the EVPN-IRB PE and tenant (*,G) or
Join route (route type 6) or Source Tree Join route (route type 7) (S,G) join messages are sent via MVPN Shared Tree Join route (route
respectively of MCAST-VPN NLRI per [RFC6514]. In case of a network type 6) or Source Tree Join route (route type 7) respectively of
with only IGMP hosts, the preferred mode of operation is that of MCAST-VPN NLRI per [RFC6514]. In case of a network with only IGMP
Shortest Path Tree(SPT) per section 14 of [RFC6514]. This mode is hosts, the preferred mode of operation is that of Shortest Path
only supported for PIM-SM and avoids the RP configuration overhead. Tree(SPT) per section 14 of [RFC6514]. This mode is only supported
Such mode is chosen by provisioning/ configuration. for PIM-SM and avoids the RP configuration overhead. Such mode is
chosen by provisioning/ configuration.
7.5. TS PIM Routers 7.5. TS PIM Routers
Just like a MVPN PE, an EVPN PE runs a separate tenant multicast Just like a MVPN PE, an EVPN PE runs a separate tenant multicast
routing instance (VPN-specific) per MVPN instance and the following routing instance (VPN-specific) per MVPN instance and the following
tenant multicast routing instances are supported: tenant multicast routing instances are supported:
- PIM Sparse Mode (PIM-SM) with the ASM service model - PIM Sparse Mode (PIM-SM) with the ASM service model
- PIM Sparse Mode with the SSM service model - PIM Sparse Mode with the SSM service model
- PIM Bidirectional Mode (BIDIR-PIM), which uses bidirectional - PIM Bidirectional Mode (BIDIR-PIM), which uses bidirectional
tenant-trees to support the ASM service model tenant-trees to support the ASM service model
A given tenant's PIM join messages for (*,G) or (S, G) are processed A given tenant's PIM join messages for (*,G) or (S, G) are processed
by the corresponding tenant multicast routing protocol and they are by the corresponding tenant multicast routing protocol and they are
advertised over MPLS/IP network using Shared Tree Join route (route advertised over MPLS/IP network using Shared Tree Join route (route
type 6) and Source Tree Join route (route type 7) respectively of type 6) and Source Tree Join route (route type 7) respectively of
MCAST-VPN NLRI per [RFC6514]. MCAST-VPN NLRI per [RFC6514].
8 Data Plane Operation 8. Data Plane Operation
When an EVPN-IRB PE receives an IGMP/MLD join message over one of its 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 Attachment Circuits (ACs), it adds that AC to its Layer-2 (L2) OIF
list. This L2 OIF list is associated with the MAC-VRF/BT list. This L2 OIF list is associated with the MAC-VRF/BT
corresponding to the subnet of the tenant device that sent the corresponding to the subnet of the tenant device that sent the IGMP/
IGMP/MLD join. Therefore, tenant (S,G) or (*,G) forwarding entries MLD join. Therefore, tenant (S,G) or (*,G) forwarding entries are
are created/updated for the corresponding MAC-VRF/BT based on these created/updated for the corresponding MAC-VRF/BT based on these
source and group IP addresses. Furthermore, the IGMP/MLD join message source and group IP addresses. Furthermore, the IGMP/MLD join
is propagated over the corresponding IRB interface and it is message is propagated over the corresponding IRB interface and it is
processed by the tenant multicast routing instance which creates the processed by the tenant multicast routing instance which creates the
corresponding tenant (S,G) or (*,G) Layer-3 (L3) forwarding entries. 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 It adds this IRB interface to the L3 OIF list. An IRB is removed as
L3 OIF when all L2 tenant (S,G) or (*,G) forwarding states is removed a L3 OIF when all L2 tenant (S,G) or (*,G) forwarding states is
for the MAC-VRF/BT associated with that IRB. Furthermore, tenant removed for the MAC-VRF/BT associated with that IRB. Furthermore,
(S,G) or (*,G) L3 forwarding state is removed when all of its L3 OIFs tenant (S,G) or (*,G) L3 forwarding state is removed when all of its
are removed - i.e., all the IRB and L3 interfaces associated with L3 OIFs are removed - i.e., all the IRB and L3 interfaces associated
that tenant (S,G) or (*,G) are removed. with that tenant (S,G) or (*,G) are removed.
When an EVPN PE receives IP multicast traffic from one of its AC, if When an EVPN PE receives IP multicast traffic from one of its AC, if
it has any attached receivers for that subnet, it performs L2 it has any attached receivers for that subnet, it performs L2
switching of the intra-subnet traffic within the BT attached to that switching of the intra-subnet traffic within the BT attached to that
AC. If the multicast flow is received over an AC that belongs to an AC. If the multicast flow is received over an AC that belongs to an
All-Active ES, then the multicast flow is also sent over the intra- All-Active ES, then the multicast flow is also sent over the intra-
ES/Intra-Subnet tunnel among multi-homing PEs. The EVPN PE then sends ES/Intra-Subnet tunnel among multi-homing PEs. The EVPN PE then
the multicast traffic over the corresponding IRB interface. The sends the multicast traffic over the corresponding IRB interface.
multicast traffic then gets routed in the corresponding IP-VRF and it The multicast traffic then gets routed in the corresponding IP-VRF
gets forwarded to interfaces in the L3 OIF list which can include and it gets forwarded to interfaces in the L3 OIF list which can
other IRB interfaces, other L3 interfaces directly connected to TSes, include other IRB interfaces, other L3 interfaces directly connected
and the MVPN Inter-Subnet tunnel which is instantiated by an I-PMSI to TSes, and the MVPN Inter-Subnet tunnel which is instantiated by an
or S-PMSI tunnel. When the multicast packet is routed within the IP- I-PMSI or S-PMSI tunnel. When the multicast packet is routed within
VRF of the EVPN PE, its Ethernet header is stripped and its TTL gets the IP- VRF of the EVPN PE, its Ethernet header is stripped and its
decremented as the result of this IP routing. When the multicast TTL gets decremented as the result of this IP routing. When the
traffic is received on an IRB interface by the BT corresponding to multicast traffic is received on an IRB interface by the BT
that interface, it gets L2 switched and sent over ACs that belong to corresponding to that interface, it gets L2 switched and sent over
the L2 OIF list. ACs that belong to the L2 OIF list.
8.1 Intra-Subnet L2 Switching 8.1. Intra-Subnet L2 Switching
Rcvr1 in Figure 1 is connected to PE1 in MAC-VRF1 (same as Src1) and 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 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 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 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 known via ARP or similar procedures. Rcvr1 will get a locally
bridged copy of multicast traffic from Src1. Rcvr3 is also connected 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 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 recorded at PE2. PE2 will also form routing entry and RPF will be
assumed as Tenant Tunnel "Tenant1" formed beforehand using MVPN assumed as Tenant Tunnel "Tenant1" formed beforehand using MVPN
procedures. Also this would cause multicast control plane to procedures. Also this would cause multicast control plane to
initiate a BGP MCAST-VPN type 7 route which would include VRI for PE1 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 and hence be accepted on PE1. PE1 will include Tenant1 tunnel as
Outgoing Interface (OIF) in the routing entry. Now, since it has Outgoing Interface (OIF) in the routing entry. Now, since it has
knowledge of remote receivers via MVPN control plane it will knowledge of remote receivers via MVPN control plane it will
encapsulate original multicast traffic in Tenant1 tunnel towards encapsulate original multicast traffic in Tenant1 tunnel towards
core. core.
8.2 Inter-Subnet L3 Routing 8.2. Inter-Subnet L3 Routing
Rcvr2 in Figure 1 is connected to PE1 in MAC-VRF2 and hence PE1 will Rcvr2 in Figure 1 is connected to PE1 in MAC-VRF2 and hence PE1 will
record its membership in MAC-VRF2. Since MAC-VRF2 is enabled with 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, IRB, it gets added as another OIF to routing entry formed for (C-S,
C-G). Rcvr2 and Rcvr4 are also in different MAC-VRFs than multicast C-G). Rcvr2 and Rcvr4 are also in different MAC-VRFs than multicast
speaker Src1 and hence need Inter-subnet forwarding. PE2 will form speaker Src1 and hence need Inter-subnet forwarding. PE2 will form
local bridging entry in MAC-VRF2 due to IGMP joins received from local bridging entry in MAC-VRF2 due to IGMP joins received from
Rcvr3 and Rcvr4 respectively. PE2 now adds another OIF 'MAC-VRF2' to Rcvr3 and Rcvr4 respectively. PE2 now adds another OIF 'MAC-VRF2' to
its existing routing entry. But there is no change in control plane its existing routing entry. But there is no change in control plane
states since its already sent MVPN route and no further signaling is 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 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 treated as routing OIF and hence MAC header gets modified as per
normal procedures for routing. PE3 forms routing entry very similar 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 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 locally but still can receive the multicast data traffic over Tenant1
tunnel formed due to MVPN procedures tunnel formed due to MVPN procedures
9. DCs with only EVPN PEs 9. DCs with only EVPN PEs
As mentioned earlier, the proposed solution can be used as a routed As mentioned earlier, the proposed solution can be used as a routed
multicast solution in data center networks with only EVPN PEs (e.g., multicast solution in data center networks with only EVPN PEs (e.g.,
routed multicast VPN only among EVPN PEs). It should be noted that routed multicast VPN only among EVPN PEs). It should be noted that
the scope of intra-subnet forwarding for the solution described in the scope of intra-subnet forwarding for the solution described in
this document, is limited to a single EVPN PE for Single-Active this document, is limited to a single EVPN PE for Single-Active
multi-homing and to multi-homing PEs for All-Active multi-homing. In multi-homing and to multi-homing PEs for All-Active multi-homing. In
other words, the IP multicast traffic that needs to be forwarded from other words, the IP multicast traffic that needs to be forwarded from
the source PE to remote PEs is routed to remote PEs regardless of the source PE to remote PEs is routed to remote PEs regardless of
whether the traffic is intra-subnet or inter-subnet. As the result, 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 the TTL value for intra-subnet traffic that spans across two or more
PEs get decremented. PEs get decremented.
However, if there are applications that require intra-subnet However, if there are applications that require intra-subnet
multicast traffic to be L2 forwarded, Section 11 discusses some multicast traffic to be L2 forwarded, Section 11 discusses some
options to support applications having TTL value 1. The procedure options to support applications having TTL value 1. The procedure
discussed in Section 11 may be used to support applications that discussed in Section 11 may be used to support applications that
require intra-subnet multicast traffic to be L2 forwarded. require intra-subnet multicast traffic to be L2 forwarded.
9.1. Setup of overlay multicast delivery 9.1. Setup of overlay multicast delivery
It must be emphasized that this solution poses no restriction on the 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 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 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 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 per the tenant multicast source and the IP-VRF in compliance with the
procedures in [RFC6514], using the incoming EVPN route type 2 or 5 procedures in [RFC6514], using the incoming EVPN route type 2 or 5
NLRI per [RFC7432]. NLRI per [RFC7432].
The VRF Route Import (VRI) extended community that is carried with The VRF Route Import (VRI) extended community that is carried with
the IP-VPN routes in [RFC6514] MUST be carried with the EVPN unicast the IP-VPN routes in [RFC6514] MUST be carried with the EVPN unicast
routes when these routes are used. The construction and processing of routes when these routes are used. The construction and processing
the VRI are consistent with [RFC6514]. The VRI MUST uniquely identify of the VRI are consistent with [RFC6514]. The VRI MUST uniquely
the PE which is advertising a multicast source and the IP-VRF it identify the PE which is advertising a multicast source and the IP-
resides in. VRF it resides in.
VRI is constructed as following: VRI is constructed as following:
- The 4-octet Global Administrator field MUST be set to an IP - The 4-octet Global Administrator field MUST be set to an IP
address of the PE. This address SHOULD be common for all the 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 IP-VRFs on the PE (e.g., this address may be the PE's loopback
address or VTEP address). address or VTEP address).
- The 2-octet Local Administrator field associated with a given - The 2-octet Local Administrator field associated with a given
IP-VRF contains a number that uniquely identifies that IP-VRF IP-VRF contains a number that uniquely identifies that IP-VRF
within the PE that contains the IP-VRF. within the PE that contains the IP-VRF.
EVPN PE MUST have Route Target Extended Community to import/export EVPN PE MUST have Route Target Extended Community to import/export
MVPN routes. In data center environment, it is desirable to have this MVPN routes. In data center environment, it is desirable to have
RT configured using auto-generated method than static configuration. this RT configured using auto-generated method than static
configuration.
The following is one recommended model to auto-generate MVPN RT: The following is one recommended model to auto-generate MVPN RT:
- The Global Administrator field of the MVPN RT MAY be set - The Global Administrator field of the MVPN RT MAY be set
to BGP AS Number. to BGP AS Number.
- The Local Administrator field of the MVPN RT MAY be set to - The Local Administrator field of the MVPN RT MAY be set to
the VNI associated with the tenant VRF. the VNI associated with the tenant VRF.
Every PE which detects a local receiver via a local IGMP join or a 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 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- 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 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 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 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 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. be locally routed/bridged to the receiver as detailed in section 6.2.
The VRI received with EVPN route type 2 or 5 NLRI from source PE will The VRI received with EVPN route type 2 or 5 NLRI from source PE will
be appended as an export route-target extended community. More be appended as an export route-target extended community. More
details about handling of various types of local receivers are in details about handling of various types of local receivers are in
section 10. The PE which has advertised the unicast route with VRI, 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 will import the incoming MCAST-VPN NLRI in the IP-VRF with the same
import route-target extended-community and other PEs SHOULD ignore import route-target extended-community and other PEs SHOULD ignore
it. Following such procedure the source PE learns about the existence it. Following such procedure the source PE learns about the
of at least one remote receiver in the tenant overlay and programs existence of at least one remote receiver in the tenant overlay and
data plane accordingly so that a single copy of multicast data is programs data plane accordingly so that a single copy of multicast
forwarded into the fabric using tenant VRF tunnel. data is forwarded into the fabric using tenant VRF tunnel.
If the multicast source is unknown (overlay ASM mode), the MCAST-VPN 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 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 overlay Rendezvous Point (RP) by appending the received RP VRI as an
export route-target extended community. Every PE which detects a export route-target extended community. Every PE which detects a
local source, registers with its RP PE. That is how the RP learns 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 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 overlay RP PE receives either the first remote (C-RP,C-G) join or a
local IGMP/PIM join, it will trigger an MCAST-VPN route type 7 (C- local IGMP/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 S,C-G) towards the actual source PE for which it has received PIM
register message in full compliance with regular PIM procedures. This register message in full compliance with regular PIM procedures.
involves the source PE to advertise the MCAST-VPN Source Active A-D This involves the source PE to advertise the MCAST-VPN Source Active
route (MCAST-VPN route-type 5) towards all PEs. The Source Active A- A-D route (MCAST-VPN route-type 5) towards all PEs. The Source
D route is used to inform all PEs in a given MVPN about the active Active A- D route is used to inform all PEs in a given MVPN about the
multicast source for switching from RPT to SPT when MVPNs use tenant active multicast source for switching from RPT to SPT when MVPNs use
RP-shared trees (i.e., rooted at tenant's RP) per section 13 of tenant RP-shared trees (i.e., rooted at tenant's RP) per section 13
[RFC6514]. This is done in order to choose a single forwarder PE and of [RFC6514]. This is done in order to choose a single forwarder PE
to suppress receiving duplicate traffic. In such scenarios, the and to suppress receiving duplicate traffic. In such scenarios, the
active multicast source is used by the receiver PEs to join the SPT active multicast source is used by the receiver PEs to join the SPT
if they have not received tenant (S,G) joins and by the RPT PEs to if they have not received tenant (S,G) joins and by the RPT PEs to
prune off the tenant (S,G) state from the RPT. The Source Active A-D prune off the tenant (S,G) state from the RPT. The Source Active A-D
route is also used for MVPN scenarios without tenant RP-shared trees. route is also used for MVPN scenarios without tenant RP-shared trees.
In such scenarios, the receiver PEs with tenant (*,G) states use the In such scenarios, the receiver PEs with tenant (*,G) states use the
Source Active A-D route to know which upstream PEs with sources Source Active A-D route to know which upstream PEs with sources
behind them to join per section 14 of [RFC6514] - i.e., to suppress behind them to join per section 14 of [RFC6514] - i.e., to suppress
joining Overlay shared tree. joining Overlay shared tree.
9.2. Handling of different encapsulations 9.2. Handling of different encapsulations
Just as in [RFC6514] the MVPN I-PMSI and S-PMSI A-D routes are used Just as in [RFC6514] the MVPN I-PMSI and S-PMSI A-D routes are used
to form the overlay multicast tunnels and signal the tunnel type to form the overlay multicast tunnels and signal the tunnel type
using the P-Multicast Service Interface Tunnel (PMSI Tunnel) using the P-Multicast Service Interface Tunnel (PMSI Tunnel)
attribute. attribute.
9.2.1. MPLS Encapsulation 9.2.1. MPLS Encapsulation
The [RFC6514] assumes MPLS/IP core and there is no modification to The [RFC6514] assumes MPLS/IP core and there is no modification to
the signaling procedures and encoding for PMSI tunnel formation the signaling procedures and encoding for PMSI tunnel formation
therein. Also, there is no need for a gateway to inter-operate with therein. Also, there is no need for a gateway to inter-operate with
non-EVPN PEs supporting [RFC6514] based MVPN over IP/MPLS. non-EVPN PEs supporting [RFC6514] based MVPN over IP/MPLS.
9.2.2 VxLAN Encapsulation 9.2.2. VxLAN Encapsulation
In order to signal VXLAN, the corresponding BGP encapsulation In order to signal VXLAN, the corresponding BGP encapsulation
extended community [TUNNEL-ENCAP] SHOULD be appended to the MVPN I- extended community [I-D.ietf-idr-tunnel-encaps] SHOULD be appended to
PMSI and S-PMSI A-D routes. The MPLS label in the PMSI Tunnel the MVPN I- PMSI and S-PMSI A-D routes. The MPLS label in the PMSI
Attribute MUST be the Virtual Network Identifier (VNI) associated Tunnel Attribute MUST be the Virtual Network Identifier (VNI)
with the customer MVPN. The supported PMSI tunnel types with VXLAN associated with the customer MVPN. The supported PMSI tunnel types
encapsulation are: PIM-SSM Tree, PIM-SM Tree, BIDIR-PIM Tree, Ingress with VXLAN encapsulation are: PIM-SSM Tree, PIM-SM Tree, BIDIR-PIM
Replication [RFC6514]. Further details are in [RFC8365]. Tree, Ingress Replication [RFC6514]. Further details are in
[RFC8365].
In this case, a gateway is needed for inter-operation between the In this case, a gateway is needed for inter-operation between the
EVPN PEs and non-EVPN MVPN PEs. The gateway should re-originate the EVPN PEs and non-EVPN MVPN PEs. The gateway should re-originate the
control plane signaling with the relevant tunnel encapsulation on control plane signaling with the relevant tunnel encapsulation on
either side. In the data plane, the gateway terminates the tunnels either side. In the data plane, the gateway terminates the tunnels
formed on either side and performs the relevant stitching/re- formed on either side and performs the relevant stitching/re-
encapsulation on data packets. encapsulation on data packets.
9.2.3. Other Encapsulation 9.2.3. Other Encapsulation
In order to signal a different tunneling encapsulation such as NVGRE, In order to signal a different tunneling encapsulation such as NVGRE,
GPE, or GENEVE the corresponding BGP encapsulation extended community GPE, or GENEVE the corresponding BGP encapsulation extended community
[TUNNEL-ENCAP] SHOULD be appended to the MVPN I-PMSI and S-PMSI A-D [I-D.ietf-idr-tunnel-encaps] SHOULD be appended to the MVPN I-PMSI
routes. If the Tunnel Type field in the encapsulation extended- and S-PMSI A-D routes. If the Tunnel Type field in the encapsulation
community is set to a type which requires Virtual Network Identifier extended- community is set to a type which requires Virtual Network
(VNI), e.g., VXLAN-GPE or NVGRE [TUNNEL-ENCAP], then the MPLS label Identifier (VNI), e.g., VXLAN-GPE or NVGRE
in the PMSI Tunnel Attribute MUST be the VNI associated with the [I-D.ietf-idr-tunnel-encaps], then the MPLS label in the PMSI Tunnel
customer MVPN. Same as in VXLAN case, a gateway is needed for inter- Attribute MUST be the VNI associated with the customer MVPN. Same as
operation between the EVPN-IRB PEs and non-EVPN MVPN PEs. in VXLAN case, a gateway is needed for inter- operation between the
EVPN-IRB PEs and non-EVPN MVPN PEs.
10. DCI with MPLS in WAN and VxLAN in DCs 10. DCI with MPLS in WAN and VxLAN in DCs
This section describers the inter-operation between MVPN PEs in WAN This section describers the inter-operation between MVPN PEs in WAN
using MPLS encapsulation with EVPN PEs in a DC network using VxLAN using MPLS encapsulation with EVPN PEs in a DC network using VxLAN
encapsulation. Since the tunnel encapsulation between these networks encapsulation. Since the tunnel encapsulation between these networks
are different, we must have at least one gateway in between. Usually, are different, we must have at least one gateway in between.
two or more are required for redundancy and load balancing purpose. Usually, two or more are required for redundancy and load balancing
In such scenarios, a DC network can be represented as a customer purpose. In such scenarios, a DC network can be represented as a
network that is multi-homed to two or more MVPN PEs via L3 interfaces customer network that is multi-homed to two or more MVPN PEs via L3
and thus standard MVPN multi-homing procedures are applicable here. interfaces and thus standard MVPN multi-homing procedures are
It should be noted that a MVPN overlay tunnel over the DC network is applicable here. It should be noted that a MVPN overlay tunnel over
terminated on the IP-VRF of the gateway and not the MAC-VRF/BTs. the DC network is terminated on the IP-VRF of the gateway and not the
Therefore, the considerations for loop prevention and split-horizon MAC-VRF/BTs. Therefore, the considerations for loop prevention and
filtering described in [INTERCON-EVPN] are not applicable here. Some split-horizon filtering described in [I-D.ietf-bess-dci-evpn-overlay]
aspects of the multi-homing between VxLAN DC networks and MPLS WAN is are not applicable here. Some aspects of the multi-homing between
in common with [INTERCON-EVPN]. VxLAN DC networks and MPLS WAN is in common with
[I-D.ietf-bess-dci-evpn-overlay] .
10.1. Control plane inter-connect 10.1. Control plane inter-connect
The gateway(s) MUST be setup with the inclusive set of all the IP- 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 VRFs that span across the two domains. On each gateway, there will
at least two BGP sessions: one towards the DC side and the other be at least two BGP sessions: one towards the DC side and the other
towards the WAN side. Usually for redundancy purpose, more sessions towards the WAN side. Usually for redundancy purpose, more sessions
are setup on each side. The unicast route propagation follows the are setup on each side. The unicast route propagation follows the
exact same procedures in [INTERCON-EVPN]. Hence, a multicast host exact same procedures in [I-D.ietf-bess-dci-evpn-overlay]. Hence, a
located in either domain, is advertised with the gateway IP address multicast host located in either domain, is advertised with the
as the next-hop to the other domain. As a result, PEs view the hosts gateway IP address as the next-hop to the other domain. As a result,
in the other domain as directly attached to the gateway and all PEs view the hosts in the other domain as directly attached to the
inter-domain multicast signaling is directed towards the gateway(s). gateway and all inter-domain multicast signaling is directed towards
Received MVPN routes type 1-7 from either side of the gateway(s), the gateway(s). Received MVPN routes type 1-7 from either side of
MUST NOT be reflected back to the same side but processed locally and the gateway(s), MUST NOT be reflected back to the same side but
re-advertised (if needed) to the other side: processed locally and re-advertised (if needed) to the other side:
- Intra-AS I-PMSI A-D Route: these are distributed within o Intra-AS I-PMSI A-D Route: these are distributed within each
each domain to form the overlay tunnels which terminate at domain to form the overlay tunnels which terminate at gateway(s).
gateway(s). They are not passed to the other side of the They are not passed to the other side of the gateway(s).
gateway(s).
- C-Multicast Route: joins are imported into the corresponding o C-Multicast Route: joins are imported into the corresponding IP-
IP-VRF on each gateway and advertised as a new route to the VRF on each gateway and advertised as a new route to the other
other side with the following modifications (the rest of side with the following modifications (the rest of NLRI fields and
NLRI fields and path attributes remain on-touched): 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 * Route-Distinguisher is set to that of the IP-VRF
* Route-target is set to the exported route-target list on IP-VRF
- S-PMSI A-D Route: these are passed to the other side to form * The PMSI tunnel attribute and BGP Encapsulation extended
selective PMSI tunnels per every (C-S,C-G) from the gateway community will be modified according to section 8
to the PEs in the other domain provided it contains
receivers for the given (C-S, C-G). Similar modifications * Next-hop will be set to the IP address which represents the
made to joins are made to the newly originated S-PMSI. gateway on either domain
o Source Active A-D Route: same as joins
o 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 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 address. Multicast signaling from/to hosts on local ACs on the
gateway(s) are generated and propagated in both domains (if needed) gateway(s) are generated and propagated in both domains (if needed)
per the procedures in section 7 in this document and in [RFC6514] 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, 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 the gateway will program an OIF per every domain from which it
receives a remote join in its forwarding plane and different receives a remote join in its forwarding plane and different
encapsulation will be used on the data packets. encapsulation will be used on the data packets.
10.2. Data plane inter-connect 10.2. Data plane inter-connect
Traffic forwarding procedures on gateways are same as those described 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, for PEs in section 5 and 6 except that, unlike a non-border leaf PE,
the gateway will not only route the incoming traffic from one side to the gateway will not only route the incoming traffic from one side to
its local receivers, but will also send it to the remote receivers in its local receivers, but will also send it to the remote receivers in
the the other domain after de-capsulation and appending the right the the other domain after de-capsulation and appending the right
encapsulation. The OIF and IIF are programmed in FIB based on the encapsulation. The OIF and IIF are programmed in FIB based on the
received joins from either side and the RPF calculation to the source received joins from either side and the RPF calculation to the source
or RP. The de-capsulation and encapsulation actions are programmed 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. 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- If there are more than one gateway between two domains, the multi-
homing procedures described in the following section must be homing procedures described in the following section must be
considered so that incoming traffic from one side is not looped back considered so that incoming traffic from one side is not looped back
to the other gateway. to the other gateway.
The multicast traffic from local sources on each gateway flows to the The multicast traffic from local sources on each gateway flows to the
other gateway with the preferred WAN encapsulation. other gateway with the preferred WAN encapsulation.
11. Supporting application with TTL value 1 11. Supporting application with TTL value 1
It is possible that some deployments may have a host on the tenant It is possible that some deployments may have a host on the tenant
domain that sends multicast traffic with TTL value 1. The interested domain that sends multicast traffic with TTL value 1. The interested
receiver for that traffic flow may be attached to different PEs on receiver for that traffic flow may be attached to different PEs on
the same subnet. The procedures specified in section 6 always routes the same subnet. The procedures specified in section 6 always routes
the traffic between PEs for both intra and inter subnet traffic. the traffic between PEs for both intra and inter subnet traffic.
Hence traffic with TTL value 1 is dropped due to the nature of Hence traffic with TTL value 1 is dropped due to the nature of
routing. routing.
This section discusses few possible ways to support traffic having This section discusses few possible ways to support traffic having
TTL value 1. Implementation MAY support any of the following model. TTL value 1. Implementation MAY support any of the following model.
11.1. Policy based model 11.1. Policy based model
Policies may be used to enforce EVPN BUM procedure for traffic flows Policies may be used to enforce EVPN BUM procedure for traffic flows
with TTL value 1. Traffic flow that matches the policy is excluded with TTL value 1. Traffic flow that matches the policy is excluded
from seamless interop procedure specified in this document, hence TTL from seamless interop procedure specified in this document, hence TTL
decrement issue will not apply. decrement issue will not apply.
11.2. Exercising BUM procedure for VLAN/BD 11.2. Exercising BUM procedure for VLAN/BD
Servers/hosts sending the traffic with TTL value 1 may be attached to Servers/hosts sending the traffic with TTL value 1 may be attached to
a separate VLAN/BD, where multicast routing is disabled. When a separate VLAN/BD, where multicast routing is disabled. When
multicast routing is disabled, EVPN BUM procedure may be applied to multicast routing is disabled, EVPN BUM procedure may be applied to
all traffic ingressing on that VLAN/BD. On the Egress PE, the RPF for all traffic ingressing on that VLAN/BD. On the Egress PE, the RPF
such traffic may be set to BD interface, where the source is for such traffic may be set to BD interface, where the source is
attached. attached.
11.3. Intra-subnet bridging 11.3. Intra-subnet bridging
The procedure specified in the section enables a PE to detect an The procedure specified in the section enables a PE to detect an
attached subnet source (i.e., source that is directly attached in the attached subnet source (i.e., source that is directly attached in the
tenant BD/VLAN). By applying the following procedure for the tenant BD/VLAN). By applying the following procedure for the
attached source, Traffic flows having TTL value 1 can be supported. attached source, Traffic flows having TTL value 1 can be supported.
- On the ingress PE, do the bridging on the interface towards the - On the ingress PE, do the bridging on the interface towards the
core interface core interface
- On the egress side, make a decision whether to bridge or route - On the egress side, make a decision whether to bridge or route
at the outgoing interface (OIF) based on whether the source is at the outgoing interface (OIF) based on whether the source is
attached to the OIF's BD/VLAN or not. attached to the OIF's BD/VLAN or not.
Recent ASIC supports single lookup forwarding for brigading and Recent ASIC supports single lookup forwarding for brigading and
routing (L2+L3). The procedure mentioned here leverages this ASIC routing (L2+L3). The procedure mentioned here leverages this ASIC
capability. capability.
PE1 PE1
+------------+ +------------+
S11 +---+(BD1) | +---------+ S11 +---+(BD1) | +---------+
| \ | | | | \ | | |
|(IP-VRF)-(CORE)| | |(IP-VRF)-(CORE)| |
| / | | | | / | | |
R12 +---+(BD2) | | | R12 +---+(BD2) | | |
+------------+ | | +------------+ | |
| | | |
PE2 | VXLAN. | PE2 | VXLAN. |
+------------+ | | +------------+ | |
R21 +---+(BD1) | | | R21 +---+(BD1) | | |
| \ | | | | \ | | |
|(IP-VRF)-(CORE)| | |(IP-VRF)-(CORE)| |
| / | | | | / | | |
R22+----+(BD3) | +---------+ R22+----+(BD3) | +---------+
+------------+ +------------+
Figure 3 Intra-subnet bridging Figure 3 Intra-subnet bridging
Consider the above picture. In the picture Consider the above picture. In the picture
- PE1 and PE2 are seamless interop capable PEs - PE1 and PE2 are seamless interop capable PEs
- S11 is a multicast host directly attached to PE1 in BD1 - S11 is a multicast host directly attached to PE1 in BD1
- Source S11 sends traffic to Group G11 - Source S11 sends traffic to Group G11
- R21, R22 are IGMP receivers for group G11 - R21, R22 are IGMP receivers for group G11
- R21 and R22 are attached to BD1 and BD3 respectively at PE2. - R21 and R22 are attached to BD1 and BD3 respectively at PE2.
When source S11 starts sending the traffic, PE1 learns the source and When source S11 starts sending the traffic, PE1 learns the source and
announces the source using MVPN procedures to the remote PEs. announces the source using MVPN procedures to the remote PEs.
At PE2, IGMP joins from R21, R22 result the creation of (*,G11) entry At PE2, IGMP joins from R21, R22 result the creation of (*,G11) entry
with outgoing OIF as IRB interface of BD1 and BD3. When PE2 learns with outgoing OIF as IRB interface of BD1 and BD3. When PE2 learns
the source information from PE1, it installs the route (S11, G11) at the source information from PE1, it installs the route (S11, G11) at
the tenant VRF with RPF as CORE interface. the tenant VRF with RPF as CORE interface.
PE2 inherits (*, G11) OIFs to (S11, G11) entry. While inheriting OIF, PE2 inherits (*, G11) OIFs to (S11, G11) entry. While inheriting
PE2 checks whether source is attached to OIF's subnet. OIF matching OIF, PE2 checks whether source is attached to OIF's subnet. OIF
source subnet is added with flag indicating bridge only interface. In matching source subnet is added with flag indicating bridge only
case of (S11, G11) entry, BD1 is added as the bridge only OIF, while interface. In case of (S11, G11) entry, BD1 is added as the bridge
BD3 is added as normal OIF(L3 OIF). only OIF, while BD3 is added as normal OIF(L3 OIF). PEs (PE2) sends
MVPN join (S11, G11) towards PE1, since it has local receivers.
PEs (PE2) sends MVPN join (S11, G11) towards PE1, since it has local
receivers.
At Ingress PE(PE1), CORE interface is added to (S11, G11) entry as an At Ingress PE(PE1), CORE interface is added to (S11, G11) entry as an
OIF (outgoing interface) with a flag indicating that bridge only OIF (outgoing interface) with a flag indicating that bridge only
interface. With this procedure, ingress PE(PE1) bridges the traffic interface. With this procedure, ingress PE(PE1) bridges the traffic
on CORE interface. (PE1 retains the TTL and source-MAC). The traffic on CORE interface. (PE1 retains the TTL and source-MAC). The
is encapsulated with VNI associated with CORE interface(L3VNI). PE1 traffic is encapsulated with VNI associated with CORE
also routes the traffic for R12 which is attached to BD2 on the same interface(L3VNI). PE1 also routes the traffic for R12 which is
device. attached to BD2 on the same device.
PE2 decapsulates the traffic from PE1 and does inner lookup on the PE2 decapsulates the traffic from PE1 and does inner lookup on the
tenant VRF associated with incoming VNI. Traffic lookup on the tenant tenant VRF associated with incoming VNI. Traffic lookup on the
VRF yields (S11, G11) entry as the matching entry. Traffic gets tenant VRF yields (S11, G11) entry as the matching entry. Traffic
bridged on BD1 (PE2 retains the TTL and source-MAC) since the OIF is gets bridged on BD1 (PE2 retains the TTL and source-MAC) since the
marked as bridge only interface. Traffic gets routed on BD2. OIF is marked as bridge only interface. Traffic gets routed on BD2.
12. Interop with L2 EVPN PEs 12. Interop with L2 EVPN PEs
A gateway device is needed to do interop between EVPN PEs that A gateway device is needed to do interop between EVPN PEs that
support seamless interop procedure specified in this document and support seamless interop procedure specified in this document and
native EVPN-PEs(L2EVPN PE). The gateway device uses BUM tunnel when L2EVPN-PEs. A tenant domain can be provisioned with one or more such
interworking with L2EVPN-PEs. gateway devices known as "Seamless interop EVPN Multicast Gateway
(SEMG)". PE that is configured as SEMG must be provisioned with all
BDs that are available in the tenant domain.
Interop procedure will be covered in the next version of the draft. When advertising IMET route for a BD, PE configured as SEMG
advertises EVPN Multicast Flags Extended Community with SEMG flag
set. Given set of eligible PEs, one PE is selected as the SEMG
designated forwarder (SEMG-DF). PE should use procedure specified in
[I-D.ietf-bess-evpn-df-election-framework] for the SEMG DF election.
13. Connecting external Multicast networks or PIM routers. L2EVPN PE may or may not have support for
[I-D.ietf-bess-evpn-igmp-mld-proxy]. Procedure specified in the
section supports both such PEs.
[I-D.ietf-bess-evpn-igmp-mld-proxy] support is recommended for
seamless interop capable PE. The following section describes interop
procedure assuming that seamless interop capable PE supports
[I-D.ietf-bess-evpn-igmp-mld-proxy].
SEMG-DF has the following special responsibilities on a BD for which
it is the DF
o Process IGMP control packets from remote L2 EVPN PEs that doesn't
support [I-D.ietf-bess-evpn-igmp-mld-proxy].
o Process EVPN SMET routes from remote L2 EVPN PE that support
[I-D.ietf-bess-evpn-igmp-mld-proxy] and creates L2 multicast
state. (Remote IGMP join and SMET route in-turn triggers creation
of L3 multicast state similar to IGMP join received on local AC)
o Originate SMET(*,*) route towards L2EVPN PEs. This is to attract
traffic from L2EPN PEs that support
[I-D.ietf-bess-evpn-igmp-mld-proxy]. ( L2EVPN PEs that doesn't
support [I-D.ietf-bess-evpn-igmp-mld-proxy] will drop this route )
o Forward the incoming traffic (S,G) from MVPN side (including non
DF SEMG) to
* Locally attached receivers on all BDs
* Send the traffic via L2 BUM tunnels, if it has L2 forwarding
state due to
+ incoming SMET route from remote L2EVPN PEs or
+ due to incoming IGMP control packets
(SEMG-DF could send the traffic on multiple BDs, if the PE ends
up being DF for more than one customer BDs and if remote
receivers exist on those BD)
o When it receives traffic from L2 EVPN PE on the intra-subnet
tunnel on BD-X
* Performs FHR functionality
* Should advertise host route with L3 label and VRF Route-Import
corresponds to PE's tenant domain
* Send the traffic towards local attached receivers
* Send the traffic towards MVPN tunnel for the remote L3
receivers
* Send the traffic towards L2EVPN receiver on BDs other than
incoming BD
All seamless interop capable PEs other than SEMG should discard SMET
routes that is coming from L2EVPN PEs and must discard all IGMP
control packets, if any received on the intra-subnet tunnel. SEMG
should discard incoming SMET routes and IGMP joins from L2EVPN PEs,
if it is not the DF for the incoming BD.
If [I-D.ietf-bess-evpn-igmp-mld-proxy] support is not available SEMG-
DF, It should get all multicast traffic from L2EVPN PEs. This may be
achieved by sending IGMP query or PIM hello on the intra-subnet
tunnel. The exact of procedure is outside the scope of this
document.
When [I-D.ietf-bess-evpn-igmp-mld-proxy] is supported both at
seamless interop capable PE and L2EVPN PE, selective forwarding is
done based on receiver interest at the egress-PE, when overlay tunnel
type is Ingress-replication or selective tunnel.
13. Connecting external Multicast networks or PIM routers.
External multicast networks or PIM routers can be attached to any External multicast networks or PIM routers can be attached to any
seamless interop capable EVPN-PEs or set of EVPN-PEs. Multicast seamless interop capable EVPN-PEs or set of EVPN-PEs. Multicast
network or PIM router can also be attached to any IRB enabled BDI network or PIM router can also be attached to any IRB enabled BDI
interface or L3 enabled interface or set of interfaces. The fabric interface or L3 enabled interface or set of interfaces. The fabric
can be used as a Transit network. All PIM signaling is terminated at can be used as a Transit network. All PIM signaling is terminated at
EVPN-PEs. EVPN-PEs.
No additional procedures are required while connecting external No additional procedures are required while connecting external
multicast networks. multicast networks.
14. RP handling 14. RP handling
This section describes various RP models for a tenant VRF. The RP This section describes various RP models for a tenant VRF. The RP
model SHOULD be consistent across all EVPN-PEs for given group/group model SHOULD be consistent across all EVPN-PEs for given group/group
range in the tenant VRF. range in the tenant VRF.
14.1. Various RP deployment options 14.1. Various RP deployment options
14.1.1. RP-less mode
14.1.1. RP-less mode
EVPN fabric without having any external multicast network/attached EVPN fabric without having any external multicast network/attached
MVPN network, doesn't need RP configuration. A configuration option MVPN network, doesn't need RP configuration. A configuration option
SHALL be provided to the end user to operate the fabric in RP less SHALL be provided to the end user to operate the fabric in RP less
mode. When an EVPN-PE is operating in RP-less mode, EVPN-PE MUST mode. When an EVPN-PE is operating in RP-less mode, EVPN-PE MUST
advertise all attached sources to remote EVPN PEs using procedure advertise all attached sources to remote EVPN PEs using procedure
specified in [RFC 6514]. specified in [RFC6514].
In RP less mode, (C-*,C-G) RPF may be set to NULL or may be set to In RP less mode, (C-*,C-G) RPF may be set to NULL or may be set to
wild card interface( Any interface on the tenant VRF). In RP-less wild card interface( Any interface on the tenant VRF). In RP-less
mode, traffic is always forwarded based on (C-S,C-G) state. mode, traffic is always forwarded based on (C-S,C-G) state.
14.1.2. Fabric anycast RP 14.1.2. Fabric anycast RP
In this model, anycast GW IP address is configured as RP in all EVPN- In this model, anycast GW IP address is configured as RP in all EVPN-
PE. When an EVPN-PE is operating in Fabric anycast-RP mode, an EVPN- PE. When an EVPN-PE is operating in Fabric anycast-RP mode, an EVPN-
PE MUST advertise all sources behind that PE to other EVPN PEs using PE MUST advertise all sources behind that PE to other EVPN PEs using
procedure specified in [RFC 6514]. In this model, Sources may be procedure specified in [RFC6514]. In this model, Sources may be
directly attached to tenant BDs or sources may be attached behind a directly attached to tenant BDs or sources may be attached behind a
PIM router (In that case EVPN-PE learns source information due to PIM PIM router (In that case EVPN-PE learns source information due to PIM
register terminating at RP interface at the tenant VRF side) register terminating at RP interface at the tenant VRF side)
In RP-less mode and Fabric anycast RP mode, EVPN-PE operates SPT-only In RP-less mode and Fabric anycast RP mode, EVPN-PE operates SPT-only
mode as per section 14 of RFC 6514. mode as per section 14 of [RFC6514].
14.1.3. Static RP 14.1.3. Static RP
The procedure specified in this document supports configuring EVPN The procedure specified in this document supports configuring EVPN
fabric with static RP. RP can be configured in the EVPN-PE itself in fabric with static RP. RP can be configured in the EVPN-PE itself in
the tenant VRF or in the external multicast networks connected behind the tenant VRF or in the external multicast networks connected behind
an EVPN PE or in the MVPN network. When RPF is not local to EVPN-PE, an EVPN PE or in the MVPN network. When RPF is not local to EVPN-PE,
EVPN-PE operates in rpt-spt mode as PER procedures specified in EVPN-PE operates in rpt-spt mode as PER procedures specified in
section 13 of RFC 6514. section 13 of [RFC6514].
14.1.4. Co-existence of Fabric anycast RP and external RP 14.1.4. Co-existence of Fabric anycast RP and external RP
External multicast network using its own RP may be connected to EVPN External multicast network using its own RP may be connected to EVPN
fabric operating with Fabric anycast RP mode. In this case, subset of fabric operating with Fabric anycast RP mode. In this case, subset
EVPN-PEs may be designated as border leafs. Anycast RP may be of EVPN-PEs may be designated as border leafs. Anycast RP may be
configured between border leafs and external RP. Border leafs configured between border leafs and external RP. Border leafs
originates SA-AD routes for external sources towards fabric PEs. originates SA-AD routes for external sources towards fabric PEs.
Border leaf acts as FHR for the sources inside the fabric. Border leaf acts as FHR for the sources inside the fabric.
Configuration option may be provided to define the PE role as BL. Configuration option may be provided to define the PE role as BL.
14.2. RP configuration options 14.2. RP configuration options
PIM Bidir and PIM-SM ASM mode require Rendezvous point (RP) PIM Bidir and PIM-SM ASM mode require Rendezvous point (RP)
configuration, which acts as a shared root for a multicast shared configuration, which acts as a shared root for a multicast shared
tree. RP can be configured using static configuration or by using BSR tree. RP can be configured using static configuration or by using
or Auto-RP procedures on the tenant VRF. This document only discusses BSR or Auto-RP procedures on the tenant VRF. This document only
static RP configuration. The use of BSR or Auto-RP procedure in the discusses static RP configuration. The use of BSR or Auto-RP
EVPN fabric is beyond the scope of this document. procedure in the EVPN fabric is beyond the scope of this document.
15. IANA Considerations 15. IANA Considerations
IANA is requested to assign new flags in the "Multicast Flags IANA is requested to assign new flags in the "Multicast Flags
Extended Community Flags" registry for the following. Extended Community Flags" registry for the following.
o Seamless interop capable PE o Seamless interop capable PE
o SEMG
16. Security Considerations 16. Security Considerations
All the security considerations in [RFC7432] apply directly to this All the security considerations in [RFC7432] apply directly to this
document because this document leverages [RFC7432] control plane and document because this document leverages [RFC7432] control plane and
their associated procedures. their associated procedures.
17. Acknowledgements 17. Acknowledgements
The authors would like to thank Niloofar Fazlollahi, Aamod The authors would like to thank Niloofar Fazlollahi, Aamod
Vyavaharkar, Raunak Banthia, and Swadesh Agrawal for their Vyavaharkar, Raunak Banthia, and Swadesh Agrawal for their
discussions and contributions. discussions and contributions.
18. References 18. References
18.1. Normative References 18.1. Normative References
[RFC7432] A. Sajassi, et al., "BGP MPLS Based Ethernet VPN", RFC [I-D.ietf-bess-dci-evpn-overlay]
7432 , February 2015. Rabadan, J., Sathappan, S., Henderickx, W., Sajassi, A.,
and J. Drake, "Interconnect Solution for EVPN Overlay
networks", draft-ietf-bess-dci-evpn-overlay-10 (work in
progress), March 2018.
[RFC8365] A. Sajassi, et al., "A Network Virtualization Overlay [I-D.ietf-bess-evpn-df-election-framework]
Solution using EVPN", RFC 8365, February 2018. Rabadan, J., satyamoh@cisco.com, s., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for EVPN
Designated Forwarder Election Extensibility", draft-ietf-
bess-evpn-df-election-framework-09 (work in progress),
January 2019.
[RFC6513] E. Rosen, et al., "Multicast in MPLS/BGP IP VPNs", RFC6513, [I-D.ietf-bess-evpn-igmp-mld-proxy]
February 2012. Sajassi, A., Thoria, S., Patel, K., Drake, J., and W. Lin,
"IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp-
mld-proxy-05 (work in progress), April 2020.
[RFC6514] R. Aggarwal, et al., "BGP Encodings and Procedures for [I-D.ietf-bess-evpn-inter-subnet-forwarding]
Multicast in MPLS/BGP IP VPNs", RFC6514, February 2012. Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", draft-
ietf-bess-evpn-inter-subnet-forwarding-09 (work in
progress), June 2020.
[EVPN-IRB] A. Sajassi, et al., "Integrated Routing and Bridging in [I-D.ietf-idr-tunnel-encaps]
EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-03, Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel
February 2017. Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15
(work in progress), December 2019.
[EVPN-IRB-MCAST] A. Rosen, et al., "EVPN Optimized Inter-Subnet [I-D.skr-bess-evpn-pim-proxy]
Multicast (OISM) Forwarding", draft-lin-bess-evpn-irb- Rabadan, J., Kotalwar, J., Sathappan, S., Zhang, Z., and
mcast-04, October 24, 2017. A. Sajassi, "PIM Proxy in EVPN Networks", draft-skr-bess-
evpn-pim-proxy-01 (work in progress), October 2017.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
18.2. Informative References 18.2. Informative References
[RFC7080] A. Sajassi, et al., "Virtual Private LAN Service (VPLS) [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Interoperability with Provider Backbone Bridges", RFC Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
7080, December 2013. 2006, <https://www.rfc-editor.org/info/rfc4389>.
[RFC7209] D. Thaler, et al., "Requirements for Ethernet VPN (EVPN)", [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
RFC 7209, May 2014. LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>.
[RFC4389] A. Sajassi, et al., "Neighbor Discovery Proxies (ND [RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual
Proxy)", RFC 4389, April 2006. Private LAN Service (VPLS) Interoperability with Provider
Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080,
December 2013, <https://www.rfc-editor.org/info/rfc7080>.
[RFC4761] K. Kompella, et al., "Virtual Private LAN Service (VPLS) [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
Using BGP for Auto-Discovery and Signaling", RFC 4761, Henderickx, W., and A. Isaac, "Requirements for Ethernet
Jauary 2007. VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014,
<https://www.rfc-editor.org/info/rfc7209>.
[INTERCON-EVPN] J. Rabadan, et al., "Interconnect Solution for EVPN Appendix A. Use Cases
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 A.1. DCs with only IGMP/MLD hosts w/o tenant router
Attribute", https://tools.ietf.org/html/draft-ietf-idr-
tunnel-encaps-06, work in progress, June 2017.
[EVPN-IGMP-PROXY] A. Sajassi, et. al., "IGMP and MLD Proxy for EVPN", In a EVPN network consisting of only IGMP/MLD hosts, PE's will
draft-ietf-bess-evpn-igmp-mld-proxy-01, work in progress, receive IGMP (*, G) or (S, G) joins from their locally attached host
March 2018. and would originate MVPN C-Multicast Route Type 6 and 7 NLRI's
respectively. As described in [RFC6514] 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
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 the
router RP-PE would be the PE configured as RP (e.g., 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 [RFC6514] 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.
[EVPN-PIM-PROXY] J. Rabadan, et. al., "PIM Proxy in EVPN Networks", However a network operator can chose to have only Shortest-Path-Tree
draft-skr-bess-evpn-pim-proxy-00, work in progress, July built in MVPN core as described in section 14 of [RFC6514]. One way
3, 2017. to achieve this, is for all PE's 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. Once 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.
19. Authors' Addresses A.2. DCs with mixed of IGMP/MLD hosts & multicast routers running PIM-
SSM
Ali Sajassi This scenario has multicast routers which can send PIM SSM (S, G)
Csco joins. Upon receiving these joins and if source described in join is
170 West Tasman Drive learnt to be behind a MVPN peer PE, local PE will originate
San Jose, CA 95134, US C-Multicast Join (RT 7) towards Source-PE. It is expected that PIM
Email: sajassi@cisco.com 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.
Kesavan Thiruvenkatasamy A.3. DCs with mixed of IGMP/MLD hosts & multicast routers running PIM-
Cisco ASM
170 West Tasman Drive
San Jose, CA 95134, US
Email: kethiruv@cisco.com
Samir Thoria This scenario includes reception of PIM (*, G) joins on PE's local
Cisco AC. These joins are handled similar to IGMP (*, G) join as explained
170 West Tasman Drive in sections above. Another interesting case can arise here is when
San Jose, CA 95134, US one of the tenant routers can act as RP for some of the ASM Groups.
Email: sthoria@cisco.com 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 [RFC6513] with respect to UMH should be used
to avoid traffic duplication due to incoherent selection of RP-PE by
different Receiver-PE's.
Ashutosh Gupta A.4. DCs with mixed of IGMP/MLD hosts & multicast routers running PIM-
Avi Networks Bidir
Email: ashutosh@avinetworks.com
Luay Jalil Creating Bidirectional (*, G) trees is useful when a customer wants
Verizon least amount of control state in network. But on downside all
Email: luay.jalil@verizon.com 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 [RFC6513] and [RFC6514]
apply when PIM-Bidir is used.
Appendix A. Use Cases Authors' Addresses
A.1. DCs with only IGMP/MLD hosts w/o tenant router Ali Sajassi
Cisco
170 West Tasman Drive
San Jose, CA 95134, US
In a EVPN network consisting of only IGMP/MLD hosts, PE's Email: sajassi@cisco.com
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 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 the router RP-PE would be the PE configured as RP
(e.g., 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 Kesavan Thiruvenkatasamy
Shortest-Path-Tree built in MVPN core as described in Cisco
section 14 of [RFC6514]. One way to achieve this, is for 170 West Tasman Drive
all PE's act as RP for its locally connected hosts and San Jose, CA 95134, US
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. Once 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.
A.2. DCs with mixed of IGMP/MLD hosts & multicast routers running PIM- Email: kethiruv@cisco.com
SSM
This scenario has multicast routers which can send PIM SSM Samir Thoria
(S, G) joins. Upon receiving these joins and if source Cisco
described in join is learnt to be behind a MVPN peer PE, 170 West Tasman Drive
local PE will originate C-Multicast Join (RT 7) towards San Jose, CA 95134, US
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.
A.3. DCs with mixed of IGMP/MLD hosts & multicast routers running PIM- Email: sthoria@cisco.com
ASM Ashutosh Gupta
This scenario includes reception of PIM (*, G) joins on VMware
PE's local AC. These joins are handled similar to IGMP (*, 3401 Hillview Ave, Palo Alto, CA 94304
G) join as explained 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.
A.4. DCs with mixed of IGMP/MLD hosts & multicast routers running PIM- Email: ashutoshgupta@vmware.com
Bidir
Creating Bidirectional (*, G) trees is useful when a Luay Jalil
customer wants least amount of control state in network. Verizon
But on downside all receivers for a particular multicast
group receive traffic from all sources sending to that Email: luay.jalil@verizon.com
group. However for the purpose of this document, all
procedures as described in RFC 6513 and RFC 6514 apply
when PIM-Bidir is used.
 End of changes. 245 change blocks. 
729 lines changed or deleted 859 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/