Diff: rfc9624xml2.original.xml

	rfc9624xml2.original.xml	rfc9624.xml

	<?xml version="1.1" encoding="US-ASCII"?>	<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
		<!-- pre-edited by ST 02/12/24 -->

		<!DOCTYPE rfc [
		<!ENTITY nbsp " ">
		<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
	]>	]>

	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	<?rfc tocdepth="3"?>	tf-bier-evpn-14" number="9624" ipr="trust200902" consensus="true" obsoletes="" u
	<?rfc tocindent="yes"?>	pdates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" sym
	<?rfc symrefs="yes"?>	Refs="true" sortRefs="true" version="3">
	<?rfc sortrefs="yes"?>
	<?rfc strict="no"?>
	<?rfc rfcedstyle="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="std" docName="draft-ietf-bier-evpn-14" ipr="trust200902">
	<front>	<front>

	<title abbrev="bier-evpn">EVPN BUM Using BIER</title>


		<!--[rfced] Please note that the title of the document has been updated as
		follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
		Style Guide"). Please review.

		Original:
		EVPN BUM Using BIER

		Current:
		EVPN Broadcast, Unknown Unicast, and Multicast (BUM) Using Bit Index
		Explicit Replication (BIER)

		Additionally, we have updated the short title. This can be seen in the header
		of the PDF output.

		Original:
		bier-evpn

		Current:
		EVPN BUM Using BIER
		-->

		<title abbrev="EVPN BUM Using BIER">EVPN Broadcast, Unknown Unicast, and Mul
		ticast (BUM) Using Bit Index
		Explicit Replication (BIER)</title>
		<seriesInfo name="RFC" value="9624"/>
	<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">	<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
	<organization>Juniper Networks</organization>	<organization>Juniper Networks</organization>
	<address>	<address>
	<email>zzhang@juniper.net</email>	<email>zzhang@juniper.net</email>
	</address>	</address>
	</author>	</author>

		<author fullname="Tony Przygienda" initials="T." surname="Przygienda">
	<author fullname="Antoni Przygienda" initials="A." surname="Przygienda">
	<organization>Juniper Networks</organization>	<organization>Juniper Networks</organization>
	<address>	<address>
	<email>prz@juniper.net</email>	<email>prz@juniper.net</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Ali Sajassi" initials="A." surname="Sajassi">	<author fullname="Ali Sajassi" initials="A." surname="Sajassi">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>
	<address>	<address>
	<email>sajassi@cisco.com</email>	<email>sajassi@cisco.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Jorge Rabadan" initials="J." surname="Rabadan">	<author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
	<organization>Nokia</organization>	<organization>Nokia</organization>
	<address>	<address>
	<email>jorge.rabadan@nokia.com</email>	<email>jorge.rabadan@nokia.com</email>
	</address>	</address>
	</author>	</author>


	<date year="2024"/>	<date month="July" year="2024"/>


		<area>RTF</area>
	<workgroup>BIER</workgroup>	<workgroup>BIER</workgroup>


		<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->

	<abstract>	<abstract>
	<t>This document specifies protocols and procedures for forwarding	<t>This document specifies protocols and procedures for forwarding

	broadcast, unknown unicast, and multicast (BUM) traffic	Broadcast, Unknown Unicast, and Multicast (BUM) traffic
	of Ethernet VPNs (EVPN) using Bit Index Explicit Replication (BIER).	of Ethernet VPNs (EVPNs) using Bit Index Explicit Replication (BIER).
	</t>	</t>
	</abstract>	</abstract>


	<note title="Requirements Language">
	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.
	</t>
	</note>
	</front>	</front>


	<middle>	<middle>

	<section title="Introduction">	<section numbered="true" toc="default">
	<t><xref target="RFC7432"/> and <xref target='RFC8365'/> specify	<name>Introduction</name>
	the protocols and procedures for Ethernet VPNs (EVPNs). For broadcast,	<t><xref target="RFC7432" format="default"/> and <xref target="RFC8365" fo
	unknown unicast and multicast (BUM) traffic, provider/underlay tunnels	rmat="default"/> specify
		the protocols and procedures for Ethernet VPNs (EVPNs). For Broadcast,
		Unknown Unicast, and Multicast (BUM) traffic, provider/underlay tunnels
	are used to carry the BUM traffic. Several	are used to carry the BUM traffic. Several

	kinds of tunnel technologies can be used as specified in <xref target="RF	kinds of tunnel technologies can be used as specified in <xref target="RF
	C7432"/> and	C7432" format="default"/> and
	<xref target="RFC8365"/>, and this document specifies the protocols an	<xref target="RFC8365" format="default"/>, and this document specifies
	d procedures to	the protocols and procedures to
	use Bit Index Explicit Replication (BIER)	use Bit Index Explicit Replication (BIER)

	<xref target='RFC8279'/> as provider tunnels for EVPN BUM traffic.	<xref target="RFC8279" format="default"/> as provider tunnels for EVPN BUM tr
	</t>	affic.
	<t>	</t>
		<t>
	BIER is an	BIER is an
	architecture that provides optimal multicast forwarding through a	architecture that provides optimal multicast forwarding through a

	"multicast domain", without requiring intermediate routers to	"multicast domain" without requiring intermediate routers to
	maintain any per-flow state or to engage in an explicit tree-building	maintain any per-flow state or to engage in an explicit tree-building
	protocol.	protocol.

	</t>	</t>
	<t>	<t>
	The EVPN BUM procedures specified in <xref target="RFC7432"/> and extende	The EVPN BUM procedures specified in <xref target="RFC7432" format="defau
	d in <xref	lt"/> and extended in <xref target="RFC9572" format="default"/>, <xref target="R
	target='I-D.ietf-bess-evpn-bum-procedure-updates'/>, <xref	FC9251" format="default"/>, and <xref target="I-D.zzhang-bess-mvpn-evpn-cmcast-e
	target='RFC9251'/>, and <xref	nhancements" format="default"/>
	target='I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements'/>	are much aligned with Multicast VPN (MVPN) procedures <xref target="RFC65
	are much aligned with Multicast VPN (MVPN) procedures <xref target="RFC65	14" format="default"/>,
	14"/>	and an EVPN Broadcast Domain (BD) corresponds to a VPN in MVPN.
	and an EVPN Broadcast Domain corresponds to a VPN in MVPN.	As such, this document is also very much aligned with <xref target="RF
	As such, this document is also very much aligned with <xref target='RF	C8556" format="default"/>, which specifies MVPN with BIER.
	C8556'/> that specifies MVPN with BIER.	For terseness, some background, terms, and concepts are not
	For terseness, some background, terms and concepts are not
	repeated here. Additionally, some text is borrowed verbatim from	repeated here. Additionally, some text is borrowed verbatim from

	<xref target='RFC8556'/>.	<xref target="RFC8556" format="default"/>.
	</t>	</t>
	<section title="Terminologies">	<section numbered="true" toc="default">
	<t>	<name>Terminology</name>
	<list style="symbols">	<dl newline="false" spacing="normal">
	<t>ES: Ethernet Segment.</t>	<dt>ES:</dt> <dd>Ethernet Segment</dd>
	<t>ESI: Ethernet Segment Identifier.</t>	<dt>ESI:</dt> <dd>Ethernet Segment Identifier</dd>
	<t>BFR: Bit-Forwarding Router.</t>	<dt>BFR:</dt> <dd>Bit-Forwarding Router</dd>
	<t>BFIR: Bit-Forwarding Ingress Router.</t>	<dt>BFIR:</dt> <dd>Bit-Forwarding Ingress Router</dd>
	<t>BFER: Bit-Forwarding Egress Router.</t>	<dt>BFER:</dt> <dd>Bit-Forwarding Egress Router</dd>
	<t>BFR-Prefix: An IP address that uniquely identifies a BFR	<dt>BFR-Prefix:</dt> <dd>An IP address that uniquely identifies a BF
	and is routable in a BIER domain.</t>	R
	<t>	and is routable in a BIER domain.</dd>
	C-S: A multicast source address identifying a multicast source	<dt>C-S:</dt> <dd>A multicast source address identifying a multicast
		source
	located at an EVPN customer site. "C-" stands for "Customer-".	located at an EVPN customer site. "C-" stands for "Customer-".

	</t>	</dd>
	<t>	<dt>C-G:</dt> <dd>A multicast group address used by an EVPN customer
	C-G: A multicast group address used by an EVPN customer.	.</dd>
	</t>	<dt>C-flow:</dt> <dd>A customer multicast flow. Each C-flow is iden
	<t>	tified by
	C-flow: A customer multicast flow. Each C-flow is identified by
	the ordered pair (source address, group address), where each	the ordered pair (source address, group address), where each
	address is in the customer's address space. The identifier of a	address is in the customer's address space. The identifier of a
	particular C-flow is usually written as (C-S, C-G).	particular C-flow is usually written as (C-S, C-G).
	Sets of C-flows can be denoted by the use of the "C-*" wildcard	Sets of C-flows can be denoted by the use of the "C-*" wildcard

	(see <xref target="RFC6625"/>), e.g., (C-*, C-G).	(see <xref target="RFC6625" format="default"/>), e.g., (C-*, C-G).</dd
	</t>	>
	<t>	<dt>P-tunnel:</dt> <dd>A multicast tunnel through the network of one
	P-tunnel. A multicast tunnel through the network of one or more	or more
	service providers used to transport C-flows. "P-" stands for "Provider -".	service providers used to transport C-flows. "P-" stands for "Provider -".

	</t>	</dd>
	<t>	<dt>IMET A-D Route:</dt> <dd>Inclusive Multicast Ethernet Tag
	IMET Route: Inclusive Multicast Ethernet Tag
	Auto-Discovery route. Carried in BGP Update messages, these	Auto-Discovery route. Carried in BGP Update messages, these
	routes are used to advertise the "default" P-tunnel for a	routes are used to advertise the "default" P-tunnel for a

	particular broadcast domain.	particular broadcast domain.</dd>
	</t>	<dt>SMET A-D Route:</dt> <dd>Selective Multicast Ethernet Tag
	<t>
	SMET Route: Selective Multicast Ethernet Tag
	Auto-Discovery route. Carried in BGP Update messages, these	Auto-Discovery route. Carried in BGP Update messages, these

	routes are used to advertise the C-flows that the advertising PE	routes are used to advertise the C-flows that the advertising Provider
	is interested in.	Edge (PE)
	</t>	is interested in.</dd>
	<t>PMSI [RFC6513]: Provider Multicast Service Interface - a conceptual in	<dt>PMSI:</dt> <dd>Provider Multicast Service Interface <xref target="
	terface for a PE	RFC6513" format="default"/>. A conceptual interface used by a PE
	to send customer multicast traffic to all or some PEs in the same	to send customer multicast traffic to all or some PEs in the same

	VPN.	VPN.</dd>
	</t>
	<t>I-PMSI: Inclusive PMSI - to all PEs in the same VPN.	<!-- [rfced] For the descriptions of "I-PMSI" and "S-PMSI", is there
	</t>	something that is "sent" to the PEs or select PEs, or is "I-PMSI"
	<t>S-PMSI: Selective PMSI - to some of the PEs in the same VPN.	and "S-PMSI" intended "for" PEs or select PEs? Please let us know
	</t>	if/how these entries may be updated for clarity.
	<t>I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route used to adver
	tise the tunnels that instantiate an I-PMSI.	Original:
	</t>	I-PMSI: Inclusive PMSI - to all PEs in the same VPN.
	<t>	S-PMSI: Selective PMSI - to some of the PEs in the same VPN.
	S-PMSI A-D route: Selective PMSI Auto-Discovery route used to advertis
	e that particular C-flows are	Perhaps:
	bound to (i.e., are traveling through) particular P-tunnels.	I-PMSI: Inclusive PMSI. For all PEs in the same VPN.
	</t>	S-PMSI: Selective PMSI. For some of the PEs in the same VPN.
	<t>	-->
	PMSI Tunnel attribute (PTA): A BGP attribute used
	to identify a particular P-tunnel.	<dt>I-PMSI:</dt> <dd>Inclusive PMSI - to all PEs in the same VPN.</dd>
	</t>	<dt>S-PMSI:</dt> <dd>Selective PMSI - to some of the PEs in the same V
	<t>VXLAN [RFC7348]: Virtual eXtensible Local Area Network.	PN.</dd>
	</t>	<dt>I-PMSI A-D Route:</dt> <dd>Inclusive PMSI Auto-Discovery route use
	<t>NVGRE [RFC7637]: Network Virtualization using Generic Routing Encapsul	d to advertise the tunnels that instantiate an I-PMSI.</dd>
	ation.	<dt>S-PMSI A-D Route:</dt> <dd>Selective PMSI Auto-Discovery route use
	</t>	d to advertise that particular C-flows are
	<t>GENEVE [RFC8926]: Generic Network Virtualization Encapsulation.	bound to (i.e., are traveling through) particular P-tunnels.</dd>
	</t>	<dt>PTA:</dt> <dd>PMSI Tunnel Attribute. A BGP attribute used
	<t>VNI: VXLAN Network Identifier.	to identify a particular P-tunnel.</dd>
	</t>	<dt>VXLAN:</dt> <dd>Virtual eXtensible Local Area Network <xref target
	<t>VSID: Virtual Subnet IDentifier.	="RFC7348" format="default"/></dd>
	</t>	<dt>NVGRE:</dt> <dd>Network Virtualization Using Generic Routing Encap
	<t>RSVP-P2MP [RFC4875]: Resource ReserVation Protocol for Point-to-Multip	sulation <xref target="RFC7637" format="default"/></dd>
	oint TE Label Switched Paths.	<dt>GENEVE:</dt> <dd>Generic Network Virtualization Encapsulation <xre
	</t>	f target="RFC8926" format="default"/></dd>
	<t>mLDP-P2MP [RFC6388]: Label Distribution Protocol Extensions for	<dt>VNI:</dt> <dd>VXLAN Network Identifier</dd>
	Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths.	<dt>VSID:</dt> <dd>Virtual Subnet IDentifier</dd>
	</t>	<dt>RSVP-P2MP:</dt> <dd>Resource Reservation Protocol for Point-to-Mul
	</list>	tipoint TE Label Switched Paths (LSPs) <xref target="RFC4875" format="default"/>
	</t>	</dd>
	</section>	<dt>mLDP-P2MP:</dt> <dd>Label Distribution Protocol Extensions for
		Point-to-Multipoint and Multipoint-to-Multipoint LSPs <xref target="RFC6388" fo
		rmat="default"/></dd>
		</dl>
		</section>
		<section>
		<name>Requirements Language</name>
		<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
	</section>	</section>

	<section title="Use of the PMSI Tunnel Attribute" anchor="pta">	</section>
	<t><xref target="RFC7432"/> specifies that Inclusive Multicast Ethernet Tag	<section anchor="pta" numbered="true" toc="default">
	(IMET)	<name>Use of the PMSI Tunnel Attribute</name>
		<t><xref target="RFC7432" format="default"/> specifies that Inclusive Mult
		icast Ethernet Tag (IMET)
	routes carry a PMSI Tunnel Attribute (PTA) to identify the particular	routes carry a PMSI Tunnel Attribute (PTA) to identify the particular

	P-tunnel to which one or more BUM flows are being assigned, the same as	P-tunnel to which one or more BUM flows are being assigned, which is the
	specified in <xref target="RFC6514"/> for MVPN.	same as
	<xref target='RFC8556'/> specifies the encoding of	specified in <xref target="RFC6514" format="default"/> for MVPN.
		<xref target="RFC8556" format="default"/> specifies the encoding of the
	PTA for the use of BIER with MVPN. Much of that specification is reused	PTA for the use of BIER with MVPN. Much of that specification is reused

	for the use of BIER with EVPN and much of the text below is borrowed	for the use of BIER with EVPN, and much of the text below is borrowed
	verbatim from <xref target='RFC8556'/>.	verbatim from <xref target="RFC8556" format="default"/>.
	</t>	</t>
	<t>The PMSI Tunnel Attribute (PTA) contains the following fields:	<t>The PTA contains the following fields:
	<list style="symbols">	</t>
	<t>"Tunnel Type". The same codepoint 0x0B that IANA has assigned for	<ul spacing="normal">
	BIER for MVPN <xref target='RFC8556'/> is used for EVPN as well.	<li>
		<t>Tunnel Type. The same codepoint 0x0B that IANA has assigned for
		BIER for MVPN <xref target="RFC8556" format="default"/> is used for EVP
		N as well.
	<!--The "composite tunnel" bit <xref target="RFC8317"/> of the type field can also be set.	<!--The "composite tunnel" bit <xref target="RFC8317"/> of the type field can also be set.
	Its semantics are updated in	Its semantics are updated in
	[I-D.draft-zzhang-bess-mvpn-evpn-composite-tunnel]. In that case,	[I-D.draft-zzhang-bess-mvpn-evpn-composite-tunnel]. In that case,
	the tunnel is referred to as a BIER composite tunnel. An example of its	the tunnel is referred to as a BIER composite tunnel. An example of its
	usage is provided in Section <xref target="ar"/> of this document.-->	usage is provided in Section <xref target="ar"/> of this document.-->

	</t>	</t>
	<t>"Tunnel Identifier". This field contains three subfields for BIER.	</li>
		<li>

		<!--[rfced] In this list, the text in items 1 and 3 does not exactly match
		that in RFC 8556. Should we update this text to match RFC 8556? Or may
		we indicate that the text is based on RFC 8556 as shown below?

		Original:
		* "Tunnel Identifier". This field contains three subfields for
		BIER. The text below is exactly as in [RFC8556].

		1 The first subfield is a single octet, containing the sub-
		domain-id of the sub-domain to which the BFIR will assign the
		packets that it transmits on the PMSI identified by the Network
		Layer Reachability Information (NLRI) of the IMET, S-PMSI A-D,
		or per-region I-PMSI A-D route that contains this PTA. How
		that sub-domain is chosen is outside the scope of this
		document.
		...
		3 The third subfield is the BFR-Prefix (see [RFC8279]) of the
		originator of the route that is carrying this PTA. This will
		either be a /32 IPv4 address or a /128 IPv6 address. Whether
		the address is IPv4 or IPv6 can be inferred from the total
		length of the PMSI Tunnel attribute.

		The BFR-prefix need not be the same IP address that is carried
		in any other field of the x-PMSI A-D route, even if the BFIR is
		the originating router of the x-PMSI A-D route.

		Perhaps:
		* "Tunnel Identifier". This field contains three subfields for
		BIER. The text below is based on the text in [RFC8556].

		1. The first subfield is a single octet, containing the sub-
		domain-id of the sub-domain to which the BFIR will assign the
		packets that it transmits on the PMSI identified by the
		Network Layer Reachability Information (NLRI) of the IMET,
		S-PMSI A-D, or per-region I-PMSI A-D route that contains this
		PTA. How that sub-domain is chosen is outside the scope of
		this document.
		...
		3. The third subfield is the BFR-Prefix (see [RFC8279]) of the
		originator of the route that is carrying this PTA. This will
		either be a /32 IPv4 address or a /128 IPv6 address. Whether
		the address is IPv4 or IPv6 can be inferred from the total
		length of the PMSI Tunnel Attribute.

		The BFR-Prefix need not be the same IP address that is carried
		in any other field of the x-PMSI A-D route, even if the BFIR
		is the originating router of the x-PMSI A-D route.
		-->

		<t>Tunnel Identifier. This field contains three subfields for BIER.
	The text below is exactly as in	The text below is exactly as in

	<xref target='RFC8556'/>.	<xref target="RFC8556" format="default"/>.
	<list style="format %d">	</t>
	<t>	<ol spacing="normal" type="1"><li>
		<t>
	The first subfield is a single octet, containing the sub-	The first subfield is a single octet, containing the sub-
	domain-id of the sub-domain to which the BFIR will assign the	domain-id of the sub-domain to which the BFIR will assign the
	packets that it transmits on the PMSI identified by the	packets that it transmits on the PMSI identified by the
	Network Layer Reachability Information (NLRI) of the IMET,	Network Layer Reachability Information (NLRI) of the IMET,
	S-PMSI A-D, or per-region I-PMSI A-D route that contains this PTA.	S-PMSI A-D, or per-region I-PMSI A-D route that contains this PTA.
	How that sub-domain is chosen is outside the scope of this	How that sub-domain is chosen is outside the scope of this
	document.	document.

	</t>	</t>
	<t> The second subfield is a two-octet field containing the	</li>
	BFR-id, in the sub-domain identified in the first subfield, of	<li>
		<t> The second subfield is a two-octet field containing the
		BFR-id in the sub-domain identified in the first subfield of
	the router that is constructing the PTA. </t>	the router that is constructing the PTA. </t>

	<t>	</li>
		<li>
		<t>
	The third subfield is the BFR-Prefix (see	The third subfield is the BFR-Prefix (see

	<xref target='RFC8279'/>) of the	<xref target="RFC8279" format="default"/>) of the
	originator of the route that is carrying this PTA. This will	originator of the route that is carrying this PTA. This will
	either be a /32 IPv4 address or a /128 IPv6 address. Whether	either be a /32 IPv4 address or a /128 IPv6 address. Whether
	the address is IPv4 or IPv6 can be inferred from the total	the address is IPv4 or IPv6 can be inferred from the total

	length of the PMSI Tunnel attribute.	length of the PMSI Tunnel Attribute.
	<vspace/>	</t>
	<vspace/>	<t>
	The BFR-prefix need not be the same IP address that is carried	The BFR-Prefix need not be the same IP address that is carried
	in any other field of the x-PMSI A-D route, even if the BFIR	in any other field of the x-PMSI A-D route, even if the BFIR
	is the originating router of the x-PMSI A-D route.	is the originating router of the x-PMSI A-D route.

	</t>	</t>
	</list>	</li>
		</ol>
		<t>
	<!--If the "composite tunnel" bit is set, as specified in	<!--If the "composite tunnel" bit is set, as specified in
	[I-D.draft-zzhang-bess-mvpn-evpn-composite-tunnel],	[I-D.draft-zzhang-bess-mvpn-evpn-composite-tunnel],
	a three-octet label field is added before the "Tunnel Identifier" field	a three-octet label field is added before the "Tunnel Identifier" field
	to indicate the IR label that this PE uses to receive IR traffic with.	to indicate the IR label that this PE uses to receive IR traffic with.
	The three-octet label field after the Tunnel Type field is the label	The three-octet label field after the Tunnel Type field is the label
	that this PE uses to send/receive BIER traffic with.-->	that this PE uses to send/receive BIER traffic with.-->

	</t>	</t>
	<t>"MPLS label". For EVPN-MPLS <xref target="RFC7432"/>, this field contain	</li>
	s an upstream-assigned	<li>
		<t>MPLS Label. For EVPN-MPLS <xref target="RFC7432" format="default"/
		>, this field contains an upstream-assigned
	MPLS label. It is assigned by the BFIR. Constraints on how the originat ing router selects this label are discussed in	MPLS label. It is assigned by the BFIR. Constraints on how the originat ing router selects this label are discussed in

	<xref target="label"/>. For EVPN-VXLAN/NVGRE/GENEVE	<xref target="label" format="default"/>. For EVPN-VXLAN/NVGRE/GENEVE
	<xref target='RFC8365'/> <xref target='RFC7348'/> <xref target='RFC7637'/	<xref target="RFC8365" format="default"/> <xref target="RFC7348" format="
	> <xref target='RFC8926'/>, this field is a 24-bit	default"/> <xref target="RFC7637" format="default"/> <xref target="RFC8926" form
		at="default"/>, this field is a 24-bit
	VNI/VSID of global significance.	VNI/VSID of global significance.

	</t>	</t>
	<t>"Flags". When the tunnel type is BIER, two of the flags in the	</li>
		<li>
		<t>Flags. When the tunnel type is BIER, two of the flags in the
	PTA Flags field are meaningful. Details about the use of these	PTA Flags field are meaningful. Details about the use of these

	flags can be found in <xref target="tracking"/>.	flags can be found in <xref target="tracking" format="default"/>.
	<list style="symbols">	</t>
	<t>"Leaf Info Required per Flow (LIR-pF)" <xref target="RFC8534"/>	<ul spacing="normal">
	</t>	<li>
	<t>"Leaf Info Required Bit (LIR)"	<t>Leaf Info Required per Flow (LIR-pF) <xref target="RFC8534" for
	</t>	mat="default"/>
	</list>	</t>
	</t>	</li>
	<!--t>"Auxiliary Information". This is optional, present if the total	<li>
		<t>Leaf Info Required Bit (LIR)
		</t>
		</li>
		</ul>
		</li>
		<!--t>"Auxiliary Information". This is optional, present if the total
	length of the PTA is larger then the sum of lengths of the fields before	length of the PTA is larger then the sum of lengths of the fields before
	this one. It is in the form of a series of TLVs.	this one. It is in the form of a series of TLVs.
	</t-->	</t-->

	</list>	</ul>
	</t>	<t>
	<t>
	Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI A-D,	Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI A-D,

	or per-region I-PMSI A-D route, the route MUST NOT be distributed beyond the	or per-region I-PMSI A-D route, the route <bcp14>MUST NOT</bcp14> be distribu ted beyond the
	boundaries of a BIER domain. That is, any routers that receive the	boundaries of a BIER domain. That is, any routers that receive the
	route must be in the same BIER domain as the originator of the route.	route must be in the same BIER domain as the originator of the route.
	If the originator is in more than one BIER domain, the route must be	If the originator is in more than one BIER domain, the route must be
	distributed only within the BIER domain in which the BFR-Prefix in	distributed only within the BIER domain in which the BFR-Prefix in
	the PTA uniquely identifies the originator. As with all MVPN routes,	the PTA uniquely identifies the originator. As with all MVPN routes,
	the distribution of these routes is controlled by the provisioning of	the distribution of these routes is controlled by the provisioning of
	Route Targets.	Route Targets.

	</t>	</t>
	<!--section title = "Auxiliary Information">	<!--section title = "Auxiliary Information">
	<t>For the "Auxiliary Information", one TLV is defined in this document -	<t>For the "Auxiliary Information", one TLV is defined in this document -
	Tunnel Encapsulation TLV. The value part of the TLV is a Tunnel TLV	Tunnel Encapsulation TLV. The value part of the TLV is a Tunnel TLV
	as defined in <xref target="RFC9012"/>.	as defined in <xref target="RFC9012"/>.
	</t>	</t>
	<t>This MAY be used when VXLAN/NVGRE/GENEVE encapsulation with an IP header	<t>This MAY be used when VXLAN/NVGRE/GENEVE encapsulation with an IP header
	(and UDP header in the case of VXLAN/GENEVE) is the BIER payload.	(and UDP header in the case of VXLAN/GENEVE) is the BIER payload.
	Normally that is not needed with BIER, except when BIER Penultimate Hop	Normally that is not needed with BIER, except when BIER Penultimate Hop
	Popping (PHP) <xref target="I-D.ietf-bier-php"/> is used and the encap sulation (after BIER header is	Popping (PHP) <xref target="I-D.ietf-bier-php"/> is used and the encap sulation (after BIER header is
	popped) between the BIER Penultimate Hop and the egress PE does not have	popped) between the BIER Penultimate Hop and the egress PE does not have
	a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case	a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case

	skipping to change at line 290 ¶	skipping to change at line 367 ¶
	used. The tunnel type (VXLAN/NVGRE/GENEVE), endpoint, and	used. The tunnel type (VXLAN/NVGRE/GENEVE), endpoint, and
	some tunnel specific information MAY be specified in the Tunnel TLV	some tunnel specific information MAY be specified in the Tunnel TLV
	or MAY be provisioned on PEs.	or MAY be provisioned on PEs.
	The tunnel endpoint MUST be an IP multicast address and the receiving	The tunnel endpoint MUST be an IP multicast address and the receiving
	egress PE MUST be set up to receive and process packets addressed to	egress PE MUST be set up to receive and process packets addressed to
	the address. The same multicast address can be used for	the address. The same multicast address can be used for
	all Bridge Domains (BDs), as the the inner VXLAN/NVGRE/GENEVE header will be used	all Bridge Domains (BDs), as the the inner VXLAN/NVGRE/GENEVE header will be used
	to identify BDs.	to identify BDs.
	</t>	</t>
	</section-->	</section-->

	<section title="IP-Based Tunnel and BIER PHP" anchor="php-address">	<section anchor="php-address" numbered="true" toc="default">
	<t>When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP header	<name>IP-Based Tunnel and BIER PHP</name>
		<t>When VXLAN/NVGRE/GENEVE is used for EVPN, by default, the outer IP he
		ader
	(and UDP header in the case of VXLAN/GENEVE) is not included in the BIER	(and UDP header in the case of VXLAN/GENEVE) is not included in the BIER

	payload, except when it is known apriori that BIER Penultimate Hop	payload, except when it is known a priori that BIER Penultimate Hop
	Popping (PHP)	Popping (PHP)

	<xref target="I-D.ietf-bier-php"/> is used in the BIER domain and	<xref target="I-D.ietf-bier-php" format="default"/> is used in the BIER d omain and
	the encapsulation (after the BIER header is	the encapsulation (after the BIER header is
	popped) between the BIER Penultimate Hop and the egress PE does not have	popped) between the BIER Penultimate Hop and the egress PE does not have

	a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case	a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case,
	the full VXLAN/NVGRE/GENEVE encapsulation MUST be used. In the outer	the full VXLAN/NVGRE/GENEVE encapsulation <bcp14>MUST</bcp14> be used. In
		the outer
	IP header, a well-known IP multicast address	IP header, a well-known IP multicast address

	(to be assigned by IANA) is used as the destination address and the	(to be assigned by IANA) is used as the destination address, and the
	egress PEs MUST be set up to receive and process packets addressed to	egress PEs <bcp14>MUST</bcp14> be set up to receive and process packets a
	the address. The address is used for all Broadcast Domains (BDs) and the	ddressed to
	inner	the destination address. The address is used for all BDs, and the inner
	VXLAN/NVGRE/GENEVE header will be used to identify BDs.	VXLAN/NVGRE/GENEVE header will be used to identify BDs.

	</t>	</t>
	</section>	</section>
	<section title="Explicit Tracking" anchor="tracking">	<section anchor="tracking" numbered="true" toc="default">
	<t>	<name>Explicit Tracking</name>
		<t>
	When using BIER to transport an EVPN BUM data packet through a BIER	When using BIER to transport an EVPN BUM data packet through a BIER
	domain, an ingress PE functions as a BFIR (see	domain, an ingress PE functions as a BFIR (see

	<xref target='RFC8279'/>). The	<xref target="RFC8279" format="default"/>). The
	BFIR must determine the set of BFERs to which the packet needs to be	BFIR must determine the set of BFERs to which the packet needs to be

	delivered. This can be done in either of two ways in the following	delivered. This can be done in either of two ways as described in the follow ing
	two sections.	two sections.

	</t>	</t>
	<section title="Using IMET/SMET routes">	<section numbered="true" toc="default">
	<t>Both IMET and SMET routes provide explicit tracking functionality.	<name>Using IMET/SMET Routes</name>
	</t>	<t>Both IMET and SMET routes provide explicit tracking functionality.
	<t>For an inclusive PMSI, the set of BFERs (egress PEs) includes	</t>
		<t>For an inclusive PMSI, the set of BFERs (egress PEs) includes
	the originators of all IMET routes for a broadcast domain. For a selectiv e	the originators of all IMET routes for a broadcast domain. For a selectiv e
	PMSI, the set of BFERs (egress PEs) includes the originators	PMSI, the set of BFERs (egress PEs) includes the originators
	of corresponding SMET routes.	of corresponding SMET routes.

	</t>	</t>
	<t>The SMET routes do not carry a PTA. When an ingress	<t>The SMET routes do not carry a PTA. When an ingress
	PE sends traffic on a selective tunnel using BIER, it uses the upstream-a ssigned label that is advertised in its IMET route.	PE sends traffic on a selective tunnel using BIER, it uses the upstream-a ssigned label that is advertised in its IMET route.

	</t>	</t>
	<t>Only when selectively forwarding is for all flows and without tunnel	<t>When only selective forwarding is used for all flows and without tu
		nnel
	segmentation, SMET routes are used without the need for S-PMSI A-D routes .	segmentation, SMET routes are used without the need for S-PMSI A-D routes .
	Otherwise, the procedures in the following section apply.	Otherwise, the procedures in the following section apply.

	</t>	</t>
	</section>	</section>
	<section title="Using S-PMSI/Leaf A-D Routes">	<section numbered="true" toc="default">
	<t>There are two cases where S-PMSI/Leaf A-D routes are used as discussed	<name>Using S-PMSI/Leaf A-D Routes</name>
		<t>There are two cases where S-PMSI/Leaf A-D routes are used as discus
		sed
	in the following two sections.	in the following two sections.

	</t>	</t>
	<section title="Selective Forwarding Only for Some Flows">	<section numbered="true" toc="default">
	<t>With the SMET procedure, a PE advertises an SMET route for each	<name>Selective Forwarding Only for Some Flows</name>
		<t>With the SMET procedure, a PE advertises a SMET route for each
	(C-S, C-G) or (C-*, C-G) state that it learns on its Attachment Circuits ( ACs), and each SMET	(C-S, C-G) or (C-*, C-G) state that it learns on its Attachment Circuits ( ACs), and each SMET
	route is tracked by every PE in the same broadcast domain. It may be desir ed	route is tracked by every PE in the same broadcast domain. It may be desir ed

	that SMET routes are not used, in order to reduce the burden of explicit t	that SMET routes are not used in order to reduce the burden of explicit tr
	racking.	acking.
	</t>	</t>
	<t>In this case, most multicast traffic will follow the I-PMSI (advertised	<t>In this case, most multicast traffic will follow the I-PMSI (adve
	via IMET route) and only some flows follow S-PMSIs. To achieve that,	rtised
	S-PMSI/Leaf A-D routes can be used, as specified in <xref	via the IMET route) and only some flows will follow S-PMSIs. To achieve t
	target='I-D.ietf-bess-evpn-bum-procedure-updates'/>.	hat,
	</t>	S-PMSI/Leaf A-D routes can be used, as specified in <xref target="RFC9572
	<t>The rules specified in Section 2.2.1 and Section 2.2.2 of	" format="default"/>.
	<xref target='RFC8556'/> apply.	</t>
	</t>	<t>The rules specified in Sections <xref target="RFC8556" section="2
	</section>	.2.1" sectionFormat="bare" format="default"/> and <xref target="RFC8556" section
	<section title="Tunnel Segmentation">	="2.2.2" sectionFormat="bare" format="default"/> of <xref target="RFC8556"/> app
	<t>Another case where S-PMSI/Leaf A-D routes are necessary is tunnel	ly.
	segmentation, which is also specified in <xref	</t>
	target='I-D.ietf-bess-evpn-bum-procedure-updates'/>, and further	</section>
		<section numbered="true" toc="default">
		<name>Tunnel Segmentation</name>
		<t>Another case where S-PMSI/Leaf A-D routes are necessary is tunnel
		segmentation, which is also specified in <xref target="RFC9572" format="d
		efault"/> and further
	clarified in	clarified in

	<xref target='I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements'/> for	<xref target="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" format="defa ult"/> for
	segmentation with SMET routes. This is only applicable to EVPN-MPLS.	segmentation with SMET routes. This is only applicable to EVPN-MPLS.

	</t>	</t>
	<t>The rules specified in Section 2.2.1 of	<t>The rules specified in <xref target="RFC8556" section="2.2.1" sec
	<xref target='RFC8556'/> apply. Section 2.2.2 of	tionFormat="of" format="default"/> apply. <xref target="RFC8556" section="2.2.2"
	<xref target='RFC8556'/> does not apply, because	sectionFormat="of" format="default"/> does not apply, because
	like in MVPN, the LIR-pF flag cannot be used with	like in MVPN, the LIR-pF flag cannot be used with
	segmentation.	segmentation.

	</t>	</t>
	</section>	</section>
	<section title="Applicability of Additional MVPN Specifications">	<section numbered="true" toc="default">
	<t>As with the MVPN case, Section "3. Use of the PMSI Tunnel Attribute	<name>Applicability of Additional MVPN Specifications</name>
	in Leaf A-D routes" of <xref target='RFC8556'/> apply.	<t>As with the MVPN case, "Use of the PMSI Tunnel Attribute
	</t>	in Leaf A-D Routes" (<xref target="RFC8556" format="default" sectionForma
	<t>Notice that, <xref target='RFC8556'/> refers to procedures	t="of" section="3"/>) applies.
	specified in <xref target='RFC6625'/> and	</t>
	<xref target="RFC8534"/>. Those two documents	<t>Notice that <xref target="RFC8556" format="default"/> refers to p
		rocedures
		specified in <xref target="RFC6625" format="default"/> and
		<xref target="RFC8534" format="default"/>. Those two documents
	were specified for MVPN but apply to IP multicast	were specified for MVPN but apply to IP multicast
	payload in EVPN as well.	payload in EVPN as well.

	</t>	</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	<section title="MPLS Label in PTA" anchor="label">	<section anchor="label" numbered="true" toc="default">
	<t>Rules in section 2.1 of <xref target='RFC8556'/> apply,	<name>MPLS Label in the PTA</name>
		<t>Rules in <xref target="RFC8556" section="2.1" sectionFormat="of" form
		at="default"/> apply,
	EXCEPT the following three bullets (they do NOT apply to EVPN) in that	EXCEPT the following three bullets (they do NOT apply to EVPN) in that
	section:	section:

	<list style="symbols">	</t>
	<t>	<ul spacing="normal">
		<li>
		<t>
	If the two routes do not have the same Address Family Identifier	If the two routes do not have the same Address Family Identifier

	(AFI) value, then their respective PTAs MUST contain different	(AFI) value, then their respective PTAs <bcp14>MUST</bcp14> contain differ ent
	MPLS label values. This ensures that when an egress PE receives a	MPLS label values. This ensures that when an egress PE receives a
	data packet with the given label, the egress PE can infer from the	data packet with the given label, the egress PE can infer from the
	label whether the payload is an IPv4 packet or an IPv6 packet.	label whether the payload is an IPv4 packet or an IPv6 packet.

	</t>	</t>
	<t>	</li>
	If the BFIR is an ingress PE supporting MVPN extranet (<xref target="RFC79	<li>
	00"/>)	<t>
		If the BFIR is an ingress PE supporting MVPN extranet <xref target="RFC790
		0" format="default"/>
	functionality, and if the two routes originate from different VRFs	functionality, and if the two routes originate from different VRFs
	on this ingress PE, then the respective PTAs of the two routes	on this ingress PE, then the respective PTAs of the two routes

	MUST contain different MPLS label values.	<bcp14>MUST</bcp14> contain different MPLS label values.
	</t>	</t>
	<t>	</li>
		<li>
		<t>
	If the BFIR is an ingress PE supporting the "Extranet Separation"	If the BFIR is an ingress PE supporting the "Extranet Separation"

	feature of MVPN extranet (see Section 7.3 of <xref target="RFC7900"/>), an d if	feature of MVPN extranet (see <xref target="RFC7900" section="7.3" section Format="of" format="default"/>), and if
	one of the routes carries the "Extranet Separation" extended	one of the routes carries the "Extranet Separation" extended
	community but the other does not, then the respective PTAs of the	community but the other does not, then the respective PTAs of the

	two routes MUST contain different MPLS label values.	two routes <bcp14>MUST</bcp14> contain different MPLS label values.
	</t>	</t>
	</list>	</li>
	</t>	</ul>
	</section>	</section>
	</section>	</section>

	<section title="Multihoming Split Horizon" anchor="multihoming">	<section anchor="multihoming" numbered="true" toc="default">
	<t>For EVPN-MPLS, <xref target="RFC7432"/> specifies the use of ESI labels t	<name>Multihoming Split Horizon</name>
	o identify	<t>For EVPN-MPLS, <xref target="RFC7432" format="default"/> specifies the
		use of ESI labels to identify
	the ES from which a BUM packet originates. A PE receiving that packet	the ES from which a BUM packet originates. A PE receiving that packet
	from the core side will not forward it to the same ES. The procedure	from the core side will not forward it to the same ES. The procedure
	works for both Ingress Replication (IR) and RSVP-TE/mLDP P2MP tunnels,	works for both Ingress Replication (IR) and RSVP-TE/mLDP P2MP tunnels,

	using downstream- and upstream-assigned ESI labels respectively. For	using downstream- and upstream-assigned ESI labels, respectively.
	EVPN-VXLAN/NVGRE/GENEVE, <xref target='RFC8365'/> specifies local bias
	procedures, with which a PE receiving a BUM packet from the core	<!--[rfced] To clarify this sentence, may we update it as follows or
		is there another way it should be updated?

		Original:
		For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local
		bias procedures, with which a PE receiving a BUM packet from the core
		side knows from encapsulation the ingress PE so it does not forward
		the packet to any multihoming ESes that the ingress PE is on.

		Perhaps:
		For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local
		bias procedures, where a PE receiving a BUM packet from the core
		side knows the ingress PE due to encapsulation; therefore, the PE
		does not forward the packet to any multihoming ESes that the ingress
		PE is on.
		-->

		For
		EVPN-VXLAN/NVGRE/GENEVE, <xref target="RFC8365" format="default"/> specif
		ies local bias
		procedures with which a PE receiving a BUM packet from the core
	side knows from encapsulation the ingress PE so it does not forward	side knows from encapsulation the ingress PE so it does not forward
	the packet to any multihoming ESes that the ingress PE is on. This is	the packet to any multihoming ESes that the ingress PE is on. This is

	because the ingress PE already forwarded the packet to those ESes	because the ingress PE already forwarded the packet to those ESes,
	regardless of whether the ingress PE is a Designated Forwarder for	regardless of whether the ingress PE is a Designated Forwarder for
	those ESes.	those ESes.

	</t>	</t>
	<t>With BIER, the local bias procedure still applies for EVPN-VXLAN/NVGRE/GE	<t>With BIER, the local bias procedure still applies for EVPN-VXLAN/NVGRE/
	NEVE	GENEVE,
	as the BFIR-id in the BIER header identifies the ingress PE.	as the BFIR-id in the BIER header identifies the ingress PE.

	For EVPN-MPLS, ESI label procedures also still apply though two upstream-	For EVPN-MPLS, ESI label procedures also still apply, though two upstream
	assigned labels will be used (one for identifying the broadcast domain	-assigned labels will be used (one for identifying the broadcast domain
	and one for identifying the ES) - the same as in the case of using	and one for identifying the ES) -- the same as in the case of using
	a single P2MP tunnel for multiple broadcast domains. The BFIR-id in	a single P2MP tunnel for multiple broadcast domains. The BFIR-id in
	the BIER header identifies the ingress PE that assigned those	the BIER header identifies the ingress PE that assigned those
	two labels.	two labels.

	</t>	</t>
	</section>	</section>
	<!--section title = "Assisted Replication with BIER Composite Tunnel" anchor ="ar">	<!--section title = "Assisted Replication with BIER Composite Tunnel" anchor ="ar">
	<t>With Assisted Replication (AR)	<t>With Assisted Replication (AR)
	<xref target="I-D.ietf-bess-evpn-optimized-ir"/> (with IP tunnels)	<xref target="I-D.ietf-bess-evpn-optimized-ir"/> (with IP tunnels)
	an AR-leaf sends traffic to an AR-replicator via Ingress Replication (IR) ,	an AR-leaf sends traffic to an AR-replicator via Ingress Replication (IR) ,
	who will then relay the traffic to other AR-leaf and AR-replicators.	who will then relay the traffic to other AR-leaf and AR-replicators.
	While the AR-replicator receives via IR the relay could be via BIER.	While the AR-replicator receives via IR the relay could be via BIER.
	An AR-leaf may not support BIER in the forwarding path but it could still	An AR-leaf may not support BIER in the forwarding path but it could still
	advertise the support of BIER and rely on its upstream router to do	advertise the support of BIER and rely on its upstream router to do
	Penultimate Hop Popping as described in	Penultimate Hop Popping as described in

	skipping to change at line 469 ¶	skipping to change at line 575 ¶
	and relay traffic from AR-leaves to RNVEs via IR.	and relay traffic from AR-leaves to RNVEs via IR.
	[question - do we need to elect an AR-replicator to relay traffic	[question - do we need to elect an AR-replicator to relay traffic
	from RNVEs?]	from RNVEs?]
	</t>	</t>
	</list>	</list>
	</t>	</t>
	<t>AR with MPLS tunnels, along with the usage of BIER composite tunnel,	<t>AR with MPLS tunnels, along with the usage of BIER composite tunnel,
	are specified in <xref target="I-D.keyupate-bess-evpn-virtual-hub"/>.	are specified in <xref target="I-D.keyupate-bess-evpn-virtual-hub"/>.
	</t>	</t>
	</section-->	</section-->

	<section title="Data Plane">	<section numbered="true" toc="default">
	<t>Like MVPN, the EVPN application plays the role of the "multicast	<name>Data Plane</name>
	flow overlay" as described in <xref target='RFC8279'/>.	<t>Like MVPN, the EVPN application plays the role of the "multicast
	</t>	flow overlay" as described in <xref target="RFC8279" format="default"/>.
	<section title="Encapsulation and Transmission">	</t>
	<t>A BFIR could be either an ingress PE or a P-tunnel segmentation point.	<section numbered="true" toc="default">
		<name>Encapsulation and Transmission</name>
		<t>A BFIR could be either an ingress PE or a P-tunnel segmentation point
		.
	The procedures are slightly different as described below.	The procedures are slightly different as described below.

	</t>	</t>
	<section title="At a BFIR that is an Ingress PE" anchor="ingresspe">	<section anchor="ingresspe" numbered="true" toc="default">
	<t>To transmit a BUM data packet, an ingress PE first determines the	<name>At a BFIR That Is an Ingress PE</name>
		<t>To transmit a BUM data packet, an ingress PE first determines the
	route matched for transmission and routes for tracking leaves according	route matched for transmission and routes for tracking leaves according
	to the following rules.	to the following rules.

	<list style="numbers">	</t>
	<t anchor="inclusive">If selective forwarding is not used, or it is not an I	<ol spacing="normal" type="1"><li anchor="inclusive">
	P Multicast packet	<t>If selective forwarding is not used or is not an IP Multicast p
		acket
	after the Ethernet header, the IMET route originated for the BD by the	after the Ethernet header, the IMET route originated for the BD by the

	ingress PE is the route matched for transmission. Leaf tracking routes	ingress PE is the route matched for transmission. Leaf-tracking routes
	are all other received IMET routes for the BD.	are all other received IMET routes for the BD.

	</t>	</t>
	<t>Otherwise, if selective forwarding is used for all IP Multicast traffic	</li>
		<li>
		<t>Otherwise, if selective forwarding is used for all IP Multicast
		traffic
	based on SMET routes, the IMET route originated for the BD by the ingress	based on SMET routes, the IMET route originated for the BD by the ingress
	PE is the route matched for transmission. Received SMET	PE is the route matched for transmission. Received SMET

	routes for the BD whose source and destination address fields match	routes for the BD, whose source and destination address fields match
	the packet's source and destination IP address	the packet's source and destination IP address,
	are leaf tracking routes.	are leaf-tracking routes.
	</t>	</t>
	<t>Otherwise, the route matched for transmission is the S-PMSI A-D route	</li>
		<li>
		<t>Otherwise, the route matched for transmission is the S-PMSI A-D
		route
	originated by the ingress PE for the BD,	originated by the ingress PE for the BD,
	whose source and destination address fields match the packet's source and	whose source and destination address fields match the packet's source and

	destination IP address and has a PTA specifying a valid tunnel type that	destination IP address and have a PTA specifying a valid tunnel type that
	is not "no tunnel info". Leaf tracking routes are determined	is not "no tunnel info". Leaf-tracking routes are determined
	as follows:	as follows:

	<list style="format %d)">	</t>
	<t>If the match for transmission route carries a PTA that has the LIR
	flag set but does not have the LIR-pF flag set, the routes matched fo	<!--[rfced] Section 4.1.1. We updated the numerals to letters within the
	r	nested list for clarity as shown below. Please let us know of any
	tracking are Leaf A-D routes whose "route key" field is identical to	objections.
	the NLRI of the S-PMSI A-D route.
	</t>	Original:
	<t>If the match for transmission route carries a PTA that has the LIR-pF	3. Otherwise, the route matched for transmission is the S-PMSI A-D route
	flag, the leaf tracking routes are Leaf A-D routes whose	originated by the ingress PE for the BD, whose source and destination
		address fields match the packet's source and destination IP address
		and has a PTA specifying a valid tunnel type that is not "no tunnel
		info". Leaf tracking routes are determined as follows:

		1) If the match for transmission route carries a PTA that has the
		LIR flag set but does not have the LIR-pF flag set, the routes
		matched for tracking are Leaf A-D routes whose "route key" field
		is identical to the NLRI of the S-PMSI A-D route.

		2) If the match for transmission route carries a PTA that has the
		LIR-pF flag, the leaf tracking routes are Leaf A-D routes whose
	"route key" field is derived from the NLRI of the S-PMSI A-D	"route key" field is derived from the NLRI of the S-PMSI A-D
	route according to the procedures described in Section 5.2 of	route according to the procedures described in Section 5.2 of

	<xref target="RFC8534"/>.	[RFC8534].
	</t>
	</list>	Current:
	<vspace/>	3. Otherwise, the route matched for transmission is the S-PMSI A-D
	<vspace/>	route originated by the ingress PE for the BD, whose source and
		destination address fields match the packet's source and
		destination IP address and have a PTA specifying a valid tunnel
		type that is not "no tunnel info". Leaf-tracking routes are
		determined as follows:

		a. If the match for the transmission route carries a PTA that
		has the LIR flag set but does not have the LIR-pF flag set,
		the routes matched for tracking are Leaf A-D routes whose
		Route Key field is identical to the NLRI of the S-PMSI A-D
		route.

		b. If the match for the transmission route carries a PTA that
		has the LIR-pF flag, the leaf-tracking routes are Leaf A-D
		routes whose Route Key field is derived from the NLRI of the
		S-PMSI A-D route according to the procedures described in
		Section 5.2 of [RFC8534].
		-->

		<!-- <ol spacing="normal" type="%d)"><li>-->
		<ol spacing="normal" type="a"><li>
		<t>If the match for the transmission route carries a PTA that
		has the LIR
		flag set but does not have the LIR-pF flag set, the routes matched fo
		r
		tracking are Leaf A-D routes whose Route Key field is identical to
		the NLRI of the S-PMSI A-D route.
		</t>
		</li>
		<li>
		<t>If the match for the transmission route carries a PTA that
		has the LIR-pF
		flag, the leaf-tracking routes are Leaf A-D routes whose
		Route Key field is derived from the NLRI of the S-PMSI A-D
		route according to the procedures described in <xref target="RFC8534"
		section="5.2" sectionFormat="of" format="default"/>.
		</t>
		</li>
		</ol>
		<t>
	Note that in both cases, SMET routes may be used in lieu of	Note that in both cases, SMET routes may be used in lieu of
	Leaf A-D routes, as a PE may omit the Leaf A-D route in response to	Leaf A-D routes, as a PE may omit the Leaf A-D route in response to

	an S-PMSI A-D route with LIR or LIR-pF bit set, if an SMET route	an S-PMSI A-D route with the LIR or LIR-pF bit set if a SMET route
	with the corresponding Tag, Source, and Group fields is already	with the corresponding Tag, Source, and Group fields is already

	originated <xref target='I-D.ietf-bess-evpn-bum-procedure-updates'/>.	originated <xref target="RFC9572" format="default"/>.
	In particular, in the second case above, even though the SMET route	In particular, in the second case above, even though the SMET route
	does not have a PTA attached, it is still considered a Leaf A-D	does not have a PTA attached, it is still considered a Leaf A-D
	route in response to a wildcard S-PMSI A-D route with the LIR-pF bit	route in response to a wildcard S-PMSI A-D route with the LIR-pF bit
	set.	set.

	</t>	</t>
	<t>Otherwise, the route matched for transmission and leaf tracking routes ar	</li>
	e	<li>
		<t>Otherwise, the route matched for transmission and leaf-tracking
		routes are
	determined as in rule <xref target="inclusive" format="counter"/>.	determined as in rule <xref target="inclusive" format="counter"/>.

	</t>	</t>
	</list>	</li>
	</t>	</ol>
	<t>If no route is matched for transmission, the packet is not forwarded	<t>If no route is matched for transmission, the packet is not forwarde
		d
	onto a P-tunnel. If the tunnel that the ingress determines to use	onto a P-tunnel. If the tunnel that the ingress determines to use
	based on the route matched for transmission (and considering	based on the route matched for transmission (and considering
	interworking with PEs that do not support certain tunnel types	interworking with PEs that do not support certain tunnel types

	per procedures in <xref target="RFC9251"/>)	per procedures in <xref target="RFC9251" format="default"/>)
	requires leaf tracking (e.g. Ingress Replication, RSVP-TE P2MP tunnel,	requires leaf tracking (e.g., Ingress Replication, RSVP-TE P2MP tunnel,
	or BIER) but there are no leaf tracking routes,	or BIER) but there are no leaf-tracking routes,
	the packet will not be forwarded onto a P-tunnel either.	the packet will not be forwarded onto a P-tunnel either.

	</t>	</t>
	<t>The following text assumes that BIER is the determined tunnel type.	<t>The following text assumes that BIER is the determined tunnel type.
	The ingress PE pushes an upstream-assigned ESI label per <xref target="RF	The ingress PE pushes an upstream-assigned ESI label per <xref target="RF
	C7432"/>	C7432" format="default"/>
	if the following conditions are all met:	if the following conditions are all met:

	<list style="symbols">	</t>
	<t>The packet is received on a multihomed ES.	<ul spacing="normal">
	</t>	<li>
	<t>It's EVPN-MPLS.	<t>The packet is received on a multihomed ES.
	</t>	</t>
	<t>ESI label procedure is used for split-horizon.	</li>
	</t>	<li>
	</list>	<t>It is EVPN-MPLS.
	</t>	</t>
	<t>The MPLS label from the PTA of the route matched	</li>
		<li>
		<t>The ESI label procedure is used for split horizon.
		</t>
		</li>
		</ul>
		<t>The MPLS label from the PTA of the route matched
	for transmission is then pushed onto the packet's label stack for	for transmission is then pushed onto the packet's label stack for
	EVPN-MPLS. For EVPN-VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is pr epended to	EVPN-MPLS. For EVPN-VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is pr epended to

	the packet with the VNI/VSID set to the value in the PTA's label field,	the packet with the VNI/VSID set to the value in the PTA's Label field,
	and then an IP/UDP header is prepended if needed (e.g. for PHP purpose).	and then an IP/UDP header is prepended if needed (e.g., for PHP purposes)
	</t>	.
	<t>Then the packet is encapsulated in a BIER	</t>
	header and forwarded, according to the procedures of	<t>Then, the packet is encapsulated in a BIER
	<xref target='RFC8279'/> and <xref target='RFC8296'/>.	header and forwarded according to the procedures of
	See especially Section 4, "Imposing and Processing	<xref target="RFC8279" format="default"/> and <xref target="RFC8296" form
	the BIER Encapsulation", of <xref target='RFC8296'/>.	at="default"/>.
	The "Proto" field in the BIER header is set to 2 in the case of EVPN-MPLS	Specifically, see "Imposing and Processing
	,	the BIER Encapsulation" (<xref target="RFC8296" format="default" sectionF
	or a value to be assigned in the case of EVPN-VXLAN/NVGRE/GENEVE (<xref	ormat="of" section="3"/>).
	target="IANA"/>) when an IP header is not used, or 4/6 if an IP header is	The Proto field in the BIER header is set to 2 in the case of EVPN-MPLS,
	used	a value to be assigned in the case of EVPN-VXLAN/NVGRE/GENEVE (<xref targ
		et="IANA" format="default"/>) when an IP header is not used, or 4/6 if an IP hea
		der is used
	for EVPN-VXLAN/NVGRE/GENEVE.	for EVPN-VXLAN/NVGRE/GENEVE.

	</t>	</t>
	<t>To create the proper BIER header for a given packet, the	<t>To create the proper BIER header for a given packet, the
	BFIR must know all the BFERs that need to receive that packet.	BFIR must know all the BFERs that need to receive that packet.

	This is determined from the set of leaf tracking routes.	This is determined from the set of leaf-tracking routes.
	</t>	</t>
	</section>	</section>
	<section title="At a BFIR that is a P-tunnel Segmentation Point">	<section numbered="true" toc="default">
	<t>In this case, the encapsulation for the upstream segment of the P-tunnel	<name>At a BFIR That Is a P-Tunnel Segmentation Point</name>
		<t>In this case, the encapsulation for the upstream segment of the P-t
		unnel
	includes (among other things) a label that identifies the x-PMSI or	includes (among other things) a label that identifies the x-PMSI or
	IMET A-D route that	IMET A-D route that
	is the match for reception on the upstream segment. The segmentation poin t	is the match for reception on the upstream segment. The segmentation poin t
	re-advertised the route into one or more downstream regions. Each	re-advertised the route into one or more downstream regions. Each
	instance of the re-advertised route for a downstream region has a PTA	instance of the re-advertised route for a downstream region has a PTA
	that specifies the tunnel for that region. For any particular downstream	that specifies the tunnel for that region. For any particular downstream

	region, the route matched for transmission is the re-advertised route	region, the route matched for transmission is the re-advertised route,
	and the leaf tracking routes are determined as follows if needed	and the leaf-tracking routes are determined as follows, if needed,
	for the tunnel type:	for the tunnel type:

	<list style="symbols">	</t>
	<t>If the route matched for transmission is an x-PMSI route, it must have	<ul spacing="normal">
	the LIR flag set in its PTA and the leaf tracking routes are all the	<li>
		<t>If the route matched for transmission is an x-PMSI route, it mu
		st have
		the LIR flag set in its PTA, and the leaf-tracking routes are all the
	matching Leaf A-D and SMET routes received in the downstream region.	matching Leaf A-D and SMET routes received in the downstream region.

	</t>	</t>
	<t>If the route matched for transmission is an IMET route, the leaf tracking	</li>
		<li>
		<t>If the route matched for transmission is an IMET route, the lea
		f-tracking
	routes are all the IMET routes for the same BD received in the downstream	routes are all the IMET routes for the same BD received in the downstream
	region.	region.

	</t>	</t>
	</list>	</li>
	</t>	</ul>
	<t>If the downstream region uses BIER, the packet is forwarded as follows:	<t>If the downstream region uses BIER, the packet is forwarded as foll
		ows:
	the upstream segmentation's encapsulation is removed and the	the upstream segmentation's encapsulation is removed and the
	above-mentioned label is swapped to the	above-mentioned label is swapped to the
	upstream-assigned label in the PTA of the route matched for transmission,	upstream-assigned label in the PTA of the route matched for transmission,

	and then a BIER header is imposed as in <xref target="ingresspe"/>.	and then a BIER header is imposed as in <xref target="ingresspe" format="
	</t>	default"/>.
	</section>	</t>
	</section>	</section>
	<section title="Disposition">	</section>
	<t>The same procedures in section 4.2 of <xref target='RFC8556'/>	<section numbered="true" toc="default">
	are followed for EVPN-MPLS, except some EVPN specifics discussed in	<name>Disposition</name>
	the following two sub-sections in this document.	<t>The same procedures in <xref target="RFC8556" section="4.2" sectionFo
	</t>	rmat="of" format="default"/>
	<t>For EVPN-VXLAN/NVGRE/GENEVE, the only difference is that the payload is	are followed for EVPN-MPLS, except for some EVPN specifics that are discu
		ssed in
		the following two subsections of this document.
		</t>
		<t>For EVPN-VXLAN/NVGRE/GENEVE, the only differences are that the payloa
		d is
	VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID	VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID
	field in the VXLAN/NVGRE/GENEVE header is used to determine the correspon ding	field in the VXLAN/NVGRE/GENEVE header is used to determine the correspon ding
	broadcast domain.	broadcast domain.

	</t>	</t>
	<section title="At a BFER that is an Egress PE">	<section numbered="true" toc="default">
	<t>Once the corresponding broadcast domain is determined from	<name>At a BFER That Is an Egress PE</name>
		<t>Once the corresponding broadcast domain is determined from
	the upstream-assigned label or VNI/VSID, EVPN forwarding procedures per	the upstream-assigned label or VNI/VSID, EVPN forwarding procedures per

	<xref target="RFC7432"/> or <xref target='RFC8365'/> are followed.	<xref target="RFC7432" format="default"/> or <xref target="RFC8365" forma t="default"/> are followed.
	In the case of EVPN-MPLS, if there is an inner label in the label stack	In the case of EVPN-MPLS, if there is an inner label in the label stack
	following the BIER header, that inner label is considered the	following the BIER header, that inner label is considered the

	upstream-assigned ESI label for split horizon purpose.	upstream-assigned ESI label for split-horizon purposes.
	</t>
	</section>
	<section title="At a BFER that is a P-tunnel Segmentation Point">
	<t>This is only applicable to EVPN-MPLS. The same procedures in
	Section 4.2.2 of <xref target='RFC8556'/> are followed,
	subject to multihoming procedures specified in
	<xref target='I-D.ietf-bess-evpn-bum-procedure-updates'/>.
	</t>
	</section>
	</section>
	</section>
	<section anchor="IANA" title="IANA Considerations">
	<t>This document requests three assignments in
	"BIER Next Protocol Identifiers" registry, with the following three
	recommended values:
	<list style="symbols">
	<t>7: Payload is VXLAN encapsulated (no IP/UDP header)
	</t>
	<t>8: Payload is NVGRE encapsulated (no IP header)
	</t>	</t>

	<t>9: Payload is GENEVE encapsulated (no IP/UDP header)	</section>
		<section numbered="true" toc="default">
		<name>At a BFER That Is a P-Tunnel Segmentation Point</name>
		<t>This is only applicable to EVPN-MPLS. The same procedures in
		<xref target="RFC8556" section="4.2.2" sectionFormat="of" format="default
		"/> are followed,
		subject to multihoming procedures specified in
		<xref target="RFC9572" format="default"/>.
	</t>	</t>

	</list>	</section>
	</t>	</section>
	<t>This document requests assignments of an IPv4 and an IPv6 multicast	</section>
	address for the case discussed in <xref target="php-address"/>.	<section anchor="IANA" numbered="true" toc="default">
	Preferably this is assigned from the Local Network Control Block	<name>IANA Considerations</name>
	(224.0.0/24) for IPv4 and Link-Local Scope Multicast Addresses	<t>Per this document, IANA has registered the following three values in th
	for IPv6. The description is "NVO BUM Traffic".	e
		"BIER Next Protocol Identifiers" registry:
	</t>	</t>

		<table align="center">
		<name>BIER Next Protocol Identifiers Registry</name>
		<thead>
		<tr>
		<th>Value</th>
		<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>7</td>
		<td>Payload is VXLAN encapsulated (no IP/UDP header)</td>
		<td>RFC 9624</td>
		</tr>
		<tr>
		<td>8</td>
		<td>Payload is NVGRE encapsulated (no IP header)</td>
		<td>RFC 9624</td>
		</tr>
		<tr>
		<td>9</td>
		<td>Payload is GENEVE encapsulated (no IP/UDP header)</td>
		<td>RFC 9624</td>
		</tr>
		</tbody>
		</table>
		<t>IANA has also assigned an IPv4 and an IPv6 multicast
		address for the case discussed in <xref target="php-address" format="defau
		lt"/>.</t>

		<t>
		The following entry has been added to the "Local Network Control Block (22
		4.0.0.0 - 224.0.0.255 (224.0.0/24))" registry for IPv4:</t>

		<dl spacing="compact">
		<dt>Address(es):</dt><dd> 224.0.0.122</dd>
		<dt>Description:</dt><dd> Network Virtualization Overlay (NVO) BUM Traffic
		</dd>
		<dt>Reference:</dt><dd> RFC 9624</dd>
		</dl>
		<t>
		The following entry has been added to the "Link-Local Scope Multicast Addresses"
		registry for IPv6:</t>

		<dl spacing="compact">
		<dt>Address(es):</dt><dd>FF02:0:0:0:0:0:0:14</dd>
		<dt>Description:</dt><dd> Network Virtualization Overlay (NVO) BUM Traffic
		</dd>
		<dt>Reference:</dt><dd> RFC 9624</dd>
		</dl>

	</section>	</section>

	<section anchor="Security" title="Security Considerations">	<section anchor="Security" numbered="true" toc="default">
		<name>Security Considerations</name>
	<t>This document is about using BIER as provider tunnels for EVPN.	<t>This document is about using BIER as provider tunnels for EVPN.

	It is very similar to using BIER as MVPN provider tunnel, and	It is very similar to using BIER as MVPN provider tunnels and
	does not introduce additional security implications	does not introduce additional security implications

	beyond what have been discussed in EVPN base protocol specification	beyond what have been discussed in the EVPN base protocol specification
	<xref target="RFC7432"/> and MVPN using BIER <xref target="RFC8556"/>.	<xref target="RFC7432" format="default"/> and MVPN using BIER <xref tar
	</t>	get="RFC8556" format="default"/>.
	</section>
	<section anchor="Acknowledgements" title="Acknowledgements">
	<t>The authors thank Eric Rosen for his review and suggestions.
	Additionally, much of the text is borrowed verbatim from
	<xref target='RFC8556'/>.
	</t>	</t>
	</section>	</section>
	</middle>	</middle>

	<back>	<back>

	<references title="Normative References">	<displayreference target="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" to=
	<?rfc include='reference.RFC.2119.xml'?>	"CMCAST-ENHANCEMENTS"/>
	<?rfc include='reference.RFC.8174.xml'?>	<displayreference target="I-D.ietf-bier-php" to="BIER-PHP"/>
	<?rfc include='reference.RFC.7900.xml'?>	<references>
	<?rfc include='reference.RFC.6625.xml'?>	<name>References</name>
	<?rfc include='reference.RFC.7432.xml'?>	<references>
	<?rfc include='reference.RFC.8279.xml'?>	<name>Normative References</name>
	<?rfc include='reference.RFC.8296.xml'?>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<?rfc include='reference.RFC.8556.xml'?>	119.xml"/>
	<?rfc include='reference.RFC.8534.xml'?>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<?rfc include='reference.RFC.9251.xml'?>	174.xml"/>
	<?rfc include='reference.RFC.8365.xml'?>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<?rfc include='reference.RFC.8926.xml'?>	900.xml"/>
	<?rfc include='reference.RFC.6513.xml'?>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<?rfc include='reference.RFC.6514.xml'?>	625.xml"/>
	<?rfc include='reference.I-D.ietf-bess-evpn-bum-procedure-updates.xml'?>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	</references>	432.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		279.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.8
		556.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		534.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.8
		365.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		926.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"/>


	<references title="Informative References">	<!-- [I-D.ietf-bess-evpn-bum-procedure-updates is now RFC 9572-->
	<?rfc include='reference.I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements.xml	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
	'?>	72.xml"/>
	<?rfc include='reference.I-D.ietf-bier-php.xml'?>
	<?rfc include='reference.RFC.7348.xml'?>	</references>
	<?rfc include='reference.RFC.7637.xml'?>	<references>
	<?rfc include='reference.RFC.4875.xml'?>	<name>Informative References</name>
	<?rfc include='reference.RFC.6388.xml'?>
		<!-- [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] IESG State - I-D Exists as
		of 7/24/24.
		Long way used to fix initials-->
		<reference anchor="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" target="https:
		//datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-
		04">
		<front>
		<title>MVPN/EVPN C-Multicast Routes Enhancements</title>
		<author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
		<organization>Juniper Networks</organization>
		</author>
		<author initials="R." surname="Kebler" fullname="Robert Kebler">
		<organization>Juniper Networks</organization>
		</author>
		<author initials="W." surname="Lin" fullname="Wen Lin">
		<organization>Juniper Networks</organization>
		</author>
		<author initials="E." surname="Rosen" fullname="Eric C. Rosen"> </author>
		<date month="March" day="17" year="2024"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-zzhang-bess-mvpn-evpn-cmcast-enha
		ncements-04"/>
		</reference>

		<!-- [I-D.ietf-bier-php] IESG State - Publication Requested as of 07/24/24.
		Long way used to fix initials -->
		<reference anchor="I-D.ietf-bier-php" target="https://datatracker.ietf.org/doc/h
		tml/draft-ietf-bier-php-11">
		<front>
		<title>BIER Penultimate Hop Popping</title>
		<author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
		<organization>Juniper Networks</organization>
		</author>
		<date month="February" day="6" year="2024"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-bier-php-11"/>
		</reference>

		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		348.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		637.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
		875.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		388.xml"/>
		</references>
	</references>	</references>

		<section anchor="Acknowledgements" numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t>The authors thank <contact fullname="Eric Rosen"/> for his review and s
		uggestions.
		Additionally, much of the text is borrowed verbatim from
		<xref target="RFC8556" format="default"/>.
		</t>
		</section>

		<!--[rfced] We notice some hidden text in the XML file. Note that it
		will be deleted upon publication unless we hear otherwise from
		the authors.
		-->

		<!--[rfced] Throughout the text, "IP Multicast" and "IP multicast" appear
		to be used inconsistently. Please review these occurrences and let us know
		if/how they may be made consistent.
		-->

		<!--[rfced] Acronyms

		a) FYI - We have added expansions for the following abbreviations
		per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
		expansion in the document carefully to ensure correctness.

		Provider Edge (PE)
		VPN Routing and Forwarding (VRF)

		b) Does the "x" in "x-PMSI" have an expansion?

		c) Should "LIR" be expanded as "Leaf Info Required" instead of "Leaf Info
		Required Bit (LIR)" to parallel "Leaf Info Required per Flow (LIR-pF)"?

		d) Can the description/expansion for "mLDP-P2MP" be updated to more
		closely match the acronym as shown below (option A)? Or if you want
		to retain the wording, should "MP2MP" be added to represent
		"Multipoint-to-Multipoint" (option B)?

		Original:
		mLDP-P2MP [RFC6388]: Label Distribution Protocol Extensions for
		Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths.

		Perhaps:
		A) mLDP-P2MP: Multipoint Label Distribution Protocol extensions
		for Point-to-Multipoint LSPs [RFC6388].
		or

		B) mLDP-P2MP-MP2MP: Multipoint Label Distribution Protocol extensions
		for Point-to-Multipoint and Multipoint-to-Multipoint LSPs [RFC6388].

		e) To match the other documents in this cluster, may we update the expansion
		of "BUM" to use "or" instead of "and"?

		Original:
		broadcast, unknown unicast and multicast (BUM)

		Perhaps:
		Broadcast, Unknown Unicast, or Multicast (BUM)

		f) In RFC 9574, "VSID" is expanded as "Virtual Segment Identifier"; this
		document expands it as "Virtual Subnet IDentifier". Should this document
		be updated to match RFC 9574?

		g) Section 5. In the descriptions under the "Local Network Control Block
		(224.0.0.0 - 224.0.0.255 (224.0.0/24))" and "Link-Local Scope Multicast
		Addresses" registries, we expanded "NVO" as "Network Virtualization
		Overlay" as shown below. If there are no objections, we will ask IANA to
		update their registries accordingly.

		Current:
		Address(es): 224.0.0.122
		Description: Network Virtualization Overlay (NVO) BUM Traffic
		Reference: RFC 9624

		Address(es): FF02:0:0:0:0:0:0:14
		Description: Network Virtualization Overlay (NVO) BUM Traffic
		Reference: RFC 9624

		h) May we update all instances of "broadcast domain" to "BD" after this
		acronym has been expanded at its first occurrence?
		-->

		<!-- [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.

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

	</back>	</back>
	</rfc>	</rfc>

End of changes. 108 change blocks.
	453 lines changed or deleted	882 lines changed or added
This html diff was produced by rfcdiff 1.48.