Diff: rfc9572xml2.original.xml

	rfc9572xml2.original.xml	rfc9572.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<!DOCTYPE rfc [
	.2119.xml">	<!ENTITY nbsp " ">
	<!ENTITY RFC7117 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<!ENTITY zwsp "">
	.7117.xml">	<!ENTITY nbhy "‑">
	<!ENTITY RFC7432 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<!ENTITY wj "⁠">
	.7432.xml">
	<!ENTITY RFC7524 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.7524.xml">
	<!ENTITY RFC6513 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6513.xml">
	<!ENTITY RFC6514 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6514.xml">
	<!ENTITY RFC7988 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.7988.xml">
	<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8174.xml">
	<!ENTITY RFC8279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8279.xml">
	<!ENTITY RFC8584 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8584.xml">
	<!ENTITY RFC8534 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8534.xml">
	<!ENTITY RFC4875 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.4875.xml">
	<!ENTITY RFC4684 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.4684.xml">
	<!ENTITY RFC6388 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6388.xml">
	]>	]>

	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>
	<?rfc tocdepth="3"?>
	<?rfc tocindent="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc strict="no"?>
	<?rfc rfcedstyle="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="std" updates="7432" docName="draft-ietf-bess-evpn-bum-procedure-u
	pdates-14" ipr="trust200902">
	<front>
	<title abbrev="evpn-bum-procedure-update">Updates on EVPN BUM Procedures</ti
	tle>


		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" updates="7432" docName="draft-ie
		tf-bess-evpn-bum-procedure-updates-14" number="9572" ipr="trust200902" obsoletes
		="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclu
		de="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

		<!-- xml2rfc v2v3 conversion 3.12.0 -->
		<front>
		<title abbrev="EVPN BUM Procedures: Updates">Updates to EVPN Broadcast, Unkn
		own Unicast, or Multicast (BUM) Procedures</title>
		<seriesInfo name="RFC" value="9572"/>
	<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="Wen Lin" initials="W." surname="Lin">	<author fullname="Wen Lin" initials="W." surname="Lin">
	<organization>Juniper Networks</organization>	<organization>Juniper Networks</organization>
	<address>	<address>
	<email>wlin@juniper.net</email>	<email>wlin@juniper.net</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>


	<author fullname="Keyur Patel" initials="K." surname="Patel">	<author fullname="Keyur Patel" initials="K." surname="Patel">
	<organization>Arrcus</organization>	<organization>Arrcus</organization>
	<address>	<address>
	<email>keyur@arrcus.com</email>	<email>keyur@arrcus.com</email>
	</address>	</address>
	</author>	</author>


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

		<date year="2024" month="May" />
	<date year="2021"/>	<area>rtg</area>

	<workgroup>BESS</workgroup>	<workgroup>BESS</workgroup>


		<keyword>per-region I-PMSI</keyword>
		<keyword>selective multicast forwarding</keyword>
		<keyword>tunnel segmentation</keyword>
		<keyword>inter-AS segmentation</keyword>
		<keyword>inter-region segmentation</keyword>

	<abstract>	<abstract>
	<t>This document specifies updated procedures for handling	<t>This document specifies updated procedures for handling

	broadcast, unknown unicast, and multicast (BUM) traffic in	Broadcast, Unknown Unicast, or Multicast (BUM) traffic in
	Ethernet VPNs (EVPN), including selective multicast,	Ethernet VPNs (EVPNs), including selective multicast
	and provider tunnel segmentation. This document updates RFC 7432.	and segmentation of provider tunnels. This document updates RFC 7432.
	</t>	</t>
	</abstract>	</abstract>


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


	<middle>	<middle>

	<section title="Terminology">	<section numbered="true" toc="default">
	<t>It is expected that audience is familiar with MVPN [RFC6513] [RFC6514], V	<name>Introduction</name>
	PLS Multicast [RFC7117] and EVPN [RFC7432] concepts and	<t><xref target="RFC7117" format="default"/> specifies procedures for mult
	terminologies. For convenience, the following terms are briefly	icast in the Virtual Private LAN
		Service (VPLS multicast), using both inclusive tunnels and
		selective tunnels with or without inter-AS segmentation, similar to the
		Multicast VPN (MVPN) procedures specified in <xref target="RFC6513" forma
		t="default"/> and <xref target="RFC6514" format="default"/>.
		<xref target="RFC7524" format="default"/> specifies inter-area tunnel seg
		mentation procedures for
		both VPLS multicast and MVPNs.
		</t>
		<t><xref target="RFC7432" format="default"/> specifies BGP MPLS-based Ethe
		rnet VPN (EVPN) procedures,
		including those handling Broadcast, Unknown Unicast, or Multicast
		(BUM) traffic. <xref target="RFC7432"/> refers to <xref target="RFC7117"
		format="default"/> for details but leaves a few feature gaps related to selectiv
		e tunnel and tunnel segmentation (<xref target="motivation"/>).
		</t>
		<t>This document aims to fill in those gaps by covering the use of selecti
		ve
		and segmented tunnels in EVPNs.
		In the same way that <xref target="RFC7432"/> refers to <xref target="RFC
		7117" format="default"/> for details, this document only specifies differences f
		rom relevant procedures provided in <xref target="RFC7117" format="default"/> an
		d <xref target="RFC7524" format="default"/>, rather than repeating the text from
		those documents.
		Note that these differences are applicable to EVPNs only
		and are not updates to <xref target="RFC7117" format="default"/> or <xref
		target="RFC7524" format="default"/>.
		</t>
		<t>MVPN, VPLS, and EVPN technologies all need to discover other Provider E
		dges (PEs) in the
		same L3/L2 VPN and announce the inclusive tunnels. MVPN technology introd
		uced
		the Inclusive P-Multicast Service Interface (I-PMSI) concept and uses I-P
		MSI Auto-Discovery (A-D) routes for that purpose.
		EVPN technology uses Inclusive Multicast Ethernet Tag (IMET) A-D routes,
		but VPLS technology just adds a PMSI Tunnel Attribute (PTA) to an existin
		g
		VPLS A-D route for that purpose. For selective tunnels, they all
		do use the same term: Selective PMSI (S-PMSI) A-D routes.
		</t>
		<t>This document often refers to the I-PMSI concept, which is
		the same for all three technologies. For consistency and convenience,
		an EVPN's IMET A-D route and a VPLS's VPLS A-D route carrying a PTA for B
		UM traffic
		purposes may each be referred to as an I-PMSI A-D route, depending on the
		context.
		</t>
		<section numbered="true" toc="default">
		<name>Requirements Language</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>
		<section numbered="true" toc="default">
		<name>Terminology</name>
		<t>It is assumed that the reader is familiar with concepts and terminologi
		es related to MVPN technology <xref target="RFC6513" format="default"/> <xref ta
		rget="RFC6514" format="default"/>, VPLS multicast <xref target="RFC7117" format=
		"default"/>, and EVPN technology <xref target="RFC7432" format="default"/>. For
		convenience, the following terms are briefly
	explained.	explained.

	<list style="symbols">	</t>
	<t>PMSI [RFC6513]: P-Multicast Service Interface - a conceptual interface	<dl spacing="normal">
	for a PE	<dt>AS:</dt><dd>Autonomous System</dd>
		<dt>PMSI <xref target="RFC6513" format="default"/>:</dt><dd>P-Multicast
		Service Interface. A conceptual interface for 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>	<dt>I-PMSI:</dt><dd>Inclusive PMSI. Enables traffic to be sent to all PE
	<t>I-PMSI: Inclusive PMSI - to all PEs in the same VPN.	s in the same VPN.</dd>
	</t>	<dt>S-PMSI:</dt><dd>Selective PMSI. Enables traffic to be sent to some o
	<t>S-PMSI: Selective PMSI - to some of the PEs in the same VPN.	f the PEs in the same VPN.</dd>
	</t>	<dt>I/S-PMSI A-D Route:</dt><dd>Auto-Discovery route used to announce th
	<t>I/S-PMSI A-D Route: Auto-Discovery routes used to announce the tunn	e tunnels that instantiate an I/S-PMSI.</dd>
	els that instantiate an I/S-PMSI.	<dt>Leaf Auto-Discovery (A-D) Route <xref target="RFC6513" format="defau
	</t>	lt"/>:</dt><dd>For explicit leaf-tracking purposes.
	<t>Leaf Auto-Discovery (A-D) routes [RFC6513]: For explicit leaf tracking	Triggered by I/S-PMSI A-D routes and targeted at the triggering
	purpose.	route's (re-)advertiser. Its Network Layer
	Triggered by I/S-PMSI A-D routes and targeted at triggering	Reachability Information (NLRI) embeds the entire NLRI of the triggering PMSI
	route's (re-)advertiser. Its NLRI embeds the entire NLRI of the trigge	A-D route.</dd>
	ring PMSI A-D route.	<dt>IMET A-D Route <xref target="RFC7432" format="default"/>:</dt><dd>In
	</t>	clusive Multicast Ethernet Tag A-D route.
	<t>IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D route.	The EVPN equivalent of an MVPN Intra-AS I-PMSI A-D route
	The EVPN equivalent of MVPN Intra-AS I-PMSI A-D route	used to announce the tunnels that instantiate an I-PMSI.</dd>
	used to announce the tunnels that instantiate an I-PMSI.	<dt>SMET A-D Route <xref target="RFC9251" format="default"/>:</dt>
	</t>	<dd>Selective Multicast Ethernet Tag A-D route. The EVPN
	<t>SMET A-D route <xref target="I-D.ietf-bess-evpn-igmp-mld-proxy"/>:	equivalent of an MVPN Leaf A-D route, but unsolicited and untargeted.<
	Selective Multicast Ethernet Tag A-D route. The EVPN	/dd>
	equivalent of MVPN Leaf A-D route but unsolicited and untargeted.	<dt>PMSI Tunnel Attribute (PTA):</dt><dd>An optional transitive BGP attr
	</t>	ibute
	<t>PMSI Tunnel Attribute (PTA): An optional transitive BGP attribute
	that may be attached to PMSI/Leaf A-D routes to provide	that may be attached to PMSI/Leaf A-D routes to provide

	information for a PMSI tunnel.	information for a PMSI tunnel.</dd>
	</t>	<dt>IBGP:</dt><dd>Internal BGP (BGP connection between internal peers).<
	</list>	/dd>
	</t>	<dt>EBGP:</dt><dd>External BGP (BGP connection between external peers).<
		/dd>
		<dt>RT:</dt><dd>Route Target. Controls route importation and propagation
		.</dd>
		</dl>
	</section>	</section>

	<section title="Introduction">	</section>
	<t>[RFC7117] specifies procedures for Multicast in Virtual Private LAN	<section anchor="segmentation" numbered="true" toc="default">
	Service (VPLS Multicast) using both inclusive tunnels and	<name>Tunnel Segmentation</name>
	selective tunnels with or without inter-as segmentation, similar to the	<t>MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are
	Multicast VPN (MVPN) procedures specified in [RFC6513] and [RFC6514].
	[RFC7524] specifies inter-area tunnel segmentation procedures for
	both VPLS Multicast and MVPN.
	</t>
	<t>[RFC7432] specifies BGP MPLS-Based Ethernet VPN (EVPN) procedures,
	including those handling broadcast, unknown unicast, and multicast
	(BUM) traffic. A lot of details are referred to [RFC7117], yet
	with quite some feature gaps like selective tunnel and tunnel
	segmentation (<xref target="segmentation"/>).
	</t>
	<t>This document aims at filling the gaps - cover the use of selective
	and segmented tunnels in EVPN. It follows the same editorial choice
	as in RFC7432 and only specifies differences from relevant procedures
	in [RFC7117] and [RFC7524], instead of repeating the text.
	Note that these differences are applicable to EVPN only,
	and are not updates to [RFC7117] or [RFC7524].
	</t>
	<t>MVPN, VPLS and EVPN all have the need to discover other PEs in the
	same L3/L2 VPN and announce the inclusive tunnels. MVPN introduced
	the I-PMSI concept and uses I-PMSI A-D route for that.
	EVPN uses Inclusive Multicast Ethernet Tag Route (IMET) A-D route
	but VPLS just adds an PMSI Tunnel Attribute (PTA) to the existing
	VPLS A-D route for that purpose. For selective tunnels, they all
	do use the same term S-PMSI A-D routes.
	</t>
	<t>Many places of this document involve the I-PMSI concept that is all
	the same for all three technologies. For consistency and convenience,
	EVPN's IMET and VPLS's VPLS A-D route carrying PTA for BUM traffic
	purpose may all be referred to as I-PMSI A-D routes depending on the
	context.
	</t>
	<!--t>MVPN uses terms I-PMSI and S-PMSI A-D Routes. For
	consistency and convenience, this document will use the same I/S-PMSI
	terms for VPLS and EVPN. In particular, EVPN's Inclusive Multicast
	Ethernet Tag Route and VPLS's VPLS A-D route carrying PTA
	(PMSI Tunnel Attribute) for BUM traffic purpose will all be referred
	to as I-PMSI A-D routes. Depending on the context, they may be used
	interchangeably.
	</t-->
	<section title="Tunnel Segmentation" anchor="segmentation">
	<t>MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are
	referred to as MVPN/EVPN/VPLS provider tunnels in this document for	referred to as MVPN/EVPN/VPLS provider tunnels in this document for
	simplicity, can be segmented for technical or administrative reasons,	simplicity, can be segmented for technical or administrative reasons,

	which are summarized in <xref target="motivation"/> of this document.	which are summarized in <xref target="motivation" format="default"/> of t
	[RFC6513] and [RFC6514] cover MVPN inter-as segmentation,	his document.
	[RFC7117] covers	<xref target="RFC6513" format="default"/> and <xref target="RFC6514" form
	VPLS multicast inter-as segmentation, and [RFC7524] (Seamless MPLS	at="default"/> cover MVPN inter-AS segmentation,
	Multicast) covers inter-area segmentation for both MVPN and VPLS.	<xref target="RFC7117" format="default"/> covers
	</t>	VPLS multicast inter-AS segmentation, and <xref target="RFC7524" format="
	<t>With tunnel segmentation, different segments of an end-to-end tunnel	default"/> (seamless MPLS
	may have different encapsulation overhead. However, the largest overhead	multicast) covers inter-area segmentation for both MVPNs and VPLSs.
		</t>
		<t>With tunnel segmentation, different segments of an end-to-end tunnel
		may have different encapsulation overheads. However, the largest overhead
	of the tunnel caused by an encapsulation method on a particular segment	of the tunnel caused by an encapsulation method on a particular segment
	is not different from the case of a non-segmented tunnel with that	is not different from the case of a non-segmented tunnel with that
	encapsulation method. This is similar to the case of a network	encapsulation method. This is similar to the case of a network
	with different link types.	with different link types.

	</t>	</t>
	<t>There is a difference between MVPN and VPLS multicast inter-as	<t>There is a difference between MVPN and VPLS multicast inter-AS
	segmentation (the VPLS approach is briefly discribed in <xref target="int	segmentation (the VPLS approach is briefly described in <xref target="int
	eraschanges"/>). For simplicity, EVPN will use the same procedures as	eraschanges" format="default"/>). For simplicity, EVPNs will use the same proced
	in MVPN. All ASBRs can re-advertise	ures as those for
		MVPNs. All ASBRs can re-advertise
	their choice of the best route. Each can become the root of its	their choice of the best route. Each can become the root of its
	intra-AS segment and inject traffic it receives from its upstream,	intra-AS segment and inject traffic it receives from its upstream,
	while each downstream PE/ASBR will only pick one of the upstream ASBRs	while each downstream PE/ASBR will only pick one of the upstream ASBRs

	as its upstream. This is also the behavior even for VPLS in case of	as its upstream. This is also the behavior even for VPLS in the case of
	inter-area segmentation.	inter-area segmentation.

	</t>	</t>
	<t>For inter-area segmentation, [RFC7524] requires the use of Inter-area	<t>For inter-area segmentation, <xref target="RFC7524" format="default"/
	P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting	> requires the use of the Inter-Area
	of "Leaf Information Required" L flag in PTA in certain situations.	Point-to-Multipoint (P2MP) Segmented Next-Hop Extended Community (S-NH-EC
	In the EVPN case, the requirements around S-NH-EC and the PTA "L" flag	) and the setting
	differ from [RFC7524] to make the segmentation procedures transparent to	of the Leaf Information Required (L) flag in the PTA in certain situation
		s.
		In the EVPN case, the requirements around the S-NH-EC and the L flag in t
		he PTA
		differ from <xref target="RFC7524" format="default"/> to make the segment
		ation procedures transparent to
	ingress and egress PEs.	ingress and egress PEs.

	</t>	</t>
	<t>[RFC7524] assumes that segmentation happens at area borders.	<t><xref target="RFC7524" format="default"/> assumes that segmentation h
		appens at area borders.
	However, it could be at "regional" borders, where a region could be a	However, it could be at "regional" borders, where a region could be a
	sub-area, or even an entire AS plus its external links	sub-area, or even an entire AS plus its external links

	(<xref target = "region"/>). That would	(<xref target="region" format="default"/>); this would
	allow for more flexible deployment scenarios (e.g. for single-area	allow for more flexible deployment scenarios (e.g., for single-area
	provider networks). This document extends the inter-area segmentation	provider networks). This document extends the inter-area segmentation con
	to inter-region segmentation for EVPN.	cept
	</t>	to inter-region segmentation for EVPNs.
	<section title="Reasons for Tunnel Segmentation" anchor="motivation">	</t>
	<t>Tunnel segmentation may be required and/or desired because of	<section anchor="motivation" numbered="true" toc="default">
		<name>Reasons for Tunnel Segmentation</name>
		<t>Tunnel segmentation may be required and/or desired for
	administrative and/or technical reasons.	administrative and/or technical reasons.

	</t>	</t>
	<t>For example, an MVPN/VPLS/EVPN network may span multiple providers	<t>For example, an MVPN/VPLS/EVPN may span multiple providers,
	and the end-to-end provider	and the end-to-end provider
	tunnels have to be segmented at and stitched by the ASBRs.	tunnels have to be segmented at and stitched by the ASBRs.
	Different providers may use different tunnel technologies (e.g.,	Different providers may use different tunnel technologies (e.g.,

	provider A uses Ingress Replication [RFC7988], provider B uses RSVP-TE	provider A uses ingress replication <xref target="RFC7988" format="defaul
	P2MP [RFC4875] while provider C uses mLDP [RFC6388]). Even if they use	t"/>, provider B uses RSVP-TE
	the same tunnel technology like RSVP-TE	P2MP <xref target="RFC4875" format="default"/>, and provider C uses Multi
	P2MP, it may be impractical to set up the tunnels across provider	point LDP (mLDP) <xref target="RFC6388" format="default"/>). Even if they use
		the same tunnel technology (e.g., RSVP-TE
		P2MP), it may be impractical to set up the tunnels across provider
	boundaries.	boundaries.

	</t>	</t>
	<t>The same situations may apply between the ASes and/or areas of a	<t>The same situations may apply between the ASes and/or areas of a
	single provider. For example, the backbone area may use RSVP-TE	single provider. For example, the backbone area may use RSVP-TE
	P2MP tunnels while non-backbone areas may use mLDP tunnels.	P2MP tunnels while non-backbone areas may use mLDP tunnels.

	</t>	</t>
	<t>Segmentation can also be used to divide an AS/area into smaller regions,	<t>Segmentation can also be used to divide an AS/area into smaller reg
		ions,
	so that control plane state and/or forwarding plane state/burden can be	so that control plane state and/or forwarding plane state/burden can be

	limited to that of individual regions. For example, instead of Ingress	limited to that of individual regions. For example, instead of
	Replicating to 100 PEs in the entire AS, with inter-area segmentation	ingress-replicating to 100 PEs in the entire AS, with inter-area segmenta
	[RFC7524] a PE only needs to replicate to local PEs and ABRs.	tion
		<xref target="RFC7524" format="default"/>, a PE only needs to replicate t
		o local PEs and Area Border Routers (ABRs).
	The ABRs will further replicate to their downstream PEs and ABRs.	The ABRs will further replicate to their downstream PEs and ABRs.
	This not only reduces the forwarding plane burden, but also reduces	This not only reduces the forwarding plane burden, but also reduces

	the leaf tracking burden in the control plane.	the leaf-tracking burden in the control plane.
	</t>	</t>
	<t>Smaller regions also have the benefit that, in case of tunnel	<t>In the case of tunnel aggregation, smaller regions provide the bene
	aggregation, it is easier to find congruence among the segments of	fit of
		making it easier to find congruence among the segments of
	different constituent (service) tunnels and the resulting aggregation	different constituent (service) tunnels and the resulting aggregation
	(base) tunnel in a region. This leads to better bandwidth efficiency,	(base) tunnel in a region. This leads to better bandwidth efficiency,
	because the more congruent they are, the fewer leaves of the base	because the more congruent they are, the fewer leaves of the base
	tunnel need to discard traffic when a service tunnel's segment	tunnel need to discard traffic when a service tunnel's segment
	does not need to receive the traffic (yet it is receiving the traffic	does not need to receive the traffic (yet it is receiving the traffic
	due to aggregation).	due to aggregation).

	</t>	</t>
	<t>Another advantage of the smaller region is smaller BIER [RFC8279]	<t>Another advantage of the smaller region is smaller Bit Index
	sub-domains. With BIER, packets carry a BitString,	Explicit Replication (BIER) subdomains <xref target="RFC8279" format="def
	in which the bits correspond to edge routers that needs to receive	ault"/>.
	traffic. Smaller sub-domains means smaller BitStrings can be used	With BIER, packets carry a BitString,
		in which the bits correspond to edge routers that need to receive
		traffic. Smaller subdomains means that smaller BitStrings can be used
	without having to send multiple copies of the same packet.	without having to send multiple copies of the same packet.

	</t>	</t>
	<!--
	<t>Finally, EVPN tunnel segmentation can be used for EVPN DCIs,
	as discussed in <xref target="dci"/>. It follows the same concepts
	discussed above.
	</t>
	</section>
	</section>
	</section>	</section>

	<section title="Additional Route Types of EVPN NLRI" anchor="routes">	</section>
	<t>[RFC7432] defines the format of EVPN NLRI as the following:	<section anchor="routes" numbered="true" toc="default">
	<figure>	<name>Additional Route Types of EVPN NLRI</name>
	<artwork>	<t><xref target="RFC7432" format="default"/> defines the format of EVPN NL
		RI as follows:
		</t>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	+-----------------------------------+	+-----------------------------------+
	\| Route Type (1 octet) \|	\| Route Type (1 octet) \|
	+-----------------------------------+	+-----------------------------------+
	\| Length (1 octet) \|	\| Length (1 octet) \|
	+-----------------------------------+	+-----------------------------------+
	\| Route Type specific (variable) \|	\| Route Type specific (variable) \|
	+-----------------------------------+	+-----------------------------------+

	</artwork>	]]></artwork>
	</figure>	<t>
	So far eight route types have been defined in [RFC7432],	So far, eight route types have been defined in <xref target="RFC7432" fo
	<xref target="I-D.ietf-bess-evpn-prefix-advertisement"/>, and	rmat="default"/>,
	<xref target="I-D.ietf-bess-evpn-igmp-mld-proxy"/>:	<xref target="RFC9136" format="default"/>, and
	<figure>	<xref target="RFC9251" format="default"/>:
	<artwork>	</t>
	+ 1 - Ethernet Auto-Discovery (A-D) route	<table anchor="tab-0">
	+ 2 - MAC/IP Advertisement route	<name>Pre-existing Route Types</name>
	+ 3 - Inclusive Multicast Ethernet Tag route	<thead>
	+ 4 - Ethernet Segment route	<tr>
	+ 5 - IP Prefix Route	<th>Value</th>
	+ 6 - Selective Multicast Ethernet Tag Route	<th>Description</th>
	+ 7 - Multicast Join Synch Route	</tr>
	+ 8 - Multicast Leave Synch Route	</thead>
	</artwork>	<tbody>
	</figure>	<tr>
		<td>1</td>
		<td>Ethernet Auto-discovery</td>
		</tr>
		<tr>
		<td>2</td>
		<td>MAC/IP Advertisement</td>
		</tr>
		<tr>
		<td>3</td>
		<td>Inclusive Multicast Ethernet Tag</td>
		</tr>
		<tr>
		<td>4</td>
		<td>Ethernet Segment</td>
		</tr>
		<tr>
		<td>5</td>
		<td>IP Prefix</td>
		</tr>
		<tr>
		<td>6</td>
		<td>Selective Multicast Ethernet Tag Route</td>
		</tr>
		<tr>
		<td>7</td>
		<td>Multicast Membership Report Synch Route</td>
		</tr>
		<tr>
		<td>8</td>
		<td>Multicast Leave Synch Route</td>
		</tr>
		</tbody>
		</table>

		<t>
	This document defines three additional route types:	This document defines three additional route types:

	<figure>	</t>
	<artwork>	<table anchor="tab-0a">
	+ 9 - Per-Region I-PMSI A-D route	<name>New Route Types</name>
	+ 10 - S-PMSI A-D route	<thead>
	+ 11 - Leaf A-D route	<tr>
	</artwork>	<th>Value</th>
	</figure>	<th>Description</th>
	The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs	</tr>
	starts with a type 1 RD, whose Administrator sub-field MUST match	</thead>
	that of the RD in all current non-Leaf A-D (<xref target="leaf"/>)	<tbody>
	EVPN routes from the same advertising router for a given EVI.	<tr>
	</t>	<td>9</td>
	<section title="Per-Region I-PMSI A-D route" anchor="per-region">	<td>Per-Region I-PMSI A-D route</td>
	<t>The Per-region I-PMSI A-D route has the following format. Its usage is	</tr>
	discussed in <xref target="aggregation"/>.	<tr>
	<figure>	<td>10</td>
	<artwork>	<td>S-PMSI A-D route</td>
		</tr>
		<tr>
		<td>11</td>
		<td>Leaf A-D route</td>
		</tr>
		</tbody>
		</table>
		<t>
		The "Route Type specific" field of the Type 9 and Type 10 EVPN NLRIs
		starts with a Type 1 RD (Route Distinguisher), whose Administrator sub-f
		ield <bcp14>MUST</bcp14> match
		that of the RD in all current EVPN routes that are not Leaf A-D routes
		(<xref target="leaf" format="default"/>), i.e., non-Leaf A-D routes
		from the same advertising router for a given EVPN instance (EVI).
		</t>
		<section anchor="per-region" numbered="true" toc="default">
		<name>Per-Region I-PMSI A-D Route</name>
		<t>The per-region I-PMSI A-D route has the following format. Its usage i
		s
		discussed in <xref target="aggregation" format="default"/>.
		</t>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	+-----------------------------------+	+-----------------------------------+

	\| RD (8 octets) \|	\| RD (8 octets) \|
	+-----------------------------------+	+-----------------------------------+
	\| Ethernet Tag ID (4 octets) \|	\| Ethernet Tag ID (4 octets) \|
	+-----------------------------------+	+-----------------------------------+
	\| Region ID (8 octets) \|	\| Region ID (8 octets) \|
	+-----------------------------------+	+-----------------------------------+

	</artwork>	]]></artwork>
	</figure>	<t>
	The Region ID identifies the region and is encoded just as how an	The Region ID identifies the region and is encoded in the same way that
	Extended Community is encoded, as detailed in	an
	<xref target="aggregation"/>.	EC is encoded, as detailed in
	</t>	<xref target="aggregation" format="default"/>.
	</section>	</t>
	<section title="S-PMSI A-D route">	</section>
	<t>The S-PMSI A-D route has the following format:	<section numbered="true" toc="default">
	<figure>	<name>S-PMSI A-D Route</name>
	<artwork>	<t>The S-PMSI A-D route has the following format:
		</t>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	+-----------------------------------+	+-----------------------------------+

	\| RD (8 octets) \|	\| RD (8 octets) \|
	+-----------------------------------+	+-----------------------------------+
	\| Ethernet Tag ID (4 octets) \|	\| Ethernet Tag ID (4 octets) \|
	+-----------------------------------+	+-----------------------------------+
	\| Multicast Source Length (1 octet) \|	\| Multicast Source Length (1 octet) \|
	+-----------------------------------+	+-----------------------------------+

	\| Multicast Source (Variable) \|	\| Multicast Source (variable) \|
	+-----------------------------------+	+-----------------------------------+
	\| Multicast Group Length (1 octet) \|	\| Multicast Group Length (1 octet) \|
	+-----------------------------------+	+-----------------------------------+

	\| Multicast Group (Variable) \|	\| Multicast Group (variable) \|
	+-----------------------------------+	+-----------------------------------+
	\|Originator's Addr Length (1 octet) \|	\|Originator's Addr Length (1 octet) \|
	+-----------------------------------+	+-----------------------------------+
	\|Originator's Addr (4 or 16 octets) \|	\|Originator's Addr (4 or 16 octets) \|
	+-----------------------------------+	+-----------------------------------+

	</artwork>	]]></artwork>
	</figure>	<t>
	Other than the addition of Ethernet Tag ID and Originator's Addr	Other than the addition of the Ethernet Tag ID and Originator's Addr
	Length, it is identical	Length fields, it is identical
	to the S-PMSI A-D route as defined in [RFC7117]. The procedures	to the S-PMSI A-D route as defined in <xref target="RFC7117" format="def
	in [RFC7117] also apply (including wildcard functionality),	ault"/>. The procedures specified
		in <xref target="RFC7117" format="default"/> also apply (including wildc
		ard functionality),
	except that the granularity level is per Ethernet Tag.	except that the granularity level is per Ethernet Tag.

	</t>	</t>
	</section>	</section>
	<section title="Leaf A-D route" anchor="leaf">	<section anchor="leaf" numbered="true" toc="default">
	<t>The Route Type specific field of a Leaf A-D route consists of	<name>Leaf A-D Route</name>
		<t>The Route Type specific field of a Leaf A-D route consists of
	the following:	the following:

	<figure>	</t>
	<artwork>	<artwork name="" type="" align="left" alt=""><![CDATA[
	+-----------------------------------+	+-----------------------------------+
	\| Route Key (variable) \|	\| Route Key (variable) \|
	+-----------------------------------+	+-----------------------------------+
	\|Originator's Addr Length (1 octet) \|	\|Originator's Addr Length (1 octet) \|
	+-----------------------------------+	+-----------------------------------+
	\|Originator's Addr (4 or 16 octets) \|	\|Originator's Addr (4 or 16 octets) \|
	+-----------------------------------+	+-----------------------------------+

	</artwork>	]]></artwork>
	</figure>	<t>
	A Leaf A-D route is originated in response to a PMSI route,	A Leaf A-D route is originated in response to a PMSI route,

	which could be an Inclusive Multicast Tag route, a per-region	which could be an IMET A-D route, a per-region
	I-PMSI A-D route, an S-PMSI A-D route, or some other types of	I-PMSI A-D route, an S-PMSI A-D route, or some other types of

	routes that may be defined in the future that triggers Leaf A-D	routes that may be defined in the future that trigger Leaf A-D
	routes. The Route Key is the NLRI of the	routes. The Route Key is the NLRI of the
	route for which this Leaf A-D route is generated.	route for which this Leaf A-D route is generated.

	</t>	</t>
	<t>The general procedures of Leaf A-D route are first specified in	<t>The general procedures for Leaf A-D routes were first specified in
	[RFC6514] for MVPN. The principles apply to VPLS and EVPN as well.	<xref target="RFC6514" format="default"/> for MVPNs. The principles there
	[RFC7117] has details for VPLS Multicast, and this document points	in apply to VPLSs and EVPNs as well.
	out some specifics for EVPN, e.g. in <xref target="inter-as"/>.	<xref target="RFC7117" format="default"/> provides details regarding VPLS
	</t>	multicast, and this document points
	</section>	out some specifics for EVPNs, e.g., in <xref target="inter-as" format="de
		fault"/>.
		</t>
		</section>
	</section>	</section>

	<section title="Selective Multicast">	<section numbered="true" toc="default">
	<t><xref target="I-D.ietf-bess-evpn-igmp-mld-proxy"/> specifies	<name>Selective Multicast</name>
	procedures for EVPN selective forwarding of IP multicast using SMET	<t><xref target="RFC9251" format="default"/> specifies
	routes. It assumes selective forwarding is always used with IR	procedures for EVPN selective forwarding of IP multicast traffic using SM
		ET
		routes. It assumes that selective forwarding is always used with ingress
		replication
	for all flows (though the same signaling can also be used for an	for all flows (though the same signaling can also be used for an

	ingress PE to find out the set of egress PEs for selective	ingress PE to learn the set of egress PEs for selective
	forwarding with BIER).	forwarding with BIER).

	An NVE proxies the IGMP/MLD state that it learns on its	A Network Virtualization Edge (NVE) proxies the IGMP/MLD state ("MLD"
	ACs to (C-S,C-G) or (C-*,C-G) SMET routes that advertises to other NVEs,	stands for "Multicast Listener Discovery") that it learns on its
		Attachment Circuits (ACs) to (C-S,C-G) or (C-*,C-G) SMET routes that are
		advertised to other NVEs,
	and a receiving NVE converts the SMET routes back to IGMP/MLD messages	and a receiving NVE converts the SMET routes back to IGMP/MLD messages
	and sends them out of its ACs. The receiving NVE also uses the SMET	and sends them out of its ACs. The receiving NVE also uses the SMET
	routes to identify which NVEs need to receive traffic for a particular	routes to identify which NVEs need to receive traffic for a particular

	(C-S,C-G) or (C-*,C-G) to achieve selective forwarding using IR or	(C-S,C-G) or (C-*,C-G) to achieve selective forwarding using ingress repl ication or
	BIER.	BIER.

	</t>	</t>
	<t>With the above procedures, selective forwarding is done for all flows	<t>With the above procedures, selective forwarding is done for all flows,
	and the SMET routes are advertised for all flows.	and the SMET routes are advertised for all flows.
	It is possible that an operator may not want to track all those	It is possible that an operator may not want to track all those

	(C-S, C-G) or (C-*,C-G) state on the NVEs, and the multicast traffic	(C-S, C-G) or (C-*,C-G) states on the NVEs, and the multicast traffic
	pattern allows inclusive forwarding for most flows while selective	pattern allows inclusive forwarding for most flows while selective

	forwarding is needed only for a few high-rate flows. For that,	forwarding is needed only for a few high-rate flows. For that reason,
	or for tunnel types other than IR/BIER, S-PMSI/Leaf A-D procedures	or for tunnel types other than ingress replication or BIER, S-PMSI/Leaf A
	defined for Selective Multicast for VPLS in [RFC7117] are used. Other	-D procedures
	than that different route types and formats are specified with EVPN SAFI	defined for selective multicast for VPLS in <xref target="RFC7117" format
	for S-PMSI A-D and Leaf A-D routes (<xref target="routes"/>), all	="default"/> are used. Other
	procedures in [RFC7117] with respect to Selective Multicast apply to	than the fact that different route types and formats are specified with a
	EVPN as well, including wildcard procedures. In a nutshell, a source	n EVPN SAFI
		for S-PMSI A-D and Leaf A-D routes (<xref target="routes" format="default
		"/>), all
		procedures specified in <xref target="RFC7117" format="default"/> with re
		spect to selective multicast apply to
		EVPNs as well, including wildcard procedures. In a nutshell, a source
	NVE advertises S-PMSI A-D routes to announce the tunnels used for	NVE advertises S-PMSI A-D routes to announce the tunnels used for
	certain flows, and receiving NVEs either join the announced PIM/mLDP	certain flows, and receiving NVEs either join the announced PIM/mLDP

	tunnel or respond with Leaf A-D routes if the Leaf Information Required	tunnel or respond with Leaf A-D routes if the L
	flag is set in the S-PMSI A-D route's PTA (so that the source NVE can	flag is set in the S-PMSI A-D route's PTA (so that the source NVE can
	include them as tunnel leaves).	include them as tunnel leaves).

	</t>	</t>
	<t>An optimization to the [RFC7117] procedures may be applied. Even if	<t>An optimization to the procedures provided in <xref target="RFC7117" fo
		rmat="default"/> may be applied. Even if
	a source NVE sets the L flag to request Leaf A-D routes, an egress	a source NVE sets the L flag to request Leaf A-D routes, an egress

	NVE MAY omit the Leaf A-D route if it has already advertised a	NVE <bcp14>MAY</bcp14> omit the Leaf A-D route if it has already advertised a
	corresponding SMET route, and the source NVE MUST use that in lieu of	corresponding SMET route, and the source NVE <bcp14>MUST</bcp14> use that in
		lieu of
	the Leaf A-D route.	the Leaf A-D route.

	</t>	</t>
	<t>The optional optimizations specified for MVPN in	<t>The optional optimizations specified for MVPNs in
	<xref target="RFC8534"/> are also applicable	<xref target="RFC8534" format="default"/> are also applicable
	to EVPN when the S-PMSI/Leaf A-D routes procedures are used for EVPN	to EVPNs when the procedures for S-PMSI/Leaf A-D routes are used for EVPN
	selective multicast forwarding.	selective multicast forwarding.

	</t>	</t>
	</section>	</section>

	<section title="Inter-AS Segmentation" anchor="inter-as">	<section anchor="inter-as" numbered="true" toc="default">
	<section title="Differences from Section 7.2.2 of [RFC7117] When Applied to	<name>Inter-AS Segmentation</name>
	EVPN" anchor="interaschanges">	<section anchor="interaschanges" numbered="true" toc="default">
	<t>The first paragraph of Section 7.2.2.2 of [RFC7117] says:	<name>Differences from Section 7.2.2 of RFC 7117 when Applied to EVPNs</
	<figure>	name>
	<artwork>	<t>The first paragraph of <xref target="RFC7117" sectionFormat="of" sect
	"... The best route procedures ensure that if multiple	ion="7.2.2.2"/> says:
		</t>
		<blockquote>
		... The best route procedures ensure that if multiple
	ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP	ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP
	neighbors, only one of these ASBRs propagates this route in Internal	neighbors, only one of these ASBRs propagates this route in Internal
	BGP (IBGP). This ASBR becomes the root of the intra-AS segment of	BGP (IBGP). This ASBR becomes the root of the intra-AS segment of
	the inter-AS tree and ensures that this is the only ASBR that accepts	the inter-AS tree and ensures that this is the only ASBR that accepts

	traffic into this AS from the inter-AS tree."	traffic into this AS from the inter-AS tree.
	</artwork>	</blockquote>
	</figure>	<t>
	The above VPLS behavior requires complicated VPLS specific procedures	The above VPLS behavior requires complicated VPLS-specific procedures
	for the ASBRs to reach agreement. For EVPN, a different approach	for the ASBRs to reach agreement. For EVPNs, a different approach
	is used and the above quoted text is not applicable to EVPN.	is used; the above text from <xref target="RFC7117"/> is not applicable t
	</t>	o EVPNs.
	<t>With the different approach for EVPN/MVPN, each ASBR will re-advertise	</t>
		<t>With the different approach for EVPNs/MVPNs, each ASBR will re-advert
		ise
	its received Inter-AS A-D route to its IBGP peers and becomes the root	its received Inter-AS A-D route to its IBGP peers and becomes the root
	of an intra-AS segment of the inter-AS tree. The intra-AS segment	of an intra-AS segment of the inter-AS tree. The intra-AS segment

	rooted at one ASBR is disjoint with another intra-AS segment rooted	rooted at one ASBR is disjoint from another intra-AS segment rooted
	at another ASBR. This is the same as the procedures for S-PMSI	at another ASBR. This is the same as the procedures for S-PMSI routes
	in [RFC7117] itself.	in <xref target="RFC7117" format="default"/> itself.
	</t>	</t>
	<t>The following bullet in Section 7.2.2.2 of [RFC7117] does not apply	<t>The following bullet in <xref target="RFC7117" sectionFormat="of" sec
	to EVPN.	tion="7.2.2.2"/> does not apply
	<figure>	to EVPNs.
	<artwork>	</t>
	+ If the ASBR uses ingress replication to instantiate the intra-AS	<blockquote>
	segment of the inter-AS tunnel, the re-advertised route MUST NOT	<ul><li>If the ASBR uses ingress replication to instantiate the intra-AS
	carry the PMSI Tunnel attribute.	segment of the inter-AS tunnel, the re-advertised route <bcp14>MUST NOT</
	</artwork>	bcp14>
	</figure>	carry the PMSI Tunnel attribute.</li></ul>
	</t>	</blockquote>
	<t>The following bullet in Section 7.2.2.2 of [RFC7117]:	<t>The following bullet in <xref target="RFC7117" sectionFormat="of" sec
	<figure>	tion="7.2.2.2"/>:
	<artwork>	</t>
	+ If the ASBR uses a P-multicast tree to instantiate the intra-AS	<blockquote><ul><li>
	segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST	If the ASBR uses a P-multicast tree to instantiate the intra-AS
		segment of the inter-AS tunnel, the PMSI Tunnel attribute <bcp14>MUST</bc
		p14>
	contain the identity of the tree that is used to instantiate the	contain the identity of the tree that is used to instantiate the
	segment (note that the ASBR could create the identity of the tree	segment (note that the ASBR could create the identity of the tree
	prior to the actual instantiation of the segment). If, in order	prior to the actual instantiation of the segment). If, in order
	to instantiate the segment, the ASBR needs to know the leaves of	to instantiate the segment, the ASBR needs to know the leaves of
	the tree, then the ASBR obtains this information from the A-D	the tree, then the ASBR obtains this information from the A-D

	routes received from other PEs/ASBRs in the ASBR's own AS.	routes received from other PEs/ASBRs in the ASBR's own AS.</li></ul>
	</artwork>	</blockquote>
	</figure>	<t>is changed to the following when applied to EVPNs:
	</t>	</t>
	<t>is changed to the following when applied to EVPN:	<blockquote><ul><li>
	<figure>	The PTA <bcp14>MUST</bcp14> specify the tunnel for the segment.
	<artwork>
	"The PMSI Tunnel attribute MUST specify the tunnel for the segment.
	If and only if, in order to establish the tunnel, the ASBR needs to	If and only if, in order to establish the tunnel, the ASBR needs to

	know the leaves of the tree, then the ASBR MUST set the L flag to	know the leaves of the tree, then the ASBR <bcp14>MUST</bcp14> set the L f lag to
	1 in the PTA to trigger Leaf A-D routes from egress PEs and	1 in the PTA to trigger Leaf A-D routes from egress PEs and

	downstream ASBRs. It MUST be (auto-)configured with an import RT,	downstream ASBRs. It <bcp14>MUST</bcp14> be (auto-)configured with an impo
	which controls acceptance of leaf A-D routes by the ASBR."	rt RT,
	</artwork>	which controls acceptance of Leaf A-D routes by the ASBR.</li></ul>
	</figure>	</blockquote>
	</t>	<t>Accordingly, the following paragraph in <xref target="RFC7117" sectio
	<t>Accordingly, the following paragraph in Section 7.2.2.4 of [RFC7117]:	nFormat="of" section="7.2.2.4"/>:
	<figure>	</t>
	<artwork>	<blockquote>
	"If the received Inter-AS A-D route carries the PMSI Tunnel attribute	If the received Inter-AS A-D route carries the PMSI Tunnel attribute
	with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR	with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR

	that originated the route MUST establish an RSVP-TE P2MP LSP with the	that originated the route <bcp14>MUST</bcp14> establish an RSVP-TE P2MP LSP w
	local PE/ASBR as a leaf. This LSP MAY have been established before	ith the
	the local PE/ASBR receives the route, or it MAY be established after	local PE/ASBR as a leaf. This LSP <bcp14>MAY</bcp14> have been established b
	the local PE receives the route."	efore
	</artwork>	the local PE/ASBR receives the route, or it <bcp14>MAY</bcp14> be established
	</figure>	after
	is changed to the following when applied to EVPN:	the local PE receives the route.
	</t>	</blockquote>
	<t>	<t>
	"If the received Inter-AS A-D route has the L flag set in its PTA,	is changed to the following when applied to EVPNs:
	then a receiving PE MUST originate a corresponding Leaf A-D route, while	</t>
	a receiving ASBR MUST originate a corresponding Leaf A-D route	<blockquote>
	if and only if it received and imported one or more corresponding Leaf	If the received Inter-AS A-D route has the L flag set in its PTA,
	A-D routes from its downstream IBGP or EBGP peers, or it has non-null	then a receiving PE <bcp14>MUST</bcp14> originate a corresponding Leaf A-D rout
	downstream forwarding state for the PIM/mLDP tunnel that instantiates	e.
	its downstream intra-AS segment. The targeted ASBR for the Leaf A-D route,	A receiving ASBR <bcp14>MUST</bcp14> originate a corresponding Leaf A-D
	which (re-)advertised the Inter-AS A-D route, MUST establish a tunnel	route if and only if one of the following conditions is met:
	to the leaves discovered by the Leaf A-D routes."	(1) it received and imported one or more corresponding Leaf A-D
	</t>	routes from its downstream IBGP or EBGP peers or (2) it has
	</section>	non-null downstream forwarding state for the PIM/mLDP tunnel that
	<section title="I-PMSI Leaf Tracking"	instantiates its downstream intra-AS segment. The targeted ASBR for the Leaf A-
	anchor="leaf-tracking">	D
	<t>An ingress PE does not set the L flag in its Inclusive Multicast	route, which (re-)advertised the Inter-AS A-D route, <bcp14>MUST</bcp14> establ
	Ethernet Tag (IMET) A-D route's PTA,	ish a tunnel to the
	even with Ingress Replication or RSVP-TE P2MP tunnels.	leaves discovered by the Leaf A-D routes.
		</blockquote>
		</section>
		<section anchor="leaf-tracking" numbered="true" toc="default">
		<name>I-PMSI Leaf Tracking</name>
		<t>An ingress PE does not set the L flag in its IMET A-D route's PTA,
		even with Ingress Replication tunnels or RSVP-TE P2MP tunnels.
	It does not rely on the Leaf A-D routes to discover leaves in	It does not rely on the Leaf A-D routes to discover leaves in

	its AS, and Section 11.2 of [RFC7432] explicitly states that the L	its AS, and <xref target="RFC7432" sectionFormat="of" section="11.2"/> ex
	flag must be set to zero.	plicitly states that the L
	</t>	flag must be set to 0.
	<t>An implementation of [RFC7432] might have used the Originating	</t>
		<t>An implementation of <xref target="RFC7432" format="default"/> might
		have used the Originating
	Router's IP Address field of the IMET A-D	Router's IP Address field of the IMET A-D

	routes to determine the leaves, or might have used the Next Hop field	routes to determine the leaves or might have used the Next Hop field
	instead. Within the same AS, both will lead to the same result.	instead. Within the same AS, both will lead to the same result.

	</t>	</t>
	<t>With segmentation, an ingress PE MUST determine the leaves	<t>With segmentation, an ingress PE <bcp14>MUST</bcp14> determine the le
		aves
	in its AS from the BGP next hops in all its received IMET A-D	in its AS from the BGP next hops in all its received IMET A-D

	routes, so it does not have to set the L flag set to request Leaf A-D	routes, so it does not have to set the L flag to request Leaf A-D
	routes. PEs within the same AS will all have different next hops	routes. PEs within the same AS will all have different next hops

	in their IMET A-D routes (hence will all be considered as leaves),	in their IMET A-D routes (and hence will all be considered as leaves),
	and PEs from other ASes will have the next hop in their IMET A-D	and PEs from other ASes will have the next hop in their IMET A-D

	routes set to addresses of ASBRs in this local AS, hence only those	routes set to addresses of ASBRs in this local AS; hence, only those
	ASBRs will be considered as leaves (as proxies for those PEs in other	ASBRs will be considered as leaves (as proxies for those PEs in other

	ASes). Note that in case of Ingress Replication, when an ASBR	ASes). Note that in the case of ingress replication, when an ASBR
	re-advertises IMET A-D routes to IBGP peers, it MUST advertise the	re-advertises IMET A-D routes to IBGP peers, it <bcp14>MUST</bcp14> adver
	same label for all those for the same Ethernet Tag ID and the same	tise the
		same label for all those routes for the same Ethernet Tag ID and the same
	EVI. Otherwise, duplicated copies will be sent by the ingress PE	EVI. Otherwise, duplicated copies will be sent by the ingress PE
	and received by egress PEs in other regions. For the same reason,	and received by egress PEs in other regions. For the same reason,
	when an ingress PE builds its flooding list, if multiple routes	when an ingress PE builds its flooding list, if multiple routes

	have the same (nexthop, label) tuple they MUST only be	have the same (nexthop, label) tuple, they <bcp14>MUST</bcp14> only be
	added as a single branch in the flooding list.	added as a single branch in the flooding list.

	</t>	</t>
	</section>	</section>
	<section title="Backward Compatibility" anchor="compatibility">	<section anchor="compatibility" numbered="true" toc="default">
	<t>The above procedures assume that all PEs are upgraded to support	<name>Backward Compatibility</name>
		<t>The above procedures assume that all PEs are upgraded to support
	the segmentation procedures:	the segmentation procedures:

	<list style="symbols">	</t>
	<t>An ingress PE uses the Next Hop and not Originating	<ul spacing="normal">
		<li>An ingress PE uses the Next Hop and not the Originating
	Router's IP Address to determine leaves for the I-PMSI tunnel.	Router's IP Address to determine leaves for the I-PMSI tunnel.

	</t>	</li>
	<t>An egress PE sends Leaf A-D routes in response to I-PMSI routes,	<li>An egress PE sends Leaf A-D routes in response to I-PMSI routes,
	if the PTA has the L flag set by the re-advertising ASBR.	if the PTA has the L flag set by the re-advertising ASBR.

	</t>	</li>
	<t>In case of Ingress Replication, when an ingress PE builds	<li>In the case of ingress replication, when an ingress PE builds
	its flooding list, multiple I-PMSI routes may have the same (nexthop, label)	its flooding list, multiple I-PMSI routes may have the same (nexthop, label)

	tuple and only a single branch for those will be added in the flooding	tuple, and only a single branch for those routes will be added in the floodin g
	list.	list.

	</t>	</li>
	</list>	</ul>
	</t>	<t>If a deployment has legacy PEs that do not support the above,
	<t>If a deployment has legacy PEs that does not support the above,
	then a legacy ingress PE would include all PEs (including those	then a legacy ingress PE would include all PEs (including those
	in remote ASes) as leaves of the inclusive tunnel and try to send	in remote ASes) as leaves of the inclusive tunnel and try to send

	traffic to them directly (no segmentation), which is either undesired	traffic to them directly (no segmentation), which is either undesirable
	or not possible; a legacy egress PE would not send Leaf A-D routes	or impossible; a legacy egress PE would not send Leaf A-D routes
	so the ASBRs would not know to send external traffic to them.	so the ASBRs would not know to send external traffic to them.

	</t>	</t>
	<t>If this backward compatibility problem needs to be addressed, the	<t>If this backward-compatibility problem needs to be addressed, the
	following procedure MUST be used (see <xref target="aggregation"/>	following procedure <bcp14>MUST</bcp14> be used (see <xref target="aggreg
		ation" format="default"/>
	for per-PE/AS/region I-PMSI A-D routes):	for per-PE/AS/region I-PMSI A-D routes):

	<list style="symbols">	</t>
	<t>An upgraded PE indicates in its per-PE I-PMSI A-D	<ul spacing="normal">
		<li>An upgraded PE indicates in its per-PE I-PMSI A-D
	route that it supports the new procedures. This is done	route that it supports the new procedures. This is done
	by setting a flag bit in the EVPN Multicast Flags Extended	by setting a flag bit in the EVPN Multicast Flags Extended
	Community.	Community.

	</t>	</li>
	<t>All per-PE I-PMSI A-D routes are restricted to the local AS	<li>All per-PE I-PMSI A-D routes are restricted to the local AS
	and not propagated to external peers.	and not propagated to external peers.

	</t>	</li>
	<t>The ASBRs in an AS originate per-region I-PMSI A-D routes	<li>The ASBRs in an AS originate per-region I-PMSI A-D routes
	and advertise them to their external peers to specify tunnels	and advertise them to their external peers to specify tunnels
	used to carry traffic from the local AS to other ASes.	used to carry traffic from the local AS to other ASes.
	Depending on the types of tunnels being used, the L flag	Depending on the types of tunnels being used, the L flag
	in the PTA may be set, in which case the downstream ASBRs	in the PTA may be set, in which case the downstream ASBRs
	and upgraded PEs will send Leaf A-D routes to pull traffic	and upgraded PEs will send Leaf A-D routes to pull traffic
	from their upstream ASBRs. In a particular downstream AS,	from their upstream ASBRs. In a particular downstream AS,
	one of the ASBRs is elected, based on the per-region	one of the ASBRs is elected, based on the per-region
	I-PMSI A-D routes for a particular source AS,	I-PMSI A-D routes for a particular source AS,
	to send traffic from that source AS to legacy PEs in the	to send traffic from that source AS to legacy PEs in the

	downstream AS. The traffic arrives at the elected ASBR	downstream AS.
	on the tunnel announced in the best per-region I-PMSI A-D	The traffic arrives at the elected ASBR on the tunnel
	route for the source AS, that the ASBR has selected of	announced in the best per-region I-PMSI A-D route for the source
	all those that it received over EBGP or IBGP sessions.	AS, as selected by the ASBR from all the routes that it received
	The election procedure is described in	over EBGP or IBGP sessions. The election procedure is described in
	<xref target="election"/>.	<xref target="election" format="default"/>.
	</t>	</li>
	<t>In an ingress/upstream AS, if and only if an ASBR has active downst	<li>In an ingress/upstream AS, if and only if an ASBR has active downs
	ream	tream
	receivers (PEs and ASBRs), which are learned either explicitly	receivers (PEs and ASBRs), which are learned either explicitly

	via Leaf A-D routes or implicitly via PIM join or mLDP label	via Leaf A-D routes or implicitly via PIM Join or mLDP label
	mapping, the ASBR originates a per-PE I-PMSI A-D route (i.e.,	mapping, the ASBR originates a per-PE I-PMSI A-D route (i.e., a
	regular Inclusive Multicast Ethernet Tag route) into the local	regular IMET route) into the local
	AS, and stitches incoming per-PE I-PMSI tunnels into its	AS and stitches incoming per-PE I-PMSI tunnels into its
	per-region I-PMSI tunnel. With this, it gets traffic from	per-region I-PMSI tunnel. Via this process, it gets traffic from
	local PEs and send to other ASes via the tunnel announced in	local PEs and sends the traffic to other ASes via the tunnel announ
		ced in
	its per-region I-PMSI A-D route.	its per-region I-PMSI A-D route.

	</t>	</li>
	</list>	</ul>
	</t>	<t>Note that even if there are no backward-compatibility issues, the use
	<t>Note that, even if there is no backward compatibility issue, the use of	of
	per-region I-PMSI has the benefit of keeping all per-PE I-PMSI A-D routes	per-region I-PMSI A-D routes provides the benefit of keeping all per-PE I
		-PMSI A-D routes
	in their local ASes, greatly reducing the flooding of the routes and	in their local ASes, greatly reducing the flooding of the routes and

	their corresponding Leaf A-D routes (when needed), and the number of	their corresponding Leaf A-D routes (when needed) and reducing the number
	inter-as tunnels.	of
	</t>	inter-AS tunnels.
	<section title="Designated ASBR Election" anchor="election">	</t>
	<t>When an ASBR re-advertises a per-region I-PMSI A-D route into an AS	<section anchor="election" numbered="true" toc="default">
		<name>Designated ASBR Election</name>
		<t>When an ASBR re-advertises a per-region I-PMSI A-D route into an AS
	in which a designated ASBR needs to be used to forward traffic	in which a designated ASBR needs to be used to forward traffic

	to the legacy PEs in the AS, it MUST include a DF Election EC.	to the legacy PEs in the AS, it <bcp14>MUST</bcp14> include a Designated
	The EC and its use is specified in <xref target="RFC8584"/>.	Forwarder (DF) Election EC.
	The AC-DF bit in the DF Election EC MUST be cleared.	The EC and its use are specified in <xref target="RFC8584" format="defaul
	If it is known that no legacy PEs exist in the AS, the ASBR MUST NOT	t"/>.
	include the EC and MUST remove the DF Election EC if one is carried in	The AC-DF bit in the DF Election EC <bcp14>MUST</bcp14> be cleared.
		If it is known that no legacy PEs exist in the AS, the ASBR <bcp14>MUST N
		OT</bcp14>
		include the EC and <bcp14>MUST</bcp14> remove the DF Election EC if one i
		s carried in
	the per-region I-PMSI A-D routes that it receives. Note that this is done	the per-region I-PMSI A-D routes that it receives. Note that this is done
	for each set of per-region I-PMSI A-D routes with the same NLRI.	for each set of per-region I-PMSI A-D routes with the same NLRI.

	</t>	</t>
	<t>Based on the procedures in	<t>Based on the procedures specified in
	<xref target="RFC8584"/>, an election	<xref target="RFC8584" format="default"/>, an election
	algorithm is determined according to the DF Election ECs carried in	algorithm is determined according to the DF Election ECs carried in

	the set of per-region I-PMSI routes of the same NLRI re-adverised into th e AS.	the set of per-region I-PMSI routes of the same NLRI re-advertised into t he AS.
	The algorithm is then applied to a candidate list, which is the set of	The algorithm is then applied to a candidate list, which is the set of
	ASBRs that re-advertised the per-region I-PMSI routes of the same NLRI	ASBRs that re-advertised the per-region I-PMSI routes of the same NLRI
	carrying the DF Election EC.	carrying the DF Election EC.

	</t>	</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section title="Inter-Region Segmentation" anchor="inter-region">	<section anchor="inter-region" numbered="true" toc="default">
	<section title="Area/AS vs. Region" anchor="region">	<name>Inter-Region Segmentation</name>
	<t>[RFC7524] is for MVPN/VPLS inter-area segmentation and does not explicitl	<section anchor="region" numbered="true" toc="default">
	y cover	<name>Area/AS vs. Region</name>
	EVPN. However, if "area" is replaced by "region" and "ABR" is replaced	<t><xref target="RFC7524" format="default"/> addresses MVPN/VPLS inter-a
	by "RBR" (Regional Border Router) then everything still works, and	rea segmentation and does not explicitly cover
	can be applied to EVPN as well.	EVPNs. However, if "area" is replaced by "region" and "ABR" is replaced
	</t>	by "RBR" (Regional Border Router), then everything still works and
	<t>A region can be a sub-area, or can be an entire AS including its	can be applied to EVPNs as well.
	external links. Instead of automatic region definition based on	</t>
		<t>A region can be a sub-area, or it can be an entire AS, including its
		external links. Instead of automatically defining a region based on
	IGP areas, a region would be defined as a BGP peer group. In fact,	IGP areas, a region would be defined as a BGP peer group. In fact,

	even with IGP area based region definition, a BGP peer group	even with a region definition based on an IGP area, a BGP peer group
	listing the PEs and ABRs in an area is still needed.	listing the PEs and ABRs in an area is still needed.

	</t>	</t>
	<t>Consider the following example diagram for inter-as segmentation:	<t>Consider the following example diagram for inter-AS segmentation:
	<figure>	</t>
	<artwork>	<artwork name="" type="" align="left" alt=""><![CDATA[
	--------- ------ ---------	--------- ------ ---------
	/ \ / \ / \	/ \ / \ / \
	/ \ / \ / \	/ \ / \ / \
	\| PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 \|	\| PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 \|
	\ / \ / \ /	\ / \ / \ /
	\ / \ / \ /	\ / \ / \ /
	--------- ------ ---------	--------- ------ ---------
	AS 100 AS 200 AS 300	AS 100 AS 200 AS 300
	\|-----------\|--------\|---------\|--------\|------------\|	\|-----------\|--------\|---------\|--------\|------------\|
	segment1 segment2 segment3 segment4 segment5	segment1 segment2 segment3 segment4 segment5

	</artwork>	]]></artwork>
	</figure>	<t>
	The inter-as segmentation procedures specified so far ([RFC6513] [RFC6514	The inter-AS segmentation procedures specified so far (<xref target="RFC6
	],	513" format="default"/>, <xref target="RFC6514" format="default"/>,
	[RFC7117], and <xref target="inter-as"/> of this document) require all	<xref target="RFC7117" format="default"/>, and <xref target="inter-as" fo
	ASBRs to be involved, and Ingress Replication is used between two ASBRs	rmat="default"/> of this document) require all
		ASBRs to be involved, and ingress replication is used between two ASBRs
	in different ASes.	in different ASes.

	</t>	</t>
	<t>	<t>
	In the above diagram, it's possible that ASBR1/4 does not support	In the above diagram, it's possible that ASBR1/4 does not support
	segmentation, and the provider tunnels in AS 100/300 can actually	segmentation, and the provider tunnels in AS 100/300 can actually
	extend across the external link. In this case, the inter-region	extend across the external link. In this case, the inter-region

	segmentation procedures can be used instead - a region is the	segmentation procedures can be used instead -- a region is the
	entire (AS100 + ASBR1-ASBR2 link) or (AS300 + ASBR3-ASBR4 link).	entire AS100 plus the ASBR1-ASBR2 link or the entire AS300 plus the
		ASBR3-ASBR4 link.
	ASBR2/3 would be the RBRs, and ASBR1/4 will just be a transit core	ASBR2/3 would be the RBRs, and ASBR1/4 will just be a transit core
	router with respect to provider tunnels.	router with respect to provider tunnels.

	</t>	</t>
	<t>As illustrated in the diagram below, ASBR2/3 will establish a multihop	<t>As illustrated in the diagram below, ASBR2/3 will establish a multiho
	EBGP session with either a RR or directly with PEs in the neighboring	p
		EBGP session, either with a Route Reflector (RR) or directly with PEs in
		the neighboring
	AS. I/S-PMSI A-D routes from ingress PEs will not be processed by	AS. I/S-PMSI A-D routes from ingress PEs will not be processed by
	ASBR1/4. When ASBR2 re-advertises the routes into AS 200, it changes	ASBR1/4. When ASBR2 re-advertises the routes into AS 200, it changes

	the next hop to its own address and changes PTA to specify the tunnel	the next hop to its own address and changes its PTA to specify the tunnel
	type/identification in its own AS. When ASBR3 re-advertises	type/identification in its own AS. When ASBR3 re-advertises
	I/S-PMSI A-D routes into the neighboring AS 300, it changes the	I/S-PMSI A-D routes into the neighboring AS 300, it changes the

	next hop to its own address and changes PTA to specify the tunnel	next hop to its own address and changes its PTA to specify the tunnel
	type/identification in the neighboring region. Now the segment is	type/identification in the neighboring region. Now, the segment is
	rooted at ASBR3 and extends across the external link to PEs.	rooted at ASBR3 and extends across the external link to PEs.

	<figure>	</t>
	<artwork>	<artwork name="" type="" align="left" alt=""><![CDATA[
	--------- ------ ---------	--------- ------ ---------
	/ RR....\.mh-ebpg / \ mh-ebgp/....RR \	/ RR....\.mh-ebpg / \ mh-ebgp/....RR \
	/ : \ `. / \ .' / : \	/ : \ `. / \ .' / : \
	\| PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 \|	\| PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 \|
	\ / \ / \ /	\ / \ / \ /
	\ / \ / \ /	\ / \ / \ /
	--------- ------ ---------	--------- ------ ---------
	AS 100 AS 200 AS 300	AS 100 AS 200 AS 300
	\|-------------------\|----------\|---------------------\|	\|-------------------\|----------\|---------------------\|
	segment 1 segment 2 segment 3	segment 1 segment 2 segment 3

	</artwork>	]]></artwork>
	</figure>	</section>
	</t>	<section anchor="aggregation" numbered="true" toc="default">
	</section>	<name>Per-Region Aggregation</name>
	<section title="Per-region Aggregation" anchor="aggregation">	<t>Notice that every I/S-PMSI route from each PE will be propagated
	<t>Notice that every I/S-PMSI route from each PE will be propagated
	throughout all the ASes or regions. They may also trigger corresponding	throughout all the ASes or regions. They may also trigger corresponding

	Leaf A-D routes depending on the types of tunnels used in each region.	Leaf A-D routes, depending on the types of tunnels used in each region.
	This may become too many - routes and corresponding tunnels. To address	This may result in too many routes and corresponding tunnels. To address
	this concern, the I-PMSI routes from all PEs in a AS/region can be	this concern, the I-PMSI routes from all PEs in an AS/region can be
	aggregated into a single I-PMSI route originated from the RBRs,	aggregated into a single I-PMSI route originated from the RBRs,
	and traffic from all those individual I-PMSI tunnels	and traffic from all those individual I-PMSI tunnels
	will be switched into the single I-PMSI tunnel. This is like the	will be switched into the single I-PMSI tunnel. This is like the
	MVPN Inter-AS I-PMSI route originated by ASBRs.	MVPN Inter-AS I-PMSI route originated by ASBRs.

	</t>	</t>
	<t>The MVPN Inter-AS I-PMSI A-D route can be better called as per-AS I-PMSI	<t>The MVPN Inter-AS I-PMSI A-D route can be better called a "per-AS I-P
	A-D route, to be compared against the (per-PE) Intra-AS I-PMSI A-D routes	MSI
	originated by each PE. In this document we will call it as per-region	A-D route", to be compared against the (per-PE) Intra-AS I-PMSI A-D route
	I-PMSI A-D route, in case we want to apply the aggregation at regional	s
		originated by each PE. In this document, we will call it a "per-region
		I-PMSI A-D route" in cases where we want to apply aggregation at the regi
		onal
	level. The per-PE I-PMSI routes will not be propagated to other	level. The per-PE I-PMSI routes will not be propagated to other
	regions. If multiple RBRs are connected to a region, then each	regions. If multiple RBRs are connected to a region, then each

	will advertise such a route, with the same Region ID and Ethernet Tag ID	will advertise such a route, with the same Region ID and Ethernet Tag ID
	(<xref target=	(<xref target="per-region" format="default"/>). Similar to the per-PE I-PMSI A-D
	"per-region"/>). Similar to the per-PE I-PMSI A-D	routes, RBRs/PEs in a downstream region will each select the best route
	routes, RBRs/PEs in a downstream region will each select a best one	from all those re-advertised by the upstream RBRs and hence will only
	from all those re-advertised by the upstream RBRs, hence will only
	receive traffic injected by one of them.	receive traffic injected by one of them.

	</t>	</t>
	<t>MVPN does not aggregate S-PMSI routes from all PEs in an AS like it	<t>MVPNs do not aggregate S-PMSI routes from all PEs in an AS like they
	does for I-PMSIs routes, because the number of PEs that will advertise	do for I-PMSI routes, because the number of PEs that will advertise
	S-PMSI routes for the same (s,g) or (*,g) is small. This is also the	S-PMSI routes for the same (S,G) or (*,G) is small. This is also the
	case for EVPN, i.e., there is no per-region S-PMSI routes.	case for EVPNs, i.e., there are no per-region S-PMSI routes.
	</t>	</t>
	<t>Notice that per-region I-PMSI routes can also be used to address	<t>Notice that per-region I-PMSI routes can also be used to address
	backwards compatibility issue, as discussed in	backward-compatibility issues, as discussed in
	<xref target="compatibility"/>.	<xref target="compatibility" format="default"/>.
	</t>	</t>
	<t>The Region ID in the per-region I-PMSI route's NLRI is encoded like an	<t>The Region ID in the per-region I-PMSI route's NLRI is encoded like a
		n
	EC. For example, the	EC. For example, the
	Region ID can encode an AS number or area ID in the following EC format:	Region ID can encode an AS number or area ID in the following EC format:

	<list style="symbols">	</t>
	<t>For a two-octet AS number, a Transitive Two-Octet AS-Specific	<ul spacing="normal">
		<li>For a two-octet AS number, a Transitive Two-Octet AS-specific
	EC of sub-type 0x09 (Source AS), with the Global Administrator	EC of sub-type 0x09 (Source AS), with the Global Administrator
	sub-field set to the AS number and the Local Administrator	sub-field set to the AS number and the Local Administrator
	sub-field set to 0.	sub-field set to 0.

	</t>	</li>
	<t>For a four-octet AS number, a Transitive Four-Octet AS-Specific	<li>For a four-octet AS number, a Transitive Four-Octet AS-specific
	EC of sub-type 0x09 (Source AS), with the Global Administrator	EC of sub-type 0x09 (Source AS), with the Global Administrator
	sub-field set to the AS number and the Local Administrator	sub-field set to the AS number and the Local Administrator
	sub-field set to 0.	sub-field set to 0.

	</t>	</li>
	<t>For an area ID, a Transitive IPv4-Address-Specific EC of any	<li>For an area ID, a Transitive IPv4-Address-specific EC of any
	sub-type, with the Global Administrator	sub-type, with the Global Administrator
	sub-field set to the area ID and the Local Administrator	sub-field set to the area ID and the Local Administrator
	sub-field set to 0.	sub-field set to 0.

	</t>	</li>
	</list>	</ul>
	Uses of other EC encoding MAY be allowed as long as it uniquely	<t>
	identifies the region and the RBRs for the same region uses the	The use of other EC encodings <bcp14>MAY</bcp14> be allowed as long as th
		ey uniquely
		identify the region and the RBRs for the same region use the
	same Region ID.	same Region ID.

	</t>	</t>
	</section>	</section>
	<section title="Use of S-NH-EC">	<section numbered="true" toc="default">
	<t>[RFC7524] specifies the use of S-NH-EC because it does not allow ABRs	<name>Use of S-NH-EC</name>
		<t><xref target="RFC7524" format="default"/> specifies the use of the S-
		NH-EC because it does not allow ABRs
	to change the BGP next hop when they re-advertise I/S-PMSI A-D routes	to change the BGP next hop when they re-advertise I/S-PMSI A-D routes

	to downstream areas. That is only to be consistent with the MVPN	to downstream areas. That behavior is only to be consistent with the MVPN
	Inter-AS I-PMSI A-D routes, whose next hop must not be changed	Inter-AS I-PMSI A-D routes, whose next hop must not be changed
	when they're re-advertised by the segmenting ABRs for reasons specific	when they're re-advertised by the segmenting ABRs for reasons specific

	to MVPN. For EVPN,	to MVPNs. For EVPNs,
	it is perfectly fine to change the next hop when RBRs re-advertise	it is perfectly fine to change the next hop when RBRs re-advertise

	the I/S-PMSI A-D routes, instead of relying on S-NH-EC. As a result,	the I/S-PMSI A-D routes, instead of relying on the S-NH-EC. As a result,
	this document specifies that RBRs change the BGP next hop when they	this document specifies that RBRs change the BGP next hop when they

	re-advertise I/S-PMSI A-D routes and do not use S-NH-EC.	re-advertise I/S-PMSI A-D routes and do not use the S-NH-EC. This provide
	The advantage of this is that neither ingress nor egress PEs need to	s
	understand/use S-NH-EC, and a consistent procedure (based on BGP next	the advantage that neither ingress PEs nor egress PEs need to
	hop) is used for both inter-as and inter-region segmentation.	understand/use the S-NH-EC, and a consistent procedure (based on BGP next
	</t>	hops) is used for both inter-AS and inter-region segmentation.
	<t>	</t>
		<t>
	If a downstream PE/RBR needs to originate Leaf A-D routes, it constructs	If a downstream PE/RBR needs to originate Leaf A-D routes, it constructs
	an IP-based Route Target Extended Community by	an IP-based Route Target Extended Community by
	placing the IP address carried in the Next Hop of the received	placing the IP address carried in the Next Hop of the received

	I/S-PMSI A-D route in the Global Administrator field of the	I/S-PMSI A-D route in the Global Administrator field of the extended
	Community, with the Local Administrator field of this Community	community, with the Local Administrator field of this extended community
	set to 0 and setting the Extended Communities attribute of the	set to 0, and also setting the Extended Communities attribute of the
	Leaf A-D route to that Community.	Leaf A-D route to that extended community.
	</t>	</t>
	<t>Similar to [RFC7524], the upstream RBR MUST (auto-)configure	<t>Similar to <xref target="RFC7524" format="default"/>, the upstream RB
	a RT with the Global Administrator field set to the Next Hop in	R <bcp14>MUST</bcp14> (auto-)configure
		an RT with the Global Administrator field set to the Next Hop in
	the re-advertised I/S-PMSI A-D route and with the Local Administrator	the re-advertised I/S-PMSI A-D route and with the Local Administrator

	field set to 0. With this, the mechanisms specified in [RFC4684]	field set to 0. Using this technique, the mechanisms specified in <xref t arget="RFC4684" format="default"/>
	for constrained BGP route	for constrained BGP route
	distribution can be used along with this specification to ensure that	distribution can be used along with this specification to ensure that

	only the needed PE/ABR will have to process a said Leaf A-D route.	only the needed PE/ABR will have to process a particular Leaf A-D route.
	</t>	</t>
	</section>	</section>
	<section title="Ingress PE's I-PMSI Leaf Tracking">	<section numbered="true" toc="default">
	<t>[RFC7524] specifies that when an ingress PE/ASBR (re-)advertises an	<name>Ingress PE's I-PMSI Leaf Tracking</name>
		<t><xref target="RFC7524" format="default"/> specifies that when an ingr
		ess PE/ASBR (re-)advertises a
	VPLS I-PMSI A-D route, it sets the L flag to 1 in the route's PTA.	VPLS I-PMSI A-D route, it sets the L flag to 1 in the route's PTA.

	Similar to the inter-as case, this is actually not really needed	Similar to the inter-AS case, this is actually not really needed
	for EVPN. To be consistent with the inter-as case, the ingress PE	for EVPNs. To be consistent with the inter-AS case, the ingress PE
	does not set the L flag in its originated I-PMSI A-D routes,	does not set the L flag in its originated I-PMSI A-D routes,

	and determines the leaves based on the BGP next hops in its received	and it determines the leaves based on the BGP next hops in its received
	I-PMSI A-D routes, as specified in <xref target="leaf-tracking"/>.	I-PMSI A-D routes, as specified in <xref target="leaf-tracking" format="d
	</t>	efault"/>.
	<t>The same backward compatibility issue exists, and the same solution	</t>
	as in the inter-as case applies, as specified in <xref target=	<t>The same backward-compatibility issue exists, and the same solution
	"compatibility"/>.	as that for the inter-AS case applies, as specified in <xref target="comp
	</t>	atibility" format="default"/>.
	</section>	</t>
		</section>
	</section>	</section>

	<section title="Multi-homing Support">	<section numbered="true" toc="default">
	<!--	<name>Multihoming Support</name>
	<t>EVPN support active-active multi-homing. For BUM traffic, only an	<t>To support multihoming with segmentation, Ethernet Segment Identifier
	elected DF PE is allowed to send to a multi-homed Ethernet Segment (ES),	(ESI) labels <bcp14>SHOULD</bcp14> be
	while a TS may use any of its active-active links to the ES. If the	allocated from a "Domain-wide Common Block" (DCB)
	link a TS uses is not attached to the DF PE, the receiving non-DF PE	<xref target="RFC9573" format="default"/> for all
	will deliver the traffic to all PEs in the same EVI, including the DF PE	tunnel types, including Ingress Replication tunnels <xref target="RFC7988
	for the sourcing ES. To prevent the DF PE from delivering the received	"/>.
	traffic back to the ES, in case of MPLS encapsulation, a BUM packet
	from a non-DF PE carries an ESI
	label, so that when the DF receives the packet it will know from the ESI
	label that the packet is from a non-DF for an ES and will not send the
	packet back to the ES.
	</t>
	<t>To support multi-homing with segmentation, ESI labels SHOULD be
	allocated from "Domain-wide Common Block" (DCB)
	<xref target="I-D.ietf-bess-mvpn-evpn-aggregation-label"/> for all
	tunnel types including Ingress Replication.
	Via means outside the scope of this document, PEs know that ESI labels	Via means outside the scope of this document, PEs know that ESI labels

	are from DCB and then existing multi-homing procedures work as is	are from a DCB, and existing multihoming procedures will then work "as is
	(whether a multi-homed Ethernet Segment spans across segmentation	"
		(whether a multihomed Ethernet Segment spans segmentation
	regions or not).	regions or not).

	</t>
	<t>Not using DCB-allocated ESI labels is outside the scope of this
	document.<!-- It would require complicated forwarding
	procedures on segmentation points, and, in case of multi-homing across
	segmentation regions, complicated control plane procedures as well.-->
	</t>
	</section>
	<section anchor="IANA" title="IANA Considerations">
	<t>IANA has temporarily assigned the following new EVPN route types in
	the EVPN Route Types registry:
	<list style="symbols">
	<t>9 - Per-Region I-PMSI A-D route</t>
	<t>10 - S-PMSI A-D route</t>
	<t>11 - Leaf A-D route</t>
	</list>
	</t>	</t>

	<t>This document requests IANA to assign one flag bit from the	<t>Not using DCB-allocated ESI labels is outside the scope of this
	EVPN Multicast Flags Extended Community Flags registry to be created in	document.
	[draft-ietf-bess-evpn-igmp-mld-proxy]:
	<list style="symbols">
	<t>Bit-S - Segmentation Procedure Support
	</t>
	</list>
	</t>	</t>
	</section>	</section>

	<section anchor="Security" title="Security Considerations">	<section anchor="IANA" numbered="true" toc="default">
	<t>	<name>IANA Considerations</name>
	The Selective Forwarding procedures via S-PMSI/Leaf A-D routes	<t>IANA has assigned the following new EVPN route types in
	in this document are based on the same procedures for MVPN [RFC6513] [R	the "EVPN Route Types" registry:
	FC6514]
	and VPLS Multicast [RFC7117]. The tunnel segmentation procedures
	in this document are based on the similar procedures for MVPN inter-AS
	[RFC6514] and inter-area [RFC7524] tunnel segmentation, and procedures
	for VPLS Multicast [RFC7117] inter-as tunnel segmentation.
	When applied to EVPN, they do not introduce new security concerns
	besides what have been discussed in [RFC6513], [RFC6514], [RFC7117],
	and [RFC7524]. They also do not introduce new security concerns
	compared to [RFC7432].
	</t>	</t>


		<table anchor="tab-1">
		<name>New Route Types</name>
		<thead>
		<tr>
		<th>Value</th>
		<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>9</td>
		<td>Per-Region I-PMSI A-D route</td>
		<td>RFC 9572</td>
		</tr>
		<tr>
		<td>10</td>
		<td>S-PMSI A-D route</td>
		<td>RFC 9572</td>
		</tr>
		<tr>
		<td>11</td>
		<td>Leaf A-D route</td>
		<td>RFC 9572</td>
		</tr>
		</tbody>
		</table>
		<t>IANA has assigned one flag bit from the
		"Multicast Flags Extended Community" registry created by
		<xref target="RFC9251"/>:
		</t>
		<table anchor="tab-2">
		<name>New Multicast Flag</name>
		<thead>
		<tr>
		<th>Bit</th>
		<th>Name</th>
		<th>Reference</th>
		<th>Change Controller</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>8</td>
		<td>Segmentation Support</td>
		<td>RFC 9572</td>
		<td>IETF</td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

	<section anchor="Acknowledgements" title="Acknowledgements">	<section anchor="Security" numbered="true" toc="default">
	<t>The authors thank Eric Rosen, John Drake, and Ron Bonica for their	<name>Security Considerations</name>
	comments and suggestions.	<t>
		The procedures specified in this document for selective forwarding via
		S-PMSI/Leaf A-D routes
		are based on the same procedures as those used for MVPNs <xref target="
		RFC6513" format="default"/> <xref target="RFC6514" format="default"/>
		and VPLS multicast <xref target="RFC7117" format="default"/>. The proce
		dures for tunnel segmentation as specified
		in this document are based on similar procedures used for MVPN inter-AS
		tunnel segmentation <xref target="RFC6514" format="default"/> and inter-area tu
		nnel segmentation <xref target="RFC7524" format="default"/>, as well as procedur
		es
		for VPLS multicast inter-AS tunnel segmentation <xref target="RFC7117"
		format="default"/>.
		When applied to EVPNs, they do not introduce new security concerns
		beyond those discussed in <xref target="RFC6513" format="default"/>, <xref t
		arget="RFC6514" format="default"/>, <xref target="RFC7117" format="default"/>,
		and <xref target="RFC7524" format="default"/>. They also do not introduce ne
		w security concerns
		compared to <xref target="RFC7432" format="default"/>.
	</t>	</t>
	</section>	</section>

	<section title="Contributors">	</middle>
	<t>The following also contributed to this document through their earlier	<back>
	work in EVPN selective multicast.	<references>
	<figure>	<name>References</name>
	<artwork>	<references>
	Junlin Zhang	<name>Normative References</name>
	Huawei Technologies	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	Huawei Bld., No.156 Beiqing Rd.	119.xml"/>
	Beijing 100095	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	China	174.xml"/>
		<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.7
		117.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		524.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.8
		534.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"/>


	Email: jackey.zhang@huawei.com	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9251.xml" />


	Zhenbin Li	<!-- draft-ietf-bess-mvpn-evpn-aggregation-label (RFC 9573) -->
	Huawei Technologies	<reference anchor='RFC9573' target="https://www.rfc-editor.org/info/rfc9573">
	Huawei Bld., No.156 Beiqing Rd.	<front>
	Beijing 100095	<title>MVPN/EVPN Tunnel Aggregation with Common Labels</title>
	China	<author initials='Z' surname='Zhang' fullname='Zhaohui Zhang'>
		<organization />
		</author>
		<author initials='E' surname='Rosen' fullname='Eric Rosen'>
		<organization />
		</author>
		<author initials='W' surname='Lin' fullname='Wen Lin'>
		<organization />
		</author>
		<author initials='Z' surname='Li' fullname='Zhenbin Li'>
		<organization />
		</author>
		<author initials='IJ' surname='Wijnands' fullname='IJsbrand Wijnands'>
		<organization />
		</author>
		<date year='2024' month='May' />
		</front>
		<seriesInfo name="RFC" value="9573"/>
		<seriesInfo name="DOI" value="10.17487/RFC9573"/>
		</reference>


	Email: lizhenbin@huawei.com	</references>
	</artwork>	<references>
	</figure>	<name>Informative References</name>
	</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	</section>	279.xml"/>
	</middle>	<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.4
		684.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		388.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		988.xml"/>


	<back>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<references title="Normative References">	136.xml"/>
	&RFC2119;	</references>
	&RFC8174;
	&RFC7432;
	&RFC7117;
	&RFC7524;
	&RFC8584;
	&RFC8534;
	&RFC6513;
	&RFC6514;
	<?rfc include='reference.I-D.ietf-bess-evpn-igmp-mld-proxy'?>
	<?rfc include='reference.I-D.ietf-bess-mvpn-evpn-aggregation-label'?>
	</references>	</references>


	<references title="Informative References">	<section anchor="Acknowledgements" numbered="false" toc="default">
	&RFC8279;	<name>Acknowledgements</name>
	&RFC4875;	<t>The authors thank <contact fullname="Eric Rosen"/>, <contact fullname="
	&RFC4684;	John Drake"/>, and <contact fullname="Ron Bonica"/> for their
	&RFC6388;	comments and suggestions.
	&RFC7988;	</t>
	<?rfc include='reference.I-D.ietf-bess-evpn-prefix-advertisement'?>	</section>
	</references>	<section numbered="false" toc="default">
		<name>Contributors</name>
		<t>The following people also contributed to this document through their ea
		rlier
		work in EVPN selective multicast.
		</t>
		<contact fullname="Junlin Zhang">
		<organization>Huawei Technologies</organization>
		<address>
		<postal>
		<street>Huawei Bld., No. 156 Beiqing Rd.</street>
		<city>Beijing</city>
		<code>100095</code>
		<country>China</country>
		</postal>
		<email>jackey.zhang@huawei.com</email>
		</address>
		</contact>

		<contact fullname="Zhenbin Li">
		<organization>Huawei Technologies</organization>
		<address>
		<postal>
		<street>Huawei Bld., No. 156 Beiqing Rd.</street>
		<city>Beijing</city>
		<code>100095</code>
		<country>China</country>
		</postal>
		<email>lizhenbin@huawei.com</email>
		</address>
		</contact>
		</section>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 134 change blocks.
	676 lines changed or deleted	893 lines changed or added
This html diff was produced by rfcdiff 1.48.