rfc9625xml2.original.xml   rfc9625.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!-- $Id: draft-ietf-bess-evpn-irb-mcast.xml,v 1.4 2020/12/23 19:26:29 zzhang <!DOCTYPE rfc [
Exp $ --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbhy "&#8209;">
C.2119.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC3376 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3376.xml">
<!ENTITY RFC3810 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3810.xml">
<!ENTITY RFC4541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4541.xml">
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3032.xml">
<!ENTITY RFC4360 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4360.xml">
<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4364.xml">
<!ENTITY RFC6513 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6513.xml">
<!ENTITY RFC6514 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6514.xml">
<!ENTITY RFC6625 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6625.xml">
<!ENTITY RFC7153 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7153.xml">
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7432.xml">
<!ENTITY RFC7606 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7606.xml">
<!ENTITY RFC7716 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7716.xml">
<!ENTITY RFC7761 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7761.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8296 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8296.xml">
<!ENTITY RFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8584.xml">
<!ENTITY RFC9135 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9135.xml">
<!ENTITY RFC9136 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9136.xml">
<!ENTITY RFC9251 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9251.xml">
]> ]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="no"?>
<rfc category="std" docName="draft-ietf-bess-evpn-irb-mcast-11" ipr="trust200902
">
<front>
<title abbrev="evpn-irb-mcast">EVPN Optimized Inter-Subnet Multicast (OISM)
Forwarding</title>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-bess-evpn-irb-mcast-11" number="9625" consensus="true" ipr="trust200902" obso
letes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDep
th="6" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="EVPN OISM Forwarding">EVPN Optimized Inter-Subnet Multicast (
OISM) Forwarding</title>
<seriesInfo name="RFC" value="9625"/>
<author fullname="Wen Lin" initials="W." surname="Lin"> <author fullname="Wen Lin" initials="W." surname="Lin">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>10 Technology Park Drive</street> <street>10 Technology Park Drive</street>
<city>Westford</city> <city>Westford</city>
<region>Massachusetts</region> <region>MA</region>
<code>01886</code> <code>01886</code>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>wlin@juniper.net</email> <email>wlin@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>10 Technology Park Drive</street> <street>10 Technology Park Drive</street>
<city>Westford</city> <city>Westford</city>
<region>Massachusetts</region> <region>MA</region>
<code>01886</code> <code>01886</code>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>zzhang@juniper.net</email> <email>zzhang@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="John Drake" initials="J." surname="Drake"> <author fullname="John Drake" initials="J." surname="Drake">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1194 N. Mathilda Ave</street> <street>1194 N. Mathilda Ave</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>jdrake@juniper.net</email> <email>jdrake@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Eric C. Rosen" initials="E." surname="Rosen" role="editor"
<author fullname="Eric C. Rosen" initials="E." surname="Rosen" >
role="editor">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>10 Technology Park Drive</street> <street>10 Technology Park Drive</street>
<city>Westford</city> <city>Westford</city>
<region>Massachusetts</region> <region>MA</region>
<code>01886</code> <code>01886</code>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email> erosen52@gmail.com</email> <email>erosen52@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jorge Rabadan" initials="J." surname="Rabadan"> <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>777 E. Middlefield Road</street> <street>777 E. Middlefield Road</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Ali Sajassi" initials="A." surname="Sajassi"> <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>170 West Tasman Drive</street> <street>170 West Tasman Drive</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>95134</code>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>sajassi@cisco.com</email> <email>sajassi@cisco.com</email>
</address> </address>
</author> </author>
<date month="August" year="2024"/>
<workgroup>BESS</workgroup> <area>RTG</area>
<workgroup>bess</workgroup>
<keyword>OISM</keyword>
<keyword>PEG</keyword>
<keyword>MEG</keyword>
<keyword>SBD</keyword>
<abstract> <abstract>
<t> <t>
Ethernet VPN (EVPN) provides a service that allows a single Local Ethernet VPN (EVPN) provides a service that allows a single Local
Area Network (LAN), comprising a single IP subnet, to be divided Area Network (LAN), comprising a single IP subnet, to be divided
into multiple "segments". Each segment may be located at a into multiple segments. Each segment may be located at a
different site, and the segments are interconnected by an IP or MPLS different site, and the segments are interconnected by an IP or MPLS
backbone. Intra-subnet traffic (either unicast or multicast) always backbone. Intra-subnet traffic (either unicast or multicast) always
appears to the end users to be bridged, even when it is actually appears to the end users to be bridged, even when it is actually
carried over the IP or MPLS backbone. When a single "tenant" owns carried over the IP or MPLS backbone. When a single tenant owns
multiple such LANs, EVPN also allows IP unicast traffic to be routed multiple such LANs, EVPN also allows IP unicast traffic to be routed
between those LANs. This document specifies new procedures that between those LANs. This document specifies new procedures that
allow inter-subnet IP multicast traffic to be routed among the LANs allow inter-subnet IP multicast traffic to be routed among the LANs
of a given tenant, while still making intra-subnet IP multicast of a given tenant while still making intra-subnet IP multicast
traffic appear to be bridged. These procedures can provide optimal traffic appear to be bridged. These procedures can provide optimal
routing of the inter-subnet multicast traffic, and do not require routing of the inter-subnet multicast traffic and do not require
any such traffic to egress a given router and then ingress that same any such traffic to egress a given router and then ingress that same
router. These procedures also accommodate IP multicast traffic that router. These procedures also accommodate IP multicast traffic that
originates or is destined external to the EVPN domain. originates or is destined to be external to the EVPN domain.
</t> </t>
</abstract> </abstract>
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.
</t>
</note>
</front> </front>
<middle> <middle>
<section title="Introduction" anchor="introduction"> <section anchor="introduction" numbered="true" toc="default">
<section title="Terminology" anchor="terminology"> <name>Introduction</name>
<t> <section anchor="terminology" numbered="true" toc="default">
In this document we make frequent use of the following terminology: <name>Terminology</name>
<list style="symbols"> <t>
<t> In this document, we make frequent use of the following terminology:
OISM: Optimized Inter-Subnet Multicast. EVPN&nbhy;PEs that </t>
<dl newline="false" spacing="normal">
<dt>OISM:</dt> <dd>Optimized Inter-Subnet Multicast. EVPN PEs that
follow the procedures of this document will be known as "OISM" follow the procedures of this document will be known as "OISM"
PEs. EVPN&nbhy;PEs that do not follow the procedures of this Provider Edges (PEs). EVPN PEs that do not follow the procedures of
document will be known as "non&nbhy;OISM" PEs. this
</t> document will be known as "non-OISM" PEs.
<t> </dd>
IP Multicast Packet: An IP packet whose IP Destination Address <dt>IP Multicast Packet:</dt> <dd>An IP packet whose IP Destination
field is a multicast address that is not a link&nbhy;local Address
address. (Link&nbhy;local addresses are IPv4 addresses in the field is a multicast address that is not a link-local
224/24 range and IPv6 address in the FF02/16 range.) address. (Link-local addresses are IPv4 addresses in the
</t> 224/24 range and IPv6 addresses in the FF02/16 range.)
<t> </dd>
IP Multicast Frame: An Ethernet frame whose payload is an IP <dt>IP Multicast Frame:</dt> <dd>An Ethernet frame whose payload is
an IP
multicast packet (as defined above). multicast packet (as defined above).
</t> </dd>
<t> <dt>(S,G) Multicast Packet:</dt> <dd>An IP multicast packet whose So
(S,G) Multicast Packet: An IP multicast packet whose IP Source urce IP Address field contains S and whose IP Destination Address field contains
Address field contains S and whose IP Destination Address field G.
contains G. </dd>
</t> <dt>(S,G) Multicast Frame:</dt> <dd>An IP multicast frame whose payl
<t> oad
(S,G) Multicast Frame: An IP multicast frame whose payload contains S in its Source IP Address field and G in its IP
contains S in its IP Source Address field and G in its IP
Destination Address field. Destination Address field.
</t> </dd>
<t> <dt>EVI:</dt> <dd>EVPN Instance. An EVPN instance spanning the
EVPN Instance (EVI): An EVPN instance spanning the Provid PE devices participating in that EVPN.
er Edge </dd>
(PE) devices participating in that EVPN. <dt>BD:</dt> <dd><t>Broadcast Domain. An emulated Ethernet, such tha
</t> t two
<t> systems on the same BD will receive each other's link-local
Broadcast Domain (BD): an emulated Ethernet, such that two broadcasts.</t>
systems on the same BD will receive each other's link&nbhy;local <t>
broadcasts. Note that EVPN supports service models in which a single EVI
<vspace/> contains only one BD and service models in which
<vspace/> a single EVI contains multiple BDs. Both types of service models
Note that EVPN supports service models in which a single EVPN are supported by this document. In all models, a given BD belongs
Instance contains only one BD, and service models in which
a single EVI contains multiple BDs. Both types of service model
are supported by this draft. In all models, a given BD belongs
to only one EVI. to only one EVI.
</t> </t>
<t> </dd>
Designated Forwarder (DF). As defined in <xref <dt>DF:</dt> <dd><t>Designated Forwarder. As defined in <xref target
target="RFC7432"/>, an Ethernet segment may be multi&nbhy;homed ="RFC7432" format="default"/>, an Ethernet segment may be multihomed
(attached to more than one PE). An Ethernet segment may also (attached to more than one PE). An Ethernet segment may also
contain multiple BDs, of one or more EVIs. For each such EVI, contain multiple BDs of one or more EVIs. For each such EVI,
one of the PEs attached to the segment becomes that EVI's DF for one of the PEs attached to the segment becomes that EVI's DF for
that segment. Since a BD may belong to only one EVI, we can that segment. Since a BD may belong to only one EVI, we can
speak unambiguously of the BD's DF for a given segment. speak unambiguously of the BD's DF for a given segment.
<vspace/>
<vspace/>
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 mean the given BD's DF for that segment.
</t> </t>
<t> </dd>
AC: Attachment Circuit. An AC connects the bridging function of <dt>AC:</dt> <dd><t>Attachment Circuit. An AC connects the bridging
an EVPN&nbhy;PE to an Ethernet segment of a particular BD. ACs function of
are not visible at the router (L3) layer. an EVPN PE to an Ethernet segment of a particular BD. ACs
<vspace/> are not visible at the Layer 3.
<vspace/> </t>
<t>
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 say that the PE has n ACs to that segment.
</t> </t>
<t> </dd>
L3 Gateway: An L3 Gateway is a PE that connects an EVPN tenant <dt>L3 Gateway:</dt> <dd>An L3 Gateway is a PE that connects an EVPN
domain to an external multicast domain by performing both the Tenant
Domain to an external multicast domain by performing both the
OISM procedures and the Layer 3 multicast procedures of the OISM procedures and the Layer 3 multicast procedures of the
external domain. external domain.
</t> </dd>
<t> <dt>PEG:</dt> <dd>PIM/EVPN Gateway. An L3 Gateway that connects an E
PEG (PIM/EVPN Gateway): A L3 Gateway that connects an EVPN VPN
Tenant Domain to an external multicast domain whose Layer 3 Tenant Domain to an external multicast domain whose Layer 3
multicast procedures are those of PIM <xref multicast procedures are those of PIM <xref target="RFC7761" format=
target="RFC7761"/>. "default"/>.
</t> </dd>
<t> <dt>MEG:</dt> <dd>MVPN/EVPN Gateway. An L3 Gateway that connects an
MEG (MVPN/EVPN Gateway): A L3 Gateway that connects an EVPN EVPN
Tenant Domain to an external multicast domain whose Layer 3 Tenant Domain to an external multicast domain whose Layer 3
multicast procedures are those of MVPN (<xref multicast procedures are those of Multicast VPN (MVPN) <xref target=
target="RFC6513"/>, <xref target="RFC6514"/>). "RFC6513" format="default"/> <xref target="RFC6514" format="default"/>.
</t> </dd>
<t> <dt>IPMG:</dt> <dd>IP Multicast Gateway. A PE that is used for inter
IPMG (IP Multicast Gateway): A PE that is used for interworking working
OISM EVPN&nbhy;PEs with non&nbhy;OISM EVPN&nbhy;PEs. OISM EVPN PEs with non-OISM EVPN PEs.
</t> </dd>
<t> <dt>DR:</dt> <dd>Designated Router. A PE that has special responsibi
DR (Designated Router): A PE that has special responsibilities lities
for handling multicast on a given BD. for handling multicast on a given BD.
</t> </dd>
<t> <dt>FHR:</dt> <dd>First Hop Router. The FHR is a PIM router <xref ta
FHR (First Hop Router): The FHR is a PIM router <xref rget="RFC7761" format="default"/> with special responsibilities. It is the
target="RFC7761"/> with special responsibilities. It is the
first multicast router to see (S,G) packets from source S, and first multicast router to see (S,G) packets from source S, and
if G is an "Any Source Multicast (ASM)" group, the FHR is if G is an Any-Source Multicast (ASM) group, the FHR is
responsible for sending PIM Register messages to the PIM responsible for sending PIM Register messages to the PIM
Rendezvous Point for group G. Rendezvous Point (RP) for group G.
</t> </dd>
<t> <dt>LHR:</dt> <dd>Last Hop Router. The LHR is a PIM router <xref tar
LHR (Last Hop Router): The LHR is a PIM router <xref get="RFC7761" format="default"/> with special responsibilities. Generally, it
target="RFC7761"/> with special responsibilities. Generally, it
is attached to a LAN, and it determines whether there are any is attached to a LAN, and it determines whether there are any
hosts on the LAN that need to receive a given multicast flow. hosts on the LAN that need to receive a given multicast flow.
If so, it creates and sends the PIM Join messages that are If so, it creates and sends the PIM Join messages that are
necessary to receive the flow. necessary to receive the flow.
</t> </dd>
<t> <dt>EC:</dt> <dd>Extended Community. A BGP Extended Communities att
EC (Extended Community). A BGP Extended Communities attribute ribute
(<xref target="RFC4360"/>, <xref target="RFC7153"/>) is a BGP <xref target="RFC4360" format="default"/> <xref target="RFC7153" for
path attribute that consists of one or more extended mat="default"/> is a BGP
communities. path attribute that consists of one or more Extended
</t> Communities.
<t> </dd>
RT (Route Target): A Route Target is a particular kind of BGP <dt>RT:</dt> <dd>Route Target. A Route Target is a particular kind o
f 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 field, a sub-type field, and a value field. Certain
type/sub-type combinations indicate that a particular Extended type/sub-type combinations indicate that a particular Extended
Community is an RT. RT1 and RT2 are considered to be the same Community is an RT. RT1 and RT2 are considered to be the same
RT if and only if they have the same type, same sub-type, and RT if and only if they have the same type, sub-type, and
same value fields. value fields.
</t> </dd>
<t> <dt>C- prefix:</dt> <dd>In many documents on VPN
Use of the "C&nbhy;" prefix. In many documents on VPN multicast, the prefix C- appears before any address or
multicast, the prefix "C&nbhy;" appears before any address or
wildcard that refers to an address or addresses in a tenant's wildcard that refers to an address or addresses in a tenant's
address space, rather than to an address of addresses in the address space rather than to an address of addresses in the
address space of the backbone network. This document omits the address space of the backbone network. This document omits the
"C&nbhy;" prefix in many cases where it is clear from the C- prefix in many cases where it is clear from the
context that the reference is to the tenant's address space. context that the reference is to the tenant's address space.
</t> </dd>
</list> </dl>
</t>
<t>
This document also assumes familiarity with the terminology of <xref
target="RFC4364"/>, <xref target="RFC6514"/>, <xref
target="RFC7432"/>, <xref target="RFC7761"/>, <xref
target="RFC9251"/>, <xref target="RFC9136"/> and <xref
target="I-D.ietf-bess-evpn-bum-procedure-updates"/>.
</t>
</section> <!-- terminology -->
<section title="Background" anchor="background">
<t> <t>
Ethernet VPN (EVPN) <xref target="RFC7432"/> provides a Layer 2 This document also assumes familiarity with the terminology of <xref tar
get="RFC4364" format="default"/>, <xref target="RFC6514" format="default"/>, <xr
ef target="RFC7432" format="default"/>, <xref target="RFC7761" format="default"/
>, <xref target="RFC9136" format="default"/>, <xref target="RFC9251" format="def
ault"/>, and <xref target="RFC9572" format="default"/>.
</t>
<section>
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section anchor="background" numbered="true" toc="default">
<name>Background</name>
<t>
Ethernet VPN (EVPN) <xref target="RFC7432" format="default"/> provides
a Layer 2
VPN (L2VPN) solution, which allows an IP or MPLS backbone provider to offer VPN (L2VPN) solution, which allows an IP or MPLS backbone provider to offer
Ethernet service to a set of customers, known as "tenants". Ethernet service to a set of customers, known as "tenants".
</t> </t>
<t> <t>
In this section (as well as in <xref target="RFC9135"/>), we In this section (as well as in <xref target="RFC9135" format="default" />), we
provide some essential background information on EVPN. provide some essential background information on EVPN.
</t> </t>
<section title="Segments, Broadcast Domains, and Tenants" <section anchor="intro_bd" numbered="true" toc="default">
anchor="intro_bd"> <name>Segments, Broadcast Domains, and Tenants</name>
<t> <t>
One of the key concepts of EVPN is the Broadcast Domain (BD). A One of the key concepts of EVPN is the Broadcast Domain (BD). A
BD is essentially an emulated Ethernet. Each BD belongs to a BD is essentially an emulated Ethernet. Each BD belongs to a
single tenant. A BD typically consists of multiple Ethernet single tenant. A BD typically consists of multiple Ethernet
"segments", and each segment may be attached to a different EVPN segments, and each segment may be attached to a different EVPN
Provider Edge (EVPN&nbhy;PE) router. EVPN&nbhy;PE routers are Provider Edge (EVPN PE) router. EVPN PE routers are
often referred to as "Network Virtualization Endpoints" or NVEs. often referred to as "Network Virtualization Endpoints (NVEs)".
However, this document will use the term "EVPN&nbhy;PE", or, However, this document will use the term "EVPN PE" or,
when the context is clear, just "PE". when the context is clear, just "PE".
</t> </t>
<t> <t>
In this document, the term "segment" is used interchangeable with In this document, the term "segment" is used interchangeably with
the "Ethernet Segment" or "ES" in <xref target="RFC7432"/ "Ethernet Segment" or "ES", as defined in <xref target="R
>. FC7432" format="default"/>.
</t> </t>
<t> <t>
Attached to each segment are "Tenant Systems" (TSes). A TS may Attached to each segment are Tenant Systems (TSs). A TS may
be any type of system, physical or virtual, host or router, be any type of system, physical or virtual, host or router,
etc., that can attach to an Ethernet. etc., that can attach to an Ethernet.
</t> </t>
<t> <t>
When two TSes are on the same segment, traffic between them does When two TSs are on the same segment, traffic between them does
not pass through an EVPN&nbhy;PE. When two TSes are on not pass through an EVPN PE. When two TSs are on
different segments of the same BD, traffic between them does different segments of the same BD, traffic between them does
pass through an EVPN&nbhy;PE. pass through an EVPN PE.
</t> </t>
<t> <t>
When two TSes, say TS1 and TS2 are on the same BD, then: When two TSs, say TS1 and TS2, are on the same BD, then the followin
<list style="symbols"> g occurs:
</t>
<ul spacing="normal">
<li>
<t> <t>
If TS1 knows the MAC address of TS2, TS1 can send unicast If TS1 knows the Media Access Control (MAC) address of TS2, TS1 can send unicast
Ethernet frames to TS2. TS2 will receive the frames Ethernet frames to TS2. TS2 will receive the frames
unaltered. unaltered.
</t> </t>
</li>
<li>
<t> <t>
If TS1 broadcasts an Ethernet frame, TS2 will receive the If TS1 broadcasts an Ethernet frame, TS2 will receive the
unaltered frame. unaltered frame.
</t> </t>
</li>
<li>
<t> <t>
If TS1 multicasts an Ethernet frame, TS2 will receive the If TS1 multicasts an Ethernet frame, TS2 will receive the
unaltered frame, as long as TS2 has been provisioned to unaltered frame as long as TS2 has been provisioned to
receive the Ethernet multicast destination MAC address. receive the Ethernet multicast destination MAC address.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
When we say that TS2 receives an unaltered frame from TS1, we When we say that TS2 receives an unaltered frame from TS1, we
mean that the frame still contains TS1's MAC address, and that mean that the frame still contains TS1's MAC address and that
no alteration of the frame's payload (and consequently, no no alteration of the frame's payload (and consequently, no
alteration of the payload's IP header) has been made. alteration of the payload's IP header) has been made.
</t> </t>
<t> <t>
EVPN allows a single segment to be attached to multiple PE EVPN allows a single segment to be attached to multiple PE
routers. This is known as "EVPN multi&nbhy;homing". Suppose a routers. This is known as "EVPN multihoming". Suppose a
given segment is attached to both PE1 and PE2, and suppose PE1 given segment is attached to both PE1 and PE2, and suppose PE1
receives a frame from that segment. It may be necessary for PE1 receives a frame from that segment. It may be necessary for PE1
to send the frame over the backbone to PE2. EVPN has procedures to send the frame over the backbone to PE2. EVPN has procedures
to ensure that such a frame cannot be sent by PE2 back to its to ensure that such a frame cannot be sent back to its
originating segment. This is particularly important for originating segment by PE2. This is particularly important for
multicast, because a frame arriving at PE1 from a given segment multicast, because a frame arriving at PE1 from a given segment
will already have been seen by all the systems on that segment will already have been seen by all the systems on that segment
that need to see it. If the frame were sent back to the that need to see it. If the frame was sent back to the
originating segment by PE2, receivers on that segment would originating segment by PE2, receivers on that segment would
receive the packet twice. Even worse, the frame might be sent receive the packet twice. Even worse, the frame might be sent
back to PE1, which could cause an infinite loop. back to PE1, which could cause an infinite loop.
</t> </t>
</section> <!-- intro_bd --> </section>
<section title="Inter-BD (Inter-Subnet) IP Traffic" <section anchor="inter_bd" numbered="true" toc="default">
anchor="inter_bd"> <name>Inter-BD (Inter-Subnet) IP Traffic</name>
<t> <t>
If a given tenant has multiple BDs, the tenant may wish to allow If a given tenant has multiple BDs, the tenant may wish to allow
IP communication among these BDs. Such a set of BDs is known as IP communication among these BDs. Such a set of BDs is known as
an "EVPN Tenant Domain" or just a "Tenant Domain". an "EVPN Tenant Domain" or just a "Tenant Domain".
</t> </t>
<t> <t>
If tenant systems TS1 and TS2 are not in the same BD, then they If tenant systems TS1 and TS2 are not in the same BD, then they
do not receive unaltered Ethernet frames from each other. In do not receive unaltered Ethernet frames from each other. In
order for TS1 to send traffic to TS2, TS1 encapsulates an IP order for TS1 to send traffic to TS2, TS1 encapsulates an IP
datagram inside an Ethernet frame, and uses Ethernet to send datagram inside an Ethernet frame and uses Ethernet to send
these frames to an IP router. The router decapsulates the IP these frames to an IP router. The router decapsulates the IP
datagram, does the IP processing and re-encapsulates the datagram, does the IP processing, and re-encapsulates the
datagram for Ethernet. The MAC source address field now has the datagram for Ethernet. The MAC Source Address field now has the
MAC address of the router, not of TS1. The TTL field of the IP MAC address of the router, not of TS1. The TTL field of the IP
datagram should be decremented by exactly 1, even if the frame datagram should be decremented by exactly 1, even if the frame
needs to be sent from one PE to another. The structure of the needs to be sent from one PE to another. The structure of the
provider's backbone is thus hidden from the tenants. provider's backbone is thus hidden from the tenants.
</t> </t>
<t> <t>
EVPN accommodates the need for inter&nbhy;BD communication EVPN accommodates the need for inter-BD communication
within a Tenant Domain by providing an integrated L2/L3 service within a Tenant Domain by providing an integrated L2/L3 service
for unicast IP traffic. EVPN's Integrated Routing and Bridging for unicast IP traffic. EVPN's Integrated Routing and Bridging
(IRB) functionality is specified in <xref target="RFC9135"/>. (IRB) functionality is specified in <xref target="RFC9135" format="d efault"/>.
Each BD in a Tenant Domain is assumed to be a single IP subnet, Each BD in a Tenant Domain is assumed to be a single IP subnet,
and each IP subnet within a given Tenant Domain is assumed to and each IP subnet within a given Tenant Domain is assumed to
be a single BD. EVPN's IRB functionality allows IP traffic to be a single BD. EVPN's IRB functionality allows IP traffic to
travel from one BD to another, and ensures that proper IP travel from one BD to another and ensures that proper IP
processing (e.g., TTL decrement) is done. processing (e.g., TTL decrement) is done.
</t> </t>
<t> <t>
A brief overview of IRB, including the notion of an "IRB A brief overview of IRB, including the notion of an IRB
interface", can be found in <xref target="irb"/>. As explained interface, can be found in <xref target="irb" format="default"/>. A
s explained
there, an IRB interface is a sort of virtual interface there, an IRB interface is a sort of virtual interface
connecting an L3 routing instance to a BD. A BD may have connecting an L3 routing instance to a BD. A BD may have
multiple attachment circuits (ACs) to a given PE, where each AC multiple Attachment Circuits (ACs) to a given PE, where each AC
connects to a different Ethernet segment of the BD. However, connects to a different Ethernet segment of the BD. However,
these ACs are not visible to the L3 routing function; from the these ACs are not visible to the L3 routing function; from the
perspective of an L3 routing instance, a PE has just one perspective of an L3 routing instance, a PE has just one
interface to each BD, viz., the IRB interface for that BD. interface to each BD, viz., the IRB interface for that BD.
</t> </t>
<t> <t>
In this document, when traffic is routed out of an IRB in terface, In this document, when traffic is routed out of an IRB in terface,
we say it is sent down the IRB interface to the BD that t he IRB is we say it is sent down the IRB interface to the BD that t he IRB is
for. In the other direction, traffic is sent up the IRB i nterface for. In the other direction, traffic is sent up the IRB i nterface
from the BD to the L3 routing instance. from the BD to the L3 routing instance.
</t> </t>
<t> <t>
The "L3 routing instance" depicted in <xref target="irb"/> is The L3 routing instance depicted in <xref target="irb" format="defau
associated with a single Tenant Domain, and may be thought of as lt"/> is
an IP&nbhy;VRF for that Tenant Domain. associated with a single Tenant Domain and may be thought of as
IP Virtual Routing and Forwarding (IP-VRF) for that Tenant Domain.
</t> </t>
</section> <!-- inter_bd --> </section>
<section title="EVPN and IP Multicast" <section anchor="evpn_ip_mcast" numbered="true" toc="default">
anchor="evpn_ip_mcast"> <name>EVPN and IP Multicast</name>
<t> <t>
<xref target="RFC9135"/> and <xref target="RFC9136"/> <xref target="RFC9135" format="default"/> and <xref target="RFC9136"
cover inter&nbhy;subnet (inter&nbhy;BD) IP unicast forwarding, format="default"/>
but they do not cover inter&nbhy;subnet IP multicast forwarding. cover inter-subnet (inter-BD) IP unicast forwarding,
but they do not cover inter-subnet IP multicast forwarding.
</t> </t>
<t> <t>
<xref target="RFC7432"/> covers intra&nbhy;subnet <xref target="RFC7432" format="default"/> covers intra-subnet
(intra&nbhy;BD) Ethernet multicast. The intra&nbhy;subnet (intra-BD) Ethernet multicast. The intra-subnet
Ethernet multicast procedures of <xref target="RFC7432"/> are Ethernet multicast procedures of <xref target="RFC7432" format="defa
used for Ethernet Broadcast traffic, for Ethernet unicast ult"/> are
traffic whose MAC Destination Address field contains an Unknown used for Ethernet broadcast traffic, Ethernet unicast
address, and for Ethernet traffic whose MAC Destination Address traffic whose Destination MAC Address field contains an unknown
field contains an Ethernet Multicast MAC address. These three address, and Ethernet traffic whose Destination MAC Address
field contains an Ethernet multicast MAC address. These three
classes of traffic are known collectively as "BUM traffic" classes of traffic are known collectively as "BUM traffic"
(Broadcast/Unknown-Unicast/Multicast), and the procedures for (Broadcast, Unknown Unicast, or Multicast traffic), and the procedur es for
handling BUM traffic are known as "BUM procedures". handling BUM traffic are known as "BUM procedures".
</t> </t>
<t> <t>
<xref target="RFC9251"/> extends the intra&nbhy;subnet <xref target="RFC9251" format="default"/> extends the intra-subnet
Ethernet multicast procedures by adding procedures that are Ethernet multicast procedures by adding procedures that are
specific to, and optimized for, the use of IP multicast within a specific to, and optimized for, the use of IP multicast within a
subnet. However, that document does not cover inter&nbhy;subnet subnet. However, that document does not cover inter-subnet
IP multicast. IP multicast.
</t> </t>
<t> <t>
The purpose of this document is to specify procedures for EVPN The purpose of this document is to specify procedures for EVPN
that provide optimized IP multicast functionality within an EVPN that provide optimized IP multicast functionality within an EVPN
tenant domain. This document also specifies procedures that Tenant Domain. This document also specifies procedures that
allow IP multicast packets to be sourced from or destined to allow IP multicast packets to be sourced from or destined to
systems outside the Tenant Domain. We refer to the entire set of systems outside the Tenant Domain. The entire set of
these procedures as "OISM" (Optimized Inter&nbhy;Subnet procedures are referred to as "Optimized Inter-Subnet
Multicast) procedures. Multicast (OISM)" procedures.
</t> </t>
<t> <t>
In order to support the OISM procedures specified in this In order to support the OISM procedures specified in this
document, an EVPN&nbhy;PE MUST also support <xref document, an EVPN PE <bcp14>MUST</bcp14> also support <xref target="
target="RFC9135"/> and <xref target="RFC9251"/>. (However, RFC9135" format="default"/> and <xref target="RFC9251" format="default"/>. (How
certain procedures in <xref target="RFC9251"/> are ever,
certain procedures in <xref target="RFC9251" format="default"/> are
modified when OISM is supported.) modified when OISM is supported.)
</t> </t>
</section>
</section> <!-- "evpn_ip_mcast --> <section anchor="evpn_stuff" numbered="true" toc="default">
<name>BDs, MAC-VRFs, and EVPN Service Models</name>
<section title="BDs, MAC-VRFS, and EVPN Service Models"
anchor="evpn_stuff">
<t> <t>
<xref target="RFC7432"/> defines the notion of "MAC&nbhy;VRF". <xref target="RFC7432" format="default"/> defines the notion of MAC-VR
A MAC&nbhy;VRF contains one or more "Bridge Tables" (see section F (MAC Virtual Routing and Forwarding).
3 of <xref target="RFC7432"/> for a discussion of this A MAC-VRF contains one or more bridge tables (see
terminology), each of which represents a single Broadcast <xref target="RFC7432" format="default" sectionFormat="of" section="
3"/>), each of which represents a single Broadcast
Domain. Domain.
</t> </t>
<t> <t>
In the IRB model (outlined in <xref target="irb"/>), an L3 routing In the IRB model (outlined in <xref target="irb" format="default"/>)
instance has one IRB interface per BD, NOT one per MAC&nbhy;VRF. , an L3 routing
This document does not distinguish between a "Broadcast Domain" instance has one IRB interface per BD, NOT one per MAC-VRF.
and a "Bridge Table", and will use the terms interchangeably (or This document does not distinguish between a Broadcast Domain
and a bridge table; instead, it uses the terms interchangeably (or
will use the acronym "BD" to refer to either). The way the BDs will use the acronym "BD" to refer to either). The way the BDs
are grouped into MAC&nbhy;VRFs is not relevant to the procedures are grouped into MAC-VRFs is not relevant to the procedures
specified in this document. specified in this document.
</t> </t>
<t> <t>
Section 6 of <xref target="RFC7432"/> also defines several <xref target="RFC7432" format="default" sectionFormat="of" section=" 6"/> also defines several
different EVPN service models: different EVPN service models:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t> <t>
In the "vlan&nbhy;based service", each MAC&nbhy;VRF contains In the vlan-based service, each MAC-VRF contains
one "bridge table", where the bridge table corresponds to a one bridge table, where the bridge table corresponds to a
particular Virtual LAN (VLAN). (See section 3 of <xref particular Virtual LAN (VLAN) (see <xref target="RFC7432" format
target="RFC7432"/> for a discussion of this terminology.) ="default" sectionFormat="of" section="3"/>).
Thus, each VLAN is treated as a BD. Thus, each VLAN is treated as a BD.
</t> </t>
</li>
<li>
<t> <t>
In the "vlan bundle service", each MAC&nbhy;VRF contains one In the vlan bundle service, each MAC-VRF contains one
bridge table, where the bridge table corresponds to a set of bridge table, where the bridge table corresponds to a set of
VLANs. Thus a set of VLANs are treated as constituting a VLANs. Thus, a set of VLANs are treated as constituting a
single BD. single BD.
</t> </t>
</li>
<li>
<t> <t>
In the "vlan&nbhy;aware bundle service", each MAC&nbhy;VRF In the vlan-aware bundle service, each MAC-VRF
may contain multiple bridge tables, where each bridge table may contain multiple bridge tables, where each bridge table
corresponds to one BD. If a MAC&nbhy;VRF contains several corresponds to one BD. If a MAC-VRF contains several
bridge tables, then it corresponds to several BDs. bridge tables, then it corresponds to several BDs.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
The procedures in this document are intended to work for all The procedures in this document are intended to work for all
these service models. these service models.
</t> </t>
</section> <!-- evpn_stuff --> </section>
</section> <!-- background --> </section>
<section anchor="need" numbered="true" toc="default">
<section title="Need for EVPN-aware Multicast Procedures" anchor="need"> <name>Need for EVPN-Aware Multicast Procedures</name>
<t> <t>
Inter&nbhy;subnet IP multicast among a set of BDs can be achieved, Inter-subnet IP multicast among a set of BDs can be achieved,
in a non&nbhy;optimal manner, without any specific EVPN in a non-optimal manner, without any specific EVPN
procedures. For instance, if a particular tenant has n BDs among procedures. For instance, if a particular tenant has n BDs among
which he wants to send IP multicast traffic, he can simply attach which it wants to send IP multicast traffic, it can simply attach
a conventional multicast router to all n BDs. Or more generally, a conventional multicast router to all n BDs. Or more generally,
as long as each BD has at least one IP multicast router, and the as long as each BD has at least one IP multicast router, and the
IP multicast routers communicate multicast control information IP multicast routers communicate multicast control information
with each other, conventional IP multicast procedures will work with each other, conventional IP multicast procedures will work
normally, and no special EVPN functionality is needed. normally, and no special EVPN functionality is needed.
</t> </t>
<t> <t>
However, that technique does not provide optimal routing for However, that technique does not provide optimal routing for
multicast. In conventional multicast routing, for a given multicast. In conventional multicast routing, for a given
multicast flow, there is only one multicast router on each BD that multicast flow, there is only one multicast router on each BD that
is permitted to send traffic of that flow to the BD. If that BD is permitted to send traffic of that flow to the BD. If that BD
has receivers for a given flow, but the source of the flow is not has receivers for a given flow, but the source of the flow is not
on that BD, then the flow must pass through that multicast router. on that BD, then the flow must pass through that multicast router.
This leads to the "hair&nbhy;pinning" problem described (for This leads to the hairpinning problem described (for
unicast) in <xref target="irb"/>. unicast) in <xref target="irb" format="default"/>.
</t> </t>
<t> <t>
For example, consider an (S,G) flow that is sourced by a TS S and For example, consider an (S,G) flow that is sourced by a TS S and
needs to be received by TSes R1 and R2. Suppose S is on a segment needs to be received by TSs R1 and R2. Suppose S is on a segment
of BD1, R1 is on a segment of BD2, but both are attached to PE1. of BD1, R1 is on a segment of BD2, but both are attached to PE1.
Suppose also that the tenant has a multicast router, attached to a Also suppose that the tenant has a multicast router attached to a
segment of BD1 and to a segment of BD2. However, the segments to segment of BD1 and to a segment of BD2. However, the segments to
which that router is attached are both attached to PE2. Then the which that router is attached are both attached to PE2. Then, the
flow from S to R would have to follow the path: flow from S to R would have to follow the path:
S-->PE1-->PE2-->Tenant&nbsp;Multicast&nbsp;Router-->PE2-->PE1-->R1. S--&gt;PE1--&gt;PE2--&gt;tenant multicast router--&gt;PE2--&gt;PE1--&g
Obviously, the path S-->PE1-->R would be preferred. t;R1.
Obviously, the path S--&gt;PE1--&gt;R would be preferred.
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure align="center">
<artwork>
+---+ +---+ +---+ +---+
|PE1+----------------------+PE2| |PE1+----------------------+PE2|
+---+-+ +-+---+ +---+-+ +-+---+
| \ \ / / | | \ \ / / |
BD1 BD2 BD3 BD3 BD2 BD1 BD1 BD2 BD3 BD3 BD2 BD1
| | | \ | | | | | \ | |
S R1 R2 router S R1 R2 router
]]></artwork>
</artwork>
</figure>
<t> <t>
Now suppose that there is a second receiver, R2. R2 is attached Now suppose that there is a second receiver, R2. R2 is attached
to a third BD, BD3. However, it is attached to a segment of BD3 to a third BD, BD3. However, it is attached to a segment of BD3
that is attached to PE1. And suppose also that the Tenant that is attached to PE1. And suppose that the tenant
Multicast Router is attached to a segment of BD3 that attaches to multicast router is attached to a segment of BD3 that attaches to
PE2. In this case, the Tenant Multicast Router will make two PE2. In this case, the tenant multicast router will make two
copies of the packet, one for BD2 and one for BD3. PE2 will send copies of the packet, one for BD2 and one for BD3. PE2 will send
both copies back to PE1. Not only is the routing sub-optimal, but both copies back to PE1. Not only is the routing sub-optimal, but
also PE2 sends multiple copies of the same packet to PE1. This is a PE2 also sends multiple copies of the same packet to PE1, which is a
further sub-optimality. further sub-optimality.
</t> </t>
<t> <t>
This is only an example; many more examples of sub-optimal This is only an example; many more examples of sub-optimal
multicast routing can easily be given. To eliminate sub-optimal multicast routing can easily be given. To eliminate sub-optimal
routing and extra copies, it is necessary to have a multicast routing and extra copies, it is necessary to have a multicast
solution that is EVPN-aware, and that can use its knowledge of the solution that is EVPN-aware and that can use its knowledge of the
internal structure of a Tenant Domain to ensure that multicast internal structure of a Tenant Domain to ensure that multicast
traffic gets routed optimally. The procedures in this document traffic gets routed optimally. The procedures in this document
allow us to avoid all such sub-optimalities when routing allow us to avoid all such sub-optimalities when routing
inter&nbhy;subnet multicast traffic within a Tenant Domain. inter-subnet multicast traffic within a Tenant Domain.
</t> </t>
</section> </section>
<section title="Additional Requirements That Must be Met by the Solution" <section anchor="requirements" numbered="true" toc="default">
anchor="requirements"> <name>Additional Requirements That Must Be Met by the Solution</name>
<t> <t>
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:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t> <t>
The solution must integrate well with the procedures specified The solution must integrate well with the procedures specified
in <xref target="RFC9251"/>. That is, an integrated set of in <xref target="RFC9251" format="default"/>. That is, an integrat
procedures must handle both intra&nbhy;subnet multicast and ed set of
inter&nbhy;subnet multicast. procedures must handle both intra-subnet multicast and
inter-subnet multicast.
</t> </t>
</li>
<li>
<t> <t>
With regard to intra&nbhy;subnet multicast, the solution MUST With regard to intra-subnet multicast, the solution <bcp14>MUST</b
maintain the integrity of multicast Ethernet service. This cp14>
maintain the integrity of the multicast Ethernet service. This
means: means:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t> <t>
If a source and a receiver are on the same subnet, the MAC If a source and a receiver are on the same subnet, the MAC
source address (SA) of the multicast frame sent by the Source Address (SA) of the multicast frame sent by the
source will not get rewritten. source will not get rewritten.
</t> </t>
</li>
<li>
<t> <t>
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 processing of the Ethernet payload is done. The IP TTL is
not decremented, the IPv4 header checksum is not changed, no not decremented, the IPv4 header checksum is not changed, no
fragmentation is done, etc. fragmentation is done, etc.
</t> </t>
</list> </li>
</t> </ul>
</li>
<li>
<t> <t>
On the other hand, if a source and a receiver are on different On the other hand, if a source and a receiver are on different
subnets, the frame received by the receiver will not have the subnets, the frame received by the receiver will not have the
MAC Source address of the source, as the frame will appear to MAC Source Address of the source, as the frame will appear to
have come from a multicast router. Also, proper processing of have come from a multicast router. Also, proper processing of
the IP header is done, e.g., TTL decrement by 1, header the IP header is done, e.g., TTL decrements by 1, header
checksum modification, possible fragmentation, etc. checksum modification, possible fragmentation, etc.
</t> </t>
</li>
<li>
<t> <t>
If a Tenant Domain contains several BDs, it MUST be possible If a Tenant Domain contains several BDs, it <bcp14>MUST</bcp14> be possible
for a multicast flow (even when the multicast group address is for a multicast flow (even when the multicast group address is
an "any source multicast" (ASM) address), to have sources in an ASM address) to have sources in
one of those BDs and receivers in one or more of the other one of those BDs and receivers in one or more of the other
BDs, without requiring the presence of any system performing BDs without requiring the presence of any system performing
PIM Rendezvous Point (RP) functions <xref PIM RP functions <xref target="RFC7761" format="default"/>.
target="RFC7761"/>.
</t> </t>
</li>
<li>
<t> <t>
Sometimes a MAC address used by one TS on a particular BD is Sometimes a MAC address used by one TS on a particular BD is
also used by another TS on a different BD. Inter&nbhy;subnet also used by another TS on a different BD. Inter-subnet
routing of multicast traffic MUST NOT make any assumptions routing of multicast traffic <bcp14>MUST NOT</bcp14> make any assu
mptions
about the uniqueness of a MAC address across several BDs. about the uniqueness of a MAC address across several BDs.
</t> </t>
</li>
<li>
<t> <t>
If two EVPN&nbhy;PEs attached to the same Tenant Domain both If two EVPN PEs attached to the same Tenant Domain both
support the OISM procedures, each may receive support the OISM procedures, each may receive
inter&nbhy;subnet multicasts from the other, even if the inter-subnet multicasts from the other, even if the
egress PE is not attached to any segment of the BD from which egress PE is not attached to any segment of the BD from which
the multicast packets are being sourced. It MUST NOT be the multicast packets are being sourced. It <bcp14>MUST NOT</bcp1 4> be
necessary to provision the egress PE with knowledge of the necessary to provision the egress PE with knowledge of the
ingress BD. ingress BD.
</t> </t>
</li>
<li>
<t> <t>
There must be a procedure that allows EVPN&nbhy;PE There must be a procedure that allows EVPN PE
routers supporting OISM procedures to send/receive multicast routers supporting OISM procedures to send/receive multicast
traffic to/from EVPN&nbhy;PE routers that support only <xref traffic to/from EVPN PE routers that support only <xref target="RF
target="RFC7432"/>, but that do not support the OISM C7432" format="default"/> but that does not support the OISM
procedures or even the procedures of <xref procedures or even the procedures of <xref target="RFC9135" format
target="RFC9135"/>. However, when interworking with such ="default"/>. However, when interworking with such
routers (which we call "non&nbhy;OISM PE routers"), optimal routers (which we call "non-OISM PE routers"), optimal
routing may not be achievable. routing may not be achievable.
</t> </t>
</li>
<li>
<t> <t>
It MUST be possible to support scenarios in which multicast It <bcp14>MUST</bcp14> be possible to support scenarios in which m
flows with sources inside a Tenant Domain have "external" ulticast
flows with sources inside a Tenant Domain have external
receivers, i.e., receivers that are outside the domain. It receivers, i.e., receivers that are outside the domain. It
must also be possible to support scenarios where multicast must also be possible to support scenarios where multicast
flows with external sources (sources outside the Tenant flows with external sources (sources outside the Tenant
Domain) have receivers inside the domain. Domain) have receivers inside the domain.
<vspace/> </t>
<vspace/> <t>
This presupposes that unicast routes to multicast sources This presupposes that unicast routes to multicast sources
outside the domain can be distributed to EVPN&nbhy;PEs outside the domain can be distributed to EVPN PEs
attached to the domain, and that unicast routes to multicast attached to the domain and that unicast routes to multicast
sources within the domain can be distributed outside the sources within the domain can be distributed outside the
domain. domain.
<vspace/> </t>
<vspace/> <t>
Of particular importance is the scenario in which the Of particular importance are the scenarios in which the
external sources and/or receivers are reachable via external sources and/or receivers are reachable via
L3VPN/MVPN, and the scenario in which external sources and/or L3VPN/MVPN or via IP/PIM.
receivers are reachable via IP/PIM. </t>
<vspace/> <t>
<vspace/> The solution for external interworking <bcp14>MUST</bcp14> allow f
The solution for external interworking MUST allow for or
deployment scenarios in which EVPN does not need to export a deployment scenarios in which EVPN does not need to export a
host route for every multicast source. host route for every multicast source.
</t> </t>
</li>
<li>
<t> <t>
The solution for external interworking must not presuppose The solution for external interworking must not presuppose
that the same tunneling technology is used within both the that the same tunneling technology is used within both the
EVPN domain and the external domain. For example, MVPN EVPN domain and the external domain. For example, MVPN
interworking must be possible when MVPN is using MPLS P2MP interworking must be possible when MVPN is using MPLS Point-to-Mul
tunneling, and EVPN is using Ingress Replication or VXLAN tipoint (P2MP)
tunneling and when EVPN is using Ingress Replication (IR) or Virtu
al eXtensible Local Area Network (VXLAN)
tunneling. tunneling.
</t> </t>
</li>
<li>
<t> <t>
The solution must not be overly dependent on the details of a The solution must not be overly dependent on the details of a
small set of use cases, but must be adaptable to new use cases small set of use cases but must be adaptable to new use cases
as they arise. (That is, the solution must be robust.) as they arise. (That is, the solution must be robust.)
</t> </t>
</list> </li>
</t> </ul>
</section> </section>
<section title="Model of Operation: Overview" anchor="model_overview"> <section anchor="model_overview" numbered="true" toc="default">
<section title="Control Plane" anchor="cp_overview"> <name>Model of Operation: Overview</name>
<t> <section anchor="cp_overview" numbered="true" toc="default">
<name>Control Plane</name>
<t>
In this section, and in the remainder of this document, we assume In this section, and in the remainder of this document, we assume
the reader is familiar with the procedures of IGMP/MLD (see <xref the reader is familiar with the procedures of IGMP / Multicast Listene
target="RFC3376"/> and <xref target="RFC3810"/>), by which hosts r Discovery (MLD) (see <xref target="RFC3376" format="default"/> and <xref targe
t="RFC3810" format="default"/>), by which hosts
announce their interest in receiving particular multicast flows. announce their interest in receiving particular multicast flows.
</t> </t>
<t> <t>
Consider a Tenant Domain consisting of a set of k BDs: Consider a Tenant Domain consisting of a set of k BDs:
BD1,&nbsp;...,&nbsp;BDk. To support the OISM procedures, each BD1, ..., BDk. To support the OISM procedures, each
Tenant Domain must also be associated with a "Supplementary Tenant Domain must also be associated with a Supplementary
Broadcast Domain" (SBD). An SBD is treated in the control plane Broadcast Domain (SBD). An SBD is treated in the control plane
as a real BD, but it does not have any ACs. The SBD has several as a real BD, but it does not have any ACs. The SBD has several
uses; these will be described later in this document (see <xref uses; these will be described later in this document (see Sections <xr
target="sbd_intro"/> and <xref target="solution"/>). ef target="sbd_intro" format="counter"/> and <xref target="solution" format="cou
</t> nter"/>).
<t> </t>
Each PE that attaches to one or more of the BDs in a given tenant <t>
domain will be provisioned to recognize that those BDs are part of Each PE that attaches to one or more of the BDs in a given Tenant
Domain will be provisioned to recognize that those BDs are part of
the same Tenant Domain. Note that a given PE does not need to be the same Tenant Domain. Note that a given PE does not need to be
configured with all the BDs of a given Tenant Domain. In general, configured with all the BDs of a given Tenant Domain. In general,
a PE will only be attached to a subset of the BDs in a given a PE will only be attached to a subset of the BDs in a given
Tenant Domain, and will be configured only with that subset of Tenant Domain and will be configured only with that subset of
BDs. However, each PE attached to a given Tenant Domain must be BDs. However, each PE attached to a given Tenant Domain must be
configured with the SBD for that Tenant Domain. configured with the SBD for that Tenant Domain.
</t> </t>
<t> <t>
Suppose a particular segment of a particular BD is attached to Suppose a particular segment of a particular BD is attached to
PE1. <xref target="RFC7432"/> specifies that PE1 must originate an PE1. <xref target="RFC7432" format="default"/> specifies that PE1 must
Inclusive Multicast Ethernet Tag (IMET) route for that BD, and originate an
Inclusive Multicast Ethernet Tag (IMET) route for that BD and
that the IMET route must be propagated to all other PEs attached that the IMET route must be propagated to all other PEs attached
to the same BD. If the given segment contains a host that has to the same BD. If the given segment contains a host that has
interest in receiving a particular multicast flow, either an (S,G) interest in receiving a particular multicast flow, either an (S,G)
flow or a (*,G) flow, PE1 will learn of that interest by flow or a (*,G) flow, PE1 will learn of that interest by
participating in the IGMP/MLD snooping procedures, participating in the IGMP/MLD snooping procedures,
as specified in <xref target="RFC4541"/>. In this case: as specified in <xref target="RFC4541" format="default"/>. In
<list style="symbols"> this case:
<t> </t>
<ul spacing="normal">
<li>
<t>
PE1 is interested in receiving the flow; PE1 is interested in receiving the flow;
</t> </t>
<t> </li>
The AC attaching the interested host to PE1 is also said to be <li>
interested in the flow; <t>
</t> the AC attaching the interested host to PE1 is also said to be
<t> interested in the flow; and
The BD containing an AC that is interested in a particular </t>
</li>
<li>
<t>
the BD containing an AC that is interested in a particular
flow is also said to be interested in that flow. flow is also said to be interested in that flow.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
Once PE1 determines that it has an AC that is interested in Once PE1 determines that it has an AC that is interested in
receiving a particular flow or set of flows, it originates one or receiving a particular flow or set of flows, it originates one or
more Selective Multicast Ethernet Tag (SMET) route(s) more Selective Multicast Ethernet Tag (SMET) routes
<xref target="RFC9251"/> to advertise that interest. <xref target="RFC9251" format="default"/> to advertise that int
</t> erest.
<t> </t>
Note that each IMET or SMET route is "for" a particular BD. The <t>
notion of a route being "for" a particular BD is explained in Note that each IMET or SMET route is for a particular BD. The
<xref target="bd_route"/>. notion of a route being for a particular BD is explained in
</t> <xref target="bd_route" format="default"/>.
<t> </t>
When OISM is being supported, the procedures of <xref <t>
target="RFC9251"/>, are modified as follows: When OISM is being supported, the procedures of <xref target="RFC9251"
<list style="symbols"> format="default"/> are modified as follows:
<t> </t>
<ul spacing="normal">
<li>
<t>
The IMET route originated by a particular PE for a particular The IMET route originated by a particular PE for a particular
BD is distributed to all other PEs attached to the Tenant BD is distributed to all other PEs attached to the Tenant
Domain containing that BD, even to those PEs that are not Domain containing that BD, even to those PEs that are not
attached to that particular BD. attached to that particular BD.
</t> </t>
<t> </li>
<li>
<t>
The SMET routes originated by a particular PE are originated The SMET routes originated by a particular PE are originated
on a per-Tenant-Domain basis, rather than on a per-BD basis. on a per-Tenant-Domain basis rather than a per-BD basis.
That is, the SMET routes are considered to be for the Tenant That is, the SMET routes are considered to be for the Tenant
Domain's SBD, rather than for any of its ordinary BDs. These Domain's SBD rather than any of its ordinary BDs. These
SMET routes are distributed to all the PEs attached to the SMET routes are distributed to all the PEs attached to the
Tenant Domain. Tenant Domain.
<vspace/> </t>
<vspace/> <t>
In this way, each PE attached to a given Tenant Domain learns, In this way, each PE attached to a given Tenant Domain learns,
from each other PE attached to the same Tenant Domain, the set from the other PEs attached to the same Tenant Domain, the set
of flows that are of interest to each of those other PEs. of flows that are of interest to each of those other PEs.
</t> </t>
</list> </li>
</t> </ul>
<!-- <t> -->
<!-- OISM PEs MUST follow the procedures of <xref -->
<!-- target="RFC9251"/>. (Though see Sections <xref -->
<!-- target="smet_adv" format="counter"/> and <xref target="external"
-->
<!-- format="counter"/> for an exception.) In this document, we exten
d -->
<!-- the procedures of <xref target="RFC9251"/> so 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 in the -
->
<!-- Tenant Domain. -->
<!-- </t> -->
<!-- <t> -->
<!-- Note that if some PE attached to the Tenant Domain does not -->
<!-- support <xref target="RFC9251"/>, it will be assumed to be -->
<!-- interested in all flows. Whether a particular remote PE supports
-->
<!-- <xref target="RFC9251"/> is determined by the presence of an -->
<!-- "EVPN Multicast Flags Extended Community" attached to its IMET --
>
<!-- routes; this is specified in <xref target="RFC9251"/>. -->
<!-- </t> -->
<t> <t>
An OISM PE that is provisioned with several BDs in the same Tenant An OISM PE that is provisioned with several BDs in the same Tenant
Domain MUST originate an IMET route for each such BD. To indicate Domain <bcp14>MUST</bcp14> originate an IMET route for each such BD.
its support of <xref target="RFC9251"/>, it SHOULD attach the To indicate
its support of <xref target="RFC9251" format="default"/>, it <bcp14>SH
OULD</bcp14> attach the
EVPN Multicast Flags Extended Community EVPN Multicast Flags Extended Community
<!-- (with the RFC9251 flag --> to each such IMET route, but it <bcp14>MUST</bcp14> attach the EC
<!-- set) -->
to each such IMET route, but it MUST attach the EC
<!-- (with the -->
<!-- RFC9251 flag set) -->
to at least one such IMET route. to at least one such IMET route.
</t> </t>
<t> <t>
Suppose PE1 is provisioned with both BD1 and BD2, and is Suppose PE1 is provisioned with both BD1 and BD2 and
provisioned to consider them to be part of the same Tenant Domain. considers them to be part of the same Tenant Domain.
It is possible that PE1 will receive from PE2 both an IMET route It is possible that PE1 will receive both an IMET route
for BD1 and an IMET route for BD2. If either of these IMET routes for BD1 and an IMET route for BD2 from PE2. If either of these IMET r
has the EVPN Multicast Flags Extended Community, PE1 MUST assume outes
that PE2 is supporting the procedures of <xref has the EVPN Multicast Flags Extended Community, PE1 <bcp14>MUST</bcp1
target="RFC9251"/> for ALL BDs in the Tenant Domain. 4> assume
</t> that PE2 is supporting the procedures of <xref target="RFC9251" format
<t> ="default"/> for ALL BDs in the Tenant Domain.
If a PE supports OISM functionality, it indicates that by setting </t>
the "OISM-supported" flag in the Multicast Flags Extended <t>
Community that it attaches to some or all of its IMET routes. An If a PE supports OISM functionality, it indicates that, by setting
OISM PE SHOULD attach this EC with the OISM-supported flag set to the OISM-supported flag in the Multicast Flags Extended
Community, it attaches to some or all of its IMET routes. An
OISM PE <bcp14>SHOULD</bcp14> attach this EC with the OISM-supported f
lag set to
all the IMET routes it originates. However, if PE1 imports IMET all the IMET routes it originates. However, if PE1 imports IMET
routes from PE2, and at least one of PE2's IMET routes indicates routes from PE2, and at least one of PE2's IMET routes indicates
that PE2 is an OISM PE, PE1 MUST assume that PE2 is following OISM that PE2 is an OISM PE, PE1 <bcp14>MUST</bcp14> assume that PE2 is fol lowing OISM
procedures. procedures.
</t> </t>
</section> <!-- control plane overview --> </section>
<section title="Data Plane" anchor="dp_overview"> <section anchor="dp_overview" numbered="true" toc="default">
<t> <name>Data Plane</name>
Suppose PE1 has an AC to a segment in BD1, and PE1 receives from <t>
that AC an (S,G) multicast frame (as defined in <xref Suppose PE1 has an AC to a segment in BD1 and PE1 receives an (S,G) mu
target="terminology"/>). lticast frame from
</t> that AC (as defined in <xref target="terminology" format="default"/>).
<t> </t>
There may be other ACs of PE1 on which TSes have indicated an <t>
There may be other ACs of PE1 on which TSs have indicated an
interest (via IGMP/MLD) in receiving (S,G) multicast packets. PE1 interest (via IGMP/MLD) in receiving (S,G) multicast packets. PE1
is responsible for sending the received multicast packet on those is responsible for sending the received multicast packet on those
ACs. There are two cases to consider: ACs. There are two cases to consider:
<list style="symbols"> </t>
<t> <ul spacing="normal">
Intra-Subnet Forwarding: In this case, an attachment AC with <li>
<t>
Intra-Subnet Forwarding: In this case, an AC with
interest in (S,G) is connected to a segment that is part of interest in (S,G) is connected to a segment that is part of
the source BD, BD1. If the segment is not multi&nbhy;homed, the source BD, BD1. If the segment is not multihomed,
or if PE1 is the Designated Forwarder (DF) (see <xref or if PE1 is the Designated Forwarder (DF) (see <xref target="RFC7
target="RFC7432"/>) for that segment, PE1 sends the multicast 432" format="default"/>) for that segment, PE1 sends the multicast
frame on that AC without changing the MAC SA. The IP header is frame on that AC without changing the MAC SA. The IP header is
not modified at all; in particular, the TTL is not not modified at all; in particular, the TTL is not
decremented. decremented.
</t> </t>
<t> </li>
<li>
<t>
Inter-Subnet Forwarding: An AC with interest in (S,G) is Inter-Subnet Forwarding: An AC with interest in (S,G) is
connected to a segment of BD2, where BD2 is different than connected to a segment of BD2, where BD2 is different than
BD1. If PE1 is the DF for that segment (or if the segment is BD1. If PE1 is the DF for that segment (or if the segment is
not multi&nbhy;homed), PE1 decapsulates the IP multicast not multihomed), PE1 decapsulates the IP multicast
packet, performs any necessary IP processing (including TTL packet, performs any necessary IP processing (including TTL
decrement), then re-encapsulates the packet appropriately for decrement), and then re-encapsulates the packet appropriately for
BD2. PE1 then sends the packet on the AC. Note that after BD2. PE1 then sends the packet on the AC. Note that after
re-encapsulation, the MAC SA will be PE1's MAC address on BD2. re-encapsulation, the MAC SA will be PE1's MAC address on BD2.
The IP TTL will have been decremented by 1. The IP TTL will have been decremented by 1.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
In addition, there may be other PEs that are interested in (S,G) In addition, there may be other PEs that are interested in (S,G)
traffic. Suppose PE2 is such a PE. Then PE1 tunnels a copy of traffic. Suppose PE2 is such a PE. Then, PE1 tunnels a copy of
the IP multicast frame (with its original MAC SA, and with no the IP multicast frame (with its original MAC SA and with no
alteration of the payload's IP header) to PE2. The tunnel alteration of the payload's IP header) to PE2. The tunnel
encapsulation contains information that PE2 can use to associate encapsulation contains information that PE2 can use to associate
the frame with an "apparent source BD". If the actual source BD the frame with an apparent source BD. If the actual source BD
of the frame is BD1, then: of the frame is BD1, then:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
<t>
If PE2 is attached to BD1, the tunnel encapsulation used to If PE2 is attached to BD1, the tunnel encapsulation used to
send the frame to PE2 will cause PE2 to identify BD1 as the send the frame to PE2 will cause PE2 to identify BD1 as the
apparent source BD. apparent source BD.
</t> </t>
<t> </li>
<li>
<t>
If PE2 is not attached to BD1, the tunnel encapsulation used 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 to send the frame to PE2 will cause PE2 to identify the SBD as
the apparent source BD. the apparent source BD.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
Note that the tunnel encapsulation used for a particular BD will Note that the tunnel encapsulation used for a particular BD
have been advertised in an IMET route or S&nbhy;PMSI route <xref will have been advertised in an IMET route or a Selective
target="I-D.ietf-bess-evpn-bum-procedure-updates"/> for that BD. That Provider Multicast Service Interface (S-PMSI) route <xref
route carries a PMSI target="RFC9572" format="default"/> for that BD. That route
Tunnel attribute, which specifies how packets originating from carries a PMSI Tunnel Attribute (PTA), which specifies how packets
that BD are encapsulated. This information enables the PE originating from that BD are encapsulated. This information
receiving a tunneled packet to identify the apparent source BD as enables the PE receiving a tunneled packet to identify the
stated above. See <xref target="adv_tunnels"/> for more details. apparent source BD as stated above. See <xref
</t> target="adv_tunnels" format="default"/> for more details.
<t> </t>
<t>
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).
</t> </t>
<t> <t>
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:
<list style="symbols"> </t>
<t> <ul spacing="normal">
For those ACs that connect PE2 to BD1, the intra&nbhy;subnet <li>
<t>
For those ACs that connect PE2 to BD1, the intra-subnet
forwarding procedure described above is used, except that it forwarding procedure described above is used, except that it
is now PE2, not PE1, carrying out that procedure. Unmodified is now PE2, not PE1, carrying out that procedure. Unmodified
EVPN procedures from <xref target="RFC7432"/> are used to EVPN procedures from <xref target="RFC7432" format="default"/> are
ensure that a packet originating from a multi&nbhy;homed used to
ensure that a packet originating from a multihomed
segment is never sent back to that segment. segment is never sent back to that segment.
</t> </t>
<t> </li>
For those ACs that do not connect to BD1, the inter&nbhy;subnet <li>
<t>
For those ACs that do not connect to BD1, the inter-subnet
forwarding procedure described above is used, except that it is forwarding procedure described above is used, except that it is
now PE2, not PE1, carrying out that procedure. now PE2, not PE1, carrying out that procedure.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
If the tunnel encapsulation identifies the apparent source BD as If the tunnel encapsulation identifies the apparent source BD as
the SBD, PE2 applies the inter&nbhy;subnet forwarding procedures the SBD, PE2 applies the inter-subnet forwarding procedures
described above to all of its ACs that have interest in the flow. described above to all of its ACs that have interest in the flow.
</t> </t>
<t> <t>
These procedures ensure that an IP multicast frame travels from its These procedures ensure that an IP multicast frame travels from its
ingress PE to all egress PEs that are interested in receiving ingress PE to all egress PEs that are interested in receiving
it. While in transit, the frame retains its original MAC SA, and it. While in transit, the frame retains its original MAC SA, and
the payload of the frame retains its original IP header. Note that the payload of the frame retains its original IP header. Note that
in all cases, when an IP multicast packet is sent from one BD to in all cases, when an IP multicast packet is sent from one BD to
another, these procedures cause its TTL to be decremented by 1. another, these procedures cause its TTL to be decremented by 1.
</t> </t>
<t> <t>
So far we have assumed that an IP multicast packet arrives at its So far, we have assumed that an IP multicast packet arrives at its
ingress PE over an AC that belongs to one of the BDs in a given ingress PE over an AC that belongs to one of the BDs in a given
Tenant Domain. However, it is possible for a packet to arrive at Tenant Domain. However, it is possible for a packet to arrive at
its ingress PE in other ways. Since an EVPN&nbhy;PE supporting IRB its ingress PE in other ways. Since an EVPN PE supporting IRB
has an IP&nbhy;VRF, it is possible that the IP&nbhy;VRF will have a has an IP-VRF, it is possible that the IP-VRF will have a
"VRF interface" that is not an IRB interface. For example, there VRF interface that is not an IRB interface. For example, there
might be a VRF interface that is actually a physical link to an might be a VRF interface that is actually a physical link to an
external Ethernet switch, or to a directly attached host, or to a external Ethernet switch, a directly attached host, or a
router. When an EVPN&nbhy;PE, say PE1, receives a packet through router. When an EVPN PE, say PE1, receives a packet through
such means, we will say that the packet has an "external" source such means, we will say that the packet has an external source
(i.e., a source "outside the Tenant Domain"). There are also other (i.e., a source outside the Tenant Domain). There are also other
scenarios in which a multicast packet might have an external scenarios in which a multicast packet might have an external
source, e.g., it might arrive over an MVPN tunnel from an L3VPN source, e.g., it might arrive over an MVPN tunnel from an L3VPN
PE. In such cases, we will still refer to PE1 as the "ingress PE. In such cases, we will still refer to PE1 as the "ingress
EVPN&nbhy;PE". EVPN PE".
</t> </t>
<t> <t>
When an EVPN&nbhy;PE, say PE1, receives an externally sourced When an EVPN PE, say PE1, receives an externally sourced
multicast packet, and there are receivers for that packet inside multicast packet, and there are receivers for that packet inside
the Tenant Domain, it does the following: the Tenant Domain, it does the following:
<list style="symbols"> </t>
<t> <ul spacing="normal">
Suppose PE1 has an AC in BD1 that has interest in (S,G). Then <li>
<t>
Suppose PE1 has an AC in BD1 that has interest in (S,G). Then,
PE1 encapsulates the packet for BD1, filling in the MAC SA PE1 encapsulates the packet for BD1, filling in the MAC SA
field with PE1's own MAC address on BD1. It sends the field with PE1's own MAC address on BD1. It sends the
resulting frame on the AC. resulting frame on the AC.
</t> </t>
<t> </li>
Suppose some other EVPN&nbhy;PE, say PE2, has interest in <li>
<t>
Suppose some other EVPN PE, say PE2, has interest in
(S,G). PE1 encapsulates the packet for Ethernet, filling in (S,G). PE1 encapsulates the packet for Ethernet, filling in
the MAC SA field with PE1's own MAC address on the SBD. PE1 the MAC SA field with PE1's own MAC address on the SBD. PE1
then tunnels the packet to PE2. The tunnel encapsulation will then tunnels the packet to PE2. The tunnel encapsulation will
identify the apparent source BD as the SBD. Since the apparent identify the apparent source BD as the SBD. Since the apparent
source BD is the SBD, PE2 will know to treat the frame as an source BD is the SBD, PE2 will know to treat the frame as an
inter&nbhy;subnet multicast. inter-subnet multicast.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
When ingress replication is used to transmit IP multicast frames When IR is used to transmit IP multicast frames
from an ingress EVPN&nbhy;PE to a set of egress PEs, then from an ingress EVPN PE to a set of egress PEs, then
the ingress PE has to send multiple copies of the frame. Each copy the ingress PE has to send multiple copies of the frame. Each copy
is the original Ethernet frame; decapsulation and IP processing is the original Ethernet frame; decapsulation and IP processing
take place only at the egress PE. take place only at the egress PE.
</t> </t>
<t> <t>
If a Point-to-Multipoint (P2MP) tree or BIER <xref If a P2MP tree or Bit Index Explicit Replication (BIER) <xref target="
target="I-D.ietf-bier-evpn"/> is used to transmit an IP multicast fram RFC9624" format="default"/> is used to transmit an IP multicast frame
e
from an ingress PE to a set of egress PEs, then the ingress PE from an ingress PE to a set of egress PEs, then the ingress PE
only has to send one copy of the frame to each of its next hops. only has to send one copy of the frame to each of its next hops.
Again, each egress PE receives the original frame and does any Again, each egress PE receives the original frame and does any
necessary IP processing. necessary IP processing.
</t> </t>
</section> <!-- dp_overview --> </section>
</section> <!-- model_overview --> </section>
</section> <!-- Introduction --> </section>
<section anchor="model_detail" numbered="true" toc="default">
<section title="Detailed Model of Operation" <name>Detailed Model of Operation</name>
anchor="model_detail">
<t> <t>
The model described in <xref target="dp_overview"/> can be expressed The model described in <xref target="dp_overview" format="default"/> can
more precisely using the notion of "IRB interface" (see <xref be expressed
target="irb"/>). For a given Tenant Domain: more precisely using the notion of IRB interface (see <xref target="irb"
<list style="symbols"> format="default"/>). For a given Tenant Domain:
</t>
<ul spacing="normal">
<li>
<t> <t>
A given PE has one IRB interface for each BD to which it is attached . 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 This IRB interface connects L3 routing to that BD. When
IP multicast packets are sent or received on the IRB interfaces, IP multicast packets are sent or received on the IRB interfaces,
the semantics of the interface is modified from the semantics the semantics of the interface are modified from the semantics
described in <xref target="irb"/>. See <xref described in <xref target="irb" format="default"/>. See <xref targe
target="ingress_irb_use"/> for the details of the modification. t="ingress_irb_use" format="default"/> for the details of the modification.
</t> </t>
</li>
<li>
<t> <t>
Each PE also has an IRB interface that connects L3 routing to Each PE also has an IRB interface that connects L3 routing to
the SBD. The semantics of this interface is different than the the SBD. The semantics of this interface is different than the
semantics of the IRB interface to the real BDs. See <xref semantics of the IRB interface to the real BDs. See <xref target="in
target="ingress_irb_use"/>. gress_irb_use" format="default"/>.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
In this section we assume that PIM is not enabled on the IRB In this section, we assume that PIM is not enabled on the IRB
interfaces. In general, it is not necessary to enable PIM on the interfaces. In general, it is not necessary to enable PIM on the
IRB interfaces unless there are PIM routers on one of the Tenant IRB interfaces unless there are PIM routers on one of the Tenant
Domain's BDs, or unless there is some other scenario requiring a Domain's BDs or there is some other scenario requiring a
Tenant Domain's L3 routing instance to become a PIM adjacency of Tenant Domain's L3 routing instance to become a PIM adjacency of
some other system. These cases will be discussed in <xref some other system. These cases will be discussed in <xref target="pim"
target="pim"/>. format="default"/>.
</t> </t>
<section anchor="sbd_intro" numbered="true" toc="default">
<section title="Supplementary Broadcast Domain" anchor="sbd_intro"> <name>Supplementary Broadcast Domain</name>
<t> <t>
Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and Suppose a given Tenant Domain contains three BDs (BD1, BD2, and BD3) and
two PEs (PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches two PEs (PE1 and PE2). PE1 attaches to BD1 and BD2, while PE2 attaches
to BD2 and BD3. to BD2 and BD3.
</t> </t>
<t> <t>
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. An 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&nbhy;RT". "SBD-RT".
</t> </t>
<t> <t>
A Tenant Domain is also configured with an IP&nbhy;VRF <xref A Tenant Domain is also configured with an IP-VRF <xref target="RFC9135"
target="RFC9135"/>, and the IP&nbhy;VRF is associated with an RT. format="default"/>, and the IP-VRF is associated with an RT.
This RT MAY be the same as the SBD&nbhy;RT. This RT <bcp14>MAY</bcp14> be the same as the SBD-RT.
</t> </t>
<t> <t>
Suppose an (S,G) multicast frame originating on BD1 has a receiver 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 on 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, BD1 to BD3 even though its ingress PE is not configured for BD3
and/or its egress PE is not configured for BD1. and/or its egress PE is not configured for BD1.
</t> </t>
<t> <t>
EVPN supports service models in which a given EVPN Instance (EVI) EVPN supports service models in which a given EVI
can contain only one BD. It also supports service models in which a can contain only one BD. It also supports service models in which a
given EVI can contain multiple BDs. No matter which service model given EVI can contain multiple BDs. No matter which service model
is being used for a particular tenant, it is highly RECOMMENDED that is being used for a particular tenant, it is highly <bcp14>RECOMMENDED</ bcp14> that
an EVI containing only the SBD be provisioned for that tenant. an EVI containing only the SBD be provisioned for that tenant.
</t> </t>
<t> <t>
If, for some reason, it is not feasible to provision an EVI that If, for some reason, it is not feasible to provision an EVI that
contains only the SBD, it is possible to put the SBD in an EVI that contains only the SBD, it is possible to put the SBD in an EVI that
contains other BDs. However, in that case, the SBD&nbhy;RT MUST be contains other BDs. However, in that case, the SBD-RT <bcp14>MUST</bcp1
different than the RT associated with any other BD. Otherwise the 4> be
procedures of this document (as detailed in Sections <xref different than the RT associated with any other BD. Otherwise, the
target="bd_route" format="counter"/> and <xref target="sbd_rts" procedures of this document (as detailed in Sections <xref target="bd_ro
format="counter"/>) will not produce correct results. ute" format="counter"/> and <xref target="sbd_rts" format="counter"/>) will not
</t> produce correct results.
</section> <!-- sbd --> </t>
</section>
<section title="Detecting When a Route is For/From a Particular BD" <section anchor="bd_route" numbered="true" toc="default">
anchor="bd_route"> <name>Detecting When a Route is for/from a Particular BD</name>
<t> <t>
In this document, we frequently say that a particular multicast In this document, we frequently say that a particular multicast
route is "from" a particular BD, or is "for" a particular BD, route is "from" or "for" a particular BD or is "related to" or
or is "related to" a particular BD, or "is "associated with" a particular BD. These terms are used
associated with" a particular BD. These terms are used
interchangeably. Subsequent sections of this document explain when interchangeably. Subsequent sections of this document explain when
various routes must be originated for particular BDs. In this various routes must be originated for particular BDs. In this
section, we explain how the PE originating a route marks the route section, we explain how the PE originating a route marks the route
to indicate which BD it is for. We also explain how a PE to indicate which BD it is for. We also explain how a PE
receiving the route determines which BD the route is for. receiving the route determines which BD the route is for.
</t> </t>
<t> <t>
In EVPN, each BD is assigned a Route Target (RT). An RT is a BGP In EVPN, each BD is assigned an RT. An RT is a BGP
extended community that can be attached to the BGP routes used by Extended Community that can be attached to the BGP routes used by
the EVPN control plane. In some EVPN service models, each BD is the EVPN control plane. In some EVPN service models, each BD is
assigned a unique RT. In other service models, a set of BDs (all in assigned a unique RT. In other service models, a set of BDs (all in
the same EVI) may be assigned the same RT. The RT that is assigned the same EVI) may be assigned the same RT. The RT that is assigned
to the SBD is called the "SBD&nbhy;RT". to the SBD is called the "SBD-RT".
</t> </t>
<t> <t>
In those service models that allow a set of BDs to share a single In those service models that allow a set of BDs to share a single
RT, each BD is assigned a non&nbhy;zero Tag ID. The Tag ID appears RT, each BD is assigned a non-zero Tag ID. The Tag ID appears
in the Network Layer Reachability Information (NLRI) of many of the in the Network Layer Reachability Information (NLRI) of many of the
BGP routes that are used by the EVPN control plane. BGP routes that are used by the EVPN control plane.
</t> </t>
<t> <t>
A given route may be for the SBD, or for an "ordinary BD" (a BD A given route may be for the SBD or an ordinary BD (a BD
that is not the SBD). An RT that has been assigned to an ordinary that is not the SBD). An RT that has been assigned to an ordinary
BD will be known as an "ordinary BD&nbhy;RT". BD will be known as an "ordinary BD-RT".
</t> </t>
<t> <t>
When constructing an IMET, SMET, S&nbhy;PMSI, or Leaf <xref target="I-D. When constructing an IMET, SMET, S-PMSI, or Leaf <xref target="RFC9572"
ietf-bess-evpn-bum-procedure-updates"/> route that is for a given BD, format="default"/> route that is for a given BD,
the following rules apply: the following rules apply:
<list style="symbols"> </t>
<t> <ul spacing="normal">
If the route is for an ordinary BD, say BD1, then <li>
<list style="symbols"> <t>
<t> If the route is for an ordinary BD, say BD1, then:
the route MUST carry the ordinary BD&nbhy;RT associated with </t>
BD1, and <ul spacing="normal">
</t> <li>
<t> <t>
the route MUST NOT carry any RT that is associated with an the route <bcp14>MUST</bcp14> carry the ordinary BD-RT associate
d with
BD1 and
</t>
</li>
<li>
<t>
the route <bcp14>MUST NOT</bcp14> carry any RT that is associate
d with an
ordinary BD other than BD1. ordinary BD other than BD1.
</t> </t>
</list> </li>
</t> </ul>
<t> </li>
If the route is for the SBD, the route MUST carry the SBD&nbhy;RT, <li>
and MUST NOT carry any RT that is associated with any other BD. <t>
</t> If the route is for the SBD, the route <bcp14>MUST</bcp14> carry the
<t> SBD-RT
As detailed in subsequent sections, under certain circumstances and <bcp14>MUST NOT</bcp14> carry any RT that is associated with any
other BD.
</t>
</li>
<li>
<t>
As detailed in subsequent sections, under certain circumstances,
a route that is for BD1 may carry both the RT of BD1 and also a route that is for BD1 may carry both the RT of BD1 and also
the SBD&nbhy;RT. the SBD-RT.
</t> </t>
</list> </li>
</t> </ul>
<t>The IMET route for the SBD MUST carry a Multicast Flags Extended <t>The IMET route for the SBD <bcp14>MUST</bcp14> carry a Multicast Flag
Community, in which an "OISM SBD" flag is set. s Extended
</t> Community in which an OISM SBD flag is set.
<t>The IMET route for a BD other than the SBD SHOULD carry an EVI-RT EC </t>
as defined in <xref target="RFC9251"/>. The EC is constructed <t>The IMET route for a BD other than the SBD <bcp14>SHOULD</bcp14> carr
from the SBD&nbhy;RT, to indicate the BD's corresponding SBD. y an EVI-RT EC
as defined in <xref target="RFC9251" format="default"/>. The EC is cons
tructed
from the SBD-RT to indicate the BD's corresponding SBD.
This allows all PEs to check that they have consistent SBD provisioning This allows all PEs to check that they have consistent SBD provisioning
and allow an Assisted Replication (AR) replicator to automatically and allows an Assisted Replication (AR) replicator to automatically
determine a BD's determine a BD's corresponding SBD without any provisioning, as explain
corresponding SBD without any provisioning, as explained in ed in
<xref target="SBD-matching"/>. <xref target="SBD-matching" format="default"/>.
</t> </t>
<t> <t>
When receiving an IMET, SMET, S&nbhy;PMSI, or Leaf route, it is necessar When receiving an IMET, SMET, S-PMSI, or Leaf route, it is necessary
y
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.
</t> </t>
<t> <t>
When one of the error cases is detected, the route MUST be regarded When one of the error cases is detected, the route <bcp14>MUST</bcp14> b
as a malformed route, and the "treat-as-withdraw" procedure of <xref e regarded
target="RFC7606"/> MUST be applied. Note that these error as a malformed route, and the treat-as-withdraw procedure of <xref targe
t="RFC7606" format="default"/> <bcp14>MUST</bcp14> be applied. Note that these
error
cases are only detectable by EVPN procedures at the receiving PE; cases are only detectable by EVPN procedures at the receiving PE;
BGP procedures at intermediate nodes will generally not detect the BGP 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 <bcp14>SHOULD NOT</bcp14> a ttempt to
do so. do so.
</t> </t>
<t> <ol spacing="normal" type="Case %d:"><li>
<list style="format Case %d:"> <t>
<t>
The receiving PE recognizes more than one of the route's RTs as The receiving PE recognizes more than one of the route's RTs as
being an SBD&nbhy;RT (i.e., the route carries SBD&nbhy;RTs of being an SBD-RT (i.e., the route carries SBD-RTs of
more than one Tenant Domain). more than one Tenant Domain).
<vspace/> </t>
<vspace/> <t>
This is an error case; the route has not been properly This is an error case; the route has not been properly
constructed. constructed.
</t> </t>
<t> </li>
<li>
<t>
The receiving PE recognizes one of the route's RTs as being The receiving PE recognizes one of the route's RTs as being
associated with an ordinary BD, and recognizes one of the associated with an ordinary BD and recognizes one of the
route's other RTs as being associated with a different ordinary route's other RTs as being associated with a different ordinary
BD. BD.
<vspace/> </t>
<vspace/> <t>
This is an error case; the route has not been properly This is an error case; the route has not been properly
constructed. constructed.
</t> </t>
<t> </li>
<li>
<t>
The receiving PE recognizes one of the route's RTs as being The receiving PE recognizes one of the route's RTs as being
associated with an ordinary BD in a particular Tenant Domain, associated with an ordinary BD in a particular Tenant Domain
and recognizes another of the route's RTs as being associated and recognizes another of the route's RTs as being associated
with the SBD of a different Tenant Domain. with the SBD of a different Tenant Domain.
<vspace/> </t>
<vspace/> <t>
This is an error case; the route has not been properly This is an error case; the route has not been properly
constructed. constructed.
</t> </t>
<t> </li>
<li>
<t>
The receiving PE does not recognize any of the route's RTs as The receiving PE does not recognize any of the route's RTs as
being associated with an ordinary BD in any of its tenant being associated with an ordinary BD in any of its Tenant
domains, but does recognize one of the RTs as the SBD&nbhy;RT Domains but does recognize one of the RTs as the SBD-RT
of one of its Tenant Domains. of one of its Tenant Domains.
<vspace/> </t>
<vspace/> <t>
In this case, the receiving PE associates the route with the SBD of In this case, the receiving PE associates the route with the SBD of
that Tenant Domain. This association is made even if the Tag ID that Tenant Domain. This association is made even if the Tag ID
field of the route's NLRI is not the Tag ID of the SBD. field of the route's NLRI is not the Tag ID of the SBD.
<vspace/> </t>
<vspace/> <t>
This is a normal use case where either (a) the route is for a BD This is a normal use case where either (a) the route is for a BD
to which the receiving PE is not attached, or (b) the route is to which the receiving PE is not attached or (b) the route is
for the SBD. In either case, the receiving PE associates the for the SBD. In either case, the receiving PE associates the
route with the SBD. route with the SBD.
</t> </t>
<t> </li>
<li>
<t>
The receiving PE recognizes exactly one of the RTs as an The receiving PE recognizes exactly one of the RTs as an
ordinary BD&nbhy;RT that is associated with one of the PE's ordinary BD-RT that is associated with one of the PE's
EVIs, say EVI&nbhy;1. The receiving PE also recognizes one of EVIs, say EVI-1. The receiving PE also recognizes one of
the RTs as being the SBD&nbhy;RT of the Tenant Domain containing the RTs as being the SBD-RT of the Tenant Domain containing
EVI&nbhy;1. EVI-1.
<vspace/> </t>
<vspace/> <t>
In this case, the route is associated with the BD in EVI&nbhy;1 In this case, the route is associated with the BD in EVI-1
that is identified (in the context of EVI&nbhy;1) by the Tag ID that is identified (in the context of EVI-1) by the Tag ID
field of the route's NLRI. (If EVI&nbhy;1 contains only a field of the route's NLRI. (If EVI-1 contains only a
single BD, the Tag ID is likely to be zero.) single BD, the Tag ID is likely to be zero.)
<vspace/> </t>
<vspace/> <t>
This is the case where the route is for a BD to which the This is the case where the route is for a BD to which the
receiving PE is attached, but the route also carries the receiving PE is attached, but the route also carries the
SBD&nbhy;RT. In this case, the receiving PE associates the route SBD-RT. In this case, the receiving PE associates the route
with the ordinary BD, not with the SBD. with the ordinary BD, not with the SBD.
</t> </t>
</list> </li>
</t> </ol>
<t> <t>
N.B.: According to the above rules, the mapping from BD to RT is a Note that according to the above rules, the mapping from BD to RT is a
many-to-one or one-to-one mapping. A route that an EVPN&nbhy;PE many-to-one or one-to-one mapping. A route that an EVPN PE
originates for a particular BD carries that BD's RT, and an originates for a particular BD carries that BD's RT, and an
EVPN&nbhy;PE that receives the route associates it with a BD as EVPN PE that receives the route associates it with a BD as
described above. However, RTs are not used only to help identify described above. However, RTs are not used only to help identify
the BD to which a route belongs; they may also used by BGP to the BD to which a route belongs; they may also be used by BGP to
determine the path along which the route is distributed, and to determine the path along which the route is distributed and to
determine which PEs receive the route. There may be cases where it determine which PEs receive the route. There may be cases where it
is desirable to originate a route for a particular BD, but have is desirable to originate a route for a particular BD but have
that route distributed to only some of the EVPN&nbhy;PEs attached to that route distributed to only some of the EVPN PEs attached to
that BD. Or one might want the route distributed to some that BD. Or one might want the route distributed to some
intermediate set of systems, where it might be modified or replaced intermediate set of systems, where it might be modified or replaced
before being propagated further. Such situations are outside the before being propagated further. Such situations are outside the
scope of this document. scope of this document.
</t> </t>
<t> <t>
Additionally, there may be situations where it is desirable to Additionally, there may be situations where it is desirable to
exchange routes among two or more different Tenant Domains ("EVPN exchange routes among two or more different Tenant Domains (EVPN
Extranet"). Such situations are outside the scope of this document. Extranet). Such situations are outside the scope of this document.
</t> </t>
<!-- <t> -->
<!-- A route is for a particular BD if it carries the RT that has been -
->
<!-- assigned to that BD, and its NLRI contains the Tag ID that has been
-->
<!-- assigned to that BD. -->
<!-- </t> -->
<!-- <t> -->
<!-- Note that a route that is for a particular BD may also carry -->
<!-- additional RTs. -->
<!-- </t> -->
</section> </section>
<section anchor="ingress_irb_use" numbered="true" toc="default">
<section title="Use of IRB Interfaces at Ingress PE" <name>Use of IRB Interfaces at Ingress PE</name>
anchor="ingress_irb_use"> <t>
<t>
When an (S,G) multicast frame is received from an AC belonging to a When an (S,G) multicast frame is received from an AC belonging to a
particular BD, say BD1: particular BD, say BD1:
<list style="format %d."> </t>
<t anchor="inter-PE"> <ol spacing="normal" type="1"><li anchor="inter-PE">
The frame is sent unchanged to other EVPN&nbhy;PEs that are <t>
The frame is sent unchanged to other EVPN PEs that are
interested in (S,G) traffic. The encapsulation used to send the interested in (S,G) traffic. The encapsulation used to send the
frame to the other EVPN&nbhy;PEs depends on the tunnel type frame to the other EVPN PEs depends on the tunnel type
being used for multicast transmission. (For our purposes, we being used for multicast transmission. (For our purposes, we
consider Ingress Replication (IR), Assisted Replication (AR) and consider IR, AR, and
BIER to be "tunnel types", even though IR, AR and BIER do not BIER to be tunnel types, even though IR, AR, and BIER do not
actually use P2MP tunnels.) At the egress PE, the apparent actually use P2MP tunnels.) At the egress PE, the apparent
source BD of the frame can be inferred from the tunnel source BD of the frame can be inferred from the tunnel
encapsulation. If the egress PE is not attached to the actual encapsulation. If the egress PE is not attached to the actual
source BD, it will infer that the apparent source BD is the SBD. source BD, it will infer that the apparent source BD is the SBD.
<vspace/> </t>
<vspace/> <t>
Note that the the inter&nbhy;PE transmission of a multicast Note that the inter-PE transmission of a multicast
frame among EVPN&nbhy;PEs of the same Tenant Domain does NOT frame among EVPN PEs of the same Tenant Domain does NOT
involve the IRB interfaces, as long as the multicast frame was involve the IRB interfaces as long as the multicast frame was
received over an AC attached to one of the Tenant Domain's BDs. received over an AC attached to one of the Tenant Domain's BDs.
</t> </t>
<t anchor="up_IRB"> </li>
<li anchor="up_IRB">
<t>
The frame is also sent up the IRB interface that attaches BD1 to The frame is also sent up the IRB interface that attaches BD1 to
the Tenant Domain's L3 routing instance in this PE. That is, the Tenant Domain's L3 routing instance in this PE. That is,
the L3 routing instance, behaving as if it were a multicast the L3 routing instance, behaving as if it were a multicast
router, receives the IP multicast frames that arrive at the PE router, receives the IP multicast frames that arrive at the PE
from its local ACs. The L3 routing instance decapsulates the from its local ACs. The L3 routing instance decapsulates the
frame's payload to extract the IP multicast packet, decrements frame's payload to extract the IP multicast packet, decrements
the IP TTL, adjusts the header checksum, and does any other the IP TTL, adjusts the header checksum, and does any other
necessary IP processing (e.g., fragmentation). necessary IP processing (e.g., fragmentation).
</t> </t>
<t anchor="down_IRB"> </li>
<li anchor="down_IRB">
<t>
The L3 routing instance keeps track of which BDs have local 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,
reachable via a local AC, that has expressed interest in (S,G) reachable via a local AC, that has expressed interest in (S,G)
traffic.) If the L3 routing instance has an IRB interface to traffic.) If the L3 routing instance has an IRB interface to
BD2, and it knows that BD2 has a LOCAL receiver interested in BD2, and it knows that BD2 has a LOCAL receiver interested in
(S,G) traffic, it encapsulates the packet in an Ethernet header (S,G) traffic, it encapsulates the packet in an Ethernet header
for BD2, putting its own MAC address in the MAC SA field. Then for BD2, putting its own MAC address in the MAC SA field. Then,
it sends the packet down the IRB interface to BD2. it sends the packet down the IRB interface to BD2.
</t> </t>
</list> </li>
</t> </ol>
<t> <t>
If a packet is sent from the L3 routing instance to a particular If a packet is sent from the L3 routing instance to a particular
BD via the IRB interface (step <xref target="down_IRB" BD via the IRB interface (step <xref target="down_IRB" format="counter"/
format="counter"/> in the above list), and if the BD in question is > in the above list), and if the BD in question is
NOT the SBD, the packet is sent ONLY to LOCAL ACs of that BD. If NOT the SBD, the packet is sent ONLY to LOCAL ACs of that BD. If
the packet needs to go to other PEs, it has already been sent to the packet needs to go to other PEs, it has already been sent to
them in step <xref target="inter-PE" format="counter"/>. Note that them in step <xref target="inter-PE" format="counter"/>. Note that
this is a change in the IRB interface semantics from what is this is a change in the IRB interface semantics from what is
described in <xref target="RFC9135"/> and <xref target="IRB"/>. described in <xref target="RFC9135" format="default"/> and <xref target=
</t> "IRB" format="default"/>.
<t> </t>
If a given locally attached segment is multi-homed, existing EVPN <t>
If a given locally attached segment is multihomed, existing EVPN
procedures ensure that a packet is not sent by a given PE to that procedures ensure that a packet is not sent by a given PE to that
segment unless the PE is the DF for that segment. Those procedures segment unless the PE is the DF for that segment. Those procedures
also ensure that a packet is never sent by a PE to its segment of also ensure that a packet is never sent by a PE to its segment of
origin. Thus EVPN segment multi-homing is fully supported; origin. Thus, EVPN segment multihoming is fully supported;
duplicate delivery to a segment or looping on a segment are thereby duplicate delivery to a segment or looping on a segment are thereby
prevented, without the need for any new procedures to be defined in prevented without the need for any new procedures to be defined in
this document. this document.
</t> </t>
<t> <t>
What if an IP multicast packet is received from outside the tenant What if an IP multicast packet is received from outside the Tenant
domain? For instance, perhaps PE1's IP&nbhy;VRF for a particular Domain? For instance, perhaps PE1's IP-VRF for a particular
tenant domain also has a physical interface leading to an external Tenant Domain also has a physical interface leading to an external
switch, host, or router, and PE1 receives an IP multicast packet or switch, host, or router and PE1 receives an IP multicast packet or
frame on that interface. Or perhaps the packet is from an L3VPN, or frame on that interface, or perhaps the packet is from an L3VPN or
a different EVPN Tenant Domain. a different EVPN Tenant Domain.
</t> </t>
<t> <t>
Such a packet is first processed by the L3 routing instance, which Such a packet is first processed by the L3 routing instance, which
decrements TTL and does any other necessary IP processing. Then the decrements TTL and does any other necessary IP processing. Then, the
packet is sent into the Tenant Domain by sending it down the IRB packet is sent into the Tenant Domain by sending it down the IRB
interface to the SBD of that Tenant Domain. This requires interface to the SBD of that Tenant Domain. This requires
encapsulating the packet in an Ethernet header. The MAC SA field encapsulating the packet in an Ethernet header. The MAC SA field
will contain the PE's own MAC on the SBD. will contain the PE's own MAC on the SBD.
</t> </t>
<t> <t>
An IP multicast packet sent by the L3 routing instance down the IRB An IP multicast packet sent by the L3 routing instance down the IRB
interface to the SBD is treated as if it had arrived from a local interface to the SBD is treated as if it had arrived from a local
AC, and steps <xref target="inter-PE" format="counter"/>&nbhy;<xref AC, and steps <xref target="inter-PE" format="counter"/>-<xref target="d
target="down_IRB" format="counter"/> are applied. Note that the own_IRB" format="counter"/> are applied. Note that the
semantics of sending a packet down the IRB interface to the SBD are semantics of sending a packet down the IRB interface to the SBD are
thus slightly different than the semantics of sending a packet down thus slightly different than the semantics of sending a packet down
other IRB interfaces. IP multicast packets sent down the SBD's IRB other IRB interfaces. IP multicast packets sent down the SBD's IRB
interface may be distributed to other PEs, but IP multicast packets interface may be distributed to other PEs, but IP multicast packets
sent down other IRB interfaces are distributed only to local ACs. sent down other IRB interfaces are distributed only to local ACs.
</t> </t>
<t> <t>
If a PE sends a link&nbhy;local multicast packet down the SBD IRB If a PE sends a link-local multicast packet down the SBD IRB
interface, that packet will be distributed (as an Ethernet frame) to interface, that packet will be distributed (as an Ethernet frame) to
other PEs of the Tenant Domain, but will not appear on any of the other PEs of the Tenant Domain but will not appear on any of the
actual BDs. actual BDs.
</t> </t>
</section> <!-- ingress_irb_use --> </section>
<section title="Use of IRB Interfaces at an Egress PE" <section anchor="egress_irb_use" numbered="true" toc="default">
anchor="egress_irb_use"> <name>Use of IRB Interfaces at an Egress PE</name>
<t> <t>
Suppose an egress EVPN&nbhy;PE receives an (S,G) multicast frame Suppose an egress EVPN PE receives an (S,G) multicast frame
from the frame's ingress EVPN&nbhy;PE. As described above, the from the frame's ingress EVPN PE. As described above, the
packet will arrive as an Ethernet frame over a tunnel from the packet will arrive as an Ethernet frame over a tunnel from the
ingress PE, and the tunnel encapsulation will identify the source BD ingress PE, and the tunnel encapsulation will identify the source BD
of the Ethernet frame. of the Ethernet frame.
</t> </t>
<t> <t>
We define the notion of the frame's "apparent source BD" as follows. We define the notion of the frame's apparent source BD as follows.
If the egress PE is attached to the actual source BD, the actual If the egress PE is attached to the actual source BD, the actual
source BD is the apparent source BD. If the egress PE is not source BD is the apparent source BD. If the egress PE is not
attached to the actual source BD, the SBD is the apparent source BD. attached to the actual source BD, the SBD is the apparent source BD.
</t> </t>
<t> <t>
The egress PE now takes the following steps: The egress PE now takes the following steps:
<list style="format %d."> </t>
<t> <ol spacing="normal" type="1"><li>
<t>
If the egress PE has ACs belonging to the apparent source BD of If the egress PE has ACs belonging to the apparent source BD of
the frame, it sends the frame unchanged to any ACs of that BD the frame, it sends the frame unchanged to any ACs of that BD
that have interest in (S,G) packets. The MAC SA of the frame is that have interest in (S,G) packets. The MAC SA of the frame is
not modified, and the IP header of the frame's payload is not not modified, and the IP header of the frame's payload is not
modified in any way. modified in any way.
</t> </t>
<t> </li>
<li>
<t>
The frame is also sent to the L3 routing instance by being sent The frame is also sent to the L3 routing instance by being sent
up the IRB interface that attaches the L3 routing instance to up the IRB interface that attaches the L3 routing instance to
the apparent source BD. Steps <xref target="up_IRB" the apparent source BD. Steps <xref target="up_IRB" format="counter
format="counter"/> and <xref target="down_IRB" "/> and <xref target="down_IRB" format="counter"/> listed in <xref target="ingre
format="counter"/> of <xref target="ingress_irb_use"/> are then ss_irb_use" format="default"/> are then
applied. applied.
</t> </t>
</list> </li>
</t> </ol>
</section> <!-- egress_irb_use --> </section>
<section title="Announcing Interest in (S,G)" anchor="interest"> <section anchor="interest" numbered="true" toc="default">
<t> <name>Announcing Interest in (S,G)</name>
<xref target="RFC9251"/> defines procedures used by an egress PE <t>
<xref target="RFC9251" format="default"/> defines procedures used by an
egress PE
to announce its interest in a multicast flow or set of flows. If an to announce its interest in a multicast flow or set of flows. If an
egress PE determines it has LOCAL receivers in a particular BD, say egress PE determines it has LOCAL receivers in a particular BD, say
BD1, that are interested in a particular set of flows, it originates BD1, that are interested in a particular set of flows, it originates
one or more SMET routes for BD1. Each SMET route specifies a one or more SMET routes for BD1. Each SMET route specifies a
particular (S,G) or (*,G) flow. By originating an SMET route for particular (S,G) or (*,G) flow. By originating a SMET route for
BD1, a PE is announcing "I have receivers for (S,G) or (*,G) in BD1, a PE is announcing "I have receivers for (S,G) or (*,G) in
BD1". Such an SMET route carries the Route Target (RT) for BD1, BD1". Such a SMET route carries the RT for BD1,
ensuring that it will be distributed to all PEs that are attached to ensuring that it will be distributed to all PEs that are attached to
BD1. BD1.
</t> </t>
<t> <t>
The OISM procedures for originating SMET routes differ slightly from The OISM procedures for originating SMET routes differ slightly from
those in <xref target="RFC9251"/>. In most cases, the SMET those in <xref target="RFC9251" format="default"/>. In most cases, the
routes are considered to be for the SBD, rather than for the BD SMET
routes are considered to be for the SBD rather than the BD
containing local receivers. These SMET routes carry the containing local receivers. These SMET routes carry the
SBD&nbhy;RT, and do not carry any ordinary BD-RT. Details on the SBD-RT and do not carry any ordinary BD-RT. Details on the
processing of SMET routes can be found in <xref target="smet_adv"/>. processing of SMET routes can be found in <xref target="smet_adv" format
</t> ="default"/>.
<t> </t>
<t>
Since the SMET routes carry the SBD-RT, every ingress PE attached to Since the SMET routes carry the SBD-RT, every ingress PE attached to
a particular Tenant Domain will learn of all other PEs (attached to a particular Tenant Domain will learn of all other PEs (attached to
the same Tenant Domain) that have interest in a particular set of the same Tenant Domain) that have interest in a particular set of
flows. Note that a PE that receives a given SMET route does not flows. Note that a PE that receives a given SMET route does not
necessarily have any BDs (other than the SBD) in common with the PE necessarily have any BDs (other than the SBD) in common with the PE
that originates that SMET route. that originates that SMET route.
</t> </t>
<t> <t>
If all the sources and receivers for a given (*,G) are in the Tenant If all the sources and receivers for a given (*,G) are in the Tenant
Domain, inter&nbhy;subnet "Any Source Multicast" traffic will be Domain, inter-subnet ASM traffic will be
properly routed without requiring any Rendezvous Points, shared properly routed without requiring any RPs, shared
trees, or other complex aspects of multicast routing infrastructure. trees, or other complex aspects of multicast routing infrastructure.
Suppose, for example, that: Suppose, for example, that:
<list style="symbols"> </t>
<t> <ul spacing="normal">
PE1 has a local receiver, on BD1, for (*,G) <li>
</t> <t>
<t> PE1 has a local receiver, on BD1, for (*,G) and
</t>
</li>
<li>
<t>
PE2 has a local source, on BD2, for (*,G). PE2 has a local source, on BD2, for (*,G).
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
PE1 will originate an SMET(*,G) route for the SBD, and PE2 will PE1 will originate a SMET(*,G) route for the SBD, and PE2 will
receive that route, even if PE2 is not attached to BD1. PE2 will receive that route, even if PE2 is not attached to BD1. PE2 will
thus know to forward (S,G) traffic to PE1. PE1 does not need to do thus know to forward (S,G) traffic to PE1. PE1 does not need to do
any "source discovery". (This does assume that source S does not any source discovery. (This does assume that source S does not
send the same (S,G) datagram on two different BDs, and that the send the same (S,G) datagram on two different BDs and that the
Tenant Domain does not contain two or more sources with the same IP Tenant Domain does not contain two or more sources with the same IP
address S. The use of multicast sources that have IP "anycast" address S. The use of multicast sources that have IP anycast
addresses is outside the scope of this document.) addresses is outside the scope of this document.)
</t> </t>
<t> <t>
If some PE attached to the Tenant Domain does not support If some PE attached to the Tenant Domain does not support
[RFC9251], it will be assumed to be interested in all flows. <xref target="RFC9251"/>, it will be assumed to be interested in all flo
Whether a particular remote PE supports [RFC9251] is determined ws.
Whether a particular remote PE supports <xref target="RFC9251"/> or not
is determined
by the presence of the Multicast Flags Extended Community by the presence of the Multicast Flags Extended Community
<!-- (and the -->
<!-- setting of the "IGMP Proxy" flag within the EC) -->
in its IMET route; in its IMET route;
this is specified in [RFC9251]. this is specified in <xref target="RFC9251"/>.
</t> </t>
</section>
</section> <!-- interest --> <section anchor="tunneling" numbered="true" toc="default">
<section title="Tunneling Frames from Ingress PE to Egress PEs" <name>Tunneling Frames from Ingress PEs to Egress PEs</name>
anchor="tunneling"> <t>
<t> <xref target="RFC7432" format="default"/> specifies the procedures for s
<xref target="RFC7432"/> specifies the procedures for setting up and etting up and
using "BUM tunnels". A BUM tunnel is a tunnel used to carry traffic using BUM tunnels. A BUM tunnel is a tunnel used to carry traffic
on a particular BD if that traffic is (a) broadcast traffic, or (b) on a particular BD if that traffic is (a) broadcast traffic, (b)
unicast traffic with an unknown MAC DA, or (c) Ethernet multicast unicast traffic with an unknown Destination MAC Address, or (c) Ethernet
multicast
traffic. traffic.
</t> </t>
<t> <t>
This document allows the BUM tunnels to be used as the default This document allows the BUM tunnels to be used as the default
tunnels for transmitting IP multicast frames. It also allows a tunnels for transmitting IP multicast frames. It also allows a
separate set of tunnels to be used, instead of the BUM tunnels, as separate set of tunnels to be used, instead of the BUM tunnels, as
the default tunnels for carrying IP multicast frames. Let's call the default tunnels for carrying IP multicast frames. Let's call
these "IP Multicast Tunnels". these "IP multicast tunnels".
</t> </t>
<t> <t>
When the tunneling is done via Ingress Replication or via BIER, this When the tunneling is done via IR 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.
</t> </t>
<t> <t>
Other things being equal, it is desirable for an ingress PE to 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 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 join 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), BD1 and 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) then PE2 must join the P2MP Label Switched Path (LSP) on which PE1 trans
mits the (S,G)
frame. PE2 must join this P2MP LSP even if PE2 is not attached to frame. PE2 must join this P2MP LSP even if PE2 is not attached to
the source BD (BD1). If PE1 were transmitting the multicast frame the source BD, BD1. If PE1 was transmitting the multicast frame
on its BD1 BUM tunnel, then PE2 would have to join the BD1 BUM on its BD1 BUM tunnel, then PE2 would have to join the BD1 BUM
tunnel, even though PE2 has no BD1 attachment circuits. This would tunnel, even though PE2 has no BD1 Attachment Circuits. This would
cause PE2 to pull all the BUM traffic from BD1, most of which it cause PE2 to pull all the BUM traffic from BD1, most of which it
would just have to discard. Thus it is RECOMMENDED that the default IP would just have to discard. Thus, it is <bcp14>RECOMMENDED</bcp14> that the default IP
multicast tunnels be distinct from the BUM tunnels. multicast tunnels be distinct from the BUM tunnels.
</t> </t>
<t> <t>
Notwithstanding the above, link-local IP multicast traffic MUST Notwithstanding the above, link-local IP multicast traffic <bcp14>MUST</
always be carried on the BUM tunnels, and ONLY on the BUM tunnels. bcp14>
link-local IP multicast traffic consists of IPv4 traffic with a always be carried on the BUM tunnels and ONLY on the BUM tunnels.
Link-local IP multicast traffic consists of IPv4 traffic with a
destination address prefix of 224/24 and IPv6 traffic with a destination address prefix of 224/24 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 <xref "IP multicast packet" and "IP multicast frame" are defined in <xref targ
target="terminology"/> so as to exclude link&nbhy;local traffic. et="terminology" format="default"/> so as to exclude link-local traffic.
</t> </t>
<t> <t>
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 <xref target="adv_tunnels"/>). When particular multicast flows (see <xref target="adv_tunnels" format="defau
lt"/>). When
an (S,G) frame is transmitted on a selective tunnel, it is not an (S,G) frame is transmitted on a selective tunnel, it is not
transmitted on the BUM tunnel or on the default IP Multicast tunnel. transmitted on the BUM tunnel or on the default IP multicast tunnel.
</t> </t>
</section>
</section> <!-- tunneling --> <section anchor="adv_scen" numbered="true" toc="default">
<section title="Advanced Scenarios" anchor="adv_scen"> <name>Advanced Scenarios</name>
<t> <t>
There are some deployment scenarios that require special There are some deployment scenarios that require special
procedures: procedures:
<!-- These are discussed in detail in <xref --> </t>
<!-- target="advanced"/>. These scenarios are: --> <ol spacing="normal" type="1"><li>
<list style="format %d."> <t>
<t>
Some multicast sources or receivers are attached to PEs that Some multicast sources or receivers are attached to PEs that
support <xref target="RFC7432"/>, but do not support this support <xref target="RFC7432" format="default"/> but do not support
document or <xref target="RFC9135"/>. To interoperate with this
these "non&nbhy;OISM PEs", it is necessary to have one or more document or <xref target="RFC9135" format="default"/>. To interoper
ate with
these non-OISM PEs, it is necessary to have one or more
gateway PEs that interface the tunnels discussed in this gateway PEs that interface the tunnels discussed in this
document with the BUM tunnels of the legacy PEs. This is document with the BUM tunnels of the legacy PEs. This is
discussed in <xref target="no-OISM"/>. discussed in <xref target="no-OISM" format="default"/>.
</t> </t>
<t> </li>
<li>
<t>
Sometimes multicast traffic originates from outside the EVPN 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 <xref target="external"/>. An important special case discussed in <xref target="external" format="default"/>. An importa
of this, integration with MVPN, is discussed in <xref nt special case
target="mvpn"/>. of this, integration with MVPN, is discussed in <xref target="mvpn"
</t> format="default"/>.
<t> </t>
</li>
<li>
<t>
In some scenarios, one or more of the tenant systems is a PIM In some scenarios, one or more of the tenant systems is a PIM
router, and the Tenant Domain is used 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
<xref target="pim" format="default"/>.
<xref target="pim"/>. </t>
</t> </li>
</list> </ol>
</t> </section>
</section> <!-- adv_scen --> </section>
<section anchor="solution" numbered="true" toc="default">
</section> <!-- model_detail --> <name>EVPN-Aware Multicast Solution Control Plane</name>
<section anchor="sbd_rts" numbered="true" toc="default">
<section title="EVPN-aware Multicast Solution Control Plane" <name>Supplementary Broadcast Domain (SBD) and Route Targets</name>
anchor="solution">
<section title="Supplementary Broadcast Domain (SBD) and Route Targets"
anchor="sbd_rts">
<t> <t>
As discussed in <xref target="sbd_intro"/>, every Tenant Domain is As discussed in <xref target="sbd_intro" format="default"/>, every Ten
associated with a single Supplementary Broadcast Domain ant Domain is
(SBD). Recall that a Tenant Domain is defined to be a set of BDs associated with a single
SBD. Recall that a Tenant Domain is defined to be a set of BDs
that can freely send and receive IP multicast traffic to/from each that can freely send and receive IP multicast traffic to/from each
other. If an EVPN&nbhy;PE has one or more ACs in a BD of a other. If an EVPN PE has one or more ACs in a BD of a
particular Tenant Domain, and if the EVPN&nbhy;PE supports the particular Tenant Domain, and if the EVPN PE supports the
procedures of this document, that EVPN&nbhy;PE MUST be provisioned procedures of this document, that EVPN PE <bcp14>MUST</bcp14> be provi
sioned
with the SBD of that Tenant Domain. with the SBD of that Tenant Domain.
</t> </t>
<t> <t>
At each EVPN&nbhy;PE attached to a given Tenant Domain, there is At each EVPN PE attached to a given Tenant Domain, there is
an IRB interface leading from the L3 routing instance of that an IRB interface leading from the L3 routing instance of that
Tenant Domain to the SBD. However, the SBD has no ACs. Tenant Domain to the SBD. However, the SBD has no ACs.
</t> </t>
<t> <t>
Each SBD is provisioned with a Route Target (RT). All the Each SBD is provisioned with an RT. All the
EVPN&nbhy;PEs supporting a given SBD are provisioned with that RT EVPN PEs supporting a given SBD are provisioned with that RT
as an import RT. That RT MUST NOT be the same as the RT as an import RT. That RT <bcp14>MUST NOT</bcp14> be the same as the R
T
associated with any other BD. associated with any other BD.
</t> </t>
<t> <t>
We will use the term "SBD&nbhy;RT" to denote the RT that has been We will use the term "SBD-RT" to denote the RT that has been
assigned to the SBD. Routes carrying this RT will be propagated assigned to the SBD. Routes carrying this RT will be propagated
to all EVPN&nbhy;PEs in the same Tenant Domain as the originator. to all EVPN PEs in the same Tenant Domain as the originator.
</t> </t>
<t> <t>
<xref target="bd_route"/> specifies the rules by which an <xref target="bd_route" format="default"/> specifies the rules by whic
EVPN&nbhy;PE that receives a route determines whether a received h an
route "belongs to" a particular ordinary BD or SBD. EVPN PE that receives a route determines whether a received
route belongs to a particular ordinary BD or SBD.
</t> </t>
<t> <t>
<xref target="bd_route"/> also specifies additional rules that <xref target="bd_route" format="default"/> also specifies additional r ules that
must be followed when constructing routes that belong to a must be followed when constructing routes that belong to a
particular BD, including the SBD. particular BD, including the SBD.
</t> </t>
<t> <t>
The SBD SHOULD be in an EVPN Instance (EVI) of its own. Even if The SBD <bcp14>SHOULD</bcp14> be in an EVI of its own. Even if
the SBD is not in an EVI of its own, the SBD&nbhy;RT MUST be the SBD is not in an EVI of its own, the SBD-RT <bcp14>MUST</bcp14> be
different than the RT associated with any other BD. This different than the RT associated with any other BD. This
restriction is necessary in order for the rules of Sections <xref restriction is necessary in order for the rules of Sections <xref targ
target="bd_route" format="counter"/> and <xref target="sbd_rts" et="bd_route" format="counter"/> and <xref target="sbd_rts" format="counter"/> t
format="counter"/> to work correctly. o work correctly.
</t> </t>
<t> <t>
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&nbhy;PE with a MAC&nbhy;VRF. Per <xref target="RFC7432"/>, EVPN PE with a MAC-VRF. Per <xref target="RFC7432" format="default"/>
each MAC&nbhy;VRF is associated with a Route Distinguisher (RD). ,
When constructing a route that is "for" an SBD, an EVPN&nbhy;PE each MAC-VRF is associated with a Route Distinguisher (RD).
will place the RD of the associated MAC&nbhy;VRF in the "Route When constructing a route that is for an SBD, an EVPN PE
Distinguisher" field of the NLRI. (If the Tenant Domain has will place the RD of the associated MAC-VRF in the Route
several MAC&nbhy;VRFs on a given PE, the EVPN&nbhy;PE has a choice Distinguisher field of the NLRI. (If the Tenant Domain has
several MAC-VRFs on a given PE, the EVPN PE has a choice
of which RD to use.) of which RD to use.)
</t> </t>
<t> <t>
If Assisted Replication (AR, see <xref target="I-D.ietf-bess-evpn-opti If AR <xref target="RFC9574" format="default"/> is
mized-ir"/>) is used, each AR-REPLICATOR for a given Tenant Domain must be
used, each AR&nbhy;REPLICATOR for a given Tenant Domain must be
provisioned with the SBD of that Tenant Domain, even if the provisioned with the SBD of that Tenant Domain, even if the
AR&nbhy;REPLICATOR does not have any L3 routing instance. AR-REPLICATOR does not have any L3 routing instances.
</t> </t>
</section> <!-- sbd_rts --> </section>
<section title="Advertising the Tunnels Used for IP Multicast" <section anchor="adv_tunnels" numbered="true" toc="default">
anchor="adv_tunnels"> <name>Advertising the Tunnels Used for IP Multicast</name>
<t> <t>
The procedures used for advertising the tunnels that carry IP The procedures used for advertising the tunnels that carry IP
multicast traffic depend upon the type of tunnel being used. If multicast traffic depend upon the type of tunnel being used. If
the tunnel type is neither Ingress Replication, Assisted the tunnel type is neither IR, AR,
Replication, nor BIER, there are procedures for advertising both nor BIER, there are procedures for advertising both
"inclusive tunnels" and "selective tunnels". inclusive tunnels and selective tunnels.
</t> </t>
<t> <t>
When IR, AR or BIER are used to transmit IP multicast packets When IR, AR, or BIER are used to transmit IP multicast packets
across the core, there are no P2MP tunnels. Once an ingress across the core, there are no P2MP tunnels. Once an ingress
EVPN&nbhy;PE determines the set of egress EVPN&nbhy;PEs for a EVPN PE determines the set of egress EVPN PEs for a
given flow, the IMET routes contain all the information needed to given flow, the IMET routes contain all the information needed to
transport packets of that flow to the egress PEs. transport packets of that flow to the egress PEs.
</t> </t>
<t> <t>
If AR is used, the ingress EVPN&nbhy;PE is also an AR&nbhy;LEAF If AR is used, the ingress EVPN PE is also an AR-LEAF,
and the IMET route coming from the selected AR&nbhy;REPLICATOR and the IMET route coming from the selected AR-REPLICATOR
contains the information needed. The AR&nbhy;REPLICATOR will contains the information needed. The AR-REPLICATOR will
behave as an ingress EVPN&nbhy;PE when sending a flow to the behave as an ingress EVPN PE when sending a flow to the
egress EVPN&nbhy;PEs. egress EVPN PEs.
</t> </t>
<t> <t>
If the tunneling technique requires P2MP tunnels to be set up If the tunneling technique requires P2MP tunnels to be set up
(e.g., RSVP&nbhy;TE P2MP, mLDP, PIM), some of the tunnels may be (e.g., RSVP-TE P2MP, Multipoint LDP (mLDP), or PIM), some of the tunne ls may be
selective tunnels and some may be inclusive tunnels. selective tunnels and some may be inclusive tunnels.
</t> </t>
<t> <t>
Selective P2MP tunnels are always advertised by the ingress PE Selective P2MP tunnels are always advertised by the ingress PE
using S&nbhy;PMSI A&nbhy;D routes <xref target="I-D.ietf-bess-evpn-bum -procedure-updates"/>. using S-PMSI Auto-Discovery (A-D) routes <xref target="RFC9572" format ="default"/>.
</t> </t>
<t> <t>
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" <xref target="RFC7432"/> as the default ordinary BUM tunnel as the default
inclusive tunnel for carrying IP multicast traffic, or using a inclusive tunnel for carrying IP multicast traffic or using a
separate IP multicast tunnel as the default inclusive tunnel for separate IP multicast tunnel as the default inclusive tunnel for
carrying IP multicast. In the former case, the inclusive tunnel is carrying IP multicast. In the former case, the inclusive tunnel is
advertised in an IMET route. In the latter case, the inclusive advertised in an IMET route. In the latter case, the inclusive
tunnel is advertised in a (C&nbhy;*,C&nbhy;*) S&nbhy;PMSI A&nbhy;D tunnel is advertised in a (C-*,C-*) S-PMSI A-D
route <xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/>. Deta route <xref target="RFC9572" format="default"/>. Details may be found
ils may be found in in
subsequent sections. subsequent sections.
</t> </t>
<section anchor="sbd-routes" numbered="true" toc="default">
<section title="Constructing Routes for the SBD" <name>Constructing Routes for the SBD</name>
anchor="sbd-routes">
<t> <t>
There are situations in which an EVPN&nbhy;PE needs to originate There are situations in which an EVPN PE needs to originate
IMET, SMET, and/or SPMSI routes for the SBD. Throughout this IMET, SMET, and/or S-PMSI routes for the SBD. Throughout this
document, we will refer to such routes respectively as document, we will refer to such routes respectively as
"SBD&nbhy;IMET routes", "SBD&nbhy;SMET routes", and "SBD-IMET routes", "SBD-SMET routes", and
"SBD&nbhy;SPMSI routes". Subsequent sections detail the "SBD-SPMSI routes". Subsequent sections detail the
conditions under which these routes need to be originated. conditions under which these routes need to be originated.
</t> </t>
<t> <t>
When an EVPN&nbhy;PE needs to originate an SBD&nbhy;IMET, When an EVPN PE needs to originate an SBD-IMET,
SBD&nbhy;SMET, or SBD&nbhy;SPMSI route, it constructs the route SBD-SMET, or SBD-SPMSI route, it constructs the route
as follows: as follows:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t> <t>
the RD field of the route's NLRI is set to the RD of the The RD field of the route's NLRI is set to the RD of the
MAC&nbhy;VRF that is associated with the SBD; MAC-VRF that is associated with the SBD.
</t> </t>
</li>
<li>
<t> <t>
the SBD&nbhy;RT is attached to the route; The SBD-RT is attached to the route.
</t> </t>
</li>
<li>
<t> <t>
the "Tag ID" field of the route's NLRI is set to the Tag The Tag ID field of the route's NLRI is set to the Tag
ID that has been assigned to the SBD. This is most likely ID that has been assigned to the SBD. This is most likely
0 if a VLAN&nbhy;based or VLAN&nbhy;bundle service is 0 if a VLAN-based or VLAN-bundle service is
being used, but non-zero if a VLAN-aware bundle service is being used but non-zero if a VLAN-aware bundle service is
being used. being used.
</t> </t>
</list> </li>
</ul>
</section>
<section anchor="imet-ir" numbered="true" toc="default">
<name>Ingress Replication</name>
<t>
When IR is used to transport IP
multicast frames of a given Tenant Domain, each EVPN PE
attached to that Tenant Domain <bcp14>MUST</bcp14> originate an SB
D-IMET
route (see <xref target="sbd-routes" format="default"/>).
</t> </t>
</section> <!-- sbd-routes -->
<section title="Ingress Replication" anchor="imet-ir">
<t> <t>
When Ingress Replication (IR) is used to transport IP The SBD-IMET route <bcp14>MUST</bcp14> carry a
multicast frames of a given Tenant Domain, each EVPN&nbhy;PE PTA, and the MPLS Label field of the PTA <bcp14>MUST</bcp14> speci
attached to that Tenant Domain MUST originate an SBD&nbhy;IMET fy a
route (see <xref target="sbd-routes"/>).
</t>
<t>
The SBD&nbhy;IMET route MUST carry a PMSI Tunnel attribute
(PTA), and the MPLS label field of the PTA MUST specify a
downstream-assigned MPLS label that maps uniquely (in the downstream-assigned MPLS label that maps uniquely (in the
context of the originating EVPN&nbhy;PE) to the SBD. context of the originating EVPN PE) to the SBD.
</t> </t>
<t> <t>
Following the procedures of <xref target="RFC7432"/>, an Following the procedures of <xref target="RFC7432" format="default
EVPN&nbhy;PE MUST also originate an IMET route for each BD to "/>, an
EVPN PE <bcp14>MUST</bcp14> also originate an IMET route for each
BD to
which it is attached. Each of these IMET routes carries a PTA which it is attached. Each of these IMET routes carries a PTA
specifying a downstream&nbhy;assigned label that maps specifying a downstream-assigned label that maps
uniquely, in the context of the originating EVPN&nbhy;PE, to uniquely, in the context of the originating EVPN PE, to
the BD in question. These IMET routes need not carry the the BD in question. These IMET routes need not carry the
SBD&nbhy;RT. SBD-RT.
</t> </t>
<t> <t>
When an ingress EVPN&nbhy;PE needs to use IR to send an IP When an ingress EVPN PE needs to use IR to send an IP
multicast frame from a particular source BD to an egress multicast frame from a particular source BD to an egress
EVPN&nbhy;PE, the ingress PE determines whether the egress PE EVPN PE, the ingress PE determines whether or not the egress PE
has originated an IMET route for that BD. If so, that IMET has originated an IMET route for that BD. If so, that IMET
route contains the MPLS label that the egress PE has assigned route contains the MPLS label that the egress PE has assigned
to the source BD. The ingress PE uses that label when to the source BD. The ingress PE uses that label when
transmitting the packet to the egress PE. Otherwise, the transmitting the packet to the egress PE. Otherwise, the
ingress PE uses the label that the egress PE has assigned to ingress PE uses the label that the egress PE has assigned to
the SBD (in the SBD&nbhy;IMET route originated by the egress). the SBD (in the SBD-IMET route originated by the egress).
</t> </t>
<t> <t>
Note that the set of IMET routes originated by a given egress Note that the set of IMET routes originated by a given egress
PE, and installed by a given ingress PE, may change over time. PE, and installed by a given ingress PE, may change over time.
If the egress PE withdraws its IMET route for the source BD, If the egress PE withdraws its IMET route for the source BD,
the ingress PE MUST stop using the label carried in that IMET the ingress PE <bcp14>MUST</bcp14> stop using the label carried in
route, and instead MUST use the label carried in the that IMET
SBD&nbhy;IMET route from that egress PE. Implementors must route and instead <bcp14>MUST</bcp14> use the label carried in the
SBD-IMET route from that egress PE. Implementors must
also take into account that an IMET route from a particular PE also take into account that an IMET route from a particular PE
for a particular BD may arrive after that PE's SBD&nbhy;IMET for a particular BD may arrive after that PE's SBD-IMET
route. route.
</t> </t>
</section>
</section> <!-- imet-ir --> <section anchor="imet-ar" numbered="true" toc="default">
<section title="Assisted Replication" anchor="imet-ar"> <name>Assisted Replication</name>
<t> <t>
When Assisted Replication is used to transport IP multicast When AR is used to transport IP multicast
frames of a given Tenant Domain, each EVPN&nbhy;PE (including frames of a given Tenant Domain, each EVPN PE (including
the AR&nbhy;REPLICATOR) attached to the Tenant Domain MUST the AR-REPLICATOR) attached to the Tenant Domain <bcp14>MUST</bcp1
originate an SBD&nbhy;IMET route (see <xref 4>
target="sbd-routes"/>). originate an SBD-IMET route (see <xref target="sbd-routes" format=
</t> "default"/>).
<t> </t>
An AR&nbhy;REPLICATOR attached to a given Tenant Domain is <t>
considered to be an EVPN&nbhy;PE of that Tenant Domain. It is An AR-REPLICATOR attached to a given Tenant Domain is
considered to be an EVPN PE of that Tenant Domain. It is
attached to all the BDs in the Tenant Domain, but it does not attached to all the BDs in the Tenant Domain, but it does not
necessarily have L3 routing instances. necessarily have L3 routing instances.
</t> </t>
<t> <t>
As with Ingress Replication, the SBD&nbhy;IMET route carries a As with IR, the SBD-IMET route carries a
PTA where the MPLS label field specifies the PTA where the MPLS Label field specifies the
downstream-assigned MPLS label that identifies the downstream-assigned MPLS label that identifies the
SBD. However, the AR&nbhy;REPLICATOR and AR&nbhy;LEAF SBD. However, the AR-REPLICATOR and AR-LEAF
EVPN&nbhy;PEs will set the PTA's flags differently, as per EVPN PEs will set the PTA's flags differently, as per
<xref target="I-D.ietf-bess-evpn-optimized-ir"/>. <xref target="RFC9574" format="default"/>.
</t> </t>
<t> <t>
In addition, each EVPN&nbhy;PE originates an IMET route for In addition, each EVPN PE originates an IMET route for
each BD to which it is attached. As in the case of Ingress each BD to which it is attached. As in the case of IR,
Replication, these routes carry the downstream-assigned MPLS these routes carry the downstream-assigned MPLS
labels that identify the BDs and do not carry the SBD&nbhy;RT. labels that identify the BDs and do not carry the SBD-RT.
</t> </t>
<t> <t>
When an ingress EVPN&nbhy;PE, acting as AR&nbhy;LEAF, needs to When an ingress EVPN PE, acting as AR-LEAF, needs to
send an IP multicast frame from a particular source BD to an send an IP multicast frame from a particular source BD to an
egress EVPN&nbhy;PE, the ingress PE determines whether there egress EVPN PE, the ingress PE determines whether or not there
is any AR&nbhy;REPLICATOR that originated an IMET route for is any AR-REPLICATOR that originated an IMET route for
that BD. After the AR&nbhy;REPLICATOR selection (if there are that BD. After the AR-REPLICATOR selection (if there are
more than one), the AR&nbhy;LEAF uses the label contained in more than one), the AR-LEAF uses the label contained in
the IMET route of the AR&nbhy;REPLICATOR when transmitting the IMET route of the AR-REPLICATOR when transmitting
packets to it. The AR&nbhy;REPLICATOR receives the packet and, packets to it. The AR-REPLICATOR receives the packet and,
based on the procedures specified in <xref target="I-D.ietf-bess-e based on the procedures specified in <xref target="RFC9574" format
vpn-optimized-ir"/> ="default"/>
and in <xref target="imet-ir"/> of this document, and in <xref target="imet-ir" format="default"/> of this document,
transmits the packets to the egress EVPN&nbhy;PEs using the transmits the packets to the egress EVPN PEs using the
labels contained in the received IMET routes for either the labels contained in the received IMET routes for either the
source BD or the SBD. source BD or the SBD.
</t> </t>
<t> <t>
If an ingress AR&nbhy;LEAF for a given BD has not received any If an ingress AR-LEAF for a given BD has not received any
IMET route for that BD from an AR&nbhy;REPLICATOR, the ingress IMET route for that BD from an AR-REPLICATOR, the ingress
AR&nbhy;LEAF follows the procedures in <xref AR-LEAF follows the procedures in <xref target="imet-ir" format="d
target="imet-ir"/>. efault"/>.
</t> </t>
<section title = "Automatic SBD Matching" anchor="SBD-matching"> <section anchor="SBD-matching" numbered="true" toc="default">
<t>Each PE needs to know a BD's <name>Automatic SBD Matching</name>
<t>Each PE needs to know a BD's
corresponding SBD. Configuring that information in each BD corresponding SBD. Configuring that information in each BD
is one way but it requires repetitive configuration and is one way, but it requires repetitive configuration and
consistency checking (to make sure that all the BDs of the same consistency checking (to make sure that all the BDs of the same
tenant are configured with the same SBD). A better way is to tenant are configured with the same SBD). A better way is to
configure the SBD info in the L3 routing instance so that all 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.
</t> </t>
<t>An AR-replicator also needs to know same information, though <t>An AR-REPLICATOR also needs to know the same information, though
it does not necessarily have an L3 routing instance. it does not necessarily have an L3 routing instance.
However, from the EVI-RT EC in a BD's IMET route, an AR-replicator However, from the EVI-RT EC in a BD's IMET route, an AR-REPLICATOR
can derive the corresponding SBD of that BD without any configurati on. can derive the corresponding SBD of that BD without any configurati on.
</t> </t>
</section> </section>
</section> <!-- imet-ar --> </section>
<section title="BIER" anchor="imet-bier"> <section anchor="imet-bier" numbered="true" toc="default">
<t> <name>BIER</name>
<t>
When BIER is used to transport multicast packets of a given When BIER is used to transport multicast packets of a given
Tenant Domain, and a given EVPN&nbhy;PE attached to that Tenant Domain, and a given EVPN PE attached to that
Tenant Domain is a possible ingress EVPN&nbhy;PE for traffic Tenant Domain is a possible ingress EVPN PE for traffic
originating outside that Tenant Domain, the given EVPN&nbhy;PE originating outside that Tenant Domain, the given EVPN PE
MUST originate an SBD&nbhy;IMET route, (see <xref <bcp14>MUST</bcp14> originate an SBD-IMET route (see <xref target=
target="sbd-routes"/>). "sbd-routes" format="default"/>).
</t> </t>
<t> <t>
In addition, IMET routes that are originated for other BDs in In addition, IMET routes that are originated for other BDs in
the Tenant Domain MUST carry the SBD&nbhy;RT. the Tenant Domain <bcp14>MUST</bcp14> carry the SBD-RT.
</t> </t>
<t> <t>
Each IMET route (including but not limited to the Each IMET route (including but not limited to the
SBD&nbhy;IMET route) MUST carry a PMSI Tunnel attribute (PTA). SBD-IMET route) <bcp14>MUST</bcp14> carry a PTA.
The MPLS label field of the PTA MUST specify an The MPLS Label field of the PTA <bcp14>MUST</bcp14> specify an
upstream-assigned MPLS label that maps uniquely (in the upstream-assigned MPLS label that maps uniquely (in the
context of the originating EVPN&nbhy;PE) to the BD for which context of the originating EVPN PE) to the BD for which
the route is originated. the route is originated.
</t> </t>
<t> <t>
Suppose an ingress EVPN&nbhy;PE, PE1, needs to use BIER to Suppose an ingress EVPN PE, say PE1, needs to use BIER to
tunnel an IP multicast frame to a set of egress tunnel an IP multicast frame to a set of egress
EVPN&nbhy;PEs. And suppose the frame's source BD is BD1. The EVPN PEs. And suppose the frame's source BD is BD1. The
frame is encapsulated as follows: frame is encapsulated as follows:
<list style="symbols"> </t>
<t> <ul spacing="normal">
A four-octet MPLS label stack entry <xref <li>
target="RFC3032"/> is prepended to the <t>
A four-octet MPLS label stack entry <xref target="RFC3032" for
mat="default"/> is prepended to the
frame. The Label field is set to the upstream-assigned frame. The Label field is set to the upstream-assigned
label that PE1 has assigned to BD1. label that PE1 has assigned to BD1.
</t> </t>
<t> </li>
<li>
<t>
The resulting MPLS packet is then encapsulated in a BIER The resulting MPLS packet is then encapsulated in a BIER
encapsulation <xref target="RFC8296"/>, <xref encapsulation <xref target="RFC8296" format="default"/> <xref
target="I-D.ietf-bier-evpn"/>. The BIER BitString is set to target="RFC9624" format="default"/>. The BIER BitString is set to
identify the egress EVPN&nbhy;PEs. The BIER "proto" field identify the egress EVPN PEs. The BIER Proto field
is set to the value for "MPLS packet with is set to the value for "MPLS packet with an
upstream&nbhy;assigned label at top of stack". upstream-assigned label at top of the stack".
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
Note: It is possible that the packet being tunneled from PE1 Note: It is possible that the packet being tunneled from PE1
originated outside the Tenant Domain. In this case, the originated outside the Tenant Domain. In this case, the
actual source BD (BD1) is considered to be the SBD, and the actual source BD, BD1, is considered to be the SBD, and the
upstream&nbhy;assigned label it carries will be the label that upstream-assigned label it carries will be the label that
PE1 assigned to the SBD, and advertised in its SBD&nbhy;IMET PE1 assigned to the SBD and advertised in its SBD-IMET
route. route.
</t> </t>
<t> <t>
Suppose an egress PE, PE2, receives such a BIER packet. The Suppose an egress PE, say PE2, receives such a BIER packet. The
BFIR&nbhy;id field of the BIER header allows PE2 to determine BFIR-id field of the BIER header allows PE2 to determine
that the ingress PE is PE1. There are then two cases to that the ingress PE is PE1. There are then two cases to
consider: consider:
<list style="numbers"> </t>
<t> <ol spacing="normal" type="1"><li>
<t>
PE2 has received and installed an IMET route for BD1 from PE2 has received and installed an IMET route for BD1 from
PE1. PE1.
<vspace/> </t>
<vspace/> <t>
In this case, the BIER packet will be carrying the In this case, the BIER packet will be carrying the
upstream&nbhy;assigned label that is specified in the PTA upstream-assigned label that is specified in the PTA
of that IMET route. This enables PE2 to determine the of that IMET route. This enables PE2 to determine the
"apparent source BD" (as defined in <xref apparent source BD (as defined in <xref target="egress_irb_use
target="egress_irb_use"/>). " format="default"/>).
<!-- that --> </t>
<!-- BD1 is the source BD of the IP multicast frame carried by </li>
--> <li>
<!-- the BIER packet. --> <t>
</t>
<t>
PE2 has not received and installed an IMET route for BD1 PE2 has not received and installed an IMET route for BD1
from PE1. from PE1.
<vspace/> </t>
<vspace/> <t>
In this case, PE2 will not recognize the In this case, PE2 will not recognize the
upstream&nbhy;assigned label carried in the BIER upstream-assigned label carried in the BIER
packet. PE2 MUST discard the packet. packet. PE2 <bcp14>MUST</bcp14> discard the packet.
</t> </t>
</list> </li>
</t> </ol>
<t> <t>
Further details on the use of BIER to support EVPN can be Further details on the use of BIER to support EVPN can be
found in <xref target="I-D.ietf-bier-evpn"/>. found in <xref target="RFC9624" format="default"/>.
</t> </t>
</section>
</section> <!-- imet-bier --> <section anchor="adv_incl" numbered="true" toc="default">
<name>Inclusive P2MP Tunnels</name>
<section title="Inclusive P2MP Tunnels" anchor="adv_incl"> <section anchor="ip_bum" numbered="true" toc="default">
<section title="Using the BUM Tunnels as IP Multicast Inclusive <name>Using the BUM Tunnels as IP Multicast Inclusive Tunnels</name>
Tunnels"
anchor="ip_bum">
<t> <t>
The procedures in this section apply only when The procedures in this section apply only when:
<list style="format (%c)"> </t>
<ol spacing="normal" type="%c)"><li>
<t> <t>
it is desired to use the BUM tunnels to carry IP multicast it is desired to use the BUM tunnels to carry IP multicast
traffic across the backbone, and traffic across the backbone and
</t> </t>
</li>
<li>
<t> <t>
the BUM tunnels are P2MP tunnels (i.e., neither IR, AR, the BUM tunnels are P2MP tunnels (i.e., neither IR, AR,
nor BIER are being used to transport the BUM traffic). nor BIER are being used to transport the BUM traffic).
</t> </t>
</list> </li>
</t> </ol>
<t> <t>
In this case, an IP multicast frame (whether inter&nbhy;subnet In this case, an IP multicast frame (whether inter-subnet
or intra&nbhy;subnet) will be carried across the backbone in or intra-subnet) will be carried across the backbone in
the BUM tunnel belonging to its source BD. Each EVPN&nbhy;PE the BUM tunnel belonging to its source BD. Each EVPN PE
attached to a given Tenant Domain needs to join the BUM attached to a given Tenant Domain needs to join the BUM
tunnels for every BD in the Tenant Domain, even those BDs to tunnels for every BD in the Tenant Domain, even those BDs to
which the EVPN&nbhy;PE is not locally attached. This ensures which the EVPN PE is not locally attached. This ensures
that an IP multicast packet from any source BD can reach all that an IP multicast packet from any source BD can reach all
PEs attached to the Tenant Domain. PEs attached to the Tenant Domain.
</t> </t>
<t> <t>
Note that this will cause all the BUM traffic from a given BD Note that this will cause all the BUM traffic from a given BD
in a Tenant Domain to be sent to all PEs that attach to that in a Tenant Domain to be sent to all PEs that attach to that
Tenant Domain, even the PEs that don't attach to the given BD. Tenant Domain, even the PEs that don't attach to the given BD.
To avoid this, it is RECOMMENDED that the BUM tunnels not be To avoid this, it is <bcp14>RECOMMENDED</bcp14> that the BUM tunne
used as IP Multicast inclusive tunnels, and that the ls not be
procedures of <xref target="wc_spmsi"/> be used instead. used as IP multicast inclusive tunnels and that the
procedures of <xref target="wc_spmsi" format="default"/> be used i
nstead.
</t> </t>
<t> <t>
If a PE is a possible ingress EVPN&nbhy;PE for traffic If a PE is a possible ingress EVPN PE for traffic
originating outside the Tenant Domain, the PE MUST originate originating outside the Tenant Domain, the PE <bcp14>MUST</bcp14>
an SBD&nbhy;IMET route (see <xref target="sbd-routes"/>). originate
This route MUST carry a PTA specifying the P2MP tunnel used an SBD-IMET route (see <xref target="sbd-routes" format="default"/
>).
This route <bcp14>MUST</bcp14> carry a PTA specifying the P2MP tun
nel used
for transmitting IP multicast packets that originate outside for transmitting IP multicast packets that originate outside
the tenant domain. All EVPN&nbhy;PEs of the Tenant Domain the Tenant Domain. All EVPN PEs of the Tenant Domain
MUST join the tunnel specified in the PTA of an SBD&nbhy;IMET <bcp14>MUST</bcp14> join the tunnel specified in the PTA of an SBD
-IMET
route: route:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t> <t>
If the tunnel is an RSVP-TE P2MP tunnel, the originator of If the tunnel is an RSVP-TE P2MP tunnel, the originator of
the route MUST use RSVP-TE P2MP procedures to add each PE the route <bcp14>MUST</bcp14> use RSVP-TE P2MP procedures to a dd each PE
of the Tenant Domain to the tunnel, even PEs that have not of the Tenant Domain to the tunnel, even PEs that have not
originated an SBD&nbhy;IMET route. originated an SBD-IMET route.
</t> </t>
</li>
<li>
<t> <t>
If the tunnel is an mLDP or PIM tunnel, each PE importing If the tunnel is an mLDP or PIM tunnel, each PE importing
the SBD&nbhy;IMET route MUST add itself to the tunnel, the SBD-IMET route <bcp14>MUST</bcp14> add itself to the tunne l,
using mLDP or PIM procedures, respectively. using mLDP or PIM procedures, respectively.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
Whether or not a PE originates an SBD&nbhy;IMET route, it will Whether or not a PE originates an SBD-IMET route, it will
of course originate an IMET route for each BD to which it is of course originate an IMET route for each BD to which it is
attached. Each of these IMET routes MUST carry the attached. Each of these IMET routes <bcp14>MUST</bcp14> carry the
SBD&nbhy;RT, as well as the RT for the BD to which it belongs. SBD-RT, as well as the RT for the BD to which it belongs.
</t> </t>
<t> <t>
If a received IMET route is not the SBD&nbhy;IMET route, it If a received IMET route is not the SBD-IMET route, it
will also be carrying the RT for its source BD. The route's will also be carrying the RT for its source BD. The route's
NLRI will carry the Tag ID for the source BD. From the RT and NLRI will carry the Tag ID for the source BD. From the RT and
the Tag ID, any PE receiving the route can determine the the Tag ID, any PE receiving the route can determine the
route's source BD. route's source BD.
</t> </t>
<t> <t>
If the MPLS label field of the PTA contains zero, the If the MPLS Label field of the PTA contains zero, the
specified P2MP tunnel is used only to carry frames of a single specified P2MP tunnel is used only to carry frames of a single
source BD. source BD.
</t> </t>
<t> <t>
If the MPLS label field of the PTA does not contain zero, it If the MPLS Label field of the PTA does not contain zero, it
MUST contain an upstream-assigned MPLS label that maps <bcp14>MUST</bcp14> contain an upstream-assigned MPLS label that m
uniquely (in the context of the originating EVPN&nbhy;PE) to aps
the source BD (or, in the case of an SBD&nbhy;IMET route, to uniquely (in the context of the originating EVPN PE) to
the source BD (or in the case of an SBD-IMET route, to
the SBD). The tunnel may then be used to carry frames of the SBD). The tunnel may then be used to carry frames of
multiple source BDs. The apparent source BD of a particular multiple source BDs. The apparent source BD of a particular
packet is inferred from the label carried by the packet. packet is inferred from the label carried by the packet.
</t> </t>
<t> <t>
IP multicast traffic originating outside the Tenant Domain is IP multicast traffic originating outside the Tenant Domain is
transmitted with the label corresponding to the SBD, as transmitted with the label corresponding to the SBD, as
specified in the ingress EVPN&nbhy;PE's SBD&nbhy;IMET route. specified in the ingress EVPN PE's SBD-IMET route.
</t> </t>
</section> <!-- ip_bum --> </section>
<section title="Using Wildcard S&nbhy;PMSI A-D Routes to Advertise <section anchor="wc_spmsi" numbered="true" toc="default">
Inclusive Tunnels Specific to IP Multicast" <name>Using Wildcard S-PMSI A-D Routes to Advertise
anchor="wc_spmsi"> Inclusive Tunnels Specific to IP Multicast</name>
<t> <t>
The procedures of this section apply when (and only when) it is The procedures of this section apply when (and only when) it is
desired to transmit IP multicast traffic on an inclusive tunnel, desired to transmit IP multicast traffic on an inclusive tunnel
but not on the same tunnel used to transmit BUM traffic. but not on the same tunnel used to transmit BUM traffic.
</t> </t>
<t> <t>
However, these procedures do NOT apply when the tunnel type is However, these procedures do NOT apply when the tunnel type is
Ingress Replication or BIER, EXCEPT in the case where it is IR or BIER, EXCEPT in the case where it is
necessary to interwork between non&nbhy;OISM PEs and OISM PEs, necessary to interwork between non-OISM PEs and OISM PEs,
as specified in <xref target="no-OISM"/>. as specified in <xref target="no-OISM" format="default"/>.
</t> </t>
<t> <t>
Each EVPN&nbhy;PE attached to the given Tenant Domain MUST Each EVPN PE attached to the given Tenant Domain <bcp14>MUST</bcp14
originate an SBD&nbhy;SPMSI A&nbhy;D route. The NLRI of that >
route MUST contain (C&nbhy;*,C&nbhy;*) (see <xref originate an SBD-SPMSI A-D route. The NLRI of that
target="RFC6625"/>). Additional rules for constructing that route <bcp14>MUST</bcp14> contain (C-*,C-*) (see <xref target="RFC6
route are given in <xref target="sbd-routes"/>. 625" format="default"/>). Additional rules for constructing that
</t> route are given in <xref target="sbd-routes" format="default"/>.
<t> </t>
In addition, an EVPN&nbhy;PE MUST originate an S&nbhy;PMSI <t>
A&nbhy;D route containing (C&nbhy;*,C&nbhy;*) in its NLRI for In addition, an EVPN PE <bcp14>MUST</bcp14> originate an S-PMSI
A-D route containing (C-*,C-*) in its NLRI for
each of the other BDs, in the given Tenant Domain, to which it each of the other BDs, in the given Tenant Domain, to which it
is attached. All such routes MUST carry the SBD&nbhy;RT. This is attached. All such routes <bcp14>MUST</bcp14> carry the SBD-RT.
ensures that those routes are imported by all EVPN&nbhy;PEs This
ensures that those routes are imported by all EVPN PEs
attached to the Tenant Domain. attached to the Tenant Domain.
</t>
<t>
A PE receiving these routes follows the procedures of <xref
target="bd_route"/> to determine which BD the route is for.
<!-- The route carrying the PTA will also be carrying the RT for --
>
<!-- that source BD, and the route's NLRI will contain the Tag ID -
->
<!-- for that source BD. This allows any PE receiving the route to
-->
<!-- determine the source BD associated with the route. -->
</t> </t>
<t> <t>
If the MPLS label field of the PTA contains zero, the A PE receiving these routes follows the procedures of <xref target=
"bd_route" format="default"/> to determine which BD the route is for.
</t>
<t>
If the MPLS Label field of the PTA contains zero, the
specified tunnel is used only to carry frames of a single specified tunnel is used only to carry frames of a single
source BD. source BD.
</t> </t>
<t> <t>
If the MPLS label field of the PTA does not contain zero, it If the MPLS Label field of the PTA does not contain zero, it
MUST specify an upstream-assigned MPLS label that maps <bcp14>MUST</bcp14> specify an upstream-assigned MPLS label that m
uniquely (in the context of the originating EVPN&nbhy;PE) to aps
uniquely (in the context of the originating EVPN PE) to
the source BD. The tunnel may be used to carry frames of the source BD. The tunnel may be used to carry frames of
multiple source BDs, and the apparent source BD for a multiple source BDs, and the apparent source BD for a
particular packet is inferred from the label carried by the particular packet is inferred from the label carried by the
packet. packet.
</t> </t>
<t> <t>
The EVPN&nbhy;PE advertising these S&nbhy;PMSI A&nbhy;D route The EVPN PE advertising these S-PMSI A-D
routes is specifying the default tunnel that it will use (as routes is specifying the default tunnel that it will use (as
ingress PE) for transmitting IP multicast packets. The ingress PE) for transmitting IP multicast packets. The
upstream-assigned label allows an egress PE to determine the upstream-assigned label allows an egress PE to determine the
apparent source BD of a given packet. apparent source BD of a given packet.
</t> </t>
</section> <!-- wc-spmsi --> </section>
</section>
<!-- <section title="RSVP-TE P2MP" anchor="wc-rsvp"> --> <section anchor="adv_secl" numbered="true" toc="default">
<!-- <t> --> <name>Selective Tunnels</name>
<!-- When RSVP-TE P2MP is used to transport multicast packets of a <t>
--> An ingress EVPN PE for a given multicast flow or set of flows
<!-- given Tenant Domain on an inclusive tunnel, and it is desired
-->
<!-- to avoid using the BUM tunnels, then each EVPN&nbhy;PE
attached to -->
<!-- that Tenant Domain MUST originate an SBD&nbhy;SPMSI A-D
route. The -->
<!-- NLRI of that route MUST contain (C&nbhy;*,C&nbhy;*) (see
<xref -->
<!-- target="RFC625"/>). Additional rules for constructing that --
>
<!-- route are given in <xref target="sbd-spmsi"/>. -->
<!-- </t> -->
<!-- <t> -->
<!-- In addition, an EVPN&nbhy;PE MUST originate an S&nbhy;PMSI A-D
route -->
<!-- containing (C&nbhy;*,C&nbhy;*) in its NLRI for each of the
other BDs in -->
<!-- the Tenant Domain to which it is attached. All such route --
>
<!-- MUST carry the SBD&nbhy;RT. This ensures that those routes
are -->
<!-- imported by all EVPN&nbhy;PEs attached to the Tenant
Domain. -->
<!-- </t> -->
<!-- <t> -->
<!-- Each S&nbhy;PMSI A-D route (including but not limited to the
-->
<!-- SBD&nbhy;SPMSI route) MUST carry a PMSI Tunnel attribute
(PTA). -->
<!-- The MPLS label field of the PTA MUST specify an -->
<!-- upstream-assigned MPLS label that maps uniquely (in the -->
<!-- context of the originating EVPN&nbhy;PE) to the SBD. -->
<!-- </t> -->
<!-- <t> -->
<!-- The EVPN&nbhy;PE advertising these S&nbhy;PMSI A-D route routes i
s
-->
<!-- specifying the default tunnel that it will use (as ingress PE
) -->
<!-- for transmitting IP multicast packets. The upstream-assigned
-->
<!-- label allows an egress PE to determine the source BD of a -->
<!-- given packet. -->
<!-- </t> -->
<!-- </section> <!-\- wc-rsvp -\-> -->
<!-- <section title="mLDP or PIM" anchor="wc-recv"> -->
<!-- <t> -->
<!-- When either mLDP or PIM (or any other protocol that uses a --
>
<!-- receiver-driven technique to build P2MP or MP2MP trees) is --
>
<!-- used to transport multicast packets of a given Tenant Domain
-->
<!-- on an inclusive tunnel, and it is desired to avoid using the
-->
<!-- BUM tunnels, the procedures of this section apply. -->
<!-- </t> -->
<!-- <t> -->
<!-- then each, -->
<!-- an EVPN&nbhy;PE attached to that Tenant Domain MUST NOT
originate -->
<!-- an SBD&nbhy;IMET route. -->
<!-- </t> -->
<!-- <t> -->
<!-- However, IMET routes that are originated for other BDs in the
-->
<!-- Tenant Domain MUST carry the SBD&nbhy;RT. -->
<!-- </t> -->
<!-- <t> -->
<!-- Each IMET route MUST carry a PMSI Tunnel attribute (PTA), and
-->
<!-- the MPLS label field of the PTA MUST specify an -->
<!-- upstream-assigned MPLS label that maps uniquely (in the -->
<!-- context of the originating EVPN&nbhy;PE) to a particular
BD. -->
<!-- </t> -->
<!-- <t> -->
<!-- The EVPN&nbhy;PE advertising these IMET routes is specifying
the -->
<!-- default tunnel that it will use (as ingress PE) for -->
<!-- transmitting IP multicast packets. The upstream-assigned -->
<!-- label allows an egress PE to determine the source BD of a -->
<!-- given packet. -->
<!-- </t> -->
<!-- <t> -->
<!-- The procedures of this section <xref target="imet-recv"/> -->
<!-- apply whenever the tunnel technology is based on the -->
<!-- construction of the multicast trees in a "receiver-driven" --
>
<!-- manner; mLDP and PIM are two ways of constructing trees in a
-->
<!-- receiver-driven manner. -->
<!-- </t> -->
<!-- </section> <!-\- wc-recv -\-> -->
</section> <!-- wc_spmsi-->
<section title="Selective Tunnels" anchor="adv_secl">
<t>
An ingress EVPN&nbhy;PE for a given multicast flow or set of flows
can always assign the flow to a particular P2MP tunnel by can always assign the flow to a particular P2MP tunnel by
originating an S&nbhy;PMSI A&nbhy;D route whose NLRI identifies originating an S-PMSI A-D route whose NLRI identifies
the flow or set of flows. The NLRI of the route could be the flow or set of flows. The NLRI of the route could be
(C&nbhy;*,C&nbhy;G), or (C&nbhy;S,C&nbhy;G). The S&nbhy;PMSI (C-*,C-G) or (C-S,C-G). The S-PMSI
A&nbhy;D route MUST carry the SBD&nbhy;RT, so that it is imported A-D route <bcp14>MUST</bcp14> carry the SBD-RT so that it is imported
by all EVPN&nbhy;PEs attached to the Tenant Domain. by all EVPN PEs attached to the Tenant Domain.
</t> </t>
<!-- <t> -->
<!-- <cref source=" ECR"> -->
<!-- Any need for (C&nbhy;S,C&nbhy;*)? -->
<!-- </cref> -->
<!-- </t> -->
<t> <t>
An S&nbhy;PMSI A&nbhy;D route is "for" a particular source BD. It An S-PMSI A-D route is for a particular source BD. It
MUST carry the RT associated with that BD, and it MUST have the <bcp14>MUST</bcp14> carry the RT associated with that BD, and it <bcp1
4>MUST</bcp14> have the
Tag ID for that BD in its NLRI. Tag ID for that BD in its NLRI.
</t> </t>
<t> <t>
When an EVPN&nbhy;PE imports an S&nbhy;PMSI A&nbhy;D route, it When an EVPN PE imports an S-PMSI A-D route, it
applies the rules of <xref target="bd_route"/> to associate the applies the rules of <xref target="bd_route" format="default"/> to ass
ociate the
route with a particular BD. route with a particular BD.
</t> </t>
<t> <t>
Each such route MUST contain a PTA, as specified in <xref Each such route <bcp14>MUST</bcp14> contain a PTA, as specified in <xr
target="wc_spmsi"/>. ef target="wc_spmsi" format="default"/>.
</t> </t>
<t> <t>
An egress EVPN&nbhy;PE interested in the specified flow or flows An egress EVPN PE interested in the specified flow or flows
MUST join the specified tunnel. Procedures for joining the <bcp14>MUST</bcp14> join the specified tunnel. Procedures for joining
the
specified tunnel are specific to the tunnel type. (Note that if specified tunnel are specific to the tunnel type. (Note that if
the tunnel type is RSVP&nbhy;TE P2MP LSP, the Leaf Information the tunnel type is RSVP-TE P2MP LSP, the Leaf Information
Required (LIR) flag of the PTA SHOULD NOT be set. An ingress OISM Required (LIR) flag of the PTA <bcp14>SHOULD NOT</bcp14> be set. An i
PE knows which OISM EVPN PEs are interested in any given flow, and ngress OISM
hence can add them to the RSVP&nbhy;TE P2MP tunnel that carries PE knows which OISM EVPN PEs are interested in any given flow and
hence can add them to the RSVP-TE P2MP tunnel that carries
such flows.) such flows.)
<!-- If the tunnel is an --> </t>
<!-- RSVP-TE P2MP LSP, joining the tunnel will require the sending of <t>
-->
<!-- Leaf A-D routes, as discussed in <xref target="I-D.ietf-bess-evpn
-bum-procedure-updates"/>. -->
</t>
<t>
If the PTA does not specify a non-zero MPLS label, the apparent If the PTA does not specify a non-zero MPLS label, the apparent
source BD of any packets that arrive on that tunnel is considered source BD of any packets that arrive on that tunnel is considered
to be the BD associated with the route that carries the PTA. If to be the BD associated with the route that carries the PTA. If
the PTA does specify a non-zero MPLS label, the apparent source BD the PTA does specify a non-zero MPLS label, the apparent source BD
of any packets that arrive on that tunnel carrying the specified of any packets that arrive on that tunnel carrying the specified
label is considered to be the BD associated with the route that label is considered to be the BD associated with the route that
carries the PTA. carries the PTA.
</t> </t>
<t> <t>
It should be noted that when either IR or BIER is used, there is It should be noted that, when either IR or BIER is used, there is
no need for an ingress PE to use S&nbhy;PMSI A&nbhy;D routes to no need for an ingress PE to use S-PMSI A-D routes to
assign specific flows to selective tunnels. The procedures of assign specific flows to selective tunnels. The procedures of
<xref target="smet_adv"/>, along with the procedures of <xref <xref target="smet_adv" format="default"/>, along with the procedures
target="imet-ir"/>, <xref target="imet-ar"/>, or <xref of Sections <xref target="imet-ir" format="counter"/>, <xref target="imet-ar" fo
target="imet-bier"/>, provide the functionality of selective rmat="counter"/>, and <xref target="imet-bier" format="counter"/>, provide the f
tunnels without the need to use S&nbhy;PMSI A&nbhy;D routes. unctionality of selective
</t> tunnels without the need to use S-PMSI A-D routes.
</t>
</section> <!-- adv_secl --> </section>
</section> <!-- adv_incl --> </section>
<section anchor="smet_adv" numbered="true" toc="default">
<section title="Advertising SMET Routes" anchor="smet_adv"> <name>Advertising SMET Routes</name>
<t> <t>
<xref target="RFC9251"/> allows an egress EVPN&nbhy;PE to express <xref target="RFC9251" format="default"/> allows an egress EVPN PE to ex
press
its interest in a particular multicast flow or set of flows by its interest in a particular multicast flow or set of flows by
originating an SMET route. The NLRI of the SMET route identifies originating a SMET route. The NLRI of the SMET route identifies
the flow or set of flows as (C&nbhy;*,C&nbhy;*) or the flow or set of flows as (C-*,C-*),
(C&nbhy;*,C&nbhy;G) or (C&nbhy;S,C&nbhy;G). (C-*,C-G), or (C-S,C-G).
</t> </t>
<t> <t>
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 with that BD. From this &lt;RT,&nbsp;tag&gt; pair, other associated with that BD. From this &lt;RT, tag&gt; pair, other
EVPN&nbhy;PEs can identify the BD to which a received SMET route EVPN PEs can identify the BD to which a received SMET route
belongs. (Remember though that the route may be carrying multiple belongs. (Remember though that the route may be carrying multiple
RTs.) RTs.)
</t> </t>
<t> <t>
There are three cases to consider: There are three cases to consider:
<list style="symbols"> </t>
<t> <ol spacing="normal" type="Case %d:">
Case 1: It is known that no BD of a Tenant Domain contains a <li>
<t>
It is known that no BD of a Tenant Domain contains a
multicast router. multicast router.
<vspace/> </t>
<vspace/> <t>
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 set of flows by originating a SMET route that belongs to the
SBD. We refer to this as an SBD&nbhy;SMET route. The SBD. We refer to this as an SBD-SMET route. The
SBD&nbhy;SMET route carries the SBD&nbhy;RT, and has the Tag ID SBD-SMET route carries the SBD-RT and has the Tag ID
for the SBD in its NLRI. SMET routes for the individual BDs are for the SBD in its NLRI. SMET routes for the individual BDs are
not needed, because there is no need for a PE that receives an not needed, because there is no need for a PE that receives a
SMET route to send a corresponding IGMP/MLD Join message on any of SMET route to send a corresponding IGMP/MLD Join message on any of
its ACs. its ACs.
</t> </t>
<t> </li>
Case 2: It is known that more than one BD of a Tenant Domain may <li>
<t>
It is known that more than one BD of a Tenant Domain may
contain a multicast router. contain a multicast router.
<vspace/> </t>
<vspace/> <t>
This is very like Case 1. An egress PE advertises its interest This is much like Case 1. An egress PE advertises its interest
in a flow or set of flows by originating an SBD&nbhy;SMET route. in a flow or set of flows by originating an SBD-SMET route.
The SBD&nbhy;SMET route carries the SBD&nbhy;RT, and has the Tag The SBD-SMET route carries the SBD-RT and has the Tag
ID for the SBD in its NLRI. ID for the SBD in its NLRI.
<vspace/> </t>
<vspace/> <t>
In this case, it is important to be sure that SMET routes for In this case, it is important to be sure that SMET routes for
the individual BDs are not originated. Suppose, for example, the individual BDs are not originated. For example, suppose
that PE1 had local receivers for a given flow on both BD1 and that PE1 had local receivers for a given flow on both BD1 and
BD2, and that it originated SMET routes for both those BDs. BD2 and that it originated SMET routes for both those BDs.
Then PEs receiving those SMET routes might send IGMP/MLD Joins on Then, PEs receiving those SMET routes might send IGMP/MLD Joins on
both those BDs. This could cause externally sourced multicast both those BDs. This could cause externally sourced multicast
traffic to enter the Tenant Domain at both BDs, which could traffic to enter the Tenant Domain at both BDs, which could
result in duplication of data. result in duplication of data.
<vspace/> </t>
<vspace/> <t>
Note that 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 originating from outside EVPN, the PEs <bcp14>MUST</bcp14> follow th
procedures of <xref target="external"/>. e
</t> procedures of <xref target="external" format="default"/>.
<t> </t>
Case 3: It is known that only a single BD of a Tenant Domain </li>
<li>
<t>
It is known that only a single BD of a Tenant Domain
contains a multicast router. contains a multicast router.
<vspace/> </t>
<vspace/> <t>
Suppose that an egress PE is attached to a BD on which there Suppose that an egress PE is attached to a BD on which there
might be a tenant multicast router. (The tenant router is not might 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 suppose that the PE has one or more ACs attached to that BD,
which are interested in a given multicast flow. In this case, which are interested in a given multicast flow. In this case,
in addition to the SMET route for the SBD, the egress PE MAY in addition to the SMET route for the SBD, the egress PE <bcp14>MAY<
originate an SMET route for that BD. This will enable the /bcp14>
originate a SMET route for that BD. This will enable the
ingress PE(s) to send IGMP/MLD messages on ACs for the BD, as ingress PE(s) to send IGMP/MLD messages on ACs for the BD, as
specified in <xref target="RFC9251"/>. As long as that is specified in <xref target="RFC9251" format="default"/>. As long as that is
the only BD on which there is a tenant multicast router, there the only BD on which there is a tenant multicast router, there
is no possibility of duplication of data. is no possibility of duplication of data.
<!-- <vspace/> --> </t>
<!-- <vspace/> --> </li>
<!-- If an SMET route is not an SBD&nbhy;SMET route, and if the SMET </ol>
--> <t>
<!-- route is for (C&nbhy;S,C&nbhy;G) (i.e., no wildcard source), an
d -->
<!-- if the EVPN&nbhy;PE originating it knows the source BD of -->
<!-- C&nbhy;S, it MAY put only the RT for that BD on the route. -->
<!-- Otherwise, the route MUST carry the SBD&nbhy;RT, so that it get
s -->
<!-- distributed to all the EVPN&nbhy;PEs attached to the tenant -->
<!-- domain. -->
<!-- <vspace/> -->
<!-- <vspace/> -->
</t>
</list>
</t>
<t>
This document does not specify procedures for dynamically This document does not specify procedures for dynamically
determining which of the three cases applies to a given deployment; determining which of the three cases applies to a given deployment;
the PEs of a given Tenant Domain MUST be provisioned to know which the PEs of a given Tenant Domain <bcp14>MUST</bcp14> be provisioned to k now which
case applies. case applies.
</t> </t>
<t>
<t> As detailed in <xref target="RFC9251"/>, a SMET route carries fla
As detailed in [RFC9251], an SMET route carries flags indicating gs indicating whether IGMP (v1, v2, or v3) or MLD (v1 or v2) messages should be
whether IGMP (v1, v2 or v3) or MLD (v1 or v2) messages should be triggered on th triggered on the ACs of the BD to which the SMET route belongs. For IGMP v3 and
e ACs of the BD to which the SMET route belongs. For IGMP v3 and MLD v2, the IE MLD v2, the Include/Exclude (IE) flag also indicates whether the source informat
flag also indicates whether the source information in the SMET route is of an In ion in the SMET route is of an Include Group type or Exclude Group type. If an S
clude Group type or Exclude Group type. If an SBD PE needs to generate IGMP/MLD BD PE needs to generate IGMP/MLD reports (as it is the case in <xref target="ext
reports as it is the case in section 6.2), or the route is for an (S, G) state, ernal_pim_router"/>) or the route is for an (S, G) state, the value of the flags
the value of the flags MUST be set according to the rules in [RFC9251]. Otherwis <bcp14>MUST</bcp14> be set according to the rules in <xref target="RFC9251"/>.
e, the flags SHOULD be set to 0. Otherwise, the flags <bcp14>SHOULD</bcp14> be set to 0.
</t> </t>
<t> <t>
Note that a PE only needs to originate the set of SBD&nbhy;SMET Note that a PE only needs to originate the set of SBD-SMET
routes that are needed to receive multicast traffic in which it is routes that are needed in order to receive multicast traffic that the PE
interested. Suppose PE1 has ACs attached to BD1 that are interested is
in (C&nbhy;*,C&nbhy;G) traffic, and ACs attached to BD2 that are interested in. Suppose PE1 has ACs attached to BD1 that are interested
interested in (C&nbhy;S,C&nbhy;G) traffic. A single SBD&nbhy;SMET in (C-*,C-G) traffic and ACs attached to BD2 that are
route specifying (C&nbhy;*,C&nbhy;G) will attract all the necessary interested in (C-S,C-G) traffic. A single SBD-SMET
route specifying (C-*,C-G) will attract all the necessary
flows. flows.
</t> </t>
<t> <t>
As another example, suppose the ACs attached to BD1 are interested As another example, suppose the ACs attached to BD1 are interested
in (C&nbhy;*,C&nbhy;G) but not in (C&nbhy;S,C&nbhy;G), while the ACs in (C-*,C-G) but not in (C-S,C-G), while the ACs
attached to BD2 are interested in (C&nbhy;S,C&nbhy;G). A single attached to BD2 are interested in (C-S,C-G). A single
SBD&nbhy;SMET route specifying (C&nbhy;*,C&nbhy;G) will pull in all SBD-SMET route specifying (C-*,C-G) will pull in all
the necessary flows. the necessary flows.
</t> </t>
<t> <t>
In other words, to determine the set of SBD&nbhy;SMET routes that In other words, to determine the set of SBD-SMET routes that
have to be sent for a given C&nbhy;G, the PE has to merge the have to 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 IGMP/MLD state for all the BDs (of the given Tenant Domain) to which
it is attached. it is attached.
</t> </t>
<t> <t>
Per <xref target="RFC9251"/>, importing an SMET route for a Per <xref target="RFC9251" format="default"/>, importing a SMET route fo
particular BD will cause IGMP/MLD state to be instantiated for the r a
IRB interface to that BD. This applies as well when the BD is the particular BD will cause the IGMP/MLD state to be instantiated for the
IRB interface to that BD. This also applies when the BD is the
SBD. SBD.
</t> </t>
<t> <t>
However, traffic that originates in one of the actual BDs of a However, traffic that originates in one of the actual BDs of a
particular Tenant Domain MUST NOT be sent down the IRB interface particular Tenant Domain <bcp14>MUST NOT</bcp14> be sent down the IRB in terface
that connects the L3 routing instance of that Tenant Domain to the that connects the L3 routing instance of that Tenant Domain to the
SBD. That would cause duplicate delivery of traffic, since such SBD. That would cause duplicate delivery of traffic, since such
traffic will have already been distributed throughout the Tenant traffic will have already been distributed throughout the Tenant
Domain. Therefore, when setting up the IGMP/MLD state based on Domain. Therefore, when setting up the IGMP/MLD state based on
SBD&nbhy;SMET routes, care must be taken to ensure that the IRB SBD-SMET routes, care must be taken to ensure that the IRB
interface to the SBD is not added to the Outgoing Interface (OIF) interface to the SBD is not added to the Outgoing Interface (OIF)
list if the traffic originates within the Tenant Domain. list if the traffic originates within the Tenant Domain.
</t> </t>
<t> <t>
There are some multicast scenarios that make use of "anycast There are some multicast scenarios that make use of anycast
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) anycast IP address, say S1, and each may transmit an (S1,G)
multicast flow. In such a scenario, the two (S1,G) flows are multicast flow. In such a scenario, the two (S1,G) flows are
typically identical. Ordinary PIM procedures will cause only one typically identical. Ordinary PIM procedures will cause only one of
the flows to be delivered to each receiver that has expressed the flows to be delivered to each receiver that has expressed
interest in either (*,G) or (S1,G). However, the OISM procedures interest in either (*,G) or (S1,G). However, the OISM procedures
described in this document will result in both of the (S1,G) flows described in this document will result in both of the (S1,G) flows
being distributed in the Tenant Domain, and duplicate delivery will being distributed in the Tenant Domain, and duplicate delivery will
result. Therefore, if there are receivers for (*,G) in a given result. Therefore, if there are receivers for (*,G) in a given
Tenant Domain, there MUST NOT be anycast sources for G within that Tenant Domain, there <bcp14>MUST NOT</bcp14> be anycast sources for G wi thin that
Tenant Domain. (This restriction could be lifted by defining Tenant Domain. (This restriction could be lifted by defining
additional procedures; however that is outside the scope of this additional procedures; however, that is outside the scope of this
document.) document.)
</t> </t>
</section>
</section> <!-- smet_adv --> </section>
</section> <!-- adv_tunnels --> <section anchor="mcast_state" numbered="true" toc="default">
<name>Constructing Multicast Forwarding State</name>
<section title="Constructing Multicast Forwarding State" <section anchor="l2_state" numbered="true" toc="default">
anchor="mcast_state"> <name>Layer 2 Multicast State</name>
<section title="Layer 2 Multicast State" anchor="l2_state">
<t> <t>
An EVPN&nbhy;PE maintains "layer 2 multicast state" for each BD to An EVPN PE maintains Layer 2 multicast state for each BD to
which it is attached. Note that this is used for forwarding IP which it is attached. Note that this is used for forwarding IP
multicast frames based on the inner IP header. The state is multicast frames based on the inner IP header. The state is
learned through IGMP/MLD snooping <xref target="RFC4541"/> learned through IGMP/MLD snooping <xref target="RFC4541" format ="default"/>
and procedures in this document. and procedures in this document.
</t> </t>
<t> <t>
Let PE1 be an EVPN&nbhy;PE, and BD1 be a BD to which it is Let PE1 be an EVPN PE and BD1 be a BD to which it is
attached. At PE1, BD1's layer 2 multicast state for a given attached. At PE1, BD1's Layer 2 multicast state for a given
(C&nbhy;S,C&nbhy;G) or (C&nbhy;*,C&nbhy;G) governs the disposition (C-S,C-G) or (C-*,C-G) governs the disposition
of an IP multicast packet that is received by BD1's layer 2 of an IP multicast packet that is received by BD1's Layer 2
multicast function on an EVPN&nbhy;PE. multicast function on an EVPN PE.
</t> </t>
<t> <t>
An IP multicast (S,G) packet is considered to have been received An IP multicast (S,G) packet is considered to have been received
by BD1's layer 2 multicast function in PE1 in the following by BD1's Layer 2 multicast function in PE1 in the following
cases: cases:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
<t>
The packet is the payload of an Ethernet frame received by PE1 The packet is the payload of an Ethernet frame received by PE1
from an AC that attaches to BD1. from an AC that attaches to BD1.
</t> </t>
<t> </li>
<li>
<t>
The packet is the payload of an Ethernet frame whose The packet is the payload of an Ethernet frame whose
apparent source BD is BD1, and which is received by the PE1 apparent source BD is BD1, which is received by the PE1
over a tunnel from another EVPN&nbhy;PE. over a tunnel from another EVPN PE.
</t> </t>
<t> </li>
<li>
<t>
The packet is received from BD1's IRB interface (i.e., has The packet is received from BD1's IRB interface (i.e., has
been transmitted by PE1's L3 routing instance down BD1's IRB been transmitted by PE1's L3 routing instance down BD1's IRB
interface). interface).
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
According to the procedures of this document, all transmission of According to the procedures of this document, all transmissions of
IP multicast packets from one EVPN&nbhy;PE to another is done at IP multicast packets from one EVPN PE to another are done at
layer 2. That is, the packets are transmitted as Ethernet frames, Layer 2. That is, the packets are transmitted as Ethernet frames,
according to the layer 2 multicast state. according to the Layer 2 multicast state.
</t> </t>
<t> <t>
Each layer 2 multicast state (S,G) or (*,G) contains a set of "output Each Layer 2 multicast state (S,G) or (*,G) contains a set of outgoing
interfaces" (OIF list). The disposition of an (S,G) multicast interfaces (an OIF list). The disposition of an (S,G) multicast
frame received by BD1's layer 2 multicast function is determined frame received by BD1's Layer 2 multicast function is determined
as follows: as follows:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t> <t>
The OIF list is taken from BD1's layer 2 (S,G) state, or if 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. there is no such (S,G) state, then it is taken from BD1's (*,G) st
ate.
(If neither state exists, the OIF list is considered to be (If neither state exists, the OIF list is considered to be
null.) null.)
</t> </t>
</li>
<li>
<t> <t>
The rules of <xref target="iif_oif"/> are applied to the OIF The rules of <xref target="iif_oif" format="default"/> are applied to the OIF
list. This will generally result in the frame being list. This will generally result in the frame being
transmitted to some, but not all, elements of the OIF list. transmitted to some, but not all, elements of the OIF list.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
Note that there is no Reverse Path Forwarding (RPF) check at layer 2. Note that there is no Reverse Path Forwarding (RPF) check at Layer 2.
<!-- In EVPN multicast, it -->
<!-- is assumed that a given IP source address appears on only a singl
e -->
<!-- segment at any one time, therefore no RPF check is -->
<!-- necessary. However, the OIF list used by a particular PE for a --
>
<!-- particular (S,G) frame depends on the way that the frame was -->
<!-- received. -->
</t> </t>
<section title="Constructing the OIF List" <section anchor="oif_construct" numbered="true" toc="default">
anchor="oif_construct"> <name>Constructing the OIF List</name>
<t> <t>
In this document, we have extended the procedures of <xref In this document, we have extended the procedures of <xref target="R
target="RFC9251"/> so that IMET and SMET routes for a FC9251" format="default"/> so that IMET and SMET routes for a
particular BD are distributed not just to PEs that attach to particular BD are distributed not just to PEs that attach to
that BD, but to PEs that attach to any BD in the Tenant Domain. that BD but to PEs that attach to any BD in the Tenant Domain.
In this way, each PE attached to a given Tenant Domain learns, In this way, each PE attached to a given Tenant Domain learns,
from other PE attached to the same Tenant Domain, the set from another PE attached to the same Tenant Domain, the set
of flows that are of interest to each of those other PEs. (If of flows that are of interest to each of those other PEs. (If
some PE attached to the Tenant Domain does not support <xref some PE attached to the Tenant Domain does not support <xref target=
target="RFC9251"/>, it will be assumed to be interested in "RFC9251" format="default"/>, it will be assumed to be interested in
all flows. Whether a particular remote PE supports <xref all flows. Whether or not a particular remote PE supports <xref tar
target="RFC9251"/> is determined by the presence of an get="RFC9251" format="default"/> is determined by the presence of an
Extended Community in its IMET route; this is specified in <xref Extended Community in its IMET route; this is specified in <xref tar
target="RFC9251"/>.) If a set of remote PEs are interested get="RFC9251" format="default"/>.) If a set of remote PEs are interested
in a particular flow, the tunnels used to reach those PEs are in a particular flow, the tunnels used to reach those PEs are
added to the OIF list of the multicast states corresponding to added to the OIF list of the multicast states corresponding to
that flow. that flow.
</t> </t>
<t> <t>
An EVPN&nbhy;PE may run IGMP/MLD snooping procedures An EVPN PE may run IGMP/MLD snooping procedures
<xref target="RFC4541"/> on each of its ACs, <xref target="RFC4541" format="default"/> on each of its
ACs
in order to determine the set of flows of interest to each AC. in order to determine the set of flows of interest to each AC.
(An AC is said to be interested in a given flow if it connects (An AC is said to be interested in a given flow if it connects
to a segment that has tenant systems interested in that flow.) to a segment that has tenant systems interested in that flow.)
If IGMP/MLD procedures are not being run on a given AC, that AC If IGMP/MLD procedures are not being run on a given AC, that AC
is considered to be interested in all flows. For each BD, the is considered to be interested in all flows. For each BD, the
set of ACs interested in a given flow is determined, and the ACs set of ACs interested in a given flow is determined, and the ACs
of that set are added to the OIF list of that BD's multicast of that set are added to the OIF list of that BD's multicast
state for that flow. state for that flow.
</t> </t>
<t> <t>
The OIF list for each multicast state must also contain the The OIF list for each multicast state must also contain the
IRB interface for the BD to which the state belongs. IRB interface for the BD to which the state belongs.
<!-- However, a given frame will be sent up only one -->
<!-- IRB interface, depending upon the source BD of the frame. This
-->
<!-- is explained further in <xref target="iif_oif"/>. -
->
</t> </t>
<t> <t>
Implementors should note that the OIF list of a multicast state Implementors should note that the OIF list of a multicast state
will change from time to time as ACs and/or remote PEs either will change from time to time as ACs and/or remote PEs either
become interested in, or lose interest in, particular multicast become interested in or lose interest in particular multicast
flows. flows.
</t> </t>
</section> <!-- oif_construct --> </section>
<section anchor="iif_oif" numbered="true" toc="default">
<section title="Data Plane: Applying the OIF List to an (S,G) Frame" <name>Data Plane: Applying the OIF List to an (S,G) Frame</name>
anchor="iif_oif"> <t>
<t> When an (S,G) multicast frame is received by the Layer 2
When an (S,G) multicast frame is received by the layer 2 multicast function of a given EVPN PE, say PE1, its
multicast function of a given EVPN&nbhy;PE, say PE1, its disposition depends upon (a) the way it was received, (b) the
disposition depends (a) on the way it was received, (b) upon the OIF list of the corresponding multicast state (see <xref target="oif
OIF list of the corresponding multicast state (see <xref _construct" format="default"/>), (c) the eligibility of an AC
target="oif_construct"/>), (c) upon the "eligibility" of an AC to receive a given frame (see <xref target="ac_eligibility" format="
to receive a given frame (see <xref target="ac_eligibility"/>) default"/>),
and (d) upon its apparent source BD (see <xref and (d) its apparent source BD (see <xref target="adv_tunnels" forma
target="adv_tunnels"/> for information about determining the t="default"/> for information about determining the
apparent source BD of a frame received over a tunnel from apparent source BD of a frame received over a tunnel from
another PE). another PE).
</t> </t>
<section title="Eligibility of an AC to Receive a Frame" <section anchor="ac_eligibility" numbered="true" toc="default">
anchor="ac_eligibility"> <name>Eligibility of an AC to Receive a Frame</name>
<t> <t>
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:
<list style="format %d."> </t>
<t> <ol spacing="normal" type="1"><li>
ESI labels are being used, PE1 is the DF for the segment to <t>
Ethernet Segment Identifier (ESI) labels are being used, PE1 is
the DF for the segment to
which AC1 is connected, and the frame did not originate from which AC1 is connected, and the frame did not originate from
that same segment (as determined by the ESI label), or that same segment (as determined by the ESI label).
</t> </t>
<t> </li>
<li>
<t>
The ingress PE for the frame is a remote PE, say PE2, The ingress PE for the frame is a remote PE, say PE2,
local bias is being used, and PE2 is not connected to local bias is being used, and PE2 is not connected to
the same segment as AC1. the same segment as AC1.
</t> </t>
<!-- <t> --> </li>
<!-- <cref source=" ECR"> --> </ol>
<!-- Of course, if the frame has no ingress EVPN&nbhy;PE --> </section>
<!-- (maybe it comes from MVPN) or if we can't tell who --> <section anchor="oif_apply" numbered="true" toc="default">
<!-- the ingress EVPN&nbhy;PE is, this won't work. --> <name>Applying the OIF List</name>
<!-- </cref> --> <t>
<!-- </t> -->
</list>
</t>
</section> <!-- ac_eligibility -->
<section title="Applying the OIF List" anchor="oif_apply">
<t>
Assume a given (S,G) multicast frame has been received by a given 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, PE, say PE1. PE1 determines the apparent source BD of the frame,
finds the layer 2 (S,G) state for that BD (or the (*,G) finds the Layer 2 (S,G) state for that BD (or the (*,G)
state if there is no (S,G) state), and uses the OIF list from state if there is no (S,G) state), and uses the OIF list from
that state. (Note that if PE1 is not attached to the actual that state. (Note that if PE1 is not attached to the actual
source BD, the apparent source BD will be the SBD.) source BD, the apparent source BD will be the SBD.)
</t> </t>
<t> <t>
Suppose PE1 has determined the frame's apparent source BD to be If PE1 has determined the frame's apparent source BD to be
BD1 (which may or may not be the SBD.) There are the following BD1 (which may or may not be the SBD), then the following
cases to consider: cases should be considered:
<list style="format %d."> </t>
<t> <ol spacing="normal" type="1"><li>
<t>
The frame was received by PE1 from a local AC, say AC1, that The frame was received by PE1 from a local AC, say AC1, that
attaches to BD1. attaches to BD1.
<list style="format %c."> </t>
<t> <ol spacing="normal" type="a"><li>
The frame MUST be sent on all local ACs of BD1 that <t>
The frame <bcp14>MUST</bcp14> be sent on all local ACs of BD1
that
appear in the OIF list, except for AC1 itself. appear in the OIF list, except for AC1 itself.
<!-- (a) AC1 itself, and (b) any AC --> </t>
<!-- that is attached to the same segment as AC1. --> </li>
</t> <li>
<t> <t>
The frame MUST also be delivered to any other The frame <bcp14>MUST</bcp14> also be delivered to any other
EVPN&nbhy;PEs that have interest in it. This is achieved EVPN PEs that have interest in it. This is achieved
as follows: as follows:
<list style="format %i."> </t>
<t> <ol spacing="normal" type="i"><li>
If (a) AR is being used, and (b) PE1 is an <t>
AR&nbhy;LEAF, and (c) the OIF list is non&nbhy;null, If (a) AR is being used, (b) PE1 is an
PE1 MUST send the frame to the AR&nbhy;REPLICATOR. AR-LEAF, and (c) the OIF list is non-null,
</t> PE1 <bcp14>MUST</bcp14> send the frame to the AR-REPLICAT
<t> OR.
Otherwise the frame MUST be sent on all tunnels in </t>
</li>
<li>
<t>
Otherwise, the frame <bcp14>MUST</bcp14> be sent on all t
unnels in
the OIF list. the OIF list.
</t> </t>
</list> </li>
</t> </ol>
<t> </li>
The frame MUST be sent to the local L3 routing instance <li>
by being sent up the IRB interface of BD1. It MUST NOT <t>
The frame <bcp14>MUST</bcp14> be sent to the local L3 routing
instance
by being sent up the IRB interface of BD1. It <bcp14>MUST NO
T</bcp14>
be sent up any other IRB interfaces. be sent up any other IRB interfaces.
</t> </t>
</list> </li>
</t> </ol>
<t> </li>
<li>
<t>
The frame was received by PE1 over a tunnel from another PE. The frame was received by PE1 over a tunnel from another PE.
(See <xref target="adv_tunnels"/> for the rules to determine (See <xref target="adv_tunnels" format="default"/> for the rules to determine
the apparent source BD of a packet received from another PE. the apparent source BD of a packet received from another PE.
Note that if PE1 is not attached to the source BD, it will Note that if PE1 is not attached to the source BD, it will
regard the SBD as the apparent source BD.) regard the SBD as the apparent source BD.)
<list style="format %c."> </t>
<t> <ol spacing="normal" type="a"><li>
The frame MUST be sent on all local ACs in the OIF list that <t>
connect to BD1 and that are eligible (per <xref The frame <bcp14>MUST</bcp14> be sent on all local ACs in the
target="ac_eligibility"/>) to receive the frame. OIF list that
</t> connect to BD1 and that are eligible (per <xref target="ac_el
<t> igibility" format="default"/>) to receive the frame.
The frame MUST be sent up the IRB interface of the </t>
</li>
<li>
<t>
The frame <bcp14>MUST</bcp14> be sent up the IRB interface of
the
apparent source BD. (Note that this may be the SBD.) The apparent source BD. (Note that this may be the SBD.) The
frame MUST NOT be sent up any other IRB interfaces. frame <bcp14>MUST NOT</bcp14> be sent up any other IRB interf
</t> aces.
<t> </t>
If PE1 is not an AR&nbhy;REPLICATOR, it MUST NOT send the </li>
frame to any other EVPN&nbhy;PEs. However, if PE1 is an <li>
AR&nbhy;REPLICATOR, it MUST send the frame to all tunnels <t>
If PE1 is not an AR-REPLICATOR, it <bcp14>MUST NOT</bcp14> se
nd the
frame to any other EVPN PEs. However, if PE1 is an
AR-REPLICATOR, it <bcp14>MUST</bcp14> send the frame to all t
unnels
in the OIF list, except for the tunnel over which the in the OIF list, except for the tunnel over which the
frame was received. frame was received.
</t> </t>
</list> </li>
</t> </ol>
<t> </li>
<li>
<t>
The frame was received by PE1 from the BD1 IRB interface The frame was received by PE1 from the BD1 IRB interface
(i.e., the frame has been transmitted by PE1's L3 routing (i.e., the frame has been transmitted by PE1's L3 routing
instance down the BD1 IRB interface), and BD1 is NOT the instance down the BD1 IRB interface), and BD1 is NOT the
SBD. SBD.
<list style="format %c."> </t>
<t> <ol spacing="normal" type="a"><li>
The frame MUST be sent on all local ACs in the OIF list <t>
that are eligible, as per <xref target="ac_eligibility"/>, The frame <bcp14>MUST</bcp14> be sent on all local ACs in the
OIF list
that are eligible, as per <xref target="ac_eligibility" forma
t="default"/>,
to receive the frame. to receive the frame.
</t> </t>
<t> </li>
The frame MUST NOT be sent to any other EVPN&nbhy;PEs. <li>
</t> <t>
<t> The frame <bcp14>MUST NOT</bcp14> be sent to any other EVPN P
The frame MUST NOT be sent up any IRB interfaces. Es.
</t> </t>
</list> </li>
</t> <li>
<t> <t>
The frame <bcp14>MUST NOT</bcp14> be sent up any IRB interfac
es.
</t>
</li>
</ol>
</li>
<li>
<t>
The frame was received from the SBD IRB interface (i.e., has The frame was received from the SBD IRB interface (i.e., has
been transmitted by PE1's L3 routing instance down the SBD been transmitted by PE1's L3 routing instance down the SBD
IRB interface). IRB interface).
<list style="format %c."> </t>
<t> <ol spacing="normal" type="a"><li>
The frame MUST be sent on all tunnels in the OIF list. <t>
The frame <bcp14>MUST</bcp14> be sent on all tunnels in the O
IF list.
This causes the frame to be delivered to any other This causes the frame to be delivered to any other
EVPN&nbhy;PEs that have interest in it. EVPN PEs that have interest in it.
</t> </t>
<t> </li>
The frame MUST NOT be sent on any local ACs. <li>
</t> <t>
<t> The frame <bcp14>MUST NOT</bcp14> be sent on any local ACs.
The frame MUST NOT be sent up any IRB interfaces. </t>
</t> </li>
</list> <li>
</t> <t>
</list> The frame <bcp14>MUST NOT</bcp14> be sent up any IRB interfac
</t> es.
</section> <!-- oif_apply --> </t>
</section> <!-- iif_oif --> </li>
</ol>
<!-- <section title="OIF List and Tunnels to other EVPN&nbhy;PEs" </li>
--> </ol>
<!-- anchor="oif_tunnels"> --> </section>
<!-- <t> --> </section>
<!-- When using MPLS to tunnel an IP multicast frame from one PE to </section>
--> <section anchor="rpf" numbered="true" toc="default">
<!-- another, the frame will always carry a label that is specific t <name>Layer 3 Forwarding State</name>
o --> <t>
<!-- a BD. We will refer to this as the "BD label". In order to -- 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
<!-- tunnel the packet, one first pushes on the ESI label, then the Layer 2 multicast state. It also sends those messages up that BD's
--> IRB interface to the L3 routing instance of a particular Tenant
<!-- BD label. These labels will be examined by the egress PE(s). - Domain. This causes the (C-S,C-G) or
-> (C-*,C-G) L3 state to be created/updated.
<!-- Then one pushes on whatever additional labels are needed to --> </t>
<!-- transport the packet to the egress PE(s). --> <t>
<!-- </t> --> A Layer 3 multicast state has both an Input Interface (IIF) and an
<!-- <t> -->
<!-- <cref source=" ECR"> -->
<!-- Did I get the ESI order right? -->
<!-- </cref> -->
<!-- </t> -->
<!-- <t> -->
<!-- This section specifies how the proper BD label is chosen for --
>
<!-- each type of tunnel. It also discusses other procedures that -
->
<!-- are specific to particular tunnel types. -->
<!-- </t> -->
<!-- <t> -->
<!-- <cref source=" ECR"> -->
<!-- I guess we should also say how to do this with VXLAN. -->
<!-- </cref> -->
<!-- </t> -->
<!-- <section title="Ingress Replication" anchor="oif_ir"> -->
<!-- <t> -->
<!-- This section applies when Ingress Replication is the techniqu
e -->
<!-- used to tunnel IP multicast frames to other EVPN&nbhy;PEs of a
-->
<!-- Tenant Domain. -->
<!-- </t> -->
<!-- <t> -->
<!-- When an ingress EVPN&nbhy;PE builds its L2 forwarding state for
-->
<!-- (S,G), it needs to determine all the egress EVPN&nbhy;PEs that
are -->
<!-- interested in (S,G). How it does this is discussed in <xref
-->
<!-- target="cp_overview"/> and in <xref target="interest"/>. -->
<!-- </t> -->
<!-- <t> -->
<!-- Then for each egress EVPN&nbhy;PE, the ingress PE needs to -->
<!-- encapsulate the frame in an MPLS packet. It first pushes on
-->
<!-- the ESI label. It pushes on a BD label that was assigned by
-->
<!-- the egress PE. This label will have been advertised in a PTA
-->
<!-- attached to an IMET route originated by that egress PE. -->
<!-- </t> -->
<!-- <t> -->
<!-- To find the proper BD label, the ingress PE needs to examine
-->
<!-- the IMET routes received from the egress PE. There are two -
->
<!-- cases to consider: -->
<!-- <list style="numbers"> -->
<!-- <t> -->
<!-- There is an installed IMET route from the egress PE for
-->
<!-- the source BD of the IP multicast frame. In this case,
-->
<!-- the label is taken from the PTA of that route. -->
<!-- </t> -->
<!-- <t> -->
<!-- There is no installed IMET route from the egress PE for
-->
<!-- the source BD of the IP multicast frame. In this case,
-->
<!-- there should be an installed IMET route from the egress
-->
<!-- PE for the SBD. The label is taken from the PTA of tha
t -->
<!-- route. -->
<!-- </t> -->
<!-- </list> -->
<!-- </t> -->
<!-- <t> -->
<!-- If neither case holds, there is an error, and the egress PE -
->
<!-- in question will not receive the (S,G) frame. -->
<!-- </t> -->
<!-- <t> -->
<!-- The OIF list for a given multicast state must be constructed
-->
<!-- such that a copy of the frame is sent to each interested -->
<!-- egress PE, with the proper BD label for that egress PE. -->
<!-- </t> -->
<!-- <t> -->
<!-- When a frame is received by a given PE over an MPLS ingress -
->
<!-- replication tunnel, its top label will be label that was -->
<!-- assigned by the receiving PE to a specific BD (possibly the -
->
<!-- SBD). The receiving PE can thus infer the source BD of the -
->
<!-- frame. -->
<!-- </t> -->
<!-- </section> <!-\- oif_ir -\-> -->
<!-- <section title="BIER" anchor="oif_bier"> -->
<!-- <t> -->
<!-- Please refer to <xref target="I-D.ietf-bier-evpn"/> for detai
ls. -->
<!-- </t> -->
<!-- <t> -->
<!-- <cref source=" ECR"> -->
<!-- I'm assuming that everything is covered in that draft, and
-->
<!-- we don't have to say anything in this draft. What do you -
->
<!-- think? -->
<!-- </cref> -->
<!-- </t> -->
<!-- </section> <!-\- oif_bier -\-> -->
<!-- <section title="P2MP LSPs" anchor="oif_p2mp"> -->
<!-- <section title="RSVP-TE P2MP" anchor="oif_rsvp"> -->
<!-- <t> -->
<!-- The procedure for using RSVP-TE P2MP to set up an inclusive -->
<!-- tunnel is as follows. -->
<!-- </t> -->
<!-- <t> -->
<!-- In case of RSVP-TE P2MP, the source NVE establishes a -->
<!-- P2MP tunnel to all remote NVEs found through the SBD's IMET -->
<!-- routes and advertises the tunnel in the IMET route for the -->
<!-- source subnet. If tunnel aggregation is not used, a remote NVE
-->
<!-- attached to the source subnet binds the incoming tunnel branch
-->
<!-- to the source subnet, and a remote NVE that is not attached to
-->
<!-- the source subnet binds the incoming tunnel branch to the SBD.
-->
<!-- </t> -->
<!-- <t> -->
<!-- In case of BIER, or if tunnel aggregation is used for -->
<!-- mLDP/RSVP-TE P2MP, a remote NVE binds the upstream allocated --
>
<!-- label in the IMET route for a source subnet to that subnet if i
t -->
<!-- is present on the NVE. Otherwise it binds the label to the SBD.
-->
<!-- </t> -->
<!-- </section> <!-\- oif_rsvp -\-> -->
<!-- <section title="PIM or mLDP" anchor="oif_pim_mldp"> -->
<!-- <t> -->
<!-- In case of PIM/mLDP, a remote NVE joins the tunnel advertised i
n -->
<!-- the IMET route for a source subnet. If tunnel aggregation is no
t -->
<!-- used, a remote NVE attached to the source subnet binds the -->
<!-- incoming tunnel branch to the source subnet, and a remote NVE -
->
<!-- that is not attached to the source subnet binds the incoming --
>
<!-- tunnel branch to the SBD. -->
<!-- </t> -->
<!-- </section> <!-\- oif-pim_mldp -\-> -->
<!-- </section> <!-\- oif_p2mp -\-> -->
<!-- </section> <!-\- oif_tunnels -\-> -->
</section> <!-- l2_mcast_state -->
<section title="Layer 3 Forwarding State" anchor="rpf">
<t>
If an EVPN&nbhy;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 multicast state. It also sends those messages up that BD's
IRB interface to the L3 routing instance of a particular tenant
domain. This causes (C&nbhy;S,C&nbhy;G) or
(C&nbhy;*,C&nbhy;G) L3 state to be created/updated.
</t>
<t>
A layer 3 multicast state has both an Input Interface (IIF) and an
OIF list. OIF list.
</t> </t>
<t> <t>
For a (C&nbhy;S,C&nbhy;G) state, if the source BD is present on the PE, For a (C-S,C-G) state, if the source BD is present on the PE,
the IIF is set to the IRB 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.
</t> </t>
<!--t>
<cref source=" ECR">
And if S is an unknown address? No one else seems bothered by the
fact that we might need to do an RPF check against an unknown
address, is there something I am not understanding?
</cref>
</t-->
<t> <t>
For (C&nbhy;*,C&nbhy;G) states, traffic can arrive from any BD, so 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 the IIF needs to be set to a wildcard value meaning "any IRB
interface". interface".
</t> </t>
<t> <t>
The OIF list of these states includes one or more of the IRB The OIF list of these states includes one or more of the IRB
interfaces of the Tenant Domain. In general, maintenance of the OIF interfaces of the Tenant Domain. In general, maintenance of the OIF
list does not require any EVPN-specific procedures. However, there list does not require any EVPN-specific procedures. However, there
is one EVPN-specific rule: is one EVPN-specific rule:
<list> </t>
<t> <t indent="3">
If the IIF is one of the IRB interfaces (or the wild card If the IIF is one of the IRB interfaces (or the wildcard
meaning "any IRB interface"), then the SBD IRB interface MUST meaning "any IRB interface"), then the SBD IRB interface <bcp14>MUST
NOT be added to the OIF list. Traffic originating from within a NOT</bcp14> be added to the OIF list. Traffic originating from with
in a
particular EVPN Tenant Domain must not be sent down the SBD IRB particular EVPN Tenant Domain must not be sent down the SBD IRB
interface, as such traffic has already been distributed to all interface, as such traffic has already been distributed to all
EVPN&nbhy;PEs attached to that Tenant Domain. EVPN PEs attached to that Tenant Domain.
</t> </t>
</list> <t>
</t> Please also see <xref target="gen_prin" format="default"/>, which states
<t> a
Please also see <xref target="gen_prin"/>, which states a
modification of this rule for the case where OISM is interworking modification of this rule for the case where OISM is interworking
with external Layer 3 multicast routing. with external Layer 3 multicast routing.
</t> </t>
</section>
</section> <!-- rpf --> </section>
</section> <!-- mcast_state --> <section anchor="no-OISM" numbered="true" toc="default">
<name>Interworking with Non-OISM EVPN PEs</name>
<section title="Interworking with non&nbhy;OISM EVPN&nbhy;PEs" anchor="no-OISM"> <t>
<t>
It is possible that a given Tenant Domain will be attached to both OISM It is possible that a given Tenant Domain will be attached to both OISM
PEs and non&nbhy;OISM PEs. Inter&nbhy;subnet IP multicast should be PEs and non-OISM PEs. Inter-subnet IP multicast should be
possible and fully functional even if not all PEs attaching to a Tenant possible and fully functional even if not all PEs attaching to a Tenant
Domain can be upgraded to support OISM functionality. Domain can be upgraded to support OISM functionality.
</t>
<t>
Note that the non&nbhy;OISM PEs are not required to have IRB support, or
support for <xref target="RFC9251"/>. It is however advantageous for
the non&nbhy;OISM PEs to support <xref target="RFC9251"/>.
</t>
<t>
In this section, we will use the following terminology:
<list style="symbols">
<t>
PE&nbhy;S: the ingress PE for an (S,G) flow.
</t> </t>
<t> <t>
PE&nbhy;R: an egress PE for an (S,G) flow. Note that the non-OISM PEs are not required to have IRB support or
support for <xref target="RFC9251" format="default"/>. However, it is advan
tageous for
the non-OISM PEs to support <xref target="RFC9251" format="default"/>.
</t> </t>
<t> <t>
BD&nbhy;S: the source BD for an (S,G) flow. PE&nbhy;S must have one In this section, we will use the following terminology:
or more ACs attached BD&nbhy;S, at least one of which attaches to
host S.
</t> </t>
<dl spacing="normal" newline="false">
<dt>PE-S:</dt> <dd>The ingress PE for an (S,G) flow.</dd>
<dt>PE-R:</dt> <dd>An egress PE for an (S,G) flow.</dd>
<dt>BD-S:</dt> <dd>The source BD for an (S,G) flow. PE-S must have on
e
or more ACs attached to BD-S, at least one of which attaches to
host S.</dd>
<dt>BD-R:</dt> <dd>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.</dd>
</dl>
<t> <t>
BD&nbhy;R: a BD that contains a host interested in the flow. The To allow OISM PEs to interwork with non-OISM PEs, a given Tenant
host is attached to PE&nbhy;R via an AC that belongs to BD&nbhy;R. Domain needs to contain one or more IP Multicast Gateways (IPMGs). An
</t>
</list>
</t>
<t>
To allow OISM PEs to interwork with non&nbhy;OISM PEs, a given Tenant
Domain needs to contain one or more "IP Multicast Gateways" (IPMGs). An
IPMG is an OISM PE with special responsibilities regarding the IPMG is an OISM PE with special responsibilities regarding the
interworking between OISM and non&nbhy;OISM PEs. interworking between OISM and non-OISM PEs.
</t> </t>
<t> <t>
If a PE is functioning as an IPMG, it MUST signal this fact by setting If a PE is functioning as an IPMG, it <bcp14>MUST</bcp14> signal this fact b
the "IPMG" flag in the Multicast Flags EC that it attaches to its IMET y setting
routes. An IPMG SHOULD attach this EC, with the IPMG flag set, to all the IPMG flag in the Multicast Flags EC that it attaches to its IMET
routes. An IPMG <bcp14>SHOULD</bcp14> attach this EC, with the IPMG flag se
t, to all
IMET routes it originates. Furthermore, if PE1 imports any IMET route from IMET routes it originates. Furthermore, if PE1 imports any IMET route from
PE2 that has the EC present with the "IPMG" flag set, then the PE1 will PE2 that has the EC present with the IPMG flag set, then the PE1 will
assume that PE2 is an IPMG. assume that PE2 is an IPMG.
</t> </t>
<t>
An IPMG Designated Forwarder (IPMG&nbhy;DF) selection procedure is used
to ensure that, at any given time, there is exactly one active
IPMG&nbhy;DF for any given BD. Details of the IPMG&nbhy;DF selection
procedure are in <xref target="ipmg-df"/>. The IPMG&nbhy;DF for a given
BD, say BD&nbhy;S, has special functions to perform when it receives
(S,G) frames on that BD:
<list style="symbols">
<t> <t>
If the frames are from a non&nbhy;OISM PE&nbhy;S: An IPMG Designated Forwarder (IPMG-DF) selection procedure is used
<list style="symbols"> to ensure that there is exactly one active
IPMG-DF for any given BD at any given time. Details of the IPMG-DF selection
procedure are in <xref target="ipmg-df" format="default"/>. The IPMG-DF for
a given
BD, say BD-S, has special functions to perform when it receives
(S,G) frames on that BD:
</t>
<ul spacing="normal">
<li>
<t> <t>
The IPMG&nbhy;DF forwards them to OISM PEs that do not attach to If the frames are from a non-OISM PE-S:
BD&nbhy;S but have interest in (S,G).
<vspace/>
<vspace/>
Note that OISM PEs that do attach to BD&nbhy;S will have
received the frames on the BUM tunnel from the non&nbhy;OISM
PE&nbhy;S.
</t> </t>
<t> <ul spacing="normal">
The IPMG&nbhy;DF forwards them to non&nbhy;OISM PEs that have <li>
interest in (S,G) on ACs that do not belong to BD&nbhy;S. <t>
<vspace/> The IPMG-DF forwards them to OISM PEs that do not attach to
<vspace/> BD-S but have interest in (S,G).
Note that if a non&nbhy;OISM PE has multiple BDs (other than </t>
BD&nbhy;S) with interest in (S,G), it will receive one copy of <t>
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.
</t>
</li>
<li>
<t>
The IPMG-DF forwards them to non-OISM PEs that have
interest in (S,G) on ACs that do not belong to BD-S.
</t>
<t>
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 for each such BD. This is necessary because the the frame for each such BD. This is necessary because the
non&nbhy;OISM PEs cannot move IP multicast traffic from one BD non-OISM PEs cannot move IP multicast traffic from one BD
to another. to another.
</t>
</li>
</ul>
</li>
<li>
<t>
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 to BD-S.
</t> </t>
</list> <t>
</t> 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 BD-S, from the OISM PE-S (see <xref target="imet-ir" fo
rmat="default"/>). If the non-OISM 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 IPMG-DF needs to
send it a copy of the frame for each BD-Ri.
</t>
</li>
</ul>
<t> <t>
If the frames are from an OISM PE, the IPMG&nbhy;DF forwards them to
non&nbhy;OISM PEs that have interest in (S,G) on ACs that do not
belong to BD&nbhy;S.
<vspace/>
<vspace/>
If a non&nbhy;OISM PE has interest in (S,G) on an AC belonging to
BD&nbhy;S, it will have received a copy of the (S,G) frame,
encapsulated for BD&nbhy;S, from the OISM PE&nbhy;S. (See <xref
target="imet-ir"/>.) If the non&nbhy;OISM PE has interest in (S,G)
on one or more ACs belonging to BD&nbhy;R1,...,BD&nbhy;Rk where the
BD&nbhy;Ri are distinct from BD&nbhy;S, the IPMG&nbhy;DF needs to
send it a copy of the frame for each BD&nbhy;Ri.
</t>
</list>
</t>
<t>
If an IPMG receives a frame on a BD for which it is not the If an IPMG receives a frame on a BD for which it is not the
IPMG&nbhy;DF, it just follows normal OISM procedures. IPMG-DF, it just follows normal OISM procedures.
</t>
<t>
This section specifies several sets of procedures:
<list style="symbols">
<t>
the procedures that the IPMG&nbhy;DF for a given BD needs to follow
when receiving, on that BD, an IP multicast frame from a
non&nbhy;OISM PE;
</t> </t>
<t> <t>
the procedures that the IPMG&nbhy;DF for a given BD needs to follow This section specifies several sets of procedures:
when receiving, on that BD, an IP multicast frame from an OISM PE;
</t> </t>
<t> <ul spacing="normal">
<li>
<t>
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 PE;
</t>
</li>
<li>
<t>
the procedures that the IPMG-DF for a given BD needs to follow
when receiving, on that BD, an IP multicast frame from an OISM PE; and
</t>
</li>
<li>
<t>
the procedures that an OISM PE needs to follow when receiving, on a the procedures that an OISM PE needs to follow when receiving, on a
given BD, an IP multicast frame from a non&nbhy;OISM PE, when the given BD, an IP multicast frame from a non-OISM PE, when the
OISM PE is not the IPMG&nbhy;DF for that BD. OISM PE is not the IPMG-DF for that BD.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
To enable OISM/non&nbhy;OISM interworking in a given Tenant Domain, the To enable OISM/non-OISM interworking in a given Tenant Domain, the
Tenant Domain MUST have some EVPN&nbhy;PEs that can function as IPMGs. Tenant Domain <bcp14>MUST</bcp14> have some EVPN PEs that can function as IP
MGs.
An IPMG must be configured with the SBD. It must also be configured An IPMG must be configured with the SBD. It must also be configured
with every BD of the Tenant Domain that exists on any of the with every BD of the Tenant Domain that exists on any of the
non&nbhy;OISM PEs of that domain. (Operationally, it may be simpler to non-OISM PEs of that domain. (Operationally, it may be simpler to
configure the IPMG with all the BDs of the Tenant Domain.) configure the IPMG with all the BDs of the Tenant Domain.)
</t> </t>
<t> <t>
A non&nbhy;OISM PE of course only needs to be configured with BDs for Of course, a non-OISM PE only needs to be configured with BDs for
which it has ACs. An OISM PE that is not an IPMG only needs to be which it has ACs. An OISM PE that is not an IPMG only needs to be
configured with the SBD and with the BDs for which it has ACs. configured with the SBD and with the BDs for which it has ACs.
</t> </t>
<t> <t>
An IPMG MUST originate a wildcard SMET route (with (C&nbhy;*,C&nbhy;*) An IPMG <bcp14>MUST</bcp14> originate a wildcard SMET route (with (C-*,C-*)
in the NLRI) for each BD in the Tenant Domain. This will cause it to in the NLRI) for each BD in the Tenant Domain. This will cause it to
receive all the IP multicast traffic that is sourced in the Tenant receive all the IP multicast traffic that is sourced in the Tenant
Domain. Note that non&nbhy;OISM nodes that do not support <xref Domain. Note that non-OISM nodes that do not support <xref target="RFC9251"
target="RFC9251"/> will send all the multicast traffic from a given format="default"/> will send all the multicast traffic from a given
BD to all PEs attached to that BD, even if those PEs do not originate an BD to all PEs attached to that BD, even if those PEs do not originate a
SMET route. SMET route.
</t> </t>
<t> <t>
The interworking procedures vary somewhat depending upon whether packets The interworking procedures vary somewhat depending upon whether packets
are transmitted from PE to PE via Ingress Replication (IR) or via are transmitted from PE to PE via IR or via
Point-to-Multipoint (P2MP) tunnels. We do not consider the use of BIER P2MP tunnels. In this section, we do not consider the use of BIER
in this section, due to the low likelihood of there being a due to the low likelihood of there being a
non&nbhy;OISM PE that supports BIER. non-OISM PE that supports BIER.
</t> </t>
<section title="IPMG Designated Forwarder" anchor="ipmg-df"> <section anchor="ipmg-df" numbered="true" toc="default">
<!-- <t> --> <name>IPMG Designated Forwarder</name>
<!-- Each IPMG for a given Tenant Domain MUST be configured with an "IPMG
-->
<!-- Ethernet Segment" for that domain. This is an Ethernet Segment that
-->
<!-- has no ACs. Conceptually, it represents the set of non-OISM PEs -->
<!-- contained in the Tenant Domain. In the control plane, this Ethernet
-->
<!-- Segment is identified by an ESI of Type 0; thus the ESI is an -->
<!-- arbitrary 9-octet value, managed and configured by the operator. -->
<!-- </t> -->
<!-- <t> -->
<!-- EVPN supports a number of procedures that can be used to select the -
->
<!-- Designated Forwarder (DF) for a particular BD on a particular Etherne
t -->
<!-- segment. Some of the possible procedures can be found, e.g., in <xre
f -->
<!-- target="RFC7432"/>, <xref target="EVPN-DF-NEW"/>, and <xref -->
<!-- target="I-D.ietf-bess-evpn-pref-df"/>. Whatever procedure is in use
in a given -->
<!-- deployment can be adapted to select an IPMG&nbhy;DF for a given BD, a
s -->
<!-- follows. -->
<!-- </t> -->
<!-- <t> -->
<!-- Each IPMG will originate an Ethernet Segment route for the IPMG dummy
-->
<!-- Ethernet segment. It MUST carry an ES-Import Route Target whose valu
e -->
<!-- is set to the high-order 6-octets of the IPMG ESI. Thus only IPMGs -
->
<!-- will import the route. -->
<!-- </t> -->
<!-- <t> -->
<!-- Once the set of IPMGs is known, it is also possible to determine the
-->
<!-- set of BDs supported by each IPMG. The DF selection procedure can --
>
<!-- then be used to choose a DF for each BD. (The conditions under which
-->
<!-- the IPMG&nbhy;DF for a given BD changes depends upon the DF selection
-->
<!-- algorithm that is in use.) -->
<!-- </t> -->
<t> <t>
Every PE that is eligible for selection as an IPMG&nbhy;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&nbhy;IMET route. As stated in <xref target="no-OISM"/>, these SBD-IMET route. As stated in <xref target="no-OISM" format="default"/>, t
SBD&nbhy;IMET routes carry a Multicast Flags EC with the IPMG Flag hese
SBD-IMET routes carry a Multicast Flags EC with the IPMG flag
set. set.
</t>
<t>
These SBD&nbhy;IMET routes SHOULD also carry a DF Election EC. The DF
Election EC and its use is specified in <xref
target="RFC8584"/>. When the route is originated, the
AC&nbhy;DF bit in the DF Election EC SHOULD not be set. This bit
is not used when selecting an IPMSG&nbhy;DF, i.e., it MUST be ignored
by the receiver of an SBD&nbhy;IMET route.
</t>
<t>
In the context of a given Tenant Domain, to select the IPMG&nbhy;DF
for a particular BD, say BD1, the IPMGs of the Tenant Domain perform
the following procedure:
<list style="symbols">
<t>
From the set of received SBD&nbhy;IMET routes for the given tenant
domain, determine the candidate set of PEs that support IPMG
functionality for that domain.
</t> </t>
<t> <t>
Eliminate from that candidate set any PEs from which an IMET route These SBD-IMET routes <bcp14>SHOULD</bcp14> also carry a DF Election EC.
for BD1 has not been received. The DF
Election EC and its use is specified in <xref target="RFC8584" format="def
ault"/>. When the route is originated, the
AC-DF bit in the DF Election EC <bcp14>SHOULD NOT</bcp14> be set. This bit
is not used when selecting an IPMG-DF, i.e., it <bcp14>MUST</bcp14> be ign
ored
by the receiver of an SBD-IMET route.
</t> </t>
<t> <t>
Select a DF Election algorithm as specified in <xref In the context of a given Tenant Domain, to select the IPMG-DF
target="RFC8584"/>. Some of the possible algorithms for a particular BD, say BD1, the IPMGs of the Tenant Domain perform
can be found, e.g., in <xref target="RFC8584"/>, the following procedures:
<xref target="RFC7432"/>, and <xref target="I-D.ietf-bess-evpn-pref-df
"/>.
</t> </t>
<ul spacing="normal">
<li>
<t>
From the set of received SBD-IMET routes for the given Tenant
Domain, determine the candidate set of PEs that support IPMG
functionality for that domain.
</t>
</li>
<li>
<t>
From that candidate set, eliminate any PEs from which an IMET route
for BD1 has not been received.
</t>
</li>
<li>
<t>
Select a DF election algorithm as specified in <xref target="RFC8584"
format="default"/>. Some of the possible algorithms
can be found, e.g., in <xref target="RFC8584" format="default"/>,
<xref target="RFC7432" format="default"/>, and <xref target="I-D.ietf-
bess-evpn-pref-df" format="default"/>.
</t>
</li>
<li>
<t>
Apply the DF election algorithm (see <xref target="RFC8584" format="de
fault"/>) to the candidate set of PEs.
The winner becomes the IPMG-DF for BD1.
</t>
</li>
</ul>
<t> <t>
Apply the DF Election Algorithm (see <xref Note that even if a given PE supports MEG (<xref target="mvpn" format="def
target="RFC8584"/>) to the candidate set of PEs. ault"/>)
The "winner' becomes the IPMG-DF for BD1. and/or PEG (<xref target="pim_iwork" format="default"/>) functionality, as
well as IPMG
functionality, its SBD-IMET routes carry only one DF Election EC.
</t> </t>
</list> </section>
</t> <section anchor="non-OISM-IR" numbered="true" toc="default">
<t> <name>Ingress Replication</name>
Note that even if a given PE supports MEG <xref target="mvpn"/>) <t>
and/or PEG (<xref target="pim_iwork"/>) functionality, as well as IPMG The procedures of this section are used when IR is
functionality, its SBD&nbhy;IMET routes carry only one DF Election EC.
</t>
</section> <!-- ipmg_df -->
<section title="Ingress Replication" anchor="non-OISM-IR">
<t>
The procedures of this section are used when Ingress Replication is
used to transmit packets from one PE to another. used to transmit packets from one PE to another.
</t> </t>
<t> <t>
When a non&nbhy;OISM PE&nbhy;S transmits a multicast frame from When a non-OISM PE-S transmits a multicast frame from
BD&nbhy;S to another PE, PE&nbhy;R, PE&nbhy;S will use the BD-S to another PE, say PE-R, PE-S will use the
encapsulation specified in the BD&nbhy;S IMET route that was encapsulation specified in the BD-S IMET route that was
originated by PE&nbhy;R. This encapsulation will include the label originated by PE-R. This encapsulation will include the label
that appears in the "MPLS label" field of the PMSI Tunnel attribute that appears in the MPLS Label field of the
(PTA) of the IMET route. If the tunnel type is VXLAN, the "label" is PTA of the IMET route. If the tunnel type is VXLAN, the label is
actually a Virtual Network Identifier (VNI); for other tunnel types, actually a Virtual Network Identifier (VNI); for other tunnel types,
the label is an MPLS label. In either case, we will speak of the the label is an MPLS label. In either case,
transmitted frames as carrying a label that was assigned to a the frames are transmitted with a label that was assigned to a
particular BD by the PE&nbhy;R to which the frame is being particular BD by the PE-R to which the frame is being
transmitted. transmitted.
</t> </t>
<t> <t>
To support OISM/non&nbhy;OISM interworking, an OISM PE&nbhy;R MUST To support OISM/non-OISM interworking, an OISM PE-R <bcp14>MUST</bcp14>
originate, for each of its BDs, both an IMET route and an S&nbhy;PMSI originate, for each of its BDs, both an IMET route and an (C-*,C-*)
(C&nbhy;*,C&nbhy;*) A&nbhy;D route. Note that even when IR is being S-PMSI A-D route. Note that even when IR is being
used, interworking between OISM and non&nbhy;OISM PEs requires the used, interworking between OISM and non-OISM PEs requires the
OISM PEs to follow the rules of <xref target="wc_spmsi"/>, as modified OISM PEs to follow the rules of <xref target="wc_spmsi" format="default"/>
, as modified
below. below.
</t> </t>
<t> <t>
Non&nbhy;OISM PEs will not understand S&nbhy;PMSI A&nbhy;D routes. So Non-OISM PEs will not understand S-PMSI A-D routes. So
when a non&nbhy;OISM PE&nbhy;S transmits an IP multicast frame with a when a non-OISM PE-S transmits an IP multicast frame with a
particular source BD to an IPMG, it encapsulates the frame using the particular source BD to an IPMG, it encapsulates the frame using the
label specified in that IPMG's BD&nbhy;S IMET route. (This is just label specified in that IPMG's BD-S IMET route. (This is just
the procedure of <xref target="RFC7432"/>.) the procedure of <xref target="RFC7432" format="default"/>.)
</t> </t>
<t>
The (C&nbhy;*,C&nbhy;*) S&nbhy;PMSI A&nbhy;D route originated by a
given OISM PE will have a PTA that specifies IR.
<list style="symbols">
<t> <t>
If MPLS tunneling is being used, the MPLS label field SHOULD The (C-*,C-*) S-PMSI A-D route originated by a
contain a non&nbhy;zero value, and the LIR flag SHOULD be zero. given OISM PE will have a PTA that specifies IR.
(The case where the MPLS label field is zero or the LIR flag is
set is outside the scope of this document.)
</t> </t>
<ul spacing="normal">
<li>
<t>
If MPLS tunneling is being used, the MPLS Label field <bcp14>SHOULD</b
cp14>
contain a non-zero value, and the LIR flag <bcp14>SHOULD</bcp14> be ze
ro.
(The case where the MPLS Label field is zero or the LIR flag is
set is outside the scope of this document.)
</t>
</li>
<li>
<t>
If the tunnel encapsulation is VXLAN, the MPLS Label field <bcp14>MUST
</bcp14>
contain a non-zero value, and the LIR flag <bcp14>MUST</bcp14> be zero
.
</t>
</li>
</ul>
<t> <t>
If the tunnel encapsulation is VXLAN, the MPLS label field MUST When an OISM PE-S transmits an IP multicast frame to an IPMG, it
contain a non&nbhy;zero value, and the LIR flag MUST be zero. will use the label specified in that IPMG's (C-*,C-*)
S-PMSI A-D route.
</t> </t>
</list> <t>
</t> When a PE originates both an IMET route and a (C-*,C-*)
<t> S-PMSI A-D route, the values of the MPLS Label field in the
When an OISM PE&nbhy;S transmits an IP multicast frame to an IPMG, it respective PTAs must be distinct. Further, each <bcp14>MUST</bcp14> map u
will use the label specified in that IPMG's (C&nbhy;*,C&nbhy;*) niquely (in
S&nbhy;PMSI A&nbhy;D route.
</t>
<t>
When a PE originates both an IMET route and a (C&nbhy;*,C&nbhy;*)
S&nbhy;PMSI A&nbhy;D route, the values of the MPLS label field in the
respective PTAs must be distinct. Further, each MUST map uniquely (in
the context of the originating PE) to the route's BD. the context of the originating PE) to the route's BD.
</t> </t>
<!-- <t> -->
<!-- In MPLS networks, it is also possible to originate an S&nbhy;PMSI A-D r
oute -->
<!-- whose PTA specifies a zero in the MPLS label field, and whose "PTA --
>
<!-- flags" field has the "Leaf Information Required" bit set. This will
-->
<!-- cause each OISM PE to send a Leaf A-D route to each other OISM PE, --
>
<!-- specifying the label to use when transmitting to it a frame of the --
>
<!-- corresponding source BD. -->
<!-- </t> -->
<t> <t>
As a result, an IPMG receiving an MPLS-encapsulated IP multicast frame As a result, an IPMG receiving an MPLS-encapsulated IP multicast frame
can always tell by the label whether the frame's ingress PE is an OISM can always tell by the label whether the frame's ingress PE is an OISM
PE or a non&nbhy;OISM PE. When an IPMG receives a VXLAN-encapsulated PE or a non-OISM PE. When an IPMG receives a VXLAN-encapsulated
IP multicast frame it may need to determine the identity of the IP multicast frame, it may need to determine the identity of the
ingress PE from the outer IP encapsulation; it can then determine ingress PE from the outer IP encapsulation; it can then determine
whether the ingress PE is an OISM PE or a non&nbhy;OISM PE by looking whether the ingress PE is an OISM PE or a non-OISM PE by looking at
the IMET route from that PE. the IMET route from that PE.
</t> </t>
<t> <t>
Suppose an IPMG receives an IP multicast frame from another Suppose an IPMG receives an IP multicast frame from another
EVPN&nbhy;PE in the Tenant Domain, and the IPMG is not the EVPN PE in the Tenant Domain and the IPMG is not the
IPMG&nbhy;DF for the frame's source BD. Then the IPMG performs only IPMG-DF for the frame's source BD. Then, the IPMG performs only
the ordinary OISM functions; it does not perform the IPMG-specific the ordinary OISM functions; it does not perform the IPMG-specific
functions for that frame. In the remainder of this section, when we functions for that frame. In the remainder of this section, when we
discuss the procedures applied by an IPMG when it receives an IP discuss the procedures applied by an IPMG when it receives an IP
multicast frame, we are presuming that the source BD of the frame is a multicast frame, we are presuming that the source BD of the frame is a
BD for which the IPMG is the IPMG&nbhy;DF. BD for which the IPMG is the IPMG-DF.
</t> </t>
<t> <t>
We have two basic cases to consider: (1) a frame's ingress PE is a We have two basic cases to consider: (1) a frame's ingress PE is a
non&nbhy;OISM node, and (2) a frame's ingress PE is an OISM node. non-OISM node and (2) a frame's ingress PE is an OISM node.
</t> </t>
<section title="Ingress PE is non&nbhy;OISM" anchor="pe-s-non-oism"> <section anchor="pe-s-non-oism" numbered="true" toc="default">
<t> <name>Ingress PE is Non-OISM</name>
In this case, a non&nbhy;OISM PE, PE&nbhy;S, has received an (S,G) <t>
In this case, a non-OISM PE, say PE-S, has received an (S,G)
multicast frame over an AC that is attached to a particular BD, multicast frame over an AC that is attached to a particular BD,
BD&nbhy;S. By virtue of normal EVPN procedures, PE&nbhy;S has sent say BD-S. By virtue of normal EVPN procedures, PE-S has sent
a copy of the frame to every PE&nbhy;R (both OISM and non&nbhy;OISM) a copy of the frame to every PE-R (both OISM and non-OISM)
in the Tenant Domain that is attached to BD&nbhy;S. If the in the Tenant Domain that is attached to BD-S. If the
non&nbhy;OISM node supports <xref target="RFC9251"/>, only PEs non-OISM node supports <xref target="RFC9251" format="default"/>, only P
Es
that have expressed interest in (S,G) receive the frame. The IPMG that have expressed interest in (S,G) receive the frame. The IPMG
will have expressed interest via a (C&nbhy;*,C&nbhy;*) SMET route will have expressed interest via a (C-*,C-*) SMET route
and thus receives the frame. and thus receives the frame.
</t> </t>
<t> <t>
Any OISM PE (including an IPMG) receiving the frame will apply Any OISM PE (including an IPMG) receiving the frame will apply
normal OISM procedures. As a result it will deliver the frame to normal OISM procedures. As a result, it will deliver the frame to
any of its local ACs (in BD&nbhy;S or in any other BD) that have any of its local ACs (in BD-S or in any other BD) that have
interest in (S,G). interest in (S,G).
</t> </t>
<t> <t>
An OISM PE that is also the IPMG&nbhy;DF for a particular BD, say An OISM PE that is also the IPMG-DF for a particular BD, say
BD&nbhy;S, has additional procedures that it applies to frames BD-S, has additional procedures that it applies to frames
received on BD&nbhy;S from non&nbhy;OISM PEs: received on BD-S from non-OISM PEs:
<list style="format %d. "> </t>
<t anchor="non-oism-to-oism"> <ol spacing="normal" type="1"><li anchor="non-oism-to-oism">
When the IPMG&nbhy;DF for BD&nbhy;S receives an (S,G) frame from <t>
a non&nbhy;OISM node, it MUST forward a copy of the frame to When the IPMG-DF for BD-S receives an (S,G) frame from
every OISM PE that is NOT attached to BD&nbhy;S but has interest a non-OISM node, it <bcp14>MUST</bcp14> forward a copy of the frame
in (S,G). The copy sent to a given OISM PE&nbhy;R must carry to
the label that PE&nbhy;R has assigned to the SBD in an every OISM PE that is NOT attached to BD-S but has interest
S&nbhy;PMSI A&nbhy;D route. The IPMG MUST NOT do any IP in (S,G). The copy sent to a given OISM PE-R must carry
the label that PE-R has assigned to the SBD in an
S-PMSI A-D route. The IPMG <bcp14>MUST NOT</bcp14> do any IP
processing of the frame's IP payload. TTL decrement and other processing of the frame's IP payload. TTL decrement and other
IP processing will be done by PE&nbhy;R, per the normal OISM IP processing will be done by PE-R, per the normal OISM
procedures. There is no need for the IPMG to include an ESI procedures. There is no need for the IPMG to include an ESI
label in the frame's tunnel encapsulation, because it is already label in the frame's tunnel encapsulation, because it is already
known that the frame's source BD has no presence on known that the frame's source BD has no presence on
PE&nbhy;R. There is also no need for the IPMG to modify the PE-R. There is also no need for the IPMG to modify the
frame's MAC SA. frame's MAC SA.
</t> </t>
<t anchor="non-oism-to-non-oism"> </li>
In addition, when the IPMG&nbhy;DF for BD&nbhy;S receives an <li anchor="non-oism-to-non-oism">
(S,G) frame from a non&nbhy;OISM node, it may need to forward <t>
copies of the frame to other non&nbhy;OISM nodes. Before it In addition, when the IPMG-DF for BD-S receives an
does so, it MUST decapsulate the (S,G) packet, and do the IP (S,G) frame from a non-OISM node, it may need to forward
processing (e.g., TTL decrement). Suppose PE&nbhy;R is a copies of the frame to other non-OISM nodes. Before it
non&nbhy;OISM node that has an AC to BD&nbhy;R, where BD&nbhy;R does so, it <bcp14>MUST</bcp14> decapsulate the (S,G) packet and do
is not the same as BD&nbhy;S, and that AC has interest in (S,G). the IP
processing (e.g., TTL decrement). Suppose PE-R is a
non-OISM node that has an AC to BD-R, where BD-R
is not the same as BD-S, and that AC has interest in (S,G).
The IPMG must then encapsulate the (S,G) packet (after the IP The IPMG must then encapsulate the (S,G) packet (after the IP
processing has been done) in an Ethernet header. The MAC SA processing has been done) in an Ethernet header. The MAC SA
field will have the MAC address of the IPMG's IRB interface for field will have the MAC address of the IPMG's IRB interface for
BD&nbhy;R. The IPMG then sends the frame to PE&nbhy;R. The BD-R. The IPMG then sends the frame to PE-R. The
tunnel encapsulation will carry the label that PE&nbhy;R tunnel encapsulation will carry the label that PE-R
advertised in its IMET route for BD&nbhy;R. There is no need to advertised in its IMET route for BD-R. There is no need to
include an ESI label, as the source and destination BDs are include an ESI label, as the source and destination BDs are
known to be different. known to be different.
<vspace/> </t>
<vspace/> <t>
Note that if a non&nbhy;OISM PE&nbhy;R has several BDs (other Note that if a non-OISM PE-R has several BDs (other
than BD&nbhy;S) with local ACs that have interest in (S,G), the than BD-S) with local ACs that have interest in (S,G), the
IPMG will send it one copy for each such BD. This is necessary IPMG will send it one copy for each such BD. This is necessary
because the non&nbhy;OISM PE cannot move packets from one BD to because the non-OISM PE cannot move packets from one BD to
another. another.
</t> </t>
</list> </li>
</t> </ol>
<t> <t>
There may be deployment scenarios in which every OISM PE is There may be deployment scenarios in which every OISM PE is
configured with every BD that is present on any non&nbhy;OISM PE. configured with every BD that is present on any non-OISM PE.
In such scenarios, the procedures of item <xref In such scenarios, the procedures of item <xref target="non-oism-to-oism
target="non-oism-to-oism" format="counter"/> above will not actually " format="counter"/> above will not actually
result in the transmission of any packets. Hence if it is known a result in the transmission of any packets. Hence, if it is known a
priori that this deployment scenario exists for a given tenant priori that this deployment scenario exists for a given Tenant
domain, the procedures of item <xref target="non-oism-to-oism" Domain, the procedures of item <xref target="non-oism-to-oism" format="c
format="counter"/> above can be disabled. ounter"/> above can be disabled.
</t> </t>
</section> <!-- PE&nbhy;S-non&nbhy;OISM --> </section>
<section title="Ingress PE is OISM" anchor="pe-s-oism"> <section anchor="pe-s-oism" numbered="true" toc="default">
<t> <name>Ingress PE is OISM</name>
In this case, an OISM PE, PE&nbhy;S, has received an (S,G) multicast
frame over an AC that attaches to a particular BD, BD&nbhy;S.
</t>
<t>
By virtue of receiving all the IMET routes for BD&nbhy;S,
PE&nbhy;S will know all the PEs attached to BD&nbhy;S. By virtue of
normal OISM procedures:
<list style="symbols">
<t> <t>
PE&nbhy;S will send a copy of the frame to every OISM PE&nbhy;R In this case, an OISM PE, say PE-S, has received an (S,G) multicast
(including the IPMG) in the Tenant Domain that is attached to frame over an AC that attaches to a particular BD, say BD-S.
BD&nbhy;S and has interest in (S,G). The copy sent to a given
PE&nbhy;R carries the label that that the PE&nbhy;R has assigned
to BD&nbhy;S in its (C&nbhy;*,C&nbhy;*) S&nbhy;PMSI A&nbhy;D
route.
<!-- or Leaf A-D route. -->
</t> </t>
<t> <t>
PE&nbhy;S will also transmit a copy of the (S,G) frame to every By virtue of receiving all the IMET routes for BD-S,
OISM PE&nbhy;R that has interest in (S,G) but is not attached to PE-S will know all the PEs attached to BD-S. By virtue of
BD&nbhy;S. The copy will contain the label that the PE&nbhy;R normal OISM procedures:
has assigned to the SBD. (As specified in <xref target="pe-s-non-oi </t>
sm"/>, <ul spacing="normal">
<li>
<t>
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 interest in (S,G). The copy sent to a given
PE-R carries the label that the PE-R has assigned
to BD-S in its (C-*,C-*) S-PMSI A-D
route.
</t>
</li>
<li>
<t>
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 copy will contain the label that the PE-R
has assigned to the SBD. (As specified in <xref target="pe-s-non-oi
sm" format="default"/>,
an IPMG is assumed to have indicated interest in all multicast an IPMG is assumed to have indicated interest in all multicast
flows.) flows.)
</t> </t>
</li>
<li>
<t>
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 label advertised by that PE-R in its IMET
route for BD-S.
</t>
</li>
</ul>
<t> <t>
PE&nbhy;S will also transmit a copy of the (S,G) frame to every The PE-Rs follow their normal procedures. An OISM PE that
non&nbhy;OISM PE&nbhy;R that is attached to BD&nbhy;S. It does receives the (S,G) frame on BD-S applies the OISM procedures to
this using the label advertised by that PE&nbhy;R in its IMET deliver the frame to its local ACs as necessary. A non-OISM
route for BD&nbhy;S. PE that receives the (S,G) frame on BD-S delivers the frame
only to its local BD-S ACs as necessary.
</t> </t>
</list> <t>
</t> Suppose that a non-OISM PE-R has interest in (S,G) on a
<t> BD that is different than BD-S, say BD-R. If the
The PE&nbhy;Rs follow their normal procedures. An OISM PE that non-OISM PE-R is attached to BD-S, the OISM PE-S
receives the (S,G) frame on BD&nbhy;S applies the OISM procedures to
deliver the frame to its local ACs, as necessary. A non&nbhy;OISM
PE that receives the (S,G) frame on BD&nbhy;S delivers the frame
only to its local BD&nbhy;S ACs, as necessary.
</t>
<t>
Suppose that a non&nbhy;OISM PE&nbhy;R has interest in (S,G) on a
BD, BD&nbhy;R, that is different than BD&nbhy;S. If the
non&nbhy;OISM PE&nbhy;R is attached to BD&nbhy;S, the OISM PE&nbhy;S
will send it the original (S,G) multicast frame, but the will send it the original (S,G) multicast frame, but the
non&nbhy;OISM PE&nbhy;R will not be able to send the frame to ACs non-OISM PE-R will not be able to send the frame to ACs
that are not in BD&nbhy;S. If PE&nbhy;R is not even attached to that are not in BD-S. If PE-R is not even attached to
BD&nbhy;S, the OISM PE&nbhy;S will not send it a copy of the frame BD-S, the OISM PE-S will not send it a copy of the frame
at all, because PE&nbhy;R is not attached to the SBD. In these at all, because PE-R is not attached to the SBD. In these
cases, the IPMG needs to relay the (S,G) multicast traffic from OISM cases, the IPMG needs to relay the (S,G) multicast traffic from OISM
PE&nbhy;S to non&nbhy;OISM PE&nbhy;R. PE-S to non-OISM PE-R.
</t> </t>
<t> <t>
When the IPMG&nbhy;DF for BD&nbhy;S receives an (S,G) frame from an When the IPMG-DF for BD-S receives an (S,G) frame from an
OISM PE&nbhy;S, it has to forward it to every non&nbhy;OISM OISM PE-S, it has to forward it to every non-OISM
PE&nbhy;R that that has interest in (S,G) on a BD&nbhy;R that is PE-R that has interest in (S,G) on a BD-R that is
different than BD&nbhy;S. The IPMG MUST decapsulate the IP different than BD-S. The IPMG <bcp14>MUST</bcp14> decapsulate the IP
multicast packet, do the IP processing, re-encapsulate it for multicast packet, do the IP processing, re-encapsulate it for
BD&nbhy;R (changing the MAC SA to the IPMG's own MAC address for BD-R (changing the MAC SA to the IPMG's own MAC address for
BD&nbhy;R), and send a copy of the frame to PE&nbhy;R. Note that a BD-R), and send a copy of the frame to PE-R. Note that a
given non&nbhy;OISM PE&nbhy;R will receive multiple copies of the 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 if it has multiple BDs on which there is interest in the
frame. frame.
</t> </t>
</section> <!-- pe-s-oism --> </section>
</section> <!-- non&nbhy;OISM-IR --> </section>
<section anchor="non-oism-p2mp" numbered="true" toc="default">
<section title="P2MP Tunnels" anchor="non-oism-p2mp"> <name>P2MP Tunnels</name>
<t> <t>
When IR is used to distribute the multicast traffic among the When IR is used to distribute the multicast traffic among the
EVPN&nbhy;PEs, the procedures of <xref target="non-OISM-IR"/> ensure EVPN PEs, the procedures described in <xref target="non-OISM-IR" format="d efault"/> ensure
that there will be no duplicate delivery of multicast traffic. That that there will be no duplicate delivery of multicast traffic. That
is, no egress PE will ever send a frame twice on any given AC. If is, no egress PE will ever send a frame twice on any given AC. If
P2MP tunnels are being used to distribute the multicast traffic, it is P2MP tunnels are being used to distribute the multicast traffic, it is
necessary to have additional procedures to prevent duplicate delivery. necessary to have additional procedures to prevent duplicate delivery.
</t> </t>
<t> <t>
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&nbhy;OISM nodes that use 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, P2MP tunnels. If it is determined that there is such a use case,
procedures for P2MP may be specified in a separate document. procedures for P2MP may be specified in a separate document.
</t> </t>
</section>
</section> <!-- non-oism-p2mp --> </section>
<!-- <section title="P2MP Tunnels" anchor="non-oism-p2mp"> --> <section anchor="external" numbered="true" toc="default">
<!-- <t> --> <name>Traffic to/from Outside the EVPN Tenant Domain</name>
<!-- <cref source=" ECR"> --> <t>
<!-- This section still preliminary, and may never actually be -->
<!-- needed. Hence it will probably be omitted from the next rev.
-->
<!-- We might want to say something short like "procedures will be
-->
<!-- provided if it is determined that this is a valid use case".
-->
<!-- </cref> -->
<!-- </t> -->
<!-- <t> -->
<!-- When IR is used to distribute the multicast traffic among the -
->
<!-- EVPN-PEs, the procedures of <xref target="non-OISM-IR"/> ensure
-->
<!-- that there will be no 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 used to distribute the multicast
-->
<!-- traffic, it is necessary have additional procedures to prevent
-->
<!-- duplicate delivery. -->
<!-- <list style="symbols"> -->
<!-- <t> -->
<!-- Every OISM PE (including the IPMGs) MUST follow the -->
<!-- procedures of <xref target="wc_spmsi"/> to advertise IP -->
<!-- Multicast Tunnels that are distinct from the BUM tunnels. -
->
<!-- OISM PEs MUST NOT send IP multicast frames on the BUM -->
<!-- tunnels. -->
<!-- </t> -->
<!-- <t> -->
<!-- The IPMG that is the DF for a given BD MUST join all the IP
-->
<!-- multicast tunnels for that BD from OISM PEs. Thus the IPMG
-->
<!-- for a given source BD, say BD-S, will receive each IP -->
<!-- multicast frame whose source BD is BD-S and whose ingress P
E -->
<!-- is OISM. -->
<!-- </t> -->
<!-- <t> -->
<!-- Since non-OISM PEs do not join the IP multicast tunnels, IP
-->
<!-- multicast traffic from an OISM ingress PE to a set of -->
<!-- non-OISM egress PEs must be relayed by the IPMG. -->
<!-- <vspace/> -->
<!-- <vspace/> -->
<!-- Note that the IPMG does not relay IP multicast frames from
-->
<!-- an ingress OISM PE to any egress OISM PEs. -->
<!-- <vspace/> -->
<!-- <vspace/> -->
<!-- Since non-OISM PEs expect to receive IP multicast frames on
-->
<!-- the BUM tunnels, the IPMG must advertise a tunnel for each
-->
<!-- BD that looks to non-OISM nodes as if it were an ordinary -
->
<!-- BUM tunnel, but is not joined by the OISM nodes. We will -
->
<!-- refer to these as "non-OISM BUM tunnels". -->
<!-- </t> -->
<!-- </list> -->
<!-- </t> -->
<!-- <t> -->
<!-- Consider an IP multicast frame whose ingress PE is non-OISM -->
<!-- and whose source BD is BD-S. -->
<!-- <list style="symbols"> -->
<!-- <t> -->
<!-- The procedures of <xref target="RFC7432"/> will cause the -
->
<!-- frame to be sent to all other PEs (OISM or non-OISM) that -
->
<!-- attach to BD-S. -->
<!-- </t> -->
<!-- <t> -->
<!-- If the frame has any non-OISM egress PEs with receivers tha
t -->
<!-- are in BD-R, where BD-R is different than BD-S, the IPMG --
>
<!-- must relay the frame to the egress non-OISM PEs. It does -
->
<!-- this by doing the IP processing of the frame's IP multicast
-->
<!-- packet, and then re-encapsulating the packet for BD-R. -->
<!-- After re-encapsulation, the MAC SA field of the Ethernet --
>
<!-- header carries the MAC address used by the IPMG itself in -
->
<!-- BD-R. Then the frame is transmitted on the non-OISM BUM --
>
<!-- tunnel for BD-R. -->
<!-- <vspace/> -->
<!-- <vspace/> -->
<!-- Note that if a non-OISM egress PE has receivers on BD-R1 --
>
<!-- and BD-R2, neither of which is BD-S, the egress PE will -->
<!-- receive two copies of the frame, one on the non-OISM BUM --
>
<!-- tunnel for BD-R1, and one on the non-OISM BUM tunnel for --
>
<!-- BD-R2. This is necessary because the non-OISM PEs cannot -
->
<!-- route frames from one BD to another. -->
<!-- </t> -->
<!-- <t> -->
<!-- OISM PEs MUST join all the IP multicast tunnels -->
<!-- advertised by other OISM PEs, including those -->
<!-- advertised by the IPMG. When an OISM PE joins the IP -->
<!-- multicast tunnel for a given BD: -->
<!-- <list style="symbols"> -->
<!-- <t> -->
<!-- If the PE is attached to that BD, it associates the -
->
<!-- tunnel with that BD. -->
<!-- </t> -->
<!-- <t> -->
<!-- If the PE is not attached to that BD, it associates -
->
<!-- the tunnel with the SBD. -->
<!-- </t> -->
<!-- </list> -->
<!-- </t> -->
<!-- <t> -->
<!-- Recall that when the IPMG (or any other OISM node) uses a
n -->
<!-- S-PMSI A-D route to advertise a tunnel in a particular BD
, the -->
<!-- route carries an RT and an Ethernet Tag ID that together
-->
<!-- identify the BD. An OISM PE uses the RT and Tag ID to -->
<!-- determine whether the route is for one of the BDs to -->
<!-- which the PE is attached. -->
<!-- </t> -->
<!-- <t> -->
<!-- When the IPMG receives an IP multicast frame on BD-S from
-->
<!-- a non-OISM ingress PE, it relays the frame unchanged on -
->
<!-- its IP multicast tunnel for BD-S. This will carry the --
>
<!-- frame to all OISM PEs that have interest in it. -->
<!-- </t> -->
<!-- <t> -->
<!-- When an OISM PE receives an IP multicast frame on the -->
<!-- IP multicast tunnel from an IPMG, and the OISM PE has -->
<!-- associated that frame with BD-S, it discards the frame. -
->
<!-- Otherwise, it follows the normal OISM procedures for -->
<!-- frames received on an SBD tunnel. -->
<!-- <vspace/> -->
<!-- <vspace/> -->
<!-- Note that if the BD-S IP multicast tunnel from the IPMG i
s -->
<!-- an MPLS P2MP LSP, and if the PTA describing that tunnel -
->
<!-- has a zero in the MPLS Label field, then an OISM PE -->
<!-- attached to BD-S SHOULD NOT join the tunnel. -->
<!-- </t> -->
<!-- </list> -->
<!-- </t> -->
<!-- <t> -->
<!-- In order for these procedures to work, the IPMG may need to -->
<!-- advertise two BUM tunnels for each BD in the tenant domain: -->
<!-- <list style="format %d. "> -->
<!-- <t> -->
<!-- Its "ordinary" BUM tunnel for the given BD, advertised -->
<!-- in an IMET route for that BD. This tunnel will be -->
<!-- joined by all PEs (OISM and non-OISM) attached to the -->
<!-- given BD. The IPMG will use this tunnel only for -->
<!-- transmitting BUM traffic that it receives from those of -->
<!-- its own ACs attaching to the given BD. -->
<!-- </t> -->
<!-- <t> -->
<!-- A "non-OISM relay BUM tunnel" for the given BD. This is --
>
<!-- advertised in a second IMET route for that BD. This -->
<!-- second IMET route MUST have a different RD and MUST have --
>
<!-- a different "originating router's IP address". It MUST -->
<!-- carry a flag or an extended community [to be determined] --
>
<!-- meaning "non-OISM-only". -->
<!-- <vspace/> -->
<!-- <vspace/> -->
<!-- Non-OISM nodes will join this tunnel, since it looks to the
m -->
<!-- like an ordinary BUM tunnel. OISM nodes will not join it,
-->
<!-- since it is marked "non-OISM-only". -->
<!-- <vspace/> -->
<!-- <vspace/> -->
<!-- When the IPMG needs to relay IP multicast traffic from an -
->
<!-- ingress PE (other than the IPMG itself) to a set of non-OIS
M -->
<!-- egress PEs, it sends the traffic on the non-OISM BUM -->
<!-- tunnel. Note that there is a different non-OISM BUM tunnel
-->
<!-- for each BD. -->
<!-- </t> -->
<!-- </list> -->
<!-- </t> -->
<!-- <t> -->
<!-- If the IPMG does not have any ACs, it need not advertise an -->
<!-- "ordinary BUM tunnel". -->
<!-- </t> -->
<!-- <t> -->
<!-- The IPMG must also advertise an "OISM-only relay tunnel" in an
-->
<!-- S-PMSI A-D route. These tunnels can be advertised in (C-*,C-*)
-->
<!-- S-PMSI A-D routes or in more specific S-PMSI A-D routes. The -
->
<!-- routes advertising these tunnels must be marked with a flag or
-->
<!-- EC that identifies them as being OISM-only relay tunnels from a
n -->
<!-- IPMG. Since these tunnels are advertised in S-PMSI A-D routes,
-->
<!-- and non-OISM nodes do not understand S-PMSI A-D routes, the -->
<!-- non-OISM nodes will not join these tunnels. -->
<!-- </t> -->
<!-- <t> -->
<!-- The non-OISM nodes will advertise P2MP tunnels in their IMET --
>
<!-- routes. These are their "BUM tunnels". Suppose the IPMG gets
-->
<!-- an (S,G) multicast frame from the BD-S BUM tunnel of a non-OISM
-->
<!-- PE-S. -->
<!-- <list style="symbols"> -->
<!-- <t> -->
<!-- If there are any non-OISM PEs with interest in (S,G) on a -
->
<!-- given BD, say BD-R, where BD-R is not the same as BD-S, the
n -->
<!-- the IPMG does the IP processing of the (S,G) multicast -->
<!-- packet, changes the MAC SA of the Ethernet encapsulation to
-->
<!-- its own MAC address, and sends the frame on the non-OISM --
>
<!-- relay BUM tunnel for BD-R. -->
<!-- </t> -->
<!-- <t> -->
<!-- If there are any OISM PEs with interest in (S,G) on a given
-->
<!-- BD, say BD-R, where BD-R is not the same as BD-S, then the
-->
<!-- IPMG sends the frame on the OISM-only relay tunnel for BD-R
-->
<!-- that it uses for sending (S,G) traffic. The IPMG MUST NOT
-->
<!-- do the IP processing and MUST NOT modify the MAC SA of the
-->
<!-- frame. -->
<!-- </t> -->
<!-- </list> -->
<!-- </t> -->
<!-- <t> -->
<!-- If an IPMG has ACs attaching to a particular BD, it MUST NOT --
>
<!-- transmit those frames on an OISM-only relay tunnel. Instead, -
->
<!-- the IPMG will need to originate a different set of routes to --
>
<!-- advertise the tunnels for carrying packets from its ACs. These
-->
<!-- routes have a different RD and a different originating router I
P -->
<!-- address than the relay tunnels. -->
<!-- </t> -->
<!-- <t> -->
<!-- We have assumed above that non-OISM nodes will not recognize --
>
<!-- S-PMSI A-D routes. If we want to accommodate a future where --
>
<!-- non-OISM nodes do support S-PMSI A-D routes, an EC or flag woul
d -->
<!-- have to be used to distinguish the OISM-only IP multicast -->
<!-- tunnels from the ordinary IP multicast tunnels. -->
<!-- The non-OISM nodes would be upgraded to understand this flag or
-->
<!-- EC when they are upgraded to understand S-PMSI A-D routes.
-->
<!-- </t> -->
<!-- </section> -->
</section> <!-- no-OISM -->
<section title="Traffic to/from Outside the EVPN Tenant Domain"
anchor="external">
<t>
In this section, we discuss scenarios where a multicast source outside a In this section, we discuss scenarios where a multicast source outside a
given EVPN Tenant Domain sends traffic to receivers inside the domain given EVPN Tenant Domain sends traffic to receivers inside the domain
(as well as, possibly, to receivers outside the domain). This requires (as well as, possibly, to receivers outside the domain). This requires
the OISM procedures to interwork with various layer 3 multicast routing the OISM procedures to interwork with various Layer 3 multicast routing
procedures. procedures.
</t> </t>
<t> <t>
We assume in this section that the Tenant Domain is not being used as an In this section, we assume that the Tenant Domain is not being used as an
intermediate transit network for multicast traffic; that is, we do not intermediate transit network for multicast traffic; that is, we do not
consider the case where the Tenant Domain contains multicast routers consider the case where the Tenant Domain contains multicast routers
that will receive traffic from sources outside the domain and forward that will receive traffic from sources outside the domain and forward
the traffic to receivers outside the domain. The transit scenario is the traffic to receivers outside the domain. The transit scenario is
considered in <xref target="pim"/>. considered in <xref target="pim" format="default"/>.
</t>
<t>
We can divide the non-transit scenarios into two classes:
<list style="format %d. ">
<t>
One or more of the EVPN PE routers provide the functionality needed
to interwork with layer 3 multicast routing procedures.
</t> </t>
<t> <t>
We can divide the non-transit scenarios into two classes:
</t>
<ol spacing="normal" type="1"><li>
<t>
One or more of the EVPN PE routers provide the functionality needed
to interwork with Layer 3 multicast routing procedures.
</t>
</li>
<li>
<t>
A single BD in the Tenant Domain contains external multicast routers A single BD in the Tenant Domain contains external multicast routers
("tenant multicast routers"), and those tenant multicast routers are (tenant multicast routers), and those tenant multicast routers are
used to interwork, on behalf of the entire Tenant Domain, with layer used to interwork, on behalf of the entire Tenant Domain, with Layer
3 multicast routing procedures. 3 multicast routing procedures.
</t> </t>
</list> </li>
</t> </ol>
<section title="Layer 3 Interworking via EVPN OISM PEs" anchor="evpn-pe-l3-iwo <section anchor="evpn-pe-l3-iwork" numbered="true" toc="default">
rk"> <name>Layer 3 Interworking via EVPN OISM PEs</name>
<section title="General Principles" anchor="gen_prin"> <section anchor="gen_prin" numbered="true" toc="default">
<t> <name>General Principles</name>
<t>
Sometimes it is necessary to interwork an EVPN Tenant Domain with an Sometimes it is necessary to interwork an EVPN Tenant Domain with an
external layer 3 multicast domain (the "external domain"), e.g., external Layer 3 multicast domain (the external domain), e.g.,
a PIM or MVPN domain. This is a PIM or MVPN domain. This is
needed to allow EVPN tenant systems to receive multicast traffic needed to allow EVPN tenant systems to receive multicast traffic
from sources ("external sources") outside the EVPN Tenant Domain. from sources (external sources) outside the EVPN Tenant Domain.
It is also needed to allow receivers ("external receivers") outside It is also needed to allow receivers (external receivers) outside
the EVPN Tenant Domain to receive traffic from sources inside the the EVPN Tenant Domain to receive traffic from sources inside the
Tenant Domain. Tenant Domain.
</t> </t>
<t> <t>
In order to allow interworking between an EVPN Tenant Domain and an In order to allow interworking between an EVPN Tenant Domain and an
external domain, one or more OISM PEs must be "L3 Gateways". An L3 external domain, one or more OISM PEs must be L3 Gateways. An L3
Gateway participates both in the OISM procedures and in the L3 Gateway participates both in the OISM procedures and in the L3
multicast routing procedures of the external domain, as shown in multicast routing procedures of the external domain, as shown in
the following figure. the following figure.
<figure> </t>
<artwork> <figure>
<name>Interworking via OISM PEs</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
src1 rcvr1 src1 rcvr1
| | | |
R1 RP R2 R1 RP R2
PIM/MVPN PIM/MVPN
domain Domain
+---+ +---+ +---+ +---+
-----|GW1|----------------------|GW2|---- -----|GW1|----------------------|GW2|----
+---+ +---+ +---+ +---+
| \ \ / / | | \ \ / / |
| \ \ / / | | \ \ / / |
BD1 BD2 SBD SBD BD2 BD1 BD1 BD2 SBD SBD BD2 BD1
EVPN Domain EVPN Domain
SBD SBD SBD SBD
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
|PE1| |PE2| |PE1| |PE2|
+---+ +---+ +---+ +---+
| \ / | | \ / |
BD1 BD2 BD2 BD1 BD1 BD2 BD2 BD1
| | | | | | | |
src2 rcvr2 src3 rcvr3 src2 rcvr2 src3 rcvr3
</artwork> ]]></artwork></figure>
</figure> <t>
</t>
<t>
An L3 Gateway that has interest in receiving (S,G) traffic must be An L3 Gateway that has interest in receiving (S,G) traffic must be
able to determine the best route to S. If an L3 Gateway has able to determine the best route to S. If an L3 Gateway has
interest in (*,G), it must be able to determine the best route to interest in (*,G), it must be able to determine the best route to
G's RP. In these interworking scenarios, the L3 Gateway must be G's RP. In these interworking scenarios, the L3 Gateway must be
running a layer 3 unicast routing protocol. Via this protocol, it running a Layer 3 unicast routing protocol. Via this protocol, it
imports unicast routes (either IP routes or VPN&nbhy;IP routes) from imports unicast routes (either IP routes or VPN-IP routes) from
routers other than EVPN PEs. And since there may be multicast routers other than EVPN PEs. And since there may be multicast
sources inside the EVPN Tenant Domain, the EVPN PEs also need to sources inside the EVPN Tenant Domain, the EVPN PEs also need to
export, either as IP routes or as VPN&nbhy;IP routes (depending upon export, either as IP routes or as VPN-IP routes (depending upon
the external domain), unicast routes to those sources. the external domain), unicast routes to those sources.
</t> </t>
<t> <t>
When selecting the best route to a multicast source or RP, an L3 When selecting the best route to a multicast source or RP, an L3
Gateway might have a choice between an EVPN route and an Gateway might have a choice between an EVPN route and an
IP/VPN&nbhy;IP route. When such a choice exists, the L3 Gateway IP/VPN-IP route. When such a choice exists, the L3 Gateway
SHOULD always prefer the EVPN route. This will ensure that when <bcp14>SHOULD</bcp14> always prefer the EVPN route. This will ensure th
at when
traffic originates in the Tenant Domain and has a receiver in the traffic originates in the Tenant Domain and has a receiver in the
Tenant Domain, the path to that receiver will remain within the EVPN Tenant Domain, the path to that receiver will remain within the EVPN
Tenant Domain, even if the source is also reachable via a routed Tenant Domain, even if the source is also reachable via a routed
path. This also provides protection against sub&nbhy;optimal path. This also provides protection against sub-optimal
routing that might occur if two EVPN PEs export IP/VPN&nbhy;IP routing that might occur if two EVPN PEs export IP/VPN-IP
routes and each imports the other's IP/VPN-IP routes. routes and each imports the other's IP/VPN-IP routes.
</t> </t>
<t> <t>
<xref target="rpf"/> discusses the way layer 3 multicast states are <xref target="rpf" format="default"/> discusses the way Layer 3 multicas
constructed by OISM PEs. These layer 3 multicast states have IRB t states are
interfaces as their IIF and OIF list entries, and are the basis for constructed by OISM PEs. These Layer 3 multicast states have IRB
interworking OISM with other layer 3 multicast procedures such as interfaces as their IIF and OIF list entries and are the basis for
MVPN or PIM. From the perspective of the layer 3 multicast interworking OISM with other Layer 3 multicast procedures such as
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.
</t> </t>
<t> <t>
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 Layer 3 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&nbhy;IRB interfaces as the multicast states may have PIM-enabled non-IRB interfaces as
IIF or OIF list members. IIF or OIF list members.
</t> </t>
<t> <t>
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.
</t> </t>
<t>
In general, an L3 Gateway has the following responsibilities:
<list style="symbols">
<t> <t>
In general, an L3 Gateway has the following responsibilities:
</t>
<ul spacing="normal">
<li>
<t>
It exports, to the external domain, unicast routes to those 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.
</t> </t>
<t> </li>
<li>
<t>
It imports, from the external domain, unicast routes to It imports, from the external domain, unicast routes to
multicast sources that are in the external domain. multicast sources that are in the external domain.
</t> </t>
<t> </li>
<li>
<t>
It executes the procedures necessary to draw externally sourced It executes the procedures necessary to draw externally sourced
multicast traffic that is of interest to locally attached multicast traffic that is of interest to locally attached
receivers in the EVPN Tenant Domain. When such traffic is receivers in the EVPN Tenant Domain. When such traffic is
received, the traffic is sent down the IRB interfaces of the BDs received, the traffic is sent down the IRB interfaces of the BDs
on which the locally attached receivers reside. on which the locally attached receivers reside.
</t> </t>
</list> </li>
</t> </ul>
<t>
One of the L3 Gateways in a given Tenant Domain becomes the "DR" for
the SBD. (See <xref target="dr_selection"/>.) This L3 gateway has
the following additional responsibilities:
<list style="symbols">
<t> <t>
One of the L3 Gateways in a given Tenant Domain becomes the DR for
the SBD (see <xref target="dr_selection" format="default"/>). This L3 G
ateway has
the following additional responsibilities:
</t>
<ul spacing="normal">
<li>
<t>
It exports, to the external domain, unicast routes to multicast It exports, to the external domain, unicast routes to multicast
sources 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.
</t> </t>
<t> </li>
<li>
<t>
It imports, from the external domain, unicast routes to multicast It imports, from the external domain, unicast routes to multicast
sources that are in the external domain. sources that are in the external domain.
</t> </t>
<t> </li>
<li>
<t>
It executes the procedures necessary to draw externally sourced It executes the procedures necessary to draw 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 IRB interface. OISM procedures already described in this
document will then ensure that the IP multicast traffic gets document will then ensure that the IP multicast traffic gets
distributed throughout the Tenant Domain to any EVPN PEs that distributed throughout the Tenant Domain to any EVPN PEs that
have interest in it. Thus to an OISM PE that is not an L3 have interest in it. Thus, to an OISM PE that is not an L3
gateway the externally sourced traffic will appear to have been Gateway, the externally sourced traffic will appear to have been
sourced on the SBD. sourced on the SBD.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
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. Gateway creates or modifies a Layer 3 (*,G) multicast state.
Suppose group G has both external sources (sources outside the EVPN Suppose group G has both external sources (sources outside the EVPN
Tenant Domain) and internal sources (sources inside the EVPN tenant Tenant Domain) and internal sources (sources inside the EVPN Tenant
domain). <xref target="rpf"/> states that when there are internal Domain). <xref target="rpf" format="default"/> states that when there ar
e internal
sources, the SBD IRB interface must not be added to the OIF list of sources, the SBD IRB interface must not be added to the OIF list of
the (*,G) state. Traffic from internal sources will already have the (*,G) state. Traffic from internal sources will already have
been delivered to all the EVPN PEs that have interest in it. been delivered to all the EVPN PEs that have interest in it.
However, if the OIF list of the (*,G) state does not contain its SBD However, if the OIF list of the (*,G) state does not contain its SBD
IRB interface, then traffic from external sources will not get IRB interface, then traffic from external sources will not get
delivered to other EVPN PEs. delivered to other EVPN PEs.
</t> </t>
<t> <t>
One way of handling this is the following. When an 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 that is from an interface other than IRB, 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.
</t> </t>
<t> <t>
If a particular BD If a particular BD is attached to several L3
<!-- (other than the SBD) --> Gateways, one of the L3 Gateways becomes the DR for that BD (see
is attached to several L3 <xref target="dr_selection" format="default"/>). If the interworking sc
Gateways, one of the L3 Gateways becomes the DR for that BD. (See enario
<xref target="dr_selection"/>.) If the interworking scenario
requires FHR functionality, it is generally the DR for a particular requires FHR functionality, it is generally the DR for a particular
BD that is responsible for performing that functionality on behalf BD that is responsible for performing that functionality on behalf
of the source hosts on that BD. (E.g., if the interworking scenario of the source hosts on that BD (e.g., if the interworking scenario
requires that PIM Register messages be sent by an FHR, the DR for a requires that PIM Register messages be sent by an FHR, the DR for a
given BD would send the PIM Register messages for sources on that given BD would send the PIM Register messages for sources on that
BD.) Note though that the DR for the SBD does not perform FHR BD). Although, note that the DR for the SBD does not perform FHR
functionality on behalf of external sources. functionality on behalf of external sources.
</t> </t>
<t> <t>
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.
</t> </t>
<t> <t>
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 a PE receiving an SMET route for that BD MUST multicast router, then a PE receiving a SMET route for that BD <bcp14>MU
NOT reconstruct IGMP/MLD Join Reports from the SMET route, and MUST NOT ST
NOT</bcp14> reconstruct IGMP/MLD Join Reports from the SMET route and <b
cp14>MUST NOT</bcp14>
transmit any such IGMP/MLD Join Reports on its local ACs attaching to transmit any such IGMP/MLD Join Reports on its local ACs attaching to
that BD. Otherwise, multicast traffic may be duplicated. that BD. Otherwise, multicast traffic may be duplicated.
</t> </t>
</section> <!-- gen_prin --> </section>
<section anchor="mvpn" numbered="true" toc="default">
<section title="Interworking with MVPN" anchor="mvpn"> <name>Interworking with MVPN</name>
<t> <t>
In this section, we specify the procedures necessary to allow EVPN PEs In this section, we specify the procedures necessary to allow EVPN PEs
running OISM procedures to interwork with L3VPN PEs that run BGP-based running OISM procedures to interwork with L3VPN PEs that run BGP-based
MVPN <xref target="RFC6514"/> procedures. More specifically, the MVPN <xref target="RFC6514" format="default"/> procedures. More specifica lly, the
procedures herein allow a given EVPN Tenant Domain to become part of procedures herein allow a given EVPN Tenant Domain to become part of
an L3VPN/MVPN, and support multicast flows where either: an L3VPN/MVPN and support multicast flows where either of the following oc
<list style="symbols"> curs:
<t> </t>
<ul spacing="normal">
<li>
<t>
The source of a given multicast flow is attached to an Ethernet The source of a given multicast flow is attached to an Ethernet
segment whose BD is part of an EVPN Tenant Domain, and one or segment whose BD is part of an EVPN Tenant Domain, and one or
more receivers of the flow are attached to the network via more receivers of the flow are attached to the network via
L3VPN/MVPN. (Other receivers may be attached to the network via L3VPN/MVPN. (Other receivers may be attached to the network via
EVPN.) EVPN.)
</t> </t>
<t> </li>
<li>
<t>
The source of a given multicast flow is attached to the network The source of a given multicast flow is attached to the network
via L3VPN/MVPN, and one or more receivers of the flow are attached via L3VPN/MVPN, and one or more receivers of the flow are attached
to an Ethernet segment that is part of an EVPN tenant to an Ethernet segment that is part of an EVPN Tenant
domain. (Other receivers may be attached via L3VPN/MVPN.) Domain. (Other receivers may be attached via L3VPN/MVPN.)
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
In this interworking model, existing L3VPN/MVPN PEs are unaware that In this interworking model, existing L3VPN/MVPN PEs are unaware that
certain sources or receivers are part of an EVPN Tenant Domain. The certain sources or receivers are part of an EVPN Tenant Domain. The
existing L3VPN/MVPN nodes run only their standard procedures and are existing L3VPN/MVPN nodes run only their standard procedures and are
entirely unaware of EVPN. Interworking is achieved by having some or entirely unaware of EVPN. Interworking is achieved by having some or
all of the EVPN PEs function as L3 Gateways running L3VPN/MVPN all of the EVPN PEs function as L3 Gateways running L3VPN/MVPN
procedures, as detailed in the following sub-sections. procedures, as detailed in the following subsections.
</t> </t>
<t> <t>
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. (Of course, there may
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 <xref there are tenant multicast routers is addressed in <xref target="pim" form
target="pim"/>.) at="default"/>.
</t> </t>
<!-- <section title="Model of Operation" anchor="iwork_model"> -->
<t> <t>
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 (MEG).
</t> </t>
<t> <t>
A MEG is an L3 Gateway (see <xref target="gen_prin"/>), hence is both A MEG is an L3 Gateway (see <xref target="gen_prin" format="default"/>); h
ence, it is both
an OISM PE and an L3VPN/MVPN PE. For a given EVPN Tenant Domain, it an OISM PE and an L3VPN/MVPN PE. For a given EVPN Tenant Domain, it
will have an IP&nbhy;VRF. If the Tenant Domain is part of an will have an IP-VRF. If the Tenant Domain is part of an
L3VPN/MVPN, the IP&nbhy;VRF also serves as an L3VPN VRF <xref L3VPN/MVPN, the IP-VRF also serves as an L3VPN VRF <xref target="RFC4364"
target="RFC4364"/>. The IRB interfaces of the IP&nbhy;VRF are format="default"/>. The IRB interfaces of the IP-VRF are
considered to be "VRF interfaces" of the L3VPN VRF. The L3VPN VRF may considered to be VRF interfaces of the L3VPN VRF. The L3VPN VRF may
also have other local VRF interfaces that are not EVPN IRB interfaces. also have other local VRF interfaces that are not EVPN IRB interfaces.
</t> </t>
<t> <t>
The VRF on the MEG will import VPN&nbhy;IP routes <xref The VRF on the MEG will import VPN-IP routes <xref target="RFC4364" format
target="RFC4364"/> from other L3VPN Provider Edge (PE) routers. It ="default"/> from other L3VPN PE routers. It
will also export VPN&nbhy;IP routes to other L3VPN PE routers. In will also export VPN-IP routes to other L3VPN PE routers. In
order to do so, it must be appropriately configured with the Route order to do so, it must be appropriately configured with the RTs
Targets used in the L3VPN to control the distribution of the used in the L3VPN to control the distribution of the
VPN&nbhy;IP routes. These Route Targets will in general be different VPN-IP routes. In general, these RTs will be different
than the Route Targets used for controlling the distribution of EVPN than the RTs used for controlling the distribution of EVPN
routes, as there is no need to distribute EVPN routes to L3VPN-only routes, as there is no need to distribute EVPN routes to L3VPN-only
PEs and no reason to distribute L3VPN/MVPN routes to EVPN-only PEs. PEs and no reason to distribute L3VPN/MVPN routes to EVPN-only PEs.
</t> </t>
<t> <t>
Note that the RDs in the imported VPN&nbhy;IP routes will not Note that the RDs in the imported VPN-IP routes will not
necessarily conform to the EVPN rules (as specified in <xref necessarily conform to the EVPN rules (as specified in <xref target="RFC74
target="RFC7432"/>) for creating RDs. Therefore a MEG MUST NOT expect 32" format="default"/>) for creating RDs. Therefore, a MEG <bcp14>MUST NOT</bcp
the RDs of the VPN&nbhy;IP routes to be of any particular format other 14> expect
the RDs of the VPN-IP routes to be of any particular format other
than what is required by the L3VPN/MVPN specifications. than what is required by the L3VPN/MVPN specifications.
</t> </t>
<t> <t>
The VPN&nbhy;IP routes that a MEG exports to L3VPN are subnet routes The VPN-IP routes that a MEG exports to L3VPN are subnet routes
and/or host routes for the multicast sources that are part of the EVPN and/or host routes for the multicast sources that are part of the EVPN
tenant domain. The exact set of routes that need to be exported is Tenant Domain. The exact set of routes that need to be exported is
discussed in <xref target="e2m"/>. discussed in <xref target="e2m" format="default"/>.
</t> </t>
<t> <t>
Each IMET route originated by a MEG SHOULD carry a Multicast Flags Each IMET route originated by a MEG <bcp14>SHOULD</bcp14> carry a Multicas
Extended Community with the "MEG" flag set, indicating that the t Flags
Extended Community with the MEG flag set, indicating that the
originator of the IMET route is a MEG. However, PE1 will consider PE2 originator of the IMET route is a MEG. However, PE1 will consider PE2
to be a MEG if PE1 imports at least one IMET route from PE2 that to be a MEG if PE1 imports at least one IMET route from PE2 that
carries the Multicast Flags EC with the MEG flag set. carries the Multicast Flags EC with the MEG flag set.
</t> </t>
<t> <t>
All the MEGs of a given Tenant Domain attach to the SBD of that All the MEGs of a given Tenant Domain attach to the SBD of that
domain, and one of them is selected to be the SBD's Designated Router domain, and one of them is selected to be the SBD's Designated Router
(the "MEG SBD&nbhy;DR") for the domain. The selection procedure is (the MEG SBD-DR) for the domain. The selection procedure is
discussed in <xref target="dr_selection"/>. discussed in <xref target="dr_selection" format="default"/>.
</t> </t>
<t> <t>
In this model of operation, MVPN procedures and EVPN procedures are In this model of operation, MVPN procedures and EVPN procedures are
largely independent. In particular, there is no assumption that MVPN largely independent. In particular, there is no assumption that MVPN
and EVPN use the same kind of tunnels. Thus no special procedures are and EVPN use the same kind of tunnels. Thus, no special procedures are
needed to handle the common scenarios where, e.g., EVPN uses VXLAN needed to handle the common scenarios where, e.g., EVPN uses VXLAN
tunnels but MVPN uses MPLS P2MP tunnels, or where EVPN uses Ingress tunnels but MVPN uses MPLS P2MP tunnels, or where EVPN uses IR
Replication but MVPN uses MPLS P2MP tunnels. but MVPN uses MPLS P2MP tunnels.
</t> </t>
<t> <t>
Similarly, no special procedures are needed to prevent duplicate data Similarly, no special procedures are needed to prevent duplicate data
delivery on Ethernet segments that are multi&nbhy;homed. delivery on Ethernet segments that are multihomed.
</t> </t>
<t> <t>
The MEG does have some special procedures (described below) for The MEG does have some special procedures (described below) for
interworking between EVPN and MVPN; these have to do with selection of interworking between EVPN and MVPN; these have to do with selection of
the Upstream PE for a given multicast source, with the exporting of the Upstream PE for a given multicast source, with the exporting of
VPN&nbhy;IP routes, and with the generation of MVPN C&nbhy;multicast VPN-IP routes and with the generation of MVPN C-multicast
routes triggered by the installation of SMET routes. routes triggered by the installation of SMET routes.
</t> </t>
<section title="MVPN Sources with EVPN Receivers" anchor="m2e"> <section anchor="m2e" numbered="true" toc="default">
<section title="Identifying MVPN Sources" anchor="mvpn_source"> <name>MVPN Sources with EVPN Receivers</name>
<t> <section anchor="mvpn_source" numbered="true" toc="default">
<name>Identifying MVPN Sources</name>
<t>
Consider a multicast source S. It is possible that a MEG will Consider a multicast source S. It is possible that a MEG will
import both an EVPN unicast route to S and a VPN&nbhy;IP route (or import 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 an ordinary IP route), where the prefix length of each route is
the same. In order to draw (S,G) multicast traffic for any group the same. In order to draw (S,G) multicast traffic for any group
G, the MEG SHOULD use the EVPN route rather than the VPN&nbhy;IP G, the MEG <bcp14>SHOULD</bcp14> use the EVPN route rather than the VP
or IP route to determine the "Upstream PE" (see section 5 of <xref N-IP
target="RFC6513"/>). or IP route to determine the Upstream PE (see <xref target="RFC6513" f
</t> ormat="default" sectionFormat="of" section="5"/>).
<t> </t>
<t>
Doing so ensures that when an EVPN tenant system desires to Doing so ensures that when an EVPN tenant system desires to
receive a multicast flow from another EVPN tenant system, the receive a multicast flow from another EVPN tenant system, the
traffic from the source to that receiver stays within the EVPN traffic from the source to that receiver stays within the EVPN
domain. This prevents problems that might arise if there is a domain. This prevents problems that might arise if there is a
unicast route via L3VPN to S, but no multicast routers along the unicast route via L3VPN to S but no multicast routers along the
routed path. This also prevents problem that might arise as a routed path. This also prevents problem that might arise as a
result of the fact that the MEGs will import each others' result of the fact that the MEGs will import each others'
VPN&nbhy;IP routes. VPN-IP routes.
</t> </t>
<t> <t>
In the <xref target="mvpn_join"/>, we describe the procedures to In <xref target="mvpn_join" format="default"/>, we describe the proced
be used when the selected route to S is a VPN&nbhy;IP route. ures to
</t> be used when the selected route to S is a VPN-IP route.
</section> <!-- mvpn_source --> </t>
</section>
<section title="Joining a Flow from an MVPN Source" anchor="mvpn_join"> <section anchor="mvpn_join" numbered="true" toc="default">
<t> <name>Joining a Flow from an MVPN Source</name>
Consider a tenant system, R, on a particular BD, BD-R. Suppose R <t>
Consider a tenant system, say R, on a particular BD, say BD-R. Suppos
e 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 attached to any PE in the EVPN Tenant Domain but is attached to
an MVPN PE. an MVPN PE.
<list style="symbols"> </t>
<t> <ul spacing="normal">
Suppose R is on a singly homed Ethernet segment of BD&nbhy;R, <li>
<t>
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 and that segment is attached to PE1, where PE1 is a MEG. PE1
learns via IGMP/MLD listening that R is interested in (S,G). learns via IGMP/MLD listening that R is interested in (S,G).
PE1 determines from its VRF that there is no route to S within PE1 determines from its VRF that there is no route to S within
the Tenant Domain (i.e., no EVPN RT-2 route matching on S's IP the Tenant Domain (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 address) but that there is a route to S via L3VPN (i.e., the
VRF contains a subnet or host route to S that was received as VRF contains a subnet or host route to S that was received as
a VPN&nbhy;IP route). PE1 thus originates (if it hasn't a VPN-IP route). Thus, PE1 originates (if it hasn't
already) an MVPN C&nbhy;multicast Source Tree Join(S,G) route. already) an MVPN C-multicast Source Tree Join (S,G) route.
The route is constructed according to normal MVPN procedures. The route is constructed according to normal MVPN procedures.
<vspace/> </t>
<vspace/> <t>
The layer 2 multicast state is constructed as specified in The Layer 2 multicast state is constructed as specified in
<xref target="l2_state"/>. <xref target="l2_state" format="default"/>.
<vspace/> </t>
<vspace/> <t>
In the layer 3 multicast state, the IIF is the appropriate In the Layer 3 multicast state, the IIF is the appropriate
MVPN tunnel, and the IRB interface to BD&nbhy;R is added to MVPN tunnel, and the IRB interface to BD-R is added to
the OIF list. the OIF list.
<vspace/> </t>
<vspace/> <t>
When PE1 receives (S,G) traffic from the appropriate MVPN When PE1 receives (S,G) traffic from the appropriate MVPN
tunnel, it performs IP processing of the traffic, and then tunnel, it performs IP processing of the traffic and then
sends the traffic down its IRB interface to BD&nbhy;R. sends the traffic down its IRB interface to BD-R.
Following normal OISM procedures, the (S,G) traffic will be Following normal OISM procedures, the (S,G) traffic will be
encapsulated for Ethernet and sent on the AC to which R is encapsulated for Ethernet and sent on the AC to which R is
attached. attached.
</t> </t>
<t> </li>
Suppose R is on a singly homed Ethernet segment of BD&nbhy;R, <li>
<t>
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 and that 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 but is NOT a MEG. PE1 learns via IGMP/MLD listening that R is
interested in (S,G). PE1 follows normal OISM procedures, interested in (S,G). PE1 follows normal OISM procedures,
originating an SBD-SMET route for (S,G); this route will be originating an SBD-SMET route for (S,G); this route will be
received by all the MEGs of the Tenant Domain, including the received by all the MEGs of the Tenant Domain, including the
MEG SBD&nbhy;DR. The MEG SBD&nbhy;DR can determine from PE1's MEG SBD-DR. From PE1's IMET routes, the MEG SBD-DR can determine
IMET routes whether PE1 is itself a MEG. If PE1 is not a MEG, whether or not PE1 is itself a MEG. If PE1 is not a MEG,
the MEG SBD&nbhy;DR will originate (if it hasn't already) an the MEG SBD-DR will originate (if it hasn't already) an
MVPN C&nbhy;multicast Source Tree Join(S,G) route. This will MVPN C-multicast Source Tree Join (S,G) route. This will
cause the MEG SBD&nbhy;DR to receive (S,G) traffic on an MVPN cause the MEG SBD-DR to receive (S,G) traffic on an MVPN
tunnel. tunnel.
<vspace/> </t>
<vspace/> <t>
The layer 2 multicast state is constructed as specified in The Layer 2 multicast state is constructed as specified in
<xref target="l2_state"/>. <xref target="l2_state" format="default"/>.
<vspace/> </t>
<vspace/> <t>
In the layer 3 multicast state, the IIF is the appropriate In the Layer 3 multicast state, the IIF is the appropriate
MVPN tunnel, and the IRB interface to the SBD is added to the MVPN tunnel, and the IRB interface to the SBD is added to the
OIF list. OIF list.
<vspace/> </t>
<vspace/> <t>
When the MEG SBD&nbhy;DR receives (S,G) traffic on an MVPN When the MEG SBD-DR receives (S,G) traffic on an MVPN
tunnel, it performs IP processing of the traffic, and the tunnel, it performs IP processing of the traffic and then
sends the traffic down its IRB interface to the SBD. sends the traffic down its IRB interface to the SBD.
Following normal OISM procedures, the traffic will be Following normal OISM procedures, the traffic will be
encapsulated for Ethernet and delivered to all PEs in the encapsulated for Ethernet and delivered to all PEs in the
Tenant Domain that have interest in (S,G), including PE1. Tenant Domain that have interest in (S,G), including PE1.
</t> </t>
<t> </li>
If R is on a multi&nbhy;homed Ethernet segment of BD&nbhy;R, <li>
<t>
If R is on a multihomed Ethernet segment of BD-R,
one of the PEs attached to the segment will be its DF one of the PEs attached to the segment will be its DF
(following normal EVPN procedures), and the DF will know (via (following normal EVPN procedures), and the DF will know (via
IGMP/MLD listening or the procedures of <xref IGMP/MLD listening or the procedures of <xref target="RFC9251" for
target="RFC9251"/>) that a tenant system reachable via one mat="default"/>) that a tenant system reachable via one
of its local ACs to BD&nbhy;R is interested in (S,G) traffic. of its local ACs to BD-R is interested in (S,G) traffic.
The DF is responsible for originating an SBD-SMET route for The DF is responsible for originating an SBD-SMET route for
(S,G), following normal OISM procedures. If the DF is a MEG, (S,G), following normal OISM procedures. If the DF is a MEG,
it MUST originate the corresponding MVPN C&nbhy;multicast it <bcp14>MUST</bcp14> originate the corresponding MVPN C-multicas
Source Tree Join(S,G) route; if the DF is not a MEG, the MEG t
SBD&nbhy;DR SBD MUST originate the C&nbhy;multicast route when Source Tree Join (S,G) route; if the DF is not a MEG, the MEG
SBD-DR SBD <bcp14>MUST</bcp14> originate the C-multicast route whe
n
it receives the SMET route. it receives the SMET route.
<vspace/> </t>
<vspace/> <t>
Optionally, if the non-DF is a MEG, it MAY originate the Optionally, if the non-DF is a MEG, it <bcp14>MAY</bcp14> originat
corresponding MVPN C&nbhy;multicast Source Tree Join(S,G) e the
corresponding MVPN C-multicast Source Tree Join (S,G)
route. This will cause the traffic to flow to both the DF and route. This will cause the traffic to flow to both the DF and
the non-DF, but only the DF will forward the traffic out an the non-DF, but only the DF will forward the traffic out an
AC. This allows for quicker recovery if the DF's local AC to AC. This allows for quicker recovery if the DF's local AC to
R fails. R fails.
</t> </t>
<t> </li>
If R is attached to a non&nbhy;OISM PE, it will receive the <li>
traffic via an IPMG, as specified in <xref target="no-OISM"/>. <t>
</t> If R is attached to a non-OISM PE, it will receive the
</list> traffic via an IPMG, as specified in <xref target="no-OISM" format
</t> ="default"/>.
<t> </t>
</li>
</ul>
<t>
If an EVPN-attached receiver is interested in (*,G) traffic, and If an EVPN-attached receiver is interested in (*,G) traffic, and
if it is possible for there to be sources of (*,G) traffic that if 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 are attached only to L3VPN nodes, the MEGs will have to know the
group-to-RP mappings. That will enable them to originate MVPN group-to-RP mappings. That will enable them to originate MVPN
C&nbhy;multicast Shared Tree Join(*,G) routes and to send them C-multicast Shared Tree Join (*,G) routes and to send them
towards the RP. (Since we are assuming in this section that there toward the RP. (Since we are assuming in this section that there
are no tenant multicast routers attached to the EVPN Tenant are no tenant multicast routers attached to the EVPN Tenant
Domain, the RP must be attached via L3VPN. Alternatively, the MEG Domain, the RP must be attached via L3VPN. Alternatively, the MEG
itself could be configured to function as an RP for group G.) itself could be configured to function as an RP for group G.)
</t> </t>
<t> <t>
The layer 2 multicast states are constructed as specified in <xref The Layer 2 multicast states are constructed as specified in <xref tar
target="l2_state"/>. get="l2_state" format="default"/>.
</t> </t>
<t> <t>
In the layer 3 (*,G) multicast state, the IIF is the appropriate In the Layer 3 (*,G) multicast state, the IIF is the appropriate
MVPN tunnel. A MEG will add to the (*,G) OIF list its IRB MVPN tunnel. A MEG will add its IRB
interfaces for any BDs containing locally attached receivers. If interfaces to the (*,G) OIF list for any BDs containing locally attach
ed receivers. If
there are receivers attached to other EVPN PEs, then whenever there are receivers attached to other EVPN PEs, then whenever
(S,G) traffic from an external source matches a (*,G) state, the (S,G) traffic from an external source matches a (*,G) state, the
MEG will create (S,G) state, with the MVPN tunnel as the IIF, the MEG will create (S,G) state, with the MVPN tunnel as the IIF, the
OIF list copied from the (*,G) state, and the SBD IRB interface OIF list copied from the (*,G) state, and the SBD IRB interface
added to the OIF list. (Please see the discussion in <xref added to the OIF list. (Please see the discussion in <xref target="ge
target="gen_prin"/> regarding the inclusion of the SBD IRB n_prin" format="default"/> regarding the inclusion of the SBD IRB
interface in a (*,G) state; the SBD IRB interface is used in the interface in a (*,G) state; the SBD IRB interface is only used in the
OIF list only for traffic from external sources.) OIF list for traffic from external sources.)
</t> </t>
<!-- <t> -->
<!-- Some special care is needed in the creation of the layer 3 (*,G)
-->
<!-- multicast state. Suppose group G has both external sources -->
<!-- (sources outside the EVPN Tenant Domain) and internal sources -->
<!-- (sources inside the EVPN Tenant Domain). <xref target="rpf"/> -->
<!-- states that when there are internal sources, the SBD IRB interfac
e -->
<!-- must not be added to the oiflist of the (*,G) state. Traffic fro
m -->
<!-- internal sources will have been sent down the SBD IRB interface o
f -->
<!-- its ingress PE, and thus will already have been delivered to all
-->
<!-- the EVPN PEs that have interest in it. However, if the oiflist o
f -->
<!-- the PEG DR's (*,G) state does not contain its SBD IRB interface,
-->
<!-- then traffic from external sources will not get delivered to othe
r -->
<!-- EVPN PEs. Therefore, when a MEG receives (S,G) traffic from an -
->
<!-- MVPN tunnel, and the traffic corresponds to a layer 3 (*,G) state
, -->
<!-- the MEG MUST create (S,G) state. The iif will be set to the MVPN
-->
<!-- tunnel the (S,G) traffic is expected to arrive on, and the oiflis
t -->
<!-- will contain the SBD IRB interface, as well as the IRB interfaces
-->
<!-- of any other BDs attached to the PEG DR that have locally attache
d -->
<!-- receivers with interest in the (S,G) traffic. -->
<!-- </t> -->
<t> <t>
Normal MVPN procedures will then result in the MEG getting the Normal MVPN procedures will then result in the MEG getting the
(*,G) traffic from all the multicast sources for G that are (*,G) traffic from all the multicast sources for G that are
attached via L3VPN. This traffic arrives on MVPN tunnels. When attached via L3VPN. This traffic arrives on MVPN tunnels. When
the MEG removes the traffic from these tunnels, it does the IP the MEG removes the traffic from these tunnels, it does the IP
processing. If there are any receivers on a given BD, BD&nbhy;R, processing. If there are any receivers on a given BD, say BD-R,
that are attached via local EVPN ACs, the MEG sends the traffic that are attached via local EVPN ACs, the MEG sends the traffic
down its BD&nbhy;R IRB interface. If there are any other EVPN PEs down its BD-R IRB interface. If there are any other EVPN PEs
that are interested in the (*,G) traffic, the MEG sends the that are interested in the (*,G) traffic, the MEG sends the
traffic down the SBD IRB interface. Normal OISM procedures then traffic down the SBD IRB interface. Normal OISM procedures then
distribute the traffic as needed to other EVPN&nbhy;PEs. distribute the traffic as needed to other EVPN PEs.
</t> </t>
</section> <!-- mvpn_join --> </section>
</section> <!-- m2e --> </section>
<section anchor="e2m" numbered="true" toc="default">
<section title="EVPN Sources with MVPN Receivers" anchor="e2m"> <name>EVPN Sources with MVPN Receivers</name>
<section title="General procedures" anchor="e2m_general"> <section anchor="e2m_general" numbered="true" toc="default">
<t> <name>General Procedures</name>
<t>
Consider the case where an EVPN tenant system S is sending IP Consider the case where an EVPN tenant system S is sending IP
multicast traffic to group G, and there is a receiver R for the multicast traffic to group G and there is a receiver R for the
(S,G) traffic that is attached to the L3VPN, but not attached to (S,G) traffic that is attached to the L3VPN but not attached to
the EVPN Tenant Domain. (We assume in this document that the the EVPN Tenant Domain. (In this document, we assume that the
L3VPN/MVPN&nbhy;only nodes will not have any special procedures to L3VPN-/MVPN-only nodes will not have any special procedures to
deal with the case where a source is inside an EVPN domain.) deal with the case where a source is inside an EVPN domain.)
</t> </t>
<t> <t>
In this case, an L3VPN PE through which R can be reached has to In this case, an L3VPN PE through which R can be reached has to
send an MVPN C&nbhy;multicast Join(S,G) route to one of the MEGs send an MVPN C-multicast Join (S,G) route to one of the MEGs
that is attached to the EVPN Tenant Domain. For this to happen, that is attached to the EVPN Tenant Domain. For this to happen,
the L3VPN PE must have imported a VPN-IP route for S (either a the L3VPN PE must have imported a VPN-IP route for S (either a
host route or a subnet route) from a MEG. host route or a subnet route) from a MEG.
</t> </t>
<t> <t>
If a MEG determines that there is multicast source transmitting on If a MEG determines that there is multicast source transmitting on
one of its ACs, the MEG SHOULD originate a VPN&nbhy;IP host route one of its ACs, the MEG <bcp14>SHOULD</bcp14> originate a VPN-IP host
for that source. This determination SHOULD be made by examining route
the IP multicast traffic that arrives on the ACs. (It MAY be made for that source. This determination <bcp14>SHOULD</bcp14> be made by
by provisioning.) A MEG SHOULD NOT export a VPN&nbhy;IP host examining
the IP multicast traffic that arrives on the ACs. (It <bcp14>MAY</bcp1
4> be made
by provisioning.) A MEG <bcp14>SHOULD NOT</bcp14> export a VPN-IP hos
t
route for any IP address that is not known to be a multicast route for any IP address that is not known to be a multicast
source (unless it has some other reason for exporting such a source (unless it has some other reason for exporting such a
route). The VPN&nbhy;IP host route for a given multicast source route). The VPN-IP host route for a given multicast source
MUST be withdrawn if the source goes silent for a configurable <bcp14>MUST</bcp14> be withdrawn if the source goes silent for a confi
period of time, or if it can be determined that the source is no gurable
period of time or if it can be determined that the source is no
longer reachable via a local AC. longer reachable via a local AC.
</t> </t>
<t> <t>
A MEG SHOULD also originate a VPN&nbhy;IP subnet route for each of A MEG <bcp14>SHOULD</bcp14> also originate a VPN-IP subnet route for e
ach of
the BDs in the Tenant Domain. the BDs in the Tenant Domain.
</t> </t>
<t> <t>
VPN&nbhy;IP routes exported by a MEG must carry any attributes or VPN-IP routes exported by a MEG must carry any attributes or
extended communities that are required by L3VPN and MVPN. In Extended Communities that are required by L3VPN and MVPN. In
particular, a VPN&nbhy;IP route exported by a MEG must carry a VRF particular, a VPN-IP route exported by a MEG must carry a VRF
Route Import Extended Community corresponding to the IP&nbhy;VRF Route Import Extended Community corresponding to the IP-VRF
from which it is imported, and a Source AS Extended Community. from which it is imported and a Source AS Extended Community.
</t> </t>
<t> <t>
As a result, if S is attached to a MEG, the L3VPN nodes will As a result, if S is attached to a MEG, the L3VPN nodes will
direct their MVPN C&nbhy;multicast Join routes to that MEG. direct their MVPN C-multicast Join routes to that MEG.
Normal MVPN procedures will cause the traffic to be delivered to Normal MVPN procedures will cause the traffic to be delivered to
the L3VPN nodes. The layer 3 multicast state for (S,G) will have the L3VPN nodes. The Layer 3 multicast state for (S,G) will have
the MVPN tunnel on its OIF list. The IIF will be the IRB the MVPN tunnel on its OIF list. The IIF will be the IRB
interface leading to the BD containing S. interface leading to the BD containing S.
</t> </t>
<t> <t>
If S is not attached to a MEG, the L3VPN nodes will direct their If S is not attached to a MEG, the L3VPN nodes will direct their
C&nbhy;multicast Join routes to whichever MEG appears to be on the C-multicast Join routes to whichever MEG appears to be on the
best route to S's subnet. Upon receiving the C&nbhy;multicast best route to S's subnet. Upon receiving the C-multicast
Join, that MEG will originate an EVPN SMET route for (S,G). As a Join, that MEG will originate an EVPN SMET route for (S,G). As a
result, the MEG will receive the (S,G) traffic at layer 2 via the result, the MEG will receive the (S,G) traffic at Layer 2 via the
OISM procedures. The (S,G) traffic will be sent up the OISM procedures. The (S,G) traffic will be sent up the
appropriate IRB interface, and the layer 3 MVPN procedures will appropriate IRB interface, and the Layer 3 MVPN procedures will
ensure that the traffic is delivered to the L3VPN nodes that have ensure that the traffic is delivered to the L3VPN nodes that have
requested it. The layer 3 multicast state for (S,G) will have the requested it. The Layer 3 multicast state for (S,G) will have the
MVPN tunnel in the OIF list, and the IIF will be one of the MVPN tunnel in the OIF list, and the IIF will be one of the
following: following:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
<t>
If S belongs to a BD that is attached to the MEG, the IIF will If S belongs to a BD that is attached to the MEG, the IIF will
be the IRB interface to that BD; be the IRB interface to that BD.
</t> </t>
<t> </li>
Otherwise the IIF will be the SBD IRB interface. <li>
</t> <t>
</list> Otherwise, the IIF will be the SBD IRB interface.
</t> </t>
<t> </li>
Note that this works even if S is attached to a non&nbhy;OISM PE, </ul>
per the procedures of <xref target="no-OISM"/>. <t>
</t> Note that this works even if S is attached to a non-OISM PE,
</section> <!-- e2m_general --> per the procedures of <xref target="no-OISM" format="default"/>.
<section title="Any-Source Multicast (ASM) Groups" anchor="e2m_asm"> </t>
<t> </section>
Suppose the MEG SBD&nbhy;DR learns that one of the PEs in its <section anchor="e2m_asm" numbered="true" toc="default">
Tenant Domain is interested in (*,G), traffic, where G is an <name>Any-Source Multicast (ASM) Groups</name>
Any&nbhy;Source Multicast (ASM) group. If there are no tenant <t>
multicast routers, the MEG SBD&nbhy;DR SHOULD perform the "First Suppose the MEG SBD-DR learns that one of the PEs in its
Hop Router" (FHR) functionality for group G on behalf of the Tenant Domain is interested in (*,G) traffic, where G is an
Tenant Domain, as described in <xref target="RFC7761"/>. This ASM group. If there are no tenant
means that the MEG SBD&nbhy;DR must know the identity of the multicast routers, the MEG SBD-DR <bcp14>SHOULD</bcp14> perform the Fi
Rendezvous Point (RP) for each group, must send Register messages rst
to the Rendezvous Point, etc. Hop Router (FHR) functionality for group G on behalf of the
</t> Tenant Domain, as described in <xref target="RFC7761" format="default"
<t> />. This
If the MEG SBD&nbhy;DR is to be the FHR for the Tenant Domain, it means that the MEG SBD-DR must know the identity of the
RP for each group, must send Register messages
to the RP, etc.
</t>
<t>
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 must see all the multicast traffic that is sourced from within the
domain and destined to an ASM group address. The MEG can ensure domain and destined to an ASM group address. The MEG can ensure
this by originating an SBD&nbhy;SMET route for (*,*). this by originating an SBD-SMET route for (*,*).
</t> </t>
<t> <t>
(As a possible optimization, an SBD&nbhy;SMET route for (*, "any (As a possible optimization, an SBD-SMET route for (*, any
ASM group") may be defined in a separate document.) ASM group) may be defined in a separate document.)
</t> </t>
<t> <t>
In some deployment scenarios, it may be preferred that the MEG In some deployment scenarios, it may be preferred that the MEG
that receives the (S,G) traffic over an AC be the one providing the that receives the (S,G) traffic over an AC be the one providing the
FHR functionality. This behavior is OPTIONAL. If this option is FHR functionality. This behavior is <bcp14>OPTIONAL</bcp14>. If this
used, it MUST be ensured that the MEG DR does not provide option is
used, it <bcp14>MUST</bcp14> be ensured that the MEG DR does not provi
de
the FHR functionality for (S,G) traffic that is attached to the FHR functionality for (S,G) traffic that is attached to
another MEG; FHR functionality for (S,G) traffic from a particular another MEG; FHR functionality for (S,G) traffic from a particular
source S MUST be provided by only a single router. source S <bcp14>MUST</bcp14> be provided by only a single router.
</t> </t>
<t> <t>
Other deployment scenarios are also possible. For example, one Other deployment scenarios are also possible. For example, one
might want to configure the MEGs themselves to be RPs. In this might want to configure the MEGs themselves to be RPs. In this
case, the RPs would have to exchange with each other information case, the RPs would have to exchange with each other information
about which sources are active. The method exchanging such about which sources are active. The method exchanging such
information is outside the scope of this document. information is outside the scope of this document.
</t> </t>
</section> <!-- e2m_asm --> </section>
<section title="Source on Multihomed Segment" anchor="e2m_multi"> <section anchor="e2m_multi" numbered="true" toc="default">
<t> <name>Source on Multihomed Segment</name>
Suppose S is attached to a segment that is all&nbhy;active <t>
multi&nbhy;homed to PEl and PE2. If S is transmitting to two Suppose S is attached to a segment that is all-active
multihomed to PE1 and PE2. If S is transmitting to two
groups, say G1 and G2, it is possible that PE1 will receive the groups, say G1 and G2, it is possible that PE1 will receive the
(S,G1) traffic from S while PE2 receives the (S,G2) traffic from (S,G1) traffic from S, whereas PE2 will receive the (S,G2) traffic fro m
S. S.
</t> </t>
<t> <t>
This creates an issue for MVPN/EVPN interworking, because there is This creates an issue for MVPN/EVPN interworking, because there is
no way to cause L3VPN/MVPN nodes to select PE1 as the ingress PE no way to cause L3VPN/MVPN nodes to select PE1 as the ingress PE
for (S,G1) traffic while selecting PE2 as the ingress PE for for (S,G1) traffic while selecting PE2 as the ingress PE for
(S,G2) traffic. (S,G2) traffic.
</t> </t>
<t> <t>
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 pick the
"wrong" EVPN&nbhy;PE as the Upstream PE for (say) the (S,G1) wrong EVPN PE as the Upstream PE for, e.g., the (S,G1)
traffic. traffic.
</t> </t>
<t> <t>
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&nbhy;homed to both PE1 and PE2, where PE1 is a MEG. And multihomed to both PE1 and PE2, where PE1 is a MEG. And
suppose that IP multicast traffic from S to G travels over the AC suppose that IP multicast traffic from S to G travels over the AC
that attaches the segment to PE2. If PE1 receives a that attaches the segment to PE2. If PE1 receives a
C&nbhy;multicast Source Tree Join (S,G) route, it MUST originate C-multicast Source Tree Join (S,G) route, it <bcp14>MUST</bcp14> origi
an SMET route for (S,G). Normal OISM procedures will then cause nate
a SMET route for (S,G). Normal OISM procedures will then cause
PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast
tunnel. Normal OISM procedures will also cause PE1 to send the tunnel. Normal OISM procedures will also cause PE1 to send the
(S,G) traffic up its BD1 IRB interface. Normal MVPN procedures (S,G) traffic up its BD1 IRB interface. Normal MVPN procedures
will then cause PE1 to forward the traffic on an MVPN tunnel. In will then cause PE1 to forward the traffic on an MVPN tunnel. In
this case, the routing is not optimal, but the traffic does flow this case, the routing is not optimal, but the traffic does flow
correctly. correctly.
</t> </t>
</section> <!-- e2m_multi --> </section>
</section> <!-- e2m --> </section>
<section anchor="optimal" numbered="true" toc="default">
<!-- </section> <!-\- iwork_model -\-> --> <name>Obtaining Optimal Routing of Traffic between MVPN and EVPN</na
me>
<section title="Obtaining Optimal Routing of Traffic Between MVPN and EVPN" <t>
anchor="optimal">
<t>
The routing of IP multicast traffic between MVPN nodes and EVPN The routing of IP multicast traffic between MVPN nodes and EVPN
nodes will be optimal as long as there is a MEG along the optimal nodes will be optimal as long as there is a MEG along the optimal
route. There are various deployment strategies that can be used to route. There are various deployment strategies that can be used to
obtain optimal routing between MVPN and EVPN. obtain optimal routing between MVPN and EVPN.
</t> </t>
<t> <t>
In one such scenario, a Tenant Domain will have a small number of In one such scenario, a Tenant Domain will have a small number of
strategically placed MEGs. For example, a Data Center may have a strategically placed MEGs. For example, a data center may have a
small number of MEGs that connect it to a wide-area network. Then small number of MEGs that connect it to a wide-area network. Then,
the optimal route into or out of the Data Center would be through the optimal route into or out of the data center would be through
the MEGs. the MEGs.
</t> </t>
<t> <t>
In this scenario, the MEGs do not need to originate VPN&nbhy;IP host In this scenario, the MEGs do not need to originate VPN-IP host
routes for the multicast sources, they only need to originate routes for the multicast sources; they only need to originate
VPN&nbhy;IP subnet routes. The internal structure of the EVPN is VPN-IP subnet routes. The internal structure of the EVPN is
completely hidden from the MVPN node. EVPN actions such as MAC completely hidden from the MVPN node. EVPN actions, such as MAC
Mobility and Mass Withdrawal <xref target="RFC7432"/> have zero Mobility and Mass Withdrawal <xref target="RFC7432" format="default"/>,
have zero
impact on the MVPN control plane. impact on the MVPN control plane.
</t> </t>
<t> <t>
While this deployment scenario provides the most optimal routing and While this deployment scenario provides the most optimal routing and
has the least impact on the installed based of MVPN nodes, it does has the least impact on the installed based of MVPN nodes, it does
complicate network planning considerations. complicate network planning considerations.
</t> </t>
<t> <t>
Another way of providing routing that is close to optimal is to turn Another way of providing routing that is close to optimal is to turn
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&nbhy;homed Ethernet to be optimal when a source host is on a multihomed Ethernet
segment (as discussed in <xref target="e2m"/>.) segment (as discussed in <xref target="e2m" format="default"/>.)
</t> </t>
<t> <t>
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.
</t> </t>
<t> <t>
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 MEG functionality to any subset of its EVPN OISM PEs. This allows
an operator to make whatever trade-offs deemed appropriate between an operator to make whatever trade-offs deemed appropriate between
optimal routing and MEG deployment. optimal routing and MEG deployment.
</t> </t>
</section> <!-- optimal --> </section>
<section anchor="dr_selection" numbered="true" toc="default">
<section title="Selecting the MEG SBD-DR" anchor="dr_selection"> <name>Selecting the MEG SBD-DR</name>
<!-- <t> -->
<!-- Each MEG for a given Tenant Domain MUST be configured with a "MEG -
->
<!-- Ethernet Segment" for that domain. This is an Ethernet Segment tha
t -->
<!-- has no ACs. Conceptually, it represents the set of non-MEG PEs -->
<!-- contained in the Tenant Domain. In the control plane, this Etherne
t -->
<!-- Segment is identified by an ESI of Type 0; thus the ESI is an -->
<!-- arbitrary 9-octet value, managed and configured by the operator. --
>
<!-- </t> -->
<!-- <t> -->
<!-- EVPN supports a number of procedures that can be used to select the
-->
<!-- Designated Forwarder (DF) for a particular BD on a particular -->
<!-- Ethernet segment. Some of the possible procedures can be found, --
>
<!-- e.g., in <xref target="RFC7432"/>, <xref target="EVPN-DF-NEW"/>, an
d -->
<!-- <xref target="I-D.ietf-bess-evpn-pref-df"/>. Whatever procedure is
in use in -->
<!-- a given deployment can be adapted to select a MEG DR for a given BD
, -->
<!-- as follows. -->
<!-- </t> -->
<!-- <t> -->
<!-- Each MEG will originate an Ethernet Segment route for the MEG -->
<!-- Ethernet Segment. It MUST carry an ES-Import Route Target whose --
>
<!-- value is set to the high-order 6-octets of the MEG ESI. Thus only
-->
<!-- MEGs will import the route. -->
<!-- </t> -->
<!-- <t> -->
<!-- Once the set of MEGs is known, it is also possible to determine the
-->
<!-- set of BDs supported by each MEG. The DF selection procedure can -
->
<!-- then be used to choose a MEG DR for the SBD. (The conditions under
-->
<!-- which the MEG DR changes depends upon the DF selection algorithm --
>
<!-- that is in use.) -->
<!-- </t> -->
<!-- <t> -->
<!-- These procedures can also be used to select a DR for each BD. If -
->
<!-- the interworking scenario requires FHR functionality, it is -->
<!-- generally the DR for a particular BD that is responsible for -->
<!-- performing that functionality on behalf of the source hosts on that
-->
<!-- BD. -->
<!-- </t> -->
<t>
Every PE that is eligible for selection as the MEG SBD&nbhy;DR
originates an SBD&nbhy;IMET route. As stated in <xref
target="no-OISM"/>, these SBD&nbhy;IMET routes carry a Multicast Flags
EC with the MEG Flag set.
</t>
<t>
These SBD&nbhy;IMET routes SHOULD also carry a DF Election EC. The DF
Election EC and its use are specified in <xref
target="RFC8584"/>. When the route is originated, the
AC&nbhy;DF bit in the DF Election EC SHOULD be set to zero. This bit
is not used when selecting a MEG SBD&nbhy;DR, i.e., it MUST be ignored
by the receiver of an SBD&nbhy;IMET route.
</t>
<t> <t>
Every PE that is eligible for selection as the MEG SBD-DR
originates an SBD-IMET route. As stated in <xref target="no-OISM" format=
"default"/>, these SBD-IMET routes carry a Multicast Flags
EC with the MEG flag set.
</t>
<t>
These SBD-IMET routes <bcp14>SHOULD</bcp14> also carry a DF Election EC.
The DF
Election EC and its use are specified in <xref target="RFC8584" format="de
fault"/>. When the route is originated, the
AC-DF bit in the DF Election EC <bcp14>SHOULD</bcp14> be set to zero. Thi
s bit
is not used when selecting a MEG SBD-DR, i.e., it <bcp14>MUST</bcp14> be i
gnored
by the receiver of an SBD-IMET route.
</t>
<t>
In the context of a given Tenant Domain, to select the MEG SBD-DR, the In the context of a given Tenant Domain, to select the MEG SBD-DR, the
MEGs of the Tenant Domain perform the following procedure: MEGs of the Tenant Domain perform the following procedure:
<list style="symbols"> </t>
<t> <ul spacing="normal">
From the set of received SBD&nbhy;IMET routes for the given tenant <li>
domain, determine the candidate set of PEs that support MEG <t>
From the set of received SBD-IMET routes for the given Tenant
Domain, determine the candidate set of PEs that support MEG
functionality for that domain. functionality for that domain.
</t> </t>
<t> </li>
Select a DF Election algorithm as specified in <xref <li>
target="RFC8584"/>. Some of the possible algorithms <t>
can be found, e.g., in <xref target="RFC7432"/>, <xref Select a DF election algorithm as specified in <xref target="RFC8584"
target="RFC8584"/>, and <xref format="default"/>. Some of the possible algorithms
target="I-D.ietf-bess-evpn-pref-df"/>. can be found, e.g., in <xref target="RFC7432" format="default"/>, <xre
</t> f target="RFC8584" format="default"/>, and <xref target="I-D.ietf-bess-evpn-pref
<t> -df" format="default"/>.
Apply the DF Election Algorithm (see <xref </t>
target="RFC8584"/>) to the candidate set of PEs. </li>
The "winner" becomes the MEG SBD-DR. <li>
</t> <t>
</list> Apply the DF election algorithm (see <xref target="RFC8584" format="de
</t> fault"/>) to the candidate set of PEs.
<t> The winner becomes the MEG SBD-DR.
Note that if a given PE supports IPMG (<xref target="mvpn"/>) or PEG </t>
(<xref target="pim_iwork"/>) functionality as well as MEG </li>
functionality, its SBD&nbhy;IMET routes carry only one DF Election EC. </ul>
</t> <t>
Note that if a given PE supports IPMG (<xref target="mvpn" format="default
</section> <!-- dr_selection --> "/>) or PEG
</section> <!-- mvpn --> (<xref target="pim_iwork" format="default"/>) functionality as well as MEG
functionality, its SBD-IMET routes carry only one DF Election EC.
<section title="Interworking with 'Global Table Multicast'" </t>
anchor="gtm"> </section>
<t> </section>
<section anchor="gtm" numbered="true" toc="default">
<name>Interworking with Global Table Multicast</name>
<t>
If multicast service to the outside sources and/or receivers is If multicast service to the outside sources and/or receivers is
provided via the BGP-based "Global Table Multicast" (GTM) procedures provided via the BGP-based Global Table Multicast (GTM) procedures
of <xref target="RFC7716"/>, the procedures of <xref target="mvpn"/> of <xref target="RFC7716" format="default"/>, the procedures of <xref targ
et="mvpn" format="default"/>
can easily be adapted for EVPN/GTM interworking. The way to adapt the can easily be adapted for EVPN/GTM interworking. The way to adapt the
MVPN procedures to GTM is explained in <xref target="RFC7716"/>. MVPN procedures to GTM is explained in <xref target="RFC7716" format="defa
</t> ult"/>.
</section> <!-- gtm --> </t>
</section>
<section title="Interworking with PIM" anchor="pim_iwork"> <section anchor="pim_iwork" numbered="true" toc="default">
<t> <name>Interworking with PIM</name>
As we have been discussing, there may be receivers in an EVPN tenant <t>
domain that are interested in multicast flows whose sources are As discussed, there may be receivers in an EVPN Tenant
Domain that are interested in multicast flows whose sources are
outside the EVPN Tenant Domain. Or there may be receivers outside an outside the EVPN Tenant Domain. Or there may be receivers outside an
EVPN Tenant Domain that are interested in multicast flows whose EVPN Tenant Domain that are interested in multicast flows whose
sources are inside the Tenant Domain. sources are inside the Tenant Domain.
</t> </t>
<t>
<t>
If the outside sources and/or receivers are part of an MVPN, If the outside sources and/or receivers are part of an MVPN,
interworking procedures are covered in <xref target="mvpn"/>. see the procedures for interworking that are covered in <xref target="mvpn
</t> " format="default"/>.
<t> </t>
<t>
There are also cases where an external source or receiver are attached There are also cases where an external source or receiver are attached
via IP, and the layer 3 multicast routing is done via PIM. In this via IP and the Layer 3 multicast routing is done via PIM. In this
case, the interworking between the "PIM domain" and the EVPN tenant case, the interworking between the PIM domain and the EVPN Tenant
domain is done at L3 Gateways that perform "PIM/EVPN Gateway" (PEG) Domain is done at L3 Gateways that perform PIM/EVPN Gateway (PEG)
functionality. A PEG is very similar to a MEG, except that its layer functionality. A PEG is very similar to a MEG, except that its Layer
3 multicast routing is done via PIM rather than via BGP. 3 multicast routing is done via PIM rather than via BGP.
</t> </t>
<t> <t>
If external sources or receivers for a given group are attached to a If external sources or receivers for a given group are attached to a
PEG via a layer 3 interface, that interface should be treated as a VRF PEG via a Layer 3 interface, that interface should be treated as a VRF
interface attached to the Tenant Domain's L3VPN VRF. The layer 3 interface attached to the Tenant Domain's L3VPN VRF. The Layer 3
multicast routing instance for that Tenant Domain will either run PIM multicast routing instance for that Tenant Domain will either run PIM
on the VRF interface or will listen for IGMP/MLD messages on that on the VRF interface or listen for IGMP/MLD messages on that
interface. If the external receiver is attached elsewhere on an IP interface. If the external receiver is attached elsewhere on an IP
network, the PE has to enable PIM on its interfaces to the backbone network, the PE has to enable PIM on its interfaces to the backbone
network. In both cases, the PE needs to perform PEG functionality, network. In both cases, the PE needs to perform PEG functionality,
and its IMET routes must carry the Multicast Flags EC with the PEG and its IMET routes must carry the Multicast Flags EC with the PEG
flag set. flag set.
</t> </t>
<t> <t>
For each BD on which there is a multicast source or receiver, one of For each BD on which there is a multicast source or receiver, one of
the PEGs will becomes the PEG DR. DR selection can be done using the the PEGs will become the PEG DR. DR selection can be done using the
same procedures specified in <xref target="dr_selection"/>, except same procedures specified in <xref target="dr_selection" format="default"/
with "PEG" substituted for "MEG". >, except
</t> with PEG substituted for MEG.
<t> </t>
<t>
As long as there are no tenant multicast routers within the EVPN As long as there are no tenant multicast routers within the EVPN
Tenant Domain, the PEGs do not need to run PIM on their IRB Tenant Domain, the PEGs do not need to run PIM on their IRB
interfaces. interfaces.
</t>
<section title="Source Inside EVPN Domain" anchor="evpn_source">
<t>
If a PEG receives a PIM Join(S,G) from outside the EVPN tenant
domain, it may find it necessary to create (S,G) state. The PE
needs to determine whether S is within the Tenant Domain. If S is
not within the EVPN Tenant Domain, the PE carries out normal layer 3
multicast routing procedures. If S is within the EVPN tenant
domain, the IIF of the (S,G) state is set as follows:
<list style="symbols">
<t>
if S is on a BD that is attached to the PE, the IIF is the
PE's IRB interface to that BD;
</t> </t>
<t> <section anchor="evpn_source" numbered="true" toc="default">
if S is not on a BD that is attached to the PE, the IIF is the <name>Source Inside EVPN Domain</name>
<t>
If a PEG receives a PIM Join (S,G) from outside the EVPN Tenant
Domain, it may find it necessary to create (S,G) state. The PE
needs to determine whether S is within the Tenant Domain. If S is
not within the EVPN Tenant Domain, the PE carries out normal Layer 3
multicast routing procedures. If S is within the EVPN Tenant
Domain, the IIF of the (S,G) state is set as follows:
</t>
<ul spacing="normal">
<li>
<t>
If S is on a BD that is attached to the PE, the IIF is the
PE's IRB interface to that BD.
</t>
</li>
<li>
<t>
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.
</t> </t>
</list> </li>
</t> </ul>
<t> <t>
When the PE creates such an (S,G) state, it MUST originate (if it When the PE creates such an (S,G) state, it <bcp14>MUST</bcp14> originat
hasn't already) an SBD&nbhy;SMET route for (S,G). This will cause e (if it
it to pull the (S,G) traffic via layer 2. When the traffic arrives 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 EVPN tunnel, it gets sent up an IRB interface where the over an EVPN tunnel, it gets sent up an IRB interface where the
layer 3 multicast routing determines the packet's disposition. The Layer 3 multicast routing determines the packet's disposition. The
SBD&nbhy;SMET route is withdrawn when the (S,G) state no longer SBD-SMET route is withdrawn when the (S,G) state no longer
exists (unless there is some other reason for not withdrawing it). exists (unless there is some other reason for not withdrawing it).
</t> </t>
<t> <t>
If there are no tenant multicast routers within the EVPN tenant 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 Domain, there cannot be an RP in the Tenant Domain, so a PEG does
not have to handle externally arriving PIM Join(*,G) messages. not have to handle externally arriving PIM Join (*,G) messages.
</t> </t>
<!-- <t> -->
<!-- It is possible that the PEG may later receive PIM Prune(S,G,rpt) --
>
<!-- from the external network. At that time, it MAY advertise
(C&nbhy;S,C&nbhy;G) -->
<!-- an SMET route with the Exclude Group type bit and IGMPv3 bit in the
-->
<!-- Flags field set (see <xref target="RFC9251"/> for details), -->
<!-- signaling to other EVPN PEs that the particular
(C&nbhy;S,C&nbhy;G) traffic is -->
<!-- not needed. -->
<!-- </t> -->
<!-- <t> -->
<!-- <cref source=" ECR"> -->
<!-- It seems to me that the above paragraph is not needed, because we
-->
<!-- are assuming there is no RP in the Tenant Domain. So we can't ge
t -->
<!-- Prune(S,G,rpt). Am I wrong about that? -->
<!-- </cref> -->
<!-- </t> -->
<t> <t>
The PEG DR for a particular BD MUST act as the a First Hop Router The PEG DR for a particular BD <bcp14>MUST</bcp14> act as the a First Ho p Router
for that BD. It will examine all (S,G) traffic on the BD, and for 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 whenever G 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 to the RP for G. This means that the PEG DR will need to pull all
the (S,G) traffic originating on a given BD, by originating an SMET the (S,G) traffic originating on a given BD by originating a SMET
(*,*) route for that BD. If a PEG DR is the DR for all the BDs, in (*,*) route for that BD. If a PEG DR is the DR for all the BDs, it
SHOULD originate just an SBD&nbhy;SMET (*,*) route rather than an <bcp14>SHOULD</bcp14> originate just an SBD-SMET (*,*) route rather than
a
SMET (*,*) route for each BD. SMET (*,*) route for each BD.
</t> </t>
<t> <t>
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 <xref target="e2m"/>, except that the as those specified for MEGs in <xref target="e2m" format="default"/>, ex
exported routes will be IP routes rather than VPN&nbhy;IP routes, cept that the
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 and it is not necessary to attach the VRF Route Import EC or the
Source AS EC. Source AS EC.
</t> </t>
<t> <t>
When a source is on a multi&nbhy;homed segment, the same issue When a source is on a multihomed segment, the same issue
discussed in <xref target="e2m_multi"/> exists. Suppose S is on an discussed in <xref target="e2m_multi" format="default"/> exists. Suppos
Ethernet segment, belonging to BD1, that is multi&nbhy;homed to both e S is on an
Ethernet segment, belonging to BD1, that is multihomed to both
PE1 and PE2, where PE1 is a PEG. And suppose that IP multicast PE1 and PE2, where PE1 is a PEG. And suppose that IP multicast
traffic from S to G travels over the AC that attaches the segment to traffic from S to G travels over the AC that attaches the segment to
PE2. If PE1 receives an external PIM Join (S,G) route, it MUST PE2. If PE1 receives an external PIM Join (S,G) route, it <bcp14>MUST</
originate an SMET route for (S,G). Normal OISM procedures will bcp14>
originate a SMET route for (S,G). Normal OISM procedures will
cause PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast cause PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast
tunnel. Normal OISM procedures will also cause PE1 to send the tunnel. Normal OISM procedures will also cause PE1 to send the
(S,G) traffic up its BD1 IRB interface. Normal PIM procedures will (S,G) traffic up its BD1 IRB interface. Normal PIM procedures will
then cause PE1 to forward the traffic along a PIM tree. In this then cause PE1 to forward the traffic along a PIM tree. In this
case, the routing is not optimal, but the traffic does flow case, the routing is not optimal, but the traffic does flow
correctly. correctly.
</t> </t>
</section>
</section> <!-- evpn_source --> <section anchor="external_source" numbered="true" toc="default">
<name>Source Outside EVPN Domain</name>
<section title="Source Outside EVPN Domain" anchor="external_source"> <t>
<t>
By means of normal OISM procedures, a PEG learns whether there are By means of normal OISM procedures, a PEG learns whether there are
receivers in the Tenant Domain that are interested in receiving receivers in the Tenant Domain that are interested in receiving
(*,G) or (S,G) traffic. The PEG must determine whether S (or the RP (*,G) or (S,G) traffic. The PEG must determine whether or not S (or the RP
for G) is outside the EVPN Tenant Domain. If so, and if there is a for G) is outside the EVPN Tenant Domain. If so, and if there is a
receiver on BD1 interested in receiving such traffic, the PEG DR for receiver on BD1 interested in receiving such traffic, the PEG DR for
BD1 is responsible for originating a PIM Join(S,G) or Join(*,G) BD1 is responsible for originating a PIM Join (S,G) or Join (*,G)
control message. control message.
</t> </t>
<t> <t>
An alternative would be to allow any PEG that is directly attached to An alternative would be to allow any PEG that is directly attached to
a receiver to originate the PIM Joins. Then the PEG DR would only a receiver to originate the PIM Joins. Then, the PEG DR would only
have to originate PIM Joins on behalf of receivers that are not have to originate PIM Joins on behalf of receivers that are not
attached to a PEG. However, if this is done, it is necessary for the attached to a PEG. However, if this is done, it is necessary for the
PEGs to run PIM on all their IRB interfaces, so that the PIM Assert PEGs to run PIM on all their IRB interfaces so that the PIM Assert
procedures can be used to prevent duplicate delivery to a given BD. procedures can be used to prevent duplicate delivery to a given BD.
</t> </t>
<t> <t>
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 (*,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 to 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 is added to the OIF list. state, and the SBD IRB interface is added to the OIF list.
</t> </t>
<!-- <t> --> </section>
<!-- However, there is the following problem. Suppose group G has both </section>
--> </section>
<!-- external sources (sources outside the EVPN Tenant Domain) and --> <section anchor="external_pim_router" numbered="true" toc="default">
<!-- internal sources (sources inside the EVPN Tenant Domain). <xref --> <name>Interworking with PIM via an External PIM Router</name>
<!-- target="rpf"/> states that when there are internal sources, the SBD
-->
<!-- IRB interface must not be added to the oiflist of the (*,G) state.
-->
<!-- Traffic from internal sources will have been sent down the SBD IRB
-->
<!-- interface of its ingress PE, and thus will already have been -->
<!-- delivered to all the EVPN PEs that have interest in it. However, i
f -->
<!-- the oiflist of the PEG DR's (*,G) state does not contain its SBD IR
B -->
<!-- interface, then traffic from external sources will not get delivere
d -->
<!-- to other EVPN PEs. Therefore, when the PEG DR receives (S,G) -->
<!-- traffic corresponding to a layer 3 (*,G) state, the PEG DR MUST -->
<!-- create (S,G) state. The iif will be set to whatever external -->
<!-- interface the (S,G) traffic is expected to arrive on, and the -->
<!-- oiflist will contain the SBD IRB interface, as well as the IRB -->
<!-- interfaces of any other BDs attached to the PEG DR that have locall
y -->
<!-- attached receivers with interest in the (S,G) traffic. -->
<!-- </t> -->
</section> <!-- external source -->
</section> <!-- pim_iwork -->
</section> <!-- evpn-pe-l3-iwork -->
<section title="Interworking with PIM via an External PIM Router"
anchor="external_pim_router">
<!--t>
<cref source=" ECR">
I made some changes to this section (formerly titled "A Variation on
External Connection"), so I might have introduced some errors. I
removed the requirement for the "gateway BD" to be the SBD, as that
doesn't seem to be necessary, and I'm not sure we want to say that the
SBD can have ACs. I removed the mention of Layer 3 multicast states,
as I think the Layer 3 states are constructed via normal OISM
procedures. I removed the mention of AE bundles because that is an
implementation/deployment issue. Please correct anything I screwed up
here.
</cref>
</t-->
<t> <t>
<xref target="evpn-pe-l3-iwork"/> describes how to use an OISM PE router <xref target="evpn-pe-l3-iwork" format="default"/> describes how to use an O
as the gateway to a non&nbhy;EVPN multicast domain, when the EVPN tenant ISM PE router
domain is not being used as an intermediate transit network for as the gateway to a non-EVPN multicast domain when the EVPN Tenant
Domain is not being used as an intermediate transit network for
multicast. An alternative approach is to have one or more external PIM multicast. An alternative approach is to have one or more external PIM
routers (perhaps operated by a tenant) on one of the BDs of the tenant routers (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".
</t> </t>
<t> <t>
In this model: In this model:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
<t>
The EVPN Tenant Domain is treated as a stub network attached to the The EVPN Tenant Domain is treated as a stub network attached to the
external PIM routers. external PIM routers.
</t> </t>
<t> </li>
The external PIM routers follow normal PIM procedures, and provide <li>
<t>
The external PIM routers follow normal PIM procedures and provide
the FHR and LHR functionality for the entire Tenant Domain. the FHR and LHR functionality for the entire Tenant Domain.
</t> </t>
<t> </li>
<li>
<t>
The OISM PEs do not run PIM. The OISM PEs do not run PIM.
</t> </t>
<t> </li>
There MUST NOT be more than one gateway BD. <li>
</t> <t>
<t> There <bcp14>MUST NOT</bcp14> be more than one gateway BD.
</t>
</li>
<li>
<t>
If an OISM PE not attached to the gateway BD has interest in a given If an OISM PE not attached to the gateway BD has interest in a given
multicast flow, it conveys that interest, following normal OISM multicast flow, it conveys that interest, following normal OISM
procedures, by originating an SBD-SMET route for that flow. procedures, by originating an SBD-SMET route for that flow.
</t> </t>
<t> </li>
<li>
<t>
If a PE attached to the gateway BD receives an SBD-SMET, it may need If a PE attached to the gateway BD receives an SBD-SMET, it may need
to generate and transmit a corresponding IGMP/MLD Join on one or to generate and transmit a corresponding IGMP/MLD Join on one or
more of its ACs. (Procedures for generating an IGMP/MLD Join as a more of its ACs. (Procedures for generating an IGMP/MLD Join as a
result of receiving an SMET route are given in <xref result of receiving a SMET route are given in <xref target="RFC9251" for
target="RFC9251"/>.) The PE MUST know which BD is the Gateway BD mat="default"/>.) The PE <bcp14>MUST</bcp14> know which BD is the gateway BD
and MUST NOT transmit an IGMP/MLD Join to any other BDs. and <bcp14>MUST NOT</bcp14> transmit an IGMP/MLD Join to any other BDs.
Furthermore, even if a particular AC is part of that BD, the PE Furthermore, even if a particular AC is part of that BD, the PE
SHOULD NOT transmit an IGMP/MLD Join on that AC unless there is an <bcp14>SHOULD NOT</bcp14> transmit an IGMP/MLD Join on that AC unless th ere is an
external PIM router attached via that AC. external PIM router attached via that AC.
<vspace/> </t>
<vspace/> <t>
As a result, IGMP/MLD messages will be received by the external PIM rout ers As a result, IGMP/MLD messages will be received by the external PIM rout ers
on the gateway BD, and those external PIM routers will send PIM Join on the gateway BD, and those external PIM routers will send PIM Join
messages externally as required. Traffic for the given multicast flow messages externally as required. Traffic for the given multicast flow
will then be received by one of the external PIM routers, and that will then be received by one of the external PIM routers, and that
traffic will be forwarded by that router to the gateway BD. traffic will be forwarded by that router to the gateway BD.
<vspace/> </t>
<vspace/> <t>
The normal OISM procedures will then cause the given multicast flow The normal OISM procedures will then cause the given multicast flow
to be tunneled to any PEs of the EVPN Tenant Domain that have 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 and other PEs will see the flow flow as originating from the gateway BD, and other PEs will see the flow
as originating from the SBD. as originating from the SBD.
</t> </t>
<t> </li>
An OISM PE attached to a gateway BD MUST set its layer 2 multicast <li>
<t>
An OISM PE attached to a gateway BD <bcp14>MUST</bcp14> set its Layer 2
multicast
state to indicate that each AC to the gateway BD has interest in all state to indicate that each AC to the gateway BD has interest in all
multicast flows. It MUST also originate an SMET route for (*,*). multicast flows. It <bcp14>MUST</bcp14> also originate a SMET route for
The procedures for originating SMET routes are discussed in <xref (*,*).
target="interest"/>. The procedures for originating SMET routes are discussed in <xref target
<vspace/> ="interest" format="default"/>.
<vspace/> </t>
<t>
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 tenant all the IP multicast traffic that is sourced within the EVPN Tenant
domain, and to transmit that traffic to the gateway BD, where the Domain and to transmit that traffic to the gateway BD, where the
external PIM routers will receive it. This enables the external PIM external PIM routers will receive it. This enables the external PIM
routers to perform FHR functions on behalf of the entire Tenant routers to perform FHR functions on behalf of the entire Tenant
Domain. (Of course, if the gateway BD has a multi&nbhy;homed Domain. (Of course, if the gateway BD has a multihomed
segment, only the PE that is the DF for that segment will transmit segment, only the PE that is the DF for that segment will transmit
the multicast traffic to the segment.) the multicast traffic to the segment.)
</t> </t>
</list> </li>
</t> </ul>
</section>
</section> <!-- external_pim_router --> </section>
</section> <!-- external --> <section anchor="pim" numbered="true" toc="default">
<name>Using an EVPN Tenant Domain as an Intermediate (Transit) Network for
<section title="Using an EVPN Tenant Domain as an Intermediate (Transit) Network Multicast Traffic</name>
for Multicast traffic"
anchor="pim">
<!--t>
<cref source=" ECR">
Basically this section says "Use PIM, send PIM messages transparently,
and use SMET routes to be sure you pull the right traffic to the right
place if the traffic is originating from the Tenant Domain, or if the
traffic is being sent through the Tenant Domain by a tenant router."
One might expect there to be a "use the SMET routes to recreate the
PIM messages", but that isn't present in this rev. (There are a few
comments where we might consider that.)
</cref>
</t-->
<t> <t>
In this section, we consider the scenario where one or more BDs of an In this section, we consider the scenario where one or more BDs of an
EVPN Tenant Domain are being used to carry IP multicast traffic for EVPN Tenant Domain are being used to carry IP multicast traffic for
which the source and at least one receiver are not part the tenant which the source and at least one receiver are not part the Tenant
domain. That is, one or more BDs of the Tenant Domain are intermediate Domain. That is, one or more BDs of the Tenant Domain are intermediate
"links" of a larger multicast tree created by PIM. links of a larger multicast tree created by PIM.
</t>
<t>
We define a "tenant multicast router" as a multicast router, running
PIM, that is:
<list style="format %d.">
<t>
attached to one or more BDs of the Tenant Domain, but
</t> </t>
<t> <t>
is not an EVPN PE router. We define a "tenant multicast router" as a multicast router, running
PIM, that:
</t> </t>
</list> <ol spacing="normal" type="1"><li>
</t> <t>
<t> is attached to one or more BDs of the Tenant Domain but
In order an EVPN Tenant Domain to be used as a transit network for IP </t>
</li>
<li>
<t>
is not an EVPN PE router.
</t>
</li>
</ol>
<t>
In order for an EVPN Tenant Domain to be used as a transit network for IP
multicast, one or more of its BDs must have tenant multicast routers, multicast, one or more of its BDs must have tenant multicast routers,
and an OISM PE that attaching to such a BD MUST be provisioned to enable and an OISM PE attached to such a BD <bcp14>MUST</bcp14> be provisioned to e
PIM on its IRB interface to that BD. (This is true even if none of the nable
PIM on its IRB interface to that BD. (This is true even if none of the
tenant routers is on a segment attached to the PE.) Further, all the tenant routers is on a segment attached to the PE.) Further, all the
OISM PEs (even ones not attached to a BD with tenant multicast routers) OISM PEs (even ones not attached to a BD with tenant multicast routers)
MUST be provisioned to enable PIM on their SBD IRB interfaces. <bcp14>MUST</bcp14> be provisioned to enable PIM on their SBD IRB interfaces
</t> .
<t> </t>
If PIM is enabled on a particular BD, the DR Selection procedure of <t>
<xref target="dr_selection"/> MUST be replaced by the normal PIM DR If PIM is enabled on a particular BD, the DR selection procedure of
Election procedure of <xref target="RFC7761"/>. Note that this may <xref target="dr_selection" format="default"/> <bcp14>MUST</bcp14> be replac
result in one of the tenant routers being selected as the DR, rather ed by the normal PIM DR
Election procedure of <xref target="RFC7761" format="default"/>. Note that
this may
result in one of the tenant routers being selected as the DR rather
than one of the OISM PE routers. In this case, First Hop Router and than one of the OISM PE routers. In this case, First Hop Router and
Last Hop Router functionality will not be performed by any of the EVPN Last Hop Router functionality will not be performed by any of the EVPN
PEs. PEs.
</t> </t>
<t> <t>
A PIM control message on a particular BD is considered to be a A PIM control message on a particular BD is considered to be a
link&nbhy;local multicast message, and as such is sent transparently link-local multicast message and, as such, is sent transparently
from PE to PE via the BUM tunnel for that BD. This is true whether the from PE to PE via the BUM tunnel for that BD. This is true whether the
control message was received from an AC, or whether it was received from control message was received from an AC or from
the local layer 3 routing instance via an IRB interface. the local Layer 3 routing instance via an IRB interface.
</t> </t>
<!--t>
<cref source=" ECR">
Do we need to consider "PIM Proxy" optimizations here?
</cref>
</t-->
<t> <t>
A PIM Join/Prune message contains three fields that are relevant to the A PIM Join/Prune message contains three fields that are relevant to the
present discussion: present discussion:
<list style="symbols">
<t>
Upstream Neighbor
</t> </t>
<t> <ul spacing="normal">
<li>
<t>
Upstream Neighbor
</t>
</li>
<li>
<t>
Group Address (G) Group Address (G)
</t> </t>
</li>
<li>
<t>
Source Address (S), omitted in the case of (*,G) Join/Prune messages
</t>
</li>
</ul>
<t> <t>
Source Address (S), omitted in the case of (*,G) Join/Prune messages. We will generally speak of a PIM Join as a Join (S,G) or a Join (*,G)
message and will use the term "Join (X,G)" to mean either "Join (S,G)" or
"Join (*,G)". In the context of a Join (X,G), we will use the term "X" to
mean "S" in the case of (S,G) or "G's RP" in the case of (*,G).
</t> </t>
</list> <t>
</t> Suppose BD1 contains two tenant multicast routers, say C1 and C2. Suppose
<t> C1 is on a segment attached to PE1 and C2 is on a segment attached to
We will generally speak of a PIM Join as a "Join(S,G)" or a "Join(*,G)" PE2. When C1 sends a PIM Join (X,G) to BD1, the Upstream Neighbor field
message, and will use the term "Join(X,G)" to mean "either Join(S,G) or might be set to PE1, PE2, or C2. C1 chooses the Upstream
Join(*,G)". In the context of a Join(X,G), we will use the term "X" to Neighbor based on its unicast routing. Typically, it will choose
mean "S in the case of (S,G), or G's RP in the case of (*,G)". the PIM router on BD1 that is closest (according to
</t> the unicast routing) to X as the
<t> Upstream Neighbor. Note that this will not necessarily be PE1.
Suppose BD1 contains two tenant multicast routers, C1 and C2. Suppose
C1 is on a segment attached to PE1, and C2 is on a segment attached to
PE2. When C1 sends a PIM Join(X,G) to BD1, the Upstream Neighbor field
might be set to either PE1, PE2, or C2. C1 chooses the Upstream
Neighbor based on its unicast routing. Typically, it will choose as the
Upstream Neighbor the PIM router on BD1 that is "closest" (according to
the unicast routing) to X. Note that this will not necessarily be PE1.
PE1 may not even be visible to the unicast routing algorithm used by the PE1 may not even be visible to the unicast routing algorithm used by the
tenant routers. Even if it is, it is unlikely to be the PIM router that tenant routers. Even if it is, it is unlikely to be the PIM router that
is closest to X. So we need to consider the following two cases: is closest to X. So we need to consider the following two cases:
<list style="format %d. "> </t>
<t> <ol spacing="normal" type="1"><li>
C1 sends a PIM Join(X,G) to BD1, with PE1 as the Upstream Neighbor. <t>
<vspace/> C1 sends a PIM Join (X,G) to BD1, with PE1 as the Upstream Neighbor.
<vspace/> </t>
<t>
PE1's PIM routing instance will receive the Join arrive on the BD1 IRB PE1's PIM routing instance will receive the Join arrive on the BD1 IRB
interface. If X is not within the Tenant Domain, PE1 handles the interface. If X is not within the Tenant Domain, PE1 handles the
Join according to normal PIM procedures. This will generally result Join according to normal PIM procedures. This will generally result
in PE1 selecting an Upstream Neighbor and sending it a Join(X,G). in PE1 selecting an Upstream Neighbor and sending it a Join (X,G).
<vspace/> </t>
<vspace/> <t>
If X is within the Tenant Domain, but is attached to some other PE, If X is within the Tenant Domain but is attached to some other PE,
PE1 sends (if it hasn't already) an SBD&nbhy;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 interface, 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 BD1. and the OIF list will include the IRB interface to BD1.
<vspace/> </t>
<vspace/> <t>
The SBD&nbhy;SMET route will pull the (X,G) traffic to PE1, and the The SBD-SMET route will pull the (X,G) traffic to PE1, and the
(X,G) state will result in the (X,G) traffic being forwarded to C1. (X,G) state will result in the (X,G) traffic being forwarded to C1.
<vspace/> </t>
<vspace/> <t>
If X is within the Tenant Domain, but is attached to PE1 itself, no If X is within the Tenant Domain but is attached to PE1 itself, no
SBD&nbhy;SMET route is sent. The IIF of the layer 3 (X,G) state SBD-SMET route is sent. The IIF of the Layer 3 (X,G) state
will be the IRB interface to X's BD, and the OIF list will include will be the IRB interface to X's BD, and the OIF list will include
the IRB interface to BD1. the IRB interface to BD1.
</t> </t>
<t> </li>
C1 sends a PIM Join(X,G) to BD1, with either PE2 or C2 as the <li>
<t>
C1 sends a PIM Join (X,G) to BD1, with either PE2 or C2 as the
Upstream Neighbor. Upstream Neighbor.
<vspace/> </t>
<vspace/> <t>
PE1's PIM routing instance will receive the Join arrive on the BD1 IRB PE1's PIM routing instance will receive the Join arrive on the BD1 IRB
interface. If neither X nor Upstream Neighbor is within the tenant interface. If neither X nor Upstream Neighbor is within the Tenant
domain, PE1 handles the Join according to normal PIM procedures. Domain, PE1 handles the Join according to normal PIM procedures.
This will NOT result in PE1 sending a Join(X,G). This will NOT result in PE1 sending a Join (X,G).
<vspace/> </t>
<vspace/> <t>
If either X or Upstream Neighbor is within the Tenant Domain, PE1 If either X or Upstream Neighbor is within the Tenant Domain, PE1
sends (if it hasn't already) an SBD&nbhy;SMET route for (X,G). The 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 interface, and IIF of the Layer 3 (X,G) state will be the SBD IRB interface, and
the OIF list will include the IRB interface to BD1. the OIF list will include the IRB interface to BD1.
<vspace/> </t>
<vspace/> <t>
The SBD&nbhy;SMET route will pull the (X,G) traffic to PE1, and the The SBD-SMET route will pull the (X,G) traffic to PE1, and the
(X,G) state will result in the (X,G) traffic being forwarded to C1. (X,G) state will result in the (X,G) traffic being forwarded to C1.
</t> </t>
</list> </li>
</t> </ol>
<!--t> </section>
<cref source=" ECR"> <section anchor="IANA" numbered="true" toc="default">
Above (case 1) is where we might consider using the SMET route to as a <name>IANA Considerations</name>
proxy for a PIM message.
</cref>
</t>
<t>
<cref source=" ECR">
Here (case 2) if we wanted to use the SMET route to proxy for the PIM
Join we'd have to block PIM J/P messages from being sent transparently
from site to site.
</cref>
</t-->
<!-- <t>It is possible that an EVPN broadcast domain is providing -->
<!-- transit service for a tenant's larger network and there are tenant -
->
<!-- routers attached to the subnet, running routing protocols like PIM.
-->
<!-- In that case, traffic routed by an upstream NVE to the subnet via IR
B -->
<!-- interface may be expected on a downstream tenant router. However, --
>
<!-- since multicast data traffic sent down the IRB interfaces -->
<!-- is forwarded to local ACs only and not to other EVPN sites according
-->
<!-- to rule XXX -->
<!-- <!-\- <xref target="blockrule" format="counter"/> in <xref target="s
olution"/>, additional -\-> -->
<!-- procedures are needed to handle this situation with tenant routers.
-->
<!-- In particular, NVEs connecting to tenant routers or traffic sources
-->
<!-- need to run PIM on the IRB interface for the transit subnet and -->
<!-- the SBD. -->
<!-- </t> -->
<!-- <t>Consider the following situation: -->
<!-- <figure> -->
<!-- <artwork> -->
<!-- S1 S2 -->
<!-- \ N1 / N2 -->
<!-- CE1a CE2b -->
<!-- \ vlan1 / vlan1 -->
<!-- NVE1 -\-\-\-\-\-\-\-\-\-\-\- NVE2 -\-\-\- CE2a -\- receiver
-->
<!-- / N3 N4 -->
<!-- S3 -->
<!-- </artwork> -->
<!-- </figure> -->
<!-- </t> -->
<!-- <t>CE1a, CE2a/b are three CE routers on vlan1 that is implemented by EV
PN. -->
<!-- The CEs and NVE1/2 run PIM protocol and are PIM neighbors on vlan1.
-->
<!-- CE2a has a receiver on network N4 for multicast traffic from S1/2/3
-->
<!-- on network N1/2/3 respectively. -->
<!-- </t> -->
<!-- <t>CE2a sends PIM joins to CE1a/CE2b/NVE1 on vlan1 for the three source
s -->
<!-- respectively and they all route traffic accordingly onto vlan1. -->
<!-- Traffic from S1/2 will reach CE2a because NVE1/2 receive the L2 traf
fic -->
<!-- on their ACs and forward across the core following EVPN procedures.
-->
<!-- Traffic from S3 is routed into vlan1 by NVE1 via the IRB interface,
-->
<!-- and per rule XXX -->
<!-- <!-\- <xref target="blockrule" format="counter"/> in <xref target="s
olution"/> the traffic will not be -\-> -->
<!-- sent across the core. Thus, according to the procedures specified --
>
<!-- so far, the traffic from S3 will never be received by NVE2 or CE2a.
-->
<!-- </t> -->
<!-- <t>To solve this problem, NVE2 needs to know that CE2a sent a PIM join
-->
<!-- to another NVE in vlan1 and needs to pull traffic via the SBD, -->
<!-- where the traffic via IRB is not blocked on the core side. Because P
IM -->
<!-- protocol already requires a router to process join/prune messages th
at -->
<!-- it receives on an interface even if it is not the intended RPF neigh
bor -->
<!-- (for the purpose of join suppression and prune overriding), NVE2 can
-->
<!-- realize that the upstream router in the join message is another NVE
-->
<!-- vs. a CE router (this only requires the NVEs to keep track if a neig
hbor -->
<!-- is an NVE for the subnet). In that case, it treats that join/prune -
->
<!-- as for itself. Correspondingly, its PIM upstream state machine will
-->
<!-- choose one of the NVEs as the RPF neighbor. Between this local NVE a
nd -->
<!-- the chosen RPF neighbor there could be multiple subnets including th
e -->
<!-- SBD but the SBD IRB interface is explicitly chosen as the RPF -->
<!-- interface. Corresponding join/prune is sent over the SBD IRB -->
<!-- interface (optionally the the join/prune could be replaced with -->
<!-- SMET routes) and the upstream NVE will route traffic through the SBD
. -->
<!-- This NVE then route traffic further downstream to CE routers. -->
<!-- </t> -->
<!-- <t>Similarly, if an NVE needs to send PIM join/prune messages due to it
s -->
<!-- local IGMP/MLD state changes, the RPF interface is always explicitly
-->
<!-- set to the SBD IRB. -->
<!-- </t> -->
<!-- <t>Note that, if CE2a chooses NVE1 or NVE2 instead of CE1a -->
<!-- as its RPF neighbor for S1, then both CE1a and NVE2 will send -->
<!-- traffic to vlan1 (NVE1 receives join from NVE2 on the SBD and sends
-->
<!-- join to CE1a on vlan1. NVE1 receives traffic from CE1a on vlan1 -->
<!-- and route to SBD. NVE2 receives traffic on SBD and route to -->
<!-- local receivers on vlan1). PIM assert procedure kicks in but only --
>
<!-- on NVE2, as CE1a does not receive traffic from NVE2. To address this
, -->
<!-- an NVE must track all the RPF neighbors and not add an IRB interface
-->
<!-- to the OIF list if it received a corresponding PIM join on the IRB,
-->
<!-- in which a tenant router is listed as the upstream neighbor. -->
<!-- That tenant router will deliver traffic to the subnet, and the traff
ic -->
<!-- will be forwarded through the core as it is not routed down the IRB
-->
<!-- but received on an AC. -->
<!-- </t> -->
<!-- <t>With PIM-ASM, if the DR on a source subnet is a tenant router, -->
<!-- it will handle the registering procedures for PIM-ASM. As a result,
-->
<!-- the NVE at same site as the tenant router/DR MUST not handle registe
ring -->
<!-- procedures as described in <xref target="solution"/>. -->
<!-- </t> -->
</section> <!-- Tenant Routers -->
<!-- </section> <!-\- Advanced Topics -\-> -->
<section anchor="IANA" title="IANA Considerations">
<t>
IANA is requested to assign new flags in the "Multicast Flags Extended
Community Flags" registry. These flags are:
<list style="symbols">
<t>
IPMG
</t>
<t>
MEG
</t>
<t>
PEG
</t>
<t>
OISM SBD
</t>
<t> <t>
OISM-supported IANA has assigned new flags in the "Multicast Flags Extended
Community" registry under the "Border Gateway Protocol (BGP) Extended Commun
ities" registry as shown below.
</t> </t>
</list>
</t>
<!-- <t>This document requests the following IANA assignments: -->
<!-- <list style="symbols"> -->
<!-- <t>A "Non-OISM" Sub-Type in -->
<!-- "EVPN Extended Community Sub-Types" registry for the -->
<!-- EVPN Non-OISM Extended Community. -->
<!-- </t> -->
<!-- <t>An "Optimized Inter-subnet Multicast" bit (OISM) in the -->
<!-- Multicast Flags extended community defined in -->
<!-- <xref target="RFC9251"/> -->
<!-- </t> -->
<!-- </list> -->
<!-- </t> -->
</section> <!-- iana -->
<section anchor="Security" title="Security Considerations"> <table align="center">
<t> <name>Multicast Flags Extended Community Registry</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Bit</th>
<th align="left" colspan="1" rowspan="1">Name</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
<th align="left" colspan="1" rowspan="1">Change Controller</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">OISM SBD</td>
<td align="left" colspan="1" rowspan="1">RFC 9625</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">IPMG</td>
<td align="left" colspan="1" rowspan="1">RFC 9625</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">10</td>
<td align="left" colspan="1" rowspan="1">MEG</td>
<td align="left" colspan="1" rowspan="1">RFC 9625</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">11</td>
<td align="left" colspan="1" rowspan="1">PEG</td>
<td align="left" colspan="1" rowspan="1">RFC 9625</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">12</td>
<td align="left" colspan="1" rowspan="1">OISM-supported</td>
<td align="left" colspan="1" rowspan="1">RFC 9625</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr>
</tbody>
</table>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
This document uses protocols and procedures defined in the normative This document uses protocols and procedures defined in the normative
references, and inherits the security considerations of those references and inherits the security considerations of those
references. references.
</t> </t>
<t> <t>
This document adds flags or Extended Communities (ECs) to a number of This document adds flags or Extended Communities (ECs) to a number of
BGP routes, in order to signal that particular nodes support the OISM, BGP routes in order to signal that particular nodes support the OISM,
IPMG, MEG, and/or PEG functionalities that are defined in this document. IPMG, MEG, and/or PEG functionalities that are defined in this document.
Incorrect addition, removal, or modification of those flags and/or ECs Incorrect addition, removal, or modification of those flags and/or ECs
will cause the procedures defined herein to malfunction, in which case will cause the procedures defined herein to malfunction, in which case
loss or diversion of data traffic is possible. Implementations should loss or diversion of data traffic is possible. Implementations should
provide tools to easily debug configuration mistakes that cause the provide tools to easily debug configuration mistakes that cause the
signaling of incorrect information. signaling of incorrect information.
</t> </t>
<t> <t>
The interworking with non-OISM networks described in sections 5 and 6, The interworking with non-OISM networks described in Sections <xref target="no-O
require gateway functions in multiple redundant PEs, among which one of ISM" format="counter"/> and <xref target="external" format="counter"/>
requires gateway functions in multiple redundant PEs, among which one of
them is elected as Designated Forwarder for a given BD (or SBD). The them is elected as Designated Forwarder for a given BD (or SBD). The
election of the MEG or PEG Designated Router, as well as the IPMG election of the MEG or PEG DR, as well as the IPMG
Designated Forwarder makes use of the RFC8584 Designated Forwarder election Designated Forwarder, makes use of the Designated Forwarder election
procedures. An attacker with access to one of these Gateways may procedures <xref target="RFC8584"/>. An attacker with access to one of these Gat
eways may
influence such election and therefore modify the forwarding of multicast traffic influence such election and therefore modify the forwarding of multicast traffic
between the OISM network and the external domain. The operator between the OISM network and the external domain. The operator
should be especially careful with the protection of these gateways by making should be especially careful with the protection of these gateways by making
sure the management interfaces to access the gateways are only allowed to sure the management interfaces to access the gateways are only allowed to
authorized operators. authorized operators.
</t> </t>
<t> <t>
The document also introduces the concept of per-Tenant-Domain dissemination The document also introduces the concept of per-Tenant-Domain dissemination
for the SMET routes, as opposed to per-BD distribution in [RFC9251]. That is, for the SMET routes, as opposed to per-BD distribution in <xref target="RFC9251"
e.g., an SMET route triggered by the reception of an IGMP/MLD join in BD-1 on PE />. That is,
1, a SMET route triggered by the reception of an IGMP/MLD Join in BD-1 on PE1
needs to be distributed and imported by all PEs of the Tenant Domain, even needs to be distributed and imported by all PEs of the Tenant Domain, even
to those PEs that are not attached to BD-1. This means that an attacker with to those PEs that are not attached to BD-1. This means that an attacker with
access to only one BD in a PE of the Tenant Domain, might force the advertisemen t of access to only one BD in a PE of the Tenant Domain might force the advertisement of
SMET routes and impact the resources of all the PEs of the Tenant Domain, as SMET routes and impact the resources of all the PEs of the Tenant Domain, as
opposed to only the PEs of that particular BD (as in RFC9251). The opposed to only the PEs of that particular BD (as in <xref target="RFC9251"/>). The
implementation should provide ways to filter/control the client IGMP/MLD implementation should provide ways to filter/control the client IGMP/MLD
reports that are received by the attached hosts. reports that are received by the attached hosts.
</t> </t>
</section> <!-- security --> </section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The authors thank Vikram Nagarajan and Princy Elizabeth for their work
on <xref target="external_pim_router"/> and <xref target="SBD-matching"/>.
The authors also benefited
tremendously from discussions with Aldrin Isaac on EVPN multicast
optimizations.
</t>
</section> <!-- acks -->
</middle> </middle>
<back>
<displayreference target="I-D.ietf-bess-evpn-pref-df" to="EVPN-DF"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.33
76.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.38
10.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.30
32.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43
60.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.66
25.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.71
53.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.74
32.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.85
84.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
135.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
136.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
251.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
572.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
574.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43
64.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.65
13.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.65
14.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.45
41.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.76
06.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77
16.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77
61.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
96.xml"/>
<back> <reference anchor="RFC9624" target="https://www.rfc-editor.org/info/rfc9
<references title="Normative References"> 624">
<front>
&RFC2119; <!-- normative keywords --> <title>EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using Bit
&RFC3376; <!-- IGMP --> Index Explicit Replication (BIER)</title>
&RFC3810; <!-- MLDv2 --> <author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zha
&RFC3032; <!-- MPLS Encaps --> ng">
&RFC4360; <!-- BGP ECs --> <organization>Juniper Networks</organization>
&RFC6625; <!-- MVPN Wildcards --> </author>
&RFC7153; <!-- BGP ECs --> <author initials="T." surname="Przygienda" fullname="Tony Przygienda"
&RFC7432; <!-- EVPN --> >
&RFC8174; <!-- normative keywords capitalized --> <organization>Juniper Networks</organization>
&RFC8584; </author>
&RFC9135; <author initials="A." surname="Sajassi" fullname="Ali Sajassi">
&RFC9136; <organization>Cisco Systems</organization>
&RFC9251; </author>
<?rfc include='reference.I-D.ietf-bess-evpn-bum-procedure-updates'?> <author initials="J." surname="Rabadan" fullname="Jorge Rabadan">
<?rfc include='reference.I-D.ietf-bess-evpn-optimized-ir'?> <organization>Nokia</organization>
</references> </author>
<date month="August" year="2024"/>
<references title="Informative References"> </front>
<seriesInfo name='RFC' value='9624'/>
<seriesInfo name='DOI' value='10.17487/RFC9624'/>
</reference>
&RFC4364; <!-- L3VPN --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bes
<!-- &RFC5015; --> <!-- BIDIR-PIM --> s-evpn-pref-df.xml"/>
&RFC6513; <!-- MVPN -->
&RFC6514; <!-- MVPN -->
&RFC4541; <!-- snooping -->
&RFC7606; <!-- BGP Error Handling -->
&RFC7716; <!-- GTM -->
&RFC7761; <!-- PIM-SM -->
&RFC8296; <!-- BIER encapsulation -->
<?rfc include='reference.I-D.ietf-bier-evpn'?> </references>
<?rfc include='reference.I-D.ietf-bess-evpn-pref-df'?>
</references> </references>
<section anchor="irb" numbered="true" toc="default">
<section title="Integrated Routing and Bridging" anchor="irb"> <name>Integrated Routing and Bridging</name>
<t> <t>
This Appendix provides a short tutorial on the interaction of This appendix provides a short tutorial on the interaction of
routing and bridging. First it shows the traditional model, where routing and bridging. First, it shows a model, where
bridging and routing are performed in separate devices. Then it shows bridging and routing are performed in separate devices. Then, it shows
the model specified in <xref target="RFC9135"/>, where a single device the model specified in <xref target="RFC9135" format="default"/>, where
a single device
contains both routing and bridging functions. The latter model is contains both routing and bridging functions. The latter model is
presupposed in the body of this document. presupposed in the body of this document.
</t> </t>
<t> <t>
<xref target="conventional_router"/> shows a "traditional" router <xref target="conventional_router" format="default"/> shows the model wh
that only does routing and has no L2 bridging capabilities. There ere a router
are two LANs, LAN1 and LAN2. LAN1 is realized by switch1, LAN2 by only does routing and has no L2 bridging capabilities. There
switch2. The router has an interface, "lan1" that attaches to LAN1 are two LANs: LAN1 and LAN2. LAN1 is realized by switch1, and LAN2 is r
(via switch1) and an interface "lan2" that attachs to LAN2 (via ealized by
switch2). Each intreface is configured, as an IP interface, with an switch2. The router has an interface, lan1, that attaches to LAN1
(via switch1) and an interface, lan2, that attaches to LAN2 (via
switch2). Each interface is configured, as an IP interface, with an
IP address and a subnet mask. IP address and a subnet mask.
<figure align="center" anchor="conventional_router" title="Conventional </t>
Router with LAN Interfaces"> <figure anchor="conventional_router">
<artwork align="center"><![CDATA[ <name>Conventional Router with LAN Interfaces</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+-------+ +--------+ +-------+ +-------+ +--------+ +-------+
| | lan1| |lan2 | | | | lan1| |lan2 | |
H1 -----+Switch1+--------+ Router1+--------+Switch2+------H3 H1 -----+Switch1+--------+ Router1+--------+Switch2+------H3
| | | | | | | | | | | |
H2 -----| | | | | | H2 -----| | | | | |
+-------+ +--------+ +-------+ +-------+ +--------+ +-------+
|_________________| |__________________| |_________________| |__________________|
LAN1 LAN2 LAN1 LAN2
]]></artwork> ]]></artwork>
</figure> </figure>
</t>
<t> <t>
IP traffic (unicast or multicast) that remains within a single IP traffic (unicast or multicast) that remains within a single
subnet never reaches the router. For instance, if H1 emits an subnet never reaches the router. For instance, if H1 emits an
Ethernet frame with H2's MAC address in the Ethernet destination Ethernet frame with H2's MAC address in the Ethernet Destination
address field, the frame will go from H1 to Switch1 to H2, without Address field, the frame will go from H1 to Switch1 to H2 without
ever reaching the router. Since the frame is never seen by a ever reaching the router. Since the frame is never seen by a
router, the IP datagram within the frame remains entirely unchanged, router, the IP datagram within the frame remains entirely unchanged,
e.g., its TTL is not decremented. The Ethernet Source and e.g., its TTL is not decremented. The Ethernet Source and
Destination MAC addresses are not changed either. Destination MAC addresses are not changed either.
</t> </t>
<t> <t>
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 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 determines 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 be routed. H1 uses ARP to map Router1's IP address to a MAC address
on LAN1. H1 then encapsulates the datagram in an Ethernet frame, on LAN1. H1 then encapsulates the datagram in an Ethernet frame,
using router1's MAC address as the destination MAC address, and using Router1's MAC address as the destination MAC address, and
sends the frame to Router1. sends the frame to Router1.
</t> </t>
<t> <t>
Router1 then receives the frame over its lan1 interface. Router1 Router1 then receives the frame over its lan1 interface. Router1
sees that the frame is addressed to it, so it removes the Ethernet sees that the frame is addressed to it, so it removes the Ethernet
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 Address field and determines t
hat
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 Router1 now performs the IP processing of the datagram: it
decrements the IP TTL, adjusts the IP header checksum (if present), decrements the IP TTL, adjusts the IP header checksum (if present),
may fragment the packet is necessary, etc. Then the datagram (or may fragment the packet as necessary, etc. Then, the datagram (or
its fragments) are encapsulated in an Ethernet header, with its fragments) is encapsulated in an Ethernet header, with
Router1's MAC address on LAN2 as the MAC Source Address, and H3's Router1's MAC address on LAN2 as the MAC Source Address and H3's
MAC address on LAN2 (which Router1 determines via ARP) as the MAC MAC address on LAN2 (which Router1 determines via ARP) as the
Destination Address. Finally the packet is sent on the lan2 Destination MAC Address. Finally, the packet is sent on the lan2
interface. interface.
</t> </t>
<t> <t>
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 encapsulates it in an Ethernet frame whose Destination MAC Address
is computed from the IP Destination Address. is computed from the IP Destination Address.
</t> </t>
<t> <t>
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 copy of the frame, unchanged, from H1. The MAC Source Address in
the Ethernet encapsulation does not change, the IP TTL field does the Ethernet encapsulation does not change, the IP TTL field does
not get decremented, etc. not get decremented, etc.
</t> </t>
<t> <t>
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, remove the Ethernet encapsulation,
and will determine how to dispatch the IP datagram based on and determine how to dispatch the IP datagram based on
Router1's multicast forwarding states. If Router1 knows that there Router1's multicast forwarding states. If Router1 knows that there
is a receiver for the multicast datagram on LAN2, it makes a copy of is a receiver for the multicast datagram on LAN2, it makes a copy of
the datagram, decrements the TTL (and performs any other necessary the datagram, decrements the TTL (and performs any other necessary
IP processing), then encapsulates the datagram in Ethernet frame for IP processing), and then encapsulates the datagram in the 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 Source Address on LAN2. The Destination MAC Address is computed
from the IP Destination Address. Finally, the frame is sent on from the IP Destination Address. Finally, the frame is sent on
Router1's LAN2 interface. Router1's LAN2 interface.
</t> </t>
<t> <t>
<xref target="IRB"/> shows an Integrated Router/Bridge that supports <xref target="IRB" format="default"/> shows an integrated router/bridge
the routing/bridging integration model of <xref target="RFC9135"/>. that supports
<figure align="center" anchor="IRB" title="Integrated Router/Bridge"> the routing/bridging integration model of <xref target="RFC9135" format=
<artwork align="center"><![CDATA[ "default"/>.
</t>
<figure anchor="IRB">
<name>Integrated Router/Bridge</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+------------------------------------------+ +------------------------------------------+
| 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
]]> </artwork> ]]></artwork>
</figure> </figure>
</t>
<t> <t>
In <xref target="IRB"/>, a single device consists of one or more "L3 In <xref target="IRB" format="default"/>, a single device consists of on
Routing Instances". The routing/forwarding tables of a given e or more L3
routing instance is known as an IP-VRF <xref target="RFC9135"/>. Routing Instances. The routing/forwarding tables of a given
routing instance is known as an IP-VRF <xref target="RFC9135" format="de
fault"/>.
In the context of EVPN, it is convenient to think of each routing In the context of EVPN, it is convenient to think of each routing
instance as representing the routing of a particular tenant. Each instance as representing the routing of a particular tenant. Each
IP-VRF is attached to one or more interfaces. IP-VRF is attached to one or more interfaces.
</t> </t>
<t> <t>
When several EVPN PEs have a routing instance of the same tenant When several EVPN PEs have a routing instance of the same Tenant
domain, those PEs advertise IP routes to the attached hosts. This Domain, those PEs advertise IP routes to the attached hosts. This
is done as specified in <xref target="RFC9135"/>. is done as specified in <xref target="RFC9135" format="default"/>.
</t> </t>
<t> <t>
The integrated router/bridge shown in <xref target="IRB"/> also The integrated router/bridge shown in <xref target="IRB" format="default
attaches to a number of "Broadcast Domains" (BDs). Each BD performs "/> also
the functions that are performed by the bridges in <xref attaches to a number of Broadcast Domains (BDs). Each BD performs
target="conventional_router"/>. To the L3 routing instance, each BD the functions that are performed by the bridges in <xref target="convent
ional_router" format="default"/>. To the L3 routing instance, each BD
appears to be a LAN. The interface attaching a particular BD to a appears to be a LAN. The interface attaching a particular BD to a
particular IP-VRF is known as an "IRB Interface". From the particular IP-VRF is known as an "IRB interface". From the
perspective of L3 routing, each BD is a subnet. Thus each IRB perspective of L3 routing, each BD is a subnet. Thus, each IRB
interface is configured with a MAC address (which is the router's interface is configured with a MAC address (which is the router's
MAC address on the corresponding LAN), as well as an IP address and MAC address on the corresponding LAN), as well as an IP address and
subnet mask. subnet mask.
</t> </t>
<t> <t>
The integrated router/bridge shown in <xref target="IRB"/> may have The integrated router/bridge shown in <xref target="IRB" format="default "/> may have
multiple ACs to each BD. These ACs are visible only to the bridging multiple ACs to each BD. These ACs are visible only to the bridging
function, not to the routing instance. To the L3 routing instance, function, not to the routing instance. To the L3 routing instance,
there is just one "interface" to each BD. there is just one interface to each BD.
</t> </t>
<t> <t>
If the L3 routing instance represents the IP routing of a particular If the L3 routing instance represents the IP routing of a particular
tenant, the BDs attached to that routing instance are BDs belonging tenant, the BDs attached to that routing instance are BDs belonging
to that same tenant. to that same tenant.
</t> </t>
<t> <t>
Bridging and routing now proceed exactly as in the case of <xref Bridging and routing now proceed exactly as in the case of <xref target=
target="conventional_router"/>, except that BD1 replaces Switch1, "conventional_router" format="default"/>, except that BD1 replaces Switch1,
BD2 replaces Switch2, interface IRB1 replaces interface lan1, and BD2 replaces Switch2, interface IRB1 replaces interface lan1, and
interface IRB2 replaces interface lan2. interface IRB2 replaces interface lan2.
</t> </t>
<t> <t>
It is important to understand that an IRB interface connects an L3 It is important to understand that an IRB interface connects an L3
routing instance to a BD, NOT to a "MAC&nbhy;VRF". (See <xref routing instance to a BD, NOT to a MAC-VRF (see <xref target="RFC7432" f
target="RFC7432"/> for the definition of "MAC&nbhy;VRF".) A ormat="default"/> for the definition of MAC-VRF). A
MAC&nbhy;VRF may contain several BDs, as long as no MAC address MAC-VRF may contain several BDs, as long as no MAC address
appears in more than one BD. From the perspective of the L3 routing appears in more than one BD. From the perspective of the L3 routing
instance, each individual BD is an individual IP subnet; whether instance, each individual BD is an individual IP subnet; whether or not
each BD has its own MAC&nbhy;VRF or not is irrelevant to the L3 each BD has its own MAC-VRF is irrelevant to the L3
routing instance. routing instance.
</t> </t>
<t> <t>
<xref target="two_router_irb"/> illustrates IRB when a pair of BDs <xref target="two_router_irb" format="default"/> illustrates IRB when a pair of BDs
(subnets) are attached to two different PE routers. In this (subnets) are attached to two different PE routers. In this
example, each BD has two segments, and one segment of each BD is example, each BD has two segments, and one segment of each BD is
attached to one PE router. attached to one PE router.
<figure align="center" anchor="two_router_irb" </t>
title="Integrated Router/Bridges with Distributed Subnet"> <figure anchor="two_router_irb">
<artwork align="center"><![CDATA[ <name>Integrated Router/Bridges with Distributed Subnet</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+------------------------------------------+ +------------------------------------------+
| Integrated Router/Bridges | | Integrated Router/Bridges |
+-------+ +--------+ +-------+ +-------+ +--------+ +-------+
| | IRB1| |IRB2 | | | | IRB1| |IRB2 | |
H1 -----+ BD1 +--------+ PE1 +--------+ BD2 +------H3 H1 -----+ BD1 +--------+ PE1 +--------+ BD2 +------H3
|(Seg-1)| |(L3 Rtg)| |(Seg-1)| |(Seg-1)| |(L3 Rtg)| |(Seg-1)|
H2 -----| | | | | | H2 -----| | | | | |
+-------+ +--------+ +-------+ +-------+ +--------+ +-------+
|___________________| | |____________________| |___________________| | |____________________|
LAN1 | LAN2 LAN1 | LAN2
| |
| |
+-------+ +--------+ +-------+ +-------+ +--------+ +-------+
| | IRB1| |IRB2 | | | | IRB1| |IRB2 | |
H4 -----+ BD1 +--------+ PE2 +--------+ BD2 +------H5 H4 -----+ BD1 +--------+ PE2 +--------+ BD2 +------H5
|(Seg-2)| |(L3 Rtg)| |(Seg-2)| |(Seg-2)| |(L3 Rtg)| |(Seg-2)|
| | | | | | | | | | | |
+-------+ +--------+ +-------+ +-------+ +--------+ +-------+
]]> </artwork> ]]></artwork>
</figure> </figure>
</t>
<t> <t>
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 BD. Thus, H1 uses ARP to find H4's MAC address and sends an
Ethernet frame with H4's MAC address in the Destination MAC address Ethernet frame with H4's MAC address in the Destination MAC Address
field. The frame is received at PE1, but since the Destination MAC field. 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 address is not PE1's MAC address, PE1 assumes that the frame is to
remain on BD1. Therefore the packet inside the frame is NOT remain on BD1. Therefore, the packet inside the frame is NOT
decapsulated, and is NOT send up the IRB interface to PE1's routing decapsulated and is NOT sent up the IRB interface to PE1's routing
instance. Rather, standard EVPN intra&nbhy;subnet procedures (as instance. Rather, standard EVPN intra-subnet procedures (as
detailed in <xref target="RFC7432"/>) are used to deliver the frame detailed in <xref target="RFC7432" format="default"/>) are used to deliv
er the frame
to PE2, which then sends it to H4. to PE2, which then sends it to H4.
</t> </t>
<t> <t>
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 PE1's MAC address in its Destination MAC Address field. PE1
receives the frame, and sees that the frame is addressed to it. PE1 receives the frame and sees that the frame is addressed to it. Thus, PE1
thus sends the frame up its IRB1 interface to the L3 routing sends the frame up its IRB1 interface to the L3 routing
instance. Appropriate IP processing is done, e.g., TTL decrement. instance. Appropriate IP processing is done, e.g., TTL decrement.
The L3 routing instance determines that the "next hop" for H5 is The L3 routing instance determines that the next hop for H5 is
PE2, so the packet is encapsulated (e.g., in MPLS) and sent across PE2, so the packet is encapsulated (e.g., in MPLS) and sent across
the backbone to PE2's routing instance. PE2 will see that the the backbone to PE2's routing instance. PE2 will see that the
packet's destination, H5, is on BD2 segment-2, and will send the packet's destination, H5, is on BD2 segment-2 and will send the
packet down its IRB2 interface. This causes the IP packet to be packet down its IRB2 interface. This causes the IP packet to be
encapsulated in an Ethernet frame with PE2's MAC address (on BD2) in encapsulated in an Ethernet frame with PE2's MAC address (on BD2) in
the Source Address field and H5's MAC address in the Destination the Source Address field and H5's MAC address in the Destination
Address field. Address field.
</t> </t>
<t> <t>
Note that if H1 has an IP packet to send to H3, the forwarding of 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 the packet is handled entirely within PE1. PE1's routing instance
sees the packet arrive on its IRB1 interface, and then transmits the sees the packet arrive on its IRB1 interface and then transmits the
packet by sending it down its IRB2 interface. packet by sending it down its IRB2 interface.
</t> </t>
<t> <t>
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 provisioned as an "anycast address" in 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 EVPN PEs attached to that Tenant Domain. Thus, although all hosts
are provisioned with the same "default router address", the actual are provisioned with the same default router address, the actual
default router for a given host will be one of the PEs default router for a given host will be one of the PEs
attached to the same Ethernet segment as the host. This attached to the same Ethernet segment as the host. This
provisioning method ensures that IP packets from a given host are provisioning method ensures that IP packets from a given host are
handled by the closest EVPN PE that supports IRB. handled by the closest EVPN PE that supports IRB.
</t> </t>
<t> <t>
In the topology of <xref target="two_router_irb"/>, one could In the topology of <xref target="two_router_irb" format="default"/>, one could
imagine that H1 is configured with a default router address that imagine that H1 is configured with a default router address that
belongs to PE2 but not to PE1. Inter-subnet routing would still belongs to PE2 but not to PE1. Inter-subnet routing would still
work, but IP packets from H1 to H3 would then follow the non-optimal work, but IP packets from H1 to H3 would then follow the non-optimal
path H1-->PE1-->PE2-->PE1-->H3. Sending traffic on this sort of path H1-->PE1--&gt;PE2--&gt;PE1--&gt;H3. Sending traffic on this sort of
path, where it leaves a router and then comes back to the same path, where it leaves a router and then comes back to the same
router, is sometimes known as "hairpinning". Similarly, if PE2 router, is sometimes known as "hairpinning". Similarly, if PE2
supports IRB but PE1 dos not, the same non-optimal path from H1 to supports IRB but PE1 dos not, the same non-optimal path from H1 to
H3 would have to be followed. To avoid hairpinning, each EVPN PE H3 would have to be followed. To avoid hairpinning, each EVPN PE
needs to support IRB. needs to support IRB.
</t> </t>
<t> <t>
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 <xref multicast traffic. Referring again to <xref target="two_router_irb" for
target="two_router_irb"/>, suppose PE1 and PE2 are functioning as IP mat="default"/>, suppose PE1 and PE2 are functioning as IP
multicast routers. Also Suppose that H3 transmits a multicast packet, multicast routers. Also, suppose that H3 transmits a multicast packet
and both H1 and H4 are interested in receiving that packet. PE1 and both H1 and H4 are interested in receiving that packet. PE1
will receive the packet from H3 via its IRB2 interface. The will receive the packet from H3 via its IRB2 interface. The
Ethernet encapsulation from BD2 is removed, the IP header processing Ethernet encapsulation from BD2 is removed, the IP header processing
is done, and the packet is then reencapsulated for BD1, with PE1's is done, and the packet is then re-encapsulated for BD1, with PE1's
MAC address in the MAC Source Address field. Then the packet is MAC address in the MAC Source Address field. Then, the packet is
sent down the IRB1 interface. Layer 2 procedures (as defined in sent down the IRB1 interface. Layer 2 procedures (as defined in
<xref target="RFC7432"/> would then be used to deliver a copy of the <xref target="RFC7432" format="default"/>) would then be used to deliver
packet locally to H1, and remotely to H4. a copy of the
packet locally to H1 and remotely to H4.
</t> </t>
<t> <t>
Please be aware that his document modifies the semantics, described Please be aware that this 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 <xref target="cp_overview"/> an IRB interface. This is explained in <xref target="cp_overview" forma t="default"/>
and subsequent sections. and subsequent sections.
</t> </t>
</section> </section>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
The authors thank <contact fullname="Vikram Nagarajan"/> and <contact fullna
me="Princy Elizabeth"/> for their work
on Sections <xref target="external_pim_router" format="counter"/> and <xref
target="SBD-matching" format="counter"/>.
The authors also benefited
tremendously from discussions with <contact fullname="Aldrin Isaac"/> on EVP
N multicast
optimizations.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 843 change blocks. 
3845 lines changed or deleted 3238 lines changed or added

This html diff was produced by rfcdiff 1.48.