rfc9856xml2.original.xml   rfc9856.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7432.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 RFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8584.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC9573 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9573.xml">
<!ENTITY RFC9625 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9625.xml">
<!ENTITY I-D.ietf-mpls-p2mp-bfd SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibx
ml3/reference.I-D.ietf-mpls-p2mp-bfd.xml">
<!ENTITY I-D.ietf-bess-evpn-bfd SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibx
ml3/reference.I-D.ietf-bess-evpn-bfd.xml">
<!ENTITY I-D.ietf-bess-evpn-mh-split-horizon SYSTEM "https://xml2rfc.ietf.org/pu
blic/rfc/bibxml3/reference.I-D.ietf-bess-evpn-mh-split-horizon.xml">
<!ENTITY RFC9572 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9572.xml">
<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4364.xml">
<!ENTITY RFC9251 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9251.xml">
<!ENTITY RFC9136 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9136.xml">
<!ENTITY RFC7761 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7761.xml">
<!ENTITY RFC9135 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9135.xml">
<!ENTITY I-D.ietf-bess-evpn-pref-df SYSTEM "https://xml2rfc.ietf.org/public/rfc/
bibxml3/reference.I-D.ietf-bess-evpn-pref-df.xml">
<!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 RFC8296 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8296.xml">
<!ENTITY RFC9574 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9574.xml">
]>
<rfc category="std" docName="draft-ietf-bess-evpn-redundant-mcast-source-15"
ipr="trust200902" submissionType="IETF">
<!-- Generated by id2xml 1.5.0 on 2020-10-30T09:57:27Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="o*+?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-bess-evpn-redundant-mcast-source-15" number="9856" ipr="trus t200902" submissionType="IETF" obsoletes="" updates="" xml:lang="en" symRefs="tr ue" sortRefs="true" tocInclude="true" version="3">
<front> <front>
<title abbrev="EVPN Redundant Sources">Multicast Source Redundancy in EVPN <title abbrev="EVPN Redundant Sources">Multicast Source Redundancy in EVPNs<
Networks</title> /title>
<seriesInfo name="RFC" value="9856"/>
<author fullname="Jorge Rabadan" initials="J." role="editor" <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabada
surname="Rabadan"> n">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>520 Almanor Avenue</street> <street>520 Almanor Avenue</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94085</code> <code>94085</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Jayant Kotalwar" initials="J." surname="Kotalwar"> <author fullname="Jayant Kotalwar" initials="J." surname="Kotalwar">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>520 Almanor Avenue</street> <street>520 Almanor Avenue</street>
<city>Sunnyvale</city>
<street>Sunnyvale, CA 94085 USA</street> <region>CA</region>
<code>94085</code>
<country>United States of America</country>
</postal> </postal>
<email>jayant.kotalwar@nokia.com</email> <email>jayant.kotalwar@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Senthil Sathappan" initials="S." surname="Sathappan"> <author fullname="Senthil Sathappan" initials="S." surname="Sathappan">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>520 Almanor Avenue</street> <street>520 Almanor Avenue</street>
<city>Sunnyvale</city>
<street>Sunnyvale, CA 94085 USA</street> <region>CA</region>
<code>94085</code>
<country>United States of America</country>
</postal> </postal>
<email>senthil.sathappan@nokia.com</email> <email>senthil.sathappan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
<organization abbrev="Juniper">Juniper Networks</organization> <organization abbrev="Juniper">Juniper Networks</organization>
<address> <address>
<email>zzhang@juniper.net</email> <email>zzhang@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Wen Lin" initials="W." surname="Lin"> <author fullname="Wen Lin" initials="W." surname="Lin">
<organization abbrev="Juniper">Juniper Networks</organization> <organization abbrev="Juniper">Juniper Networks</organization>
<address> <address>
<email>wlin@juniper.net</email> <email>wlin@juniper.net</email>
</address> </address>
</author> </author>
<date month="September" year="2025"/>
<area>RTG</area>
<workgroup>bess</workgroup>
<date day="14" month="February" year="2025"/> <keyword>Warm standby</keyword>
<keyword>hot standby</keyword>
<workgroup>BESS Workgroup</workgroup> <keyword>OISM</keyword>
<keyword>redundant G-source</keyword>
<keyword>SFG</keyword>
<keyword>Single Flow Group</keyword>
<abstract> <abstract>
<t>In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic <t>In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic
replication and delivery play a crucial role in enabling efficient and replication and delivery play a crucial role in enabling efficient and
scalable layer-2 and layer-3 services. A common deployment scenario scalable Layer 2 and Layer 3 services. A common deployment scenario
involves redundant multicast sources that ensure high availability and involves redundant multicast sources that ensure high availability and
resiliency. However, the presence of redundant sources can lead to resiliency. However, the presence of redundant sources can lead to
duplicate IP multicast traffic in the network, causing inefficiencies duplicate IP multicast traffic in the network, causing inefficiencies
and increased overhead. This document specifies extensions to the EVPN and increased overhead. This document specifies extensions to the EVPN
multicast procedures that allow for the suppression of duplicate IP multicast procedures that allow for the suppression of duplicate IP
multicast traffic from redundant sources. The proposed mechanisms multicast traffic from redundant sources. The proposed mechanisms
enhance EVPN's capability to deliver multicast traffic efficiently while enhance the EVPN's capability to deliver multicast traffic efficiently whi le
maintaining high availability. These extensions are applicable to maintaining high availability. These extensions are applicable to
various EVPN deployment scenarios and provide guidelines to ensure various EVPN deployment scenarios and provide guidelines to ensure
consistent and predictable behavior across diverse network consistent and predictable behavior across diverse network
topologies.</t> topologies.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" title="Introduction"> <section anchor="sect-1" numbered="true" toc="default">
<t>Ethernet Virtual Private Networks (EVPN) <xref target="RFC7432"/> <name>Introduction</name>
<t>Ethernet Virtual Private Networks (EVPNs) <xref target="RFC7432" format
="default"/>
support both intra-subnet and inter-subnet IP multicast forwarding. support both intra-subnet and inter-subnet IP multicast forwarding.
<xref target="RFC9251"/> outlines the procedures required to optimize <xref target="RFC9251" format="default"/> outlines the procedures required to optimize
the delivery of IP multicast flows when both sources and receivers are the delivery of IP multicast flows when both sources and receivers are
connected to the same EVPN Broadcast Domain. <xref target="RFC9625"/>, connected to the same EVPN Broadcast Domain. <xref target="RFC9625" format ="default"/>,
on the other hand, defines the procedures for supporting inter-subnet IP on the other hand, defines the procedures for supporting inter-subnet IP
multicast within a tenant network, where the IP multicast source and multicast within a tenant network, where the IP multicast source and
receivers of the same multicast flow are connected to different receivers of the same multicast flow are connected to different
Broadcast Domains within the same tenant.</t> Broadcast Domains within the same tenant.</t>
<t>However, <xref target="RFC9251" format="default"/>, <xref target="RFC96
<t>However, <xref target="RFC9251"/>, <xref target="RFC9625"/>, and 25" format="default"/>, and
conventional IP multicast techniques do not provide a solution for conventional IP multicast techniques do not provide a solution for
scenarios where: <list style="numbers"> scenarios where: </t>
<ol spacing="normal" type="1"><li>
<t>A given multicast group carries multiple flows (i.e., multiple <t>A given multicast group carries multiple flows (i.e., multiple
sources are active), and</t> sources are active), and</t>
</li>
<li>
<t>Each receiver should receive only from one source.</t> <t>Each receiver should receive only from one source.</t>
</list></t> </li>
</ol>
<t>Existing multicast solutions typically assume that there are no <t>Existing multicast solutions typically assume that there are no
redundant sources sending identical flows to the same IP multicast redundant sources sending identical flows to the same IP multicast
group. In cases where redundant sources do exist, the receiver group. In cases where redundant sources do exist, the receiver
application is expected to handle duplicate packets.</t> application is expected to handle duplicate packets.</t>
<t>In conventional IP multicast networks, such as those running Protocol <t>In conventional IP multicast networks, such as those running Protocol
Independent Multicast (PIM) <xref target="RFC7761"/> or Multicast VPNs Independent Multicast (PIM) <xref target="RFC7761" format="default"/> or M
(MVPN) <xref target="RFC6513"/>, a workaround is to configure all ulticast Virtual Private Network
(MVPN) <xref target="RFC6513" format="default"/>, a workaround is to confi
gure all
redundant sources with the same IP address. This approach ensures that redundant sources with the same IP address. This approach ensures that
each receiver gets only one flow because: <list style="symbols"> each receiver gets only one flow because: </t>
<t>The RP (Rendezvous Point) in the multicast network always creates <ul spacing="normal">
(S,G) state for each source.</t> <li>
<t>The Rendezvous Point (RP) in the multicast network always creates
<t>The Last Hop Router (LHR) may also create (S,G) state.</t> the (S,G) state for each source.</t>
</li>
<li>
<t>The Last Hop Router (LHR) may also create the (S,G) state.</t>
</li>
<li>
<t>The (S,G) state binds the flow to a source-specific tree rooted <t>The (S,G) state binds the flow to a source-specific tree rooted
at the source IP address. When multiple sources share the same IP at the source IP address. When multiple sources share the same IP
address, the resulting source-specific trees ensure that each LHR or address, the resulting source-specific trees ensure that each LHR or
RP resides on at most one tree.</t> RP resides on at most one tree.</t>
</list></t> </li>
</ul>
<t>This workaround, which often uses anycast addresses, is suitable for <t>This workaround, which often uses anycast addresses, is suitable for
warm standby redundancy solutions (<xref target="sect-4"/>). However, it Warm Standby (WS) redundancy solutions (<xref target="sect-4" format="defa
is not effective for hot standby redundancy scenarios (<xref ult"/>). However, it
target="sect-5"/>) and introduces challenges when sources need to be is not effective for Hot Standby (HS) redundancy scenarios (<xref target="
sect-5" format="default"/>), and it introduces challenges when sources need to b
e
reachable via IP unicast or when multiple sources with the same IP reachable via IP unicast or when multiple sources with the same IP
address are attached to the same Broadcast Domain. In scenarios where address are attached to the same Broadcast Domain. In scenarios where
multiple multicast sources stream traffic to the same group using EVPN multiple multicast sources stream traffic to the same group using EVPN
Optimized Inter-Subnet Multicast (OISM), there is not necessarily any Optimized Inter-Subnet Multicast (OISM), there is not necessarily any
(S,G) state created for the redundant sources. In such cases, the Last (S,G) state created for the redundant sources. In such cases, the Last Hop
Hop Routers may only have (*,G) state, and there may not be a Rendezvous Routers may only have a (*,G) state, and there may not be an RP router to creat
Point router to create (S,G) state.</t> e an (S,G) state.</t>
<t>This document extends <xref target="RFC9251" format="default"/> and <xr
<t>This document extends <xref target="RFC9251"/> and <xref ef target="RFC9625" format="default"/> to address scenarios where IP multicast s
target="RFC9625"/> to address scenarios where IP multicast source ource
redundancy exists. Specifically, it defines procedures for EVPN PEs redundancy exists. Specifically, it defines procedures for EVPN Provider E
(Provider Edge devices/routers) to ensure that receivers do not dge (PE)
devices/routers to ensure that receivers do not
experience packet duplication when two or more sources send identical IP experience packet duplication when two or more sources send identical IP
multicast flows into the tenant domain. These procedures are limited to multicast flows into the tenant domain. These procedures are limited to
the context of <xref target="RFC9251"/> and <xref target="RFC9625"/>; the context of <xref target="RFC9251" format="default"/> and <xref target= "RFC9625" format="default"/>;
handling redundant sources in other multicast solutions is beyond the handling redundant sources in other multicast solutions is beyond the
scope of this document.</t> scope of this document.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</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 anchor="sect-1.1" title="Terminology"> <dl spacing="normal" newline="false">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <dt>BD:</dt><dd>Broadcast Domain. An emulated Ethernet, such that two
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and systems on the same BD will receive each other's link-local
"OPTIONAL" in this document are to be interpreted as described in BCP broadcasts. In this document, "BD" also refers to the instantiation of
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only a Broadcast Domain on an EVPN PE. An EVPN PE can be attached to one
when, they appear in all capitals, as shown here.</t> or multiple BDs of the same tenant.</dd>
<dt>BUM:</dt><dd>Broadcast, Unknown Unicast, and Multicast traffic.</d
<t><list style="symbols"> d>
<t>Broadcast Domain (BD): an emulated Ethernet, such that two <dt>DF:</dt><dd>Designated Forwarder. As defined in <xref
systems on the same BD will receive each other's link-local target="RFC7432" format="default"/>, an Ethernet Segment (ES) may be
broadcasts. In this document, BD also refers to the instantiation multi-homed (attached to more than one PE). An ES may
of a Broadcast Domain on an EVPN PE. An EVPN PE can be attached to also contain multiple BDs of one or more EVIs. For each such EVI,
one or multiple BDs of the same tenant.</t> 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 speak
<t>BUM: Broadcast, Unknown unicast, and Multicast traffic.</t> unambiguously of the BD's DF for a given segment.</dd>
<dt>Downstream PE:</dt><dd>In this document, a downstream PE is
<t>Designated Forwarder (DF): as defined in <xref referred to as the EVPN PE that is connected to the IP Multicast
target="RFC7432"/>, an Ethernet Segment may be multi-homed receivers and gets the IP Multicast flows from remote EVPN PEs.</dd>
(attached to more than one PE). An Ethernet Segment may also <dt>EVI:</dt><dd>EVPN Instance.</dd>
contain multiple BDs, of one or more EVIs. For each such EVI, one <dt>G-traffic:</dt><dd>Any frame with an IP payload whose destination
of the PEs attached to the segment becomes that EVI's DF for that IP
segment. Since a BD may belong to only one EVI, we can speak address is a multicast group G.</dd>
unambiguously of the BD's DF for a given segment.</t> <dt>G-source:</dt><dd>Any system sourcing IP multicast traffic to
group G.</dd>
<t>Downstream PE: in this document a Downstream PE is referred to <dt>Hot Standby Redundancy:</dt><dd>The multicast source redundancy
as the EVPN PE that is connected to the IP Multicast receivers and procedure defined in this document, by which the upstream PEs
gets the IP Multicast flows from remote EVPN PEs.</t> forward the redundant multicast flows to the downstream PEs, and the
downstream PEs make sure only one flow is forwarded to the
<t>EVI: EVPN Instance.</t> interested attached receivers.</dd>
<dt>IGMP:</dt><dd>Internet Group Management Protocol <xref
<t>G-traffic: any frame with an IP payload whose IP Destination target="RFC9776" format="default"/>.</dd>
Address (IP DA) is a multicast group G.</t> <dt>I-PMSI:</dt><dd>Inclusive Multicast Tree or Inclusive Provider Mul
ticast Service Interface. While defined in <xref target="RFC6513"
<t>G-source: any system sourcing IP multicast traffic to group format="default"/>, in this document it is only applicable to EVPN
G.</t> and refers to the default multicast tree for a given BD. All the
EVPN PEs that are attached to a specific BD belong to the I-PMSI for
<t>Hot Standby Redundancy: multicast source redundancy procedure the BD. The I-PMSI trees are signaled by EVPN Inclusive Multicast
defined in this document, by which the upstream PEs forward the Ethernet Tag (IMET) routes.</dd>
redundant multicast flows to the downstream PEs, and the <dt>IMET route:</dt><dd>EVPN Inclusive Multicast Ethernet Tag route,
downstream PEs make sure only one flow is forwarded to the as in <xref target="RFC7432" format="default"/>.</dd>
interested attached receivers.</t> <dt>MLD:</dt><dd>Multicast Listener Discovery <xref target="RFC9777"
format="default"/>.</dd>
<t>IGMP: Internet Group Management Protocol <xref <dt>MVPN:</dt><dd>Multicast Virtual Private Networks, as in <xref
target="RFC3376"/>.</t> target="RFC6513" format="default"/>.</dd>
<dt>OISM:</dt><dd>Optimized Inter-Subnet Multicast, as in <xref
<t>Inclusive Multicast Tree or Inclusive Provider Multicast target="RFC9625" format="default"/>.</dd>
Service Interface (I-PMSI): defined in <xref target="RFC6513"/>, <dt>PE:</dt><dd>Provider Edge.</dd>
in this document it is applicable only to EVPN and refers to the <dt>PIM:</dt><dd>Protocol Independent Multicast, as in <xref
default multicast tree for a given BD. All the EVPN PEs that are target="RFC7761" format="default"/>.</dd>
attached to a specific BD belong to the I-PMSI for the BD. The <dt>P-tunnel:</dt><dd>The term "Provider tunnel" refers to the type
I-PMSI trees are signaled by EVPN Inclusive Multicast Ethernet Tag of tree employed by an upstream EVPN PE to forward multicast traffic
(IMET) routes.</t> to downstream PEs. The P-tunnels supported in this document include
Ingress Replication (IR), Assisted Replication (AR) <xref
<t>IMET route: EVPN Inclusive Multicast Ethernet Tag route, as in target="RFC9574" format="default"/>, Bit Indexed Explicit
<xref target="RFC7432"/>.</t> Replication (BIER) <xref target="RFC8296" format="default"/>,
multicast Label Distribution Protocol (mLDP), and
<t>MLD: Multicast Listener Discovery <xref target="RFC3810"/>.</t> Point-to-Multipoint (P2MP) RSVP - Traffic Engineering (RSVP-TE)
extensions.</dd>
<t>MVPN: Multicast Virtual Private Networks, as in <xref <dt>Redundant G-source:</dt><dd>A host or router transmitting a
target="RFC6513"/>.</t> Single Flow Group (SFG) within a tenant network, where multiple
hosts or routers are also transmitting the same SFG. Redundant
<t>OISM: Optimized Inter-Subnet Multicast, as in <xref G-sources transmitting the same SFG should have distinct IP
target="RFC9625"/>.</t> addresses; however, they may share the same IP address if located in
different Broadcast Domains (BDs) within the same tenant network.
<t>PE: Provider Edge.</t> For the purposes of this document, redundant G-sources are assumed
to not exhibit "bursty" traffic behavior.</dd>
<t>PIM: Protocol Independent Multicast, as in <xref <dt>S-ES and S-ESI:</dt><dd>Multicast Source Ethernet Segment and
target="RFC7761"/>.</t> multicast Source Ethernet Segment Identifier. The ES
and ESI associated to a G-source.</dd>
<t>P-tunnel: The term "Provider tunnel" refers to the type of tree <dt>S-PMSI:</dt><dd><t>Selective Multicast Tree or Selective Provider
employed by an upstream EVPN PE to forward multicast traffic to Multicast Service Interface. As defined in <xref target="RFC6513"
downstream PEs. The P-tunnels supported in this document include format="default"/>, this term refers to a multicast tree to which
Ingress Replication (IR), Assisted Replication (AR) <xref only the PEs interested in a specific Broadcast Domain
target="RFC9574"/>, Bit Indexed Explicit Replication (BIER) <xref belong. In the context of this document, it is specific to EVPN.
target="RFC8296"/>, multicast Label Distribution Protocol (mLDP), Two types of EVPN S-PMSIs are supported:</t>
and Point-to-Multi-Point Resource Reservation Protocol with <dl spacing="normal" newline="false">
Traffic Engineering extensions (P2MP RSVP-TE).</t> <dt>S-PMSIs with Auto-Discovery routes:</dt><dd>These S-PMSIs
require the upstream PE to advertise S-PMSI Auto-Discovery
<t>Redundant G-source: A host or router transmitting a Single Flow (S-PMSI A-D) routes, as described in <xref target="RFC9572"
Group (SFG) within a tenant network, where multiple hosts or format="default"/>. Downstream PEs interested in the multicast
routers are also transmitting the same SFG. Redundant G-sources traffic join the S-PMSI tree following the procedures specified
transmitting the same SFG should have distinct IP addresses; in <xref target="RFC9572" format="default"/>.</dd>
however, they may share the same IP address if located in <dt>S-PMSIs without Auto-Discovery Routes:</dt><dd>These S-PMSIs
different Broadcast Domains (BDs) within the same tenant network. do not require the advertisement of S-PMSI A-D routes. Instead,
For the purposes of this document, redundant G-sources are assumed they rely on the forwarding information provided by
not to exhibit "bursty" traffic behavior.</t> IMET routes. Upstream PEs forward IP
multicast flows only to downstream PEs that advertise
<t>S-ES and S-ESI: multicast Source Ethernet Segment and multicast Selective Multicast Ethernet Tag (SMET) routes for the specific
Source Ethernet Segment Identifier. The Ethernet Segment and flow. These S-PMSIs are supported exclusively with the following
Ethernet Segment Identifier associated to a G-source.</t> P-tunnel types: IR, AR, and BIER.</dd>
</dl>
<t>Selective Multicast Tree or Selective Provider Multicast </dd>
Service Interface (S-PMSI): As defined in <xref <dt>SFG:</dt><dd><t>Single Flow Group. A multicast group that
target="RFC6513"/>, this term refers to a multicast tree to which represents traffic containing a single flow. Multiple sources, which
only the PEs interested in a specific Broadcast Domain (BD) may have the same or different IP addresses, can transmit traffic
belong. In the context of this document, it is specific to EVPN. for an SFG. An SFG can be represented in two forms:</t>
Two types of EVPN S-PMSIs are supported:<list style="symbols"> <dl spacing="normal" newline="false">
<t>S-PMSIs with Auto-Discovery Routes: These S-PMSIs require <dt>(*,G):</dt><dd>Indicates that any source transmitting
the upstream PE to advertise S-PMSI Auto-Discovery (S-PMSI multicast traffic to group G is considered a redundant G-source
A-D) routes, as described in <xref target="RFC9572"/>. for the SFG.</dd>
Downstream PEs interested in the multicast traffic join the <dt>(S,G):</dt><dd>Indicates that S is a prefix of any
S-PMSI tree following the procedures specified in <xref length. In this representation, a source is deemed a redundant
target="RFC9572"/>.</t> G-source for the SFG if its address matches the specified prefix
S.</dd>
<t>S-PMSIs without Auto-Discovery Routes: These S-PMSIs do not </dl>
require the advertisement of S-PMSI A-D routes. Instead, they </dd>
rely on the forwarding information provided by Inclusive <dt>SMET route:</dt><dd>Selective Multicast Ethernet Tag route, as
Multicast Ethernet Tag (IMET) routes. Upstream PEs forward IP in <xref target="RFC9251" format="default"/>.</dd>
multicast flows only to downstream PEs that advertise <dt>(S,G) and (*,G):</dt><dd>Used to describe multicast packets or
Selective Multicast Ethernet Tag (SMET) routes for the multicast state. "S" stands for Source (IP address of the multicast
specific flow. These S-PMSIs are supported exclusively with traffic), and "G" stands for the Group or multicast destination IP
the following P-tunnel types: Ingress Replication (IR), address of the group. An (S,G) multicast packet refers to an IP
Assisted Replication (AR), and Bit Indexed Explicit packet with source IP address "S" and destination IP address "G",
Replication (BIER).</t> and it is forwarded on a multicast router if there is a
</list></t> corresponding state for (S,G). A (*,G) multicast packet refers to an
IP packet with "any" source IP address and a destination IP address
<t>SFG (Single Flow Group): A multicast group that represents "G", and it is forwarded on a multicast router based on the
traffic containing a single flow. Multiple sources, which may have existence of the corresponding (*,G) state. The document uses
the same or different IP addresses, can transmit traffic for an variations of these terms. For example, (S1,G1) represents the
SFG. An SFG can be represented in two forms: <list style="symbols"> multicast packets or multicast state for source IP address "S1" and
<t>(*,G): Indicates that any source transmitting multicast group IP address "G1".</dd>
traffic to group G is considered a redundant G-source for the <dt>Upstream PE:</dt><dd>In this document, an upstream PE refers to
SFG.</t> either the EVPN PE that is directly connected to the IP multicast
source or the PE closest to the source. The upstream PE receives
<t>(S,G): Indicates that S is a prefix of any length. In this IP multicast flows through local Attachment Circuits (ACs).</dd>
representation, a source is deemed a redundant G-source for <dt>Warm Standby Redundancy:</dt><dd>A multicast source redundancy
the SFG if its address matches the specified prefix S.</t> mechanism defined in this document, wherein the upstream PEs
</list></t> connected to redundant sources within the same tenant ensure that
only one source of a given flow transmits multicast traffic to the
<t>SMET route: Selective Multicast Ethernet Tag route, as in <xref interested downstream PEs at any given time.</dd>
target="RFC9251"/>.</t> </dl>
<t>(S,G) and (*,G): used to describe multicast packets or
multicast state. S stands for Source (IP address of the multicast
traffic) and G stands for the Group or multicast destination IP
address of the group. An (S,G) multicast packet refers to an IP
packet with source IP address "S" and destination IP address "G",
and it is forwarded on a multicast router if there is a
corresponding state for (S,G). A (*,G) multicast packet refers to
an IP packet with "any" source IP address and a destination IP
address "G", and it is forwarded on a multicast router based on
the existence of the corresponding (*,G) state. The document uses
variations of these terms. For example, (S1,G1) represents the
multicast packets or multicast state for source IP address "S1"
and group IP address "G1".</t>
<t>Upstream PE: In this document, an Upstream PE refers to the
EVPN PE that is either directly connected to the IP multicast
source or is the PE closest to the source. The Upstream PE
receives IP multicast flows through local Attachment Circuits
(ACs).</t>
<t>Warm Standby Redundancy: A multicast source redundancy
mechanism defined in this document, wherein the upstream PEs
connected to redundant sources within the same tenant ensure that
only one source of a given flow transmits multicast traffic to the
interested downstream PEs at any given time.</t>
</list></t>
<t>This document also assumes familiarity with the terminology of <t>This document also assumes familiarity with the terminology of
<xref target="RFC7432"/>, <xref target="RFC4364"/>, <xref <xref target="RFC7432" format="default"/>, <xref target="RFC4364" format
target="RFC6513"/>, <xref target="RFC6514"/>, <xref ="default"/>, <xref target="RFC6513" format="default"/>, <xref target="RFC6514"
target="RFC9251"/>, <xref target="RFC9625"/>, <xref format="default"/>, <xref target="RFC9251" format="default"/>, <xref target="RFC
target="RFC9136"/>, and <xref target="RFC9572"/>.</t> 9625" format="default"/>, <xref target="RFC9136" format="default"/>, and <xref t
arget="RFC9572" format="default"/>.</t>
</section> </section>
<section anchor="sect-1.2" numbered="true" toc="default">
<section anchor="sect-1.2" <name>Background on IP Multicast Delivery in EVPN Networks</name>
title="Background on IP Multicast Delivery in EVPN Networks">
<t>IP multicast facilitates the delivery of a single copy of a packet <t>IP multicast facilitates the delivery of a single copy of a packet
from a source (S) to a group of receivers (G) along a multicast tree. from a source (S) to a group of receivers (G) along a multicast tree.
In an EVPN tenant domain, the multicast tree can be constructed where In an EVPN tenant domain, the multicast tree can be constructed where
the source (S) and the receivers for the multicast group (G) are the source (S) and the receivers for the multicast group (G) are
either connected to the same Broadcast Domain (BD) or to different either connected to the same Broadcast Domain (BD) or to different Broad
Broadcast Domains. The former scenario is referred to as "Intra-subnet cast Domains.
The former scenario is referred to as "Intra-subnet
IP Multicast forwarding", while the latter is referred to as IP Multicast forwarding", while the latter is referred to as
"Inter-subnet IP Multicast forwarding".</t> "Inter-subnet IP Multicast forwarding".</t>
<section anchor="sect-1.2.1" numbered="true" toc="default">
<section anchor="sect-1.2.1" <name>Intra-Subnet IP Multicast Forwarding</name>
title="Intra-subnet IP Multicast Forwarding">
<t>When the source S1 and the receivers interested in G1 are <t>When the source S1 and the receivers interested in G1 are
connected to the same Broadcast Domain (BD), the EVPN network can connected to the same Broadcast Domain, the EVPN network can
deliver IP multicast traffic to the receivers using two different deliver IP multicast traffic to the receivers using two different
approaches, as illustrated in <xref approaches, as illustrated in <xref target="ure-intra-subnet-ip-multic
target="ure-intra-subnet-ip-multicast"/>:</t> ast" format="default"/>:</t>
<figure anchor="ure-intra-subnet-ip-multicast">
<figure anchor="ure-intra-subnet-ip-multicast" <name>Intra-Subnet IP Multicast</name>
title="Intra-subnet IP Multicast"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
S1 + S1 + S1 + S1 +
(a) + | (b) + | (a) + | (b) + |
| | (S1,G1) | | (S1,G1) | | (S1,G1) | | (S1,G1)
PE1 | | PE1 | | PE1 | | PE1 | |
+-----+ v +-----+ v +-----+ v +-----+ v
|+---+| |+---+| |+---+| |+---+|
||BD1|| ||BD1|| ||BD1|| ||BD1||
|+---+| |+---+| |+---+| |+---+|
+-----+ +-----+ +-----+ +-----+
+-------|-------+ +-------| +-------|-------+ +-------|
skipping to change at line 413 skipping to change at line 344
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
PE2| PE3| PE4| PE2| PE3| PE4 PE2| PE3| PE4| PE2| PE3| PE4
- | - - - | - | - | - - - | - - | - - - | - | - | - - - | -
| | | | | | | | | | | | | | | | | |
v v v v v v v v v v
| R1 R2 | R3 | R1 R2 | R3 | R1 R2 | R3 | R1 R2 | R3
- - - G1- - - - - - G1- - - - - - G1- - - - - - G1- - -
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="symbols"> <dl spacing="normal" newline="false">
<t>Model (a): IP Multicast Delivery as BUM Traffic <vspace <dt>Model (a):</dt>
blankLines="1"/>The upstream PE sends the IP Multicast flows to <dd>
all downstream PEs, even to PEs with non-interested receivers, <t>IP Multicast Delivery as BUM Traffic</t>
such as, e.g., PE4 in <xref <t>The upstream PE sends the IP Multicast flows to all
target="ure-intra-subnet-ip-multicast"/>. To optimize this downstream PEs, even to PEs with non-interested receivers, such
behavior, downstream PEs can snoop IGMP/MLD messages from as, e.g., PE4 in <xref target="ure-intra-subnet-ip-multicast"
receivers to build Layer 2 multicast state. For instance, PE4 format="default"/>. To optimize this behavior, downstream PEs
could avoid forwarding (S1,G1) to R3, since R3 has not expressed can snoop IGMP/MLD messages from receivers to build Layer 2
interest in (S1,G1).</t> multicast state. For instance, PE4 could avoid forwarding
(S1,G1) to R3, since R3 has not expressed interest in
<t>Model (b): Optimized Delivery with S-PMSI<vspace (S1,G1).</t>
blankLines="1"/>Model (b) in <xref </dd>
target="ure-intra-subnet-ip-multicast"/> uses a "Selective <dt>Model (b):</dt>
Provider Multicast Service Interface (S-PMSI)" to optimize the <dd>
delivery of the (S1,G1) flow. <list style="symbols"> <t>Optimized Delivery with S-PMSI</t>
<t>For example, if PE1 uses "Ingress Replication (IR)", it <t>Model (b) in <xref target="ure-intra-subnet-ip-multicast"
will forward (S1,G1) only to downstream PEs that have issued format="default"/> uses a "Selective Provider Multicast Service
a "Selective Multicast Ethernet Tag (SMET)" route for Interface (S-PMSI)" to optimize the delivery of the (S1,G1)
(S1,G1), such as PE2 and PE3.</t> flow. </t>
<ul spacing="normal">
<t>If PE1 uses a P-tunnel type other than IR (e.g., Assisted <li>For example, if PE1 uses "IR", it
Replication (AR) or Bit Indexed Explicit Replication will forward (S1,G1) only to downstream PEs that have issued a
(BIER)), PE1 will advertise an "S-PMSI Auto-Discovery (A-D)" "SMET" route for (S1,G1),
route for (S1,G1). Downstream PEs such as PE2 and PE3 will such as PE2 and PE3.</li>
then join the corresponding multicast tree to receive the <li>If PE1 uses a P-tunnel type other than IR (e.g.,
flow.</t> AR or BIER),
</list></t> PE1 will advertise an "S-PMSI Auto-Discovery (A-D)" route for
</list></t> (S1,G1). Downstream PEs, such as PE2 and PE3, will then join the
corresponding multicast tree to receive the flow.</li>
</ul>
</dd>
</dl>
<t>Procedures for Model (b) are specified in <xref <t>Procedures for Model (b) are specified in <xref target="RFC9251" fo
target="RFC9251"/>.</t> rmat="default"/> and <xref target="RFC9572" format="default"/>.</t>
</section> </section>
<section anchor="sect-1.2.2" numbered="true" toc="default">
<section anchor="sect-1.2.2" <name>Inter-Subnet IP Multicast Forwarding</name>
title="Inter-subnet IP Multicast Forwarding">
<t>When the sources and receivers are connected to different BDs <t>When the sources and receivers are connected to different BDs
within the same tenant domain, the EVPN network can deliver IP within the same tenant domain, the EVPN network can deliver IP
multicast traffic using either Inclusive or Selective Multicast multicast traffic using either Inclusive or Selective Multicast
Trees, as illustrated in <xref Trees, as illustrated in <xref target="ure-inter-subnet-ip-multicast"
target="ure-inter-subnet-ip-multicast"/> with models (a) and (b), format="default"/> with models (a) and (b),
respectively.</t> respectively.</t>
<figure anchor="ure-inter-subnet-ip-multicast">
<figure anchor="ure-inter-subnet-ip-multicast" <name>Inter-Subnet IP Multicast</name>
title="Inter-subnet IP Multicast"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
S1 + S1 + S1 + S1 +
(a) + | (b) + | (a) + | (b) + |
| | (S1,G1) | | (S1,G1) | | (S1,G1) | | (S1,G1)
PE1 | | PE1 | | PE1 | | PE1 | |
+-----+ v +-----+ v +-----+ v +-----+ v
|+---+| |+---+| |+---+| |+---+|
||BD1|| ||BD1|| ||BD1|| ||BD1||
|+---+| |+---+| |+---+| |+---+|
+-----+ +-----+ +-----+ +-----+
+-------|-------+ +-------| +-------|-------+ +-------|
skipping to change at line 488 skipping to change at line 419
|+-|-+| |+-|-+| |+---+| |+-|-+| |+-|-+| |+---+| |+-|-+| |+-|-+| |+---+| |+-|-+| |+-|-+| |+---+|
+--|--+ +--|--+ +-----+ +--|--+ +--|--+ +-----+ +--|--+ +--|--+ +-----+ +--|--+ +--|--+ +-----+
PE2| PE3| PE4 PE2| PE3| PE4 PE2| PE3| PE4 PE2| PE3| PE4
- | - - - | - - | - - - | - - | - - - | - - | - - - | -
| | | | | | | | | | | | | | | |
v v v v v v v v
| R1 R2 | R3 | R1 R2 | R3 | R1 R2 | R3 | R1 R2 | R3
- - - G1- - - - - - G1- - - - - - G1- - - - - - G1- - -
]]></artwork> ]]></artwork>
</figure> </figure>
<t>As defined in <xref target="RFC9625" format="default"/>, inter-subn
<t>As defined in <xref target="RFC9625"/>, inter-subnet multicast et multicast
forwarding in EVPN is optimized by ensuring IP multicast flows are forwarding in EVPN is optimized by ensuring IP multicast flows are
sent within the context of the source BD. If a downstream PE is not sent within the context of the source BD. If a downstream PE is not
connected to the source BD, the IP multicast flow is delivered to connected to the source BD, the IP multicast flow is delivered to
the Supplementary Broadcast Domain (SBD), as shown in <xref the Supplementary Broadcast Domain (SBD), as shown in <xref target="ur
target="ure-inter-subnet-ip-multicast"/>.</t> e-inter-subnet-ip-multicast" format="default"/>.</t>
<t><list style="symbols">
<t>Inclusive and Selective Multicast Trees<list style="empty">
<t>Model (a): Inclusive Multicast Tree</t>
<ul spacing="normal">
<li><t>Inclusive and Selective Multicast Trees</t>
<dl spacing="normal">
<dt>Model (a):</dt><dd><t> Inclusive Multicast Tree</t>
<t>In this model, the Inclusive Multicast Tree for BD1 on <t>In this model, the Inclusive Multicast Tree for BD1 on
PE1 delivers (S1,G1) to all downstream PEs, such as PE2, PE1 delivers (S1,G1) to all downstream PEs, such as PE2,
PE3, and PE4, in the context of the SBD. Each downstream PE PE3, and PE4, in the context of the SBD. Each downstream PE
then locally routes the flow to its Attachment Circuits, then locally routes the flow to its ACs,
ensuring delivery to interested receivers.</t> ensuring delivery to interested receivers.</t></dd>
<dt>Model (b):</dt><dd><t>Selective Multicast Tree</t>
<t>Model (b): Selective Multicast Tree</t>
<t>In this model, PE1 optimizes forwarding by delivering <t>In this model, PE1 optimizes forwarding by delivering
(S1,G1) only to downstream PEs that explicitly indicate (S1,G1) only to downstream PEs that explicitly indicate
interest in the flow via Selective Multicast Ethernet Tag interest in the flow via SMET
(SMET) routes. If the P-tunnel type is "Ingress Replication routes. If the P-tunnel type is "IR", "AR", or "BIER", PE1 doe
(IR)", "Assisted Replication (AR)", or "Bit Indexed Explicit s not need to advertise an
Replication (BIER)", PE1 does not need to advertise an
S-PMSI A-D route. Downstream PEs join the multicast tree S-PMSI A-D route. Downstream PEs join the multicast tree
based on the SMET routes advertised for (S1,G1).</t> based on the SMET routes advertised for (S1,G1).</t></dd>
</list></t> </dl>
</li>
<t>Advantages of <xref target="RFC9625"/><list style="empty"> <li><t>Advantages of <xref target="RFC9625" format="default"/></t>
<t><xref target="RFC9625"/> extends the procedures defined <t><xref target="RFC9625" format="default"/> extends the
in <xref target="RFC9251"/> to support both intra- and procedures defined in <xref target="RFC9251" format="default"/> to
inter-subnet multicast forwarding for EVPN. It ensures that support both intra- and inter-subnet multicast forwarding for
every upstream PE attached to a source is aware of all EVPN. It ensures that every upstream PE attached to a source is
downstream PEs within the same tenant domain that have aware of all downstream PEs within the same tenant domain that
interest in specific flows. This is achieved through the have interest in specific flows. This is achieved through the
advertisement of SMET routes with the SBD Route Target, advertisement of SMET routes with the SBD Route Target, which are
which are imported by all upstream PEs.</t> imported by all upstream PEs.</t>
</list></t> </li>
<li><t>Elimination of Complexity</t>
<t>The inter-subnet multicast mechanism defined in <xref
target="RFC9625" format="default"/> eliminates the need for:
Rendezvous Points (RPs), shared trees, upstream multicast hop
selection, or other complex conventional multicast routing
techniques.</t>
</li>
</ul>
<t>Elimination of Complexity<list style="empty"> <t>By leveraging the EVPN framework, inter-subnet multicast
<t>The inter-subnet multicast mechanism defined in <xref
target="RFC9625"/> eliminates the need for: Rendezvous
Points (RP), Shared trees, Upstream Multicast Hop selection,
or other complex conventional multicast routing
techniques.</t>
</list></t>
</list>By leveraging the EVPN framework, inter-subnet multicast
forwarding achieves efficient delivery without introducing forwarding achieves efficient delivery without introducing
unnecessary overhead or dependencies on classic IP multicast unnecessary overhead or dependencies on classic IP multicast
protocols.</t> protocols.</t>
</section> </section>
</section> </section>
<section anchor="sect-1.3" numbered="true" toc="default">
<section anchor="sect-1.3" <name>Multi-Homed IP Multicast Sources in EVPN</name>
title="Multi-Homed IP Multicast Sources in EVPN">
<t>Unlike conventional multicast routing technologies, multi-homed PEs <t>Unlike conventional multicast routing technologies, multi-homed PEs
connected to the same source do not create IP multicast packet connected to the same source do not create IP multicast packet
duplication when utilizing a multi-homed Ethernet Segment. <xref duplication when utilizing a multi-homed ES. <xref target="ure-all-activ
target="ure-all-active-multi-homing-and-oism"/> illustrates this e-multi-homing-and-oism" format="default"/> illustrates this
scenario, where two multi-homed PEs (PE1 and PE2) are attached to the scenario, where two multi-homed PEs (PE1 and PE2) are attached to the
same source S1. The source S1 is connected via a Layer 2 switch (SW1) same source S1. The source S1 is connected via a Layer 2 switch (SW1)
to an all-active Ethernet Segment (ES-1), with a Link Aggregation to an all-active ES (ES-1), with a Link Aggregation
Group (LAG) extending to PE1 and PE2.</t> Group (LAG) extending to PE1 and PE2.</t>
<figure anchor="ure-all-active-multi-homing-and-oism">
<figure anchor="ure-all-active-multi-homing-and-oism" <name>All-Active Multi-Homing and OISM</name>
title="All-active Multi-homing and OISM"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
S1 S1
| |
v v
+-----+ +-----+
| SW1 | | SW1 |
+-----+ +-----+
+---- | | +---- | |
(S1,G1)| +----+ +----+ (S1,G1)| +----+ +----+
IGMP/MLD | | all-active | IGMP/MLD | | all-active |
J(S1,G1) PE1 v | ES-1 | PE2 J(S1,G1) PE1 v | ES-1 | PE2
skipping to change at line 595 skipping to change at line 518
+--------------| |VRF| |----------------+ +--------------| |VRF| |----------------+
| +---+---+---+ | | +---+---+---+ |
| |BD2| |BD3| | | |BD2| |BD3| |
| +-|-+ +-|-+ | | +-|-+ +-|-+ |
+---|-------|---+ +---|-------|---+
^ | | ^ ^ | | ^
IGMP/MLD | v v | IGMP/MLD IGMP/MLD | v v | IGMP/MLD
J(*,G1) | R2 R3 | J(S1,G1) J(*,G1) | R2 R3 | J(S1,G1)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When S1 transmits the (S1,G1) flow, SW1 selects a single link <t>When S1 transmits the (S1,G1) flow, SW1 selects a single link
within the all-active Ethernet Segment to forward the flow, as per within the all-active ES to forward the flow, as per
<xref target="RFC7432"/>. In this example, assuming PE1 is the <xref target="RFC7432" format="default"/>. In this example, assuming PE1
receiving PE for Broadcast Domain BD1, the multicast flow is forwarded is the
once BD1 establishes multicast state for (S1,G1) or (*,G1). In <xref receiving PE for BD1, the multicast flow is forwarded
target="ure-all-active-multi-homing-and-oism"/>: <list style="symbols"> once BD1 establishes multicast state for (S1,G1) or (*,G1). In <xref tar
get="ure-all-active-multi-homing-and-oism" format="default"/>: </t>
<ul spacing="normal">
<li>
<t>Receiver R1 receives (S1,G1) directly via the IRB (Integrated <t>Receiver R1 receives (S1,G1) directly via the IRB (Integrated
Routing and Bridging) interface, defined in <xref Routing and Bridging) interface, defined in <xref target="RFC9135" f
target="RFC9135"/>, following the procedures in <xref ormat="default"/>, following the procedures in <xref target="RFC9625" format="de
target="RFC9625"/>.</t> fault"/>.</t>
</li>
<li>
<t>Receivers R2 and R3, upon issuing IGMP/MLD reports, trigger PE3 <t>Receivers R2 and R3, upon issuing IGMP/MLD reports, trigger PE3
to advertise an SMET (*,G1) route. This creates multicast state in to advertise an SMET (*,G1) route. This creates multicast state in
PE1's BD1, enabling PE1 to forward the multicast flow to PE3's PE1's BD1, enabling PE1 to forward the multicast flow to PE3's
SBD. PE3 subsequently delivers the flow to R2 and R3 as defined in SBD. PE3 subsequently delivers the flow to R2 and R3 as defined in
<xref target="RFC9625"/>.</t> <xref target="RFC9625" format="default"/>.</t>
</list>Requirements for Multi-Homed IP Multicast Sources:</t> </li>
</ul>
<t><list style="symbols"> <t>Requirements for Multi-Homed IP Multicast Sources:</t>
<ul spacing="normal">
<li>
<t>When IP multicast source multi-homing is needed, EVPN <t>When IP multicast source multi-homing is needed, EVPN
multi-homed Ethernet Segments MUST be used.</t> multi-homed ESes <bcp14>MUST</bcp14> be used.</t>
</li>
<li>
<t>EVPN multi-homing ensures that only one upstream PE forwards a <t>EVPN multi-homing ensures that only one upstream PE forwards a
given multicast flow at a time, preventing packet duplication at given multicast flow at a time, preventing packet duplication at
downstream PEs.</t> downstream PEs.</t>
</li>
<li>
<t>The SMET route for a multicast flow ensures that all upstream <t>The SMET route for a multicast flow ensures that all upstream
PEs in the multi-homed Ethernet Segment maintain state for the PEs in the multi-homed ES maintain state for the
flow. This allows for immediate failover, as the backup PE can flow. This allows for immediate failover, as the backup PE can
seamlessly take over forwarding in case of an upstream PE seamlessly take over forwarding in case of an upstream PE
failure.</t> failure.</t>
</list></t> </li>
</ul>
<t>This document assumes that multi-homed PEs connected to the same <t>This document assumes that multi-homed PEs connected to the same
source always utilize multi-homed Ethernet Segments.</t> source always utilize multi-homed ESes.</t>
</section> </section>
<section anchor="sect-1.4" numbered="true" toc="default">
<section anchor="sect-1.4" <name>The Need for Redundant IP Multicast Sources in EVPN</name>
title="The Need for Redundant IP Multicast Sources in EVPN">
<t>While multi-homing PEs to the same IP multicast G-source provides a <t>While multi-homing PEs to the same IP multicast G-source provides a
certain level of resiliency, multicast applications are often critical certain level of resiliency, multicast applications are often critical
in operator networks, necessitating a higher level of redundancy. This in operator networks, necessitating a higher level of redundancy. This
document assumes the following:</t> document assumes the following:</t>
<t><list style="letters"> <ol type="a" spacing="normal">
<t>Redundant G-sources: redundant G-sources for an SFG may exist <li>Redundant G-sources: Redundant G-sources for an SFG may
within the EVPN tenant network. A redundant G-source is defined as exist within the EVPN tenant network. A redundant G-source is
a host or router transmitting an SFG stream in a tenant network defined as a host or router transmitting an SFG stream in a tenant
where another host or router is also sending traffic to the same network where another host or router is also sending traffic to the
SFG.</t> same SFG.</li>
<li>G-source placement: Redundant G-sources may reside in
<t>G-source placement: redundant G-sources may reside in the same the same BD or in different BDs of the tenant network. There must be
BD or in different BDs of the tenant network. There must be no no restrictions on the locations of receiver systems within the
restrictions on the locations of receiver systems within the tenant.</li>
tenant.</t> <li>G-source attachment to EVPN PEs: Redundant G-sources may
be either single-homed to a single EVPN PE or multi-homed to
<t>G-source attachment to EVPN PEs: redundant G-sources may be multiple EVPN PEs.</li>
either single-homed to a single EVPN PE or multi-homed to multiple <li>Packet duplication avoidance: The EVPN PEs must ensure
EVPN PEs.</t> that receiver systems do not experience duplicate packets for the
same SFG.</li>
</ol>
<t>Packet duplication avoidance: the EVPN PEs must ensure that <t>This framework ensures that EVPN networks can effectively
receiver systems do not experience duplicate packets for the same
SFG.</t>
</list>This framework ensures that EVPN networks can effectively
support redundant multicast sources while maintaining high reliability support redundant multicast sources while maintaining high reliability
and operational efficiency.</t> and operational efficiency.</t>
</section> </section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
<section anchor="sect-2" title="Solution Overview"> <name>Solution Overview</name>
<t>An SFG can be represented as (*,G) if any source transmitting <t>An SFG can be represented as (*,G) if any source transmitting
multicast traffic to group G is considered a redundant G-source. multicast traffic to group G is considered a redundant G-source.
Alternatively, this document allows an SFG to be represented as (S,G), Alternatively, this document allows an SFG to be represented as (S,G),
where the source IP address S is a prefix of variable length. In this where the source IP address S is a prefix of variable length. In this
case, a source is deemed a redundant G-source for the SFG if its address case, a source is deemed a redundant G-source for the SFG if its address
falls within the specified prefix. The use of variable-length prefixes falls within the specified prefix. In the remainder of this document,
in source advertisements via S-PMSI A-D routes is permitted in this some examples use (*,G) state for brevity. Wherever an SFG is
document only for the specific application of redundant G-sources.</t> represented as (*,G), it should be understood as being interchangeable
with (S,G). The use of variable-length prefixes in source advertisements
via S-PMSI A-D routes is permitted in this document only for the
specific application of redundant G-sources.</t>
<t>This document describes two solutions for handling redundant <t>This document describes two solutions for handling redundant
G-sources:</t> G-sources:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Warm Standby Solution</t> <t>Warm Standby Solution</t>
</li>
<li>
<t>Hot Standby Solution</t> <t>Hot Standby Solution</t>
</list></t> </li>
</ul>
<section anchor="sect-2.1" title="Warm Standby Solution"> <section anchor="sect-2.1" numbered="true" toc="default">
<name>Warm Standby Solution</name>
<t>The Warm Standby solution is an upstream PE-based solution, where <t>The Warm Standby solution is an upstream PE-based solution, where
downstream PEs do not participate in the procedures. In this solution, downstream PEs do not participate in the procedures. In this solution,
all upstream PEs connected to redundant G-sources for an SFG (*,G) or all upstream PEs connected to redundant G-sources for an SFG (*,G) or
(S,G) elect a "Single Forwarder (SF)" among themselves. After the (S,G) elect a "Single Forwarder (SF)" among themselves. After the
Single Forwarder is elected, the upstream PEs apply Reverse Path Single Forwarder is elected, the upstream PEs apply Reverse Path
Forwarding checks to the multicast state for the SFG: <list Forwarding checks to the multicast state for the SFG: </t>
style="symbols">
<t>Non-Single Forwarder Behavior: a non-Single Forwarder upstream
PE discards all (*,G) or (S,G) packets received over its local
Attachment Circuit.</t>
<t>Single Forwarder Behavior: the Single Forwarder accepts and <ul spacing="normal">
forwards (*,G) or (S,G) packets received on a single local <li>Non-Single Forwarder (Non-SF) Behavior: A Non-SF
Attachment Circuit for the SFG. If packets are received on upstream PE discards all (*,G) or (S,G) packets received over its
multiple local Attachment Circuits, the Single Forwarder discards local AC.</li>
packets on all but one. The selection of the Attachment Circuit <li>Single Forwarder Behavior: The Single Forwarder accepts
for forwarding is a local implementation detail.</t> and forwards (*,G) or (S,G) packets received on a single local
</list></t> AC for the SFG. If packets are received on multiple
local ACs, the Single Forwarder discards packets on
all but one. The selection of the AC for forwarding
is a local implementation detail.</li>
</ul>
<t>In the event of a failure of the Single Forwarder, a new Single <t>In the event of a failure of the Single Forwarder, a new Single Forwa
Forwarder is elected among the upstream PEs. This election process rder
is elected among the upstream PEs. This election process
requires BGP extensions on existing EVPN routes, which are detailed in requires BGP extensions on existing EVPN routes, which are detailed in
<xref target="sect-3"/> and <xref target="sect-4"/>.</t> Sections <xref target="sect-3" format="counter"/> and <xref target="sect -4" format="counter"/>.</t>
</section> </section>
<section anchor="sect-2.2" numbered="true" toc="default">
<section anchor="sect-2.2" title="Hot Standby Solution"> <name>Hot Standby Solution</name>
<t>The Hot Standby solution relies on downstream PEs to prevent <t>The Hot Standby solution relies on downstream PEs to prevent
duplication of SFG packets. Upstream PEs, aware of locally connected duplication of SFG packets. Upstream PEs, aware of locally connected
G-sources, append a unique Ethernet Segment Identifier (ESI) label to G-sources, append a unique ESI label to
multicast packets for each SFG. Downstream PEs receive SFG packets multicast packets for each SFG. Downstream PEs receive SFG packets
from all upstream PEs attached to redundant G-sources and avoid from all upstream PEs attached to redundant G-sources and avoid
duplication by performing a Reverse Path Forwarding check on the (*,G) duplication by performing a Reverse Path Forwarding check on the (*,G)
state for the SFG:</t> state for the SFG:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>Packet Filtering: a downstream PE discards (*,G) packets <li>Packet Filtering: A downstream PE discards (*,G) packets
received from the "wrong G-source."</t> received from the "wrong G-source."</li>
<li>Wrong G-source Identification: The "wrong G-source" is
<t>Wrong G-source Identification: the "wrong G-source" is identified using an ESI label that differs from the ESI label
identified using an ESI label that differs from the ESI label associated with the selected G-source.</li>
associated with the selected G-source.</t> <li>ESI Label Usage: In this solution, the ESI label is used
for "ingress filtering" at the downstream PE, rather than for
<t>ESI Label Usage: in this solution, the ESI label is used for "egress filtering" as described in <xref target="RFC7432"
"ingress filtering" at the downstream PE, rather than for "egress format="default"/>. In <xref target="RFC7432" format="default"/>,
filtering" as described in <xref target="RFC7432"/>. In <xref the ESI label indicates which egress ACs must be
target="RFC7432"/>, the ESI label indicates which egress excluded when forwarding BUM traffic. Here, the ESI label
Attachment Circuits must be excluded when forwarding BUM traffic. identifies ingress traffic that should be discarded by the
Here, the ESI label identifies ingress traffic that should be downstream PE.</li>
discarded by the downstream PE.</t> </ul>
</list></t>
<t>Control plane and data plane extensions to <xref target="RFC7432"/> <t>Control plane and data plane extensions to <xref target="RFC7432" for mat="default"/>
are required to support ESI labels for SFGs forwarded by upstream PEs. are required to support ESI labels for SFGs forwarded by upstream PEs.
Upon failure of the selected G-source, the downstream PE switches to a Upon failure of the selected G-source, the downstream PE switches to a
different G-source and updates its Reverse Path Forwarding check for different G-source and updates its Reverse Path Forwarding check for
the (*,G) state. These extensions and procedures are described in the (*,G) state. These extensions and procedures are described in Sectio
<xref target="sect-3"/> and <xref target="sect-5"/>.</t> ns
<xref target="sect-3" format="counter"/> and <xref target="sect-5" forma
t="counter"/>.</t>
</section> </section>
<section anchor="sect-2.3" numbered="true" toc="default">
<section anchor="sect-2.3" title="Solution Selection"> <name>Solution Selection</name>
<t>Operators should select a solution based on their specific <t>Operators should select a solution based on their specific
requirements: <list style="symbols"> requirements: </t>
<ul spacing="normal">
<li>
<t>The Warm Standby solution is more bandwidth-efficient but <t>The Warm Standby solution is more bandwidth-efficient but
incurs longer failover times in the event of a G-source or incurs longer failover times in the event of a G-source or
upstream PE failure. Additionally, only the upstream PEs connected upstream PE failure. Additionally, only the upstream PEs connected
to redundant G-sources for the same SFG need to support the new to redundant G-sources for the same SFG need to support the new
procedures in the Warm Standby solution.</t> procedures in the Warm Standby solution.</t>
</li>
<li>
<t>The Hot Standby solution is recommended for scenarios requiring <t>The Hot Standby solution is recommended for scenarios requiring
fast failover times, provided that the additional bandwidth fast failover times, provided that the additional bandwidth
consumption (due to multiple transmissions of SFG packets to consumption (due to multiple transmissions of SFG packets to
downstream PEs) is acceptable.</t> downstream PEs) is acceptable.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="sect-2.4" numbered="true" toc="default">
<section anchor="sect-2.4" title="System Support"> <name>System Support</name>
<t>This document does not mandate support for both solutions on a <t>This document does not mandate support for both solutions on a
single system. If one solution is implemented, support for the other single system. If one solution is implemented, support for the other
is OPTIONAL.</t> is <bcp14>OPTIONAL</bcp14>.</t>
</section> </section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default">
<section anchor="sect-3" title="BGP EVPN Extensions"> <name>BGP EVPN Extensions</name>
<t>This document introduces the following BGP EVPN extensions:</t> <t>This document introduces the following BGP EVPN extensions:</t>
<section anchor="sect-3.1" numbered="true" toc="default">
<section anchor="sect-3.1" <name>Single Flow Group Flag in the Multicast Flags Extended Community</
title="Single Flow Group Flag in the Multicast Flags Extended Com name>
munity">
<t>A new Single Flow Group (SFG) flag is defined within the Multicast <t>A new Single Flow Group (SFG) flag is defined within the Multicast
Flags Extended Community. This flag is requested from the IANA Flags Extended Community. This flag has been registered as bit 4
registry for "Multicast Flags Extended Community Flag Values". The SFG in the "Multicast Flags Extended Community" registry (see <xref target="
flag is set in S-PMSI A-D routes that carry (*,G) or (S,G) Single Flow sfg"/>). The SFG
Group information in the NLRI (BGP EVPN Network Layer Reachability flag is set in S-PMSI A-D routes that carry (*,G) or (S,G) Single Flow G
Information).</t> roup
information in the BGP EVPN Network Layer Reachability
Information (NLRI).</t>
</section> </section>
<section anchor="sect-3.2" numbered="true" toc="default">
<section anchor="sect-3.2" <name>ESI Label Extended Community in S-PMSI A-D Routes</name>
title="ESI Label Extended Community in S-PMSI A-D Routes">
<t>The Hot Standby solution requires the advertisement of one or more <t>The Hot Standby solution requires the advertisement of one or more
ESI Label Extended Communities <xref target="RFC7432"/> alongside the ESI Label Extended Communities <xref target="RFC7432" format="default"/> alongside the
S-PMSI A-D routes. These extended communities encode the ESI values S-PMSI A-D routes. These extended communities encode the ESI values
associated with an S-PMSI A-D (*,G) or (S,G) route that advertises the associated with an S-PMSI A-D (*,G) or (S,G) route that advertises the
presence of a Single Flow Group.</t> presence of a Single Flow Group.</t>
<t>Key considerations include:</t> <t>Key considerations include:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>When advertised with the S-PMSI A-D routes, only the ESI label
<t>When advertised with the S-PMSI A-D routes, only the ESI Label
value in the extended community is relevant to the procedures value in the extended community is relevant to the procedures
defined in this document.</t> defined in this document.</t>
</li>
<t>The Flags field within the extended community MUST be set to <li>
'0x00' on transmission and MUST be ignored on reception.</t> <t>The Flags field within the extended community <bcp14>MUST</bcp14>
</list><xref target="RFC7432"/> specifies the use of the ESI Label be set to
"0x00" on transmission and <bcp14>MUST</bcp14> be ignored on recepti
on.</t>
</li>
</ol>
<t><xref target="RFC7432" format="default"/> specifies the use of the ES
I Label
Extended Community in conjunction with the A-D per ES route. This Extended Community in conjunction with the A-D per ES route. This
document extends the applicability of the ESI Label Extended Community document extends the applicability of the ESI Label Extended Community
by allowing its inclusion multiple times (with different ESI Label by allowing its inclusion multiple times (with different ESI label
values) alongside the EVPN S-PMSI A-D route. These extensions enable values) alongside the EVPN S-PMSI A-D route. These extensions enable
the precise encoding and advertisement of Single Flow Group-related the precise encoding and advertisement of SFG-related
information, facilitating efficient multicast traffic handling in EVPN information, facilitating efficient multicast traffic handling in EVPN
networks.</t> networks.</t>
</section> </section>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
<section anchor="sect-4" <name>Warm Standby (WS) Solution for Redundant G-Sources</name>
title="Warm Standby (WS) Solution for Redundant G-Sources"> <t>This section specifies the Warm Standby solution for handling
<t>This section specifies the Warm Standby (WS) solution for handling
redundant multicast sources (G-sources). Note that while the examples redundant multicast sources (G-sources). Note that while the examples
use IPv4 addresses, the solution supports both IPv4 and IPv6 use IPv4 addresses, the solution supports both IPv4 and IPv6
sources.</t> sources.</t>
<section anchor="sect-4.1" numbered="true" toc="default">
<section anchor="sect-4.1" title="Specification"> <name>Specification</name>
<t>The Warm Standby solution follows these general procedures:</t> <t>The Warm Standby solution follows these general procedures:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>Configuration of the upstream PEs</t>
<t>Configuration of the upstream PEs<vspace <t>Upstream PEs, potentially connected to redundant
blankLines="1"/>Upstream PEs, potentially connected to redundant G-sources, are configured to recognize: </t>
G-sources, are configured to recognize: <list style="symbols"> <ul spacing="normal">
<li>
<t>The multicast groups that carry an SFG in the tenant <t>The multicast groups that carry an SFG in the tenant
domain.</t> domain.</t>
</li>
<li>
<t>The local Broadcast Domains that may host redundant <t>The local Broadcast Domains that may host redundant
G-sources</t> G-sources</t>
</list>The SFG configuration applies to either 'any' source, </li>
i.e., (*) or to a specific 'source prefix' (e.g., "192.0.2.0/30" </ul>
<t>The SFG configuration applies to either "any" source,
i.e., (*) or to a specific "source prefix" (e.g., "192.0.2.0/30"
or "2001:db8::/120"). For instance, if the IPv4 prefix is or "2001:db8::/120"). For instance, if the IPv4 prefix is
192.0.2.0/30, the sources 192.0.2.1 and 192.0.2.2 are considered 192.0.2.0/30, the sources 192.0.2.1 and 192.0.2.2 are considered
redundant G-sources for the SFG, while 192.0.2.10 is not. In a redundant G-sources for the SFG, while 192.0.2.10 is not. In a
different example for IPv6, if the prefix is 2001:db8::/120, different example for IPv6, if the prefix is 2001:db8::/120,
sources 2001:db8::1 or 2001:db8::2 are considered redundant sources 2001:db8::1 or 2001:db8::2 are considered redundant
G-sources for the SFG, but 2001:db8:1::1 is not.<vspace G-sources for the SFG, but 2001:db8:1::1 is not.</t>
blankLines="1"/>Example Configuration (<xref <t>Example Configuration (<xref target="ure-ws-solution-for-redundan
target="ure-ws-solution-for-redundant-g-sources"/>):<list t-g-sources" format="default"/>):</t>
style="symbols"> <ul spacing="normal">
<li>
<t>PE1 is configured to recognize G1 as an SFG for any source, <t>PE1 is configured to recognize G1 as an SFG for any source,
with potential redundant G-sources attached to Broadcast with potential redundant G-sources attached to
Domains BD1 and BD2.</t> BD1 and BD2.</t>
</li>
<li>
<t>Alternatively, PE1 may recognize G1 as an SFG for sources <t>Alternatively, PE1 may recognize G1 as an SFG for sources
within 192.0.2.0/30 (or 2001:db8::/120), with redundant within 192.0.2.0/30 (or 2001:db8::/120), with redundant
G-sources in BD1 and BD2.</t> G-sources in BD1 and BD2.</t>
</list></t> </li>
</ul>
<t>Signaling the location of a G-source for an SFG<vspace </li>
blankLines="1"/>Upon receiving the first IP multicast packet for a <li>
<t>Signaling the location of a G-source for an SFG</t>
<t>Upon receiving the first IP multicast packet for a
configured SFG on a Broadcast Domain, an upstream PE (e.g., configured SFG on a Broadcast Domain, an upstream PE (e.g.,
PE1):<list style="symbols"> PE1):</t>
<t>MUST advertise an S-PMSI A-D route for the SFG:<list <ul spacing="normal">
style="symbols"> <li>
<t><bcp14>MUST</bcp14> advertise an S-PMSI A-D route for the SFG
:</t>
<ul spacing="normal">
<li>
<t>An (*,G) route if the SFG is configured for any <t>An (*,G) route if the SFG is configured for any
source.</t> source.</t>
</li>
<li>
<t>An (S,G) route (where S can have any prefix length) if <t>An (S,G) route (where S can have any prefix length) if
the SFG is configured for a source prefix.</t> the SFG is configured for a source prefix.</t>
</list></t> </li>
</ul>
<t>MUST include the following attributes in the S-PMSI A-D </li>
route:<list style="symbols"> <li>
<t>Route Targets (RTs): the Supplementary Broadcast Domain <t><bcp14>MUST</bcp14> include the following attributes in the S
Route Target (SBD-RT), if applicable, and the Broadcast -PMSI A-D
Domain Route Target (BD-RT) of the Broadcast Domain route:</t>
receiving the traffic. The SBD-RT is needed so that the <ul spacing="normal">
route is imported by all PEs attached to the tenant domain <li>
in an OISM solution.</t> <t>Route Targets (RTs): The Broadcast Domain Route Target
(BD-RT) of the BD receiving the traffic and, if
<t>Multicast Flags Extended Community: that MUST include applicable, the Supplementary Broadcast Domain Route
Target (SBD-RT), which is needed so that the route is
imported by all PEs attached to the tenant domain in an
OISM solution.</t>
</li>
<li>
<t>Multicast Flags Extended Community: <bcp14>MUST</bcp14> i
nclude
the SFG flag to indicate that the route conveys an the SFG flag to indicate that the route conveys an
SFG.</t> SFG.</t>
</li>
<li>
<t>Designated Forwarder Election Extended Community: <t>Designated Forwarder Election Extended Community:
specifies the algorithm and preferences for the Single Specifies the algorithm and preferences for the Single Forwa
Forwarder election, using the Designated Forwarder rder
election defined in <xref target="RFC8584"/>.</t> election, using the DF
</list></t> election defined in <xref target="RFC8584" format="default"/
>.</t>
<t>Advertises the route:<list style="symbols"> </li>
<t>Without a PMSI Tunnel Attribute if using Ingress </ul>
Replication (IR), Assisted Replication (AR), or Bit </li>
Indexed Explicit Replication (BIER).</t> <li>
<t>Advertises the route:</t>
<ul spacing="normal">
<li>
<t>Without a PMSI Tunnel Attribute if using IR, AR, or BIER.
</t>
</li>
<li>
<t>With a PMSI Tunnel Attribute for other tunnel <t>With a PMSI Tunnel Attribute for other tunnel
types.</t> types.</t>
</list></t> </li>
</ul>
<t>MUST withdraw the S-PMSI A-D route when the SFG traffic </li>
ceases. A timer is RECOMMENDED to detect inactivity and <li>
<t><bcp14>MUST</bcp14> withdraw the S-PMSI A-D route when the SF
G traffic
ceases. A timer is <bcp14>RECOMMENDED</bcp14> to detect inactivi
ty and
trigger route withdrawal.</t> trigger route withdrawal.</t>
</list></t> </li>
</ul>
<t>Single Forwarder Election on the upstream PEs<vspace </li>
blankLines="1"/>If an upstream PE receives one or more S-PMSI A-D <li>
routes for the same SFG from remote PEs, it performs Single <t>Single Forwarder Election on the upstream PEs</t>
Forwarder Election based on the Designated Forwarder Election <t>If an upstream PE receives one or more S-PMSI A-D
Extended Community. <list style="symbols"> routes for the same SFG from remote PEs, it performs Single Forwarde
r
Election based on the Designated Forwarder Election
Extended Community. </t>
<ul spacing="normal">
<li>
<t>Two routes are considered part of the same SFG if they are <t>Two routes are considered part of the same SFG if they are
advertised for the same tenant and match on the following advertised for the same tenant and match in the following
fields:<list style="symbols"> fields:</t>
<ul spacing="normal">
<li>
<t>Multicast Source Length</t> <t>Multicast Source Length</t>
</li>
<li>
<t>Multicast Source</t> <t>Multicast Source</t>
</li>
<li>
<t>Multicast Group Length</t> <t>Multicast Group Length</t>
</li>
<li>
<t>Multicast Group</t> <t>Multicast Group</t>
</list></t> </li>
</ul>
<t>Election Rules:<list style="numbers"> </li>
<t>A consistent Designated Forwarder Election Algorithm <li>
MUST be used across all upstream PEs for the Single <t>Election Rules:</t>
Forwarder election. In OISM networks, the Default <ol spacing="normal" type="1"><li>
Designated Forwarder Election Algorithm MUST NOT be used <t>A consistent DF Election Algorithm
<bcp14>MUST</bcp14> be used across all upstream PEs for the
Single Forwarder
election. In OISM networks, the Default
Designated Forwarder Election Algorithm <bcp14>MUST NOT</bcp
14> be used
if redundant G-sources are attached to Broadcast Domains if redundant G-sources are attached to Broadcast Domains
with different Ethernet Tags.</t> with different Ethernet Tags.</t>
</li>
<t>In case of a mismatch in the Designated Forwarder <li>
<t>In case of a mismatch in the DF
Election Algorithm or capabilities, the tie-breaker is the Election Algorithm or capabilities, the tie-breaker is the
lowest PE IP address (as advertised in the Originator lowest PE IP address (as advertised in the Originator
Address field of the S-PMSI A-D route).</t> Address field of the S-PMSI A-D route).</t>
</list></t> </li>
</list></t> </ol>
</li>
<t>Reverse Path Forwarding Checks on Upstream PEs<vspace </ul>
blankLines="1"/>All PEs with a local G-source for an SFG apply a </li>
<li>
<t>Reverse Path Forwarding Checks on the Upstream PEs</t>
<t>All PEs with a local G-source for an SFG apply a
Reverse Path Forwarding check to the (*,G) or (S,G) state based on Reverse Path Forwarding check to the (*,G) or (S,G) state based on
the Single Forwarder election result:<list style="numbers"> the Single Forwarder election result:</t>
<t>Non-Single Forwarder PEs: MUST discard all (*,G) or (S,G) <ol spacing="normal" type="1"><li>
packets received on local Attachment Circuits.</t> <t>Non-SF PEs: <bcp14>MUST</bcp14> discard all (*,G) or (S,G)
packets received on local ACs.</t>
<t>Single Forwarder PEs: MUST forward (*,G) or (S,G) packets </li>
received on one (and only one) local Attachment Circuit.</t> <li>
</list></t> <t>Single Forwarder PEs: <bcp14>MUST</bcp14> forward (*,G) or (S
</list></t> ,G) packets
received on one (and only one) local AC.</t>
<t>Key Features of the Warm Standby Solution:<list style="symbols"> </li>
</ol>
</li>
</ol>
<t>Key Features of the Warm Standby Solution:</t>
<ul spacing="normal">
<li>
<t>The solution ensures redundancy for SFGs without requiring <t>The solution ensures redundancy for SFGs without requiring
upgrades to downstream PEs (where no redundant G-sources are upgrades to downstream PEs (where no redundant G-sources are
connected).</t> connected).</t>
</li>
<t>Existing procedures for non-SFG G-sources remain unchanged.</t> <li>
<t>Existing procedures for Non-SFG G-sources remain unchanged.</t>
</li>
<li>
<t>Redundant G-sources can be either single-homed or multi-homed. <t>Redundant G-sources can be either single-homed or multi-homed.
Multi-homing does not alter the above procedures.</t> Multi-homing does not alter the above procedures.</t>
</list></t> </li>
</ul>
<t>Examples of the Warm Standby solution are provided in <xref <t>Examples of the Warm Standby solution are provided in Sections <xref
target="sect-4.2"/> and <xref target="sect-4.3"/>.</t> target="sect-4.2" format="counter"/> and <xref target="sect-4.3" format="counter
"/>.</t>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
<section anchor="sect-4.2" <name>Warm Standby Example in an OISM Network</name>
title="Warm Standby Example in an OISM Network"> <t><xref target="ure-ws-solution-for-redundant-g-sources" format="defaul
<t><xref target="ure-ws-solution-for-redundant-g-sources"/> t"/>
illustrates an example where S1 and S2 are redundant G-sources for the illustrates an example where S1 and S2 are redundant G-sources for the
Single Flow Group (*,G1).</t> Single Flow Group (*,G1).</t>
<figure anchor="ure-ws-solution-for-redundant-g-sources">
<figure anchor="ure-ws-solution-for-redundant-g-sources" <name>Warm Standby Solution for Redundant G-Sources</name>
title="Warm Standby Solution for Redundant G-Sources"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
S1 (Single S2 S1 (Single S2
| Forwarder) | | Forwarder) |
(S1,G1)| (S2,G1)| (S1,G1)| (S2,G1)|
| | | |
PE1 | PE2 | PE1 | PE2 |
+--------v---+ +--------v---+ +--------v---+ +--------v---+
S-PMSI | +---+ | | +---+ | S-PMSI S-PMSI | +---+ | | +---+ | S-PMSI
(*,G1) | +---|BD1| | | +---|BD2| | (*,G1) (*,G1) | +---|BD1| | | +---|BD2| | (*,G1)
Pref200 | |VRF+---+ | | |VRF+---+ | Pref100 Pref200 | |VRF+---+ | | |VRF+---+ | Pref100
|SFG |+---+ | | | |+---+ | | SFG| |SFG |+---+ | | | |+---+ | | SFG|
skipping to change at line 995 skipping to change at line 966
| |VRF+---+ | | |VRF+---+ | | | |VRF+---+ | | |VRF+---+ | | |VRF+---+ | | | |VRF+---+ |
|+---+ | | |+---+ | | | |+---+ | | |+---+ | | |+---+ | | | |+---+ | |
||BD3|--+ | ||BD4|--+ | +--->|BD1|--+ | ||BD3|--+ | ||BD4|--+ | +--->|BD1|--+ |
|+---+ | |+---+ | |+---+ | |+---+ | |+---+ | |+---+ |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| ^ | ^ | ^ | ^
| | IGMP/MLD | | IGMP/MLD | | IGMP/MLD | | IGMP/MLD
R1 | J(*,G1) R3| J(*,G1) R1 | J(*,G1) R3| J(*,G1)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Warm Standby procedure is as follows:</t> <t>The Warm Standby procedure is as follows:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>Configuration of the upstream PEs (PE1 and PE2)</t>
<t>Configuration of the upstream PEs (PE1 and PE2)<vspace <ul spacing="normal">
blankLines="1"/><list style="symbols"> <li>
<t>PE1 and PE2 are configured to recognize G1 as a Single Flow <t>PE1 and PE2 are configured to recognize G1 as a Single Flow G
Group for any source.</t> roup
for any source.</t>
<t>Redundant G-sources for G1 may be attached to Broadcast </li>
Domains BD1 (for PE1) and BD2 (for PE2).</t> <li>
</list></t> <t>Redundant G-sources for G1 may be attached to
BD1 (for PE1) and BD2 (for PE2).</t>
<t>Signaling the location of S1 and S2 for (*,G1)<vspace </li>
blankLines="1"/>Upon receiving traffic for G1 on a local </ul>
Attachment Circuit:<list style="symbols"> </li>
<li>
<t>Signaling the location of S1 and S2 for (*,G1)</t>
<t>Upon receiving traffic for G1 on a local
AC:</t>
<ul spacing="normal">
<li>
<t>PE1 and PE2 originate S-PMSI A-D routes for (*,G1), <t>PE1 and PE2 originate S-PMSI A-D routes for (*,G1),
including:<list style="symbols"> including:</t>
<t>The Supplementary Broadcast Domain Route Target <ul spacing="normal">
(SBD-RT),</t> <li>
<t>the SBD-RT,</t>
<t>The Designated Forwarder Election Extended Community, </li>
<li>
<t>the Designated Forwarder Election Extended Community,
and</t> and</t>
</li>
<t>The SFG flag in the Multicast Flags Extended <li>
<t>the SFG flag in the Multicast Flags Extended
Community.</t> Community.</t>
</list></t> </li>
</ul>
<t>These routes indicate the presence of a Single Flow </li>
Group.</t> <li>
</list></t> <t>These routes indicate the presence of a Single Flow Group.</t
>
<t>Single Forwarder Election<vspace blankLines="1"/><list </li>
style="symbols"> </ul>
</li>
<li>
<t>Single Forwarder Election</t>
<ul spacing="normal">
<li>
<t>Based on the Designated Forwarder Election Extended <t>Based on the Designated Forwarder Election Extended
Community, PE1 and PE2 perform Single Forwarder election.</t> Community, PE1 and PE2 perform Single Forwarder election.</t>
</li>
<t>Assuming they use Preference-based Election <xref <li>
target="I-D.ietf-bess-evpn-pref-df"/>, PE1 (with a higher <t>Assuming they use Preference-based Election <xref target="RFC
9785" format="default"/>, PE1 (with a higher
preference) is elected as the Single Forwarder for (*,G1).</t> preference) is elected as the Single Forwarder for (*,G1).</t>
</list></t> </li>
</ul>
</li>
<li>
<t>Reverse Path Forwarding check on the PEs attached to a <t>Reverse Path Forwarding check on the PEs attached to a
redundant G-source<list style="letters"> redundant G-source</t>
<t>Non-Single Forwarder Behavior: PE2 discards all (*,G1) <ol spacing="normal" type="a"><li>
packets received on its local Attachment Circuit.</t> <t>Non-SF Behavior: PE2 discards all (*,G1)
packets received on its local AC.</t>
</li>
<li>
<t>Single Forwarder Behavior: PE1 forwards (*,G1) packets <t>Single Forwarder Behavior: PE1 forwards (*,G1) packets
received on one (and only one) local Attachment Circuit.</t> received on one (and only one) local AC.</t>
</list></t> </li>
</list></t> </ol>
</li>
<t>The outcome:<list style="symbols"> </ol>
<t>The outcome:</t>
<ul spacing="normal">
<li>
<t>Upon receiving IGMP/MLD reports for (*,G1) or (S,G1), <t>Upon receiving IGMP/MLD reports for (*,G1) or (S,G1),
downstream PEs (PE3 and PE5) issue SMET routes to pull the downstream PEs (PE3 and PE5) issue SMET routes to pull the
multicast Single Flow Group traffic from PE1 only.</t> multicast Single Flow Group traffic from PE1 only.</t>
</li>
<t>In the event of a failure of S1, the Attachment Circuit <li>
<t>In the event of a failure of S1, the AC
connected to S1, or PE1 itself, the S-PMSI A-D route for (*,G1) is connected to S1, or PE1 itself, the S-PMSI A-D route for (*,G1) is
withdrawn by PE1.</t> withdrawn by PE1.</t>
</li>
<li>
<t>As a result, PE2 is promoted to Single Forwarder, ensuring <t>As a result, PE2 is promoted to Single Forwarder, ensuring
continued delivery of (*,G1) traffic.</t> continued delivery of (*,G1) traffic.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="sect-4.3" numbered="true" toc="default">
<section anchor="sect-4.3" <name>Warm Standby Example in a Single-BD Tenant Network</name>
title="Warm Standby Example in a Single-BD Tenant Network"> <t><xref target="ure-ws-solution-for-redundant-g-sources-in-the-same-bd"
<t><xref format="default"/>
target="ure-ws-solution-for-redundant-g-sources-in-the-same-bd"/>
illustrates an example where S1 and S2 are redundant G-sources for the illustrates an example where S1 and S2 are redundant G-sources for the
Single Flow Group (*,G1). In this case, all G-sources and receivers Single Flow Group (*,G1). In this case, all G-sources and receivers
are connected to the same Broadcast Domain (BD1), and there is no are connected to the same BD1, and there is no
Supplementary Broadcast Domain (SBD).</t> SBD.</t>
<figure anchor="ure-ws-solution-for-redundant-g-sources-in-the-same-bd">
<figure anchor="ure-ws-solution-for-redundant-g-sources-in-the-same-bd" <name>WS Solution for Redundant G-Sources in the Same BD</name>
title="WS Solution for Redundant G-Sources in the same BD"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
S1 (Single S2 S1 (Single S2
| Forwarder) | | Forwarder) |
(S1,G1)| (S2,G1)| (S1,G1)| (S2,G1)|
| | | |
PE1 | PE2 | PE1 | PE2 |
+--------v---+ +--------v---+ +--------v---+ +--------v---+
S-PMSI | +---+ | | +---+ | S-PMSI S-PMSI | +---+ | | +---+ | S-PMSI
(*,G1) | |BD1| | | |BD1| | (*,G1) (*,G1) | |BD1| | | |BD1| | (*,G1)
Pref200 | +---+ | | +---+ | Pref100 Pref200 | +---+ | | +---+ | Pref100
|SFG | | | | | SFG| |SFG | | | | | SFG|
skipping to change at line 1107 skipping to change at line 1096
| +---+ | | +---+ | | +---+ | | +---+ | | +---+ | | +---+ |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| ^ | ^ | ^ | ^
| | IGMP/MLD | | IGMP/MLD | | IGMP/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1) R1 | J(*,G1) R3 | J(*,G1)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The procedures for the Warm Standby solution in this example are <t>The procedures for the Warm Standby solution in this example are
identical to those described in <xref target="sect-4.2"/>, with the identical to those described in <xref target="sect-4.2" format="default"
following distinction:<list style="symbols"> />, with the
<t>Signaling the S-PMSI A-D Routes <list style="symbols"> following distinction:</t>
<ul spacing="normal">
<li>
<t>Signaling the S-PMSI A-D Routes </t>
<ul spacing="normal">
<li>
<t>Upon receiving traffic for the Single Flow Group (*,G1), <t>Upon receiving traffic for the Single Flow Group (*,G1),
PE1 and PE2 advertise S-PMSI A-D routes.</t> PE1 and PE2 advertise S-PMSI A-D routes.</t>
</li>
<li>
<t>These routes include only the BD1-RT (Broadcast Domain 1 <t>These routes include only the BD1-RT (Broadcast Domain 1
Route Target) as there is no Supplementary Broadcast Domain Route Target) as there is no SBD
(SBD) in this scenario.</t> in this scenario.</t>
</list></t> </li>
</list></t> </ul>
</li>
</ul>
<t>This example represents a specific sub-case of the broader <t>This example represents a specific sub-case of the broader
procedure detailed in <xref target="sect-4.2"/>, adapted to a single procedure detailed in <xref target="sect-4.2" format="default"/>, adapte d to a single
Broadcast Domain environment. The absence of an SBD simplifies the Broadcast Domain environment. The absence of an SBD simplifies the
configuration, as all signaling remains within the context of BD1.</t> configuration, as all signaling remains within the context of BD1.</t>
</section> </section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
<section anchor="sect-5" <name>Hot Standby Solution for Redundant G-Sources</name>
title="Hot Standby Solution for Redundant G-Sources">
<t>This section specifies the Hot Standby solution for handling <t>This section specifies the Hot Standby solution for handling
redundant multicast sources (G-sources). The solution supports both IPv4 redundant multicast sources (G-sources). The solution supports both IPv4
and IPv6 sources.</t> and IPv6 sources.</t>
<section anchor="sect-5.1" numbered="true" toc="default">
<section anchor="sect-5.1" title="Specification"> <name>Specification</name>
<t>The Hot Standby solution is designed for scenarios requiring fast <t>The Hot Standby solution is designed for scenarios requiring fast
failover in the event of a G-source or upstream PE failure. It assumes failover in the event of a G-source or upstream PE failure. It assumes
that additional bandwidth consumption in the tenant network is that additional bandwidth consumption in the tenant network is
acceptable. The procedure is as follows:</t> acceptable. The procedure is as follows:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>Configuration of PEs</t>
<t>Configuration of PEs<vspace blankLines="1"/><list <ul spacing="normal">
style="symbols"> <li>
<t>Upstream PEs are configured to identify Single Flow Groups <t>Upstream PEs are configured to identify Single Flow Groups
in the tenant domain. This includes groups for any source or a in the tenant domain. This includes groups for any source or a
source prefix containing redundant G-sources.</t> source prefix containing redundant G-sources.</t>
</li>
<t>Each redundant G-source MUST be associated with an Ethernet <li>
Segment on the upstream PEs. This applies to both single-homed <t>Each redundant G-source <bcp14>MUST</bcp14> be associated wit
h an ES
on the upstream PEs. This applies to both single-homed
and multi-homed G-sources. For both, single-homed and and multi-homed G-sources. For both, single-homed and
multi-homed G-sources, ESI labels are essential for Reverse multi-homed G-sources, ESI labels are essential for Reverse
Path Forwarding checks on downstream PEs. The term S-ESI is Path Forwarding checks on downstream PEs. The term S-ESI is
used to denote the ESI associated with a redundant used to denote the ESI associated with a redundant
G-source.</t> G-source.</t>
</li>
<li>
<t>Unlike the Warm Standby solution, the Hot Standby solution <t>Unlike the Warm Standby solution, the Hot Standby solution
requires downstream PEs to support the procedure.</t> requires downstream PEs to support the procedure.</t>
</li>
<t>Downstream PEs: <list style="symbols"> <li>
<t>Do not need explicit configuration for Single Flow <t>Downstream PEs: </t>
Groups or their ESIs (since they get that information from <ul spacing="normal">
<li>
<t>Do not need explicit configuration for Single Flow Groups
or their ESIs (since they get that information from
the upstream PEs).</t> the upstream PEs).</t>
</li>
<li>
<t>Dynamically select an ESI for each Single Flow Group <t>Dynamically select an ESI for each Single Flow Group
based on local policy (hence different downstream PEs may based on local policy (hence different downstream PEs may
select different Ethernet Segment Identifiers) and program select different ESIs) and program
a Reverse Path Forwarding check to discard (*,G) or (S,G) a Reverse Path Forwarding check to discard (*,G) or (S,G)
packets from other ESIs.</t> packets from other ESIs.</t>
</list></t> </li>
</list></t> </ul>
</li>
</ul>
</li>
<li>
<t>Signaling the location of a G-source for a given SFG and its <t>Signaling the location of a G-source for a given SFG and its
association to the local Ethernet Segments<vspace blankLines="1"/> association to the local ESes</t>
An upstream PE configured for Hot Standby procedures: <list <t>An upstream PE configured for Hot Standby procedures: </t>
style="symbols"> <ul spacing="normal">
<t>MUST advertise an S-PMSI A-D route for each Single Flow <li>
Group. These routes:<list style="symbols"> <t><bcp14>MUST</bcp14> advertise an S-PMSI A-D route for each Si
ngle Flow Group.
These routes:</t>
<ul spacing="normal">
<li>
<t>Use the Broadcast Domain Route Target (BD-RT) and, if <t>Use the Broadcast Domain Route Target (BD-RT) and, if
applicable, the Supplementary Broadcast Domain Route applicable, the
Target (SBD-RT) so that the routes are imported in all the SBD-RT so that the routes are imported in all the
PEs of the tenant domain.</t> PEs of the tenant domain.</t>
</li>
<t>MUST include ESI Label Extended Communities to convey <li>
<t><bcp14>MUST</bcp14> include ESI Label Extended Communitie
s to convey
the S-ESI labels associated with the Single Flow Group. the S-ESI labels associated with the Single Flow Group.
These ESI-labels match the labels advertised by the EVPN These ESI labels match the labels advertised by the EVPN
A-D per ES routes for each S-ES.</t> A-D per ES routes for each S-ES.</t>
</list></t> </li>
</ul>
<t>MAY include a PMSI Tunnel Attribute, depending on the </li>
<li>
<t><bcp14>MAY</bcp14> include a PMSI Tunnel Attribute, depending
on the
tunnel type, as specified in the Warm Standby procedure.</t> tunnel type, as specified in the Warm Standby procedure.</t>
</li>
<t>MUST trigger the S-PMSI A-D route advertisement based on <li>
<t><bcp14>MUST</bcp14> trigger the S-PMSI A-D route advertisemen
t based on
the SFG configuration (and not based on the reception of the SFG configuration (and not based on the reception of
traffic).</t> traffic).</t>
</list></t> </li>
</ul>
<t>Distribution of DCB ESI-labels and G-source ES routes<vspace </li>
blankLines="1"/><list style="symbols"> <li>
<t>Upstream PEs advertise corresponding EVPN routes:<list <t>Distribution of DCB ESI labels and G-source ES routes</t>
style="symbols"> <ul spacing="normal">
<t>EVPN Ethernet Segment (ES) routes for the local S-ESIs. <li>
ES routes are used for regular Designated Forwarder <t>Upstream PEs advertise corresponding EVPN routes:</t>
<ul spacing="normal">
<li>
<t>EVPN ES routes for the local S-ESIs.
ES routes are used for regular DF
Election for the S-ES. This document does not introduce Election for the S-ES. This document does not introduce
any change in the procedures related to the EVPN ES any change in the procedures related to the EVPN ES
routes.</t> routes.</t>
</li>
<li>
<t>A-D per EVI and A-D per ES routes for tenant-specific <t>A-D per EVI and A-D per ES routes for tenant-specific
traffic. If the SBD exists, the EVPN A-D per EVI and A-D traffic. If the SBD exists, the EVPN A-D per EVI and A-D
per ES routes MUST include the route target SBD-RT since per ES routes <bcp14>MUST</bcp14> include the route target S BD-RT, since
they have to be imported by all the PEs in the tenant they have to be imported by all the PEs in the tenant
domain.</t> domain.</t>
</list></t> </li>
</ul>
<t>ESI Label Procedures:<list style="symbols"> </li>
<li>
<t>ESI label procedures:</t>
<ul spacing="normal">
<li>
<t>The EVPN A-D per ES routes convey the S-ESI labels that <t>The EVPN A-D per ES routes convey the S-ESI labels that
the downstream PEs use to implement Reverse Path the downstream PEs use to implement Reverse Path
Forwarding checks for SFGs.</t> Forwarding checks for SFGs.</t>
</li>
<t>All packets for a given G-source MUST carry the same <li>
<t>All packets for a given G-source <bcp14>MUST</bcp14> carr
y the same
S-ESI label. For example, if two redundant G-sources are S-ESI label. For example, if two redundant G-sources are
multi-homed to PE1 and PE2 via S-ES-1 and S-ES-2, PE1 and multi-homed to PE1 and PE2 via S-ES-1 and S-ES-2, PE1 and
PE2 MUST allocate the same ESI label "Lx" for S-ES-1 and PE2 <bcp14>MUST</bcp14> allocate the same ESI label "Lx" for
they MUST allocate the same ESI label "Ly" for S-ES-2. In S-ES-1, and
addition, Lx and Ly MUST be different.</t> they <bcp14>MUST</bcp14> allocate the same ESI label "Ly" fo
r S-ES-2. In
addition, Lx and Ly <bcp14>MUST</bcp14> be different.</t>
</li>
<li>
<t>S-ESI labels are allocated as Domain-wide Common Block <t>S-ESI labels are allocated as Domain-wide Common Block
(DCB) labels and follow the procedures in <xref (DCB) labels and follow the procedures in <xref target="RFC9
target="RFC9573"/>. In addition, the PE indicates that 573" format="default"/>. In addition, the PE indicates that
these ESI labels are DCB labels by using the extensions these ESI labels are DCB labels by using the extensions
described in <xref target="sect-5.2"/>.</t> described in <xref target="sect-5.2" format="default"/>.</t>
</list></t> </li>
</list></t> </ul>
</li>
</ul>
</li>
<li>
<t>Processing of EVPN A-D per ES/EVI routes and Reverse Path <t>Processing of EVPN A-D per ES/EVI routes and Reverse Path
Forwarding check on the downstream PEs<vspace blankLines="1"/>The Forwarding check on the downstream PEs</t>
<t>The
EVPN A-D per ES/EVI routes are received and imported in all the EVPN A-D per ES/EVI routes are received and imported in all the
PEs in the tenant domain. Downstream PEs process received EVPN A-D PEs in the tenant domain. Downstream PEs process received EVPN A-D
per ES/EVI routes based on their configuration: <list per ES/EVI routes based on their configuration: </t>
style="symbols"> <ul spacing="normal">
<li>
<t>The PEs attached to the same Broadcast Domain of the route <t>The PEs attached to the same Broadcast Domain of the route
target BD-RT that is included in the EVPN A-D per ES/EVI target BD-RT that is included in the EVPN A-D per ES/EVI
routes process the routes as in <xref target="RFC7432"/> and routes process the routes as in <xref target="RFC7432" format="d
<xref target="RFC8584"/>. If the receiving PE is attached to efault"/> and
the same Ethernet Segment as indicated in the route, <xref <xref target="RFC8584" format="default"/>. If the receiving PE i
target="RFC7432"/> split-horizon procedures are followed and s attached to
the Designated Forwarder Election candidate list is modified the same ES as indicated in the route, split-horizon procedures
as in <xref target="RFC8584"/> if the Ethernet Segment <xref target="RFC7432" format="default"/> are followed and
supports the AC-DF (Attachment Circuit influenced Designated the DF Election candidate list is modified
Forwarder) capability.</t> as in <xref target="RFC8584" format="default"/> if the ES
supports the AC-DF (AC influenced DF) capability.</t>
</li>
<li>
<t>The PEs that are not attached to the Broadcast Domain <t>The PEs that are not attached to the Broadcast Domain
identified by the route target BD-RT but are attached to the identified by the BD-RT but are attached to the
Supplementary Broadcast Domain of the received route target SBD of the received
SBD-RT, MUST import the EVPN A-D per ES/EVI routes and use SBD-RT <bcp14>MUST</bcp14> import the EVPN A-D per ES/EVI routes
and use
them for redundant G-source mass withdrawal, as explained them for redundant G-source mass withdrawal, as explained
later.</t> later.</t>
</li>
<li>
<t>Upon importing EVPN A-D per ES routes corresponding to <t>Upon importing EVPN A-D per ES routes corresponding to
different S-ESes, a PE MUST select a primary S-ES based on different S-ESes, a PE <bcp14>MUST</bcp14> select a primary S-ES based on
local policy, and add a Reverse Path Forwarding check to the local policy, and add a Reverse Path Forwarding check to the
(*,G) or (S,G) state in the Broadcast Domain or Supplementary (*,G) or (S,G) state in the Broadcast Domain or SBD.
Broadcast Domain. This Reverse Path Forwarding check discards This Reverse Path Forwarding check discards
all ingress packets to (*,G)/(S,G) that are not received with all ingress packets to (*,G)/(S,G) that are not received with
the ESI-label of the primary S-ES.</t> the ESI label of the primary S-ES.</t>
</list></t> </li>
</ul>
</li>
<li>
<t>G-traffic forwarding for redundant G-sources and fault <t>G-traffic forwarding for redundant G-sources and fault
detection<vspace blankLines="1"/><list style="symbols"> detection</t>
<t>Traffic Forwarding with S-ESI Labels:<list style="symbols"> <ul spacing="normal">
<li>
<t>Traffic forwarding with S-ESI labels:</t>
<ul spacing="normal">
<li>
<t>When there is an existing (*,G) or (S,G) state for the <t>When there is an existing (*,G) or (S,G) state for the
SFG with output interface list entries associated with SFG with output interface list entries associated with
remote EVPN PEs, the upstream PE will add an S-ESI label remote EVPN PEs, the upstream PE will add an S-ESI label
to the bottom of the stack when forwarding G-traffic to the bottom of the stack when forwarding G-traffic
received on an S-ES. This label is allocated from a received on an S-ES. This label is allocated from a
domain-wide common block as described in Step 3.</t> DCB as described in Step 3.</t>
</li>
<t>If Point-to-multipoint or BIER PMSIs are used, this <li>
<t>If point-to-multipoint or BIER PMSIs are used, this
procedure does not introduce new data path requirements on procedure does not introduce new data path requirements on
the upstream PEs, apart from allocating the S-ESI label the upstream PEs, apart from allocating the S-ESI label
from the domain-wide common block as per <xref from the DCB as per <xref target="RFC9573" format="default"/
target="RFC9573"/>). However, when Ingress Replication or >). However, when IR or AR
Assisted Replication are employed, this document extends are employed, this document extends
the procedures defined in <xref target="RFC7432"/>. In the procedures defined in <xref target="RFC7432" format="def
ault"/>. In
these scenarios, the upstream PE pushes the S-ESI labels these scenarios, the upstream PE pushes the S-ESI labels
on packets not only destinated for PEs sharing the ES but on packets not only destined for PEs sharing the ES but
also for all PEs within the tenant domain. This ensures also for all PEs within the tenant domain. This ensures
that downstream PEs receive all the multicast packets from that downstream PEs receive all the multicast packets from
the redundant G-sources with an S-ESI label, regardless of the redundant G-sources with an S-ESI label, regardless of
the PMSI type or local ESes. Downstream PEs will discard the PMSI type or local ESes. Downstream PEs will discard
any packet carrying an S-ESI label different from the any packet carrying an S-ESI label different from the
primary S-ESI label (associated with the selected primary primary S-ESI label (associated with the selected primary
S-ES), as outlined in Step 4.</t> S-ES), as outlined in Step 4.</t>
</list></t> </li>
</ul>
<t>Handling Route Withdrawals and Fault Detection<list </li>
style="symbols"> <li>
<t>Handling route withdrawals and fault detection</t>
<ul spacing="normal">
<li>
<t>If the last EVPN A-D per EVI or the last EVPN A-D per <t>If the last EVPN A-D per EVI or the last EVPN A-D per
ES route for the primary S-ES is withdrawn, the downstream ES route for the primary S-ES is withdrawn, the downstream
PE will immediately select a new primary S-ES and update PE will immediately select a new primary S-ES and update
the Reverse Path Forwarding check accordingly.</t> the Reverse Path Forwarding check accordingly.</t>
</li>
<li>
<t>For scenarios where the same S-ES is used across <t>For scenarios where the same S-ES is used across
multiple tenant domains by the upstream PEs, the multiple tenant domains by the upstream PEs, the
withdrawal of all the EVPN A-D per-ES routes associated withdrawal of all the EVPN A-D per-ES routes associated
with an S-ES enables a mass withdrawal mechanism. This with an S-ES enables a mass withdrawal mechanism. This
allows the downstream PE to simultaneously update the allows the downstream PE to simultaneously update the
Reverse Path Forwarding check for all tenant domains that Reverse Path Forwarding check for all tenant domains that
rely on the same S-ES.</t> rely on the same S-ES.</t>
</list></t> </li>
</ul>
<t>Removal of Reverse Path Forwarding Checks on S-PMSI </li>
Withdrawal<list style="symbols"> <li>
<t>Removal of Reverse Path Forwarding checks on S-PMSI
withdrawal</t>
<ul spacing="normal">
<li>
<t>The withdrawal of the last EVPN S-PMSI A-D route for a <t>The withdrawal of the last EVPN S-PMSI A-D route for a
given (*,G) or (S,G) that represents an SFG SHOULD result given (*,G) or (S,G) that represents an SFG <bcp14>SHOULD</b cp14> result
in the downstream PE removing the S-ESI label-based in the downstream PE removing the S-ESI label-based
Reverse Path Forwarding check for that (*,G) or (S,G).</t> Reverse Path Forwarding check for that (*,G) or (S,G).</t>
</list></t> </li>
</list></t> </ul>
</list></t> </li>
</ul>
</li>
</ol>
<t>This document supports the use of Context Label Space ID Extended <t>This document supports the use of Context-Specific Label Space ID Ext
Communities, as described in <xref target="RFC9573"/>, for scenarios ended
where S-ESI labels are allocated within context label spaces. When the Communities, as described in <xref target="RFC9573" format="default"/>,
context label space ID extended community is advertised along with the for scenarios
ESI label in an EVPN A-D per ES route, the ESI label is from a context where S-ESI labels are allocated within context-specific label spaces. W
label space identified by the Domain-wide Common Block (DCB) label in hen the
context-specific label space ID extended community is advertised along w
ith the
ESI label in an EVPN A-D per ES route, the ESI label is from a context-s
pecific
label space identified by the DCB label in
the Extended Community.</t> the Extended Community.</t>
</section> </section>
<section anchor="sect-5.2" numbered="true" toc="default">
<section anchor="sect-5.2" <name>Extensions for the Advertisement of DCB Labels</name>
title="Extensions for the Advertisement of DCB Labels"> <t>DCB labels are specified in <xref target="RFC9573" format="default"/>
<t>Domain-wide Common Block Labels are specified in <xref , and this document makes use of them as outlined in
target="RFC9573"/> and this document makes use of them as outlined in <xref target="sect-5.1" format="default"/>. <xref target="RFC9573" forma
<xref target="sect-5.1"/>. <xref target="RFC9573"/> assumes that t="default"/> assumes that
Domain-wide Common Block labels are applicable only to DCB labels are applicable only to
Multipoint-to-Multipoint, Point-to-Multipoint, or BIER tunnels. Multipoint-to-Multipoint, Point-to-Multipoint, or BIER tunnels.
Additionally, it specifies that when a PMSI label is a Domain-wide Additionally, it specifies that when a PMSI label is a
Common Block label, the ESI label used for multi-homing is also a DCB label, the ESI label used for multi-homing is also a
Domain-wide Common Block label.</t> DCB label.</t>
<t>This document extends the use of DCB-allocated ESI labels with the <t>This document extends the use of DCB-allocated ESI labels with the
following provisions: <list style="letters"> following provisions: </t>
<t>DCB-allocated ESI labels MAY be used with Ingress Replication <ol spacing="normal" type="a"><li>
tunnels, and</t> <t>DCB-allocated ESI labels <bcp14>MAY</bcp14> be used with IR
tunnels and</t>
<t>DCB-allocated ESI labels MAY be used by PEs that do not use </li>
<li>
<t>DCB-allocated ESI labels <bcp14>MAY</bcp14> be used by PEs that d
o not use
DCB-allocated PMSI labels.</t> DCB-allocated PMSI labels.</t>
</list>These control plane extensions are indicated in the EVPN A-D </li>
per ES routes for the relevant S-ESs by: <list style="numbers"> </ol>
<t>Adding the ESI-DCB-flag (Domain-wide Common Block flag) to the <t>These control plane extensions are indicated in the EVPN A-D
ESI Label Extended Community, or</t> per ES routes for the relevant S-ESes by: </t>
<ol spacing="normal" type="1"><li>
<t>Adding the Context Label Space ID extended community</t> <t>Adding the ESI-DCB-flag (DCB flag) to the
</list>The encoding of the DCB-flag within the ESI Label Extended ESI label Extended Community, or</t>
</li>
<li>
<t>Adding the Context-Specific Label Space ID extended community</t>
</li>
</ol>
<t>The encoding of the DCB-flag within the ESI Label Extended
Community is shown below:</t> Community is shown below:</t>
<figure anchor="ESI-label">
<t><figure anchor="ESI-label" title="ESI Label Extended Community"> <name>ESI Label Extended Community</name>
<artwork><![CDATA[ 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 | | Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | ESI Label | | Reserved=0 | ESI Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>This document defines the DCB-flag as follows: <list </figure>
style="symbols"> <t>This document defines the DCB-flag as follows: </t>
<ul spacing="normal">
<li>
<t>Bit 5 of the Flags octet in the ESI Label Extended Community is <t>Bit 5 of the Flags octet in the ESI Label Extended Community is
defined as the ESI-DCB-flag by this document.</t> defined as the ESI-DCB-flag by this document.</t>
</li>
<li>
<t>When the ESI-DCB-flag is set, it indicates that the ESI label <t>When the ESI-DCB-flag is set, it indicates that the ESI label
is a DCB label.</t> is a DCB label.</t>
</list></t> </li>
</ul>
<t>Criteria for identifying a DCB label:</t> <t>Criteria for identifying a DCB label:</t>
<t>An ESI label is considered a DCB label if either of the following <t>An ESI label is considered a DCB label if either of the following
conditions is met:</t> conditions is met:</t>
<ol spacing="normal" type="a"><li>
<t><list style="letters">
<t>The ESI label is encoded in an ESI Label Extended Community <t>The ESI label is encoded in an ESI Label Extended Community
with the ESI-DCB-flag set.</t> with the ESI-DCB-flag set.</t>
</li>
<li>
<t>The ESI label is signaled by a PE that has advertised a PMSI <t>The ESI label is signaled by a PE that has advertised a PMSI
label that is a DCB label.</t> label that is a DCB label.</t>
</list></t> </li>
</ol>
<t>As in <xref target="RFC9573"/> this document also permits the use <t>As in <xref target="RFC9573" format="default"/>, this document also p
of context label space ID extended community. When this extended ermits the use
of context-specific label space ID extended community. When this extende
d
community is advertised along with the ESI label in an EVPN A-D per ES community is advertised along with the ESI label in an EVPN A-D per ES
route, it indicates that the ESI label is from a context label space route, it indicates that the ESI label is from a context-specific label space
identified by the DCB label in the Extended Community.</t> identified by the DCB label in the Extended Community.</t>
</section> </section>
<section anchor="sect-5.3" numbered="true" toc="default">
<section anchor="sect-5.3" title="Use of BFD in the HS Solution"> <name>Use of BFD in the HS Solution</name>
<t>In addition to utilizing the state of the EVPN A-D per EVI, EVPN <t>In addition to utilizing the state of the EVPN A-D per EVI, EVPN
A-D per ES or S-PMSI A-D routes to adjust the Reverse Path Forwarding A-D per ES, or S-PMSI A-D routes to adjust the Reverse Path Forwarding
checks for (*,G) or (S,G) as discussed in <xref target="sect-5.1"/>, checks for (*,G) or (S,G) as discussed in <xref target="sect-5.1" format
the Bidirectional Forwarding Detection (BFD) protocol MAY be employed ="default"/>,
the Bidirectional Forwarding Detection (BFD) protocol <bcp14>MAY</bcp14>
be employed
to monitor the status of the multipoint tunnels used to forward the to monitor the status of the multipoint tunnels used to forward the
SFG packets from redundant G-sources.</t> SFG packets from redundant G-sources.</t>
<t>BFD integration:</t>
<t>BFD integration:<list style="symbols"> <ul spacing="normal">
<li>
<t>The BGP-BFD Attribute is advertised alongside the S-PMSI A-D or <t>The BGP-BFD Attribute is advertised alongside the S-PMSI A-D or
Inclusive Multicast Ethernet Tag routes, depending on whether IMET routes, depending on whether
Inclusive PMSI or Selective PMSI trees are being utilized.</t> Inclusive PMSI or Selective PMSI trees are being utilized.</t>
</li>
<t>The procedures outlined in <xref <li>
target="I-D.ietf-mpls-p2mp-bfd"/> are followed to bootstrap <t>The procedures outlined in <xref target="RFC9780" format="default
"/> are followed to bootstrap
multipoint BFD sessions on the downstream PEs.</t> multipoint BFD sessions on the downstream PEs.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="sect-5.4" numbered="true" toc="default">
<section anchor="sect-5.4" <name>Hot Standby Example in an OISM Network</name>
title="Hot Standby Example in an OISM Network"> <t>This section describes the Hot Standby model applied in an Optimized
<t>This section describes the Hot Standby model applied in an Inter-Subnet Multicast
Optimized Inter-Subnet Multicast (OISM) network. <xref (OISM) network. Figures <xref target="ure-hs-solution-for-multi-homed-re
target="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism"/> dundant-g-sources-in-oism" format="counter"/>
and <xref and <xref target="ure-hs-solution-for-single-homed-redundant-g-sources-i
target="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism"/> n-oism" format="counter"/>
illustrate scenarios with multi-homed and single-homed redundant illustrate scenarios with multi-homed and single-homed redundant
G-sources, respectively.</t> G-sources, respectively.</t>
<section anchor="sect-5.4.1" numbered="true" toc="default">
<section anchor="sect-5.4.1" title="Multi-Homed Redundant G-Sources"> <name>Multi-Homed Redundant G-Sources</name>
<t>Scenario (<xref <t>Scenario (<xref target="ure-hs-solution-for-multi-homed-redundant-g
target="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism"/> -sources-in-oism" format="default"/>):
): </t>
<list style="symbols"> <ul spacing="normal">
<li>
<t>S1 and S2 are redundant G-sources for the Single Flow Group <t>S1 and S2 are redundant G-sources for the Single Flow Group
(*,G1), connected to Broadcast Domain BD1.</t> (*,G1), connected to BD1.</t>
</li>
<li>
<t>S1 and S2 are all-active multi-homed to upstream PEs (PE1 and <t>S1 and S2 are all-active multi-homed to upstream PEs (PE1 and
PE2).</t> PE2).</t>
</li>
<li>
<t>Receivers are connected to downstream PEs (PE3 and PE5) in <t>Receivers are connected to downstream PEs (PE3 and PE5) in
Broadcast Domains BD3 and BD1, respectively.</t> BD3 and BD1, respectively.</t>
</li>
<li>
<t>S1 and S2 are connected to the multi-homing PEs using a LAG. <t>S1 and S2 are connected to the multi-homing PEs using a LAG.
Multicast traffic can traverse either link.</t> Multicast traffic can traverse either link.</t>
</li>
<li>
<t>In this model, downstream PEs receive duplicate G-traffic for <t>In this model, downstream PEs receive duplicate G-traffic for
(*,G1) and must use Reverse Path Forwarding checks to avoid (*,G1) and must use Reverse Path Forwarding checks to avoid
delivering duplicate packets to receivers.</t> delivering duplicate packets to receivers.</t>
</list></t> </li>
</ul>
<figure anchor="ure-hs-solution-for-multi-homed-redundant-g-sources-in <figure anchor="ure-hs-solution-for-multi-homed-redundant-g-sources-in
-oism" -oism">
title="HS Solution for Multi-homed Redundant G-Sources in OISM <name>Hot Standby Solution for Multi-Homed Redundant G-Sources in OI
"> SM</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
S1(ESI-1) S2(ESI-2) S1(ESI-1) S2(ESI-2)
| | | |
| +----------------------+ | +----------------------+
(S1,G1)| | (S2,G1)| (S1,G1)| | (S2,G1)|
+----------------------+ | +----------------------+ |
PE1 | | PE2 | | PE1 | | PE2 | |
+--------v---+ +--------v---+ +--------v---+ +--------v---+
| +---+ | | +---+ | S-PMSI | +---+ | | +---+ | S-PMSI
S-PMSI | +---|BD1| | | +---|BD1| | (*,G1) S-PMSI | +---|BD1| | | +---|BD1| | (*,G1)
(*,G1) | |VRF+---+ | | |VRF+---+ | SFG (*,G1) | |VRF+---+ | | |VRF+---+ | SFG
skipping to change at line 1482 skipping to change at line 1535
| |VRF+---+ | | |VRF+---+ | | | | |VRF+---+ | | |VRF+---+ | | |VRF+---+ | | | | |VRF+---+ |
|+---+ | | |+---+ | | | | |+---+ | | |+---+ | | |+---+ | | | | |+---+ | |
||BD3|--+ | ||BD4|--+ | | +->|BD1|--+ | ||BD3|--+ | ||BD4|--+ | | +->|BD1|--+ |
|+---+ | |+---+ | +--->+---+ | |+---+ | |+---+ | +--->+---+ |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| ^ | ^ | ^ | ^
| | IGMP/MLD | | IGMP/MLD | | IGMP/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1) R1 | J(*,G1) R3 | J(*,G1)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The procedure is as follows:</t> <t>The procedure is as follows:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>Configuration of the PEs:</t>
<t>Configuration of the PEs:<list style="symbols"> <ul spacing="normal">
<li>
<t>PE1 and PE2 are configured to recognize (*,G1) as a <t>PE1 and PE2 are configured to recognize (*,G1) as a
Single Flow Group.</t> Single Flow Group.</t>
</li>
<li>
<t>Redundant G-sources use S-ESIs: ESI-1 for S1 and ESI-2 <t>Redundant G-sources use S-ESIs: ESI-1 for S1 and ESI-2
for S2.</t> for S2.</t>
</li>
<t>The Ethernet Segments (ES-1 and ES-2) are configured on <li>
both PEs. ESI-labels are allocated from a Domain-wide Common <t>The ESes (ES-1 and ES-2) are configured on
Block (DCB) <xref target="RFC9573"/> - ESI-label-1 for ESI-1 both PEs. ESI labels are allocated from a
DCB <xref target="RFC9573" format="default"/> - ESI-label-1 fo
r ESI-1
and ESI-label-2 for ESI-2.</t> and ESI-label-2 for ESI-2.</t>
</li>
<t>The downstream PEs, PE3, PE4 and PE5 are configured to <li>
<t>The downstream PEs (PE3, PE4, and PE5) are configured to
support Hot Standby mode and select the G-source with, e.g., support Hot Standby mode and select the G-source with, e.g.,
lowest ESI value.</t> lowest ESI value.</t>
</list></t> </li>
</ul>
<t>Advertisement of the EVPN routes:<list style="symbols"> </li>
<li>
<t>Advertisement of the EVPN routes:</t>
<ul spacing="normal">
<li>
<t>PE1 and PE2 advertise S-PMSI A-D routes for (*,G1), <t>PE1 and PE2 advertise S-PMSI A-D routes for (*,G1),
including:<list style="symbols"> including:</t>
<ul spacing="normal">
<li>
<t>Route Targets: BD1-RT and SBD-RT.</t> <t>Route Targets: BD1-RT and SBD-RT.</t>
</li>
<li>
<t>ESI Label Extended Communities for ESI-label-1 and <t>ESI Label Extended Communities for ESI-label-1 and
ESI-label-2.</t> ESI-label-2.</t>
</li>
<li>
<t>The SFG flag indicating that (*,G1) represents a <t>The SFG flag indicating that (*,G1) represents a
Single Flow Group.</t> Single Flow Group.</t>
</list></t> </li>
</ul>
</li>
<li>
<t>EVPN ES and A-D per ES/EVI routes are also advertised for <t>EVPN ES and A-D per ES/EVI routes are also advertised for
ESI-1 and ESI-2. These include SBD-RT for downstream PE ESI-1 and ESI-2. These include SBD-RT for downstream PE
import. The EVPN A-D per ES routes contain ESI-label-1 for import. The EVPN A-D per ES routes contain ESI-label-1 for
ESI-1 (on both PEs) and ESI-label-2 for ESI-2 (also on both ESI-1 (on both PEs) and ESI-label-2 for ESI-2 (also on both
PEs).</t> PEs).</t>
</list></t> </li>
</ul>
</li>
<li>
<t>Processing of EVPN A-D per ES/EVI routes and Reverse Path <t>Processing of EVPN A-D per ES/EVI routes and Reverse Path
Forwarding check on Downstream PEs:<list style="symbols"> Forwarding check on downstream PEs:</t>
<ul spacing="normal">
<li>
<t>PE1 and PE2 receive each other's ES and A-D per ES/EVI <t>PE1 and PE2 receive each other's ES and A-D per ES/EVI
routes. Designated Forwarder Election and programming of the routes. DF Election and programming of the
ESI-labels for egress split-horizon filtering follow, as ESI labels for egress split-horizon filtering follow, as
specified in <xref target="RFC7432"/> and <xref specified in <xref target="RFC7432" format="default"/> and <xr
target="RFC8584"/>.</t> ef target="RFC8584" format="default"/>.</t>
</li>
<t>PE3/PE4 import the EVPN A-D per ES/EVI routes in the SBD, <li>
<t>PE3/PE4 import the EVPN A-D per ES/EVI routes in the SBD;
PE5 imports them in BD1.</t> PE5 imports them in BD1.</t>
</li>
<li>
<t>As downstream PEs, PE3 and PE5 use the EVPN A-D per <t>As downstream PEs, PE3 and PE5 use the EVPN A-D per
ES/EVI routes to program Reverse Path Forwarding checks.</t> ES/EVI routes to program Reverse Path Forwarding checks.</t>
</li>
<li>
<t>The primary S-ESI for (*,G1) is selected based on local <t>The primary S-ESI for (*,G1) is selected based on local
policy (e.g., lowest ESI value), and therefore packets with policy (e.g., lowest ESI value), and therefore packets with
ESI-label-2 are discarded if ESI-label-1 is selected as the ESI-label-2 are discarded if ESI-label-1 is selected as the
primary label.</t> primary label.</t>
</list></t> </li>
</ul>
<t>Traffic forwarding and fault detection:<list style="symbols"> </li>
<li>
<t>Traffic forwarding and fault detection:</t>
<ul spacing="normal">
<li>
<t>PE1 receives (S1,G1) traffic and forwards it with <t>PE1 receives (S1,G1) traffic and forwards it with
ESI-label-1 in the context of BD1. This traffic passes ESI-label-1 in the context of BD1. This traffic passes
Reverse Path Forwarding checks on downstream PEs (PE3 and Reverse Path Forwarding checks on downstream PEs (PE3 and
PE5, since PE4 has no local interested receivers) and is PE5, since PE4 has no local interested receivers) and is
delivered to receivers.</t> delivered to receivers.</t>
</li>
<li>
<t>PE2 receives (S2,G1) traffic and forwards it with <t>PE2 receives (S2,G1) traffic and forwards it with
ESI-label-2. This traffic fails the Reverse Path Forwarding ESI-label-2. This traffic fails the Reverse Path Forwarding
check on PE3 and PE5 and is discarded.</t> check on PE3 and PE5 and is discarded.</t>
</li>
<li>
<t>If the link between S1 and PE1 fails, PE1 withdraws the <t>If the link between S1 and PE1 fails, PE1 withdraws the
EVPN ES and A-D routes for ESI-1. S1 forwards the (S1,G1) EVPN ES and A-D routes for ESI-1. S1 forwards the (S1,G1)
traffic to PE2 instead. PE2 continues forwarding (S2,G1) traffic to PE2 instead. PE2 continues forwarding (S2,G1)
traffic using ESI-label-2 and now also forwards (S1,G1) with traffic using ESI-label-2 and now also forwards (S1,G1) with
ESI-label-1. The Reverse Path Forwarding checks do not ESI-label-1. The Reverse Path Forwarding checks do not
change in PE3/PE5.</t> change in PE3/PE5.</t>
</li>
<li>
<t>If all links to S1 fail, PE2 also withdraws the EVPN ES <t>If all links to S1 fail, PE2 also withdraws the EVPN ES
and A-D routes for ESI-1 and downstream PEs update the and A-D routes for ESI-1 and downstream PEs update the
Reverse Path Forwarding checks to accept ESI-label-2 Reverse Path Forwarding checks to accept ESI-label-2
traffic.</t> traffic.</t>
</list></t> </li>
</list></t> </ul>
</li>
</ol>
</section> </section>
<section anchor="sect-5.4.2" numbered="true" toc="default">
<section anchor="sect-5.4.2" title="Single-Homed Redundant G-Sources"> <name>Single-Homed Redundant G-Sources</name>
<t>Scenario (<xref <t>Scenario (<xref target="ure-hs-solution-for-single-homed-redundant-
target="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism"/ g-sources-in-oism" format="default"/>):</t>
>):<list <ul spacing="normal">
style="symbols"> <li>
<t>S1 is single-homed to PE1 using ESI-1, and S2 is single-homed <t>S1 is single-homed to PE1 using ESI-1, and S2 is single-homed
to PE2 using ESI-2.</t> to PE2 using ESI-2.</t>
</li>
<li>
<t>The scenario is a subset of the multi-homed case. Only one PE <t>The scenario is a subset of the multi-homed case. Only one PE
advertises EVPN A-D per ES/EVI routes for each S-ESI.</t> advertises EVPN A-D per ES/EVI routes for each S-ESI.</t>
</list></t> </li>
</ul>
<figure anchor="ure-hs-solution-for-single-homed-redundant-g-sources-i <figure anchor="ure-hs-solution-for-single-homed-redundant-g-sources-i
n-oism" n-oism">
title="HS Solution for single-homed Redundant G-Sources in OIS <name>HS Solution for Single-Homed Redundant G-Sources in OISM</name
M"> >
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
S1(ESI-1) S2(ESI-2) S1(ESI-1) S2(ESI-2)
| | | |
(S1,G1)| (S2,G1)| (S1,G1)| (S2,G1)|
| | | |
PE1 | PE2 | PE1 | PE2 |
+--------v---+ +--------v---+ +--------v---+ +--------v---+
| +---+ | | +---+ | S-PMSI | +---+ | | +---+ | S-PMSI
S-PMSI | +---|BD1| | | +---|BD2| | (*,G1) S-PMSI | +---|BD1| | | +---|BD2| | (*,G1)
(*,G1) | |VRF+---+ | | |VRF+---+ | SFG (*,G1) | |VRF+---+ | | |VRF+---+ | SFG
SFG |+---+ | | | |+---+ | | | ESI2 SFG |+---+ | | | |+---+ | | | ESI2
skipping to change at line 1616 skipping to change at line 1698
| |VRF+---+ | | |VRF+---+ | | | |VRF+---+ | | |VRF+---+ | | |VRF+---+ | | | |VRF+---+ |
|+---+ | | |+---+ | | | |+---+ | | |+---+ | | |+---+ | | | |+---+ | |
||BD3|--+ | ||BD4|--+ | +--->|BD1|--+ | ||BD3|--+ | ||BD4|--+ | +--->|BD1|--+ |
|+---+ | |+---+ | |+---+ | |+---+ | |+---+ | |+---+ |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| ^ | ^ | ^ | ^
| | IGMP/MLD | | IGMP/MLD | | IGMP/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1) R1 | J(*,G1) R3 | J(*,G1)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The procedures follow the same logic as described in the <t>The procedures follow the same logic as described in the
multi-homed scenario, with the distinction that each ESI is specific multi-homed scenario, with the distinction that each ESI is specific
to a single PE.</t> to a single PE.</t>
<t>Figures <xref target="ure-hs-solution-for-multi-homed-redundant-g-s
<t><xref ources-in-oism" format="counter"/>
target="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism"/> and <xref target="ure-hs-solution-for-single-homed-redundant-g-sources
and <xref -in-oism" format="counter"/>
target="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism"/
>
demonstrate the application of the Hot Standby solution, ensuring demonstrate the application of the Hot Standby solution, ensuring
seamless traffic forwarding while avoiding duplication in the seamless traffic forwarding while avoiding duplication in the
presence of redundant G-sources.</t> presence of redundant G-sources.</t>
</section> </section>
</section> </section>
<section anchor="sect-5.5" numbered="true" toc="default">
<section anchor="sect-5.5" <name>Hot Standby Example in a Single-BD Tenant Network</name>
title="Hot Standby Example in a Single-BD Tenant Network"> <t>The Hot Standby procedures described in <xref target="sect-5.4" forma
<t>The Hot Standby procedures described in <xref target="sect-5.4"/> t="default"/>
apply equally to scenarios where the tenant network comprises a single apply equally to scenarios where the tenant network comprises a single
Broadcast Domain (e.g., BD1), irrespective of whether the redundant Broadcast Domain (e.g., BD1), irrespective of whether the redundant
G-sources are multi-homed or single-homed. In such cases:<list G-sources are multi-homed or single-homed. In such cases:</t>
style="symbols"> <ul spacing="normal">
<t>The advertised routes do not include the Supplementary <li>
Broadcast Domain Route Target (SBD-RT).</t> <t>The advertised routes do not include the SBD-RT.</t>
</li>
<t>All procedures are confined to the single Broadcast Domain <li>
(BD1).</t> <t>All procedures are confined to the single BD1.</t>
</list>The absence of the SBD simplifies the configuration and </li>
</ul>
<t>The absence of the SBD simplifies the configuration and
limits the scope of the Hot Standby solution to BD1, while maintaining limits the scope of the Hot Standby solution to BD1, while maintaining
the integrity of the procedures for managing redundant G-sources.</t> the integrity of the procedures for managing redundant G-sources.</t>
</section> </section>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default">
<section anchor="sect-6" title="Security Considerations"> <name>Security Considerations</name>
<t>The same Security Considerations described in <xref <t>The same Security Considerations described in <xref target="RFC9625" fo
target="RFC9625"/> are valid for this document.</t> rmat="default"/> are valid for this document.</t>
<t>From a security perspective, out of the two methods described in this <t>From a security perspective, out of the two methods described in this
document, the Warm Standby method is considered lighter in terms of document, the Warm Standby method is considered lighter in terms of
control plane and therefore its impact is low on the processing control plane, and therefore its impact is low on the processing
capabilities of the PEs. The Hot Standby method adds more burden on the capabilities of the PEs. The Hot Standby method adds more burden on the
control plane of all the PEs of the tenant with sources and control plane of all the PEs of the tenant with sources and
receivers.</t> receivers.</t>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default">
<section anchor="sect-7" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA is requested to allocate bit 4 in the Multicast Flags Extended <t>IANA has allocated bit 4 in the "Multicast Flags Extended
Community registry that was introduced by <xref target="RFC9251"/>. This Community" registry that was introduced by <xref target="RFC9251" format="
default"/>. This
bit indicates that a given (*,G) or (S,G) in an S-PMSI A-D route is bit indicates that a given (*,G) or (S,G) in an S-PMSI A-D route is
associated with an SFG. This bit is called "Single Flow Group" bit and associated with an SFG. This bit is called "Single Flow Group" bit, and
it is defined as follows:</t> it is defined as follows:</t>
<table align="center" anchor="sfg">
<thead>
<tr>
<th align="left">Bit</th>
<th align="left">Name</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">4</td>
<td align="left">Single Flow Group</td>
<td align="left">This Document</td>
</tr>
</tbody>
</table>
<texttable> <t>IANA has allocated bit 5 in the "EVPN ESI Label Extended Community Flag
<ttcol>Bit</ttcol> s" registry that was introduced by <xref target="RFC9746" format="default"/>. Th
is bit is the ESI-DCB
<ttcol>Name</ttcol>
<ttcol>Reference</ttcol>
<c>4</c>
<c>Single Flow Group</c>
<c>This Document</c>
</texttable>
<t>IANA is requested to allocate bit 5 in the ESI Label Extended
Community Flags registry that was introduced by <xref
target="I-D.ietf-bess-evpn-mh-split-horizon"/>. This bit is the ESI-DCB
flag and indicates that the ESI label contained in the ESI Label flag and indicates that the ESI label contained in the ESI Label
Extended Community is a Domain-wide Common Block label. This bit is Extended Community is a DCB label. This bit is
defined as follows:</t> defined as follows:</t>
<texttable> <table align="center">
<ttcol>Bit</ttcol> <thead>
<tr>
<ttcol>Name</ttcol> <th align="left">Bit</th>
<th align="left">Name</th>
<ttcol>Reference</ttcol> <th align="left">Reference</th>
</tr>
<c>5</c> </thead>
<tbody>
<c>ESI-DCB Flag</c> <tr>
<td align="left">5</td>
<c>This Document</c> <td align="left">ESI-DCB</td>
</texttable> <td align="left">This Document</td>
</section> </tr>
</tbody>
<section title="Acknowledgments"> </table>
<t>The authors would like to thank Mankamana Mishra, Ali Sajassi, Greg
Mirsky and Sasha Vainshtein for their review and valuable comments.
Special thanks to Gunter van de Velde for his excellent review, which
significantly enhanced the document&rsquo;s readability.</t>
</section>
<section anchor="sect-9" title="Contributors">
<t>In addition to the authors listed on the front page, the following
people have significantly contributed to this document:</t>
<t>Eric C. Rosen</t>
<t>Email: erosen52@gmail.com</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
&RFC7432; <name>References</name>
<references>
&RFC6513; <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
&RFC6514; 432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
&RFC9251; 513.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
&RFC9625; 514.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
&RFC8584; 251.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
&RFC2119; 625.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&RFC8174; 584.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC9573; 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&I-D.ietf-bess-evpn-mh-split-horizon; 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
573.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
746.xml"/>
</references>
<references>
<name>Informative References</name>
<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
572.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
785.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
780.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
761.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
776.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
777.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
574.xml"/>
</references>
</references> </references>
<references title="Informative References"> <section numbered="false" toc="default">
&RFC9136; <name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Mankamana
&RFC9572; Mishra"/>, <contact fullname="Ali Sajassi"/>, <contact fullname="Greg
Mirsky"/>, and <contact fullname="Sasha Vainshtein"/> for their review
&I-D.ietf-bess-evpn-pref-df; and valuable comments. Special thanks to <contact fullname="Gunter Van
de Velde"/> for his excellent review, which significantly enhanced the
&RFC4364; document's readability.</t>
</section>
&I-D.ietf-mpls-p2mp-bfd; <section anchor="sect-9" numbered="false" toc="default">
<name>Contributors</name>
&RFC7761; <t>In addition to the authors listed on the front page, the following
person has significantly contributed to this document:</t>
&RFC9135;
&RFC3376;
&RFC3810; <contact fullname="Eric C. Rosen">
<address>
<email>erosen52@gmail.com</email>
</address>
</contact>
&RFC8296; </section>;
&RFC9574;
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 262 change blocks. 
1057 lines changed or deleted 1229 lines changed or added

This html diff was produced by rfcdiff 1.48.