Diff: rfc9856xml2.original.xml

	rfc9856xml2.original.xml	rfc9856.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	<!DOCTYPE rfc [
	<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	<!ENTITY nbsp " ">
	C.7432.xml">	<!ENTITY zwsp "">
	<!ENTITY RFC6513 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	<!ENTITY nbhy "‑">
	C.6513.xml">	<!ENTITY wj "⁠">
	<!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"?>	<!-- [rfced] Would you like the references to be alphabetized
		or left in their current order?
	<?rfc compact="yes"?>	-->

	<?rfc subcompact="no"?>

	<?rfc symrefs="yes"?>

	<?rfc sortrefs="no"?>

	<?rfc text-list-symbols="o*+?>


	<?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="false" 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="August" year="2025"/>
		<area>RTG</area>
		<workgroup>bess</workgroup>


	<date day="14" month="February" year="2025"/>	<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->


	<workgroup>BESS Workgroup</workgroup>	<keyword>example</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 Multicasts (PIMs) <xref target="RFC7761" format="default"/> or
	(MVPN) <xref target="RFC6513"/>, a workaround is to configure all	Multicast Virtual Private Networks
		(MVPNs) <xref target="RFC6513" format="default"/>, a workaround is to conf
		igure 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 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 may be
	broadcasts. In this document, BD also refers to the instantiation	multi-homed (attached to more than one PE). An Ethernet Segment 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	<!-- [rfced] We have removed "(IP DA)" as the abbreviation does not seem to be u
	of the PEs attached to the segment becomes that EVI's DF for that	sed in this document. DA (by itself) also does not appear. Elsewhere, the text
	segment. Since a BD may belong to only one EVI, we can speak	refers to "destination IP address". Are these the same? Should the definition
	unambiguously of the BD's DF for a given segment.</t>	for G-traffic be updated for consistency?

	<t>Downstream PE: in this document a Downstream PE is referred to
	as the EVPN PE that is connected to the IP Multicast receivers and
	gets the IP Multicast flows from remote EVPN PEs.</t>

	<t>EVI: EVPN Instance.</t>

	<t>G-traffic: any frame with an IP payload whose IP Destination
	Address (IP DA) is a multicast group G.</t>

	<t>G-source: any system sourcing IP multicast traffic to group
	G.</t>

	<t>Hot Standby Redundancy: multicast source redundancy procedure
	defined in this document, by which the upstream PEs forward the
	redundant multicast flows to the downstream PEs, and the
	downstream PEs make sure only one flow is forwarded to the
	interested attached receivers.</t>

	<t>IGMP: Internet Group Management Protocol <xref
	target="RFC3376"/>.</t>

	<t>Inclusive Multicast Tree or Inclusive Provider Multicast
	Service Interface (I-PMSI): defined in <xref target="RFC6513"/>,
	in this document it is applicable only to EVPN 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 the BD. The
	I-PMSI trees are signaled by EVPN Inclusive Multicast Ethernet Tag
	(IMET) routes.</t>

	<t>IMET route: EVPN Inclusive Multicast Ethernet Tag route, as in
	<xref target="RFC7432"/>.</t>

	<t>MLD: Multicast Listener Discovery <xref target="RFC3810"/>.</t>

	<t>MVPN: Multicast Virtual Private Networks, as in <xref
	target="RFC6513"/>.</t>

	<t>OISM: Optimized Inter-Subnet Multicast, as in <xref
	target="RFC9625"/>.</t>

	<t>PE: Provider Edge.</t>

	<t>PIM: Protocol Independent Multicast, as in <xref
	target="RFC7761"/>.</t>

	<t>P-tunnel: The term "Provider tunnel" refers to the type of tree
	employed by an upstream EVPN PE to forward multicast traffic to
	downstream PEs. The P-tunnels supported in this document include
	Ingress Replication (IR), Assisted Replication (AR) <xref
	target="RFC9574"/>, Bit Indexed Explicit Replication (BIER) <xref
	target="RFC8296"/>, multicast Label Distribution Protocol (mLDP),
	and Point-to-Multi-Point Resource Reservation Protocol with
	Traffic Engineering extensions (P2MP RSVP-TE).</t>

	<t>Redundant G-source: A host or router transmitting a Single Flow
	Group (SFG) within a tenant network, where multiple hosts or
	routers are also transmitting the same SFG. Redundant G-sources
	transmitting the same SFG should have distinct IP addresses;
	however, they may share the same IP address if located in
	different Broadcast Domains (BDs) within the same tenant network.
	For the purposes of this document, redundant G-sources are assumed
	not to exhibit "bursty" traffic behavior.</t>

	<t>S-ES and S-ESI: multicast Source Ethernet Segment and multicast
	Source Ethernet Segment Identifier. The Ethernet Segment and
	Ethernet Segment Identifier associated to a G-source.</t>

	<t>Selective Multicast Tree or Selective Provider Multicast
	Service Interface (S-PMSI): As defined in <xref
	target="RFC6513"/>, this term refers to a multicast tree to which
	only the PEs interested in a specific Broadcast Domain (BD)
	belong. In the context of this document, it is specific to EVPN.
	Two types of EVPN S-PMSIs are supported:<list style="symbols">
	<t>S-PMSIs with Auto-Discovery Routes: These S-PMSIs require
	the upstream PE to advertise S-PMSI Auto-Discovery (S-PMSI
	A-D) routes, as described in <xref target="RFC9572"/>.
	Downstream PEs interested in the multicast traffic join the
	S-PMSI tree following the procedures specified in <xref
	target="RFC9572"/>.</t>

	<t>S-PMSIs without Auto-Discovery Routes: These S-PMSIs do not
	require the advertisement of S-PMSI A-D routes. Instead, they
	rely on the forwarding information provided by Inclusive
	Multicast Ethernet Tag (IMET) routes. Upstream PEs forward IP
	multicast flows only to downstream PEs that advertise
	Selective Multicast Ethernet Tag (SMET) routes for the
	specific flow. These S-PMSIs are supported exclusively with
	the following P-tunnel types: Ingress Replication (IR),
	Assisted Replication (AR), and Bit Indexed Explicit
	Replication (BIER).</t>
	</list></t>

	<t>SFG (Single Flow Group): A multicast group that represents
	traffic containing a single flow. Multiple sources, which may have
	the same or different IP addresses, can transmit traffic for an
	SFG. An SFG can be represented in two forms: <list style="symbols">
	<t>(*,G): Indicates that any source transmitting multicast
	traffic to group G is considered a redundant G-source for the
	SFG.</t>

	<t>(S,G): Indicates that S is a prefix of any length. In this
	representation, a source is deemed a redundant G-source for
	the SFG if its address matches the specified prefix S.</t>
	</list></t>


	<t>SMET route: Selective Multicast Ethernet Tag route, as in <xref	Original:
	target="RFC9251"/>.</t>	* G-traffic: any frame with an IP payload whose IP Destination
		Address (IP DA) is a multicast group G.


	<t>(S,G) and (*,G): used to describe multicast packets or	Perhaps:
	multicast state. S stands for Source (IP address of the multicast	G-traffic: Any frame with an IP payload whose destination IP address
	traffic) and G stands for the Group or multicast destination IP	is a multicast group G.
	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	<dt>G-traffic:</dt><dd>Any frame with an IP payload whose IP
	mechanism defined in this document, wherein the upstream PEs	Destination Address is a multicast group G.</dd>
	connected to redundant sources within the same tenant ensure that	<dt>G-source:</dt><dd>Any system sourcing IP multicast traffic to
	only one source of a given flow transmits multicast traffic to the	group G.</dd>
	interested downstream PEs at any given time.</t>	<dt>Hot Standby Redundancy:</dt><dd>The multicast source redundancy
	</list></t>	procedure defined in this document, by which the upstream PEs
		forward the redundant multicast flows to the downstream PEs, and the
		downstream PEs make sure only one flow is forwarded to the
		interested attached receivers.</dd>
		<dt>IGMP:</dt><dd>Internet Group Management Protocol <xref
		target="RFC3376" format="default"/>.</dd>
		<dt>I-PMSI:</dt><dd>Inclusive Multicast Tree or Inclusive Provider Mul
		ticast Service Interface. While defined in <xref target="RFC6513"
		format="default"/>, in this document it is only applicable to EVPN
		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
		the BD. The I-PMSI trees are signaled by EVPN Inclusive Multicast
		Ethernet Tag (IMET) routes.</dd>
		<dt>IMET route:</dt><dd>EVPN Inclusive Multicast Ethernet Tag route,
		as in <xref target="RFC7432" format="default"/>.</dd>
		<dt>MLD:</dt><dd>Multicast Listener Discovery <xref target="RFC3810"
		format="default"/>.</dd>
		<dt>MVPN:</dt><dd>Multicast Virtual Private Networks, as in <xref
		target="RFC6513" format="default"/>.</dd>
		<dt>OISM:</dt><dd>Optimized Inter-Subnet Multicast, as in <xref
		target="RFC9625" format="default"/>.</dd>
		<dt>PE:</dt><dd>Provider Edge.</dd>
		<dt>PIM:</dt><dd>Protocol Independent Multicast, as in <xref
		target="RFC7761" format="default"/>.</dd>
		<dt>P-tunnel:</dt><dd>The term "Provider tunnel" refers to the type
		of tree employed by an upstream EVPN PE to forward multicast traffic
		to downstream PEs. The P-tunnels supported in this document include
		Ingress Replication (IR), Assisted Replication (AR) <xref
		target="RFC9574" format="default"/>, Bit Indexed Explicit
		Replication (BIER) <xref target="RFC8296" format="default"/>,
		multicast Label Distribution Protocol (mLDP), and
		Point-to-Multipoint (P2MP) RSVP - Traffic Engineering (RSVP-TE)
		extensions.</dd>
		<dt>Redundant G-source:</dt><dd>A host or router transmitting a
		Single Flow Group (SFG) within a tenant network, where multiple
		hosts or routers are also transmitting the same SFG. Redundant
		G-sources transmitting the same SFG should have distinct IP
		addresses; however, they may share the same IP address if located in
		different Broadcast Domains (BDs) within the same tenant network.
		For the purposes of this document, redundant G-sources are assumed
		to not exhibit "bursty" traffic behavior.</dd>
		<dt>S-ES and S-ESI:</dt><dd>Multicast Source Ethernet Segment and
		multicast Source Ethernet Segment Identifier. The Ethernet Segment
		and Ethernet Segment Identifier associated to a G-source.</dd>
		<dt>S-PMSI:</dt><dd><t>Selective Multicast Tree or Selective Provider
		Multicast Service Interface. As defined in <xref target="RFC6513"
		format="default"/>, this term refers to a multicast tree to which
		only the PEs interested in a specific Broadcast Domain
		belong. In the context of this document, it is specific to EVPN.
		Two types of EVPN S-PMSIs are supported:</t>
		<dl spacing="normal" newline="false">
		<dt>S-PMSIs with Auto-Discovery routes:</dt><dd>These S-PMSIs
		require the upstream PE to advertise S-PMSI Auto-Discovery
		(S-PMSI A-D) routes, as described in <xref target="RFC9572"
		format="default"/>. Downstream PEs interested in the multicast
		traffic join the S-PMSI tree following the procedures specified
		in <xref target="RFC9572" format="default"/>.</dd>
		<dt>S-PMSIs without Auto-Discovery Routes:</dt><dd>These S-PMSIs
		do not require the advertisement of S-PMSI A-D routes. Instead,
		they rely on the forwarding information provided by
		Inclusive Multicast Ethernet Tag (IMET) routes. Upstream PEs forwa
		rd IP
		multicast flows only to downstream PEs that advertise
		Selective Multicast Ethernet Tag (SMET) routes for the specific
		flow. These S-PMSIs are supported exclusively with the following
		P-tunnel types: Ingress Replication (IR), Assisted Replication (AR
		), and Bit Indexed Explicit Replication (BIER).</dd>
		</dl>
		</dd>
		<dt>SFG:</dt><dd><t>Single Flow Group. A multicast group that
		represents traffic containing a single flow. Multiple sources, which
		may have the same or different IP addresses, can transmit traffic
		for an SFG. An SFG can be represented in two forms:</t>
		<dl spacing="normal" newline="false">
		<dt>(*,G):</dt><dd>Indicates that any source transmitting
		multicast traffic to group G is considered a redundant G-source
		for the SFG.</dd>
		<dt>(S,G):</dt><dd>Indicates that S is a prefix of any
		length. In this representation, a source is deemed a redundant
		G-source for the SFG if its address matches the specified prefix
		S.</dd>
		</dl>
		</dd>
		<dt>SMET route:</dt><dd>Selective Multicast Ethernet Tag route, as
		in <xref target="RFC9251" format="default"/>.</dd>
		<dt>(S,G) and (*,G):</dt><dd>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".</dd>
		<dt>Upstream PE:</dt><dd>In this document, an Upstream PE refers to
		either the EVPN PE that is directly connected to the IP multicast
		source or the PE closest to the source. The Upstream PE receives
		IP multicast flows through local Attachment Circuits (ACs).</dd>
		<dt>Warm Standby Redundancy:</dt><dd>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.</dd>
		</dl>

	<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 357 ¶
	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
	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 "Ingress Replication (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)"	"Selective Multicast Ethernet Tag (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., Assisted
	flow.</t>	Replication (AR) or Bit Indexed Explicit Replication (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"/>.</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 432 ¶
	\|+-\|-+\| \|+-\|-+\| \|+---+\| \|+-\|-+\| \|+-\|-+\| \|+---+\|	\|+-\|-+\| \|+-\|-+\| \|+---+\| \|+-\|-+\| \|+-\|-+\| \|+---+\|
	+--\|--+ +--\|--+ +-----+ +--\|--+ +--\|--+ +-----+	+--\|--+ +--\|--+ +-----+ +--\|--+ +--\|--+ +-----+
	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 Attachment Circuits,

	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 Selective Multicast Ethernet Tag (SME
	(SMET) routes. If the P-tunnel type is "Ingress Replication	T)
	(IR)", "Assisted Replication (AR)", or "Bit Indexed Explicit	routes. If the P-tunnel type is "Ingress Replication (IR)", "A
	Replication (BIER)", PE1 does not need to advertise an	ssisted
		Replication (AR)", or "Bit Indexed Explicit 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 Ethernet Segment. <xref target=
	target="ure-all-active-multi-homing-and-oism"/> illustrates this	"ure-all-active-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 Ethernet Segment (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 533 ¶
	+--------------\| \|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 Ethernet Segment 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 Ethernet Segments <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 Ethernet Segment 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 Ethernet Segments.</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. The use of variable-length prefixes
	in source advertisements via S-PMSI A-D routes is permitted in this	in source advertisements via S-PMSI A-D routes is permitted in this
	document only for the specific application of redundant G-sources.</t>	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 Behavior: A non-Single Forwarder
	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 Attachment Circuit.</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>	Attachment Circuit for the SFG. If packets are received on multiple
		local Attachment Circuits, the Single Forwarder discards packets on
		all but one. The selection of the Attachment Circuit 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 Ethernet Segment Identifier (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 Attachment Circuits 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
		-PMSI A-D
		route:</t>
		<ul spacing="normal">
		<li>
		<t>Route Targets (RTs): The Supplementary Broadcast Domain
	Route Target (SBD-RT), if applicable, and the Broadcast	Route Target (SBD-RT), if applicable, and the Broadcast
	Domain Route Target (BD-RT) of the Broadcast Domain	Domain Route Target (BD-RT) of the Broadcast Domain
	receiving the traffic. The SBD-RT is needed so that the	receiving the traffic. The SBD-RT is needed so that the
	route is imported by all PEs attached to the tenant domain	route is imported by all PEs attached to the tenant domain
	in an OISM solution.</t>	in an OISM solution.</t>

		</li>
	<t>Multicast Flags Extended Community: that MUST include	<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 Designated Forwarder
	</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 Ingress Replicat
		ion (IR), Assisted Replication (AR), or Bit Indexed Explicit Replication (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 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>
		<t>Non-Single Forwarder PEs: <bcp14>MUST</bcp14> discard all (*,
		G) or (S,G)
	packets received on local Attachment Circuits.</t>	packets received on local Attachment Circuits.</t>

		</li>
	<t>Single Forwarder PEs: MUST forward (*,G) or (S,G) packets	<li>
		<t>Single Forwarder PEs: <bcp14>MUST</bcp14> forward (*,G) or (S
		,G) packets
	received on one (and only one) local Attachment Circuit.</t>	received on one (and only one) local Attachment Circuit.</t>

	</list></t>	</li>
	</list></t>	</ol>
		</li>
	<t>Key Features of the Warm Standby Solution:<list style="symbols">	</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>
		<li>
	<t>Existing procedures for non-SFG G-sources remain unchanged.</t>	<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 978 ¶
	\| \|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
		Attachment Circuit:</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 Supplementary Broadcast Domain Route Target (SBD-RT),
	<t>The Designated Forwarder Election Extended Community,	</t>
		</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>
		<ol spacing="normal" type="a"><li>
	<t>Non-Single Forwarder Behavior: PE2 discards all (*,G1)	<t>Non-Single Forwarder Behavior: PE2 discards all (*,G1)
	packets received on its local Attachment Circuit.</t>	packets received on its local Attachment Circuit.</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 Attachment Circuit.</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>
		<li>
	<t>In the event of a failure of S1, the Attachment Circuit	<t>In the event of a failure of S1, the Attachment Circuit
	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>	Supplementary Broadcast Domain (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 1108 ¶
	\| +---+ \| \| +---+ \| \| +---+ \|	\| +---+ \| \| +---+ \| \| +---+ \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	+------------+ +------------+ +------------+	+------------+ +------------+ +------------+
	\| ^ \| ^	\| ^ \| ^
	\| \| 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 Supplementary Broadcast Domain (SBD
	(SBD) in this scenario.</t>	)
	</list></t>	in this scenario.</t>
	</list></t>	</li>
		</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 Ethernet Segment
		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 Ethernet Segment Identifiers) 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 Ethernet Segments</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 Supplementary Broadcast Domain Route Target
	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>
		<t>Upstream PEs advertise corresponding EVPN routes:</t>
		<ul spacing="normal">
		<li>
		<t>EVPN Ethernet Segment routes for the local S-ESIs.
	ES routes are used for regular Designated Forwarder	ES routes are used for regular Designated Forwarder
	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 same Ethernet Segment as indicated in the route, split-horiz
		on procedures <xref target="RFC7432" format="default"/> are followed and
	the Designated Forwarder Election candidate list is modified	the Designated Forwarder Election candidate list is modified

	as in <xref target="RFC8584"/> if the Ethernet Segment	as in <xref target="RFC8584" format="default"/> if the Ethernet
	supports the AC-DF (Attachment Circuit influenced Designated	Segment
	Forwarder) capability.</t>	supports the AC-DF (Attachment Circuit influenced Designated For
		warder) 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	Supplementary Broadcast Domain 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 Supplementary Br
	Broadcast Domain. This Reverse Path Forwarding check discards	oadcast Domain.
		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>	domain-wide common block as described in Step 3.</t>

		</li>
		<li>
		<!-- [rfced] Should "destinated" be "destined?


	<t>If Point-to-multipoint or BIER PMSIs are used, this	Original:
		In these scenarios, the upstream PE pushes
		the S-ESI labels on packets not only destinated for PEs
		sharing the ES but also for all PEs within the tenant
		domain.
		-->
		<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 domain-wide common block as per <xref target="RFC95
	target="RFC9573"/>). However, when Ingress Replication or	73" format="default"/>). However, when Ingress Replication or Assisted Replicati
	Assisted Replication are employed, this document extends	on
	the procedures defined in <xref target="RFC7432"/>. In	are employed, this document extends
		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 destinated 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>
		</li>
		<li>
	<t>Removal of Reverse Path Forwarding Checks on S-PMSI	<t>Removal of Reverse Path Forwarding Checks on S-PMSI

	Withdrawal<list style="symbols">	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>

		<!-- [rfced] Since RFC 9573 uses the term "Context-Specific Label Space ID
		Extended Community" rather than "Context Label Space ID Extended
		Community", may we update to match? Note this would also update the
		following terms to the term on the right:


		context label spaces > context-specific label spaces
		context label space ID > context-specific label space ID
		-->
	<t>This document supports the use of Context Label Space ID Extended	<t>This document supports the use of Context Label Space ID Extended

	Communities, as described in <xref target="RFC9573"/>, for scenarios	Communities, as described in <xref target="RFC9573" format="default"/>, for scenarios
	where S-ESI labels are allocated within context label spaces. When the	where S-ESI labels are allocated within context label spaces. When the
	context label space ID extended community is advertised along with the	context label space ID extended community is advertised along with the
	ESI label in an EVPN A-D per ES route, the ESI label is from a context	ESI label in an EVPN A-D per ES route, the ESI label is from a context
	label space identified by the Domain-wide Common Block (DCB) label in	label space identified by the Domain-wide Common Block (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>Domain-wide Common Block labels are specified in <xref target="RFC957
	<t>Domain-wide Common Block Labels are specified in <xref	3" format="default"/>, 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	Domain-wide Common Block 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	Domain-wide Common Block label, the ESI label used for multi-homing is a
		lso a
	Domain-wide Common Block label.</t>	Domain-wide Common Block 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 Ingress
		Replication
	<t>DCB-allocated ESI labels MAY be used by PEs that do not use	tunnels and</t>
		</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>These control plane extensions are indicated in the EVPN A-D
		per ES routes for the relevant S-ESs by: </t>
		<ol spacing="normal" type="1"><li>
	<t>Adding the ESI-DCB-flag (Domain-wide Common Block flag) to the	<t>Adding the ESI-DCB-flag (Domain-wide Common Block flag) to the
	ESI Label Extended Community, or</t>	ESI Label Extended Community, or</t>

		</li>
		<li>
	<t>Adding the Context Label Space ID extended community</t>	<t>Adding the Context Label Space ID extended community</t>

	</list>The encoding of the DCB-flag within the ESI Label Extended	</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
		ermits the use
	of context label space ID extended community. When this extended	of context label space ID extended community. When this extended
	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 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	Inclusive Multicast Ethernet Tag 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 1563 ¶
	\| \|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>
		<li>
	<t>The Ethernet Segments (ES-1 and ES-2) are configured on	<t>The Ethernet Segments (ES-1 and ES-2) are configured on

	both PEs. ESI-labels are allocated from a Domain-wide Common	both PEs. ESI labels are allocated from a Domain-wide Common B
	Block (DCB) <xref target="RFC9573"/> - ESI-label-1 for ESI-1	lock
		(DCB) <xref target="RFC9573" format="default"/> - ESI-label-1
		for 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. Designated Forwarder 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 1726 ¶
	\| \|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 Supplementary Broadcast
		Domain Route Target (SBD-RT).</t>
	<t>All procedures are confined to the single Broadcast Domain	</li>
	(BD1).</t>	<li>
	</list>The absence of the SBD simplifies the configuration and	<t>All procedures are confined to the single BD1.</t>
		</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 Domain-wide Common Block label. This bit is
	defined as follows:</t>	defined as follows:</t>

		<!-- [rfced] Should "Flag" be part of the name? The other registered values do not include "Flag". It seems redundant, since it is a registry of flags. If "F lag" is to be removed, we will ask IANA to update their registry accordingly.


	<texttable>	Original Table 2:
	<ttcol>Bit</ttcol>	+=====+==============+===============+
		\| Bit \| Name \| Reference \|
	<ttcol>Name</ttcol>	+=====+==============+===============+
		\| 5 \| ESI-DCB Flag \| This Document \|
	<ttcol>Reference</ttcol>	-->

	<c>5</c>

	<c>ESI-DCB Flag</c>

	<c>This Document</c>
	</texttable>
	</section>

	<section title="Acknowledgments">
	<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’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>	<table align="center">
		<thead>
		<tr>
		<th align="left">Bit</th>
		<th align="left">Name</th>
		<th align="left">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left">5</td>
		<td align="left">ESI-DCB Flag</td>
		<td align="left">This Document</td>
		</tr>
		</tbody>
		</table>
	</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
		432.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		513.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		514.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		251.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		625.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		584.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		573.xml"/>


	&RFC6514;	<!-- Note to RE and AUTH48 manager
		draft-ietf-bess-evpn-mh-split-horizon-11 is now RFC 9764.
		Note: had to add this reference the long way. There was no BibXML for
		this RFC, so an xi:include would not work.
		-->


	&RFC9251;	<reference anchor="RFC9746" target="https://www.rfc-editor.org/info/rfc9746">
		<front>
		<title>BGP EVPN Multihoming Extensions for Split-Horizon Filtering</title>
		<author initials='J' surname='Rabadan' fullname='Jorge Rabadan' role="editor
		">
		<organization/>
		</author>
		<author initials='K' surname='Nagaraj' fullname='Kiran Nagaraj'>
		<organization/>
		</author>
		<author initials='W' surname='Lin' fullname='Wen Lin'>
		<organization/>
		</author>
		<author initials='A' surname='Sajassi' fullname='Ali Sajassi'>
		<organization/>
		</author>
		<date month='March' year='2025'/>
		</front>
		<seriesInfo name="RFC" value="9746"/>
		<seriesInfo name="DOI" value="10.17487/RFC9746"/>
		</reference>


	&RFC9625;	</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"/>


	&RFC8584;	<!-- [I-D.ietf-bess-evpn-pref-df]
		-->
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		785.xml"/>


	&RFC2119;	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 364.xml"/>;


	&RFC8174;	<!-- [I-D.ietf-mpls-p2mp-bfd]
		-->
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		780.xml"/>


	&RFC9573;	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 761.xml"/>;


	&I-D.ietf-bess-evpn-mh-split-horizon;	<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.3
		376.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		810.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
		Mishra"/>, <contact fullname="Ali Sajassi"/>, <contact fullname="Greg
		Mirsky"/>, and <contact fullname="Sasha Vainshtein"/> for their review
		and valuable comments. Special thanks to <contact fullname="Gunter Van
		de Velde"/> for his excellent review, which significantly enhanced the
		document's readability.</t>
		</section>
		<section anchor="sect-9" numbered="false" toc="default">
		<name>Contributors</name>
		<t>In addition to the authors listed on the front page, the following
		person has significantly contributed to this document:</t>


	&RFC9572;	<contact fullname="Eric C. Rosen">
		<address>
		<email>erosen52@gmail.com</email>
		</address>
		</contact>


	&I-D.ietf-bess-evpn-pref-df;	</section>;


	&RFC4364;	</back>;


	&I-D.ietf-mpls-p2mp-bfd;	<!-- [rfced] Throughout the text, several abbreviations are introduced but not u sed or are repeatedly defined. Please consider whether the abbreviated form sho uld be used in most cases once the term has been introduced.


	&RFC7761;	For example:
		Attachment Circuit (AC)
		Assisted Replication (AR)
		Bit Indexed Explicit Replication (BIER)
		Domain-wide Common Block (DCB)
		Designated Forwarder (DF)
		Ethernet Segment (ES)
		Ethernet Segment Identifier (ESI)
		Inclusive Multicast Ethernet Tag (IMET)
		Ingress Replication (IR)
		Supplementary Broadcast Domain (SBD)
		Supplementary Broadcast Domain Route Target (SBD-RT)
		Selective Multicast Ethernet Tag (SMET)
		-->


	&RFC9135;	<!-- [rfced] Throughout the text, the following terminology appears to be
		capitalized inconsistently. Please review these occurrences and let us
		know if/how they may be made consistent.


	&RFC3376;	Downstream vs. downstream
		ESI Label vs. ESI label
		Upstream vs. upstream
		-->


	&RFC3810;	<!-- [rfced] Please review the "Inclusive Language" portion of the online
		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this nature typically
		result in more precise language, which is helpful for readers.


	&RFC8296;	Note that our script did not flag any words in particular, but this should
		still be reviewed as a best practice.
		-->


	&RFC9574;
	</references>
	</back>
	</rfc>	</rfc>

End of changes. 288 change blocks.
	989 lines changed or deleted	1277 lines changed or added
This html diff was produced by rfcdiff 1.48.