< draft-sajassi-bess-evpn-mvpn-seamless-interop-03.txt   draft-sajassi-bess-evpn-mvpn-seamless-interop-04.txt >
BESS Working Group A. Sajassi BESS Working Group A. Sajassi
Internet Draft S. Thoria Internet Draft K. Thiruvenkatasamy
Category: Standard Track Cisco Category: Standard Track S. Thoria
Cisco
A. Gupta A. Gupta
Avi Networks Avi Networks
L. Jalil L. Jalil
Verizon Verizon
Expires: May 22, 2019 October 22, 2018 Expires: January 06, 2020 July 05, 2019
Seamless Multicast Interoperability between EVPN and MVPN PEs Seamless Multicast Interoperability between EVPN and MVPN PEs
draft-sajassi-bess-evpn-mvpn-seamless-interop-03 draft-sajassi-bess-evpn-mvpn-seamless-interop-04
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)
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Optimum Forwarding . . . . . . . . . . . . . . . . . . . . 6 4.1. Optimum Forwarding . . . . . . . . . . . . . . . . . . . . 7
4.2. Optimum Replication . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 7
4.5. EVPN Service Interfaces . . . . . . . . . . . . . . . . . . 7 4.5. EVPN Service Interfaces . . . . . . . . . . . . . . . . . . 8
4.6. Distributed Anycast Gateway . . . . . . . . . . . . . . . . 7 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 . . . 8
5. IRB Unicast versus IRB Multicast . . . . . . . . . . . . . . . 8 4.11. External source and receivers . . . . . . . . . . . . . . 9
4.12. Tenant RP placement . . . . . . . . . . . . . . . . . . . 9
5. IRB Unicast versus IRB Multicast . . . . . . . . . . . . . . . 9
5.1. Emulated Virtual LAN Service . . . . . . . . . . . . . . . 9 5.1. Emulated Virtual LAN Service . . . . . . . . . . . . . . . 9
6. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9 6. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Operational Model for EVPN IRB PEs . . . . . . . . . . . . 9 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 . . . 12
6.3. Multi-homing of IP Multicast Source and Receivers . . . . 13 6.3. Multi-homing of IP Multicast Source and Receivers . . . . 13
6.3.1. Single-Active Multi-Homing . . . . . . . . . . . . . . 13 6.3.1. Single-Active Multi-Homing . . . . . . . . . . . . . . 14
6.3.2. All-Active Multi-Homing . . . . . . . . . . . . . . . 14 6.3.2. All-Active Multi-Homing . . . . . . . . . . . . . . . 15
6.4. Mobility for Tenant's Sources and Receivers . . . . . . . 16 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 . . . . . . . . . . . . 17
7. Control Plane Operation . . . . . . . . . . . . . . . . . . . 17 6.6 EVPN and MVPN interworking with gateway model . . . . . . . 17
7.1. Intra-ES IP Multicast Tunnel . . . . . . . . . . . . . . . 17 7. Control Plane Operation . . . . . . . . . . . . . . . . . . . 18
7.2. Intra-Subnet BUM Tunnel . . . . . . . . . . . . . . . . . . 18 7.1. Intra-ES/Intra-Subnet IP Multicast Tunnel . . . . . . . . . 18
7.3. Inter-Subnet IP Multicast Tunnel . . . . . . . . . . . . . 19 7.2. Intra-Subnet BUM Tunnel . . . . . . . . . . . . . . . . . . 19
7.4. IGMP Hosts as TSes . . . . . . . . . . . . . . . . . . . . 19 7.3. Inter-Subnet IP Multicast Tunnel . . . . . . . . . . . . . 20
7.5. TS PIM Routers . . . . . . . . . . . . . . . . . . . . . . 20 7.4. IGMP Hosts as TSes . . . . . . . . . . . . . . . . . . . . 20
8 Data Plane Operation . . . . . . . . . . . . . . . . . . . . . 20 7.5. TS PIM Routers . . . . . . . . . . . . . . . . . . . . . . 21
8.1 Intra-Subnet L2 Switching . . . . . . . . . . . . . . . . . 21 8 Data Plane Operation . . . . . . . . . . . . . . . . . . . . . 21
8.2 Inter-Subnet L3 Routing . . . . . . . . . . . . . . . . . . 21 8.1 Intra-Subnet L2 Switching . . . . . . . . . . . . . . . . . 22
9. DCs with only EVPN PEs . . . . . . . . . . . . . . . . . . . . 22 8.2 Inter-Subnet L3 Routing . . . . . . . . . . . . . . . . . . 22
9.1. Setup of overlay multicast delivery . . . . . . . . . . . . 22 9. DCs with only EVPN PEs . . . . . . . . . . . . . . . . . . . . 23
9.2. Handling of different encapsulations . . . . . . . . . . . 24 9.1. Setup of overlay multicast delivery . . . . . . . . . . . . 23
9.2.1. MPLS Encapsulation . . . . . . . . . . . . . . . . . . 24 9.2. Handling of different encapsulations . . . . . . . . . . . 25
9.2.2 VxLAN Encapsulation . . . . . . . . . . . . . . . . . . 24 9.2.1. MPLS Encapsulation . . . . . . . . . . . . . . . . . . 25
9.2.3. Other Encapsulation . . . . . . . . . . . . . . . . . 24 9.2.2 VxLAN Encapsulation . . . . . . . . . . . . . . . . . . 25
10. DCI with MPLS in WAN and VxLAN in DCs . . . . . . . . . . . . 25 9.2.3. Other Encapsulation . . . . . . . . . . . . . . . . . 26
10.1. Control plane inter-connect . . . . . . . . . . . . . . . 25 10. DCI with MPLS in WAN and VxLAN in DCs . . . . . . . . . . . . 26
10.2. Data plane inter-connect . . . . . . . . . . . . . . . . . 26 10.1. Control plane inter-connect . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10.2. Data plane inter-connect . . . . . . . . . . . . . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Supporting application with TTL value 1 . . . . . . . . . . . 28
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Policy based model . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.2. Exercising BUM procedure for VLAN/BD . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.3. Intra-subnet bridging . . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . . 28 12. Interop with L2 EVPN PEs . . . . . . . . . . . . . . . . . . . 30
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 13. Connecting external Multicast networks or PIM routers. . . . . 30
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 29 14. RP handling . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.1. DCs with only IGMP/MLD hosts w/o tenant router . . . . . . 29 14.1. Various RP deployment options . . . . . . . . . . . . . . 30
A.2. DCs with mixed of IGMP/MLD hosts & multicast routers 14.1.1. RP-less mode . . . . . . . . . . . . . . . . . . . . . 30
running PIM-SSM . . . . . . . . . . . . . . . . . . . . . 30 14.1.2. Fabric anycast RP . . . . . . . . . . . . . . . . . . 31
A.3. DCs with mixed of IGMP/MLD hosts & multicast routers 14.1.3. Static RP . . . . . . . . . . . . . . . . . . . . . . 31
running PIM-ASM . . . . . . . . . . . . . . . . . . . . . 30 14.1.4. Co-existence of Fabric anycast RP and external RP . . 31
A.4. DCs with mixed of IGMP/MLD hosts & multicast routers 14.2. RP configuration options . . . . . . . . . . . . . . . . . 31
running PIM-Bidir . . . . . . . . . . . . . . . . . . . . 30 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
18.1. Normative References . . . . . . . . . . . . . . . . . . 32
18.2. Informative References . . . . . . . . . . . . . . . . . 33
19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 34
A.1. DCs with only IGMP/MLD hosts w/o tenant router . . . . . . 34
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)
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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
Most of the terminology used in this documents comes from [RFC8365] Most of the terminology used in this documents comes from [RFC8365]
Broadcast Domain: In a bridged network, the broadcast domain Broadcast Domain (BD): In a bridged network, the broadcast domain
corresponds to a Virtual LAN (VLAN), where a VLAN is typically corresponds to a Virtual LAN (VLAN), where a VLAN is typically
represented by a single VLAN ID (VID) but can be represented by represented by a single VLAN ID (VID) but can be represented by
several VIDs where Shared VLAN Learning (SVL) is used per [802.1Q]. several VIDs where Shared VLAN Learning (SVL) is used per [802.1Q].
Bridge Table: An instantiation of a broadcast domain on a MAC-VRF. Bridge Table (BT): An instantiation of a broadcast domain on a MAC-
VRF.
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
skipping to change at page 6, line 32 skipping to change at page 6, line 33
segment are allowed to forward known unicast traffic to/from that segment are allowed to forward known unicast traffic to/from that
Ethernet segment for a given VLAN, then the Ethernet segment is Ethernet segment for a given VLAN, then the Ethernet segment is
defined to be operating in All-Active redundancy mode. defined to be operating in All-Active redundancy mode.
PIM-SM: Protocol Independent Multicast - Sparse-Mode PIM-SM: Protocol Independent Multicast - Sparse-Mode
PIM-SSM: Protocol Independent Multicast - Source Specific Multicast PIM-SSM: Protocol Independent Multicast - Source Specific Multicast
Bidir PIM: Bidirectional PIM Bidir PIM: Bidirectional PIM
FHR: First Hop Router
LHR: Last Hop Router
CO: Central Office of a service provider CO: Central Office of a service provider
SPDC: Service Provider Data Center SPDC: Service Provider Data Center
LATA: Local Access and Transport Area
Border Leafs: A set of EVPN-PE acting as exit point for EVPN fabric.
L3VNI: A VNI in the tenant VRF, which is associated with the core
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 or
skipping to change at page 7, line 4 skipping to change at page 7, line 16
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 or
it can span across multiple LATAs. The solution SHALL support optimum it can span across multiple LATAs. The solution SHALL support optimum
multicast forwarding with both ingress replication tunnels and P2MP multicast forwarding with both ingress replication tunnels and P2MP
tunnels. 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. Multicast tunnels can be either ingress replication tunnels traffic, when both PEs use the same tunnel type. Multicast tunnels
or P2MP tunnels. The solution MUST support optimum replication for can be either ingress replication tunnels or P2MP tunnels. The
both Intra-subnet and Inter-subnet IP multicast traffic: solution MUST support optimum replication for both Intra-subnet and
Inter-subnet IP multicast traffic:
- Non-IP traffic SHALL be forwarded per EVPN baseline [RFC7432] or - 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
skipping to change at page 8, line 39 skipping to change at page 9, line 5
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
The solution SHALL support sources and receivers external to the
tenant domain. i.e., multicast source inside the tenant domain can
have receiver outside the tenant domain and vice versa.
4.12. Tenant RP placement
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
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 [EVPN-IRB] describes the operation for EVPN PEs in IRB mode for
unicast traffic. The same IRB model used for unicast traffic in unicast traffic. The same IRB model used for unicast traffic in
[EVPN-IRB], where an IP-VRF in an EVPN PE is attached to one or more [EVPN-IRB], where an IP-VRF in an EVPN PE is attached to one or more
bridge tables (BTs) via virtual IRB interfaces, is also applicable bridge tables (BTs) via virtual IRB interfaces, is also applicable
for multicast traffic. However, there are some noticeable differences for multicast traffic. However, there are some noticeable differences
between the IRB operation for unicast traffic described in [EVPN-IRB] between the IRB operation for unicast traffic described in [EVPN-IRB]
versus for multicast traffic described in this document. For unicast versus for multicast traffic described in this document. For unicast
traffic, the intra-subnet traffic, is bridged within the MAC-VRF traffic, the intra-subnet traffic, is bridged within the MAC-VRF
skipping to change at page 12, line 34 skipping to change at page 12, line 34
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 1) Unicast route advertisements for IP multicast source
2) Multi-homing of IP multicast sources and receivers 2) Multi-homing of IP multicast sources and receivers
3) Mobility for Tenant's sources and receivers 3) Mobility for Tenant's sources and receivers
4) non-IP multicast traffic handling 4) 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 (or 5) and IPVPN unicast route along route using EVPN route type 2 and IPVPN unicast route along with VRF
with VRF Route Import extended community. EVPN route type 2 (or 5) is Route Import extended community. EVPN route type 2 is advertised with
advertised with the Route Targets corresponding to both IP-VRF and the Route Targets corresponding to both IP-VRF and MAC-VRF/BT;
MAC-VRF/BT; whereas, IPVPN unicast route is advertised with RT whereas, IPVPN unicast route is advertised with RT corresponding to
corresponding to the IP-VRF. When unicast routes are advertised by the IP-VRF. When unicast routes are advertised by MVPN PEs, they are
MVPN PEs, they are advertised using IPVPN unicast route along with advertised using IPVPN unicast route along with VRF Route Import
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 (or 5) and IPVPN unicast route along source using EVPN route type 2 and IPVPN unicast route along with VRF
with VRF Route Import extended community. EVPN route type 2 (or 5) is Route Import extended community. EVPN route type 2 is advertised with
advertised with the Route Targets corresponding to both IP-VRF and the Route Targets corresponding to both IP-VRF and MAC-VRF/BT;
MAC-VRF/BT; whereas, IPVPN unicast route is advertised with RT whereas, IPVPN unicast route is advertised with RT corresponding to
corresponding to the IP-VRF. When the other multi-homing EVPN PEs for the IP-VRF. When the other multi-homing EVPN PEs for that ES receive
that ES receive this unicast EVPN route, they import the route and this unicast EVPN route, they import the route and check to see if
check to see if they have learned the route locally for that ES, if they have learned the route locally for that ES, if they have, then
they have, then they do nothing. But if they have not, then they add they do nothing. But if they have not, then they add the IP and MAC
the IP and MAC addresses to their IP-VRF and MAC-VRF/BT tables addresses to their IP-VRF and MAC-VRF/BT tables respectively with the
respectively with the local interface corresponding to that ES as the local interface corresponding to that ES as the corresponding route
corresponding route adjacency. Furthermore, these PEs advertise an adjacency. Furthermore, these PEs advertise an IPVPN unicast route
IPVPN unicast route along with VRF Route Import extended community along with VRF Route Import extended community and Route Target
and Route Target corresponding to IP-VRF to other remote PEs for that corresponding to IP-VRF to other remote PEs for that MVPN. Therefore,
MVPN. Therefore, the remote PEs learn the unicast route corresponding the remote PEs learn the unicast route corresponding to the source
to the source from all multi-homing PEs associated with that All- from all multi-homing PEs associated with that All- Active Ethernet
Active Ethernet Segment even though one of the multi-homing PEs may Segment even though one of the multi-homing PEs may only have
only have directly learned the IP address of the source. directly learned the IP address of the source.
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
been extended in the EVPN fabric. EVPN-PE may summarize sources (IP
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
and advertises those routes with EVPN route type 5. EVPN host-routes
are advertised as IPVPN host-routes to MVPN-PEs only incase of
seamless interop mode.
Section 6.6 discusses connecting EVPN and MVPN networks with gateway
model. Section 9 extends seamless interop procedures to EVPN only
fabrics as an IRB solution for multicast.
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
EVPN only fabric. No L3VPN provisioning is needed between EVPN-PEs.
In gateway model, EVPN-PE advertises unicast routes as IPVPN routes
along with VRI extended community for all multicast sources attached
behind EVPN-PEs. All IPVPN routes SHOULD be summarized while
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
skipping to change at page 14, line 51 skipping to change at page 15, line 22
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 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 and thus perform the tasks mentioned in the previous section for ACs 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
skipping to change at page 17, line 22 skipping to change at page 17, line 42
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 [RF7432]
BUM procedures and does not get routed via IP-VRF for multicast BUM procedures and does not get routed via IP-VRF for multicast
addresses. So, such BUM traffic will be limited to a given EVI/VLAN addresses. So, such BUM traffic will be limited to a given EVI/VLAN
(e.g., a give subnet); whereas, IP multicast traffic, will be locally (e.g., a give subnet); whereas, IP multicast traffic, will be locally
L2 switched for local interfaces attached on the same subnet and will L2 switched for local interfaces attached on the same subnet and will
be routed for local interfaces attached on a different subnet or for be routed for local interfaces attached on a different subnet or for
forwarding traffic to other EVPN PEs (refer to section 5.1.1 for data forwarding traffic to other EVPN PEs (refer to section 8 for data
plane operation). plane operation).
6.6 EVPN and MVPN interworking with gateway model
The procedures specified in this document offers optimal multicast
forwarding within a data center and also enables seamless
interoperability of multicast traffic between EVPN and MVPN networks,
when same tunnel types are used in the data plane.
There are few other use cases in connecting MVPN networks in the EVPN
fabric other than seamless interop model, where gateway model is used
to interconnect both networks.
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
EVPN-PEs
Case3: MVPN network (MVPN-PEs) which uses different tunnel model
can be directly attached to EVPN fabric.
In gateway model, MVPN routes from one domain are terminated at the
gateway PE and re-originated for another domain.
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.
Also, IPVPN routes need not be advertised inside the fabric. 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
receivers exist both MVPN and EVPN networks. (Two different data
planes are used to send the traffic in the fabric; one for EVPN
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 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 tunnel. Vast ES. We refer to this multicast tunnel as Intra-ES/Intra-Subnet
majority of All-Active multi-homing for TOR devices in DC networks tunnel. Vast majority of All-Active multi-homing for TOR devices in
are just dual-homing which means the multicast flow received by one DC networks are just dual-homing which means the multicast flow
of the dual-homing PE only needs to be sent to the other dual-homing received by one of the dual-homing PE only needs to be sent to the
PE. Therefore, a simple ingress replication tunnel is all that is other dual-homing PE. Therefore, a simple ingress replication tunnel
needed. In case of multi-homing to three or more EVPN PEs, then other is all that is needed. In case of multi-homing to three or more EVPN
tunnel types such as P2MP, MP2MP, BIER, and Assisted Replication can PEs, then other tunnel types such as P2MP, MP2MP, BIER, and Assisted
be considered. It should be noted that this intra-ES tunnel is only Replication can be considered. It should be noted that this intra-ES
needed for All-Active multi-homing and it is not required for Single- tunnel is only needed for All-Active multi-homing and it is not
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], [EVPN-
DF-Framework], or other DF election algorithms to decide who is a DF DF-Framework], or other DF election algorithms to decide who is a DF
for a given BD. If the BD belongs to a tenant that has IRB IP for a given BD. If the BD belongs to a tenant that has IRB IP
multicast enabled for it, then for fixed-mode, each PE sets up an multicast enabled for it, then for fixed-mode, each PE sets up an
intra-ES tunnel to forward IP multicast traffic received locally on intra-ES tunnel to forward IP multicast traffic received locally on
that BD to other multi-homing PE(s) for that ES. Therefore, IP that BD to other multi-homing PE(s) for that ES. Therefore, IP
multicast traffic received via a local attachment circuit is sent on multicast traffic received via a local attachment circuit is sent on
skipping to change at page 18, line 33 skipping to change at page 19, line 34
tunnel is treated as if it is received via its local AC. Thus, the tunnel is treated as if it is received via its local AC. Thus, the
multi-homing PEs cannot receive the same IP multicast flow from an multi-homing PEs cannot receive the same IP multicast flow from an
MVPN tunnel (e.g., over an IRB interface for that BD) because between MVPN tunnel (e.g., over an IRB interface for that BD) because between
a source behind a local AC versus a source behind a remote PE, the PE a source behind a local AC versus a source behind a remote PE, the PE
always chooses its local AC. 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 IP multicast tunnel among themselves. information to setup intra-ES/Intra-Subnet IP multicast tunnel among
themselves.
7.2. Intra-Subnet BUM 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 is
used for transmission of all BUM traffic including user IP multicast used for transmission of all BUM traffic including user IP multicast
traffic. However, for multicast traffic handling in EVPN-IRB PEs, traffic. However, for multicast traffic handling in EVPN-IRB PEs,
this tunnel is used for all broadcast, unknown-unicast, non-IP this tunnel is used for all broadcast, unknown-unicast, non-IP
multicast traffic, and link-local IP multicast traffic - i.e., it is multicast traffic, and link-local IP multicast traffic - i.e., it is
used for all BUM traffic except user IP multicast traffic. This used for all BUM traffic except user IP multicast traffic. This
skipping to change at page 19, line 17 skipping to change at page 20, line 17
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 to form default underlay tunnel Intra-AS I-PMSI A-D route is used for the setup of default
(also called inclusive tunnel) for a tenant IP-VRF. The tunnel underlay tunnel (also called inclusive tunnel) for a tenant IP-
attributes are indicated using PMSI attribute with this route. VRF. The tunnel attributes are indicated using PMSI attribute
with this route.
S-PMSI A-D route is used to form Customer flow specific underlay S-PMSI A-D route is used for the setup of Customer flow specific
tunnels. This enables selective delivery of data to PEs having underlay tunnels. This enables selective delivery of data to PEs
active receivers and optimizes fabric bandwidth utilization. The having active receivers and optimizes fabric bandwidth
tunnel attributes are indicated using PMSI attribute with this utilization. The tunnel attributes are indicated using PMSI
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 and
terminated from/to among IP-VRFs of EVPN/MVPN PEs; whereas, intra- terminated from/to among IP-VRFs of EVPN/MVPN PEs; whereas, intra-
subnet tunnel is originated/terminated among MAC-VRFs of EVPN PEs. 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 [IGMP-PROXY]. IGMP states are built in the corresponding
BDs of the multi-homing EVPN PEs. In [IGMP-PROXY] the DF PE for that BDs of the multi-homing EVPN PEs. In [IGMP-PROXY] the DF PE for that
BD originates an EVPN Selective Multicast Tag route (SMET route) BD originates an EVPN Selective Multicast Tag route (SMET route)
route to other EVPN PEs. However, in here there is no need to use route to other EVPN PEs. However, in here there is no need to use
SMET because the IGMP messages are terminated by the EVPN-IRB PE and SMET because the IGMP messages are terminated by the EVPN-IRB PE and
tenant (*,G) or (S,G) join messages are sent via MVPN Shared Tree tenant (*,G) or (S,G) join messages are sent via MVPN Shared Tree
Join route (route type 6) or Source Tree Join route (route type 7) Join route (route type 6) or Source Tree Join route (route type 7)
respectively of MCAST-VPN NLRI per [RFC6514]. In case of a network respectively of MCAST-VPN NLRI per [RFC6514]. In case of a network
with only IGMP hosts, the preferred mode of operation is that of SPT- with only IGMP hosts, the preferred mode of operation is that of
only per section 14 of [RFC6514]. This mode is only supported for Shortest Path Tree(SPT) per section 14 of [RFC6514]. This mode is
PIM-SM and avoids the RP configuration overhead. Such mode is chosen only supported for PIM-SM and avoids the RP configuration overhead.
by provisioning/ configuration. 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
skipping to change at page 21, line 11 skipping to change at page 22, line 9
L3 OIF when all L2 tenant (S,G) or (*,G) forwarding states is removed L3 OIF when all L2 tenant (S,G) or (*,G) forwarding states is removed
for the MAC-VRF/BT associated with that IRB. Furthermore, tenant for the MAC-VRF/BT associated with that IRB. Furthermore, tenant
(S,G) or (*,G) L3 forwarding state is removed when all of its L3 OIFs (S,G) or (*,G) L3 forwarding state is removed when all of its L3 OIFs
are removed - i.e., all the IRB and L3 interfaces associated with are removed - i.e., all the IRB and L3 interfaces associated with
that tenant (S,G) or (*,G) are removed. 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-ES All-Active ES, then the multicast flow is also sent over the intra-
tunnel among multi-homing PEs. The EVPN PE then sends the multicast ES/Intra-Subnet tunnel among multi-homing PEs. The EVPN PE then sends
traffic over the corresponding IRB interface. The multicast traffic the multicast traffic over the corresponding IRB interface. The
then gets routed in the corresponding IP-VRF and it gets forwarded to multicast traffic then gets routed in the corresponding IP-VRF and it
interfaces in the L3 OIF list which can include other IRB interfaces, gets forwarded to interfaces in the L3 OIF list which can include
other L3 interfaces directly connected to TSes, and the MVPN inter- other IRB interfaces, other L3 interfaces directly connected to TSes,
subnet tunnel which is instantiated by an I-PMSI or S-PMSI tunnel. and the MVPN Inter-Subnet tunnel which is instantiated by an I-PMSI
When the multicast packet is routed within the IP-VRF of the EVPN PE, or S-PMSI tunnel. When the multicast packet is routed within the IP-
its Ethernet header is stripped and its TTL gets decremented as the VRF of the EVPN PE, its Ethernet header is stripped and its TTL gets
result of this IP routing. When the multicast traffic is received on decremented as the result of this IP routing. When the multicast
an IRB interface by the BT corresponding to that interface, it gets traffic is received on an IRB interface by the BT corresponding to
L2 switched and sent over ACs that belong to the L2 OIF list. that interface, it gets L2 switched and sent over 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
skipping to change at page 22, line 26 skipping to change at page 23, line 23
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. Based on past experiences with MVPN over last PEs get decremented.
dozen years for supported IP multicast applications, layer-3
forwarding of intra-subnet multicast traffic should be fine. However, However, if there are applications that require intra-subnet
if there are applications that require intra-subnet multicast traffic multicast traffic to be L2 forwarded, Section 11 discusses some
to be L2 forwarded (e.g., without decrementing TTL value), then options to support applications having TTL value 1. The procedure
[EVPN-IRB-MCAST] proposes a solution to accommodate such discussed in Section 11 may be used to support applications that
applications. 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 via the EVPN unicast the IP-VPN routes in [RFC6514] MUST be carried with the EVPN unicast
routes instead. The construction and processing of the VRI are routes when these routes are used. The construction and processing of
consistent with [RFC6514]. The VRI MUST uniquely identify the PE the VRI are consistent with [RFC6514]. The VRI MUST uniquely identify
which is advertising a multicast source and the IP-VRF it resides in. the PE which is advertising a multicast source and the IP-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). 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
MVPN routes. In data center environment, it is desirable to have this
RT configured using auto-generated method than static configuration.
The following is one recommended model to auto-generate MVPN RT:
- The Global Administrator field of the MVPN RT MAY be set
to BGP AS Number.
- The Local Administrator field of the MVPN RT MAY be set to
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 existence
of at least one remote receiver in the tenant overlay and programs of at least one remote receiver in the tenant overlay and programs
data plane accordingly so that a single copy of multicast data is data plane accordingly so that a single copy of multicast data is
forwarded into the core VRF using tenant VRF tunnel. 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
skipping to change at page 26, line 5 skipping to change at page 26, line 51
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 [INTERCON-EVPN]. Hence, a multicast host
located in either domain, is advertised with the gateway IP address located in either domain, is advertised with the gateway IP address
as the next-hop to the other domain. As a result, PEs view the hosts as the next-hop to the other domain. As a result, PEs view the hosts
in the other domain as directly attached to the gateway and all in the other domain as directly attached to the gateway and all
inter-domain multicast signaling is directed towards the gateway(s). inter-domain multicast signaling is directed towards the gateway(s).
Received MVPN routes type 1-7 from either side of the gateway(s), Received MVPN routes type 1-7 from either side of the gateway(s),
MUST NOT be reflected back to the same side but processed locally and MUST NOT be reflected back to the same side but processed locally and
re-advertised (if needed) to the other side: re-advertised (if needed) to the other side:
- Intra-AS I-PMSI A-D Route: these are distributed within - Intra-AS I-PMSI A-D Route: these are distributed within
each domain to form the overlay tunnels which terminate at each domain to form the overlay tunnels which terminate at
gateway(s). They are not passed to the other side of the gateway(s). They are not passed to the other side of the
gateway(s). gateway(s).
- C-Multicast Route: joins are imported into the corresponding - C-Multicast Route: joins are imported into the corresponding
IP-VRF on each gateway and advertised as a new route to the IP-VRF on each gateway and advertised as a new route to the
other side with the following modifications (the rest of other side with the following modifications (the rest of
NLRI fields and path attributes remain on-touched): NLRI fields and path attributes remain on-touched):
* Route-Distinguisher is set to that of the IP-VRF * Route-Distinguisher is set to that of the IP-VRF
* Route-target is set to the exported route-target * Route-target is set to the exported route-target
list on IP-VRF list on IP-VRF
* The PMSI tunnel attribute and BGP Encapsulation * The PMSI tunnel attribute and BGP Encapsulation
extended community will be modified according to extended community will be modified according to
section 8 section 8
* Next-hop will be set to the IP address which * Next-hop will be set to the IP address which
represents the gateway on either domain represents the gateway on either domain
- Source Active A-D Route: same as joins - Source Active A-D Route: same as joins
- S-PMSI A-D Route: these are passed to the other side to form - 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 selective PMSI tunnels per every (C-S,C-G) from the gateway
to the PEs in the other domain provided it contains to the PEs in the other domain provided it contains
receivers for the given (C-S, C-G). Similar modifications receivers for the given (C-S, C-G). Similar modifications
made to joins are made to the newly originated S-PMSI. 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.
skipping to change at page 27, line 4 skipping to change at page 27, line 49
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. IANA Considerations 11. Supporting application with TTL value 1
There is no additional IANA considerations for PBB-EVPN beyond what It is possible that some deployments may have a host on the tenant
is already described in [RFC7432]. domain that sends multicast traffic with TTL value 1. The interested
receiver for that traffic flow may be attached to different PEs on
the same subnet. The procedures specified in section 6 always routes
the traffic between PEs for both intra and inter subnet traffic.
Hence traffic with TTL value 1 is dropped due to the nature of
routing.
12. Security Considerations This section discusses few possible ways to support traffic having
TTL value 1. Implementation MAY support any of the following model.
11.1. Policy based model
Policies may be used to enforce EVPN BUM procedure for traffic flows
with TTL value 1. Traffic flow that matches the policy is excluded
from seamless interop procedure specified in this document, hence TTL
decrement issue will not apply.
11.2. Exercising BUM procedure for VLAN/BD
Servers/hosts sending the traffic with TTL value 1 may be attached to
a separate VLAN/BD, where multicast routing is disabled. When
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
such traffic may be set to BD interface, where the source is
attached.
11.3. Intra-subnet bridging
The procedure specified in the section enables a PE to detect an
attached subnet source (i.e., source that is directly attached in the
tenant BD/VLAN). By applying the following procedure for the
attached source, Traffic flows having TTL value 1 can be supported.
- On the ingress PE, do the bridging on the interface towards the
core interface
- On the egress side, make a decision whether to bridge or route
at the outgoing interface (OIF) based on whether the source is
attached to the OIF's BD/VLAN or not.
Recent ASIC supports single lookup forwarding for brigading and
routing (L2+L3). The procedure mentioned here leverages this ASIC
capability.
PE1
+------------+
S11 +---+(BD1) | +---------+
| \ | | |
|(IP-VRF)-(CORE)| |
| / | | |
R12 +---+(BD2) | | |
+------------+ | |
| |
PE2 | VXLAN. |
+------------+ | |
R21 +---+(BD1) | | |
| \ | | |
|(IP-VRF)-(CORE)| |
| / | | |
R22+----+(BD3) | +---------+
+------------+
Figure 3 Intra-subnet bridging
Consider the above picture. In the picture
- PE1 and PE2 are seamless interop capable PEs
- S11 is a multicast host directly attached to PE1 in BD1
- Source S11 sends traffic to Group G11
- R21, R22 are IGMP receivers for group G11
- R21 and R22 are attached to BD1 and BD3 respectively at PE2.
When source S11 starts sending the traffic, PE1 learns the source and
announces the source using MVPN procedures to the remote PEs.
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
the source information from PE1, it installs the route (S11, G11) at
the tenant VRF with RPF as CORE interface.
PE2 inherits (*, G11) OIFs to (S11, G11) entry. While inheriting OIF,
PE2 checks whether source is attached to OIF's subnet. OIF matching
source subnet is added with flag indicating bridge only interface. In
case of (S11, G11) entry, BD1 is added as the bridge 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.
At Ingress PE(PE1), CORE interface is added to (S11, G11) entry as an
OIF (outgoing interface) with a flag indicating that bridge only
interface. With this procedure, ingress PE(PE1) bridges the traffic
on CORE interface. (PE1 retains the TTL and source-MAC). The traffic
is encapsulated with VNI associated with CORE interface(L3VNI). PE1
also routes the traffic for R12 which is attached to BD2 on the same
device.
PE2 decapsulates the traffic from PE1 and does inner lookup on the
tenant VRF associated with incoming VNI. Traffic lookup on the tenant
VRF yields (S11, G11) entry as the matching entry. Traffic gets
bridged on BD1 (PE2 retains the TTL and source-MAC) since the OIF is
marked as bridge only interface. Traffic gets routed on BD2.
12. Interop with L2 EVPN PEs
A gateway device is needed to do interop between EVPN PEs that
support seamless interop procedure specified in this document and
native EVPN-PEs(L2EVPN PE). The gateway device uses BUM tunnel when
interworking with L2EVPN-PEs.
Interop procedure will be covered in the next version of the draft.
13. Connecting external Multicast networks or PIM routers.
External multicast networks or PIM routers can be attached to any
seamless interop capable EVPN-PEs or set of EVPN-PEs. Multicast
network or PIM router can also be attached to any IRB enabled BDI
interface or L3 enabled interface or set of interfaces. The fabric
can be used as a Transit network. All PIM signaling is terminated at
EVPN-PEs.
No additional procedures are required while connecting external
multicast networks.
14. RP handling
This section describes various RP models for a tenant VRF. The RP
model SHOULD be consistent across all EVPN-PEs for given group/group
range in the tenant VRF.
14.1. Various RP deployment options
14.1.1. RP-less mode
EVPN fabric without having any external multicast network/attached
MVPN network, doesn't need RP configuration. A configuration option
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
advertise all attached sources to remote EVPN PEs using procedure
specified in [RFC 6514].
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
mode, traffic is always forwarded based on (C-S,C-G) state.
14.1.2. Fabric anycast RP
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 MUST advertise all sources behind that PE to other EVPN PEs using
procedure specified in [RFC 6514]. In this model, Sources may be
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
register terminating at RP interface at the tenant VRF side)
In RP-less mode and Fabric anycast RP mode, EVPN-PE operates SPT-only
mode as per section 14 of RFC 6514.
14.1.3. Static RP
The procedure specified in this document supports configuring EVPN
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
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
section 13 of RFC 6514.
14.1.4. Co-existence of Fabric anycast RP and external RP
External multicast network using its own RP may be connected to EVPN
fabric operating with Fabric anycast RP mode. In this case, subset of
EVPN-PEs may be designated as border leafs. Anycast RP may be
configured between border leafs and external RP. Border leafs
originates SA-AD routes for external sources towards fabric PEs.
Border leaf acts as FHR for the sources inside the fabric.
Configuration option may be provided to define the PE role as BL.
14.2. RP configuration options
PIM Bidir and PIM-SM ASM mode require Rendezvous point (RP)
configuration, which acts as a shared root for a multicast shared
tree. RP can be configured using static configuration or by using BSR
or Auto-RP procedures on the tenant VRF. This document only discusses
static RP configuration. The use of BSR or Auto-RP procedure in the
EVPN fabric is beyond the scope of this document.
15. IANA Considerations
IANA is requested to assign new flags in the "Multicast Flags
Extended Community Flags" registry for the following.
o Seamless interop capable PE
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.
13. Acknowledgements 17. Acknowledgements
The authors would like to thank Niloofar Fazlollahi, Aamod The authors would like to thank Niloofar Fazlollahi, Aamod
Vyavaharkar, Kesavan Thiruvenkatasamy, and Swadesh Agrawal for their Vyavaharkar, Raunak Banthia, and Swadesh Agrawal for their
discussions and contributions. discussions and contributions.
14. References 18. References
14.1. Normative References 18.1. Normative References
[RFC7432] A. Sajassi, et al., "BGP MPLS Based Ethernet VPN", RFC [RFC7432] A. Sajassi, et al., "BGP MPLS Based Ethernet VPN", RFC
7432 , February 2015. 7432 , February 2015.
[RFC8365] A. Sajassi, et al., "A Network Virtualization Overlay [RFC8365] A. Sajassi, et al., "A Network Virtualization Overlay
Solution using EVPN", RFC 8365, February 2018. Solution using EVPN", RFC 8365, February 2018.
[RFC6513] E. Rosen, et al., "Multicast in MPLS/BGP IP VPNs", RFC6513, [RFC6513] E. Rosen, et al., "Multicast in MPLS/BGP IP VPNs", RFC6513,
February 2012. February 2012.
skipping to change at page 28, line 10 skipping to change at page 33, line 6
Multicast in MPLS/BGP IP VPNs", RFC6514, February 2012. Multicast in MPLS/BGP IP VPNs", RFC6514, February 2012.
[EVPN-IRB] A. Sajassi, et al., "Integrated Routing and Bridging in [EVPN-IRB] A. Sajassi, et al., "Integrated Routing and Bridging in
EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-03, EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-03,
February 2017. February 2017.
[EVPN-IRB-MCAST] A. Rosen, et al., "EVPN Optimized Inter-Subnet [EVPN-IRB-MCAST] A. Rosen, et al., "EVPN Optimized Inter-Subnet
Multicast (OISM) Forwarding", draft-lin-bess-evpn-irb- Multicast (OISM) Forwarding", draft-lin-bess-evpn-irb-
mcast-04, October 24, 2017. mcast-04, October 24, 2017.
14.2. Informative References 18.2. Informative References
[RFC7080] A. Sajassi, et al., "Virtual Private LAN Service (VPLS) [RFC7080] A. Sajassi, et al., "Virtual Private LAN Service (VPLS)
Interoperability with Provider Backbone Bridges", RFC Interoperability with Provider Backbone Bridges", RFC
7080, December 2013. 7080, December 2013.
[RFC7209] D. Thaler, et al., "Requirements for Ethernet VPN (EVPN)", [RFC7209] D. Thaler, et al., "Requirements for Ethernet VPN (EVPN)",
RFC 7209, May 2014. RFC 7209, May 2014.
[RFC4389] A. Sajassi, et al., "Neighbor Discovery Proxies (ND [RFC4389] A. Sajassi, et al., "Neighbor Discovery Proxies (ND
Proxy)", RFC 4389, April 2006. Proxy)", RFC 4389, April 2006.
skipping to change at page 28, line 42 skipping to change at page 34, line 5
tunnel-encaps-06, work in progress, June 2017. tunnel-encaps-06, work in progress, June 2017.
[EVPN-IGMP-PROXY] A. Sajassi, et. al., "IGMP and MLD Proxy for EVPN", [EVPN-IGMP-PROXY] A. Sajassi, et. al., "IGMP and MLD Proxy for EVPN",
draft-ietf-bess-evpn-igmp-mld-proxy-01, work in progress, draft-ietf-bess-evpn-igmp-mld-proxy-01, work in progress,
March 2018. March 2018.
[EVPN-PIM-PROXY] J. Rabadan, et. al., "PIM Proxy in EVPN Networks", [EVPN-PIM-PROXY] J. Rabadan, et. al., "PIM Proxy in EVPN Networks",
draft-skr-bess-evpn-pim-proxy-00, work in progress, July draft-skr-bess-evpn-pim-proxy-00, work in progress, July
3, 2017. 3, 2017.
15. Authors' Addresses 19. Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Csco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
Email: sajassi@cisco.com Email: sajassi@cisco.com
Kesavan Thiruvenkatasamy
Cisco
170 West Tasman Drive
San Jose, CA 95134, US
Email: kethiruv@cisco.com
Samir Thoria Samir Thoria
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
Email: sthoria@cisco.com Email: sthoria@cisco.com
Ashutosh Gupta Ashutosh Gupta
Avi Networks Avi Networks
Email: ashutosh@avinetworks.com Email: ashutosh@avinetworks.com
 End of changes. 52 change blocks. 
167 lines changed or deleted 468 lines changed or added

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