< draft-ietf-bess-evpn-irb-mcast-07.txt.orig   draft-ietf-bess-evpn-irb-mcast-07.txt >
skipping to change at page 1, line 32 skipping to change at page 1, line 32
site, and the segments are interconnected by an IP or MPLS backbone. site, and the segments are interconnected by an IP or MPLS backbone.
Intra-subnet traffic (either unicast or multicast) always appears to Intra-subnet traffic (either unicast or multicast) always appears to
the endusers to be bridged, even when it is actually carried over the the endusers to be bridged, even when it is actually carried over the
IP or MPLS backbone. When a single "tenant" owns multiple such LANs, IP or MPLS backbone. When a single "tenant" owns multiple such LANs,
EVPN also allows IP unicast traffic to be routed between those LANs. EVPN also allows IP unicast traffic to be routed between those LANs.
This document specifies new procedures that allow inter-subnet IP This document specifies new procedures that allow inter-subnet IP
multicast traffic to be routed among the LANs of a given tenant, multicast traffic to be routed among the LANs of a given tenant,
while still making intra-subnet IP multicast traffic appear to be while still making intra-subnet IP multicast traffic appear to be
bridged. These procedures can provide optimal routing of the inter- bridged. These procedures can provide optimal routing of the inter-
subnet multicast traffic, and do not require any such traffic to subnet multicast traffic, and do not require any such traffic to
leave a given router and then reenter that same router. These egress a given router and then ingress that same router. These
procedures also accommodate IP multicast traffic that needs to travel procedures also accommodate IP multicast traffic that originages
to or from systems that are outside the EVPN domain. or is destined external to 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/.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 67
11.2. Informative References . . . . . . . . . . . . . . . . . 69 11.2. Informative References . . . . . . . . . . . . . . . . . 69
Appendix A. Integrated Routing and Bridging . . . . . . . . . . 71 Appendix A. Integrated Routing and Bridging . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 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 an 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 [RFC9135]), we provide some essential In this section (as well as in [RFC9135]), we provide some essential
background information on EVPN. background information on EVPN.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 4, line 32 skipping to change at page 4, line 32
1.1.1. Segments, Broadcast Domains, and Tenants 1.1.1. Segments, Broadcast Domains, and Tenants
One of the key concepts of EVPN is the Broadcast Domain (BD). A BD One of the key concepts of EVPN is the Broadcast Domain (BD). A BD
is essentially an emulated ethernet. Each BD belongs to a single is essentially an emulated ethernet. Each BD belongs to a single
tenant. A BD typically consists of multiple ethernet "segments", and tenant. A BD typically consists of multiple ethernet "segments", and
each segment may be attached to a different EVPN Provider Edge each segment may be attached to a different EVPN Provider Edge
(EVPN-PE) router. EVPN-PE routers are often referred to as "Network (EVPN-PE) router. EVPN-PE routers are often referred to as "Network
Virtualization Endpoints" or NVEs. However, this document will use Virtualization Endpoints" or NVEs. However, this document will use
the term "EVPN-PE", or, when the context is clear, just "PE". the term "EVPN-PE", or, when the context is clear, just "PE".
In this document, we use the term "segment" to mean the same as In this document, the term "segment" is used interchangable with the
"Ethernet Segment" or "ES" in [RFC7432]. term "Ethernet Segment" or "ES" in [RFC7432].
Attached to each segment are "Tenant Systems" (TSes). A TS may be Attached to each segment are "Tenant Systems" (TSes). A TS may be
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. frames to TS2. TS2 will receive the frames unaltered.
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. the ethernet multicast destination MAC address.
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 (and consequently, no alteration of alteration of the frame's payload (and consequently, no alteration of
the payload's IP header) has been made. 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". Suppose a given segment is This is known as "EVPN multi-homing". Suppose a given segment is
attached to both PE1 and PE2, and suppose PE1 receives a frame from attached to both PE1 and PE2, and suppose PE1 receives a frame from
that segment. It may be necessary for PE1 to send the frame over the that segment. It may be necessary for PE1 to send the frame over the
skipping to change at page 6, line 48 skipping to change at page 6, line 48
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 [RFC9135] and [RFC9251]. (However, an EVPN-PE MUST also support [RFC9135] and [RFC9251]. (However,
certain of the procedures in [RFC9251] are modified when OISM is certain procedures in [RFC9251] are modified when OISM is
supported.) 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), an L3 routing instance has
one IRB interface per BD, NOT one per MAC-VRF. This document does one IRB interface per BD, NOT one per MAC-VRF. This document does
not distinguish between a "Broadcast Domain" and a "Bridge Table", not distinguish between a "Broadcast Domain" and a "Bridge Table",
and will use the terms interchangeably (or will use the acronym "BD" and will use the terms interchangeably (or will use the acronym "BD"
to refer to either). The way the BDs are grouped into MAC-VRFs is to refer to either). The way the BDs are grouped into MAC-VRFs is
not relevant to the procedures specified in this document. 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
skipping to change at page 8, line 34 skipping to change at page 8, line 34
the Tenant Multicast Router will make two copies of the packet, one the Tenant Multicast Router will make two copies of the packet, one
for BD2 and one for BD3. PE2 will send both copies back to PE1. Not for BD2 and one for BD3. PE2 will send both copies back to PE1. Not
only is the routing sub-optimal, but PE2 sends multiple copies of the only is the routing sub-optimal, but PE2 sends multiple copies of the
same packet to PE1. This is a further sub-optimality. same packet to PE1. This is a further sub-optimality.
This is only an example; many more examples of sub-optimal multicast This is only an example; many more examples of sub-optimal multicast
routing can easily be given. To eliminate sub-optimal routing and routing can easily be given. To eliminate sub-optimal routing and
extra copies, it is necessary to have a multicast solution that is extra copies, it is necessary to have a multicast solution that is
EVPN-aware, and that can use its knowledge of the internal structure EVPN-aware, and that can use its knowledge of the internal structure
of a Tenant Domain to ensure that multicast traffic gets routed of a Tenant Domain to ensure that multicast traffic gets routed
optimally. The procedures of this document allow us to avoid all optimally. The procedures in this document allow us to avoid all
such sub-optimalities when routing inter-subnet multicasts within a such sub-optimalities when routing inter-subnet multicast traffic within a
Tenant Domain. Tenant Domain.
1.3. Additional Requirements That Must be Met by the Solution 1.3. Additional Requirements That Must be Met by the Solution
In addition to providing optimal routing of multicast flows within a In addition to providing optimal routing of multicast flows within a
Tenant Domain, the EVPN-aware multicast solution is intended to Tenant Domain, the EVPN-aware multicast solution is intended to
satisfy the following requirements: satisfy the following requirements:
o The solution must integrate well with the procedures specified in o The solution must integrate well with the procedures specified in
[RFC9251]. That is, an integrated set of procedures must handle [RFC9251]. That is, an integrated set of procedures must handle
skipping to change at page 9, line 19 skipping to change at page 9, line 19
* If a source and a receiver are on the same subnet, no IP * If a source and a receiver are on the same subnet, no IP
processing of the ethernet payload is done. The IP TTL is not processing of the ethernet payload is done. The IP TTL is not
decremented, the header checksum is not changed, no decremented, the header checksum is not changed, no
fragmentation is done, etc. fragmentation is done, etc.
o On the other hand, if a source and a receiver are on different o On the other hand, if a source and a receiver are on different
subnets, the frame received by the receiver will not have the MAC subnets, the frame received by the receiver will not have the MAC
Source address of the source, as the frame will appear to have Source address of the source, as the frame will appear to have
come from a multicast router. Also, proper processing of the IP come from a multicast router. Also, proper processing of the IP
header is done, e.g., TTL decrement by 1, header checksum header is done, e.g., TTL decrement by 1, header checksum
modification, possibly fragmentation, etc. modification, possible fragmentation, etc.
o If a Tenant Domain contains several BDs, it MUST be possible for a o If a Tenant Domain contains several BDs, it MUST be possible for a
multicast flow (even when the multicast group address is an "any multicast flow (even when the multicast group address is an "any
source multicast" (ASM) address), to have sources in one of those source multicast" (ASM) address), to have sources in one of those
BDs and receivers in one or more of the other BDs, without BDs and receivers in one or more of the other BDs, without
requiring the presence of any system performing PIM Rendezvous requiring the presence of any system performing PIM Rendezvous
Point (RP) functions ([RFC7761]). Multicast throughout a Tenant Point (RP) functions [RFC7761]. Multicast throughout a Tenant
Domain must not require the tenant systems to be aware of any Domain must not require the tenant systems to be aware of any
underlying multicast infrastructure. underlying multicast infrastructure.
o Sometimes a MAC address used by one TS on a particular BD is also o Sometimes a MAC address used by one TS on a particular BD is also
used by another TS on a different BD. Inter-subnet routing of used by another TS on a different BD. Inter-subnet routing of
multicast traffic MUST NOT make any assumptions about the multicast traffic MUST NOT make any assumptions about the
uniqueness of a MAC address across several BDs. uniqueness of a MAC address across several BDs.
o If two EVPN-PEs attached to the same Tenant Domain both support o If two EVPN-PEs attached to the same Tenant Domain both support
the OISM procedures, each may receive inter-subnet multicasts from the OISM procedures, each may receive inter-subnet multicasts from
the other, even if the egress PE is not attached to any segment of the other, even if the egress PE is not attached to any segment of
the BD from which the multicast packets are being sourced. It the BD from which the multicast packets are being sourced. It
MUST NOT be necessary to provision the egress PE with knowledge of MUST NOT be necessary to provision the egress PE with knowledge of
the ingress BD. the ingress BD.
o There must be a procedure that that allows EVPN-PE routers o There must be a procedure that allows EVPN-PE routers
supporting OISM procedures to send/receive multicast traffic to/ supporting OISM procedures to send/receive multicast traffic to/
from EVPN-PE routers that support only [RFC7432], but that do not from EVPN-PE routers that support only [RFC7432], but that do not
support the OISM procedures or even the procedures of [RFC9135]. support the OISM procedures or even the procedures of [RFC9135].
However, when interworking with such routers (which we call However, when interworking with such routers (which we call
"non-OISM PE routers"), optimal routing may not be achievable. "non-OISM PE routers"), optimal routing may not be achievable.
o It MUST be possible to support scenarios in which multicast flows o It MUST be possible to support scenarios in which multicast flows
with sources inside a Tenant Domain have "external" receivers, with sources inside a Tenant Domain have "external" receivers,
i.e., receivers that are outside the domain. It must also be i.e., receivers that are outside the domain. It must also be
possible to support scenarios where multicast flows with external possible to support scenarios where multicast flows with external
sources (sources outside the Tenant Domain) have receivers inside sources (sources outside the Tenant Domain) have receivers inside
the domain. the domain.
This presupposes that unicast routes to multicast sources outside This presupposes that unicast routes to multicast sources outside
the domain can be distributed to EVPN-PEs attached to the domain, the domain can be distributed to EVPN-PEs attached to the domain,
and that unicast routes to multicast sources within the domain can and that unicast routes to multicast sources within the domain can
be distributed outside the domain. be distributed outside the domain.
Of particular importance are the scenario in which the external Of particular importance is the scenario in which the external
sources and/or receivers are reachable via L3VPN/MVPN, and the sources and/or receivers are reachable via L3VPN/MVPN, and the
scenario in which external sources and/or receivers are reachable scenario in which external sources and/or receivers are reachable
via IP/PIM. via IP/PIM.
The solution for external interworking MUST allow for deployment The solution for external interworking MUST allow for deployment
scenarios in which EVPN does not need to export a host route for scenarios in which EVPN does not need to export a host route for
every multicast source. every multicast source.
o The solution for external interworking must not presuppose that o The solution for external interworking must not presuppose that
the same tunneling technology is used within both the EVPN domain the same tunneling technology is used within both the EVPN domain
skipping to change at page 11, line 32 skipping to change at page 11, line 32
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 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. 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
skipping to change at page 12, line 8 skipping to change at page 12, line 8
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 o FHR (First Hop Router): The FHR is a PIM router [RFC7761] with
special responsibilities. It is the first multicast router to see special responsibilities. It is the first multicast router to see
(S,G) packets from source S, and if G is an "Any Source Multicast (S,G) packets from source S, and if G is an "Any Source Multicast
(ASM)" group, the FHR is responsible for sending PIM Register (ASM)" group, the FHR is responsible for sending PIM Register
messages to the PIM Rendezvous Point for group G. messages to the PIM Rendezvous Point for group G.
o LHR (Last Hop Router): The LHR is a PIM router ([RFC7761]) with o LHR (Last Hop Router): The LHR is a PIM router [RFC7761] with
special responsibilities. Generally it is attached to a LAN, and special responsibilities. Generally it is attached to a LAN, and
it determines whether there are any hosts on the LAN that need to 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 receive a given multicast flow. If so, it creates and sends the
PIM Join messages that are necessary to draw the flow. PIM Join messages that are necessary to receive the flow.
o EC (Extended Community). A BGP Extended Communities attribute o EC (Extended Community). A BGP Extended Communities attribute
([RFC4360], [RFC7153]) is a BGP path attribute that consists of ([RFC4360], [RFC7153]) is a BGP path attribute that consists of
one or more extended communities. one or more extended communities.
o RT (Route Target): A Route Target is a particular kind of BGP o RT (Route Target): A Route Target is a particular kind of BGP
Extended Community. A BGP Extended Community consists of a type Extended Community. A BGP Extended Community consists of a type
field, a sub-type field, and a value field. Certain type/sub-type field, a sub-type field, and a value field. Certain type/sub-type
combinations indicate that a particular Extended Community is an combinations indicate that a particular Extended Community is an
RT. RT1 and RT2 are considered to be the same RT if and only if RT. RT1 and RT2 are considered to be the same RT if and only if
skipping to change at page 13, line 28 skipping to change at page 13, line 28
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 route must Ethernet Tag (IMET) route for that BD, and that the IMET route must
be 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 [RFC9251]. In this case, we will say that: specified in [RFC9251]. In this case:
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 an AC that is interested in receiving Once PE1 determines that it has an AC that is interested in receiving
a particular flow or set of flows, it originates one or more a particular flow or set of flows, it originates one or more
Selective Multicast Ethernet Tag (SMET) route to advertise that Selective Multicast Ethernet Tag (SMET) route(s) to advertise that
interest. interest.
Note that each IMET or SMET route is "for" a particular BD. The Note that each IMET or SMET route is "for" a particular BD. The
notion of a route being "for" a particular BD is explained in notion of a route being "for" a particular BD is explained in
Section 2.2. Section 2.2.
When OISM is being supported, the procedures of [RFC9251], are When OISM is being supported, the procedures of [RFC9251], are
modified as follows: modified as follows:
o The IMET route originated by a particular PE for a particular BD o The IMET route originated by a particular PE for a particular BD
skipping to change at page 14, line 46 skipping to change at page 14, line 46
and at least one of PE2's IMET routes indicates that PE2 is an OISM and at least one of PE2's IMET routes indicates that PE2 is an OISM
PE, PE1 MUST 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 packets on those ACs.
There are two cases to consider: There are two cases to consider:
o Intra-Subnet Forwarding: In this case, an attachment AC with o Intra-Subnet Forwarding: In this case, an attachment AC with
interest in (S,G) is connected to a segment that is part of the interest in (S,G) is connected to a segment that is part of the
source BD, BD1. If the segment is not multi-homed, or if PE1 is source BD, BD1. If the segment is not multi-homed, or if PE1 is
the Designated Forwarder (DF) (see [RFC7432]) for that segment, the Designated Forwarder (DF) (see [RFC7432]) for that segment,
PE1 sends the multicast frame on that AC without changing the MAC PE1 sends the multicast frame on that AC without changing the MAC
SA. The IP header is not modified at all; in particular, the TTL SA. The IP header is not modified at all; in particular, the TTL
is not decremented. is not decremented.
skipping to change at page 15, line 36 skipping to change at page 15, line 36
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 apparent the frame to PE2 will cause PE2 to identify BD1 as the apparent
source BD. 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
apparent source BD. apparent source BD.
Note that the tunnel encapsulation used for a particular BD will have Note that the tunnel encapsulation used for a particular BD will have
been advertised in an IMET route or S-PMSI route been advertised in an IMET route or S-PMSI route
([I-D.ietf-bess-evpn-bum-procedure-updates]) for that BD. That route [I-D.ietf-bess-evpn-bum-procedure-updates] for that BD. That route
carries a PMSI Tunnel attribute, which specifies how packets carries a PMSI Tunnel attribute, which specifies how packets
originating from that BD are encapsulated. This information enables originating from that BD are encapsulated. This information enables
the PE receiving a tunneled packet to identify the apparent source BD the PE receiving a tunneled packet to identify the apparent source BD
as stated above. See Section 3.2 for more details. 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 apparent If PE2 determines from the tunnel encapsulation that the apparent
source BD is BD1, then source BD is BD1, then
skipping to change at page 17, line 8 skipping to change at page 17, line 8
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 packet to PE2. The tunnel encapsulation will identify the
apparent source BD as the SBD. Since the apparent source BD is apparent source BD as the SBD. Since the apparent source BD is
the SBD, PE2 will know to treat the frame as an inter-subnet the SBD, PE2 will know to treat the frame as an inter-subnet
multicast. 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 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 ([I-D.ietf-bier-evpn]) If a Point-to-Multipoint (P2MP) tree or BIER [I-D.ietf-bier-evpn]
is used to transmit an IP multicast frame from an ingress PE to a set is used to 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 of egress 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 frame to each of its next hops. Again, each egress PE receives the
original frame and does any necessary IP processing. original 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). For a given using the notion of "IRB interface" (see Appendix A). For a given
Tenant Domain: Tenant Domain:
o A given PE has one IRB for each BD to which it is attached. This o A given PE has one IRB interface for each BD to which it is attached. This
IRB interface connects L3 routing to that BD. When IP multicast IRB interface connects L3 routing to that BD. When IP multicast
packets are sent or received on the IRB interfaces, the semantics packets are sent or received on the IRB interfaces, the semantics
of the interface is modified from the semantics described in of the interface is modified from the semantics described in
Appendix A. See Section 2.3 for the details of the modification. 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 o Each PE also has an IRB interface that connects L3 routing to the
SBD. The semantics of this interface is different than the SBD. The semantics of this interface is different than the
semantics of the IRB interface to the real BDs. See Section 2.3. 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
skipping to change at page 18, line 7 skipping to change at page 18, line 7
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 with the SBD for that tenant the Tenant Domain must be provisioned with the SBD for that tenant
domain. A Route Target (RT) must be associated with the SBD, and domain. A Route Target (RT) must be associated with the SBD, and
provisioned on each of those PEs. We will refer to that RT as the provisioned on each of those PEs. We will refer to that RT as the
"SBD-RT". "SBD-RT".
A Tenant Domain is also configured with an IP-VRF ([RFC9135]), and A Tenant Domain is also configured with an IP-VRF [RFC9135], 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.
skipping to change at page 19, line 14 skipping to change at page 19, line 14
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 given route may be about the SBD, or about an "ordinary BD" (a BD A given route may be about the SBD, or about an "ordinary BD" (a BD
that is not the SBD). An RT that has been assigned to an ordinary BD that is not the SBD). An RT that has been assigned to an ordinary BD
will be known as an "ordinary BD-RT". will be known as an "ordinary BD-RT".
When constructing an IMET, SMET, S-PMSI or Leaf When constructing an IMET, SMET, S-PMSI, or Leaf
([I-D.ietf-bess-evpn-bum-procedure-updates]) route that is about a ([I-D.ietf-bess-evpn-bum-procedure-updates]) route that is about a
given BD, the following rules apply: given BD, the following rules apply:
o If the route is about an ordinary BD, say BD1, then o If the route is about an ordinary BD, say BD1, then
* the route MUST carry the ordinary BD-RT associated with BD1, * the route MUST carry the ordinary BD-RT associated with BD1,
and and
* the route MUST NOT carry any RT that is associated with an * the route MUST NOT carry any RT that is associated with an
ordinary BD other than BD1. ordinary BD other than BD1.
o If the route is about the SBD, the route MUST carry the SBD-RT, 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. and MUST NOT carry any RT that is associated with any other BD.
o As detailed in subsequent sections, under certain circumstances a 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 route that is about BD1 may carry both the RT of BD1 and also the
SBD-RT. SBD-RT.
The IMET route for the SBD MUST carry an Multicast Flags Extended The IMET route for the SBD MUST carry a Multicast Flags Extended
Community, in which an "OISM SBD" flag is set. Community, in which an "OISM SBD" flag is set.
The IMET route for a BD other than the SBD SHOULD carry an EVI-RT EC The IMET route for a BD other than the SBD SHOULD carry an EVI-RT EC
as defined in [RFC9251]. The EC is constructed from the SBD-RT, to as defined in [RFC9251]. The EC is constructed from the SBD-RT, to
indicate the BD's corresponding SBD. This allows all PEs to check indicate the BD's corresponding SBD. This allows all PEs to check
that they have consistent SBD provisioning and allow an AR-replicator that they have consistent SBD provisioning and allow an AR-replicator
to automatically determine a BD's corresponding SBD w/o any to automatically determine a BD's corresponding SBD without any
provisioning, as explained in Section 3.2.3.1. provisioning, as explained in Section 3.2.3.1.
When receiving an IMET, SMET, S-PMSI or Leaf route, it is necessary 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. 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 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 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 consider. Some of these cases are error cases that arise when the
route has not been properly constructed. route has not been properly constructed.
When one of the error cases is detected, the route MUST be regarded When one of the error cases is detected, the route MUST be regarded
as a malformed route, and the "treat-as-withdraw" procedure of as a malformed route, and the "treat-as-withdraw" procedure of
[RFC7606] MUST be applied. Note though that these error cases are [RFC7606] MUST be applied. Note that these error cases are
only detectable by EVPN procedures at the receiving PE; BGP only detectable by EVPN procedures at the receiving PE; BGP
procedures at intermediate nodes will generally not detect the procedures at intermediate nodes will generally not detect the
existence of such error cases, and in general SHOULD NOT attempt to existence of such error cases, and in general SHOULD NOT attempt to
do so. do so.
Case 1: The receiving PE recognizes more than one of the route's RTs 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 as being an SBD-RT (i.e., the route carries SBD-RTs of more
than one Tenant Domain). than one Tenant Domain).
This is an error case; the route has not been properly This is an error case; the route has not been properly
skipping to change at page 20, line 37 skipping to change at page 20, line 37
associated with the SBD of a different Tenant Domain. associated with the SBD of a different Tenant Domain.
This is an error case; the route has not been properly This is an error case; the route has not been properly
constructed. constructed.
Case 4: The receiving PE does not recognize any of the route's RTs 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 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 domains, but does recognize one of the RTs as the SBD-RT of
one of its Tenant Domains. one of its Tenant Domains.
In this case, receiving PE associates the route with the SBD In this case, the receiving PE associates the route with the SBD
of that Tenant Domain. This association is made even if the 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 Tag ID field of the route's NLRI is not the Tag ID of the
SBD. SBD.
This is a normal use case where either (a) the route is for 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 a BD to which the receiving PE is not attached, or (b) the
route is for the SBD. In either case, the receiving PE route is for the SBD. In either case, the receiving PE
associates the route with the SBD. associates the route with the SBD.
Case 5: The receiving PE recognizes exactly one of the RTs as an Case 5: The receiving PE recognizes exactly one of the RTs as an
skipping to change at page 22, line 5 skipping to change at page 22, line 5
P2MP tunnels.) At the egress PE, the apparent source BD of the P2MP tunnels.) At the egress PE, the apparent source BD of the
frame can be inferred from the tunnel encapsulation. If the frame can be inferred from the tunnel encapsulation. If the
egress PE is not attached to the actual source BD, it will infer egress PE is not attached to the actual source BD, it will infer
that the apparent source 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 on 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 TS, receivers for (S,G) traffic. (A "local receiver" is a TS,
skipping to change at page 25, line 21 skipping to change at page 25, line 21
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 advantage to having separate IP used, there is a significant advantage to having separate IP
multicast tunnels. multicast tunnels.
Other things being equal, it is desirable for an ingress PE to Other things being equal, it is desirable for an ingress PE to
transmit a copy of a given (S,G) multicast frame on only one P2MP transmit a copy of a given (S,G) multicast frame on only one P2MP
tunnel. All egress PEs interested in (S,G) packets then have to join tunnel. All egress PEs interested in (S,G) packets then have to join
that tunnel. If the source BD and PE for an (S,G) frame are BD1 an that tunnel. If the source BD and PE for an (S,G) frame are BD1 and
PE1 respectively, and if PE2 has receivers on BD2 for (S,G), then PE2 PE1 respectively, and if PE2 has receivers on BD2 for (S,G), then PE2
must join the P2MP LSP on which PE1 transmits the (S,G) frame. PE2 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 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 receive 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, it is RECOMMENDED that the default IP multicast tunnels be
distinct from the BUM tunnels. distinct from the BUM tunnels.
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 link-local traffic.
Note that it is also possible to use "selective tunnels" to carry 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 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 transmitted on a selective tunnel, it is not transmitted on the BUM
tunnel or on the default IP Multicast tunnel. 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:
skipping to change at page 26, line 14 skipping to change at page 26, line 14
have one or more gateway PEs that interface the tunnels discussed have one or more gateway PEs that interface the tunnels discussed
in this document with the BUM tunnels of the legacy PEs. This is in this document with the BUM tunnels of the legacy PEs. This is
discussed in Section 5. discussed in Section 5.
2. Sometimes multicast traffic originates from outside the EVPN 2. Sometimes multicast traffic originates from outside the EVPN
domain, or needs to be sent outside the EVPN domain. This is domain, or needs to be sent outside the EVPN domain. This is
discussed in Section 6. An important special case of this, discussed in Section 6. An important special case of this,
integration with MVPN, is discussed in Section 6.1.2. integration with MVPN, is discussed in Section 6.1.2.
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 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
As discussed in Section 2.1, every Tenant Domain is associated with a As discussed in Section 2.1, every Tenant Domain is associated with a
single Supplementary Broadcast Domain (SBD). Recall that a Tenant single Supplementary Broadcast Domain (SBD). Recall that a Tenant
Domain is defined to be a set of BDs that can freely send and receive Domain is defined to be a set of BDs that can freely send and receive
skipping to change at page 26, line 38 skipping to change at page 26, line 38
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
to the SBD. However, the SBD has no ACs. to the SBD. However, the SBD has no ACs.
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. That RT MUST NOT be the same as the RT associated with any other BD.
We will use the term "SBD-RT" to denote the RT has has been assigned We will use the term "SBD-RT" to denote that the RT has has been assigned
to the 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.
Section 2.2 specifies the rules by which an EVPN-PE that receives a Section 2.2 specifies the rules by which an EVPN-PE that receives a
route determines whether a received route "belongs to" a particular route determines whether a received route "belongs to" a particular
ordinary BD or SBD. ordinary BD or SBD.
Section 2.2 also specifies additional rules that must be following Section 2.2 also specifies additional rules that must be followed
when constructing routes that belong to a particular BD, including when constructing routes that belong to a particular BD, including
the SBD. the SBD.
The SBD SHOULD be in an EVPN Instance (EVI) of its own. Even if the The SBD SHOULD be in an EVPN Instance (EVI) of its own. Even if the
SBD is not in an EVI of its own, the SBD-RT MUST be different than SBD is not in an EVI of its own, the SBD-RT MUST be different than
the RT associated with any other BD. This restriction is necessary 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. 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
skipping to change at page 27, line 44 skipping to change at page 27, line 44
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 P2MP 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 ([I-D.ietf-bess-evpn-bum-procedure-updates]). S-PMSI A-D routes [I-D.ietf-bess-evpn-bum-procedure-updates].
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 ([I-D.ietf-bess-evpn-bum-procedure-updates]). S-PMSI A-D route [I-D.ietf-bess-evpn-bum-procedure-updates].
Details may be found in subsequent sections. Details may be found in subsequent sections.
3.2.1. Constructing Routes for the SBD 3.2.1. Constructing Routes for the SBD
There are situations in which an EVPN-PE needs to originate IMET, There are situations in which an EVPN-PE needs to originate IMET,
SMET, and/or SPMSI routes for the SBD. Throughout this document, we SMET, and/or SPMSI routes for the SBD. Throughout this document, we
will refer to such routes respectively as "SBD-IMET routes", will refer to such routes respectively as "SBD-IMET routes",
"SBD-SMET routes", and "SBD-SPMSI routes". Subsequent sections "SBD-SMET routes", and "SBD-SPMSI routes". Subsequent sections
detail the conditions under which these routes need to be originated. detail the conditions under which these routes need to be originated.
skipping to change at page 30, line 13 skipping to change at page 30, line 13
either the source BD or the SBD. either the source BD or the SBD.
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.3.1. Automatic SBD Matching 3.2.3.1. Automatic SBD Matching
Each PE needs to know a BD's corresponding SBD. Configuring that Each PE needs to know a BD's corresponding SBD. Configuring that
information in each BD is one way but it requires repetitive information in each BD is one way but it requires repetitive
configuration and consistency check (to make sure that all the BDs of configuration and consistency checking (to make sure that all the BDs of
the same tenant are configured with the same SBD). A better way is the same tenant are configured with the same SBD). A better way is
to configure the SBD info in the L3 routing instance so that all to configure the SBD info in the L3 routing instance so that all
related BDs will derive the SBD information. related BDs will derive the SBD information.
An AR-replicator also needs to know same information, though it does An AR-replicator also needs to know same information, though it does
not necessarily have an L3 routing instance. However from the EVI-RT not necessarily have an L3 routing instance. However from the EVI-RT
EC in a BD's IMET route, an AR-replicator can derive the EC in a BD's IMET route, an AR-replicator can derive the
corresponding SBD of that BD w/o any configuration. corresponding SBD of that BD without any configuration.
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, and a given EVPN-PE attached to that Tenant Domain is a Domain, and a given EVPN-PE attached to that Tenant Domain is a
possible ingress EVPN-PE for traffic originating outside that Tenant possible ingress EVPN-PE for traffic originating outside that Tenant
Domain, the given EVPN-PE MUST originate an SBD-IMET route, (see Domain, the given EVPN-PE MUST originate an SBD-IMET route, (see
Section 3.2.1). 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
skipping to change at page 30, line 44 skipping to change at page 30, line 44
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.
Suppose an ingress EVPN-PE, PE1, needs to use BIER to tunnel an IP Suppose an ingress EVPN-PE, PE1, needs to use BIER to tunnel an IP
multicast frame to a set of egress EVPN-PEs. And suppose the frame's multicast frame to a set of egress EVPN-PEs. And suppose the frame's
source BD is BD1. The frame is encapsulated as follows: source BD is BD1. The frame is encapsulated as follows:
o A four-octet MPLS label stack entry ([RFC3032]) is prepended to o A four-octet MPLS label stack entry [RFC3032] is prepended to
the frame. The Label field is set to the upstream-assigned label the frame. The Label field is set to the upstream-assigned label
that PE1 has assigned to BD1. that PE1 has assigned to BD1.
o The resulting MPLS packet is then encapsulated in a BIER o The resulting MPLS packet is then encapsulated in a BIER
encapsulation ([RFC8296], [I-D.ietf-bier-evpn]). The BIER encapsulation ([RFC8296], [I-D.ietf-bier-evpn]). The BIER
BitString is set to identify the egress EVPN-PEs. The BIER BitString is set to identify the egress EVPN-PEs. The BIER
"proto" field is set to the value for "MPLS packet with "proto" field is set to the value for "MPLS packet with
upstream-assigned label at top of stack". upstream-assigned label at top of stack".
Note: It is possible that the packet being tunneled from PE1 Note: It is possible that the packet being tunneled from PE1
skipping to change at page 34, line 48 skipping to change at page 34, line 48
3.3. Advertising SMET Routes 3.3. Advertising SMET Routes
[RFC9251] allows an egress EVPN-PE to express its interest in a [RFC9251] allows an egress EVPN-PE to express its interest in a
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 with 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 three cases to consider: There are three cases to consider:
o Case 1: 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 advertises its interest in a flow or In this case, an egress PE advertises its interest in a flow or
set of flows by originating an SMET route that belongs to the SBD. set of flows by originating an SMET route that belongs to the SBD.
We refer to this as an SBD-SMET route. The SBD-SMET route carries We refer to this as an SBD-SMET route. The SBD-SMET route carries
the SBD-RT, and has the Tag ID for the SBD in its NLRI. SMET the SBD-RT, and has the Tag ID for the SBD in its NLRI. SMET
routes for the individual BDs are not needed, because there is no routes for the individual BDs are not needed, because there is no
need for a PE that receives an SMET route to send a corresponding need for a PE that receives an SMET route to send a corresponding
IGMP Join message out any of its ACs. IGMP Join message on any of its ACs.
o Case 2: It is known that more than one BD of a Tenant Domain may o Case 2: It is known that more than one BD of a Tenant Domain may
contain a multicast router. contain a multicast router.
This is very like Case 1. An egress PE advertises its interest in This is very like Case 1. An egress PE advertises its interest in
a flow or set of flows by originating an SBD-SMET route. The a flow or set of flows by originating an SBD-SMET route. The
SBD-SMET route carries the SBD-RT, and has the Tag ID for the SBD SBD-SMET route carries the SBD-RT, and has the Tag ID for the SBD
in its NLRI. in its NLRI.
In this case, it is important to be sure that SMET routes for the In this case, it is important to be sure that SMET routes for the
individual BDs are not originated. Suppose, for example, that PE1 individual BDs are not originated. Suppose, for example, that PE1
had local receivers for a given flow on both BD1 and BD2, and that had local receivers for a given flow on both BD1 and BD2, and that
it originated SMET routes for both those BDs. Then PEs receiving it originated SMET routes for both those BDs. Then PEs receiving
those SMET routes might send IGMP Joins on both those BDs. This those SMET routes might send IGMP Joins on both those BDs. This
could cause externally sourced multicast traffic to enter the could cause externally sourced multicast traffic to enter the
Tenant Domain at both BDs, which could result in duplication of Tenant Domain at both BDs, which could result in duplication of
data. data.
N.B.: If it is possible that more than one BD contains a tenant Note that if it is possible that more than one BD contains a tenant
multicast router, then in order to receive multicast data multicast router, then in order to receive multicast data
originating from outside EVPN, the PEs MUST follow the procedures originating from outside EVPN, the PEs MUST follow the procedures
of Section 6. of Section 6.
o Case 3: It is known that only a single BD of a Tenant Domain o Case 3: It is known that only a single BD of a Tenant Domain
contains a multicast router. contains a multicast router.
Suppose that an egress PE is attached to a BD on which there might Suppose that an egress PE is attached to a BD on which there might
be a tenant multicast router. (The tenant router is not be a tenant multicast router. (The tenant router is not
necessarily on a segment that is attached to that PE.) And 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 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 are interested in a given multicast flow. In this case, in
ADDITION to the SMET route for the SBD, the egress PE MAY addition to the SMET route for the SBD, the egress PE MAY
originate an SMET route for that BD. This will enable the ingress 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 PE(s) to send IGMP/MLD messages on ACs for the BD, as specified in
[RFC9251]. As long as that is the only BD on which there is a [RFC9251]. As long as that is the only BD on which there is a
tenant multicast router, there is no possibility of duplication of tenant multicast router, there is no possibility of duplication of
data. data.
This document does not specify procedures for dynamically determining This document does not specify procedures for dynamically determining
which of the three cases applies to a given deployment; the PEs of a 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. given Tenant Domain MUST be provisioned to know which case applies.
As detailed in [RFC9251], an SMET route carries a Multicast Flags EC As detailed in [RFC9251], an SMET route carries a Multicast Flags EC
containing flags indicating whether it is to result in the containing flags indicating whether IGMP v1, v2, or v3 messages on
propagation of IGMP v1, v2, or v3 messages on the ACs of the BD to the ACs of the BD to which the SMET route belongs are propagated.
which the SMET route belongs. These flags SHOULD be set to zero in These flags SHOULD be set to zero in an SBD-SMET route.
an SBD-SMET route.
Note that a PE only needs to originate the set of SBD-SMET routes 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. that are needed to receive multicast 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 attract
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 attract 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 [RFC9251], importing an SMET route for a particular BD will cause Per [RFC9251], importing an SMET route for a particular BD will cause
IGMP/MLD state to be instantiated for the IRB interface to that BD. IGMP/MLD state to be instantiated for the IRB interface to that BD.
This applies as well when the BD is the SBD. This applies as well when the BD is the SBD.
However, traffic that originates in one of the actual BDs of a However, traffic that originates in one of the actual BDs of a
skipping to change at page 37, line 10 skipping to change at page 37, line 10
sources". For example, two different sources may share the same sources". For example, two different sources may share the same
anycast IP address, say S1, and each may transmit an (S1,G) multicast 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 flow. In such a scenario, the two (S1,G) flows are typically
identical. Ordinary PIM procedures will cause only one the flows to identical. Ordinary PIM procedures will cause only one the flows to
be delivered to each receiver that has expressed interest in either be delivered to each receiver that has expressed interest in either
(*,G) or (S1,G). However, the OISM procedures described in this (*,G) or (S1,G). However, the OISM procedures described in this
document will result in both of the (S1,G) flows being distributed in document will result in both of the (S1,G) flows being distributed in
the Tenant Domain, and duplicate delivery will result. Therefore, if the Tenant Domain, and duplicate delivery will result. Therefore, if
there are receivers for (*,G) in a given Tenant Domain, there MUST there are receivers for (*,G) in a given Tenant Domain, there MUST
NOT be anycast sources for G within that Tenant Domain. (This NOT be anycast sources for G within that Tenant Domain. (This
restriction can be lifted by defining additional procedures; however restriction could be lifted by defining additional procedures; however
that is outside the scope of this document.) 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
skipping to change at page 37, line 44 skipping to change at page 37, line 44
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.
Each layer 2 multicast state (S,G) or (*,G) contains a set "output Each layer 2 multicast state (S,G) or (*,G) contains a set of "output
interfaces" (OIF list). The disposition of an (S,G) multicast frame interfaces" (OIF list). The disposition of an (S,G) multicast frame
received by BD1's layer 2 multicast function is determined as received by BD1's layer 2 multicast function is determined as
follows: follows:
o The OIF list is taken from BD1's layer 2 (S,G) state, or if there o The OIF list is taken from BD1's layer 2 (S,G) state, or if there
is no such (S,G) state, then from BD1's (*,G) state. (If neither is no such (S,G) state, then from BD1's (*,G) state. (If neither
state exists, the OIF list is considered to be null.) state exists, the OIF list is considered to be null.)
o The rules of Section 4.1.2 are applied to the OIF list. This will o The rules of Section 4.1.2 are applied to the OIF list. This will
generally result in the frame being transmitted to some, but not generally result in the frame being transmitted to some, but not
all, elements of the OIF list. all, elements of the OIF list.
Note that there is no RPF check at layer 2. Note that there is no RPF check at layer 2.
4.1.1. Constructing the OIF List 4.1.1. Constructing the OIF List
In this document, we have extended the procedures of [RFC9251] so In this document, we have extended the procedures of [RFC9251] so
that IMET and SMET routes for a particular BD are distributed not that IMET and SMET routes for a particular BD are distributed not
just to PEs that attach to that BD, but to PEs that attach to any BD just to PEs that 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 in the Tenant Domain. In this way, each PE attached to a given
Tenant Domain learns, from each other PE attached to the same Tenant Tenant Domain learns, from other PEs attached to the same Tenant
Domain, the set of flows that are of interest to each of those other Domain, the set of flows that are of interest to each of those other
PEs. (If some PE attached to the Tenant Domain does not support PEs. (If some PE attached to the Tenant Domain does not support
[RFC9251], it will be assumed to be interested in all flows. Whether [RFC9251], it will be assumed to be interested in all flows. Whether
a particular remote PE supports [RFC9251] is determined by the a particular remote PE supports [RFC9251] is determined by the
presence of an Extended Community in its IMET route; this is presence of an Extended Community in its IMET route; this is
specified in [RFC9251].) If a set of remote PEs are interested in a specified in [RFC9251].) If a set of remote PEs are interested in a
particular flow, the tunnels used to reach those PEs are added to the particular flow, the tunnels used to reach those PEs are added to the
OIF list of the multicast states corresponding to that flow. OIF list of the multicast states corresponding to that flow.
An EVPN-PE may run IGMP/MLD procedures on each of its ACs, in order An EVPN-PE may run IGMP/MLD procedures on each of its ACs, in order
skipping to change at page 38, line 46 skipping to change at page 38, line 46
The OIF list for each multicast state must also contain the IRB The OIF list for each multicast state must also contain the IRB
interface for the BD to which the state belongs. interface for the BD to which the state belongs.
Implementors should note that the OIF list of a multicast state will Implementors should note that the OIF list of a multicast state will
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) on 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
apparent source BD (see Section 3.2 for information about determining apparent source BD (see Section 3.2 for information about determining
the apparent source BD of a frame received over a tunnel from another the apparent source BD of a frame received over a tunnel from another
PE). 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:
skipping to change at page 39, line 24 skipping to change at page 39, line 24
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 apparent source BD of the frame, finds say PE1. PE1 determines the apparent source BD of the frame, finds
the layer 2 (S,G) state for that BD (or the (*,G) state if there is the layer 2 (S,G) state for that BD (or the (*,G) state if there is
no (S,G) state), and takes the OIF list from that state. (Note that no (S,G) state), and uses the OIF list from that state. (Note that
if PE1 is not attached to the actual source BD, the apparent source if PE1 is not attached to the actual source BD, the apparent source
BD will be 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 apparent source BD to be BD1
(which may or may not be the SBD.) There are the following cases to (which may 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 on 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:
i. If (a) AR is being used, and (b) PE1 is an AR-LEAF, and i. If (a) AR is being used, and (b) PE1 is an AR-LEAF, and
(c) the OIF list is non-null, PE1 MUST send the frame (c) the OIF list is non-null, PE1 MUST send the frame
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
skipping to change at page 40, line 11 skipping to change at page 40, line 11
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 apparent source (See Section 3.2 for the rules to determine the apparent source
BD of a 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 apparent attached to the source BD, it will regard the SBD as the apparent
source BD.) source BD.)
a. The frame MUST be sent out all local ACs in the OIF list that a. The frame MUST be sent on 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 apparent b. The frame MUST be sent up the IRB interface of the apparent
source BD. (Note that this may be the SBD.) The frame MUST source BD. (Note that this may be the SBD.) The frame MUST
NOT be sent 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.
a. The frame MUST be sent out all local ACs in the OIF list that a. The frame MUST be sent on all local ACs in the OIF list that
are eligible (per Section 4.1.2.1 to receive the frame. are eligible, as per Section 4.1.2.1, to receive the frame.
b. The frame MUST NOT be sent to any other EVPN-PEs. b. The frame MUST NOT be sent to any other EVPN-PEs.
c. The frame MUST NOT be sent up any IRB interfaces. c. The frame MUST NOT be sent up any IRB interfaces.
4. The frame was received from the SBD IRB interface (i.e., has been 4. The frame was received from the SBD IRB interface (i.e., has been
transmitted by PE1's L3 routing instance down the SBD IRB transmitted by PE1's L3 routing instance down the SBD IRB
interface). interface).
a. The frame MUST be sent on all tunnels in the OIF list. This a. The frame MUST be sent on all tunnels in the OIF list. This
skipping to change at page 40, line 51 skipping to change at page 40, line 51
have interest in it. have interest in it.
b. The frame MUST NOT be sent on any local ACs. b. The frame MUST NOT be sent on any local ACs.
c. The frame MUST NOT be sent up any IRB interfaces. c. The frame MUST NOT be sent up any IRB interfaces.
4.2. Layer 3 Forwarding State 4.2. Layer 3 Forwarding State
If an EVPN-PE is performing IGMP/MLD procedures on the ACs of a given If an EVPN-PE is performing IGMP/MLD procedures on the ACs of a given
BD, it processes those messages at layer 2 to help form the layer 2 BD, it processes those messages at layer 2 to help form the layer 2
multicast state. If also sends those messages up that BD's IRB multicast state. It also sends those messages up that BD's IRB
interface to the L3 routing instance of a particular tenant domain. interface to the L3 routing instance of a particular tenant domain.
This causes layer 2 (C-S,C-G) or (C-*,C-G) L3 state to be created/ This causes layer 2 (C-S,C-G) or (C-*,C-G) L3 state to be created/
updated. updated.
A layer 3 multicast state has both an Input Interface (IIF) and an A flow's layer 3 multicast state has both an Input Interface (IIF) and an
OIF list. OIF list.
To set the IIF of an (C-S,C-G) state, the EVPN-PE must determine the To set the IIF of a (C-S,C-G) state, the EVPN-PE must determine the
source BD of C-S. This is done by looking up S in the local source BD of C-S. This is done by looking up S in the local
MAC-VRF(s) of the given Tenant Domain. MAC-VRF(s) of the given Tenant Domain.
If the source BD is present on the PE, the IIF is set to the IRB If the source BD is present on the PE, the IIF is set to the IRB
interface that attaches to that BD. Otherwise the IIF is set to the interface that attaches to that BD. Otherwise the IIF is set to the
SBD IRB interface. SBD IRB interface.
For (C-*,C-G) states, traffic can arrive from any BD, so the IIF For (C-*,C-G) states, traffic can arrive from any BD, so the IIF
needs to be set to a wildcard value meaning "any IRB interface". needs to be set to a wildcard value meaning "any IRB interface".
skipping to change at page 42, line 20 skipping to change at page 42, line 20
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
setting the "IPMG" flag in the Multicast Flags EC that it attaches to setting the "IPMG" flag in the Multicast Flags EC that it attaches to
its IMET routes. An IPMG SHOULD attach this EC with the IPMG flag its IMET routes. An IPMG SHOULD attach this EC, with the IPMG flag
set to all IMET routes it originates. However, if PE1 imports any set, to all IMET routes it originates. Furthermore, if PE1 imports any
IMET route from PE2 that has the EC present with the "IPMG" flag set, IMET route from PE2 that has the EC present with the "IPMG" flag set,
then the PE1 will assume 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
BD-S but have interest in (S,G). BD-S but have interest in (S,G).
Note that OISM PEs that do attach to BD-S will have received Note that OISM PEs that do attach to BD-S will have received
the frames on the BUM tunnel from the non-OISM PE-S. the frames on the BUM tunnel from the non-OISM PE-S.
* The IPMG-DF forwards them to non-OISM PEs that have interest in * The IPMG-DF forwards them to non-OISM PEs that have interest in
(S,G) on ACs that do not belong to BD-S. (S,G) on ACs that do not belong to BD-S.
Note that if a non-OISM PE has multiple BDs other than BD-S Note that if a non-OISM PE has multiple BDs (other than BD-S)
with interest in (S,G), it will receive one copy of the frame with interest in (S,G), it will receive one copy of the frame
for each such BD. This is necessary because the non-OISM PEs for each such BD. This is necessary because the non-OISM PEs
cannot move IP multicast traffic from one BD to another. cannot move IP multicast traffic from one BD to another.
o If the frames are from an OISM PE, the IPMG-DF forwards them to o If the frames are from an OISM PE, the IPMG-DF forwards them to
non-OISM PEs that have interest in (S,G) on ACs that do not belong non-OISM PEs that have interest in (S,G) on ACs that do not belong
to BD-S. to BD-S.
If a non-OISM PE has interest in (S,G) on an AC belonging to BD-S, If a non-OISM PE has interest in (S,G) on an AC belonging to BD-S,
it will have received a copy of the (S,G) frame, encapsulated for it will have received a copy of the (S,G) frame, encapsulated for
BD-S, from the OISM PE-S. (See Section 3.2.2.) If the non-OISM BD-S, from the OISM PE-S. (See Section 3.2.2.) If the non-OISM
PE has interest in (S,G) on one or more ACs belonging to PE has interest in (S,G) on one or more ACs belonging to
BD-R1,...,BD-Rk where the BD-Ri are distinct from BD-S, the BD-R1,...,BD-Rk where the BD-Ri are distinct from BD-S, the
IPMG-DF needs to send it a copy of the frame for BD-Ri. IPMG-DF needs to send it a copy of the frame for each BD-Ri.
If an IPMG receives a frame on a BD for which it is not the IPMG-DF, If an IPMG receives a frame on a BD for which it is not the IPMG-DF,
it just follows normal OISM procedures. it just follows normal OISM procedures.
This section specifies several sets of procedures: This section specifies several sets of procedures:
o the procedures that the IPMG-DF for a given BD needs to follow o the procedures that the IPMG-DF for a given BD needs to follow
when receiving, on that BD, an IP multicast frame from a non-OISM when receiving, on that BD, an IP multicast frame from a non-OISM
PE; PE;
skipping to change at page 44, line 14 skipping to change at page 44, line 14
5.1. IPMG Designated Forwarder 5.1. IPMG Designated Forwarder
Every PE that is eligible for selection as an IPMG-DF for a Every PE that is eligible for selection as an IPMG-DF for a
particular BD originates both an IMET route for that BD and an 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 SBD-IMET route. As stated in Section 5, these SBD-IMET routes carry
a Multicast Flags EC with the IPMG Flag set. a Multicast Flags EC with the IPMG Flag set.
These SBD-IMET routes SHOULD also carry a DF Election EC. The DF These SBD-IMET routes SHOULD also carry a DF Election EC. The DF
Election EC and its use is specified in ([RFC8584]). When the route Election EC and its use is specified in ([RFC8584]). When the route
is originated, the AC-DF bit in the DF Election EC SHOULD be set to is originated, the AC-DF bit in the DF Election EC SHOULD be not be
zero. This bit is not used when selecting an IPMSG-DF, i.e., it MUST set. This bit is not used when selecting an IPMSG-DF, i.e., it MUST
be ignored by the receiver of an SBD-IMET route. be ignored by the receiver of an SBD-IMET route.
In the context of a given Tenant Domain, to select the IPMG-DF for a In the context of a given Tenant Domain, to select the IPMG-DF for a
particular BD, say BD1, the IPMGs of the Tenant Domain perform the particular BD, say BD1, the IPMGs of the Tenant Domain perform the
following procedure: following procedure:
o From the set of received SBD-IMET routes for the given tenant o From the set of received SBD-IMET routes for the given tenant
domain, determine the candidate set of PEs that support IPMG domain, determine the candidate set of PEs that support IPMG
functionality for that domain. functionality for that domain.
skipping to change at page 47, line 38 skipping to change at page 47, line 38
o PE-S will send a copy of the frame to every OISM PE-R (including o PE-S will send a copy of the frame to every OISM PE-R (including
the IPMG) in the Tenant Domain that is attached to BD-S and has the IPMG) in the Tenant Domain that is attached to BD-S and has
interest in (S,G). The copy sent to a given PE-R carries the interest in (S,G). The copy sent to a given PE-R carries the
label that that the PE-R has assigned to BD-S in its (C-*,C-*) label that that the PE-R has assigned to BD-S in its (C-*,C-*)
S-PMSI A-D route. S-PMSI A-D route.
o PE-S will also transmit a copy of the (S,G) frame to every OISM o PE-S will also transmit a copy of the (S,G) frame to every OISM
PE-R that has interest in (S,G) but is not attached to BD-S. The PE-R that has interest in (S,G) but is not attached to BD-S. The
copy will contain the label that the PE-R has assigned to the SBD. copy will contain the label that the PE-R has assigned to the SBD.
(As in Section 5.2.1, an IPMG is assumed to have indicated (As specified in Section 5.2.1, an IPMG is assumed to have indicated
interest in all multicast flows.) interest in all multicast flows.)
o PE-S will also transmit a copy of the (S,G) frame to every o PE-S will also transmit a copy of the (S,G) frame to every
non-OISM PE-R that is attached to BD-S. It does this using the non-OISM PE-R that is attached to BD-S. It does this using the
label advertised by that PE-R in its IMET route for BD-S. label advertised by that PE-R in its IMET route for BD-S.
The PE-Rs follow their normal procedures. An OISM PE that receives The PE-Rs follow their normal procedures. An OISM PE that receives
the (S,G) frame on BD-S applies the OISM procedures to deliver the the (S,G) frame on BD-S applies the OISM procedures to deliver the
frame to its local ACs, as necessary. A non-OISM PE that receives frame to its local ACs, as necessary. A non-OISM PE that receives
the (S,G) frame on BD-S delivers the frame only to its local BD-S the (S,G) frame on BD-S delivers the frame only to its local BD-S
ACs, as necessary. ACs, as necessary.
Suppose that a non-OISM PE-R has interest in (S,G) on a BD, BD-R, Suppose that a non-OISM PE-R has interest in (S,G) on a BD, BD-R,
that is different than BD-S. If the non-OISM PE-R is attached to that is different than BD-S. If the non-OISM PE-R is attached to
BD-S, the OISM PE-S will send forward it the original (S,G) multicast BD-S, the OISM PE-S will send it the original (S,G) multicast
frame, but the non-OISM PE-R will not be able to send the frame to frame, but the non-OISM PE-R will not be able to send the frame to
ACs that are not in BD-S. If PE-R is not even attached to BD-S, the ACs that are not in BD-S. If PE-R is not even attached to BD-S, the
OISM PE-S will not send it a copy of the frame at all, because PE-R OISM PE-S will not send it a copy of the frame at all, because PE-R
is not attached to the SBD. In these cases, the IPMG needs to relay is not attached to the SBD. In these cases, the IPMG needs to relay
the (S,G) multicast traffic from OISM PE-S to non-OISM PE-R. the (S,G) multicast traffic from OISM PE-S to non-OISM PE-R.
When the IPMG-DF for BD-S receives an (S,G) frame from an OISM PE-S, When the IPMG-DF for BD-S receives an (S,G) frame from an OISM PE-S,
it has to forward it to every non-OISM PE-R that that has interest in it has to forward it to every non-OISM PE-R that that has interest in
(S,G) on a BD-R that is different than BD-S. The IPMG MUST (S,G) on a BD-R that is different than BD-S. The IPMG MUST
decapsulate the IP multicast packet, do the IP processing, re- decapsulate the IP multicast packet, do the IP processing, re-
encapsulate it for BD-R (changing the MAC SA to the IPMG's own MAC encapsulate it for BD-R (changing the MAC SA to the IPMG's own MAC
address on BD-R), and send a copy of the frame to PE-R. Note that a address for BD-R), and send a copy of the frame to PE-R. Note that a
given non-OISM PE-R will receive multiple copies of the frame, if it given non-OISM PE-R will receive multiple copies of the frame, if it
has multiple BDs on which there is interest in the frame. has multiple BDs on which there is interest in the frame.
5.3. P2MP Tunnels 5.3. P2MP Tunnels
When IR is used to distribute the multicast traffic among the When IR is used to distribute the multicast traffic among the
EVPN-PEs, the procedures of Section 5.2 ensure that there will be no EVPN-PEs, the procedures of Section 5.2 ensure that there will be no
duplicate delivery of multicast traffic. That is, no egress PE will duplicate delivery of multicast traffic. That is, no egress PE will
ever send a frame twice on any given AC. If P2MP tunnels are being ever send a frame twice on any given AC. If P2MP tunnels are being
used to distribute the multicast traffic, it is necessary have used to distribute the multicast traffic, it is necessary to have
additional procedures to prevent duplicate delivery. additional procedures to prevent duplicate delivery.
At the present time, it is not clear that there will be a use case in At the present time, it is not clear that there will be a use case in
which OISM nodes need to interwork with non-OISM nodes that use P2MP which OISM nodes need to interwork with non-OISM nodes that use P2MP
tunnels. If it is determined that there is such a use case, tunnels. If it is determined that there is such a use case,
procedures for it will be included in a future revision of this procedures for P2MP will be included in a future revision of this
document. document.
6. Traffic to/from Outside the EVPN Tenant Domain 6. Traffic to/from Outside the EVPN Tenant Domain
In this section, we discuss scenarios where a multicast source In this section, we discuss scenarios where a multicast source
outside a given EVPN Tenant Domain sends traffic to receivers inside outside a given EVPN Tenant Domain sends traffic to receivers inside
the domain (as well as, possibly, to receivers outside the domain). the domain (as well as, possibly, to receivers outside the domain).
This requires the OISM procedures to interwork with various layer 3 This requires the OISM procedures to interwork with various layer 3
multicast routing procedures. multicast routing procedures.
skipping to change at page 50, line 14 skipping to change at page 50, line 14
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
procedures running in a given L3 Gateway, an EVPN Tenant Domain is a procedures running in a given L3 Gateway, an EVPN Tenant Domain is a
set of IRB interfaces. set of IRB interfaces.
When interworking an EVPN Tenant Domain with an external domain, the When interworking an EVPN Tenant Domain with an external domain, the
L3 Gateway's layer 3 multicast states will not only have IRB L3 Gateway's multicast states will not only have IRB
interfaces as IIF and OIF list entries, but also other "interfaces" interfaces as IIF and OIF list entries, but also other "interfaces"
that lead outside the Tenant Domain. For example, when interworking that lead outside the Tenant Domain. For example, when interworking
with MVPN, the multicast states may have MVPN tunnels as well as IRB with MVPN, the multicast states may have MVPN tunnels as well as IRB
interfaces as IIF or OIF list members. When interworking with PIM, interfaces as IIF or OIF list members. When interworking with PIM,
the multicast states may have PIM-enabled non-IRB interfaces as IIF the multicast states may have PIM-enabled non-IRB interfaces as IIF
or OIF list members. or OIF list members.
As long as a Tenant Domain is not being used as an intermediate As long as a Tenant Domain is not being used as an intermediate
transit network for IP multicast traffic, it is not necessary to transit network for IP multicast traffic, it is not necessary to
enable PIM on its IRB interfaces. enable PIM on its IRB interfaces.
In general, an L3 Gateway has the following responsibilities: In general, an L3 Gateway has the following responsibilities:
o It exports, to the external domain, unicast routes to those o It exports, to the external domain, unicast routes to those
multicast sources in the EVPN Tenant Domain that are locally multicast sources in the EVPN Tenant Domain that are locally
attached to the L3 Gateway. attached to the 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 receive 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 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 receive externally sourced
multicast traffic that is of interest to receivers in the EVPN multicast traffic that is of interest to receivers in the EVPN
Tenant Domain that are not locally attached to an L3 gateway. Tenant Domain that are not locally attached to an L3 gateway.
When such traffic is received, the traffic is sent down the SBD When such traffic is received, the traffic is sent down the SBD
IRB interface. OISM procedures already described in this document IRB interface. OISM procedures already described in this document
will then ensure that the IP multicast traffic gets distributed will then ensure that the IP multicast traffic gets distributed
throughout the Tenant Domain to any EVPN PEs that have interest in throughout the Tenant Domain to any EVPN PEs that have interest in
it. Thus to an OISM PE that is not an L3 gateway the externally it. Thus to an OISM PE that is not an L3 gateway the externally
sourced traffic will appear to have been sourced on the SBD. sourced traffic will appear to have been sourced on the SBD.
In order for this to work, some special care is needed when an L3 In order for this to work, some special care is needed when an L3
gateway creates or modifies a layer 3 (*,G) multicast state. Suppose gateway creates or modifies a layer 3 (*,G) multicast state. Suppose
group G has both external sources (sources outside the EVPN Tenant group G has both external sources (sources outside the EVPN Tenant
Domain) and internal sources (sources inside the EVPN tenant domain). Domain) and internal sources (sources inside the EVPN tenant domain).
Section 4.2 states that when there are internal sources, the SBD IRB Section 4.2 states that when there are internal sources, the SBD IRB
interface must not be added to the OIF list of the (*,G) state. interface must not be added to the OIF list of the (*,G) state.
Traffic from internal sources will already have been delivered to all Traffic from internal sources will already have been delivered to all
the EVPN PEs that have interest in it. However, if the OIF list of the EVPN PEs that have interest in it. However, if the OIF list of
the (*,G) state does not contain its SBD IRB interface, then traffic the (*,G) state does not contain its SBD IRB interface, then traffic
from external sources will not get delivered to other EVPN PEs. from external sources will not get delivered to other EVPN PEs.
One way of handling this is the following. When a L3 gateway One way of handling this is the following. When an L3 gateway
receives (S,G) traffic from other than an IRB interface, and the receives (S,G) traffic from other than an IRB interface, and the
traffic corresponds to a layer 3 (*,G) state, the L3 gateway can traffic corresponds to a layer 3 (*,G) state, the L3 gateway can
create (S,G) state. The IIF will be set to the external interface create (S,G) state. The IIF will be set to the external interface
over which the traffic is expected. The OIF list will contain the over which the traffic is expected. The OIF list will contain the
SBD IRB interface, as well as the IRB interfaces of any other BDs SBD IRB interface, as well as the IRB interfaces of any other BDs
attached to the PEG DR that have locally attached receivers with attached to the PEG DR that have locally attached receivers with
interest in the (S,G) traffic. The (S,G) state will ensure that the interest in the (S,G) traffic. The (S,G) state will ensure that the
external traffic is sent down the SBD IRB interface. The following external traffic is sent down the SBD IRB interface. The following
text will assume this procedure; however other implementation text will assume this procedure; however other implementation
techniques may also be possible. techniques may also be possible.
If a particular BD is attached to several L3 Gateways, one of the L3 If a particular BD is attached to several L3 Gateways, one of the L3
Gateways becomes the DR for that BD. (See Section 6.1.2.4.) If the Gateways becomes the DR for that BD. (See Section 6.1.2.4.) If the
interworking scenario requires FHR functionality, it is generally the interworking scenario requires FHR functionality, it is generally the
DR for a particular BD that is responsible for performing that DR for a particular BD that is responsible for performing that
functionality on behalf of the source hosts on that BD. (E.g., if functionality on behalf of the source hosts on that BD. (E.g., if
the interworking scenario requires that PIM Register messages be sent the interworking scenario requires that PIM Register messages be sent
by a FHR, the DR for a given BD would send the PIM Register messages by an 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 N.B.: If it is possible that more than one BD contains a tenant
skipping to change at page 52, line 45 skipping to change at page 52, line 45
In this section, we assume that there are no tenant multicast routers In this section, we assume that there are no tenant multicast routers
on any of the EVPN-attached ethernet segments. (There may of course on any of the EVPN-attached ethernet segments. (There may of course
be multicast routers in the L3VPN.) Consideration of the case where be multicast routers in the L3VPN.) Consideration of the case where
there are tenant multicast routers is deferred till Section 7.) there are tenant multicast routers is deferred till Section 7.)
To support MVPN/EVPN interworking, we introduce the notion of an To support MVPN/EVPN interworking, we introduce the notion of an
MVPN/EVPN Gateway, or MEG. MVPN/EVPN Gateway, or MEG.
A MEG is an L3 Gateway (see Section 6.1.1), hence is both an OISM PE A MEG is an L3 Gateway (see Section 6.1.1), hence is both an OISM PE
and an L3VPN/MVPN PE. For a given EVPN Tenant Domain it will have an and an L3VPN/MVPN PE. For a given EVPN Tenant Domain, it will have an
IP-VRF. If the Tenant Domain is part of an L3VPN/MVPN, the IP-VRF IP-VRF. If the Tenant Domain is part of an L3VPN/MVPN, the IP-VRF
also serves as an L3VPN VRF ([RFC4364]). The IRB interfaces of the also serves as an L3VPN VRF ([RFC4364]). The IRB interfaces of the
IP-VRF are considered to be "VRF interfaces" of the L3VPN VRF. The IP-VRF are considered to be "VRF interfaces" of the L3VPN VRF. The
L3VPN VRF may also have other local VRF interfaces that are not EVPN L3VPN VRF may also have other local VRF interfaces that are not EVPN
IRB interfaces. IRB interfaces.
The VRF on the MEG will import VPN-IP routes ([RFC4364]) from other The VRF on the MEG will import VPN-IP routes ([RFC4364]) from other
L3VPN Provider Edge (PE) routers. It will also export VPN-IP routes L3VPN Provider Edge (PE) routers. It will also export VPN-IP routes
to other L3VPN PE routers. In order to do so, it must be to other L3VPN PE routers. In order to do so, it must be
appropriately configured with the Route Targets used in the L3VPN to appropriately configured with the Route Targets used in the L3VPN to
skipping to change at page 54, line 12 skipping to change at page 54, line 12
of VPN-IP routes, and with the generation of MVPN C-multicast routes of VPN-IP routes, and with the generation of MVPN C-multicast routes
triggered by the installation of SMET routes. triggered by the installation of SMET routes.
6.1.2.1. MVPN Sources with EVPN Receivers 6.1.2.1. MVPN Sources with EVPN Receivers
6.1.2.1.1. Identifying MVPN Sources 6.1.2.1.1. Identifying MVPN Sources
Consider a multicast source S. It is possible that a MEG will import Consider a multicast source S. It is possible that a MEG will import
both an EVPN unicast route to S and a VPN-IP route (or an ordinary IP both an EVPN unicast route to S and a VPN-IP route (or an ordinary IP
route), where the prefix length of each route is the same. In order route), where the prefix length of each route is the same. In order
to draw (S,G) multicast traffic for any group G, the MEG SHOULD use to receive (S,G) multicast traffic for any group G, the MEG SHOULD use
the EVPN route rather than the VPN-IP or IP route to determine the the EVPN route rather than the VPN-IP or IP route to determine the
"Upstream PE" (see section 5 of [RFC6513]). "Upstream PE" (see section 5 of [RFC6513]).
Doing so ensures that when an EVPN tenant system desires to receive a Doing so ensures that when an EVPN tenant system desires to receive a
multicast flow from another EVPN tenant system, the traffic from the multicast flow from another EVPN tenant system, the traffic from the
source to that receiver stays within the EVPN domain. This prevents source to that receiver stays within the EVPN domain. This prevents
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
Consider a tenant system, R, on a particular BD, BD-R. Suppose R Consider a tenant system, R, on a particular BD, BD-R. Suppose R
wants to receive (S,G) multicast traffic, where source S is not wants to receive (S,G) multicast traffic, where source S is not
attached to any PE in the EVPN Tenant Domain, but is attached to an attached to any PE in the EVPN Tenant Domain, but is attached to an
MVPN PE. MVPN PE.l
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 matching on 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
MVPN procedures. MVPN procedures.
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 BD-R is added to the OIF list. tunnel, and the IRB interface to BD-R is added to the OIF list.
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 on 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 SBD- (S,G). PE1 follows normal OISM procedures, originating an SBD-
SMET route for (S,G); this route will be received by all the MEGs SMET route for (S,G); this route will be received by all the MEGs
of the Tenant Domain, including the MEG SBD-DR. The MEG SBD-DR of the Tenant Domain, including the MEG SBD-DR. The MEG SBD-DR
can determine from PE1's IMET routes whether PE1 is itself a MEG. can determine from PE1's IMET routes whether PE1 is itself a MEG.
If PE1 is not a MEG, the MEG SBD-DR will originate (if it hasn't If PE1 is not a MEG, the MEG SBD-DR will originate (if it hasn't
already) an MVPN C-multicast Source Tree Join(S,G) route. This already) an MVPN C-multicast Source Tree Join(S,G) route. This
skipping to change at page 55, line 47 skipping to change at page 55, line 47
its local ACs to BD-R is interested in (S,G) traffic. The DF is its local ACs to BD-R is interested in (S,G) traffic. The DF is
responsible for originating an SBD-SMET route for (S,G), following responsible for originating an SBD-SMET route for (S,G), following
normal OISM procedures. If the DF is a MEG, it MUST originate the normal OISM procedures. If the DF is a MEG, it MUST originate the
corresponding MVPN C-multicast Source Tree Join(S,G) route; if the corresponding MVPN C-multicast Source Tree Join(S,G) route; if the
DF is not a MEG, the MEG SBD-DR SBD MUST originate the C-multicast DF is not a MEG, the MEG SBD-DR SBD MUST originate the C-multicast
route when it receives the SMET route. route when it receives the SMET route.
Optionally, if the non-DF is a MEG, it MAY originate the Optionally, if the non-DF is a MEG, it MAY originate the
corresponding MVPN C-multicast Source Tree Join(S,G) route. This 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 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 only the DF will forward the traffic on an AC. This allows for
quicker recovery if the DF's local AC to R fails. 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
skipping to change at page 58, line 28 skipping to change at page 58, line 28
If the MEG SBD-DR is to be the FHR for the Tenant Domain, it must see If the MEG SBD-DR is to be the FHR for the Tenant Domain, it must see
all 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 (*,*). originating an SBD-SMET route for (*,*).
(As a possible optimization, an SBD-SMET route for (*, "any ASM (As a possible optimization, an SBD-SMET route for (*, "any ASM
group") may be defined in a future revision of this draft.) group") 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 providing the FHR
functionality. This behavior is OPTIONAL. If this option is used, functionality. This behavior is OPTIONAL. If this option is used,
it MUST be ensured that the MEG DR does not provide the FHR 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 that is attached to another MEG; FHR
functionality for (S,G) traffic from a particular source S MUST be functionality for (S,G) traffic from a particular source S MUST be
provided by only a single router. 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 themselves to 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
PEl and PE2. If S is transmitting to two groups, say G1 and G2, it PEl and PE2. If S is transmitting to two groups, say G1 and G2, it
is possible that PE1 will receive the (S,G1) traffic from S while PE2 is possible that PE1 will receive the (S,G1) traffic from S while PE2
receives the (S,G2) traffic from S. receives the (S,G2) traffic from S.
skipping to change at page 59, line 12 skipping to change at page 59, line 12
(S,G1) traffic while selecting PE2 as the ingress PE for (S,G2) (S,G1) traffic while selecting PE2 as the ingress PE for (S,G2)
traffic. traffic.
However, the following procedure ensures that the IP multicast However, the following procedure ensures that the IP multicast
traffic will still flow, even if the L3VPN/MVPN nodes picks the traffic will still flow, even if the L3VPN/MVPN nodes picks the
"wrong" EVPN-PE as the Upstream PE for (say) the (S,G1) traffic. "wrong" EVPN-PE as the Upstream PE for (say) the (S,G1) traffic.
Suppose S is on an ethernet segment, belonging to BD1, that is Suppose S is on an ethernet segment, belonging to BD1, that is
multi-homed to both PE1 and PE2, where PE1 is a MEG. And suppose multi-homed to both PE1 and PE2, where PE1 is a MEG. And suppose
that IP multicast traffic from S to G travels over the AC that that IP multicast traffic from S to G travels over the AC that
attaches the segment to PE2 . If PE1 receives a C-multicast Source attaches the segment to PE2. If PE1 receives a C-multicast Source
Tree Join (S,G) route, it MUST originate an SMET route for (S,G). Tree Join (S,G) route, it MUST originate an SMET route for (S,G).
Normal OISM procedures will then cause PE2 to send the (S,G) traffic Normal OISM procedures will then cause PE2 to send the (S,G) traffic
to PE1 on an EVPN IP multicast tunnel. Normal OISM procedures will to PE1 on an EVPN IP multicast tunnel. Normal OISM procedures will
also cause PE1 to send the (S,G) traffic up its BD1 IRB interface. also cause PE1 to send the (S,G) traffic up its BD1 IRB interface.
Normal MVPN procedures will then cause PE1 to forward the traffic on Normal MVPN procedures will then cause PE1 to forward the traffic on
an MVPN tunnel. In this case, the routing is not optimal, but the an MVPN tunnel. In this case, the routing is not optimal, but the
traffic does flow correctly. traffic does flow correctly.
6.1.2.3. Obtaining Optimal Routing of Traffic Between MVPN and EVPN 6.1.2.3. Obtaining Optimal Routing of Traffic Between MVPN and EVPN
skipping to change at page 60, line 7 skipping to change at page 60, line 7
each EVPN PE into a MEG. Then routing of MVPN-to-EVPN traffic is each EVPN PE into a MEG. Then routing of MVPN-to-EVPN traffic is
optimal. However, routing of EVPN-to-MVPN traffic is not guaranteed optimal. However, routing of EVPN-to-MVPN traffic is not guaranteed
to be optimal when a source host is on a multi-homed ethernet segment to be optimal when a source host is on a multi-homed ethernet segment
(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 deemed appropriate between
optimal routing and MEG deployment. optimal routing and MEG deployment.
6.1.2.4. Selecting the MEG SBD-DR 6.1.2.4. Selecting the MEG SBD-DR
Every PE that is eligible for selection as the MEG SBD-DR originates Every PE that is eligible for selection as the MEG SBD-DR originates
an SBD-IMET route. As stated in Section 5, these SBD-IMET routes an SBD-IMET route. As stated in Section 5, these SBD-IMET routes
carry a Multicast Flags EC with the MEG Flag set. carry a Multicast Flags EC with the MEG Flag set.
These SBD-IMET routes SHOULD also carry a DF Election EC. The DF These SBD-IMET routes SHOULD also carry a DF Election EC. The DF
Election EC and its use is specified in ([RFC8584]). When the route Election EC and its use are specified in ([RFC8584]). When the route
is originated, the AC-DF bit in the DF Election EC SHOULD be set to is originated, the AC-DF bit in the DF Election EC SHOULD be set to
zero. This bit is not used when selecting a MEG SBD-DR, i.e., it zero. This bit is not used when selecting a MEG SBD-DR, i.e., it
MUST be ignored by the receiver of an SBD-IMET route. MUST be ignored by the receiver of an SBD-IMET route.
In the context of a given Tenant Domain, to select the MEG SBD-DR, In the context of a given Tenant Domain, to select the MEG SBD-DR,
the MEGs of the Tenant Domain perform the following procedure: the MEGs of the Tenant Domain perform the following procedure:
o From the set of received SBD-IMET routes for the given tenant o From the set of received SBD-IMET routes for the given tenant
domain, determine he candidate set of PEs that support MEG domain, determine the candidate set of PEs that support MEG
functionality for that domain. functionality for that domain.
o Select a DF Election algorithm as specified in [RFC8584]. Some of o Select a DF Election algorithm as specified in [RFC8584]. Some of
the possible algorithms can be found, e.g., in [RFC7432], the possible algorithms can be found, e.g., in [RFC7432],
[RFC8584], and [I-D.ietf-bess-evpn-pref-df]. [RFC8584], and [I-D.ietf-bess-evpn-pref-df].
o Apply the DF Election Algorithm (see [RFC8584]) to the candidate o Apply the DF Election Algorithm (see [RFC8584]) to the candidate
set of PEs. The "winner" becomes the MEG SBD-DR. set of PEs. The "winner" becomes the MEG SBD-DR.
Note that if a given PE supports IPMG (Section 6.1.2) or PEG Note that if a given PE supports IPMG (Section 6.1.2) or PEG
skipping to change at page 62, line 7 skipping to change at page 62, line 7
the IIF of the (S,G) state is set as follows: the IIF of the (S,G) state is set as follows:
o if S is on a BD that is attached to the PE, the IIF is the PE's o if S is on a BD that is attached to the PE, the IIF is the PE's
IRB interface to that BD; IRB interface to that BD;
o if S is not on a BD that is attached to the PE, the IIF is the o if S is not on a BD that is attached to the PE, the IIF is the
PE's IRB interface to the SBD. PE's IRB interface to the SBD.
When the PE creates such an (S,G) state, it MUST originate (if it When the PE creates such an (S,G) state, it MUST originate (if it
hasn't already) an SBD-SMET route for (S,G). This will cause it to hasn't already) an SBD-SMET route for (S,G). This will cause it to
pull the (S,G) traffic via layer 2. When the traffic arrives over an receive the (S,G) traffic via layer 2. When the traffic arrives over an
EVPN tunnel, it gets sent up an IRB interface where the layer 3 EVPN tunnel, it gets sent up an IRB interface where the layer 3
multicast routing determines the packet's disposition. The SBD-SMET multicast routing determines the packet's disposition. The SBD-SMET
route is withdrawn when the (S,G) state no longer exists (unless route is withdrawn when the (S,G) state no longer exists (unless
there is some other reason for not withdrawing it). there is some other reason for not withdrawing it).
If there are no tenant multicast routers with the EVPN tenant domain, If there are no tenant multicast routers within the EVPN tenant domain,
there cannot be an RP in the Tenant Domain, so a PEG does not have to there cannot be an RP in the Tenant Domain, so a PEG does not have to
handle externally arriving PIM Join(*,G) messages. handle externally arriving PIM Join(*,G) messages.
The PEG DR for a particular BD MUST act as the a First Hop Router for The PEG DR for a particular BD MUST act as the a First Hop Router for
that BD. It will examine all (S,G) traffic on the BD, and whenever G that BD. It will examine all (S,G) traffic on the BD, and whenever G
is an ASM group, the PEG DR will send Register messages to the RP for is an ASM group, the PEG DR will send Register messages to the RP for
G. This means that the PEG DR will need to pull all the (S,G) G. This means that the PEG DR will need to receive all the (S,G)
traffic originating on a given BD, by originating an SMET (*,*) route traffic originating on a given BD, by originating an SMET (*,*) route
for that BD. If a PEG DR is the DR for all the BDS, in SHOULD for that BD. If a PEG DR is the DR for all the SBD, in SHOULD
originate just an SBD-SMET (*,*) route rather than an SMET (*,*) originate just an SBD-SMET (*,*) route rather than an SMET (*,*)
route for each BD. route for each BD.
The rules for exporting IP routes to multicast sources are the same The rules for exporting IP routes to multicast sources are the same
as those specified for MEGs in Section 6.1.2.2, except that the as those specified for MEGs in Section 6.1.2.2, except that the
exported routes will be IP routes rather than VPN-IP routes, and it exported routes will be IP routes rather than VPN-IP routes, and it
is not necessary to attach the VRF Route Import EC or the Source AS is not necessary to attach the VRF Route Import EC or the Source AS
EC. EC.
When a source is on a multi-homed segment, the same issue discussed When a source is on a multi-homed segment, the same issue discussed
skipping to change at page 63, line 23 skipping to change at page 63, line 23
The IIF for the layer 3 (S,G) or (*,G) state is determined by normal The IIF for the layer 3 (S,G) or (*,G) state is determined by normal
PIM procedures. If a receiver is on BD1, and the PEG DR is attached PIM procedures. If a receiver is on BD1, and the PEG DR is attached
to BD1, its IRB interface to BD1 is added to the OIF list. This to BD1, its IRB interface to BD1 is added to the OIF list. This
ensures that any receivers locally attached to the PEG DR will ensures that any receivers locally attached to the PEG DR will
receive the traffic. If there are receivers attached to other EVPN receive the traffic. If there are receivers attached to other EVPN
PEs, then whenever (S,G) traffic from an external source matches a PEs, then whenever (S,G) traffic from an external source matches a
(*,G) state, the PEG will create (S,G) state. The IIF will be set to (*,G) state, the PEG will create (S,G) state. The IIF will be set to
whatever external interface the traffic is expected to arrive on whatever external interface the traffic is expected to arrive on
(copied from the (*,G) state), the OIF list is copied from the (*,G) (copied from the (*,G) state), the OIF list is copied from the (*,G)
state, and the SBD IRB interface added to the OIF list. state, and the SBD IRB interface is added to the OIF list.
6.2. Interworking with PIM via an External PIM Router 6.2. Interworking with PIM via an External PIM Router
Section 6.1 describes how to use an OISM PE router as the gateway to Section 6.1 describes how to use an OISM PE router as the gateway to
a non-EVPN multicast domain, when the EVPN tenant domain is not being a non-EVPN multicast domain, when the EVPN tenant domain is not being
used as an intermediate transit network for multicast. An used as an intermediate transit network for multicast. An
alternative approach is to have one or more external PIM routers alternative approach is to have one or more external PIM routers
(perhaps operated by a tenant) on one of the BDs of the tenant (perhaps operated by a tenant) on one of the BDs of the tenant
domain. We will refer to this BD as the "gateway BD". domain. We will refer to this BD as the "gateway BD".
skipping to change at page 63, line 51 skipping to change at page 63, line 51
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 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, following normal given multicast flow, it conveys that interest, following normal
OISM procedures, by originating an SBD-SMET route for that flow. OISM procedures, by originating an SBD-SMET route for that flow.
o If a PE attached to the gateway BD receives an SBD-SMET, it may o If a PE attached to the gateway BD receives an SBD-SMET, it may
need to generate and transmit a corresponding IGMP/MLD Join out need to generate and transmit a corresponding IGMP/MLD Join on
one or more of its ACs. (Procedures for generating an IGMP/MLD one or more of its ACs. (Procedures for generating an IGMP/MLD
Join as a result of receiving an SMET route are given in Join as a result of receiving an SMET route are given in
[RFC9251].) The PE MUST know which BD is the Gateway BD and MUST [RFC9251].) The PE MUST know which BD is the Gateway BD and MUST
NOT transmit an IGMP/MLD Join to any other BDs. Furthermore, even 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 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 an IGMP/MLD Join on that AC unless there is an external PIM route
attached via that AC. attached via that AC.
As a result, IGMP/MLD messages will seen by the external PIM As a result, IGMP/MLD messages will be received by the external PIM
routers on the gateway BD, and those external PIM routers will routers on the gateway BD, and those external PIM routers will
send PIM Join messages externally as required. Traffic of the send PIM Join messages externally as required. Traffic for the
given multicast flow will then be received by one of the external given multicast flow will then be received by one of the external
PIM routers, and that traffic will be forwarded by that router to PIM routers, and that traffic will be forwarded by that router to
the gateway BD. 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 and 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.
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. This enables the where the external PIM routers will receive it. This enables the
external PIM routers to perform FHR functions on behalf of the external PIM routers to perform FHR functions on behalf of the
entire Tenant Domain. (Of course, if the gateway BD has a entire Tenant Domain. (Of course, if the gateway BD has a
multi-homed segment, only the PE that is the DF for that segment multi-homed segment, only the PE that is the DF for that segment
will transmit the multicast traffic to the 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
skipping to change at page 66, line 13 skipping to change at page 66, line 13
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:
1. 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 PE1's PIM routing instance will receive the Join arrive on the BD1
IRB interface. If X is not within the Tenant Domain, PE1 IRB interface. If X is not within the Tenant Domain, PE1
handles the Join according to normal PIM procedures. This will handles the Join according to normal PIM procedures. This will
generally result in PE1 selecting an Upstream Neighbor and generally result in PE1 selecting an Upstream Neighbor and
sending it a 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 PE, PE1 sends (if it hasn't already) an SBD-SMET route for
(X,G). The IIF of the layer 3 (X,G) state will be the SBD IRB (X,G). The IIF of the layer 3 (X,G) state will be the SBD IRB
interface, and the OIF list will include the IRB interface to interface, and the OIF list will include the IRB interface to
BD1. BD1.
The SBD-SMET route will pull the (X,G) traffic to PE1, and the The SBD-SMET route will receive 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 will be the IRB interface to X's BD, and the OIF list will
include the IRB interface to BD1. include the IRB interface to BD1.
2. 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 PE1's PIM routing instance will receive the Join on the BD1
IRB 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, If either X or Upstream Neighbor is within the Tenant Domain,
PE1 sends (if it hasn't already) an SBD-SMET route for (X,G). PE1 sends (if it hasn't already) an SBD-SMET route for (X,G).
The IIF of the layer 3 (X,G) state will be the SBD IRB The IIF of the layer 3 (X,G) state will be the SBD IRB
interface, and the OIF list will include the IRB interface to interface, and the OIF list will include the IRB interface to
BD1. BD1.
The SBD-SMET route will pull the (X,G) traffic to PE1, and the The SBD-SMET route will attract 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
IANA is requested to assign new flags in the "Multicast Flags IANA is requested to assign new flags in the "Multicast Flags
Extended Community Flags" registry. These flags are: Extended Community Flags" registry. These flags are:
o IPMG o IPMG
skipping to change at page 71, line 9 skipping to change at page 71, line 9
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non- for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 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 devices. Then it shows the model
specified in [RFC9135], where a single box contains both routing and specified in [RFC9135], where a single device 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
no L2 bridging capabilities. There are two LANs, LAN1 and LAN2. no L2 bridging capabilities. There are two LANs, LAN1 and LAN2.
LAN1 is realized by switch1, LAN2 by switch2. The router has an LAN1 is realized by switch1, LAN2 by switch2. The router has an
interface, "lan1" that attaches to LAN1 (via switch1) and an interface, "lan1" that attaches to LAN1 (via switch1) and an
interface "lan2" that attachs to LAN2 (via switch2). Each intreface interface "lan2" that attachs to LAN2 (via switch2). Each intreface
is configured, as an IP interface, with an IP address and a subnet is configured, as an IP interface, with an IP address and a subnet
mask. mask.
skipping to change at page 71, line 38 skipping to change at page 71, line 38
|_________________| |__________________| |_________________| |__________________|
LAN1 LAN2 LAN1 LAN2
Figure 1: Conventional Router with LAN Interfaces Figure 1: Conventional Router with LAN Interfaces
IP traffic (unicast or multicast) that remains within a single subnet IP traffic (unicast or multicast) that remains within a single subnet
never reaches the router. For instance, if H1 emits an ethernet never reaches the router. For instance, if H1 emits an ethernet
frame with H2's MAC address in the ethernet destination address frame with H2's MAC address in the ethernet destination address
field, the frame will go from H1 to Switch1 to H2, without ever field, the frame will go from H1 to Switch1 to H2, without ever
reaching the router. Since the frame is never seen by a router, the reaching the router. Since the frame is never seen by a router, the
IP datagram within the frame remains entirely unchanged; e.g., its IP datagram within the frame remains entirely unchanged, e.g., its
TTL is not decremented. The ethernet Source and Destination MAC TTL is not decremented. The ethernet Source and Destination MAC
addresses are not changed either. addresses are not changed either.
If H1 wants to send a unicast IP datagram to H3, which is on a If H1 wants to send a unicast IP datagram to H3, which is on a
different subnet, H1 has to be configured with the IP address of a different subnet, H1 has to be configured with the IP address of a
"default router". Let's assume that H1 is configured with an IP "default router". Let's assume that H1 is configured with an IP
address of Router1 as its default router address. H1 compares H3's address of Router1 as its default router address. H1 compares H3's
IP address with its own IP address and IP subnet mask, and determines IP address with its own IP address and IP subnet mask, and determines
that H3 is on a different subnet. So the packet has to be routed. that H3 is on a different subnet. So the packet has to be routed.
H1 uses ARP to map Router1's IP address to a MAC address on LAN1. H1 H1 uses ARP to map Router1's IP address to a MAC address on LAN1. H1
skipping to change at page 72, line 17 skipping to change at page 72, line 17
encapsulation and processes the IP datagram. The datagram is not encapsulation and processes the IP datagram. The datagram is not
addressed to Router1, so it must be forwarded further. Router1 does addressed to Router1, so it must be forwarded further. Router1 does
a lookup of the datagram's IP destination field, and determines that a lookup of the datagram's IP destination field, and determines that
the destination (H3) can be reached via Router1's lan2 interface. the destination (H3) can be reached via Router1's lan2 interface.
Router1 now performs the IP processing of the datagram: it decrements Router1 now performs the IP processing of the datagram: it decrements
the IP TTL, adjusts the IP header checksum (if present), may fragment the IP TTL, adjusts the IP header checksum (if present), may fragment
the packet is necessary, etc. Then the datagram (or its fragments) the packet is necessary, etc. Then the datagram (or its fragments)
are encapsulated in an ethernet header, with Router1's MAC address on are encapsulated in an ethernet header, with Router1's MAC address on
LAN2 as the MAC Source Address, and H3's MAC address on LAN2 (which LAN2 as the MAC Source Address, and H3's MAC address on LAN2 (which
Router1 determines via ARP) as the MAC Destination Address. Finally Router1 determines via ARP) as the MAC Destination Address. Finally
the packet is sent out the lan2 interface. the packet is sent on the lan2 interface.
If H1 has an IP multicast datagram to send (i.e., an IP datagram If H1 has an IP multicast datagram to send (i.e., an IP datagram
whose Destination Address field is an IP Multicast Address), it whose Destination Address field is an IP Multicast Address), it
encapsulates it in an ethernet frame whose MAC Destination Address is encapsulates it in an ethernet frame whose MAC Destination Address is
computed from the IP Destination Address. computed from the IP Destination Address.
If H2 is a receiver for that multicast address, H2 will receive a If H2 is a receiver for that multicast address, H2 will receive a
copy of the frame, unchanged, from H1. The MAC Source Address in the copy of the frame, unchanged, from H1. The MAC Source Address in the
ethernet encapsulation does not change, the IP TTL field does not get ethernet encapsulation does not change, the IP TTL field does not get
decremented, etc. decremented, etc.
If H3 is a receiver for that multicast address, the datagram must be If H3 is a receiver for that multicast address, the datagram must be
routed to H3. In order for this to happen, Router1 must be routed to H3. In order for this to happen, Router1 must be
configured as a multicast router, and it must accept traffic sent to configured as a multicast router, and it must accept traffic sent to
ethernet multicast addresses. Router1 will receive H1's multicast ethernet multicast addresses. Router1 will receive H1's multicast
frame on its lan1 interface, will remove the ethernet encapsulation, frame on its lan1 interface, will remove the ethernet encapsulation,
and will determine how to dispatch the IP datagram based on Router1's and will determine how to dispatch the IP datagram based on Router1's
multicast forwarding states. If Router1 knows that there is a multicast forwarding states. If Router1 knows that there is a
receiver for the multicast datagram on LAN2, makes a copy of the receiver for the multicast datagram on LAN2, it makes a copy of the
datagram, decrements the TTL (and performs any other necessary IP IP datagram, decrements the TTL (and performs any other necessary IP
processing), then encapsulates the datagram in ethernet frame for processing), then encapsulates the datagram in ethernet frame for
LAN2. The MAC Source Address for this frame will be Router1's MAC LAN2. The MAC Source Address for this frame will be Router1's MAC
Source Address on LAN2. The MAC Destination Address is computed from Source Address on LAN2. The MAC Destination Address is computed from
the IP Destination Address. Finally, the frame is sent out Router1's the IP Destination Address. Finally, the frame is sent on Router1's
LAN2 interface. LAN2 interface.
Figure 2 shows an Integrated Router/Bridge that supports the routing/ Figure 2 shows an Integrated Router/Bridge that supports the routing/
bridging integration model of [RFC9135]. bridging integration model of [RFC9135].
+------------------------------------------+ +------------------------------------------+
| Integrated Router/Bridge | | Integrated Router/Bridge |
+-------+ +--------+ +-------+ +-------+ +--------+ +-------+
| | IRB1| L3 |IRB2 | | | | IRB1| L3 |IRB2 | |
H1 -----+ BD1 +--------+Routing +--------+ BD2 +------H3 H1 -----+ BD1 +--------+Routing +--------+ BD2 +------H3
| | |Instance| | | | | |Instance| | |
H2 -----| | | | | | H2 -----| | | | | |
+-------+ +--------+ +-------+ +-------+ +--------+ +-------+
|___________________| |____________________| |___________________| |____________________|
LAN1 LAN2 LAN1 LAN2
Figure 2: Integrated Router/Bridge Figure 2: Integrated Router/Bridge
In Figure 2, a single box consists of one or more "L3 Routing In Figure 2, a single device consists of one or more "L3 Routing
Instances". The routing/forwarding tables of a given routing Instances". The routing/forwarding tables of a given routing
instance is known as an IP-VRF ([RFC9135]). In the context of EVPN, instance is known as an IP-VRF [RFC9135]. In the context of EVPN,
it is convenient to think of each routing instance as representing it is convenient to think of each routing instance as representing
the routing of a particular tenant. Each IP-VRF is attached to one the routing of a particular tenant. Each IP-VRF is attached to one
or more interfaces. or more interfaces.
When several EVPN PEs have a routing instance of the same tenant When several EVPN PEs have a routing instance in the same tenant
domain, those PEs advertise IP routes to the attached hosts. This is domain, those PEs advertise IP routes to the attached hosts. This is
done as specified in [RFC9135]. done as specified in [RFC9135].
The integrated router/bridge shown in Figure 2 also attaches to a The integrated router/bridge shown in Figure 2 also attaches to a
number of "Broadcast Domains" (BDs). Each BD performs the functions number of "Broadcast Domains" (BDs). Each BD performs the functions
that are performed by the bridges in Figure 1. To the L3 routing that are performed by the bridges in Figure 1. To the L3 routing
instance, each BD appears to be a LAN. The interface attaching a instance, each BD appears to be a LAN. The interface attaching a
particular BD to a particular IP-VRF is known as an "IRB Interface". particular BD to a particular IP-VRF is known as an "IRB Interface".
From the perspective of L3 routing, each BD is a subnet. Thus each From the perspective of L3 routing, each BD is a subnet. Thus each
IRB interface is configured with a MAC address (which is the router's IRB interface is configured with a MAC address (which is the router's
skipping to change at page 74, line 48 skipping to change at page 74, line 48
If H1 needs to send an IP packet to H4, it determines from its IP If H1 needs to send an IP packet to H4, it determines from its IP
address and subnet mask that H4 is on the same subnet as H1. address and subnet mask that H4 is on the same subnet as H1.
Although H1 and H4 are not attached to the same PE router, EVPN Although H1 and H4 are not attached to the same PE router, EVPN
provides ethernet communication among all hosts that are on the same provides ethernet communication among all hosts that are on the same
BD. H1 thus uses ARP to find H4's MAC address, and sends an ethernet BD. H1 thus uses ARP to find H4's MAC address, and sends an ethernet
frame with H4's MAC address in the Destination MAC address field. frame with H4's MAC address in the Destination MAC address field.
The frame is received at PE1, but since the Destination MAC address The frame is received at PE1, but since the Destination MAC address
is not PE1's MAC address, PE1 assumes that the frame is to remain on is not PE1's MAC address, PE1 assumes that the frame is to remain on
BD1. Therefore the packet inside the frame is NOT decapsulated, and BD1. Therefore the packet inside the frame is NOT decapsulated, and
is NOT send up the IRB interface to PE1's routing instance. Rather, is NOT sent via the IRB interface to PE1's routing instance. Rather,
standard EVPN intra-subnet procedures (as detailed in [RFC7432] are standard EVPN intra-subnet procedures (as detailed in [RFC7432]) are
used to deliver the frame to PE2, which then sends it to H4. used to deliver the frame to PE2, which then sends it to H4.
If H1 needs to send an IP packet to H5, it determines from its IP If H1 needs to send an IP packet to H5, it determines from its IP
address and subnet mask that H5 is NOT on the same subnet as H1. address and subnet mask that H5 is NOT on the same subnet as H1.
Assuming that H1 has been configured with the IP address of PE1 as Assuming that H1 has been configured with the IP address of PE1 as
its default router, H1 sends the packet in an ethernet frame with its default router, H1 sends the packet in an ethernet frame with
PE1's MAC address in its Destination MAC Address field. PE1 receives PE1's MAC address in its Destination MAC Address field. PE1 receives
the frame, and sees that the frame is addressed to it. PE1 thus the frame, and sees that the frame is addressed to it. PE1 thus
sends the frame up its IRB1 interface to the L3 routing instance. sends the frame via its IRB1 interface to the L3 routing instance.
Appropriate IP processing is done (e.g., TTL decrement). The L3 Appropriate IP processing is done, e.g., TTL decrement. The L3
routing instance determines that the "next hop" for H5 is PE2, so the routing instance determines that the "next hop" for H5 is PE2, so the
packet is encapsulated (e.g., in MPLS) and sent across the backbone packet is encapsulated (e.g., in MPLS) and sent across the backbone
to PE2's routing instance. PE2 will see that the packet's to PE2's routing instance. PE2 will see that the packet's
destination, H5, is on BD2 segment-2, and will send the packet down destination, H5, is on BD2 segment-2, and will send the packet via
its IRB2 interface. This causes the IP packet to be encapsulated in its IRB2 interface. This causes the IP packet to be encapsulated in
an ethernet frame with PE2's MAC address (on BD2) in the Source an ethernet frame with PE2's MAC address (on BD2) in the Source
Address field and H5's MAC address in the Destination Address field. Address field and H5's MAC address in the Destination Address field.
Note that if H1 has an IP packet to send to H3, the forwarding of the Note that if H1 has an IP packet to send to H3, the forwarding of the
packet is handled entirely within PE1. PE1's routing instance sees packet is handled entirely within PE1. PE1's routing instance sees
the packet arrive on its IRB1 interface, and then transmits the the packet arrive on its IRB1 interface, and then transmits the
packet by sending it down its IRB2 interface. packet by sending it via its IRB2 interface.
Often, all the hosts in a particular Tenant Domain will be Often, all the hosts in a particular Tenant Domain will be
provisioned with the same value of the default router IP address. provisioned with the same value of the default router IP address.
This IP address can be assigned, as an "anycast address", to all the This IP address can be provisioned as an "anycast address" in all the
EVPN PEs attached to that Tenant Domain. Thus although all hosts are EVPN PEs attached to that Tenant Domain. Thus although all hosts are
provisioned with the same "default router address", the actual provisioned with the same "default router address", the actual
default router for a given host will be one of the PEs that is default router for a given host will be the PEs that is
attached to the same ethernet segment as the host. This provisioning attached to the same ethernet segment as the host. This provisioning
method ensures that IP packets from a given host are handled by the method ensures that IP packets from a given host are handled by the
closest EVPN PE that supports IRB. closest EVPN PE that supports IRB.
In the topology of Figure 3, one could imagine that H1 is configured In the topology of Figure 3, one could imagine that H1 is configured
with a default router address that belongs to PE2 but not to PE1. with a default router address that belongs to PE2 but not to PE1.
Inter-subnet routing would still work, but IP packets from H1 to H3 Inter-subnet routing would still work, but IP packets from H1 to H3
would then follow the non-optimal path H1-->PE1-->PE2-->PE1-->H3. would then follow the non-optimal path H1-->PE1-->PE2-->PE1-->H3.
Sending traffic on this sort of path, where it leaves a router and Sending traffic on this sort of path, where it leaves a router and
then comes back to the same router, is sometimes known as then comes back to the same router, is sometimes known as
"hairpinning". Similarly, if PE2 supports IRB but PE1 dos not, the "hairpinning". Similarly, if PE2 supports IRB but PE1 dos not, the
same non-optimal path from H1 to H3 would have to be followed. To same non-optimal path from H1 to H3 would have to be followed. To
avoid hairpinning, each EVPN PE needs to support IRB. avoid hairpinning, each EVPN PE needs to support IRB.
It is worth pointing out the way IRB interfaces interact with It is worth pointing out the way IRB interfaces interact with
multicast traffic. Referring again to Figure 3, suppose PE1 and PE2 multicast traffic. Referring again to Figure 3, suppose PE1 and PE2
are functioning as IP multicast routers. Suppose also that H3 are functioning as IP multicast routers. Also suppose that H3
transmits a multicast packet, and both H1 and H4 are interested in transmits a multicast packet, and both H1 and H4 are interested in
receiving that packet. PE1 will receive the packet from H3 via its receiving that packet. PE1 will receive the packet from H3 via its
IRB2 interface. The ethernet encapsulation from BD2 is removed, the IRB2 interface. The ethernet encapsulation from BD2 is removed, the
IP header processing is done, and the packet is then reencapsulated IP header processing is done, and the packet is then reencapsulated
for BD1, with PE1's MAC address in the MAC Source Address field. for BD1, with PE1's MAC address in the MAC Source Address field.
Then the packet is sent down the IRB1 interface. Layer 2 procedures Then the packet is sent via the IRB1 interface. Layer 2 procedures
(as defined in [RFC7432] would then be used to deliver a copy of the (as defined in [RFC7432]) would then be used to deliver a copy of the
packet locally to H1, and remotely to H4. packet locally to H1, and remotely to H4.
Please be aware that his document modifies the semantics, described Please be aware that his document modifies the semantics, described
in the previous paragraph, of sending/receiving multicast traffic on in the previous paragraph, of sending/receiving multicast traffic on
an IRB interface. This is explained in Section 1.5.1 and subsequent an IRB interface. This is explained in Section 1.5.1 and subsequent
sections. sections.
Authors' Addresses Authors' Addresses
Wen Lin Wen Lin
 End of changes. 121 change blocks. 
137 lines changed or deleted 136 lines changed or added

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