draft-ietf-bess-evpn-irb-mcast-00.txt   draft-ietf-bess-evpn-irb-mcast-01.txt 
BESS W. Lin BESS W. Lin
Internet-Draft Z. Zhang Internet-Draft Z. Zhang
Intended status: Standards Track J. Drake Intended status: Standards Track J. Drake
Expires: August 17, 2018 E. Rosen, Ed. Expires: January 17, 2019 E. Rosen, Ed.
Juniper Networks, Inc. Juniper Networks, Inc.
J. Rabadan J. Rabadan
Nokia Nokia
A. Sajassi A. Sajassi
Cisco Systems Cisco Systems
February 13, 2018 July 16, 2018
EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding
draft-ietf-bess-evpn-irb-mcast-00 draft-ietf-bess-evpn-irb-mcast-01
Abstract Abstract
Ethernet VPN (EVPN) provides a service that allows a single Local Ethernet VPN (EVPN) provides a service that allows a single Local
Area Network (LAN), i.e., a single IP subnet, to be distributed over Area Network (LAN), comprising a single IP subnet, to be divided into
multiple sites. The sites are interconnected by an IP or MPLS multiple "segments". Each segment may be located at a different
backbone. Intra-subnet traffic (either unicast or multicast) always site, and the segments are interconnected by an IP or MPLS backbone.
appears to the endusers to be bridged, even when it is actually Intra-subnet traffic (either unicast or multicast) always appears to
carried over the IP backbone. When a single "tenant" owns multiple the endusers to be bridged, even when it is actually carried over the
such LANs, EVPN also allows IP unicast traffic to be routed between IP or MPLS backbone. When a single "tenant" owns multiple such LANs,
those LANs. This document specifies new procedures that allow inter- EVPN also allows IP unicast traffic to be routed between those LANs.
subnet IP multicast traffic to be routed among the LANs of a given This document specifies new procedures that allow inter-subnet IP
tenant, while still making intra-subnet IP multicast traffic appear multicast traffic to be routed among the LANs of a given tenant,
to be bridged. These procedures can provide optimal routing of the while still making intra-subnet IP multicast traffic appear to be
inter-subnet multicast traffic, and do not require any such traffic bridged. These procedures can provide optimal routing of the inter-
to leave a given router and then reenter that same router. These subnet multicast traffic, and do not require any such traffic to
leave a given router and then reenter that same router. These
procedures also accommodate IP multicast traffic that needs to travel procedures also accommodate IP multicast traffic that needs to travel
to or from systems that are outside the EVPN domain. to or from systems that are outside the EVPN domain.
Status of This Memo Status of This Memo
This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on August 17, 2018. This Internet-Draft will expire on January 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
1.1.1. Segments, Broadcast Domains, and Tenants . . . . . . 4 1.1.1. Segments, Broadcast Domains, and Tenants . . . . . . 4
1.1.2. Inter-BD (Inter-Subnet) IP Traffic . . . . . . . . . 5 1.1.2. Inter-BD (Inter-Subnet) IP Traffic . . . . . . . . . 5
1.1.3. EVPN and IP Multicast . . . . . . . . . . . . . . . . 6 1.1.3. EVPN and IP Multicast . . . . . . . . . . . . . . . . 6
1.1.4. BDs, MAC-VRFS, and EVPN Service Models . . . . . . . 7 1.1.4. BDs, MAC-VRFS, and EVPN Service Models . . . . . . . 7
1.2. Need for EVPN-aware Multicast Procedures . . . . . . . . 7 1.2. Need for EVPN-aware Multicast Procedures . . . . . . . . 7
1.3. Additional Requirements That Must be Met by the Solution 8 1.3. Additional Requirements That Must be Met by the Solution 8
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10
1.5. Model of Operation: Overview . . . . . . . . . . . . . . 12 1.5. Model of Operation: Overview . . . . . . . . . . . . . . 12
1.5.1. Control Plane . . . . . . . . . . . . . . . . . . . . 12 1.5.1. Control Plane . . . . . . . . . . . . . . . . . . . . 12
1.5.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 14 1.5.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 14
2. Detailed Model of Operation . . . . . . . . . . . . . . . . . 16 2. Detailed Model of Operation . . . . . . . . . . . . . . . . . 17
2.1. Supplementary Broadcast Domain . . . . . . . . . . . . . 16 2.1. Supplementary Broadcast Domain . . . . . . . . . . . . . 17
2.2. When is a Route About/For/From a Particular BD . . . . . 17 2.2. Detecting When a Route is About/For/From a Particular BD 18
2.3. Use of IRB Interfaces at Ingress PE . . . . . . . . . . . 18 2.3. Use of IRB Interfaces at Ingress PE . . . . . . . . . . . 21
2.4. Use of IRB Interfaces at an Egress PE . . . . . . . . . . 19 2.4. Use of IRB Interfaces at an Egress PE . . . . . . . . . . 23
2.5. Announcing Interest in (S,G) . . . . . . . . . . . . . . 20 2.5. Announcing Interest in (S,G) . . . . . . . . . . . . . . 23
2.6. Tunneling Frames from Ingress PE to Egress PEs . . . . . 21 2.6. Tunneling Frames from Ingress PE to Egress PEs . . . . . 24
2.7. Advanced Scenarios . . . . . . . . . . . . . . . . . . . 22 2.7. Advanced Scenarios . . . . . . . . . . . . . . . . . . . 25
3. EVPN-aware Multicast Solution Control Plane . . . . . . . . . 22 3. EVPN-aware Multicast Solution Control Plane . . . . . . . . . 26
3.1. Supplementary Broadcast Domain (SBD) and Route Targets . 22 3.1. Supplementary Broadcast Domain (SBD) and Route Targets . 26
3.2. Advertising the Tunnels Used for IP Multicast . . . . . . 23 3.2. Advertising the Tunnels Used for IP Multicast . . . . . . 27
3.2.1. Constructing SBD Routes . . . . . . . . . . . . . . . 24 3.2.1. Constructing Routes for the SBD . . . . . . . . . . . 27
3.2.1.1. Constructing an SBD-IMET Route . . . . . . . . . 24 3.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 28
3.2.1.2. Constructing an SBD-SMET Route . . . . . . . . . 25 3.2.3. Assisted Replication . . . . . . . . . . . . . . . . 29
3.2.1.3. Constructing an SBD-SPMSI Route . . . . . . . . . 25 3.2.4. BIER . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 26 3.2.5. Inclusive P2MP Tunnels . . . . . . . . . . . . . . . 31
3.2.3. Assisted Replication . . . . . . . . . . . . . . . . 26
3.2.4. BIER . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.5. Inclusive P2MP Tunnels . . . . . . . . . . . . . . . 28
3.2.5.1. Using the BUM Tunnels as IP Multicast Inclusive 3.2.5.1. Using the BUM Tunnels as IP Multicast Inclusive
Tunnels . . . . . . . . . . . . . . . . . . . . . 28 Tunnels . . . . . . . . . . . . . . . . . . . . . 31
3.2.5.1.1. RSVP-TE P2MP . . . . . . . . . . . . . . . . 28
3.2.5.1.2. mLDP or PIM . . . . . . . . . . . . . . . . . 29
3.2.5.2. Using Wildcard S-PMSI A-D Routes to Advertise 3.2.5.2. Using Wildcard S-PMSI A-D Routes to Advertise
Inclusive Tunnels Specific to IP Multicast . . . 30 Inclusive Tunnels Specific to IP Multicast . . . 32
3.2.6. Selective Tunnels . . . . . . . . . . . . . . . . . . 30 3.2.6. Selective Tunnels . . . . . . . . . . . . . . . . . . 33
3.3. Advertising SMET Routes . . . . . . . . . . . . . . . . . 31 3.3. Advertising SMET Routes . . . . . . . . . . . . . . . . . 34
4. Constructing Multicast Forwarding State . . . . . . . . . . . 33 4. Constructing Multicast Forwarding State . . . . . . . . . . . 36
4.1. Layer 2 Multicast State . . . . . . . . . . . . . . . . . 33 4.1. Layer 2 Multicast State . . . . . . . . . . . . . . . . . 36
4.1.1. Constructing the OIF List . . . . . . . . . . . . . . 34 4.1.1. Constructing the OIF List . . . . . . . . . . . . . . 37
4.1.2. Data Plane: Applying the OIF List to an (S,G) Frame . 35 4.1.2. Data Plane: Applying the OIF List to an (S,G) Frame . 38
4.1.2.1. Eligibility of an AC to Receive a Frame . . . . . 35 4.1.2.1. Eligibility of an AC to Receive a Frame . . . . . 38
4.1.2.2. Applying the OIF List . . . . . . . . . . . . . . 35 4.1.2.2. Applying the OIF List . . . . . . . . . . . . . . 38
4.2. Layer 3 Forwarding State . . . . . . . . . . . . . . . . 37 4.2. Layer 3 Forwarding State . . . . . . . . . . . . . . . . 40
5. Interworking with non-OISM EVPN-PEs . . . . . . . . . . . . . 37 5. Interworking with non-OISM EVPN-PEs . . . . . . . . . . . . . 41
5.1. IPMG Designated Forwarder . . . . . . . . . . . . . . . . 40 5.1. IPMG Designated Forwarder . . . . . . . . . . . . . . . . 43
5.2. Ingress Replication . . . . . . . . . . . . . . . . . . . 40 5.2. Ingress Replication . . . . . . . . . . . . . . . . . . . 44
5.2.1. Ingress PE is non-OISM . . . . . . . . . . . . . . . 42 5.2.1. Ingress PE is non-OISM . . . . . . . . . . . . . . . 45
5.2.2. Ingress PE is OISM . . . . . . . . . . . . . . . . . 43 5.2.2. Ingress PE is OISM . . . . . . . . . . . . . . . . . 47
5.3. P2MP Tunnels . . . . . . . . . . . . . . . . . . . . . . 44 5.3. P2MP Tunnels . . . . . . . . . . . . . . . . . . . . . . 48
6. Traffic to/from Outside the EVPN Tenant Domain . . . . . . . 44 6. Traffic to/from Outside the EVPN Tenant Domain . . . . . . . 48
6.1. Layer 3 Interworking via EVPN OISM PEs . . . . . . . . . 45 6.1. Layer 3 Interworking via EVPN OISM PEs . . . . . . . . . 48
6.1.1. General Principles . . . . . . . . . . . . . . . . . 45 6.1.1. General Principles . . . . . . . . . . . . . . . . . 48
6.1.2. Interworking with MVPN . . . . . . . . . . . . . . . 47 6.1.2. Interworking with MVPN . . . . . . . . . . . . . . . 51
6.1.2.1. MVPN Sources with EVPN Receivers . . . . . . . . 49 6.1.2.1. MVPN Sources with EVPN Receivers . . . . . . . . 53
6.1.2.1.1. Identifying MVPN Sources . . . . . . . . . . 49 6.1.2.1.1. Identifying MVPN Sources . . . . . . . . . . 53
6.1.2.1.2. Joining a Flow from an MVPN Source . . . . . 50 6.1.2.1.2. Joining a Flow from an MVPN Source . . . . . 54
6.1.2.2. EVPN Sources with MVPN Receivers . . . . . . . . 52 6.1.2.2. EVPN Sources with MVPN Receivers . . . . . . . . 56
6.1.2.2.1. General procedures . . . . . . . . . . . . . 52 6.1.2.2.1. General procedures . . . . . . . . . . . . . 56
6.1.2.2.2. Any-Source Multicast (ASM) Groups . . . . . . 53 6.1.2.2.2. Any-Source Multicast (ASM) Groups . . . . . . 57
6.1.2.2.3. Source on Multihomed Segment . . . . . . . . 54 6.1.2.2.3. Source on Multihomed Segment . . . . . . . . 58
6.1.2.3. Obtaining Optimal Routing of Traffic Between MVPN 6.1.2.3. Obtaining Optimal Routing of Traffic Between MVPN
and EVPN . . . . . . . . . . . . . . . . . . . . 55 and EVPN . . . . . . . . . . . . . . . . . . . . 59
6.1.2.4. DR Selection . . . . . . . . . . . . . . . . . . 55 6.1.2.4. Selecting the MEG SBD-DR . . . . . . . . . . . . 59
6.1.3. Interworking with 'Global Table Multicast' . . . . . 56 6.1.3. Interworking with 'Global Table Multicast' . . . . . 60
6.1.4. Interworking with PIM . . . . . . . . . . . . . . . . 56 6.1.4. Interworking with PIM . . . . . . . . . . . . . . . . 60
6.1.4.1. Source Inside EVPN Domain . . . . . . . . . . . . 57 6.1.4.1. Source Inside EVPN Domain . . . . . . . . . . . . 61
6.1.4.2. Source Outside EVPN Domain . . . . . . . . . . . 58 6.1.4.2. Source Outside EVPN Domain . . . . . . . . . . . 62
6.2. Interworking with PIM via an External PIM Router . . . . 59 6.2. Interworking with PIM via an External PIM Router . . . . 63
7. Using an EVPN Tenant Domain as an Intermediate (Transit) 7. Using an EVPN Tenant Domain as an Intermediate (Transit)
Network for Multicast traffic . . . . . . . . . . . . . . . . 60 Network for Multicast traffic . . . . . . . . . . . . . . . . 64
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
9. Security Considerations . . . . . . . . . . . . . . . . . . . 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 67
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 67
11.1. Normative References . . . . . . . . . . . . . . . . . . 62 11.1. Normative References . . . . . . . . . . . . . . . . . . 67
11.2. Informative References . . . . . . . . . . . . . . . . . 64 11.2. Informative References . . . . . . . . . . . . . . . . . 69
Appendix A. Integrated Routing and Bridging . . . . . . . . . . 65 Appendix A. Integrated Routing and Bridging . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
1.1. Background 1.1. Background
Ethernet VPN (EVPN) [RFC7432] provides a Layer 2 VPN (L2VPN) Ethernet VPN (EVPN) [RFC7432] provides a Layer 2 VPN (L2VPN)
solution, which allows IP backbone provider to offer ethernet service solution, which allows IP backbone provider to offer ethernet service
to a set of customers, known as "tenants". to a set of customers, known as "tenants".
In this section (as well as in [EVPN-IRB]), we provide some essential In this section (as well as in [EVPN-IRB]), we provide some essential
skipping to change at page 4, line 50 skipping to change at page 4, line 46
any type of system, physical or virtual, host or router, etc., that any type of system, physical or virtual, host or router, etc., that
can attach to an ethernet. can attach to an ethernet.
When two TSes are on the same segment, traffic between them does not When two TSes are on the same segment, traffic between them does not
pass through an EVPN-PE. When two TSes are on different segments of pass through an EVPN-PE. When two TSes are on different segments of
the same BD, traffic between them does pass through an EVPN-PE. the same BD, traffic between them does pass through an EVPN-PE.
When two TSes, say TS1 and TS2 are on the same BD, then: When two TSes, say TS1 and TS2 are on the same BD, then:
o If TS1 knows the MAC address of TS2, TS1 can send unicast ethernet o If TS1 knows the MAC address of TS2, TS1 can send unicast ethernet
frames to TS2. TS2 will receive the frames unaltered. That is, frames to TS2. TS2 will receive the frames unaltered.
TS1's MAC address will be in the MAC Source Address field. If the
frame contains an IP datagram, the IP header is not modified in
any way during the transmission.
o If TS1 broadcasts an ethernet frame, TS2 will receive the o If TS1 broadcasts an ethernet frame, TS2 will receive the
unaltered frame. unaltered frame.
o If TS1 multicasts an ethernet frame, TS2 will receive the o If TS1 multicasts an ethernet frame, TS2 will receive the
unaltered frame, as long as TS2 has been provisioned to receive unaltered frame, as long as TS2 has been provisioned to receive
ethernet multicasts. ethernet multicasts.
When we say that TS2 receives an unaltered frame from TS1, we mean When we say that TS2 receives an unaltered frame from TS1, we mean
that the frame still contains TS1's MAC address, and that no that the frame still contains TS1's MAC address, and that no
alteration of the frame's payload has been done. alteration of the frame's payload (and consequently, no alteration of
the payload's IP header) has been made.
EVPN allows a single segment to be attached to multiple PE routers. EVPN allows a single segment to be attached to multiple PE routers.
This is known as "EVPN multi-homing". EVPN has procedures to ensure This is known as "EVPN multi-homing". Suppose a given segment is
that a frame from a given segment, arriving at a particular PE attached to both PE1 and PE2, and suppose PE1 receives a frame from
router, cannot be returned to that segment via a different PE router. that segment. It may be necessary for PE1 to send the frame over the
This is particularly important for multicast, because a frame backbone to PE2. EVPN has procedures to ensure that such a frame
arriving at a PE from a given segment will already have been seen by cannot be sent by PE2 back to its originating segment. This is
all systems on the segment that need to see it. If the frame were particularly important for multicast, because a frame arriving at PE1
sent back to the originating segment, receivers on that segment would from a given segment will already have been seen by all the systems
on that segment that need to see it. If the frame were sent back to
the originating segment by PE2, receivers on that segment would
receive the packet twice. Even worse, the frame might be sent back receive the packet twice. Even worse, the frame might be sent back
to a PE, which could cause an infinite loop. to PE1, which could cause an infinite loop.
1.1.2. Inter-BD (Inter-Subnet) IP Traffic 1.1.2. Inter-BD (Inter-Subnet) IP Traffic
If a given tenant has multiple BDs, the tenant may wish to allow IP If a given tenant has multiple BDs, the tenant may wish to allow IP
communication among these BDs. Such a set of BDs is known as an communication among these BDs. Such a set of BDs is known as an
"EVPN Tenant Domain" or just a "Tenant Domain". "EVPN Tenant Domain" or just a "Tenant Domain".
If tenant systems TS1 and TS2 are not in the same BD, then they do If tenant systems TS1 and TS2 are not in the same BD, then they do
not receive unaltered ethernet frames from each other. In order for not receive unaltered ethernet frames from each other. In order for
TS1 to send traffic to TS2, TS1 encapsulates an IP datagram inside an TS1 to send traffic to TS2, TS1 encapsulates an IP datagram inside an
ethernet frame, and uses ethernet to send these frames to an IP ethernet frame, and uses ethernet to send these frames to an IP
router. The router decapsulates the IP datagram, does the IP router. The router decapsulates the IP datagram, does the IP
processing, and re-encapsulates the datagram for ethernet. The MAC processing, and re-encapsulates the datagram for ethernet. The MAC
source address field now has the MAC address of the router, not of source address field now has the MAC address of the router, not of
TS1. The TTL field of the IP datagram should be decremented by TS1. The TTL field of the IP datagram should be decremented by
exactly 1; this hides the structure of the provider's IP backbone exactly 1, even if the frame needs to be sent from one PE to another.
from the tenants. The structure of the provider's IP backbone is thus hidden from the
tenants.
EVPN accommodates the need for inter-BD communication within a Tenant EVPN accommodates the need for inter-BD communication within a Tenant
Domain by providing an integrated L2/L3 service for unicast IP Domain by providing an integrated L2/L3 service for unicast IP
traffic. EVPN's Integrated Routing and Bridging (IRB) functionality traffic. EVPN's Integrated Routing and Bridging (IRB) functionality
is specified in [EVPN-IRB]. Each BD in a Tenant Domain is assumed to is specified in [EVPN-IRB]. Each BD in a Tenant Domain is assumed to
be a single IP subnet, and each IP subnet within a a given Tenant be a single IP subnet, and each IP subnet within a a given Tenant
Domain is assumed to be a single BD. EVPN's IRB functionality allows Domain is assumed to be a single BD. EVPN's IRB functionality allows
IP traffic to travel from one BD to another, and ensures that proper IP traffic to travel from one BD to another, and ensures that proper
IP processing (e.g., TTL decrement) is done. IP processing (e.g., TTL decrement) is done.
skipping to change at page 6, line 32 skipping to change at page 6, line 30
[EVPN-IRB] and [EVPN_IP_Prefix] cover inter-subnet (inter-BD) IP [EVPN-IRB] and [EVPN_IP_Prefix] cover inter-subnet (inter-BD) IP
unicast forwarding, but they do not cover inter-subnet IP multicast unicast forwarding, but they do not cover inter-subnet IP multicast
forwarding. forwarding.
[RFC7432] covers intra-subnet (intra-BD) ethernet multicast. The [RFC7432] covers intra-subnet (intra-BD) ethernet multicast. The
intra-subnet ethernet multicast procedures of [RFC7432] are used for intra-subnet ethernet multicast procedures of [RFC7432] are used for
ethernet Broadcast traffic, for ethernet unicast traffic whose MAC ethernet Broadcast traffic, for ethernet unicast traffic whose MAC
Destination Address field contains an Unknown address, and for Destination Address field contains an Unknown address, and for
ethernet traffic whose MAC Destination Address field contains an ethernet traffic whose MAC Destination Address field contains an
ethernet Multicast MAC address. These three classes of traffic are ethernet Multicast MAC address. These three classes of traffic are
known collectively as "BUM traffic" (Broadcast/UnknownUnicast/ known collectively as "BUM traffic" (Broadcast/Unknown-Unicast/
Multicast), and the procedures for handling BUM traffic are known as Multicast), and the procedures for handling BUM traffic are known as
"BUM procedures". "BUM procedures".
[IGMP-Proxy] extends the intra-subnet ethernet multicast procedures [IGMP-Proxy] extends the intra-subnet ethernet multicast procedures
by adding procedures that are specific to, and optimized for, the use by adding procedures that are specific to, and optimized for, the use
of IP multicast within a subnet. However,that document does not of IP multicast within a subnet. However,that document does not
cover inter-subnet IP multicast. cover inter-subnet IP multicast.
The purpose of this document is to specify procedures for EVPN that The purpose of this document is to specify procedures for EVPN that
provide optimized IP multicast functionality within an EVPN tenant provide optimized IP multicast functionality within an EVPN tenant
domain. This document also specifies procedures that allow IP domain. This document also specifies procedures that allow IP
multicast packets to be sourced from or destined to systems outside multicast packets to be sourced from or destined to systems outside
the Tenant Domain. We refer to the entire set of these procedures as the Tenant Domain. We refer to the entire set of these procedures as
"OISM" (Optimized Inter-Subnet Multicast) procedures. "OISM" (Optimized Inter-Subnet Multicast) procedures.
In order to support the OISM procedures specified in this document, In order to support the OISM procedures specified in this document,
an EVPN-PE MUST also support [EVPN-IRB] and [IGMP-Proxy]. an EVPN-PE MUST also support [EVPN-IRB] and [IGMP-Proxy]. (However,
certain of the procedures in [IGMP-Proxy] are modified when OISM is
supported.)
1.1.4. BDs, MAC-VRFS, and EVPN Service Models 1.1.4. BDs, MAC-VRFS, and EVPN Service Models
[RFC7432] defines the notion of "MAC-VRF". A MAC-VRF contains one or [RFC7432] defines the notion of "MAC-VRF". A MAC-VRF contains one or
more "Bridge Tables" (see section 3 of [RFC7432] for a discussion of more "Bridge Tables" (see section 3 of [RFC7432] for a discussion of
this terminology), each of which represents a single Broadcast this terminology), each of which represents a single Broadcast
Domain. Domain.
In the IRB model (outlined in Appendix A) a L3 routing instance has In the IRB model (outlined in Appendix A) a L3 routing instance has
one IRB interface per BD, NOT one per MAC-VRF. The procedures of one IRB interface per BD, NOT one per MAC-VRF. This document does
this document are intended to work with all the EVPN service models. not distinguish between a "Broadcast Domain" and a "Bridge Table",
This document does not distinguish between a "Broadcast Domain" and a and will use the terms interchangeably (or will use the acronym "BD"
"Bridge Table", and will use the terms interchangeably (or will use to refer to either). The way the BDs are grouped into MAC-VRFs is
the acronym "BD" to refer to either). The way the BDs are grouped not relevant to the procedures specified in this document.
into MAC-VRFs is not relevant to the procedures specified in this
document.
Section 6 of [RFC7432] also defines several different EVPN service Section 6 of [RFC7432] also defines several different EVPN service
models: models:
o In the "vlan-based service", each MAC-VRF contains one "bridge o In the "vlan-based service", each MAC-VRF contains one "bridge
table", where the bridge table corresponds to a particular Virtual table", where the bridge table corresponds to a particular Virtual
LAN (VLAN). (See section 3 of [RFC7432] for a discussion of this LAN (VLAN). (See section 3 of [RFC7432] for a discussion of this
terminology.) Thus each VLAN is treated as a BD. terminology.) Thus each VLAN is treated as a BD.
o In the "vlan bundle service", each MAC-VRF contains one bridge o In the "vlan bundle service", each MAC-VRF contains one bridge
skipping to change at page 11, line 12 skipping to change at page 11, line 12
Address field contains S and whose IP Destination Address field Address field contains S and whose IP Destination Address field
contains G. contains G.
o (S,G) Multicast Frame: An IP multicast frame whose payload o (S,G) Multicast Frame: An IP multicast frame whose payload
contains S in its IP Source Address field and G in its IP contains S in its IP Source Address field and G in its IP
Destination Address field. Destination Address field.
o Broadcast Domain (BD): an emulated ethernet, such that two systems o Broadcast Domain (BD): an emulated ethernet, such that two systems
on the same BD will receive each other's link-local broadcasts. on the same BD will receive each other's link-local broadcasts.
Note that EVPN supports models in which a single EVPN Instance Note that EVPN supports service models in which a single EVPN
(EVI) contains only one BD, and models in which a single EVI Instance (EVI) contains only one BD, and service models in which a
contains multiple BDs. Both models are supported by this draft. single EVI contains multiple BDs. Both types of service model are
However, a given BD belongs to only one EVI. supported by this draft. In all models, a given BD belongs to
only one EVI.
o Designated Forwarder (DF). As defined in [RFC7432], an ethernet o Designated Forwarder (DF). As defined in [RFC7432], an ethernet
segment may be multi-homed (attached to more than one PE). An segment may be multi-homed (attached to more than one PE). An
ethernet segment may also contain multiple BDs, of one or more ethernet segment may also contain multiple BDs, of one or more
EVIs. For each such EVI, one of the PEs attached to the segment EVIs. For each such EVI, one of the PEs attached to the segment
becomes that EVI's DF for that segment. Since a BD may belong to becomes that EVI's DF for that segment. Since a BD may belong to
only one EVI, we can speak unambiguously of the BD's DF for a only one EVI, we can speak unambiguously of the BD's DF for a
given segment. given segment.
When the text makes it clear that we are speaking in the context When the text makes it clear that we are speaking in the context
of a given BD, we will frequently use the term "a segment's DF" to of a given BD, we will frequently use the term "a segment's DF" to
mean the given BD's DF for that segment. mean the given BD's DF for that segment.
o AC: Attachment Circuit. An AC connects the bridging function of o AC: Attachment Circuit. An AC connects the bridging function of
an EVPN-PE to an ethernet segment of a particular BD. ACs are not an EVPN-PE to an ethernet segment of a particular BD. ACs are not
visible at the router (L3) layer. visible at the router (L3) layer.
If a given ethernet segment, attached to a given PE, contains n
BDs, we will say that the PE has n ACs to that segment.
o L3 Gateway: An L3 Gateway is a PE that connects an EVPN tenant o L3 Gateway: An L3 Gateway is a PE that connects an EVPN tenant
domain to an external multicast domain by performing both the OISM domain to an external multicast domain by performing both the OISM
procedures and the Layer 3 multicast procedures of the external procedures and the Layer 3 multicast procedures of the external
domain. domain.
o PEG (PIM/EVPN Gateway): A L3 Gateway that connects an EVPN tenant o PEG (PIM/EVPN Gateway): A L3 Gateway that connects an EVPN Tenant
domain to an external multicast domain whose Layer 3 multicast Domain to an external multicast domain whose Layer 3 multicast
procedures are those of PIM ([RFC7761]). procedures are those of PIM ([RFC7761]).
o MEG (MVPN/EVPN Gateway): A L3 Gateway that connects an EVPN tenant o MEG (MVPN/EVPN Gateway): A L3 Gateway that connects an EVPN Tenant
domain to an external multicast domain whose Layer 3 multicast Domain to an external multicast domain whose Layer 3 multicast
procedures are those of MVPN ([RFC6513], [RFC6514]). procedures are those of MVPN ([RFC6513], [RFC6514]).
o IPMG (IP Multicast Gateway): A PE that is used for interworking o IPMG (IP Multicast Gateway): A PE that is used for interworking
OISM EVPN-PEs with non-OISM EVPN-PEs. OISM EVPN-PEs with non-OISM EVPN-PEs.
o DR (Designated Router): A PE that has special responsibilities for o DR (Designated Router): A PE that has special responsibilities for
handling multicast on a given BD. handling multicast on a given BD.
o FHR (First Hop Router): The FHR is a PIM router ([RFC7761]) with
special responsibilities. It is the first multicast router to see
(S,G) packets from source S, and if G is an "Any Source Multicast
(ASM)" group, the FHR is responsible for sending PIM Register
messages to the PIM Rendezvous Point for group G.
o LHR (Last Hop Router): The LHR is a PIM router ([RFC7761]) with
special responsibilities. Generally it is attached to a LAN, and
it determines whether there are any hosts on the LAN that need to
receive a given multicast flow. If so, it creates and sends the
PIM Join messages that are necessary to draw the flow.
o EC (Extended Community). A BGP Extended Communities attribute
([RFC4360], [RFC7153]) is a BGP path attribute that consists of
one or more extended communities.
o RT (Route Target): A Route Target is a particular kind of BGP
Extended Community. A BGP Extended Community consists of a type
field, a sub-type field, and a value field. Certain type/sub-type
combinations indicate that a particular Extended Community is an
RT. RT1 and RT2 are considered to be the same RT if and only if
they have the same type, same sub-type, and same value fields.
o Use of the "C-" prefix. In many documents on VPN multicast, the o Use of the "C-" prefix. In many documents on VPN multicast, the
prefix "C-" appears before any address or wildcard that refers to prefix "C-" appears before any address or wildcard that refers to
an address or addresses in a tenant's address space, rather than an address or addresses in a tenant's address space, rather than
to an address of addresses in the address space of the backbone to an address of addresses in the address space of the backbone
network. This document omits the "C-" prefix in many cases where network. This document omits the "C-" prefix in many cases where
it is clear from the context that the reference is to the tenant's it is clear from the context that the reference is to the tenant's
address space. address space.
This document also assumes familiarity with the terminology of This document also assumes familiarity with the terminology of
[RFC4364], [RFC6514], [RFC7432], [RFC7761], [IGMP-Proxy], [RFC4364], [RFC6514], [RFC7432], [RFC7761], [IGMP-Proxy],
skipping to change at page 12, line 30 skipping to change at page 13, line 9
In this section, and in the remainder of this document, we assume the In this section, and in the remainder of this document, we assume the
reader is familiar with the procedures of IGMP/MLD (see [RFC2236] and reader is familiar with the procedures of IGMP/MLD (see [RFC2236] and
[RFC2710]), by which hosts announce their interest in receiving [RFC2710]), by which hosts announce their interest in receiving
particular multicast flows. particular multicast flows.
Consider a Tenant Domain consisting of a set of k BDs: BD1, ..., BDk. Consider a Tenant Domain consisting of a set of k BDs: BD1, ..., BDk.
To support the OISM procedures, each Tenant Domain must also be To support the OISM procedures, each Tenant Domain must also be
associated with a "Supplementary Broadcast Domain" (SBD). An SBD is associated with a "Supplementary Broadcast Domain" (SBD). An SBD is
treated in the control plane as a real BD, but it does not have any treated in the control plane as a real BD, but it does not have any
ACs. The SBD has several uses, that will be described later in this ACs. The SBD has several uses; these will be described later in this
document. (See Section 2.1.) document (see Section 2.1 and Section 3).
Each PE that attaches to one or more of the BDs in a given tenant Each PE that attaches to one or more of the BDs in a given tenant
domain will be provisioned to recognize that those BDs are part of domain will be provisioned to recognize that those BDs are part of
the same Tenant Domain. Note that a given PE does not need to be the same Tenant Domain. Note that a given PE does not need to be
configured with all the BDs of a given Tenant Domain. In general, a configured with all the BDs of a given Tenant Domain. In general, a
PE will only be attached to a subset of the BDs in a given Tenant PE will only be attached to a subset of the BDs in a given Tenant
Domain, and will be configured only with that subset of BDs. Domain, and will be configured only with that subset of BDs.
However, each PE attached to a given Tenant Domain must be configured However, each PE attached to a given Tenant Domain must be configured
with the SBD for that Tenant Domain. with the SBD for that Tenant Domain.
Suppose a particular segment of a particular BD is attached to PE1. Suppose a particular segment of a particular BD is attached to PE1.
[RFC7432] specifies that PE1 must originate an Inclusive Multicast [RFC7432] specifies that PE1 must originate an Inclusive Multicast
Ethernet Tag (IMET) route for that BD, and that the IMET must be Ethernet Tag (IMET) route for that BD, and that the IMET route must
propagated to all other PEs attached to the same BD. If the given be propagated to all other PEs attached to the same BD. If the given
segment contains a host that has interest in receiving a particular segment contains a host that has interest in receiving a particular
multicast flow, either an (S,G) flow or a (*,G) flow, PE1 will learn multicast flow, either an (S,G) flow or a (*,G) flow, PE1 will learn
of that interest by participating in the IGMP/MLD procedures, as of that interest by participating in the IGMP/MLD procedures, as
specified in [IGMP-Proxy]. In this case, we will say that: specified in [IGMP-Proxy]. In this case, we will say that:
o PE1 is interested in receiving the flow; o PE1 is interested in receiving the flow;
o The AC attaching the interested host to PE1 is also said to be o The AC attaching the interested host to PE1 is also said to be
interested in the flow; interested in the flow;
o The BD containing an AC that is interested in a particular flow is o The BD containing an AC that is interested in a particular flow is
also said to be interested in that flow. also said to be interested in that flow.
Once PE1 determines that it has interest in receiving a particular Once PE1 determines that it has an AC that is interested in receiving
flow or set of flows, it uses the procedures of [IGMP-Proxy] to a particular flow or set of flows, it originates one or more
advertise its interest in those flows. It advertises its interest in Selective Multicast Ethernet Tag (SMET) route to advertise that
a given flow by originating a Selective Multicast Ethernet Tag (SMET) interest.
route. An SMET route is propagated to the other PEs that attach to
the same BD.
OISM PEs MUST follow the procedures of [IGMP-Proxy]. In this Note that each IMET or SMET route is "for" a particular BD. The
document, we extend the procedures of [IGMP-Proxy] so that IMET and notion of a route being "for" a particular BD is explained in
SMET routes for a particular BD are distributed not just to PEs that Section 2.2.
attach to that BD, but to PEs that attach to any BD in the Tenant
Domain.
In this way, each PE attached to a given Tenant Domain learns, from When OISM is being supported, the procedures of [IGMP-Proxy], are
each other PE attached to the same Tenant Domain, the set of flows modified as follows:
that are of interest to each of those other PEs.
o The IMET route originated by a particular PE for a particular BD
is distributed to all other PEs attached to the Tenant Domain
containing that BD, even to those PEs that are not attached to
that particular BD.
o The SMET routes originated by a particular PE are originated on a
per-Tenant-Domain basis, rather than on a per-BD basis. That is,
the SMET routes are considered to be for the Tenant Domain's SBD,
rather than for any of its ordinary BDs. These SMET routes are
distributed to all the PEs attached to the Tenant Domain.
In this way, each PE attached to a given Tenant Domain learns,
from each other PE attached to the same Tenant Domain, the set of
flows that are of interest to each of those other PEs.
An OISM PE that is provisioned with several BDs in the same Tenant An OISM PE that is provisioned with several BDs in the same Tenant
Domain may originate an IMET route for each such BD. To indicate its Domain MUST originate an IMET route for each such BD. To indicate
support of [IGMP-Proxy], it MUST attach the EVPN Multicast Flags its support of [IGMP-Proxy], it SHOULD attach the EVPN Multicast
Extended Community to each such IMET route. Flags Extended Community to each such IMET route, but it MUST attach
the EC to at least one such IMET route.
Suppose PE1 is provisioned with both BD1 and BD2, and is provisioned Suppose PE1 is provisioned with both BD1 and BD2, and is provisioned
to consider them to be part of the same Tenant Domain. It is to consider them to be part of the same Tenant Domain. It is
possible that PE1 will receive from PE2 both an IMET route for BD1 possible that PE1 will receive from PE2 both an IMET route for BD1
and an IMET route for BD2. If either of these IMET routes has the and an IMET route for BD2. If either of these IMET routes has the
EVPN Multicast Flags Extended Community, PE1 MUST assume that PE2 is EVPN Multicast Flags Extended Community, PE1 MUST assume that PE2 is
supporting the procedures of [IGMP-Proxy] for ALL BDs in the Tenant supporting the procedures of [IGMP-Proxy] for ALL BDs in the Tenant
Domain. Domain.
If a PE supports OISM functionality, it MUST indicate that by If a PE supports OISM functionality, it indicates that by setting the
attaching an "OISM-supported" flag or Extended Community (EC) to all "OISM-supported" flag in the Multicast Flags Extended Community that
its IMET routes. (Details to be specified in next revision.) An it attaches to some or all of its IMET routes. An OISM PE SHOULD
OISM PE SHOULD attach this flag or EC to all the IMET routes it attach this EC with the OISM-supported flag set to all the IMET
originates. However, if PE1 imports IMET routes from PE2, and at routes it originates. However, if PE1 imports IMET routes from PE2,
least one of PE2's IMET routes indicates that PE2 is an OISM PE, PE1 and at least one of PE2's IMET routes indicates that PE2 is an OISM
will assume that PE2 is following OISM procedures. PE, PE1 MUST assume that PE2 is following OISM procedures.
1.5.2. Data Plane 1.5.2. Data Plane
Suppose PE1 has an AC to a segment in BD1, and PE1 receives from that Suppose PE1 has an AC to a segment in BD1, and PE1 receives from that
AC an (S,G) multicast frame (as defined in Section 1.4). AC an (S,G) multicast frame (as defined in Section 1.4).
There may be other ACs of PE1 on which TSes have indicated an There may be other ACs of PE1 on which TSes have indicated an
interest (via IGMP/MLD) in receiving (S,G) multicast packets. PE1 is interest (via IGMP/MLD) in receiving (S,G) multicast packets. PE1 is
responsible for sending the received multicast packet out those ACs. responsible for sending the received multicast packet out those ACs.
There are two cases to consider: There are two cases to consider:
skipping to change at page 14, line 35 skipping to change at page 15, line 21
the DF for that segment (or if the segment is not multi-homed), the DF for that segment (or if the segment is not multi-homed),
PE1 decapsulates the IP multicast packet, performs any necessary PE1 decapsulates the IP multicast packet, performs any necessary
IP processing (including TTL decrement), then re-encapsulates the IP processing (including TTL decrement), then re-encapsulates the
packet appropriately for BD2. PE1 then sends the packet on the packet appropriately for BD2. PE1 then sends the packet on the
AC. Note that after re-encapsulation, the MAC SA will be PE1's AC. Note that after re-encapsulation, the MAC SA will be PE1's
MAC address on BD2. The IP TTL will have been decremented by 1. MAC address on BD2. The IP TTL will have been decremented by 1.
In addition, there may be other PEs that are interested in (S,G) In addition, there may be other PEs that are interested in (S,G)
traffic. Suppose PE2 is such a PE. Then PE1 tunnels a copy of the traffic. Suppose PE2 is such a PE. Then PE1 tunnels a copy of the
IP multicast frame (with its original MAC SA, and with no alteration IP multicast frame (with its original MAC SA, and with no alteration
of the payload's IP header). The tunnel encapsulation contains of the payload's IP header) to PE2. The tunnel encapsulation
information that PE2 can use to associate the frame with a source BD. contains information that PE2 can use to associate the frame with an
If the source BD is BD1: "apparent source BD". If the actual source BD of the frame is BD1,
then:
o If PE2 is attached to BD1, the tunnel encapsulation used to send o If PE2 is attached to BD1, the tunnel encapsulation used to send
the frame to PE2 will cause PE2 to identify BD1 as the source BD. the frame to PE2 will cause PE2 to identify BD1 as the apparent
source BD.
o If PE2 is not attached to BD1, the tunnel encapsulation used to o If PE2 is not attached to BD1, the tunnel encapsulation used to
send the frame to PE2 will cause PE2 to identify the SBD as the send the frame to PE2 will cause PE2 to identify the SBD as the
source BD. apparent source BD.
The way in which the tunnel encapsulation identifies the source BD is Note that the tunnel encapsulation used for a particular BD will have
of course dependent on the type of tunnel that is used. This will be been advertised in an IMET route or S-PMSI route ([EVPN-BUM]) for
specified later in this document. that BD. That route carries a PMSI Tunnel attribute, which specifies
how packets originating from that BD are encapsulated. This
information enables the PE receiving a tunneled packet to identify
the apparent source BD as stated above. See Section 3.2 for more
details.
When PE2 receives the tunneled frame, it will forward it on any of When PE2 receives the tunneled frame, it will forward it on any of
its ACs that have interest in (S,G). its ACs that have interest in (S,G).
If PE2 determines from the tunnel encapsulation that the source BD is If PE2 determines from the tunnel encapsulation that the apparent
BD1, then source BD is BD1, then
o For those ACs that connect PE2 to BD1, the intra-subnet forwarding o For those ACs that connect PE2 to BD1, the intra-subnet forwarding
procedure described above is used, except that it is now PE2, not procedure described above is used, except that it is now PE2, not
PE1, carrying out that procedure. Unmodified EVPN procedures from PE1, carrying out that procedure. Unmodified EVPN procedures from
[RFC7432] are used to ensure that a packet originating from a [RFC7432] are used to ensure that a packet originating from a
multi-homed segment is never sent back to that segment. multi-homed segment is never sent back to that segment.
o For those ACs that do not connect to BD1, the inter-subnet o For those ACs that do not connect to BD1, the inter-subnet
forwarding procedure described above is used, except that it is forwarding procedure described above is used, except that it is
now PE2, not PE1, carrying out that procedure. now PE2, not PE1, carrying out that procedure.
If the tunnel encapsulation identifies the source BD as the SBD, PE2 If the tunnel encapsulation identifies the apparent source BD as the
applies the inter-subnet forwarding procedures described above to all SBD, PE2 applies the inter-subnet forwarding procedures described
of its ACs that have interest in the flow. above to all of its ACs that have interest in the flow.
These procedures ensure that an IP multicast frame travels from its These procedures ensure that an IP multicast frame travels from its
ingress PE to all egress PEs that are interested in receiving it. ingress PE to all egress PEs that are interested in receiving it.
While in transit, the frame retains its original MAC SA, and the While in transit, the frame retains its original MAC SA, and the
payload of the frame retains its original IP header. Note that in payload of the frame retains its original IP header. Note that in
all cases, when an IP multicast packet is sent from one BD to all cases, when an IP multicast packet is sent from one BD to
another, these procedures cause its TTL to be decremented by 1. another, these procedures cause its TTL to be decremented by 1.
So far we have assumed that an IP multicast packet arrives at its So far we have assumed that an IP multicast packet arrives at its
ingress PE over an AC that belongs to one of the BDs in a given ingress PE over an AC that belongs to one of the BDs in a given
Tenant Domain. However, it is possible for a packet to arrive at its Tenant Domain. However, it is possible for a packet to arrive at its
ingress PE in other ways. Since an EVPN-PE supporting IRB has an ingress PE in other ways. Since an EVPN-PE supporting IRB has an
IP-VRF, it is possible that the IP-VRF will have a "VRF interface" IP-VRF, it is possible that the IP-VRF will have a "VRF interface"
that is not an IRB interface. For example, there might be a VRF that is not an IRB interface. For example, there might be a VRF
interface that is actually a physical link to an external ethernet interface that is actually a physical link to an external ethernet
switch, or to a directly attached host, or to a router. When an switch, or to a directly attached host, or to a router. When an
EVPN-PE, say PE1, receives a packet through such means, we will say EVPN-PE, say PE1, receives a packet through such means, we will say
that the packet has an "external" source (i.e., a source "outside the that the packet has an "external" source (i.e., a source "outside the
tenant domain"). There are also other scenarios in which a multicast Tenant Domain"). There are also other scenarios in which a multicast
packet might have an external source, e.g., it might arrive over an packet might have an external source, e.g., it might arrive over an
MVPN tunnel from an L3VPN PE. In such cases, we will still refer to MVPN tunnel from an L3VPN PE. In such cases, we will still refer to
PE1 as the "ingress EVPN-PE". PE1 as the "ingress EVPN-PE".
When an EVPN-PE, say PE1, receives an externally sourced multicast When an EVPN-PE, say PE1, receives an externally sourced multicast
packet, and there are receivers for that packet inside the Tenant packet, and there are receivers for that packet inside the Tenant
Domain, it does the following: Domain, it does the following:
o Suppose PE1 has an AC in BD1 that has interest in (S,G). Then PE1 o Suppose PE1 has an AC in BD1 that has interest in (S,G). Then PE1
encapsulates the packet for BD1, filling in the MAC SA field with encapsulates the packet for BD1, filling in the MAC SA field with
the MAC address of PE1 itself on BD1. It sends the resulting PE1's own MAC address on BD1. It sends the resulting frame on the
frame on the AC. AC.
o Suppose some other EVPN-PE, say PE2, has interest in (S,G). PE1 o Suppose some other EVPN-PE, say PE2, has interest in (S,G). PE1
encapsulates the packet for ethernet, filling in the MAC SA field encapsulates the packet for ethernet, filling in the MAC SA field
with PE1's own MAC address on the SBD. PE1 then tunnels the with PE1's own MAC address on the SBD. PE1 then tunnels the
packet to PE2. The tunnel encapsulation will identify the source packet to PE2. The tunnel encapsulation will identify the
BD as the SBD. Since the source BD is the SBD, PE2 will know to apparent source BD as the SBD. Since the apparent source BD is
treat the frame as an inter-subnet multicast. the SBD, PE2 will know to treat the frame as an inter-subnet
multicast.
When ingress replication is used to transmit IP multicast frames from When ingress replication is used to transmit IP multicast frames from
an ingress EVPN-PE to a set of egress PEs, then of course the ingress an ingress EVPN-PE to a set of egress PEs, then of course the ingress
PE has to send multiple copies of the frame. Each copy is the PE has to send multiple copies of the frame. Each copy is the
original ethernet frame; decapsulation and IP processing take place original ethernet frame; decapsulation and IP processing take place
only at the egress PE. only at the egress PE.
If a Point-to-Multipoint (P2MP) tree or BIER ([EVPN-BIER]) is used to If a Point-to-Multipoint (P2MP) tree or BIER ([EVPN-BIER]) is used to
transmit an IP multicast frame from an ingress PE to a set of egress transmit an IP multicast frame from an ingress PE to a set of egress
PEs, then the ingress PE only has to send one copy of the frame to PEs, then the ingress PE only has to send one copy of the frame to
each of its next hops. Again, each egress PE receives the original each of its next hops. Again, each egress PE receives the original
frame and does any necessary IP processing. frame and does any necessary IP processing.
2. Detailed Model of Operation 2. Detailed Model of Operation
The model described in Section 1.5.2 can be expressed more precisely The model described in Section 1.5.2 can be expressed more precisely
using the notion of "IRB interface" (see Appendix A). However, this using the notion of "IRB interface" (see Appendix A). For a given
requires that the semantics of the IRB interface be modified for Tenant Domain:
multicast packets. It is also necessary to have an IRB interface
that connects the L3 routing instance of a particular Tenant Domain o A given PE has one IRB for each BD to which it is attached. This
(in a particular PE) to the SBD of that Tenant Domain. IRB interface connects L3 routing to that BD. When IP multicast
packets are sent or received on the IRB interfaces, the semantics
of the interface is modified from the semantics described in
Appendix A. See Section 2.3 for the details of the modification.
o Each PE also has an IRB interface that connects L3 routing to the
SBD. The semantics of this interface is different than the
semantics of the IRB interface to the real BDs. See Section 2.3.
In this section we assume that PIM is not enabled on the IRB In this section we assume that PIM is not enabled on the IRB
interfaces. In general, it is not necessary to enable PIM on the IRB interfaces. In general, it is not necessary to enable PIM on the IRB
interfaces unless there are PIM routers on one of the Tenant Domain's interfaces unless there are PIM routers on one of the Tenant Domain's
BDs, or unless there is some other scenario requiring a Tenant BDs, or unless there is some other scenario requiring a Tenant
Domain's L3 routing instance to become a PIM adjacency of some other Domain's L3 routing instance to become a PIM adjacency of some other
system. These cases will be discussed in Section 7. system. These cases will be discussed in Section 7.
2.1. Supplementary Broadcast Domain 2.1. Supplementary Broadcast Domain
Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and
two PEs (PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches two PEs (PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches
to BD2 and BD3. to BD2 and BD3.
To carry out the procedures described above, all the PEs attached to To carry out the procedures described above, all the PEs attached to
the Tenant Domain must be provisioned to have the SBD for that tenant the Tenant Domain must be provisioned with the SBD for that tenant
domain. An RT must be associated with the SBD, and provisioned on domain. A Route Target (RT) must be associated with the SBD, and
each of those PEs. We will refer to that RT as the "SBD-RT". provisioned on each of those PEs. We will refer to that RT as the
"SBD-RT".
A Tenant Domain is also configured with an IP-VRF ([EVPN-IRB]), and A Tenant Domain is also configured with an IP-VRF ([EVPN-IRB]), and
the IP-VRF is associated with an RT. This RT MAY be the same as the the IP-VRF is associated with an RT. This RT MAY be the same as the
SBD-RT. SBD-RT.
Suppose an (S,G) multicast frame originating on BD1 has a receiver on Suppose an (S,G) multicast frame originating on BD1 has a receiver on
BD3. PE1 will transmit the packet to PE2 as a frame, and the BD3. PE1 will transmit the packet to PE2 as a frame, and the
encapsulation will identify the frame's source BD as BD1. Since PE2 encapsulation will identify the frame's source BD as BD1. Since PE2
is not provisioned with BD1, it will treat the packet as if its is not provisioned with BD1, it will treat the packet as if its
source BD were the SBD. That is, a packet can be transmitted from source BD were the SBD. That is, a packet can be transmitted from
BD1 to BD3 even though its ingress PE is not configured for BD3, and/ BD1 to BD3 even though its ingress PE is not configured for BD3, and/
or its egress PE is not configured for BD1. or its egress PE is not configured for BD1.
EVPN supports service models in which a given EVPN Instance (EVI) can EVPN supports service models in which a given EVPN Instance (EVI) can
contain only one BD. It also supports service models in which a contain only one BD. It also supports service models in which a
given EVI can contain multiple BDs. The SBD can be treated either as given EVI can contain multiple BDs. No matter which service model is
its own EVI, or it can be treated as one BD within an EVI that being used for a particular tenant, it is highly RECOMMENDED that an
contains multiple BDs. The procedures specified in this document EVI containing only the SBD be provisioned for that tenant.
accommodate both cases.
2.2. When is a Route About/For/From a Particular BD If, for some reason, it is not feasible to provision an EVI that
contains only the SBD, it is possible to put the SBD in an EVI that
contains other BDs. However, in that case, the SBD-RT MUST be
different than the RT associated with any other BD. Otherwise the
procedures of this document (as detailed in Sections 2.2 and 3.1)
will not produce correct results.
In this document, we will frequently say that a particular route is 2.2. Detecting When a Route is About/For/From a Particular BD
"about" a particular BD, or is "from" a particular BD, or is "for" a
particular BD or is "related to" a particular BD. These terms are
used interchangeably. In this section, we explain exactly what that
means.
In EVPN, each BD is assigned an RT. In some service models, each BD In this document, we frequently say that a particular multicast route
is assigned a unique RT. In other service models, a set of BDs (all is "about" a particular BD, or is "from" a particular BD, or is "for"
in the same Tenant Domain) may be assigned the same RT. (An RT is a particular BD or is "related to" a particular BD or "is associated
actually assigned to a MAC-VRF, and hence is shared by all the BDs with" a particular BD. These terms are used interchangeably.
that share the MAC-VRF.) The RT is a BGP extended community that may Subsequent sections of this document explain when various routes must
be attached to the BGP routes used by the EVPN control plane. be originated for particular BDs. In this section, we explain how
the PE originating a route marks the route to indicate which BD it is
about. We also explain how a PE receiving the route determines which
BD the route is about.
In EVPN, each BD is assigned a Route Target (RT). An RT is a BGP
extended community that can be attached to the BGP routes used by the
EVPN control plane. In some EVPN service models, each BD is assigned
a unique RT. In other service models, a set of BDs (all in the same
EVI) may be assigned the same RT. The RT that is assigned to the SBD
is called the "SBD-RT".
In those service models that allow a set of BDs to share a single RT, In those service models that allow a set of BDs to share a single RT,
each BD is assigned a non-zero Tag ID. The Tag ID appears in the each BD is assigned a non-zero Tag ID. The Tag ID appears in the
Network Layer Reachability Information (NLRI) of many of the BGP Network Layer Reachability Information (NLRI) of many of the BGP
routes that are used by the EVPN control plane. routes that are used by the EVPN control plane.
A route is about a particular BD if it carries the RT that has been A given route may be about the SBD, or about an "ordinary BD" (a BD
assigned to that BD, and its NLRI contains the Tag ID that has been that is not the SBD). An RT that has been assigned to an ordinary BD
assigned to that BD. will be known as an "ordinary BD-RT".
Note that a route that is about a particular BD may also carry When constructing an IMET, SMET, S-PMSI ([EVPN-BUM]), or Leaf
additional RTs. ([EVPN-BUM]) route that is about a given BD, the following rules
apply:
o If the route is about an ordinary BD, say BD1, then
* the route MUST carry the ordinary BD-RT associated with BD1,
and
* the route MUST NOT carry any RT that is associated with an
ordinary BD other than BD1.
o If the route is about the SBD, the route MUST carry the SBD-RT,
and MUST NOT carry any RT that is associated with any other BD.
o As detailed in subsequent sections, under certain circumstances a
route that is about BD1 may carry both the RT of BD1 and also the
SBD-RT.
When receiving an IMET, SMET, S-PMSI or Leaf route, it is necessary
for the receiving PE to determine the BD to which the route belongs.
This is done by examining the RTs carried by the route, as well as
the Tag ID field of the route's NLRI. There are several cases to
consider. Some of these cases are error cases that arise when the
route has not been properly constructed.
When one of the error cases is detected, the route MUST be regarded
as a malformed route, and the "treat-as-withdraw" procedure of
[RFC7606] MUST be applied. Note though that these error cases are
only detectable by EVPN procedures at the receiving PE; BGP
procedures at intermediate nodes will generally not detect the
existence of such error cases, and in general SHOULD NOT attempt to
do so.
Case 1: The receiving PE recognizes more than one of the route's RTs
as being an SBD-RT (i.e., the route carries SBD-RTs of more
than one Tenant Domain).
This is an error case; the route has not been properly
constructed.
Case 2: The receiving PE recognizes one of the route's RTs as being
associated with an ordinary BD, and recognizes one of the
route's other RTs as being associated with a different
ordinary BD.
This is an error case; the route has not been properly
constructed.
Case 3: The receiving PE recognizes one of the route's RTs as being
associated with an ordinary BD in a particular Tenant
Domain, and recognizes another of the route's RTs as being
associated with the SBD of a different Tenant Domain.
This is an error case; the route has not been properly
constructed.
Case 4: The receiving PE does not recognize any of the route's RTs
as being associated with an ordinary BD in any of its tenant
domains, but does recognize one of the RTs as the SBD-RT of
one of its Tenant Domains.
In this case, receiving PE associates the route with the SBD
of that Tenant Domain. This association is made even if the
Tag ID field of the route's NLRI is not the Tag ID of the
SBD.
This is a normal use case where either (a) the route is for
a BD to which the receiving PE is not attached, or (b) the
route is for the SBD. In either case, the receiving PE
associates the route with the SBD.
Case 5: The receiving PE recognizes exactly one of the RTs as an
ordinary BD-RT that is associated with one of the PE's EVIs,
say EVI-1. The receiving PE also recognizes one of the RTs
as being the SBD-RT of the Tenant Domain containing EVI-1.
In this case, the route is associated with the BD in EVI-1
that is identified (in the context of EVI-1) by the Tag ID
field of the route's NLRI. (If EVI-1 contains only a single
BD, the Tag ID is likely to be zero.)
This is the case where the route is for a BD to which the
receiving PE is attached, but the route also carries the
SBD-RT. In this case, the receiving PE associates the route
with the ordinary BD, not with the SBD.
N.B.: According to the above rules, the mapping from BD to RT is a
many-to-one or one-to-one mapping. A route that an EVPN-PE
originates for a particular BD carries that BD's RT, and an EVPN-PE
that receives the route associates it with a BD as described above.
However, RTs are not used only to help identify the BD to which a
route belongs; they may also used by BGP to determine the path along
which the route is distributed, and to determine which PEs receive
the route. There may be cases where it is desirable to originate a
route about a particular BD, but have that route distributed to only
some of the EVPN-PEs attached to that BD. Or one might want the
route distributed to some intermediate set of systems, where it might
be modified or replaced before being propagated further. Such
situations are outside the scope of this document.
Additionally, there may be situations where it is desirable to
exchange routes among two or more different Tenant Domains ("EVPN
Extranet"). Such situations are outside the scope of this document.
2.3. Use of IRB Interfaces at Ingress PE 2.3. Use of IRB Interfaces at Ingress PE
When an (S,G) multicast frame is received from an AC belonging to a When an (S,G) multicast frame is received from an AC belonging to a
particular BD, say BD1: particular BD, say BD1:
1. The frame is sent unchanged to other EVPN-PEs that are interested 1. The frame is sent unchanged to other EVPN-PEs that are interested
in (S,G) traffic. The encapsulation used to send the frame to in (S,G) traffic. The encapsulation used to send the frame to
the other EVPN-PEs depends on the tunnel type being used for the other EVPN-PEs depends on the tunnel type being used for
multicast transmission. (For our purposes, we consider Ingress multicast transmission. (For our purposes, we consider Ingress
Replication (IR), Assisted Replication (AR) and BIER to be Replication (IR), Assisted Replication (AR) and BIER to be
"tunnel types", even though IR, AR and BIER do not actually use "tunnel types", even though IR, AR and BIER do not actually use
P2MP tunnels.) At the egress PE, the source BD of the frame can P2MP tunnels.) At the egress PE, the apparent source BD of the
be inferred from the tunnel encapsulation. If the egress PE is frame can be inferred from the tunnel encapsulation. If the
not attached to the real source BD, it will infer that the source egress PE is not attached to the actual source BD, it will infer
BD is the SBD. that the apparent source BD is the SBD.
Note that the the inter-PE transmission of a multicast frame Note that the the inter-PE transmission of a multicast frame
among EVPN-PEs of the same Tenant Domain does NOT involve the IRB among EVPN-PEs of the same Tenant Domain does NOT involve the IRB
interfaces, as long as the multicast frame was received over an interfaces, as long as the multicast frame was received over an
AC attached to one of the Tenant Domain's BDs. AC attached to one of the Tenant Domain's BDs.
2. The frame is also sent up the IRB interface that attaches BD1 to 2. The frame is also sent up the IRB interface that attaches BD1 to
the Tenant Domain's L3 routing instance in this PE. That is, the the Tenant Domain's L3 routing instance in this PE. That is, the
L3 routing instance, behaving as if it were a multicast router, L3 routing instance, behaving as if it were a multicast router,
receives the IP multicast frames that arrive at the PE from its receives the IP multicast frames that arrive at the PE from its
local ACs. The L3 routing instance decapsulates the frame's local ACs. The L3 routing instance decapsulates the frame's
payload to extract the IP multicast packet, decrements the IP payload to extract the IP multicast packet, decrements the IP
TTL, adjusts the header checksum, and does any other necessary IP TTL, adjusts the header checksum, and does any other necessary IP
processing (e.g., fragmentation). processing (e.g., fragmentation).
3. The L3 routing instance keeps track of which BDs have local 3. The L3 routing instance keeps track of which BDs have local
receivers for (S,G) traffic. (A "local receiver" is a tenant receivers for (S,G) traffic. (A "local receiver" is a TS,
system, reachable via a local attachment circuit that has reachable via a local AC, that has expressed interest in (S,G)
expressed interest in (S,G) traffic.) If the L3 routing instance traffic.) If the L3 routing instance has an IRB interface to
has an IRB interface to BD2, and it knows that BD2 has a LOCAL BD2, and it knows that BD2 has a LOCAL receiver interested in
receiver interested in (S,G) traffic, it encapsulates the packet (S,G) traffic, it encapsulates the packet in an ethernet header
in an ethernet header for BD2, putting its own MAC address in the for BD2, putting its own MAC address in the MAC SA field. Then
MAC SA field. Then it sends the packet down the IRB interface to it sends the packet down the IRB interface to BD2.
BD2.
If a packet is sent from the L3 routing instance to a particular BD If a packet is sent from the L3 routing instance to a particular BD
via the IRB interface (step 3 in the above list), and if the BD in via the IRB interface (step 3 in the above list), and if the BD in
question is NOT the SBD, the packet is sent ONLY to LOCAL ACs of that question is NOT the SBD, the packet is sent ONLY to LOCAL ACs of that
BD. If the packet needs to go to other PEs, it has already been sent BD. If the packet needs to go to other PEs, it has already been sent
to them in step 1. Note that this is a change in the IRB interface to them in step 1. Note that this is a change in the IRB interface
semantics from what is described in [EVPN-IRB] and Figure 2. semantics from what is described in [EVPN-IRB] and Figure 2.
Existing EVPN procedures ensure that a packet is not sent by a given If a given locally attached segment is multi-homed, existing EVPN
PE to a given locally attached segment unless the PE is the DF for procedures ensure that a packet is not sent by a given PE to that
that segment. Those procedures also ensure that a packet is never segment unless the PE is the DF for that segment. Those procedures
sent by a PE to its segment of origin. Thus EVPN segment multi- also ensure that a packet is never sent by a PE to its segment of
homing is fully supported; duplicate delivery to a segment or looping origin. Thus EVPN segment multi-homing is fully supported; duplicate
on a segment are thereby prevented, without the need for any new delivery to a segment or looping on a segment are thereby prevented,
procedures to be defined in this document. without the need for any new procedures to be defined in this
document.
What if an IP multicast packet is received from outside the tenant What if an IP multicast packet is received from outside the tenant
domain? For instance, perhaps PE1's IP-VRF for a particular tenant domain? For instance, perhaps PE1's IP-VRF for a particular tenant
domain also has a physical interface leading to an external switch, domain also has a physical interface leading to an external switch,
host, or router, and PE1 receives an IP multicast packet or frame on host, or router, and PE1 receives an IP multicast packet or frame on
that interface. Or perhaps the packet is from an L3VPN, or a that interface. Or perhaps the packet is from an L3VPN, or a
different EVPN Tenant Domain. different EVPN Tenant Domain.
Such a packet is first processed by the L3 routing instance, which Such a packet is first processed by the L3 routing instance, which
decrements TTL and does any other necessary IP processing. Then the decrements TTL and does any other necessary IP processing. Then the
packet is sent into the Tenant Domain by sending it down the IRB packet is sent into the Tenant Domain by sending it down the IRB
interface to the SBD of that Tenant Domain. This requires interface to the SBD of that Tenant Domain. This requires
encapsulating the packet in an ethernet header, with the PE's own MAC encapsulating the packet in an ethernet header. The MAC SA field
address, on the SBD, in the MAC SA field. will contain the PE's own MAC on the SBD.
An IP multicast packet sent by the L3 routing instance down the IRB An IP multicast packet sent by the L3 routing instance down the IRB
interface to the SBD is treated as if it had arrived from a local AC, interface to the SBD is treated as if it had arrived from a local AC,
and steps 1-3 are applied. Note that the semantics of sending a and steps 1-3 are applied. Note that the semantics of sending a
packet down the IRB interface to the SBD are thus slightly different packet down the IRB interface to the SBD are thus slightly different
than the semantics of sending a packet down other IRB interfaces. IP than the semantics of sending a packet down other IRB interfaces. IP
multicast packets sent down the SBD's IRB interface may be multicast packets sent down the SBD's IRB interface may be
distributed to other PEs, but IP multicast packets sent down other distributed to other PEs, but IP multicast packets sent down other
IRB interfaces are distributed only to local ACs. IRB interfaces are distributed only to local ACs.
skipping to change at page 19, line 49 skipping to change at page 23, line 18
actual BDs. actual BDs.
2.4. Use of IRB Interfaces at an Egress PE 2.4. Use of IRB Interfaces at an Egress PE
Suppose an egress EVPN-PE receives an (S,G) multicast frame from the Suppose an egress EVPN-PE receives an (S,G) multicast frame from the
frame's ingress EVPN-PE. As described above, the packet will arrive frame's ingress EVPN-PE. As described above, the packet will arrive
as an ethernet frame over a tunnel from the ingress PE, and the as an ethernet frame over a tunnel from the ingress PE, and the
tunnel encapsulation will identify the source BD of the ethernet tunnel encapsulation will identify the source BD of the ethernet
frame. frame.
We define the notion of the frame's "inferred source BD" as follows. We define the notion of the frame's "apparent source BD" as follows.
If the egress PE is attached to the actual source BD, the actual If the egress PE is attached to the actual source BD, the actual
source BD is the inferred source BD. If the egress PE is not source BD is the apparent source BD. If the egress PE is not
attached to the actual source BD, the inferred source BD is the SBD. attached to the actual source BD, the SBD is the apparent source BD.
The egress PE now takes the following steps: The egress PE now takes the following steps:
1. If the egress PE has ACs belonging to the inferred source BD of 1. If the egress PE has ACs belonging to the apparent source BD of
the frame, it sends the frame unchanged to any ACs of that BD the frame, it sends the frame unchanged to any ACs of that BD
that have interest in (S,G) packets. The MAC SA of the frame is that have interest in (S,G) packets. The MAC SA of the frame is
not modified, and the IP header of the frame's payload is not not modified, and the IP header of the frame's payload is not
modified in any way. modified in any way.
2. The frame is also sent to the L3 routing instance by being sent 2. The frame is also sent to the L3 routing instance by being sent
up the IRB interface that attaches the L3 routing instance to the up the IRB interface that attaches the L3 routing instance to the
inferred source BD. Steps 2 and 3 of Section 2.3 are then apparent source BD. Steps 2 and 3 of Section 2.3 are then
applied. applied.
2.5. Announcing Interest in (S,G) 2.5. Announcing Interest in (S,G)
[IGMP-Proxy] defines the procedures used by an egress PE to announce [IGMP-Proxy] defines procedures used by an egress PE to announce its
its interest in a multicast flow or set of flows. This is done by interest in a multicast flow or set of flows. If an egress PE
originating an SMET route. If an egress PE determines it has LOCAL determines it has LOCAL receivers in a particular BD, say BD1, that
receivers in a particular BD that are interested in a particular set are interested in a particular set of flows, it originates one or
of flows, it originates one or more SMET routes for that BD. The more SMET routes for BD1. Each SMET route specifies a particular
SMET route specifies a flow or set of flows, and identifies the (S,G) or (*,G) flow. By originating an SMET route for BD1, a PE is
egress PE. The SMET route is specific to a particular BD. A PE that announcing "I have receivers for (S,G) or (*,G) in BD1". Such an
originates an SMET route is announcing "I have receivers for (S,G) or SMET route carries the Route Target (RT) for BD1, ensuring that it
(*,G) in BD-x". will be distributed to all PEs that are attached to BD1.
In [IGMP-Proxy], an SMET route for a particular BD carries a Route The OISM procedures for originating SMET routes differ slightly from
Target (RT) that ensures it will be distributed to all PEs that are those in [IGMP-Proxy]. In most cases, the SMET routes are considered
attached to that BD. In this document, it is REQUIRED that an SMET to be for the SBD, rather than for the BD containing local receivers.
route also carry the RT that is assigned to the SBD. This ensures These SMET routes carry the SBD-RT, and do not carry any ordinary BD-
that every ingress PE attached to a particular Tenant Domain will RT. Details on the processing of SMET routes can be found in
learn of all other PEs (attached to the same Tenant Domain) that have Section 3.3.
interest in a particular set of flows. Note that it is not necessary
for the ingress PE to have any BDs other than the SBD in common with
the egress PEs.
Since the SMET routes from any BD in a given Tenant Domain are Since the SMET routes carry the SBD-RT, every ingress PE attached to
propagated to all PEs of that Tenant Domain, an (S,G) receiver on one a particular Tenant Domain will learn of all other PEs (attached to
BD can receive (S,G) packets that originate in a different BD. the same Tenant Domain) that have interest in a particular set of
Within an EVPN domain, a given IP source address can only be on one flows. Note that a PE that receives a given SMET route does not
BD. Therefore inter-subnet multicasting can be done, within the necessarily have any BDs (other than the SBD) in common with the PE
Tenant Domain, without requiring any Rendezvous Points, shared trees, that originates that SMET route.
or other complex aspects of multicast routing infrastructure. (Note
that while the MAC addresses do not have to be unique across all the If all the sources and receivers for a given (*,G) are in the Tenant
BDs in a Tenant Domain, the IP addresses to have to be unique across Domain, inter-subnet "Any Source Multicast" traffic will be properly
all those BDs.) routed without requiring any Rendezvous Points, shared trees, or
other complex aspects of multicast routing infrastructure. Suppose,
for example, that:
o PE1 has a local receiver, on BD1, for (*,G)
o PE2 has a local source, on BD2, for (*,G).
PE1 will originate an SMET(*,G) route for the SBD, and PE2 will
receive that route, even if PE2 is not attached to BD1. PE2 will
thus know to forward (S,G) traffic to PE1. PE1 does not need to do
any "source discovery". (This does assume that source S does not
send the same (S,G) datagram on two different BDs, and that the
Tenant Domain does not contain two or more sources with the same IP
address S. The use of multicast sources that have IP "anycast"
addresses is outside the scope of this document.)
If some PE attached to the Tenant Domain does not support [IGMP- If some PE attached to the Tenant Domain does not support [IGMP-
Proxy], it will be assumed to be interested in all flows. Whether a Proxy], it will be assumed to be interested in all flows. Whether a
particular remote PE supports [IGMP-Proxy] is determined by the particular remote PE supports [IGMP-Proxy] is determined by the
presence of the Multicast Flags Extended Community in its IMET route; presence of the Multicast Flags Extended Community in its IMET route;
this is specified in [IGMP-Proxy].) this is specified in [IGMP-Proxy].
2.6. Tunneling Frames from Ingress PE to Egress PEs 2.6. Tunneling Frames from Ingress PE to Egress PEs
[RFC7432] specifies the procedures for setting up and using "BUM [RFC7432] specifies the procedures for setting up and using "BUM
tunnels". A BUM tunnel is a tunnel used to carry traffic on a tunnels". A BUM tunnel is a tunnel used to carry traffic on a
particular BD if that traffic is (a) broadcast traffic, or (b) particular BD if that traffic is (a) broadcast traffic, or (b)
unicast traffic with an unknown MAC DA, or (c) ethernet multicast unicast traffic with an unknown MAC DA, or (c) ethernet multicast
traffic. traffic.
This document allows the BUM tunnels to be used as the default This document allows the BUM tunnels to be used as the default
tunnels for transmitting intra-subnet IP multicast frames. It also tunnels for transmitting IP multicast frames. It also allows a
allows a separate set of tunnels to be used, instead of the BUM separate set of tunnels to be used, instead of the BUM tunnels, as
tunnels, as the default tunnels for carrying intra-subnet IP the default tunnels for carrying IP multicast frames. Let's call
multicast frames. Let's call these "IP Multicast Tunnels". these "IP Multicast Tunnels".
When the tunneling is done via Ingress Replication or via BIER, this When the tunneling is done via Ingress Replication or via BIER, this
difference is of no significance. However, when P2MP tunnels are difference is of no significance. However, when P2MP tunnels are
used, there is a significant advantages to having separate IP used, there is a significant advantage to having separate IP
multicast tunnels. multicast tunnels.
It is desirable for an ingress PE to transmit a copy of a given (S,G) Other things being equal, it is desirable for an ingress PE to
multicast frame on only one tunnel. All egress PEs interested in transmit a copy of a given (S,G) multicast frame on only one P2MP
(S,G) packets must then join that tunnel. If the source BD/PE for an tunnel. All egress PEs interested in (S,G) packets then have to join
(S,G) packet is BD1/PE1, and PE2 has receivers for (S,G) on BD2, PE2 that tunnel. If the source BD and PE for an (S,G) frame are BD1 an
must join the P2MP LSP on which PE1 transmits the frame. PE2 must PE1 respectively, and if PE2 has receivers on BD2 for (S,G), then PE2
join this P2MP LSP even if PE2 is not attached to the source BD must join the P2MP LSP on which PE1 transmits the (S,G) frame. PE2
must join this P2MP LSP even if PE2 is not attached to the source BD
(BD1). If PE1 were transmitting the multicast frame on its BD1 BUM (BD1). If PE1 were transmitting the multicast frame on its BD1 BUM
tunnel, then PE2 would have to join the BD1 BUM tunnel, even though tunnel, then PE2 would have to join the BD1 BUM tunnel, even though
PE2 has no BD1 attachment circuits. This would cause PE2 to pull all PE2 has no BD1 attachment circuits. This would cause PE2 to pull all
the BUM traffic from BD1, most of which it would just have to the BUM traffic from BD1, most of which it would just have to
discard. Thus we RECOMMEND that the default IP multicast tunnels be discard. Thus we RECOMMEND that the default IP multicast tunnels be
distinct from the BUM tunnels. distinct from the BUM tunnels.
Whether or not the default IP multicast tunnels are distinct from the
BUM tunnels, selective tunnels for particular multicast flows can
still be used. Traffic sent on a selective tunnel would not be sent
on the default tunnel.
Notwithstanding the above, link local IP multicast traffic MUST Notwithstanding the above, link local IP multicast traffic MUST
always be carried on the BUM tunnels, and ONLY on the BUM tunnels. always be carried on the BUM tunnels, and ONLY on the BUM tunnels.
Link local IP multicast traffic consists of IPv4 traffic with a Link local IP multicast traffic consists of 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. In this document, the terms destination address prefix of FF02/16. In this document, the terms
"IP multicast packet" and "IP multicast frame" are defined in "IP multicast packet" and "IP multicast frame" are defined in
Section 1.4 so as to exclude the link-local traffic. Section 1.4 so as to exclude the link-local traffic.
Note that it is also possible to use "selective tunnels" to carry
particular multicast flows (see Section 3.2). When an (S,G) frame is
transmitted on a selective tunnel, it is not transmitted on the BUM
tunnel or on the default IP Multicast tunnel.
2.7. Advanced Scenarios 2.7. Advanced Scenarios
There are some deployment scenarios that require special procedures: There are some deployment scenarios that require special procedures:
1. Some multicast sources or receivers are attached to PEs that 1. Some multicast sources or receivers are attached to PEs that
support [RFC7432], but do not support this document or support [RFC7432], but do not support this document or
[EVPN-IRB]. To interoperate with these "non-OISM PEs", it is [EVPN-IRB]. To interoperate with these "non-OISM PEs", it is
necessary to have one or more gateway PEs that interface the necessary to have one or more gateway PEs that interface the
tunnels discussed in this document with the BUM tunnels of the tunnels discussed in this document with the BUM tunnels of the
legacy PEs. This is discussed in Section 5. legacy PEs. This is discussed in Section 5.
skipping to change at page 22, line 30 skipping to change at page 26, line 14
3. In some scenarios, one or more of the tenant systems is a PIM 3. In some scenarios, one or more of the tenant systems is a PIM
router, and the Tenant Domain is used for as a transit network router, and the Tenant Domain is used for as a transit network
that is part of a larger multicast domain. This is discussed in that is part of a larger multicast domain. This is discussed in
Section 7. Section 7.
3. EVPN-aware Multicast Solution Control Plane 3. EVPN-aware Multicast Solution Control Plane
3.1. Supplementary Broadcast Domain (SBD) and Route Targets 3.1. Supplementary Broadcast Domain (SBD) and Route Targets
Every Tenant Domain is associated with a single Supplementary As discussed in Section 2.1, every Tenant Domain is associated with a
Broadcast Domain (SBD), as discussed in Section 2.1. Recall that a single Supplementary Broadcast Domain (SBD). Recall that a Tenant
Tenant Domain is defined to be a set of BDs that can freely send and Domain is defined to be a set of BDs that can freely send and receive
receive IP multicast traffic to/from each other. If an EVPN-PE has IP multicast traffic to/from each other. If an EVPN-PE has one or
one or more ACs in a BD of a particular Tenant Domain, and if the more ACs in a BD of a particular Tenant Domain, and if the EVPN-PE
EVPN-PE supports the procedures of this document, that EVPN-PE must supports the procedures of this document, that EVPN-PE MUST be
be provisioned with the SBD of that Tenant Domain. provisioned with the SBD of that Tenant Domain.
At each EVPN-PE attached to a given Tenant Domain, there is an IRB At each EVPN-PE attached to a given Tenant Domain, there is an IRB
interface leading from the L3 routing instance of that Tenant Domain interface leading from the L3 routing instance of that Tenant Domain
and the SBD. However, the SBD has no ACs. to the SBD. However, the SBD has no ACs.
The SBD may be in an EVPN Instance (EVI) of its own, or it may be one
of several BDs (of the same Tenant Domain) in an EVI.
Each SBD is provisioned with a Route Target (RT). All the EVPN-PEs Each SBD is provisioned with a Route Target (RT). All the EVPN-PEs
supporting a given SBD are provisioned with that RT as an import RT. supporting a given SBD are provisioned with that RT as an import RT.
That RT MUST NOT be the same as the RT associated with any other BD.
Each SBD is also provisioned with a "Tag ID" (see Section 6 of
[RFC7432]).
o If the SBD is the only BD in its EVI, the mapping from RT to SBD
is one-to-one. The Tag ID is zero.
o If the SBD is one of several BDs in its EVI, it may have its own
RT, or it may share an RT with one or more of those other BDs. In
either case, it must be assigned a non-zero Tag ID. The mapping
from <RT, Tag ID> is always one-to-one.
We will use the term "SBD-RT" to denote the RT has has been assigned We will use the term "SBD-RT" to denote the RT has has been assigned
to an SBD. Routes carrying this RT will be propagated to all to the SBD. Routes carrying this RT will be propagated to all
EVPN-PEs in the same Tenant Domain as the originator. EVPN-PEs in the same Tenant Domain as the originator.
An EVPN-PE that receives a route can always determine whether a Section 2.2 specifies the rules by which an EVPN-PE that receives a
received route "belongs to" a particular SBD, by seeing if that route route determines whether a received route "belongs to" a particular
carries the SBD-RT and has the Tag ID of the SBD in its NLRI. ordinary BD or SBD.
If the VLAN-based service model is being used for a particular Tenant Section 2.2 also specifies additional rules that must be following
Domain, and thus each BD is in a distinct EVI, it is natural to have when constructing routes that belong to a particular BD, including
the SBD be in a distinct EVI as well. If the VLAN-aware bundle the SBD.
service is being used, it is natural to include the SBD in the same
EVI that contains the other BDs. However, it is not required to do The SBD SHOULD be in an EVPN Instance (EVI) of its own. Even if the
so; the SBD can still be placed in an EVI of its own, if that is SBD is not in an EVI of its own, the SBD-RT MUST be different than
desired. the RT associated with any other BD. This restriction is necessary
in order for the rules of Sections 2.2 and 3.1 to work correctly.
Note that an SBD, just like any other BD, is associated on each Note that an SBD, just like any other BD, is associated on each
EVPN-PE with a MAC-VRF. Per [RFC7432], each MAC-VRF is associated EVPN-PE with a MAC-VRF. Per [RFC7432], each MAC-VRF is associated
with a Route Distinguisher (RD). When constructing a route that is with a Route Distinguisher (RD). When constructing a route that is
"about" an SBD, an EVPN-PE will place the RD of the associated "about" an SBD, an EVPN-PE will place the RD of the associated
MAC-VRF in the "Route Distinguisher" field of the NLRI. (If the MAC-VRF in the "Route Distinguisher" field of the NLRI. (If the
Tenant Domain has several MAC-VRFs on a given PE, the EVPN-PE has a Tenant Domain has several MAC-VRFs on a given PE, the EVPN-PE has a
choice of which RD to use.) choice of which RD to use.)
If Assisted Replication (AR, see [EVPN-AR]) is used, each If Assisted Replication (AR, see [EVPN-AR]) is used, each
skipping to change at page 24, line 14 skipping to change at page 27, line 35
If AR is used, the ingress EVPN-PE is also an AR-LEAF and the IMET If AR is used, the ingress EVPN-PE is also an AR-LEAF and the IMET
route coming from the selected AR-REPLICATOR contains the information route coming from the selected AR-REPLICATOR contains the information
needed. The AR-REPLICATOR will behave as an ingress EVPN-PE when needed. The AR-REPLICATOR will behave as an ingress EVPN-PE when
sending a flow to the egress EVPN-PEs. sending a flow to the egress EVPN-PEs.
If the tunneling technique requires P2MP tunnels to be set up (e.g., If the tunneling technique requires P2MP tunnels to be set up (e.g.,
RSVP-TE P2MP, mLDP, PIM), some of the tunnels may be selective RSVP-TE P2MP, mLDP, PIM), some of the tunnels may be selective
tunnels and some may be inclusive tunnels. tunnels and some may be inclusive tunnels.
Selective tunnels are always advertised by the ingress PE using Selective P2MP tunnels are always advertised by the ingress PE using
S-PMSI A-D routes ([EVPN-BUM]). S-PMSI A-D routes ([EVPN-BUM]).
For inclusive tunnels, there is a choice between using a BD's For inclusive tunnels, there is a choice between using a BD's
ordinary "BUM tunnel" [RFC7432] as the default inclusive tunnel for ordinary "BUM tunnel" [RFC7432] as the default inclusive tunnel for
carrying IP multicast traffic, or using a separate IP multicast carrying IP multicast traffic, or using a separate IP multicast
tunnel as the default inclusive tunnel for carrying IP multicast. In tunnel as the default inclusive tunnel for carrying IP multicast. In
the former case, the inclusive tunnel is advertised in an IMET route. the former case, the inclusive tunnel is advertised in an IMET route.
In the latter case, the inclusive tunnel is advertised in a (C-*,C-*) In the latter case, the inclusive tunnel is advertised in a (C-*,C-*)
S-PMSI A-D route ([EVPN-BUM]). Details may be found in subsequent S-PMSI A-D route ([EVPN-BUM]). Details may be found in subsequent
sections. sections.
3.2.1. Constructing SBD Routes 3.2.1. Constructing Routes for the SBD
3.2.1.1. Constructing an SBD-IMET Route
In general, an EVPN-PE originates an IMET route for each real BD.
Whether an EVPN-PE has to originate an IMET route for the SBD (of a
particular Tenant Domain) depends upon the type of tunnels being used
to carry EVPN multicast traffic across the backbone. In some cases,
an IMET route does not need to be originated for the SBD, but the
other IMET routes have to carry the SBD-RT as well as any other RTs
they would ordinarily carry (per [RFC7432].
Subsequent sections will specify when it is necessary for an EVPN-PE
to originate an IMET route for the SBD. We will refer to such a
route as an "SBD-IMET route".
When an EVPN-PE needs to originate an SBD-IMET route that is "for"
the SBD, it constructs the route as follows:
o the RD field of the route's NLRI is set to the RD of the MAC-VRF
that is associated with the SBD;
o a Route Target Extended Community containing the value of the
SBD-RT is attached to that route;
o the "Tag ID" field of the NLRI is set to the Tag ID that has been
assigned to the SBD. This is most likely 0 if a VLAN-based or
VLAN-bundle service is being used and non-zero if a VLAN-aware
bundle service is being used.
3.2.1.2. Constructing an SBD-SMET Route
An EVPN-PE can originate an SMET route to indicate that it has
receivers, on a specified BD, for a specified multicast flow. In
some scenarios, an EVPN-PE must originate an SMET route that is for
the SBD, which we will call an "SBD-SMET route". Whether an EVPN-PE
has to originate an SMET route for the SBD (of a particular tenant
domain) depends upon various factors, detailed in subsequent
sections.
When an EVPN-PE needs to originate an SBD-SMET route that is "for"
the SBD, it constructs the route as follows:
o the RD field of the route's NLRI is set to the RD of the MAC-VRF
that is associated with the SBD;
o a Route Target Extended Community containing the value of the
SBD-RT is attached to that route;
o the "Tag ID" field of the NLRI is set to the Tag ID that has been
assigned to the SBD. This is most likely 0 if a VLAN-based or
VLAN-bundle service is being used and non-zero if a VLAN-aware
bundle service is being used.
3.2.1.3. Constructing an SBD-SPMSI Route
An EVPN-PE can originate an S-PMSI A-D route (see [EVPN-BUM]) to There are situations in which an EVPN-PE needs to originate IMET,
indicate that it is going to use a particular P2MP tunnel to carry SMET, and/or SPMSI routes for the SBD. Throughout this document, we
the traffic of particular IP multicast flows. In general, an S-PMSI will refer to such routes respectively as "SBD-IMET routes",
A-D route is specific to a particular BD. In some scenarios, an "SBD-SMET routes", and "SBD-SPMSI routes". Subsequent sections
EVPN-PE must originate an S-PMSI A-D route that is for the SBD, which detail the conditions under which these routes need to be originated.
we will call an "SBD-SPMSI route". Whether an EVPN-PE has to
originate an SBD-SPMSI route for (of a particular Tenant Domain)
depends upon various factors, detailed in subsequent sections.
When an EVPN-PE needs to originate an SBD-SPMSI route that is "for" When an EVPN-PE needs to originate an SBD-IMET, SBD-SMET, or
the SBD, it constructs the route as follows: SBD-SPMSI route, it constructs the route as follows:
o the RD field of the route's NLRI is set to the RD of the MAC-VRF o the RD field of the route's NLRI is set to the RD of the MAC-VRF
that is associated with the SBD; that is associated with the SBD;
o a Route Target Extended Community containing the value of the o the SBD-RT is attached to the route;
SBD-RT is attached to that route;
o the "Tag ID" field of the NLRI is set to the Tag ID that has been o the "Tag ID" field of the route's NLRI is set to the Tag ID that
assigned to the SBD. This is most likely 0 if a VLAN-based or has been assigned to the SBD. This is most likely 0 if a
VLAN-bundle service is being used and non-zero if a VLAN-aware VLAN-based or VLAN-bundle service is being used, but non-zero if a
bundle service is being used. VLAN-aware bundle service is being used.
3.2.2. Ingress Replication 3.2.2. Ingress Replication
When Ingress Replication (IR) is used to transport IP multicast When Ingress Replication (IR) is used to transport IP multicast
frames of a given Tenant Domain, each EVPN-PE attached to that Tenant frames of a given Tenant Domain, each EVPN-PE attached to that Tenant
Domain MUST originate an SBD-IMET route, as described in Domain MUST originate an SBD-IMET route (see Section 3.2.1).
Section 3.2.1.1.
The SBD-IMET route MUST carry a PMSI Tunnel attribute (PTA), and the The SBD-IMET route MUST carry a PMSI Tunnel attribute (PTA), and the
MPLS label field of the PTA MUST specify a downstream-assigned MPLS MPLS label field of the PTA MUST specify a downstream-assigned MPLS
label that maps uniquely (in the context of the originating EVPN-PE) label that maps uniquely (in the context of the originating EVPN-PE)
to the SBD. to the SBD.
An EVPN-PE MUST also originate an IMET route for each BD to which it Following the procedures of [RFC7432], an EVPN-PE MUST also originate
is attached, following the procedures of [RFC7432]. Each of these an IMET route for each BD to which it is attached. Each of these
IMET routes carries a PTA that specifying a downstream-assigned label IMET routes carries a PTA specifying a downstream-assigned label that
that maps uniquely (in the context of the originating EVPN-PE) to the maps uniquely, in the context of the originating EVPN-PE, to the BD
BD in question. These IMET routes need not carry the SBD-RT. in question. These IMET routes need not carry the SBD-RT.
When an ingress EVPN-PE needs to use IR to send an IP multicast frame When an ingress EVPN-PE needs to use IR to send an IP multicast frame
from a particular source BD to an egress EVPN-PE, the ingress PE from a particular source BD to an egress EVPN-PE, the ingress PE
determines whether the egress PE has originated an IMET route for determines whether the egress PE has originated an IMET route for
that BD. If so, that IMET route contains the MPLS label that the that BD. If so, that IMET route contains the MPLS label that the
egress PE has assigned to the source BD. The ingress PE uses that egress PE has assigned to the source BD. The ingress PE uses that
label when transmitting the packet to the egress PE. Otherwise, the label when transmitting the packet to the egress PE. Otherwise, the
ingress PE uses the label that the egress PE has assigned to the SBD ingress PE uses the label that the egress PE has assigned to the SBD
(in the SBD-IMET route originated by the egress). (in the SBD-IMET route originated by the egress).
Note that the set of IMET routes originated by a given egress PE, and Note that the set of IMET routes originated by a given egress PE, and
installed by a given ingress PE, will change over time. If the installed by a given ingress PE, may change over time. If the egress
egress PE withdraws its IMET route for the source BD, the ingress PE PE withdraws its IMET route for the source BD, the ingress PE MUST
must stop using the label carried in that IMET route, and start using stop using the label carried in that IMET route, and instead MUST use
the label carried in the SBD-IMET route from that egress PE. the label carried in the SBD-IMET route from that egress PE.
Implementors must also take into account that an IMET route from a
particular PE for a particular BD may arrive after that PE's SBD-IMET
route.
3.2.3. Assisted Replication 3.2.3. Assisted Replication
When Assisted Replication is used to transport IP multicast frames of When Assisted Replication is used to transport IP multicast frames of
a given Tenant Domain, each EVPN-PE (including the AR-REPLICATOR) a given Tenant Domain, each EVPN-PE (including the AR-REPLICATOR)
attached to the Tenant Domain MUST originate an SBD-IMET route, as attached to the Tenant Domain MUST originate an SBD-IMET route (see
described in Section 3.2.1.1. Section 3.2.1).
An AR-REPLICATOR attached to a given Tenant Domain is considered to An AR-REPLICATOR attached to a given Tenant Domain is considered to
be an EVPN-PE of that Tenant Domain. It is attached to all the BDs be an EVPN-PE of that Tenant Domain. It is attached to all the BDs
in the Tenant Domain, but it has no IRB interfaces. in the Tenant Domain, but it has no IRB interfaces.
As with Ingress Replication, the SBD-IMET route carries a PTA where As with Ingress Replication, the SBD-IMET route carries a PTA where
the MPLS label field specifies the downstream-assigned MPLS label the MPLS label field specifies the downstream-assigned MPLS label
that identifies the SBD. However, the AR-REPLICATOR and AR-LEAF that identifies the SBD. However, the AR-REPLICATOR and AR-LEAF
EVPN-PEs will set the PTA's flags differently, as per [EVPN-AR]. EVPN-PEs will set the PTA's flags differently, as per [EVPN-AR].
skipping to change at page 27, line 33 skipping to change at page 29, line 46
egress EVPN-PEs using the labels contained in the IMET routes egress EVPN-PEs using the labels contained in the IMET routes
received from the egress PEs. received from the egress PEs.
If an ingress AR-LEAF for a given BD has not received any IMET route If an ingress AR-LEAF for a given BD has not received any IMET route
for that BD from an AR-REPLICATOR, the ingress AR-LEAF follows the for that BD from an AR-REPLICATOR, the ingress AR-LEAF follows the
procedures in Section 3.2.2. procedures in Section 3.2.2.
3.2.4. BIER 3.2.4. BIER
When BIER is used to transport multicast packets of a given Tenant When BIER is used to transport multicast packets of a given Tenant
Domain, each EVPN-PE attached to that Tenant Domain MUST originate an Domain, and a given EVPN-PE attached to that Tenant Domain is a
SBD-IMET route, as described in Section 3.2.1.1. possible ingress EVPN-PE for traffic originating outside that Tenant
Domain, the given EVPN-PE MUST originate an SBD-IMET route, (see
Section 3.2.1).
In addition, IMET routes that are originated for other BDs in the In addition, IMET routes that are originated for other BDs in the
Tenant Domain MUST carry the SBD-RT. Tenant Domain MUST carry the SBD-RT.
Each IMET route (including but not limited to the SBD-IMET route) Each IMET route (including but not limited to the SBD-IMET route)
MUST carry a PMSI Tunnel attribute (PTA). The MPLS label field of MUST carry a PMSI Tunnel attribute (PTA). The MPLS label field of
the PTA MUST specify an upstream-assigned MPLS label that maps the PTA MUST specify an upstream-assigned MPLS label that maps
uniquely (in the context of the originating EVPN-PE) to the BD for uniquely (in the context of the originating EVPN-PE) to the BD for
which the route is originated. which the route is originated.
When an ingress EVPN-PE uses BIER to send an IP multicast packet Suppose an ingress EVPN-PE, PE1, needs to use BIER to tunnel an IP
(inside an ethernet frame) from a particular source BD to a set of multicast frame to a set of egress EVPN-PEs. And suppose the frame's
egress EVPN-PEs, the ingress PE follows the BIER encapsulation with source BD is BD1. The frame is encapsulated as follows:
the upstream-assigned label it has assigned to the source BD. (This
label will come from the originated SBD-IMET route ONLY if the o A four-octet MPLS label stack entry ([RFC3032]) is prepended to
traffic originated from outside the Tenant Domain.) An egress PE can the frame. The Label field is set to the upstream-assigned label
determine from that label whether the packet's source BD is one of that PE1 has assigned to BD1.
the BDs to which the egress PE is attached.
o The resulting MPLS packet is then encapsulated in a BIER
encapsulation ([RFC8296], [EVPN-BIER]). The BIER BitString is set
to identify the egress EVPN-PEs. The BIER "proto" field is set to
the value for "MPLS packet with upstream-assigned label at top of
stack".
Note: It is possible that the packet being tunneled from PE1
originated outside the Tenant Domain. In this case, the actual
source BD (BD1) is considered to be the SBD, and the
upstream-assigned label it carries will be the label that PE1
assigned to the SBD, and advertised in its SBD-IMET route.
Suppose an egress PE, PE2, receives such a BIER packet. The BFIR-id
field of the BIER header allows PE2 to determine that the ingress PE
is PE1. There are then two cases to consider:
1. PE2 has received and installed an IMET route for BD1 from PE1.
In this case, the BIER packet will be carrying the
upstream-assigned label that is specified in the PTA of that IMET
route. This enables PE2 to determine the "apparent source BD"
(as defined in Section 2.4).
2. PE2 has not received and installed an IMET route for BD1 from
PE1.
In this case, PE2 will not recognize the upstream-assigned label
carried in the BIER packet. PE2 MUST discard the packet.
Further details on the use of BIER to support EVPN can be found in Further details on the use of BIER to support EVPN can be found in
[EVPN-BIER]. [EVPN-BIER].
3.2.5. Inclusive P2MP Tunnels 3.2.5. Inclusive P2MP Tunnels
3.2.5.1. Using the BUM Tunnels as IP Multicast Inclusive Tunnels 3.2.5.1. Using the BUM Tunnels as IP Multicast Inclusive Tunnels
The procedures in this section apply only when it is desired to use The procedures in this section apply only when
the BUM tunnels to carry IP multicast traffic across the backbone.
In this cases, an IP multicast frame (whether inter-subnet or (a) it is desired to use the BUM tunnels to carry IP multicast
traffic across the backbone, and
(b) the BUM tunnels are P2MP tunnels (i.e., neither IR, AR, nor BIER
are being used to transport the BUM traffic).
In this case, an IP multicast frame (whether inter-subnet or
intra-subnet) will be carried across the backbone in the BUM tunnel intra-subnet) will be carried across the backbone in the BUM tunnel
belonging to its source BD. An EVPN-PE attached to a given Tenant belonging to its source BD. Each EVPN-PE attached to a given Tenant
Domain will then need to join the BUM tunnels for each BD in the Domain needs to join the BUM tunnels for every BD in the Tenant
Tenant Domain, even if the EVPN-PE is not attached to all of those Domain, even those BDs to which the EVPN-PE is not locally attached.
BDs. The reason is that an IP multicast packet from any source BD This ensures that an IP multicast packet from any source BD can reach
might be needed by an EVPN-PE that is not attached to that source all PEs attached to the Tenant Domain.
domain.
Note that this will cause BUM traffic from a given BD in a Tenant Note that this will cause all the BUM traffic from a given BD in a
Domain to be sent to all PEs that attach to that tenant domain, even Tenant Domain to be sent to all PEs that attach to that Tenant
the PEs that don't attach to the given BD. To avoid this, it is Domain, even the PEs that don't attach to the given BD. To avoid
RECOMMENDED that the BUM tunnels not be used as IP Multicast this, it is RECOMMENDED that the BUM tunnels not be used as IP
inclusive tunnels, and that the procedures of Section 3.2.5.2 be used Multicast inclusive tunnels, and that the procedures of
instead. Section 3.2.5.2 be used instead.
3.2.5.1.1. RSVP-TE P2MP If a PE is a possible ingress EVPN-PE for traffic originating outside
the Tenant Domain, the PE MUST originate an SBD-IMET route (see
Section 3.2.1). This route MUST carry a PTA specifying the P2MP
tunnel used for transmitting IP multicast packets that originate
outside the tenant domain. All EVPN-PEs of the Tenant Domain MUST
join the tunnel specified in the PTA of an SBD-IMET route:
When BUM tunnels created by RSVP-TE P2MP are used to transport IP o If the tunnel is an RSVP-TE P2MP tunnel, the originator of the
multicast frames of a given Tenant Domain, each EVPN-PE attached to route MUST use RSVP-TE P2MP procedures to add each PE of the
that Tenant Domain MUST originate an SBD-IMET route, as described in Tenant Domain to the tunnel, even PEs that have not originated an
Section 3.2.1.1. SBD-IMET route.
In addition, IMET routes that are originated for other BDs in the o If the tunnel is an mLDP or PIM tunnel, each PE importing the
Tenant Domain MUST carry the SBD-RT. SBD-IMET route MUST add itself to the tunnel, using mLDP or PIM
procedures, respectively.
Each IMET route (including but not limited to the SBD-IMET route) Whether or not a PE originates an SBD-IMET route, it will of course
MUST carry a PMSI Tunnel attribute (PTA). originate an IMET route for each BD to which it is attached. Each of
these IMET routes MUST carry the SBD-RT, as well as the RT for the BD
to which it belongs.
If received IMET route is not the SBD-IMET route, it will also be If a received IMET route is not the SBD-IMET route, it will also be
carrying the RT for its source BD. The route's NLRI will carry the carrying the RT for its source BD. The route's NLRI will carry the
Tag ID for the source BD. From the RT and the Tag ID, any PE Tag ID for the source BD. From the RT and the Tag ID, any PE
receiving the route can determine the route's source BD. receiving the route can determine the route's source BD.
If the MPLS label field of the PTA contains zero, the specified If the MPLS label field of the PTA contains zero, the specified P2MP
RSVP-TE P2MP tunnel is used only to carry frames of a single source tunnel is used only to carry frames of a single source BD.
BD.
If the MPLS label field of the PTA does not contain zero, it MUST If the MPLS label field of the PTA does not contain zero, it MUST
contain an upstream-assigned MPLS label that maps uniquely (in the contain an upstream-assigned MPLS label that maps uniquely (in the
context of the originating EVPN-PE) to the source BD (or, in the case context of the originating EVPN-PE) to the source BD (or, in the case
of an SBD-IMET route, the SBD). The tunnel may be used to carry of an SBD-IMET route, to the SBD). The tunnel may then be used to
frames of multiple source BDs, and the source BD for a particular carry frames of multiple source BDs. The apparent source BD of a
packet is inferred from the label carried by the packet. particular packet is inferred from the label carried by the packet.
IP multicast traffic originating outside the Tenant Domain is IP multicast traffic originating outside the Tenant Domain is
transmitted with the label corresponding to the SBD, as specified in transmitted with the label corresponding to the SBD, as specified in
the ingress EVPN-PE's SBD-IMET route. the ingress EVPN-PE's SBD-IMET route.
3.2.5.1.2. mLDP or PIM
When either mLDP or PIM is used to transport multicast packets of a
given Tenant Domain, an EVPN-PE attached to that tenant domain
originates an SBD-IMET route only if it is the ingress PE for IP
multicast traffic originating outside the tenant domain. Such
traffic is treated as having the SBD as its source BD.
An EVPN-PE MUST originate an IMET routes for each BD to which it is
attached. These IMET routes MUST carry the SBD-RT of the Tenant
Domain to which the BD belongs. Each such IMET route must also carry
the RT of the BD to which it belongs.
When an IMET route (other than the SBD-IMET route) is received by an
egress PE, the route will be carrying the RT for its source BD and
the route's NLRI will contain the Tag ID for that source BD. This
allows any PE receiving the route to determine the source BD
associated with the route.
If the MPLS label field of the PTA contains zero, the specified mLDP
or PIM tunnel is used only to carry frames of a single source BD.
If the MPLS label field of the PTA does not contain zero, it MUST
contain an upstream-assigned MPLS label that maps uniquely (in the
context of the originating EVPN-PE) to the source BD. The tunnel may
be used to carry frames of multiple source BDs, and the source BD for
a particular packet is inferred from the label carried by the packet.
The EVPN-PE advertising these IMET routes is specifying the default
tunnel that it will use (as ingress PE) for transmitting IP multicast
packets. The upstream-assigned label allows an egress PE to
determine the source BD of a given packet.
The procedures of this section apply whenever the tunnel technology
is based on the construction of the multicast trees in a "receiver-
driven" manner; mLDP and PIM are two ways of constructing trees in a
receiver-driven manner.
3.2.5.2. Using Wildcard S-PMSI A-D Routes to Advertise Inclusive 3.2.5.2. Using Wildcard S-PMSI A-D Routes to Advertise Inclusive
Tunnels Specific to IP Multicast Tunnels Specific to IP Multicast
The procedures of this section apply when (and only when) it is The procedures of this section apply when (and only when) it is
desired to transmit IP multicast traffic on an inclusive tunnel, but desired to transmit IP multicast traffic on an inclusive tunnel, but
not on the same tunnel used to transmit BUM traffic. not on the same tunnel used to transmit BUM traffic.
However, these procedures do NOT apply when the tunnel type is However, these procedures do NOT apply when the tunnel type is
Ingress Replication or BIER, EXCEPT in the case where it is necessary Ingress Replication or BIER, EXCEPT in the case where it is necessary
to interwork between non-OISM PEs and OISM PEs, as specified in to interwork between non-OISM PEs and OISM PEs, as specified in
Section 5. Section 5.
Each EVPN-PE attached to the given Tenant Domain MUST originate an Each EVPN-PE attached to the given Tenant Domain MUST originate an
SBD-SPMSI A-D route. The NLRI of that route MUST contain (C-*,C-*) SBD-SPMSI A-D route. The NLRI of that route MUST contain (C-*,C-*)
(see [RFC6625]). Additional rules for constructing that route are (see [RFC6625]). Additional rules for constructing that route are
given in Section 3.2.1.3. given in Section 3.2.1.
In addition, an EVPN-PE MUST originate an S-PMSI A-D route containing In addition, an EVPN-PE MUST originate an S-PMSI A-D route containing
(C-*,C-*) in its NLRI for each of the other BDs in the Tenant Domain (C-*,C-*) in its NLRI for each of the other BDs, in the given Tenant
to which it is attached. All such routes MUST carry the SBD-RT. Domain, to which it is attached. All such routes MUST carry the
This ensures that those routes are imported by all EVPN-PEs attached SBD-RT. This ensures that those routes are imported by all EVPN-PEs
to the Tenant Domain. attached to the Tenant Domain.
The route carrying the PTA will also be carrying the RT for that A PE receiving these routes follows the procedures of Section 2.2 to
source BD, and the route's NLRI will contain the Tag ID for that determine which BD the route is for.
source BD. This allows any PE receiving the route to determine the
source BD associated with the route.
If the MPLS label field of the PTA contains zero, the specified If the MPLS label field of the PTA contains zero, the specified
tunnel is used only to carry frames of a single source BD. tunnel is used only to carry frames of a single source BD.
If the MPLS label field of the PTA does not contain zero, it MUST If the MPLS label field of the PTA does not contain zero, it MUST
specify an upstream-assigned MPLS label that maps uniquely (in the specify an upstream-assigned MPLS label that maps uniquely (in the
context of the originating EVPN-PE) to the source BD. The tunnel may context of the originating EVPN-PE) to the source BD. The tunnel may
be used to carry frames of multiple source BDs, and the source BD for be used to carry frames of multiple source BDs, and the apparent
a particular packet is inferred from the label carried by the packet. source BD for a particular packet is inferred from the label carried
by the packet.
The EVPN-PE advertising these S-PMSI A-D route routes is specifying The EVPN-PE advertising these S-PMSI A-D route routes is specifying
the default tunnel that it will use (as ingress PE) for transmitting the default tunnel that it will use (as ingress PE) for transmitting
IP multicast packets. The upstream-assigned label allows an egress IP multicast packets. The upstream-assigned label allows an egress
PE to determine the source BD of a given packet. PE to determine the apparent source BD of a given packet.
3.2.6. Selective Tunnels 3.2.6. Selective Tunnels
An ingress EVPN-PE for a given multicast flow or set of flows can An ingress EVPN-PE for a given multicast flow or set of flows can
always assign the flow to a particular P2MP tunnel by originating an always assign the flow to a particular P2MP tunnel by originating an
S-PMSI A-D route whose NLRI identifies the flow or set of flows. The S-PMSI A-D route whose NLRI identifies the flow or set of flows. The
NLRI of the route could be (C-*,C-G), or (C-S,C-G). The S-PMSI A-D NLRI of the route could be (C-*,C-G), or (C-S,C-G). The S-PMSI A-D
route MUST carry the SBD-RT, so that it is imported by all EVPN-PEs route MUST carry the SBD-RT, so that it is imported by all EVPN-PEs
attached to the Tenant Domain. attached to the Tenant Domain.
An S-PMSI A-D route is "for" a particular source BD. It MUST carry An S-PMSI A-D route is "for" a particular source BD. It MUST carry
the RT associated with that BD, and it MUST have the Tag ID for that the RT associated with that BD, and it MUST have the Tag ID for that
BD in its NLRI. BD in its NLRI.
When an EVPN-PE imports an S-PMSI A-D route, it applies the rules of
Section 2.2 to associate the route with a particular BD.
Each such route MUST contain a PTA, as specified in Section 3.2.5.2. Each such route MUST contain a PTA, as specified in Section 3.2.5.2.
An egress EVPN-PE interested in the specified flow or flows MUST join An egress EVPN-PE interested in the specified flow or flows MUST join
the specified tunnel. Procedures for joining the specified tunnel the specified tunnel. Procedures for joining the specified tunnel
are specific to the tunnel type. (Note that if the tunnel type is are specific to the tunnel type. (Note that if the tunnel type is
RSVP-TE P2MP LSP, the Leaf Information Required (LIR) flag of the PTA RSVP-TE P2MP LSP, the Leaf Information Required (LIR) flag of the PTA
SHOULD NOT be set. An ingress OISM PE knows which OISM EVPN PEs are SHOULD NOT be set. An ingress OISM PE knows which OISM EVPN PEs are
interested in any given flow, and hence can add them to the RSVP-TE interested in any given flow, and hence can add them to the RSVP-TE
P2MP tunnel that carries such flows.) P2MP tunnel that carries such flows.)
When an EVPN-PE imports an S-PMSI A-D route, it infers the source BD If the PTA does not specify a non-zero MPLS label, the apparent
from the RTs and the Tag ID. If the EVPN-PE is not attached to the source BD of any packets that arrive on that tunnel is considered to
source BD, the tunnel it specifies is treated as belonging to the be the BD associated with the route that carries the PTA. If the PTA
SBD. That is, packets arriving on that tunnel are treated as having does specify a non-zero MPLS label, the apparent source BD of any
been sourced in the SBD. Note that a packet is only considered to packets that arrive on that tunnel carrying the specified label is
have arrived on the specified tunnel if the packet carries the considered to be the BD associated with the route that carries the
upstream-assigned label specified in in the PTA, or if there is no PTA.
upstream-assigned label specified in the PTA.
It should be noted that when either IR or BIER is used, there is no It should be noted that when either IR or BIER is used, there is no
need for an ingress PE to use S-PMSI A-D routes to assign specific need for an ingress PE to use S-PMSI A-D routes to assign specific
flows to selective tunnels. The procedures of Section 3.3, along flows to selective tunnels. The procedures of Section 3.3, along
with the procedures of Section 3.2.2, Section 3.2.3, or with the procedures of Section 3.2.2, Section 3.2.3, or
Section 3.2.4, provide the functionality of selective tunnels without Section 3.2.4, provide the functionality of selective tunnels without
the need to use S-PMSI A-D routes. the need to use S-PMSI A-D routes.
3.3. Advertising SMET Routes 3.3. Advertising SMET Routes
skipping to change at page 31, line 50 skipping to change at page 34, line 22
particular multicast flow or set of flows by originating an SMET particular multicast flow or set of flows by originating an SMET
route. The NLRI of the SMET route identifies the flow or set of route. The NLRI of the SMET route identifies the flow or set of
flows as (C-*,C-*) or (C-*,C-G) or (C-S,C-G). flows as (C-*,C-*) or (C-*,C-G) or (C-S,C-G).
Each SMET route belongs to a particular BD. The Tag ID for the BD Each SMET route belongs to a particular BD. The Tag ID for the BD
appears in the NLRI of the route, and the route carries the RT appears in the NLRI of the route, and the route carries the RT
associated that that BD. From this <RT, tag> pair, other EVPN-PEs associated that that BD. From this <RT, tag> pair, other EVPN-PEs
can identify the BD to which a received SMET route belongs. can identify the BD to which a received SMET route belongs.
(Remember though that the route may be carrying multiple RTs.) (Remember though that the route may be carrying multiple RTs.)
There are two cases to consider: There are three cases to consider:
1. Case 1: When it is known that no BD of a Tenant Domain contains a o Case 1: It is known that no BD of a Tenant Domain contains a
multicast router. multicast router.
In this case, an egress PE can advertise its interest in a flow In this case, an egress PE advertises its interest in a flow or
or set of flows by originating a single SMET route. The SMET set of flows by originating an SMET route that belongs to the SBD.
route will belong to the SBD. We refer to this as an SBD-SMET We refer to this as an SBD-SMET route. The SBD-SMET route carries
route. The SBD-SMET route carries the SBD-RT, and has the Tag ID the SBD-RT, and has the Tag ID for the SBD in its NLRI. SMET
for the SBD in its NLRI. SMET routes for the individual BDs are routes for the individual BDs are not needed, because there is no
not needed. need for a PE that receives an SMET route to send a corresponding
IGMP Join message out any of its ACs.
2. Case 2: When it is possible that a BD of a Tenant Domain contains o Case 2: It is known that more than one BD of a Tenant Domain may
a multicast router. contain a multicast router.
Suppose that an egress PE is attached to a BD on which there This is very like Case 1. An egress PE advertises its interest in
might be a tenant multicast router. (The tenant router is not a flow or set of flows by originating an SBD-SMET route. The
necessarily on a segment that is attached to that PE.) And SBD-SMET route carries the SBD-RT, and has the Tag ID for the SBD
suppose that the PE has one or more ACs attached to that BD which in its NLRI.
are interested in a given multicast flow. In this case, IN
ADDITION to the SMET route for the SBD, the egress PE MUST
originate an SMET route for that BD. This will enable the
ingress PE(s) to send IGMP/MLD messages on ACs for the BD, as
specified in [IGMP-Proxy].
If an SMET route is not an SBD-SMET route, and if the SMET route In this case, it is important to be sure that SMET routes for the
is for (C-S,C-G) (i.e., no wildcard source), and if the EVPN-PE individual BDs are not originated. Suppose, for example, that PE1
originating it knows the source BD of C-S, it MAY put only the RT had local receivers for a given flow on both BD1 and BD2, and that
for that BD on the route. Otherwise, the route MUST carry the it originated SMET routes for both those BDs. Then PEs receiving
SBD-RT, so that it gets distributed to all the EVPN-PEs attached those SMET routes might send IGMP Joins on both those BDs. This
to the tenant domain. could cause externally sourced multicast traffic to enter the
Tenant Domain at both BDs, which could result in duplication of
data.
As detailed in [IGMP-Proxy], an SMET route carries flags saying N.B.: If it is possible that more than one BD contains a tenant
whether it is to result in the propagation of IGMP v1, v2, or v3 multicast router, then in order to receive multicast data
messages on the ACs of the BD to which the SMET route belongs. These originating from outside EVPN, the PEs MUST follow the procedures
flags SHOULD be set to zero in an SBD-SMET route. of Section 6.
Note that a PE only needs to originate the set SBD-SMET routes that o Case 3: It is known that only a single BD of a Tenant Domain
are needed to pull in all the traffic in which it is interested. contains a multicast router.
Suppose that an egress PE is attached to a BD on which there might
be a tenant multicast router. (The tenant router is not
necessarily on a segment that is attached to that PE.) And
suppose that the PE has one or more ACs attached to that BD which
are interested in a given multicast flow. In this case, IN
ADDITION to the SMET route for the SBD, the egress PE MAY
originate an SMET route for that BD. This will enable the ingress
PE(s) to send IGMP/MLD messages on ACs for the BD, as specified in
[IGMP-Proxy]. As long as that is the only BD on which there is a
tenant multicast router, there is no possibility of duplication of
data.
This document does not specify procedures for dynamically determining
which of the three cases applies to a given deployment; the PEs of a
given Tenant Domain MUST be provisioned to know which case applies.
As detailed in [IGMP-Proxy], an SMET route carries a Multicast Flags
EC containing flags indicating whether it is to result in the
propagation of IGMP v1, v2, or v3 messages on the ACs of the BD to
which the SMET route belongs. These flags SHOULD be set to zero in
an SBD-SMET route.
Note that a PE only needs to originate the set of SBD-SMET routes
that are needed to pull in all the traffic in which it is interested.
Suppose PE1 has ACs attached to BD1 that are interested in (C-*,C-G) Suppose PE1 has ACs attached to BD1 that are interested in (C-*,C-G)
traffic, and ACs attached to BD2 that are interested in (C-S,C-G) traffic, and ACs attached to BD2 that are interested in (C-S,C-G)
traffic. A single SBD-SMET route specifying (C-*,C-G) will pull in traffic. A single SBD-SMET route specifying (C-*,C-G) will pull in
all the necessary flows. all the necessary flows.
As another example, suppose the ACs attached to BD1 are interested in As another example, suppose the ACs attached to BD1 are interested in
(C-*,C-G) but not in (C-S,C-G), while the ACs attached to BD2 are (C-*,C-G) but not in (C-S,C-G), while the ACs attached to BD2 are
interested in (C-S,C-G). A single SBD-SMET route specifying interested in (C-S,C-G). A single SBD-SMET route specifying
(C-*,C-G) will pull in all the necessary flows. (C-*,C-G) will pull in all the necessary flows.
In other words, to determine the set of SBD-SMET routes that have to In other words, to determine the set of SBD-SMET routes that have to
be sent for a given C-G, the PE has to merge the IGMP/MLD state for be sent for a given C-G, the PE has to merge the IGMP/MLD state for
all the BDs (of the given Tenant Domain) to which it is attached. all the BDs (of the given Tenant Domain) to which it is attached.
Per [IGMP-Proxy], importing an SMET route for a particular BD will Per [IGMP-Proxy], importing an SMET route for a particular BD will
cause IGMP/MLD state to be instantiated for the IRB interface to that cause IGMP/MLD state to be instantiated for the IRB interface to that
BD. This applies as well when the BD is the SBD. BD. This applies as well when the BD is the SBD.
However, traffic originating in a BD of a particular Tenant Domain However, traffic that originates in one of the actual BDs of a
MUST NOT be sent down the IRB interface that connects the L3 routing particular Tenant Domain MUST NOT be sent down the IRB interface that
instance of that Tenant Domain to the SBD of that Tenant Domain. connects the L3 routing instance of that Tenant Domain to the SBD.
That would cause duplicate delivery of traffic, since traffic That would cause duplicate delivery of traffic, since such traffic
arriving at L3 over the IRB interface from the SBD has already been will have already been distributed throughout the Tenant Domain.
distributed throughout the Tenant Domain. When setting up the IGMP/ Therefore, when setting up the IGMP/MLD state based on SBD-SMET
MLD state based on SBD-SMET routes, care must be taken to ensure that routes, care must be taken to ensure that the IRB interface to the
the IRB interface to the SBD is not added to the Outgoing Interface SBD is not added to the Outgoing Interface (OIF) list if the traffic
(OIF) list if the traffic originates within the Tenant Domain. originates within the Tenant Domain.
There are some multicast scenarios that make use of "anycast
sources". For example, two different sources may share the same
anycast IP address, say S1, and each may transmit an (S1,G) multicast
flow. In such a scenario, the two (S1,G) flows are typically
identical. Ordinary PIM procedures will cause only one the flows to
be delivered to each receiver that has expressed interest in either
(*,G) or (S1,G). However, the OISM procedures described in this
document will result in both of the (S1,G) flows being distributed in
the Tenant Domain, and duplicate delivery will result. Therefore, if
there are receivers for (*,G) in a given Tenant Domain, there MUST
NOT be anycast sources for G within that Tenant Domain. (This
restriction can be lifted by defining additional procedures; however
that is outside the scope of this document.)
4. Constructing Multicast Forwarding State 4. Constructing Multicast Forwarding State
4.1. Layer 2 Multicast State 4.1. Layer 2 Multicast State
An EVPN-PE maintains "layer 2 multicast state" for each BD to which An EVPN-PE maintains "layer 2 multicast state" for each BD to which
it is attached. it is attached.
Let PE1 be an EVPN-PE, and BD1 be a BD to which it is attached. At Let PE1 be an EVPN-PE, and BD1 be a BD to which it is attached. At
PE1, BD1's layer 2 multicast state for a given (C-S,C-G) or (C-*,C-G) PE1, BD1's layer 2 multicast state for a given (C-S,C-G) or (C-*,C-G)
governs the disposition of an IP multicast packet that is received by governs the disposition of an IP multicast packet that is received by
BD1's layer 2 multicast function on an EVPN-PE. BD1's layer 2 multicast function on an EVPN-PE.
An IP multicast (S,G) packet is considered to have been received by An IP multicast (S,G) packet is considered to have been received by
BD1's layer 2 multicast function in PE1 in the following cases: BD1's layer 2 multicast function in PE1 in the following cases:
o The packet is the payload of an ethernet frame received by PE1 o The packet is the payload of an ethernet frame received by PE1
from an AC that attaches to BD1. from an AC that attaches to BD1.
o The packet is the payload of an ethernet frame whose source BD is o The packet is the payload of an ethernet frame whose apparent
BD1, and which is received by the PE1 over a tunnel from another source BD is BD1, and which is received by the PE1 over a tunnel
EVPN-PE. from another EVPN-PE.
o The packet is received from BD1's IRB interface (i.e., has been o The packet is received from BD1's IRB interface (i.e., has been
transmitted by PE1's L3 routing instance down BD1's IRB transmitted by PE1's L3 routing instance down BD1's IRB
interface). interface).
According to the procedures of this document, all transmission of IP According to the procedures of this document, all transmission of IP
multicast packets from one EVPN-PE to another is done at layer 2. multicast packets from one EVPN-PE to another is done at layer 2.
That is, the packets are transmitted as ethernet frames, according to That is, the packets are transmitted as ethernet frames, according to
the layer 2 multicast state. the layer 2 multicast state.
skipping to change at page 35, line 12 skipping to change at page 38, line 23
change from time to time as ACs and/or remote PEs either become change from time to time as ACs and/or remote PEs either become
interested in, or lose interest in, particular multicast flows. interested in, or lose interest in, particular multicast flows.
4.1.2. Data Plane: Applying the OIF List to an (S,G) Frame 4.1.2. Data Plane: Applying the OIF List to an (S,G) Frame
When an (S,G) multicast frame is received by the layer 2 multicast When an (S,G) multicast frame is received by the layer 2 multicast
function of a given EVPN-PE, say PE1, its disposition depends (a) the function of a given EVPN-PE, say PE1, its disposition depends (a) the
way it was received, (b) upon the OIF list of the corresponding way it was received, (b) upon the OIF list of the corresponding
multicast state (see Section 4.1.1), (c) upon the "eligibility" of an multicast state (see Section 4.1.1), (c) upon the "eligibility" of an
AC to receive a given frame (see Section 4.1.2.1 and (d) upon its AC to receive a given frame (see Section 4.1.2.1 and (d) upon its
source BD (see Section 3.2 for information about determining the apparent source BD (see Section 3.2 for information about determining
source BD of a frame received over a tunnel from another PE). the apparent source BD of a frame received over a tunnel from another
PE).
4.1.2.1. Eligibility of an AC to Receive a Frame 4.1.2.1. Eligibility of an AC to Receive a Frame
A given (S,G) multicast frame is eligible to be transmitted by a A given (S,G) multicast frame is eligible to be transmitted by a
given PE, say PE1, on a given AC, say AC1, only if one of the given PE, say PE1, on a given AC, say AC1, only if one of the
following conditions holds: following conditions holds:
1. ESI labels are being used, PE1 is the DF for the segment to which 1. ESI labels are being used, PE1 is the DF for the segment to which
AC1 is connected, and the frame did not originate from that same AC1 is connected, and the frame did not originate from that same
segment (as determined by the ESI label), or segment (as determined by the ESI label), or
2. The ingress PE for the frame is a remote PE, say PE2, local bias 2. The ingress PE for the frame is a remote PE, say PE2, local bias
is being used, and PE2 is not connected to the same segment as is being used, and PE2 is not connected to the same segment as
AC1. AC1.
4.1.2.2. Applying the OIF List 4.1.2.2. Applying the OIF List
Assume a given (S,G) multicast frame has been received by a given PE, Assume a given (S,G) multicast frame has been received by a given PE,
say PE1. PE1 determines the source BD of the frame, finds the layer say PE1. PE1 determines the apparent source BD of the frame, finds
2 (S,G) state for the source BD (or the (*,G) state if there is no the layer 2 (S,G) state for that BD (or the (*,G) state if there is
(S,G) state), and takes the OIF list from that state. Note that if no (S,G) state), and takes the OIF list from that state. (Note that
PE1 is not attached to the actual source BD, it will treat the frame if PE1 is not attached to the actual source BD, the apparent source
as if its source BD is the SBD. BD will be the SBD.)
Suppose PE1 has determined the frame's apparent source BD to be BD1
Suppose PE1 has determined the frame's source BD to be BD1 (which may (which may or may not be the SBD.) There are the following cases to
or may not be the SBD.) There are the following cases to consider: consider:
1. The frame was received by PE1 from a local AC, say AC1, that 1. The frame was received by PE1 from a local AC, say AC1, that
attaches to BD1. attaches to BD1.
a. The frame MUST be sent out all local ACs of BD1 that appear a. The frame MUST be sent out all local ACs of BD1 that appear
in the OIF list, except for AC1 itself. in the OIF list, except for AC1 itself.
b. The frame MUST also be delivered to any other EVPN-PEs that b. The frame MUST also be delivered to any other EVPN-PEs that
have interest in it. This is achieved as follows: have interest in it. This is achieved as follows:
skipping to change at page 36, line 13 skipping to change at page 39, line 29
to the AR-REPLICATOR. to the AR-REPLICATOR.
ii. Otherwise the frame MUST be sent on all tunnels in the ii. Otherwise the frame MUST be sent on all tunnels in the
OIF list. OIF list.
c. The frame MUST be sent to the local L3 routing instance by c. The frame MUST be sent to the local L3 routing instance by
being sent up the IRB interface of BD1. It MUST NOT be sent being sent up the IRB interface of BD1. It MUST NOT be sent
up any other IRB interfaces. up any other IRB interfaces.
2. The frame was received by PE1 over a tunnel from another PE. 2. The frame was received by PE1 over a tunnel from another PE.
(See Section 3.2 for the rules to determine the source BD of a (See Section 3.2 for the rules to determine the apparent source
packet received from another PE. Note that if PE1 is not BD of a packet received from another PE. Note that if PE1 is not
attached to the source BD, it will regard the SBD as the source attached to the source BD, it will regard the SBD as the apparent
BD.) source BD.)
a. The frame MUST be sent out all local ACs in the OIF list that a. The frame MUST be sent out all local ACs in the OIF list that
connect to BD1 and that are eligible (per Section 4.1.2.1) to connect to BD1 and that are eligible (per Section 4.1.2.1) to
receive the frame. receive the frame.
b. The frame MUST be sent up the IRB interface of the source BD. b. The frame MUST be sent up the IRB interface of the apparent
(Note that this may be the SBD.) The frame MUST NOT be sent source BD. (Note that this may be the SBD.) The frame MUST
up any other IRB interfaces. NOT be sent up any other IRB interfaces.
c. If PE1 is not an AR-REPLICATOR, it MUST NOT send the frame to c. If PE1 is not an AR-REPLICATOR, it MUST NOT send the frame to
any other EVPN-PEs. However, if PE1 is an AR-REPLICATOR, it any other EVPN-PEs. However, if PE1 is an AR-REPLICATOR, it
MUST send the frame to all tunnels in the OIF list, except MUST send the frame to all tunnels in the OIF list, except
for the tunnel over which the frame was received. for the tunnel over which the frame was received.
3. The frame was received by PE1 from the BD1 IRB interface (i.e., 3. The frame was received by PE1 from the BD1 IRB interface (i.e.,
the frame has been transmitted by PE1's L3 routing instance down the frame has been transmitted by PE1's L3 routing instance down
the BD1 IRB interface), and BD1 is NOT the SBD. the BD1 IRB interface), and BD1 is NOT the SBD.
skipping to change at page 38, line 27 skipping to change at page 41, line 45
o BD-R: a BD that contains a host interested in the flow. The host o BD-R: a BD that contains a host interested in the flow. The host
is attached to PE-R via an AC that belongs to BD-R. is attached to PE-R via an AC that belongs to BD-R.
To allow OISM PEs to interwork with non-OISM PEs, a given Tenant To allow OISM PEs to interwork with non-OISM PEs, a given Tenant
Domain needs to contain one or more "IP Multicast Gateways" (IPMGs). Domain needs to contain one or more "IP Multicast Gateways" (IPMGs).
An IPMG is an OISM PE with special responsibilities regarding the An IPMG is an OISM PE with special responsibilities regarding the
interworking between OISM and non-OISM PEs. interworking between OISM and non-OISM PEs.
If a PE is functioning as an IPMG, it MUST signal this fact by If a PE is functioning as an IPMG, it MUST signal this fact by
attaching a particular flag or EC (details to be determined) to its setting the "IPMG" flag in the Multicast Flags EC that it attaches to
IMET routes. An IPMG SHOULD attach this flag or EC to all IMET its IMET routes. An IPMG SHOULD attach this EC with the IPMG flag
routes it originates. However, if PE1 imports any IMET route from set to all IMET routes it originates. However, if PE1 imports any
PE2 that has the "IPMG" flag or EC present, then the PE1 will assume IMET route from PE2 that has the EC present with the "IPMG" flag set,
that PE2 is an IPMG. then the PE1 will assume that PE2 is an IPMG.
An IPMG Designated Forwarder (IPMG-DF) selection procedure is used to An IPMG Designated Forwarder (IPMG-DF) selection procedure is used to
ensure that, at any given time, there is exactly one active IPMG-DF ensure that, at any given time, there is exactly one active IPMG-DF
for any given BD. Details of the IPMG-DF selection procedure are in for any given BD. Details of the IPMG-DF selection procedure are in
Section 5.1. The IPMG-DF for a given BD, say BD-S, has special Section 5.1. The IPMG-DF for a given BD, say BD-S, has special
functions to perform when it receives (S,G) frames on that BD: functions to perform when it receives (S,G) frames on that BD:
o If the frames are from a non-OISM PE-S: o If the frames are from a non-OISM PE-S:
* The IPMG-DF forwards them to OISM PEs that do not attach to * The IPMG-DF forwards them to OISM PEs that do not attach to
skipping to change at page 40, line 13 skipping to change at page 43, line 32
route. route.
The interworking procedures vary somewhat depending upon whether The interworking procedures vary somewhat depending upon whether
packets are transmitted from PE to PE via Ingress Replication (IR) or packets are transmitted from PE to PE via Ingress Replication (IR) or
via Point-to-Multipoint (P2MP) tunnels. We do not consider the use via Point-to-Multipoint (P2MP) tunnels. We do not consider the use
of BIER in this section, due to the low likelihood of there being a of BIER in this section, due to the low likelihood of there being a
non-OISM PE that supports BIER. non-OISM PE that supports BIER.
5.1. IPMG Designated Forwarder 5.1. IPMG Designated Forwarder
Each IPMG MUST be configured with an "IPMG dummy ethernet segment" Every PE that is eligible for selection as an IPMG-DF for a
that has no ACs. particular BD originates both an IMET route for that BD and an
SBD-IMET route. As stated in Section 5, these SBD-IMET routes carry
a Multicast Flags EC with the IPMG Flag set.
EVPN supports a number of procedures that can be used to select the These SBD-IMET routes SHOULD also carry a DF Election EC. The DF
Designated Forwarder (DF) for a particular BD on a particular Election EC and its use is specified in ([DF-Election-Framework]).
ethernet segment. Some of the possible procedures can be found, When the route is originated, the AC-DF bit in the DF Election EC
e.g., in [RFC7432], [EVPN-DF-NEW], and [EVPN-DF-WEIGHTED]. Whatever SHOULD be set to zero. This bit is not used when selecting an
procedure is in use in a given deployment can be adapted to select an IPMSG-DF, i.e., it MUST be ignored by the receiver of an SBD-IMET
IPMG-DF for a given BD, as follows. route.
Each IPMG will originate an Ethernet Segment route for the IPMG dummy In the context of a given Tenant Domain, to select the IPMG-DF for a
ethernet segment. It MUST carry a Route Target derived from the particular BD, say BD1, the IPMGs of the Tenant Domain perform the
corresponding Ethernet Segment Identifier. Thus only IPMGs will following procedure:
import the route.
Once the set of IPMGs is known, it is also possible to determine the o From the set of received SBD-IMET routes for the given tenant
set of BDs supported by each IPMG. The DF selection procedure can domain, determine the candidate set of PEs that support IPMG
then be used to choose a DF for each BD. (The conditions under which functionality for that domain.
the IPMG-DF for a given BD changes depends upon the DF selection
algorithm that is in use.) o Eliminate from that candidate set any PEs from which an IMET route
for BD1 has not been received.
o Select a DF Election algorithm as specified in
[DF-Election-Framework]. Some of the possible algorithms can be
found, e.g., in [DF-Election-Framework], [RFC7432], and
[EVPN-DF-WEIGHTED].
o Apply the DF Election Algorithm (see [DF-Election-Framework]) to
the candidate set of PEs. The "winner' becomes the IPMG-DF for
BD1.
Note that even if a given PE supports MEG (Section 6.1.2) and/or PEG
(Section 6.1.4) functionality, as well as IPMG functionality, its
SBD-IMET routes carry only one DF Election EC.
5.2. Ingress Replication 5.2. Ingress Replication
The procedures of this section are used when Ingress Replication is The procedures of this section are used when Ingress Replication is
used to transmit packets from one PE to another. used to transmit packets from one PE to another.
When a non-OISM PE-S transmits a multicast frame from BD-S to another When a non-OISM PE-S transmits a multicast frame from BD-S to another
PE, PE-R, PE-S will use the encapsulation specified in the BD-S IMET PE, PE-R, PE-S will use the encapsulation specified in the BD-S IMET
route that was originated by PE-R. This encapsulation will include route that was originated by PE-R. This encapsulation will include
the label that appears in the "MPLS label" field of the PMSI Tunnel the label that appears in the "MPLS label" field of the PMSI Tunnel
skipping to change at page 45, line 5 skipping to change at page 48, line 40
not consider the case where the Tenant Domain contains multicast not consider the case where the Tenant Domain contains multicast
routers that will receive traffic from sources outside the domain and routers that will receive traffic from sources outside the domain and
forward the traffic to receivers outside the domain. The transit forward the traffic to receivers outside the domain. The transit
scenario is considered in Section 7. scenario is considered in Section 7.
We can divide the non-transit scenarios into two classes: We can divide the non-transit scenarios into two classes:
1. One or more of the EVPN PE routers provide the functionality 1. One or more of the EVPN PE routers provide the functionality
needed to interwork with layer 3 multicast routing procedures. needed to interwork with layer 3 multicast routing procedures.
2. One BD in the Tenant Domain contains external multicast routers 2. A single BD in the Tenant Domain contains external multicast
("tenant multicast routers") that are used to interwork the routers ("tenant multicast routers"), and those tenant multicast
entire Tenant Domain with layer 3 multicast routing procedures. routers are used to interwork, on behalf of the entire Tenant
Domain, with layer 3 multicast routing procedures.
6.1. Layer 3 Interworking via EVPN OISM PEs 6.1. Layer 3 Interworking via EVPN OISM PEs
6.1.1. General Principles 6.1.1. General Principles
Sometimes it is necessary to interwork an EVPN Tenant Domain with an Sometimes it is necessary to interwork an EVPN Tenant Domain with an
external layer 3 multicast domain (the "external domain"). This is external layer 3 multicast domain (the "external domain"). This is
needed to allow EVPN tenant systems to receive multicast traffic from needed to allow EVPN tenant systems to receive multicast traffic from
sources ("external sources") outside the EVPN Tenant Domain. It is sources ("external sources") outside the EVPN Tenant Domain. It is
also needed to allow receivers ("external receivers") outside the also needed to allow receivers ("external receivers") outside the
skipping to change at page 45, line 41 skipping to change at page 49, line 28
routes (either IP routes or VPN-IP routes) from routers other than routes (either IP routes or VPN-IP routes) from routers other than
EVPN PEs. And since there may be multicast sources inside the EVPN EVPN PEs. And since there may be multicast sources inside the EVPN
Tenant Domain, the EVPN PEs also need to export, either as IP routes Tenant Domain, the EVPN PEs also need to export, either as IP routes
or as VPN-IP routes (depending upon the external domain), unicast or as VPN-IP routes (depending upon the external domain), unicast
routes to those sources. routes to those sources.
When selecting the best route to a multicast source or RP, an L3 When selecting the best route to a multicast source or RP, an L3
Gateway might have a choice between an EVPN route and an IP/VPN-IP Gateway might have a choice between an EVPN route and an IP/VPN-IP
route. When such a choice exists, the L3 Gateway SHOULD always route. When such a choice exists, the L3 Gateway SHOULD always
prefer the EVPN route. This will ensure that when traffic originates prefer the EVPN route. This will ensure that when traffic originates
in the Tenant Domain and has a receiver in the tenant domain, the in the Tenant Domain and has a receiver in the Tenant Domain, the
path to that receiver will remain within the EVPN tenant domain, even path to that receiver will remain within the EVPN Tenant Domain, even
if the source is also reachable via a routed path. This also if the source is also reachable via a routed path. This also
provides protection against sub-optimal routing that might occur if provides protection against sub-optimal routing that might occur if
two EVPN PEs export IP/VPN-IP routes and each imports the other's IP/ two EVPN PEs export IP/VPN-IP routes and each imports the other's IP/
VPN-IP routes. VPN-IP routes.
Section 4.2 discusses the way layer 3 multicast states are Section 4.2 discusses the way layer 3 multicast states are
constructed by OISM PEs. These layer 3 multicast states have IRB constructed by OISM PEs. These layer 3 multicast states have IRB
interfaces as their IIF and OIF list entries, and are the basis for interfaces as their IIF and OIF list entries, and are the basis for
interworking OISM with other layer 3 multicast procedures such as interworking OISM with other layer 3 multicast procedures such as
MVPN or PIM. From the perspective of the layer 3 multicast MVPN or PIM. From the perspective of the layer 3 multicast
skipping to change at page 46, line 36 skipping to change at page 50, line 25
o It imports, from the external domain, unicast routes to multicast o It imports, from the external domain, unicast routes to multicast
sources that are in the external domain. sources that are in the external domain.
o It executes the procedures necessary to draw externally sourced o It executes the procedures necessary to draw externally sourced
multicast traffic that is of interest to locally attached multicast traffic that is of interest to locally attached
receivers in the EVPN Tenant Domain. When such traffic is receivers in the EVPN Tenant Domain. When such traffic is
received, the traffic is sent down the IRB interfaces of the BDs received, the traffic is sent down the IRB interfaces of the BDs
on which the locally attached receivers reside. on which the locally attached receivers reside.
One of the L3 Gateways in a given Tenant Domain becomes the "DR" for One of the L3 Gateways in a given Tenant Domain becomes the "DR" for
the SBD.(See Section 6.1.2.4.) This L3 gateway has the following the SBD. (See Section 6.1.2.4.) This L3 gateway has the following
additional responsibilities: additional responsibilities:
o It exports, to the external domain, unicast routes to multicast o It exports, to the external domain, unicast routes to multicast
sources that in the EVPN Tenant Domain that are not locally sources that in the EVPN Tenant Domain that are not locally
attached to any L3 gateway. attached to any L3 gateway.
o It imports, from the external domain, unicast routes to multicast o It imports, from the external domain, unicast routes to multicast
sources that are in the external domain. sources that are in the external domain.
o It executes the procedures necessary to draw externally sourced o It executes the procedures necessary to draw externally sourced
skipping to change at page 47, line 47 skipping to change at page 51, line 35
by a FHR, the DR for a given BD would send the PIM Register messages by a FHR, the DR for a given BD would send the PIM Register messages
for sources on that BD.) Note though that the DR for the SBD does for sources on that BD.) Note though that the DR for the SBD does
not perform FHR functionality on behalf of external sources. not perform FHR functionality on behalf of external sources.
An optional alternative is to have each L3 gateway perform FHR An optional alternative is to have each L3 gateway perform FHR
functionality for locally attached sources. Then the DR would only functionality for locally attached sources. Then the DR would only
have to perform FHR functionality on behalf of sources that are have to perform FHR functionality on behalf of sources that are
locally attached to itself AND sources that are not attached to any locally attached to itself AND sources that are not attached to any
L3 gateway. L3 gateway.
N.B.: If it is possible that more than one BD contains a tenant
multicast router, then a PE receiving an SMET route for that BD MUST
NOT reconstruct IGMP Join Reports from the SMET route, and MUST NOT
transmit any such IGMP Join Reports on its local ACs attaching to
that BD. Otherwise, multicast traffic may be duplicated.
6.1.2. Interworking with MVPN 6.1.2. Interworking with MVPN
In this section, we specify the procedures necessary to allow EVPN In this section, we specify the procedures necessary to allow EVPN
PEs running OISM procedures to interwork with L3VPN PEs that run BGP- PEs running OISM procedures to interwork with L3VPN PEs that run BGP-
based MVPN ([RFC6514]) procedures. More specifically, the procedures based MVPN ([RFC6514]) procedures. More specifically, the procedures
herein allow a given EVPN Tenant Domain to become part of an L3VPN/ herein allow a given EVPN Tenant Domain to become part of an L3VPN/
MVPN, and support multicast flows where either: MVPN, and support multicast flows where either:
o The source of a given multicast flow is attached to an ethernet o The source of a given multicast flow is attached to an ethernet
segment whose BD is part of an EVPN Tenant Domain, and one or more segment whose BD is part of an EVPN Tenant Domain, and one or more
skipping to change at page 49, line 13 skipping to change at page 53, line 10
conform to the EVPN rules (as specified in [RFC7432]) for creating conform to the EVPN rules (as specified in [RFC7432]) for creating
RDs. Therefore a MEG MUST NOT expect the RDs of the VPN-IP routes to RDs. Therefore a MEG MUST NOT expect the RDs of the VPN-IP routes to
be of any particular format other than what is required by the L3VPN/ be of any particular format other than what is required by the L3VPN/
MVPN specifications. MVPN specifications.
The VPN-IP routes that a MEG exports to L3VPN are subnet routes and/ The VPN-IP routes that a MEG exports to L3VPN are subnet routes and/
or host routes for the multicast sources that are part of the EVPN or host routes for the multicast sources that are part of the EVPN
tenant domain. The exact set of routes that need to be exported is tenant domain. The exact set of routes that need to be exported is
discussed in Section 6.1.2.2. discussed in Section 6.1.2.2.
Each IMET route originated by a MEG SHOULD carry a flag or Extended Each IMET route originated by a MEG SHOULD carry a Multicast Flags
Community (to be determined) indicating that the originator of the Extended Community with the "MEG" flag set, indicating that the
IMET route is a MEG. However, PE1 will consider PE2 to be a MEG if originator of the IMET route is a MEG. However, PE1 will consider
PE1 imports at least one IMET route from PE2 that carries the flag or PE2 to be a MEG if PE1 imports at least one IMET route from PE2 that
EC. carries the Multicast Flags EC with the MEG flag set.
All the MEGs of a given Tenant Domain attach to the SBD of that All the MEGs of a given Tenant Domain attach to the SBD of that
domain, and one of them is selected to be the SBD's Designated Router domain, and one of them is selected to be the SBD's Designated Router
(DR) for the domain. The selection procedure is discussed in (the "MEG SBD-DR") for the domain. The selection procedure is
Section 6.1.2.4. discussed in Section 6.1.2.4.
In this model of operation, MVPN procedures and EVPN procedures are In this model of operation, MVPN procedures and EVPN procedures are
largely independent. In particular, there is no assumption that MVPN largely independent. In particular, there is no assumption that MVPN
and EVPN use the same kind of tunnels. Thus no special procedures and EVPN use the same kind of tunnels. Thus no special procedures
are needed to handle the common scenarios where, e.g., EVPN uses are needed to handle the common scenarios where, e.g., EVPN uses
VXLAN tunnels but MVPN uses MPLS P2MP tunnels, or where EVPN uses VXLAN tunnels but MVPN uses MPLS P2MP tunnels, or where EVPN uses
Ingress Replication but MVPN uses MPLS P2MP tunnels. Ingress Replication but MVPN uses MPLS P2MP tunnels.
Similarly, no special procedures are needed to prevent duplicate data Similarly, no special procedures are needed to prevent duplicate data
delivery on ethernet segments that are multi-homed. delivery on ethernet segments that are multi-homed.
skipping to change at page 50, line 18 skipping to change at page 54, line 12
problems that might arise if there is a unicast route via L3VPN to S, problems that might arise if there is a unicast route via L3VPN to S,
but no multicast routers along the routed path. This also prevents but no multicast routers along the routed path. This also prevents
problem that might arise as a result of the fact that the MEGs will problem that might arise as a result of the fact that the MEGs will
import each others' VPN-IP routes. import each others' VPN-IP routes.
In the Section 6.1.2.1.2, we describe the procedures to be used when In the Section 6.1.2.1.2, we describe the procedures to be used when
the selected route to S is a VPN-IP route. the selected route to S is a VPN-IP route.
6.1.2.1.2. Joining a Flow from an MVPN Source 6.1.2.1.2. Joining a Flow from an MVPN Source
Suppose a tenant system R wants to receive (S,G) multicast traffic, Consider a tenant system, R, on a particular BD, BD-R. Suppose R
where source S is not attached to any PE in the EVPN Tenant Domain, wants to receive (S,G) multicast traffic, where source S is not
but is attached to an MVPN PE. attached to any PE in the EVPN Tenant Domain, but is attached to an
MVPN PE.
o Suppose R is on a singly homed ethernet segment of BD-R, and that o Suppose R is on a singly homed ethernet segment of BD-R, and that
segment is attached to PE1, where PE1 is a MEG. PE1 learns via segment is attached to PE1, where PE1 is a MEG. PE1 learns via
IGMP/MLD listening that R is interested in (S,G). PE1 determines IGMP/MLD listening that R is interested in (S,G). PE1 determines
from its VRF that there is no route to S within the Tenant Domain from its VRF that there is no route to S within the Tenant Domain
(i.e., no EVPN RT-2 route with S's IP address), but that there is (i.e., no EVPN RT-2 route with S's IP address), but that there is
a route to S via L3VPN (i.e., the VRF contains a subnet or host a route to S via L3VPN (i.e., the VRF contains a subnet or host
route to S that was received as a VPN-IP route). PE1 thus route to S that was received as a VPN-IP route). PE1 thus
originates (if it hasn't already) an MVPN C-multicast Source Tree originates (if it hasn't already) an MVPN C-multicast Source Tree
Join(S,G) route. The route is constructed according to normal Join(S,G) route. The route is constructed according to normal
skipping to change at page 50, line 48 skipping to change at page 54, line 43
When PE1 receives (S,G) traffic from the appropriate MVPN tunnel, When PE1 receives (S,G) traffic from the appropriate MVPN tunnel,
it performs IP processing of the traffic, and then sends the it performs IP processing of the traffic, and then sends the
traffic down its IRB interface to BD-R. Following normal OISM traffic down its IRB interface to BD-R. Following normal OISM
procedures, the (S,G) traffic will be encapsulated for ethernet procedures, the (S,G) traffic will be encapsulated for ethernet
and sent out the AC to which R is attached. and sent out the AC to which R is attached.
o Suppose R is on a singly homed ethernet segment of BD-R, and that o Suppose R is on a singly homed ethernet segment of BD-R, and that
segment is attached to PE1, where PE1 is an OISM PE but is NOT a segment is attached to PE1, where PE1 is an OISM PE but is NOT a
MEG. PE1 learns via IGMP/MLD listening that R is interested in MEG. PE1 learns via IGMP/MLD listening that R is interested in
(S,G). PE1 follows normal OISM procedures, originating an SMET (S,G). PE1 follows normal OISM procedures, originating an SBD-
route in BD-R for (S,G). Since this route will carry the SBD-RT, SMET route for (S,G); this route will be received by all the MEGs
it will be received by the MEG that is the DR for the Tenant of the Tenant Domain, including the MEG SBD-DR. The MEG SBD-DR
Domain. The MEG DR can determine from PE1's IMET route whether can determine from PE1's IMET routes whether PE1 is itself a MEG.
PE1 is itself a MEG. If PE1 is not a MEG, the MEG DR will If PE1 is not a MEG, the MEG SBD-DR will originate (if it hasn't
originate (if it hasn't already) an MVPN C-multicast Source Tree already) an MVPN C-multicast Source Tree Join(S,G) route. This
Join(S,G) route. This will cause the DR MEG to receive (S,G) will cause the MEG SBD-DR to receive (S,G) traffic on an MVPN
traffic on an MVPN tunnel. tunnel.
The layer 2 multicast state is constructed as specified in The layer 2 multicast state is constructed as specified in
Section 4.1. Section 4.1.
In the layer 3 multicast state, the IIF is the appropriate MVPN In the layer 3 multicast state, the IIF is the appropriate MVPN
tunnel, and the IRB interface to the SBD is added to the OIF list. tunnel, and the IRB interface to the SBD is added to the OIF list.
When the DR MEG receives (S,G) traffic on an MVPN tunnel, it When the MEG SBD-DR receives (S,G) traffic on an MVPN tunnel, it
performs IP processing of the traffic, and the sends the traffic performs IP processing of the traffic, and the sends the traffic
down its IRB interface to the SBD. Following normal OISM down its IRB interface to the SBD. Following normal OISM
procedures, the traffic will be encapsulated for ethernet and procedures, the traffic will be encapsulated for ethernet and
delivered to all PEs in the Tenant Domain that have interest in delivered to all PEs in the Tenant Domain that have interest in
(S,G), including PE1. (S,G), including PE1.
o If R is on a multi-homed ethernet segment of BD-R, one of the PEs o If R is on a multi-homed ethernet segment of BD-R, one of the PEs
attached to the segment will be its DF (following normal EVPN attached to the segment will be its DF (following normal EVPN
procedures), and the DF will know (via the procedures of procedures), and the DF will know (via IGMP/MLD listening or the
[IGMP-Proxy] that a tenant system reachable via one of its local procedures of [IGMP-Proxy]) that a tenant system reachable via one
ACs to BD-R is interested in (S,G) traffic. The DF is responsible of its local ACs to BD-R is interested in (S,G) traffic. The DF
for originating an SMET route for (S,G), following normal OISM is responsible for originating an SBD-SMET route for (S,G),
procedures. If the DF is a MEG, it will originate the following normal OISM procedures. If the DF is a MEG, it MUST
corresponding MVPN C-multicast Source Tree Join(S,G) route; if the originate the corresponding MVPN C-multicast Source Tree Join(S,G)
DF is not a MEG, the MEG that is the DR will originate the route; if the DF is not a MEG, the MEG SBD-DR SBD MUST originate
C-multicast route when it receives the SMET route. the C-multicast route when it receives the SMET route.
Optionally, if the non-DF is a MEG, it MAY originate the
corresponding MVPN C-multicast Source Tree Join(S,G) route. This
will cause the traffic to flow to both the DF and the non-DF, but
only the DF will forward the traffic out an AC. This allows for
quicker recovery if the DF's local AC to R fails.
o If R is attached to a non-OISM PE, it will receive the traffic via o If R is attached to a non-OISM PE, it will receive the traffic via
an IPMG, as specified in Section 5. an IPMG, as specified in Section 5.
If an EVPN-attached receiver is interested in (*,G) traffic, and if If an EVPN-attached receiver is interested in (*,G) traffic, and if
it is possible for there to be sources of (*,G) traffic that are it is possible for there to be sources of (*,G) traffic that are
attached only to L3VPN nodes, the MEGs will have to know the group- attached only to L3VPN nodes, the MEGs will have to know the group-
to-RP mappings. That will enable them to originate MVPN C-multicast to-RP mappings. That will enable them to originate MVPN C-multicast
Shared Tree Join(*,G) routes and to send them towards the RP. (Since Shared Tree Join(*,G) routes and to send them towards the RP. (Since
we are assuming in this section that there are no tenant multicast we are assuming in this section that there are no tenant multicast
skipping to change at page 53, line 42 skipping to change at page 57, line 42
o If S belongs to a BD that is attached to the MEG, the IIF will be o If S belongs to a BD that is attached to the MEG, the IIF will be
the IRB interface to that BD; the IRB interface to that BD;
o Otherwise the IIF will be the SBD IRB interface. o Otherwise the IIF will be the SBD IRB interface.
Note that this works even if S is attached to a non-OISM PE, per the Note that this works even if S is attached to a non-OISM PE, per the
procedures of Section 5. procedures of Section 5.
6.1.2.2.2. Any-Source Multicast (ASM) Groups 6.1.2.2.2. Any-Source Multicast (ASM) Groups
Suppose the MEG DR learns that one of the PEs in its Tenant Domain is Suppose the MEG SBD-DR learns that one of the PEs in its Tenant
interested in (*,G), traffic, where G is an Any-Source Multicast Domain is interested in (*,G), traffic, where G is an Any-Source
(ASM) group. If there are no tenant multicast routers, the MEG DR Multicast (ASM) group. If there are no tenant multicast routers, the
SHOULD perform the "First Hop Router" (FHR) functionality for group G MEG SBD-DR SHOULD perform the "First Hop Router" (FHR) functionality
on behalf of the Tenant Domain, as described in [RFC7761]. This for group G on behalf of the Tenant Domain, as described in
means that the MEG DR must know the identity of the Rendezvous Point [RFC7761]. This means that the MEG SBD-DR must know the identity of
(RP) for each group, must send Register messages to the Rendezvous the Rendezvous Point (RP) for each group, must send Register messages
Point, etc. to the Rendezvous Point, etc.
If the MEG DR is to be the FHR for the Tenant Domain, it must see all If the MEG SBD-DR is to be the FHR for the Tenant Domain, it must see
the multicast traffic that is sourced from within the domain and all the multicast traffic that is sourced from within the domain and
destined to an ASM group address. The MEG can ensure this by destined to an ASM group address. The MEG can ensure this by
originating an SBD-SMET route for (*,*). As an optimization, an originating an SBD-SMET route for (*,*).
SBD-SMET route for (*, "any ASM group"), or even (*, "any ASM group
that might have MVPN sources") can be defined. (As a possible optimization, an SBD-SMET route for (*, "any ASM
group"), or even (*, "any ASM group that might have MVPN sources")
may be defined in a future revision of this draft.)
In some deployment scenarios, it may be preferred that the MEG that In some deployment scenarios, it may be preferred that the MEG that
receives the (S,G) traffic over an AC be the one provides the FHR receives the (S,G) traffic over an AC be the one provides the FHR
functionality. In that case, the MEG DR wold not need to provide the functionality. This behavior is OPTIONAL. If this option is used,
FHR functionality for (S,G) traffic that is attached to another MEG. it MUST be ensured that the MEG DR does not provide the FHR
functionality for (S,G) traffic that is attached to another MEG; FHR
functionality for (S,G) traffic from a particular source S MUST be
provided by only a single router.
Other deployment scenarios are also possible. For example, one might Other deployment scenarios are also possible. For example, one might
want to configure the MEGs to themselves be RPs. In this case, the want to configure the MEGs to themselves be RPs. In this case, the
RPs would have to exchange with each other information about which RPs would have to exchange with each other information about which
sources are active. The method exchanging such information is sources are active. The method exchanging such information is
outside the scope of this document. outside the scope of this document.
6.1.2.2.3. Source on Multihomed Segment 6.1.2.2.3. Source on Multihomed Segment
Suppose S is attached to a segment that is all-active multi-homed to Suppose S is attached to a segment that is all-active multi-homed to
skipping to change at page 55, line 43 skipping to change at page 59, line 43
(as discussed in Section 6.1.2.2.) (as discussed in Section 6.1.2.2.)
The obvious disadvantage of this method is that it requires every The obvious disadvantage of this method is that it requires every
EVPN PE to be a MEG. EVPN PE to be a MEG.
The procedures specified in this document allow an operator to add The procedures specified in this document allow an operator to add
MEG functionality to any subset of his EVPN OISM PEs. This allows an MEG functionality to any subset of his EVPN OISM PEs. This allows an
operator to make whatever trade-offs he deems appropriate between operator to make whatever trade-offs he deems appropriate between
optimal routing and MEG deployment. optimal routing and MEG deployment.
6.1.2.4. DR Selection 6.1.2.4. Selecting the MEG SBD-DR
Each MEG MUST be configured with an "MEG dummy ethernet segment" that Every PE that is eligible for selection as the MEG SBD-DR originates
has no ACs. an SBD-IMET route. As stated in Section 5, these SBD-IMET routes
carry a Multicast Flags EC with the MEG Flag set.
EVPN supports a number of procedures that can be used to select the These SBD-IMET routes SHOULD also carry a DF Election EC. The DF
Designated Forwarder (DF) for a particular BD on a particular Election EC and its use is specified in ([DF-Election-Framework]).
ethernet segment. Some of the possible procedures can be found, When the route is originated, the AC-DF bit in the DF Election EC
e.g., in [RFC7432], [EVPN-DF-NEW], and [EVPN-DF-WEIGHTED]. Whatever SHOULD be set to zero. This bit is not used when selecting a MEG
procedure is in use in a given deployment can be adapted to select a SBD-DR, i.e., it MUST be ignored by the receiver of an SBD-IMET
MEG DR for a given BD, as follows. route.
Each MEG will originate an Ethernet Segment route for the MEG dummy In the context of a given Tenant Domain, to select the MEG SBD-DR,
ethernet segment. It MUST carry a Route Target derived from the the MEGs of the Tenant Domain perform the following procedure:
corresponding Ethernet Segment Identifier. Thus only MEGs will
import the route.
Once the set of MEGs is known, it is also possible to determine the o From the set of received SBD-IMET routes for the given tenant
set of BDs supported by each MEG. The DF selection procedure can domain, determine he candidate set of PEs that support MEG
then be used to choose a MEG DR for the SBD. (The conditions under functionality for that domain.
which the MEG DR changes depends upon the DF selection algorithm that
is in use.)
These procedures can also be used to select a DR for each BD. o Select a DF Election algorithm as specified in
[DF-Election-Framework]. Some of the possible algorithms can be
found, e.g., in [RFC7432], [DF-Election-Framework], and
[EVPN-DF-WEIGHTED].
o Apply the DF Election Algorithm (see [DF-Election-Framework]) to
the candidate set of PEs. The "winner" becomes the MEG SBD-DR.
Note that if a given PE supports IPMG (Section 6.1.2) or PEG
(Section 6.1.4) functionality as well as MEG functionality, its
SBD-IMET routes carry only one DF Election EC.
6.1.3. Interworking with 'Global Table Multicast' 6.1.3. Interworking with 'Global Table Multicast'
If multicast service to the outside sources and/or receivers is If multicast service to the outside sources and/or receivers is
provided via the BGP-based "Global Table Multicast" (GTM) procedures provided via the BGP-based "Global Table Multicast" (GTM) procedures
of [RFC7716], the procedures of Section 6.1.2 can easily be adapted of [RFC7716], the procedures of Section 6.1.2 can easily be adapted
for EVPN/GTM interworking. The way to adapt the MVPN procedures to for EVPN/GTM interworking. The way to adapt the MVPN procedures to
GTM is explained in [RFC7716]. GTM is explained in [RFC7716].
6.1.4. Interworking with PIM 6.1.4. Interworking with PIM
skipping to change at page 57, line 6 skipping to change at page 61, line 13
layer 3 multicast routing is done via PIM rather than via BGP. layer 3 multicast routing is done via PIM rather than via BGP.
If external sources or receivers for a given group are attached to a If external sources or receivers for a given group are attached to a
PEG via a layer 3 interface, that interface should be treated as a PEG via a layer 3 interface, that interface should be treated as a
VRF interface attached to the Tenant Domain's L3VPN VRF. The layer 3 VRF interface attached to the Tenant Domain's L3VPN VRF. The layer 3
multicast routing instance for that Tenant Domain will either run PIM multicast routing instance for that Tenant Domain will either run PIM
on the VRF interface or will listen for IGMP/MLD messages on that on the VRF interface or will listen for IGMP/MLD messages on that
interface. If the external receiver is attached elsewhere on an IP interface. If the external receiver is attached elsewhere on an IP
network, the PE has to enable PIM on its interfaces to the backbone network, the PE has to enable PIM on its interfaces to the backbone
network. In both cases, the PE needs to perform PEG functionality, network. In both cases, the PE needs to perform PEG functionality,
and its IMET routes must carry a flag or EC identifying it as a PEG. and its IMET routes must carry the Muliticast Flags EC with the PEG
flag set.
For each BD on which there is a multicast source or receiver, one of For each BD on which there is a multicast source or receiver, one of
the PEGs will becomes the PEG DR. DR selection can be done using the the PEGs will becomes the PEG DR. DR selection can be done using the
same procedures specified in Section 6.1.2.4. same procedures specified in Section 6.1.2.4, except with "PEG"
substituted for "MEG".
As long as there are no tenant multicast routers within the EVPN As long as there are no tenant multicast routers within the EVPN
Tenant Domain, the PEGs do not need to run PIM on their IRB Tenant Domain, the PEGs do not need to run PIM on their IRB
interfaces. interfaces.
6.1.4.1. Source Inside EVPN Domain 6.1.4.1. Source Inside EVPN Domain
If a PEG receives a PIM Join(S,G) from outside the EVPN tenant If a PEG receives a PIM Join(S,G) from outside the EVPN tenant
domain, it may find it necessary to create (S,G) state. The PE needs domain, it may find it necessary to create (S,G) state. The PE needs
to determine whether S is within the Tenant Domain. If S is not to determine whether S is within the Tenant Domain. If S is not
skipping to change at page 59, line 24 skipping to change at page 63, line 31
In this model: In this model:
o The EVPN Tenant Domain is treated as a stub network attached to o The EVPN Tenant Domain is treated as a stub network attached to
the external PIM routers. the external PIM routers.
o The external PIM routers follow normal PIM procedures, and provide o The external PIM routers follow normal PIM procedures, and provide
the FHR and LHR functionality for the entire Tenant Domain. the FHR and LHR functionality for the entire Tenant Domain.
o The OISM PEs do not run PIM. o The OISM PEs do not run PIM.
o There MUST NOT be more than one gateway BD.
o If an OISM PE not attached to the gateway BD has interest in a o If an OISM PE not attached to the gateway BD has interest in a
given multicast flow, it conveys that interest to the OISM PEs given multicast flow, it conveys that interest, following normal
that are attached to the gateway BD. This is done by following OISM procedures, by originating an SBD-SMET route for that flow.
normal OISM procedures. As a result, IGMP/MLD messages will seen
by the external PIM routers on the gateway BD, and those external o If a PE attached to the gateway BD receives an SBD-SMET, it may
PIM routers will send PIM Join messages externally as required. need to generate and transmit a corresponding IGMP/MLD Join out
Traffic of the given multicast flow will then be received by one one or more of its ACs. (Procedures for generating an IGMP/MLD
of the external PIM routers, and that traffic will be forwarded by Join as a result of receiving an SMET route are given in
that router to the gateway BD. [IGMP-Proxy].) The PE MUST know which BD is the Gateway BD and
MUST NOT transmit an IGMP/MLD Join to any other BDs. Furthermore,
even if a particular AC is part of that BD, the PE SHOULD NOT
transmit an IGMP/MLD Join on that AC unless that an external PIM
route is attached via that AC.
As a result, IGMP/MLD messages will seen by the external PIM
routers on the gateway BD, and those external PIM routers will
send PIM Join messages externally as required. Traffic of the
given multicast flow will then be received by one of the external
PIM routers, and that traffic will be forwarded by that router to
the gateway BD.
The normal OISM procedures will then cause the given multicast The normal OISM procedures will then cause the given multicast
flow to be tunneled to any PEs of the EVPN Tenant Domain that have flow to be tunneled to any PEs of the EVPN Tenant Domain that have
interest in the flow. PEs attached to the gateway BD will see the interest in the flow. PEs attached to the gateway BD will see the
flow as originating from the gateway BD, other PEs will see the flow as originating from the gateway BD, other PEs will see the
flow as originating from the SBD. flow as originating from the SBD.
o An OISM PE attached to a gateway BD MUST set its layer 2 multicast o An OISM PE attached to a gateway BD MUST set its layer 2 multicast
state to indicate that each AC to the gateway BD has interest in state to indicate that each AC to the gateway BD has interest in
all multicast flows. It MUST also originate an SMET route for all multicast flows. It MUST also originate an SMET route for
(*,*). The procedures for originating SMET routes are discussed (*,*). The procedures for originating SMET routes are discussed
in Section 2.5. in Section 2.5.
o This will cause the OISM PEs attached to the gateway BD to receive This will cause the OISM PEs attached to the gateway BD to receive
all the IP multicast traffic that is sourced within the EVPN all the IP multicast traffic that is sourced within the EVPN
tenant domain, and to transmit that traffic to the gateway BD, tenant domain, and to transmit that traffic to the gateway BD,
where the external PIM routers will see it. (Of course, if the where the external PIM routers will see it. This enables the
gateway BD has a multi-homed segment, only the PE that is the DF external PIM routers to perform FHR functions on behalf of the
for that segment will transmit the multicast traffic to the entire Tenant Domain. (Of course, if the gateway BD has a
segment.) multi-homed segment, only the PE that is the DF for that segment
will transmit the multicast traffic to the segment.)
7. Using an EVPN Tenant Domain as an Intermediate (Transit) Network for 7. Using an EVPN Tenant Domain as an Intermediate (Transit) Network for
Multicast traffic Multicast traffic
In this section, we consider the scenario where one or more BDs of an In this section, we consider the scenario where one or more BDs of an
EVPN Tenant Domain are being used to carry IP multicast traffic for EVPN Tenant Domain are being used to carry IP multicast traffic for
which the source and at least one receiver are not part the tenant which the source and at least one receiver are not part the tenant
domain. That is, one or more BDs of the Tenant Domain are domain. That is, one or more BDs of the Tenant Domain are
intermediate "links" of a larger multicast tree created by PIM. intermediate "links" of a larger multicast tree created by PIM.
We define a "tenant multicast router" as a multicast router, running We define a "tenant multicast router" as a multicast router, running
PIM, that is: PIM, that is:
attached to one or more BDs of the Tenant Domain, but 1. attached to one or more BDs of the Tenant Domain, but
is not an EVPN PE router. 2. is not an EVPN PE router.
In order an EVPN Tenant Domain to be used as a transit network for IP In order an EVPN Tenant Domain to be used as a transit network for IP
multicast, one or more of its BDs must have tenant multicast routers, multicast, one or more of its BDs must have tenant multicast routers,
and an OISM PE that attaching to such a BD MUST be provisioned to and an OISM PE that attaching to such a BD MUST be provisioned to
enable PIM on its IRB interface to that BD. (This is true even if enable PIM on its IRB interface to that BD. (This is true even if
none of the tenant routers is on a segment attached to the PE.) none of the tenant routers is on a segment attached to the PE.)
Further, all the OISM PEs (even ones not attached to a BD with tenant Further, all the OISM PEs (even ones not attached to a BD with tenant
multicast routers) MUST be provisioned to enable PIM on their SBD IRB multicast routers) MUST be provisioned to enable PIM on their SBD IRB
interfaces. interfaces.
skipping to change at page 61, line 23 skipping to change at page 65, line 46
attached to PE2. When C1 sends a PIM Join(X,G) to BD1, the Upstream attached to PE2. When C1 sends a PIM Join(X,G) to BD1, the Upstream
Neighbor field might be set to either PE1, PE2, or C2. C1 chooses Neighbor field might be set to either PE1, PE2, or C2. C1 chooses
the Upstream Neighbor based on its unicast routing. Typically, it the Upstream Neighbor based on its unicast routing. Typically, it
will choose as the Upstream Neighbor the PIM router on BD1 that is will choose as the Upstream Neighbor the PIM router on BD1 that is
"closest" (according to the unicast routing) to X. Note that this "closest" (according to the unicast routing) to X. Note that this
will not necessarily be PE1. PE1 may not even be visible to the will not necessarily be PE1. PE1 may not even be visible to the
unicast routing algorithm used by the tenant routers. Even if it is, unicast routing algorithm used by the tenant routers. Even if it is,
it is unlikely to be the PIM router that is closest to X. So we need it is unlikely to be the PIM router that is closest to X. So we need
to consider the following two cases: to consider the following two cases:
C1 sends a PIM Join(X,G) to BD1, with PE1 as the Upstream 1. C1 sends a PIM Join(X,G) to BD1, with PE1 as the Upstream
Neighbor. Neighbor.
PE1's PIM routing instance will see the Join arrive on the BD1 IRB PE1's PIM routing instance will see the Join arrive on the BD1
interface. If X is not within the Tenant Domain, PE1 handles the IRB interface. If X is not within the Tenant Domain, PE1
Join according to normal PIM procedures. This will generally handles the Join according to normal PIM procedures. This will
result in PE1 selecting an Upstream Neighbor and sending it a generally result in PE1 selecting an Upstream Neighbor and
Join(X,G). sending it a Join(X,G).
If X is within the Tenant Domain, but is attached to some other If X is within the Tenant Domain, but is attached to some other
PE, PE1 sends (if it hasn't already) an SBD-SMET route for (X,G). PE, PE1 sends (if it hasn't already) an SBD-SMET route for
The IIF of the layer 3 (X,G) state will be the SBD IRB interface, (X,G). The IIF of the layer 3 (X,G) state will be the SBD IRB
and the OIF list will include the IRB interface to BD1. interface, and the OIF list will include the IRB interface to
BD1.
The SBD-SMET route will pull the (X,G) traffic to PE1, and the The SBD-SMET route will pull the (X,G) traffic to PE1, and the
(X,G) state will result in the (X,G) traffic being forwarded to (X,G) state will result in the (X,G) traffic being forwarded to
C1. C1.
If X is within the Tenant Domain, but is attached to PE1 itself, If X is within the Tenant Domain, but is attached to PE1 itself,
no SBD-SMET route is sent. The IIF of the layer 3 (X,G) state no SBD-SMET route is sent. The IIF of the layer 3 (X,G) state
will be the IRB interface to X's BD, and the OIF list will include will be the IRB interface to X's BD, and the OIF list will
the IRB interface to BD1. include the IRB interface to BD1.
C1 sends a PIM Join(X,G) to BD1, with either PE2 or C2 as the 2. C1 sends a PIM Join(X,G) to BD1, with either PE2 or C2 as the
Upstream Neighbor. Upstream Neighbor.
PE1's PIM routing instance will see the Join arrive on the BD1 IRB PE1's PIM routing instance will see the Join arrive on the BD1
interface. If neither X nor Upstream Neighbor is within the IRB interface. If neither X nor Upstream Neighbor is within the
tenant domain, PE1 handles the Join according to normal PIM tenant domain, PE1 handles the Join according to normal PIM
procedures. This will NOT result in PE1 sending a Join(X,G). procedures. This will NOT result in PE1 sending a Join(X,G).
If either X or Upstream Neighbor is within the Tenant Domain, PE1 If either X or Upstream Neighbor is within the Tenant Domain,
sends (if it hasn't already) an SBD-SMET route for (X,G). The IIF PE1 sends (if it hasn't already) an SBD-SMET route for (X,G).
of the layer 3 (X,G) state will be the SBD IRB interface, and the The IIF of the layer 3 (X,G) state will be the SBD IRB
OIF list will include the IRB interface to BD1. interface, and the OIF list will include the IRB interface to
BD1.
The SBD-SMET route will pull the (X,G) traffic to PE1, and the The SBD-SMET route will pull the (X,G) traffic to PE1, and the
(X,G) state will result in the (X,G) traffic being forwarded to (X,G) state will result in the (X,G) traffic being forwarded to
C1. C1.
8. IANA Considerations 8. IANA Considerations
To be supplied. IANA is requested to assign new flags in the "Multicast Flags
Extended Community Flags" registry. These flags are:
o IPMG
o MEG
o PEG
9. Security Considerations 9. Security Considerations
This document uses protocols and procedures defined in the normative This document uses protocols and procedures defined in the normative
references, and inherits the security considerations of those references, and inherits the security considerations of those
references. references.
This document adds flags or Extended Communities (ECs) to a number of This document adds flags or Extended Communities (ECs) to a number of
BGP routes, in order to signal that particular nodes support the BGP routes, in order to signal that particular nodes support the
OISM, IPMG, MEG, and/or PEG functionalities that are defined in this OISM, IPMG, MEG, and/or PEG functionalities that are defined in this
skipping to change at page 62, line 44 skipping to change at page 67, line 29
10. Acknowledgements 10. Acknowledgements
The authors thank Vikram Nagarajan and Princy Elizabeth for their The authors thank Vikram Nagarajan and Princy Elizabeth for their
work on Section 6.2. The authors also benefited tremendously from work on Section 6.2. The authors also benefited tremendously from
discussions with Aldrin Isaac on EVPN multicast optimizations. discussions with Aldrin Isaac on EVPN multicast optimizations.
11. References 11. References
11.1. Normative References 11.1. Normative References
[DF-Election-Framework]
Rabadan, J., Mohanty, S., Sajassi, A., Drake, J., Nagaraj,
K., and S. Sathappan, "Framework for EVPN Designated
Forwarder Election Extensibility", internet-draft draft-
ietf-bess-evpn-df-election-framework-03.txt, May 2018.
[EVPN-AR] Rabadan, J., Ed., "Optimized Ingress Replication solution [EVPN-AR] Rabadan, J., Ed., "Optimized Ingress Replication solution
for EVPN", internet-draft ietf-bess-evpn-optimized-ir- for EVPN", internet-draft ietf-bess-evpn-optimized-ir-
02.txt, August 2017. 03.txt, Febryary 2018.
[EVPN-BUM] [EVPN-BUM]
Zhang, Z., Lin, W., Rabadan, J., and K. Patel, "Updates on Zhang, Z., Lin, W., Rabadan, J., and K. Patel, "Updates on
EVPN BUM Procedures", internet-draft ietf-bess-evpn-bum- EVPN BUM Procedures", internet-draft ietf-bess-evpn-bum-
procedure-updates-02.txt, September 2017. procedure-updates-03.txt, April 2018.
[EVPN-IRB] [EVPN-IRB]
Sajassi, A., Salam, S., Thoria, S., Drake, J., Rabadan, Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
J., and L. Yong, "Integrated Routing and Bridging in Rabadan, "Integrated Routing and Bridging in EVPN",
EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet- internet-draft draft-ietf-bess-evpn-inter-subnet-
forwarding-03.txt, February 2017. forwarding-04.txt, July 2018.
[EVPN_IP_Prefix] [EVPN_IP_Prefix]
Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
Sajassi, "IP Prefix Advertisement in EVPN", internet- Sajassi, "IP Prefix Advertisement in EVPN", internet-
draft ietf-bess-evpn-prefix-advertisement-09.txt, November draft ietf-bess-evpn-prefix-advertisement-11.txt, May
2017. 2018.
[IGMP-Proxy] [IGMP-Proxy]
Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J.,
and W. Lin, "IGMP and MLD Proxy for EVPN", internet-draft and W. Lin, "IGMP and MLD Proxy for EVPN", internet-draft
draft-ietf-bess-evpn-igmp-mld-proxy-00.txt, March 2017. draft-ietf-bess-evpn-igmp-mld-proxy-02.txt, June 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<https://www.rfc-editor.org/info/rfc2236>. <https://www.rfc-editor.org/info/rfc2236>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999, DOI 10.17487/RFC2710, October 1999,
<https://www.rfc-editor.org/info/rfc2710>. <https://www.rfc-editor.org/info/rfc2710>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012, RFC 6625, DOI 10.17487/RFC6625, May 2012,
<https://www.rfc-editor.org/info/rfc6625>. <https://www.rfc-editor.org/info/rfc6625>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <https://www.rfc-editor.org/info/rfc7153>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[EVPN-BIER] [EVPN-BIER]
Zhang, Z., Przygienda, A., Sajassi, A., and J. Rabadan, Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan,
"EVPN BUM Using BIER", internet-draft ietf-bier-evpn- "EVPN BUM Using BIER", internet-draft ietf-bier-evpn-
00.txt, August 2017. 01.txt, April 2018.
[EVPN-DF-NEW]
Mohanty, S., Patel, K., Sajassi, A., Drake, J., and T.
Przygienda, "A new Designated Forwarder Election for the
EVPN", internet-draft ietf-bess-evpn-df-election-03.txt,
October 2017.
[EVPN-DF-WEIGHTED] [EVPN-DF-WEIGHTED]
Rabadan, J., Sathappan, S., Przygienda, T., Lin, W., Rabadan, J., Sathappan, S., Przygienda, T., Lin, W.,
Drake, J., Sajassi, A., and S. Mohanty, "Preference-based Drake, J., Sajassi, A., and S. Mohanty, "Preference-based
EVPN DF Election", internet-draft ietf-bess-evpn-pref-df- EVPN DF Election", internet-draft ietf-bess-evpn-pref-df-
00.txt, June 2017. 01.txt, April 2018.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., [RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K.,
and D. Pacella, "Global Table Multicast with BGP Multicast and D. Pacella, "Global Table Multicast with BGP Multicast
VPN (BGP-MVPN) Procedures", RFC 7716, VPN (BGP-MVPN) Procedures", RFC 7716,
DOI 10.17487/RFC7716, December 2015, DOI 10.17487/RFC7716, December 2015,
<https://www.rfc-editor.org/info/rfc7716>. <https://www.rfc-editor.org/info/rfc7716>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
Appendix A. Integrated Routing and Bridging Appendix A. Integrated Routing and Bridging
This Appendix provides a short tutorial on the interaction of routing This Appendix provides a short tutorial on the interaction of routing
and bridging. First it shows the traditional model, where bridging and bridging. First it shows the traditional model, where bridging
and routing are performed in separate boxes. Then it shows the model and routing are performed in separate boxes. Then it shows the model
specified in [EVPN-IRB], where a single box contains both routing and specified in [EVPN-IRB], where a single box contains both routing and
bridging functions. The latter model is presupposed in the body of bridging functions. The latter model is presupposed in the body of
this document. this document.
Figure 1 shows a "traditional" router that only does routing and has Figure 1 shows a "traditional" router that only does routing and has
 End of changes. 172 change blocks. 
693 lines changed or deleted 934 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/