rfc9572.original		rfc9572.txt
	BESS Z. Zhang		Internet Engineering Task Force (IETF) Z. Zhang
	Internet-Draft W. Lin		Request for Comments: 9572 W. Lin
	Updates: 7432 (if approved) Juniper Networks		Updates: 7432 Juniper Networks
	Intended status: Standards Track J. Rabadan		Category: Standards Track J. Rabadan
	Expires: May 22, 2022 Nokia		ISSN: 2070-1721 Nokia
	K. Patel		K. Patel
	Arrcus		Arrcus
	A. Sajassi		A. Sajassi
	Cisco Systems		Cisco Systems
	November 18, 2021		April 2024
	Updates on EVPN BUM Procedures		Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM)
	draft-ietf-bess-evpn-bum-procedure-updates-14		Procedures
	Abstract		Abstract
	This document specifies updated procedures for handling broadcast,		This document specifies updated procedures for handling Broadcast,
	unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),		Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs),
	including selective multicast, and provider tunnel segmentation.		including selective multicast and segmentation of provider tunnels.
	This document updates RFC 7432.		This document updates RFC 7432.
	Requirements Language
	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.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on May 22, 2022.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9572.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Revised BSD License text as described in Section 4.e of the
	the Trust Legal Provisions and are provided without warranty as		Trust Legal Provisions and are provided without warranty as described
	described in the Simplified BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language
	2.1. Tunnel Segmentation . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology
	2.1.1. Reasons for Tunnel Segmentation . . . . . . . . . . . 5		2. Tunnel Segmentation
	3. Additional Route Types of EVPN NLRI . . . . . . . . . . . . . 6		2.1. Reasons for Tunnel Segmentation
	3.1. Per-Region I-PMSI A-D route . . . . . . . . . . . . . . . 7		3. Additional Route Types of EVPN NLRI
	3.2. S-PMSI A-D route . . . . . . . . . . . . . . . . . . . . 7		3.1. Per-Region I-PMSI A-D Route
	3.3. Leaf A-D route . . . . . . . . . . . . . . . . . . . . . 8		3.2. S-PMSI A-D Route
	4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 8		3.3. Leaf A-D Route
	5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 9		4. Selective Multicast
	5.1. Differences from Section 7.2.2 of [RFC7117] When Applied		5. Inter-AS Segmentation
	to EVPN . . . . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Differences from Section 7.2.2 of RFC 7117 when Applied to
	5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 11		EVPNs
	5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 11		5.2. I-PMSI Leaf Tracking
	5.3.1. Designated ASBR Election . . . . . . . . . . . . . . 13		5.3. Backward Compatibility
	6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 13		5.3.1. Designated ASBR Election
	6.1. Area/AS vs. Region . . . . . . . . . . . . . . . . . . . 13		6. Inter-Region Segmentation
	6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 14		6.1. Area/AS vs. Region
	6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 15		6.2. Per-Region Aggregation
	6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 16		6.3. Use of S-NH-EC
	7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 16		6.4. Ingress PE's I-PMSI Leaf Tracking
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. Multihoming Support
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		9. Security Considerations
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		10.1. Normative References
	12.1. Normative References . . . . . . . . . . . . . . . . . . 18		10.2. Informative References
	12.2. Informative References . . . . . . . . . . . . . . . . . 19		Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Contributors
			Authors' Addresses
	1. Terminology		1. Introduction
	It is expected that audience is familiar with MVPN [RFC6513]		[RFC7117] specifies procedures for multicast in the Virtual Private
	[RFC6514], VPLS Multicast [RFC7117] and EVPN [RFC7432] concepts and		LAN Service (VPLS multicast), using both inclusive tunnels and
	terminologies. For convenience, the following terms are briefly		selective tunnels with or without inter-AS segmentation, similar to
	explained.		the Multicast VPN (MVPN) procedures specified in [RFC6513] and
			[RFC6514]. [RFC7524] specifies inter-area tunnel segmentation
			procedures for both VPLS multicast and MVPNs.
	o PMSI [RFC6513]: P-Multicast Service Interface - a conceptual		[RFC7432] specifies BGP MPLS-based Ethernet VPN (EVPN) procedures,
			including those handling Broadcast, Unknown Unicast, or Multicast
			(BUM) traffic. [RFC7432] refers to [RFC7117] for details but leaves
			a few feature gaps related to selective tunnel and tunnel
			segmentation (Section 2.1).
			This document aims to fill in those gaps by covering the use of
			selective and segmented tunnels in EVPNs. In the same way that
			[RFC7432] refers to [RFC7117] for details, this document only
			specifies differences from relevant procedures provided in [RFC7117]
			and [RFC7524], rather than repeating the text from those documents.
			Note that these differences are applicable to EVPNs only and are not
			updates to [RFC7117] or [RFC7524].
			MVPN, VPLS, and EVPN technologies all need to discover other Provider
			Edges (PEs) in the same L3/L2 VPN and announce the inclusive tunnels.
			MVPN technology introduced the Inclusive P-Multicast Service
			Interface (I-PMSI) concept and uses I-PMSI 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 existing VPLS A-D route for that
			purpose. For selective tunnels, they all do use the same term:
			Selective PMSI (S-PMSI) A-D routes.
			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
			BUM traffic purposes may each be referred to as an I-PMSI A-D route,
			depending on the context.
			1.1. Requirements Language
			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.
			1.2. Terminology
			It is assumed that the reader is familiar with concepts and
			terminologies related to MVPN technology [RFC6513] [RFC6514], VPLS
			multicast [RFC7117], and EVPN technology [RFC7432]. For convenience,
			the following terms are briefly explained.
			AS: Autonomous System
			PMSI [RFC6513]: P-Multicast Service Interface. A conceptual
	interface for a PE to send customer multicast traffic to all or		interface for a PE to send customer multicast traffic to all or
	some PEs in the same VPN.		some PEs in the same VPN.
	o I-PMSI: Inclusive PMSI - to all PEs in the same VPN.		I-PMSI: Inclusive PMSI. Enables traffic to be sent to all PEs in
			the same VPN.
	o S-PMSI: Selective PMSI - to some of the PEs in the same VPN.		S-PMSI: Selective PMSI. Enables traffic to be sent to some of the
			PEs in the same VPN.
	o I/S-PMSI A-D Route: Auto-Discovery routes used to announce the		I/S-PMSI A-D Route: Auto-Discovery route used to announce the
	tunnels that instantiate an I/S-PMSI.		tunnels that instantiate an I/S-PMSI.
	o Leaf Auto-Discovery (A-D) routes [RFC6513]: For explicit leaf		Leaf Auto-Discovery (A-D) Route [RFC6513]: For explicit leaf-
	tracking purpose. Triggered by I/S-PMSI A-D routes and targeted		tracking purposes. Triggered by I/S-PMSI A-D routes and targeted
	at triggering route's (re-)advertiser. Its NLRI embeds the entire		at the triggering route's (re-)advertiser. Its Network Layer
	NLRI of the triggering PMSI A-D route.		Reachability Information (NLRI) embeds the entire NLRI of the
			triggering PMSI A-D route.
	o IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D		IMET A-D Route [RFC7432]: Inclusive Multicast Ethernet Tag A-D
	route. The EVPN equivalent of MVPN Intra-AS I-PMSI A-D route used		route. The EVPN equivalent of an MVPN Intra-AS I-PMSI A-D route
	to announce the tunnels that instantiate an I-PMSI.		used to announce the tunnels that instantiate an I-PMSI.
	o SMET A-D route [I-D.ietf-bess-evpn-igmp-mld-proxy]: Selective		SMET A-D Route [RFC9251]: Selective Multicast Ethernet Tag A-D
	Multicast Ethernet Tag A-D route. The EVPN equivalent of MVPN		route. The EVPN equivalent of an MVPN Leaf A-D route, but
	Leaf A-D route but unsolicited and untargeted.		unsolicited and untargeted.
	o PMSI Tunnel Attribute (PTA): An optional transitive BGP attribute		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.
	2. Introduction		IBGP: Internal BGP (BGP connection between internal peers).
	[RFC7117] specifies procedures for Multicast in 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 [RFC6513] and [RFC6514].
	[RFC7524] specifies inter-area tunnel segmentation procedures for
	both VPLS Multicast and MVPN.
	[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
	(Section 2.1).
	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].
	MVPN, VPLS and EVPN all have the need to discover other PEs in the		EBGP: External BGP (BGP connection between external peers).
	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.
	Many places of this document involve the I-PMSI concept that is all		RT: Route Target. Controls route importation and propagation.
	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.
	2.1. Tunnel Segmentation		2. Tunnel Segmentation
	MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are		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 Section 2.1.1 of this document. [RFC6513]		which are summarized in Section 2.1 of this document. [RFC6513] and
	and [RFC6514] cover MVPN inter-as segmentation, [RFC7117] covers VPLS		[RFC6514] cover MVPN inter-AS segmentation, [RFC7117] covers VPLS
	multicast inter-as segmentation, and [RFC7524] (Seamless MPLS		multicast inter-AS segmentation, and [RFC7524] (seamless MPLS
	Multicast) covers inter-area segmentation for both MVPN and VPLS.		multicast) covers inter-area segmentation for both MVPNs and VPLSs.
	With tunnel segmentation, different segments of an end-to-end tunnel		With tunnel segmentation, different segments of an end-to-end tunnel
	may have different encapsulation overhead. However, the largest		may have different encapsulation overheads. However, the largest
	overhead of the tunnel caused by an encapsulation method on a		overhead of the tunnel caused by an encapsulation method on a
	particular segment is not different from the case of a non-segmented		particular segment is not different from the case of a non-segmented
	tunnel with that encapsulation method. This is similar to the case		tunnel with that encapsulation method. This is similar to the case
	of a network with different link types.		of a network with different link types.
	There is a difference between MVPN and VPLS multicast inter-as		There is a difference between MVPN and VPLS multicast inter-AS
	segmentation (the VPLS approach is briefly discribed in Section 5.1).		segmentation (the VPLS approach is briefly described in Section 5.1).
	For simplicity, EVPN will use the same procedures as in MVPN. All		For simplicity, EVPNs will use the same procedures as those for
	ASBRs can re-advertise their choice of the best route. Each can		MVPNs. All ASBRs can re-advertise their choice of the best route.
	become the root of its intra-AS segment and inject traffic it		Each can become the root of its intra-AS segment and inject traffic
	receives from its upstream, while each downstream PE/ASBR will only		it receives from its upstream, while each downstream PE/ASBR will
	pick one of the upstream ASBRs as its upstream. This is also the		only pick one of the upstream ASBRs as its upstream. This is also
	behavior even for VPLS in case of inter-area segmentation.		the behavior even for VPLS in the case of inter-area segmentation.
	For inter-area segmentation, [RFC7524] requires the use of Inter-area		For inter-area segmentation, [RFC7524] requires the use of the Inter-
	P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting		Area Point-to-Multipoint (P2MP) Segmented Next-Hop Extended Community
	of "Leaf Information Required" L flag in PTA in certain situations.		(S-NH-EC) and the setting of the Leaf Information Required (L) flag
	In the EVPN case, the requirements around S-NH-EC and the PTA "L"		in the PTA in certain situations. In the EVPN case, the requirements
	flag differ from [RFC7524] to make the segmentation procedures		around the S-NH-EC and the L flag in the PTA differ from [RFC7524] to
	transparent to ingress and egress PEs.		make the segmentation procedures transparent to ingress and egress
			PEs.
	[RFC7524] assumes that segmentation happens at area borders.		[RFC7524] assumes that segmentation happens 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 (Section 6.1).		sub-area, or even an entire AS plus its external links (Section 6.1);
	That would allow for more flexible deployment scenarios (e.g. for		this would allow for more flexible deployment scenarios (e.g., for
	single-area provider networks). This document extends the inter-area		single-area provider networks). This document extends the inter-area
	segmentation to inter-region segmentation for EVPN.		segmentation concept to inter-region segmentation for EVPNs.
	2.1.1. Reasons for Tunnel Segmentation		2.1. Reasons for Tunnel Segmentation
	Tunnel segmentation may be required and/or desired because of		Tunnel segmentation may be required and/or desired for administrative
	administrative and/or technical reasons.		and/or technical reasons.
	For example, an MVPN/VPLS/EVPN network may span multiple providers		For example, an MVPN/VPLS/EVPN may span multiple providers, and the
	and the end-to-end provider tunnels have to be segmented at and		end-to-end provider tunnels have to be segmented at and stitched by
	stitched by the ASBRs. Different providers may use different tunnel		the ASBRs. Different providers may use different tunnel technologies
	technologies (e.g., provider A uses Ingress Replication [RFC7988],		(e.g., provider A uses ingress replication [RFC7988], provider B uses
	provider B uses RSVP-TE P2MP [RFC4875] while provider C uses mLDP		RSVP-TE P2MP [RFC4875], and provider C uses Multipoint LDP (mLDP)
	[RFC6388]). Even if they use the same tunnel technology like RSVP-TE		[RFC6388]). Even if they use the same tunnel technology (e.g., RSVP-
	P2MP, it may be impractical to set up the tunnels across provider		TE P2MP), it may be impractical to set up the tunnels across provider
	boundaries.		boundaries.
	The same situations may apply between the ASes and/or areas of a		The same situations may apply between the ASes and/or areas of a
	single provider. For example, the backbone area may use RSVP-TE P2MP		single provider. For example, the backbone area may use RSVP-TE P2MP
	tunnels while non-backbone areas may use mLDP tunnels.		tunnels while non-backbone areas may use mLDP tunnels.
	Segmentation can also be used to divide an AS/area into smaller		Segmentation can also be used to divide an AS/area into smaller
	regions, so that control plane state and/or forwarding plane state/		regions, so that control plane state and/or forwarding plane state/
	burden can be limited to that of individual regions. For example,		burden can be limited to that of individual regions. For example,
	instead of Ingress Replicating to 100 PEs in the entire AS, with		instead of ingress-replicating to 100 PEs in the entire AS, with
	inter-area segmentation [RFC7524] a PE only needs to replicate to		inter-area segmentation [RFC7524], a PE only needs to replicate to
	local PEs and ABRs. The ABRs will further replicate to their		local PEs and Area Border Routers (ABRs). The ABRs will further
	downstream PEs and ABRs. This not only reduces the forwarding plane		replicate to their downstream PEs and ABRs. This not only reduces
	burden, but also reduces the leaf tracking burden in the control		the forwarding plane burden, but also reduces the leaf-tracking
	plane.		burden in the control plane.
	Smaller regions also have the benefit that, in case of tunnel		In the case of tunnel aggregation, smaller regions provide the
	aggregation, it is easier to find congruence among the segments of		benefit 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		(base) tunnel in a region. This leads to better bandwidth
	efficiency, because the more congruent they are, the fewer leaves of		efficiency, because the more congruent they are, the fewer leaves of
	the base tunnel need to discard traffic when a service tunnel's		the base tunnel need to discard traffic when a service tunnel's
	segment does not need to receive the traffic (yet it is receiving the		segment does not need to receive the traffic (yet it is receiving the
	traffic due to aggregation).		traffic due to aggregation).
	Another advantage of the smaller region is smaller BIER [RFC8279]		Another advantage of the smaller region is smaller Bit Index Explicit
	sub-domains. With BIER, packets carry a BitString, in which the bits		Replication (BIER) subdomains [RFC8279]. With BIER, packets carry a
	correspond to edge routers that needs to receive traffic. Smaller		BitString, in which the bits correspond to edge routers that need to
	sub-domains means smaller BitStrings can be used without having to		receive traffic. Smaller subdomains means that smaller BitStrings
	send multiple copies of the same packet.		can be used without having to send multiple copies of the same
			packet.
	3. Additional Route Types of EVPN NLRI		3. Additional Route Types of EVPN NLRI
	[RFC7432] defines the format of EVPN NLRI as the following:		[RFC7432] defines the format of EVPN NLRI as follows:
	+-----------------------------------+		+-----------------------------------+
	| Route Type (1 octet) |		| Route Type (1 octet) |
	+-----------------------------------+		+-----------------------------------+
	| Length (1 octet) |		| Length (1 octet) |
	+-----------------------------------+		+-----------------------------------+
	| Route Type specific (variable) |		| Route Type specific (variable) |
	+-----------------------------------+		+-----------------------------------+
	So far eight route types have been defined in [RFC7432],		So far, eight route types have been defined in [RFC7432], [RFC9136],
	[I-D.ietf-bess-evpn-prefix-advertisement], and		and [RFC9251]:
	[I-D.ietf-bess-evpn-igmp-mld-proxy]:
	+ 1 - Ethernet Auto-Discovery (A-D) route		+=======+=========================================+
	+ 2 - MAC/IP Advertisement route		| Value | Description |
	+ 3 - Inclusive Multicast Ethernet Tag route		+=======+=========================================+
	+ 4 - Ethernet Segment route		| 1 | Ethernet Auto-discovery |
	+ 5 - IP Prefix Route		+-------+-----------------------------------------+
	+ 6 - Selective Multicast Ethernet Tag Route		| 2 | MAC/IP Advertisement |
	+ 7 - Multicast Join Synch Route		+-------+-----------------------------------------+
	+ 8 - Multicast Leave Synch Route		| 3 | Inclusive Multicast Ethernet Tag |
			+-------+-----------------------------------------+
			| 4 | Ethernet Segment |
			+-------+-----------------------------------------+
			| 5 | IP Prefix |
			+-------+-----------------------------------------+
			| 6 | Selective Multicast Ethernet Tag Route |
			+-------+-----------------------------------------+
			| 7 | Multicast Membership Report Synch Route |
			+-------+-----------------------------------------+
			| 8 | Multicast Leave Synch Route |
			+-------+-----------------------------------------+
			Table 1: Pre-existing Route Types
	This document defines three additional route types:		This document defines three additional route types:
	+ 9 - Per-Region I-PMSI A-D route		+=======+=============================+
	+ 10 - S-PMSI A-D route		| Value | Description |
	+ 11 - Leaf A-D route		+=======+=============================+
			| 9 | Per-Region I-PMSI A-D route |
			+-------+-----------------------------+
			| 10 | S-PMSI A-D route |
			+-------+-----------------------------+
			| 11 | Leaf A-D route |
			+-------+-----------------------------+
	The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs		Table 2: New Route Types
	starts with a type 1 RD, whose Administrator sub-field MUST match
	that of the RD in all current non-Leaf A-D (Section 3.3) EVPN routes
	from the same advertising router for a given EVI.
	3.1. Per-Region I-PMSI A-D route		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-field MUST match that of the RD in all current EVPN routes that
			are not Leaf A-D routes (Section 3.3), i.e., non-Leaf A-D routes from
			the same advertising router for a given EVPN instance (EVI).
	The Per-region I-PMSI A-D route has the following format. Its usage		3.1. Per-Region I-PMSI A-D Route
			The per-region I-PMSI A-D route has the following format. Its usage
	is discussed in Section 6.2.		is discussed in Section 6.2.
	+-----------------------------------+		+-----------------------------------+
	| RD (8 octets) |		| RD (8 octets) |
	+-----------------------------------+		+-----------------------------------+
	| Ethernet Tag ID (4 octets) |		| Ethernet Tag ID (4 octets) |
	+-----------------------------------+		+-----------------------------------+
	| Region ID (8 octets) |		| Region ID (8 octets) |
	+-----------------------------------+		+-----------------------------------+
	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
	Extended Community is encoded, as detailed in Section 6.2.		that an EC is encoded, as detailed in Section 6.2.
	3.2. S-PMSI A-D route		3.2. S-PMSI A-D Route
	The S-PMSI A-D route has the following format:		The S-PMSI A-D route has the following format:
	+-----------------------------------+		+-----------------------------------+
	| 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) |
	+-----------------------------------+		+-----------------------------------+
	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 to the S-PMSI A-D route as defined in		Length fields, it is identical to the S-PMSI A-D route as defined in
	[RFC7117]. The procedures in [RFC7117] also apply (including		[RFC7117]. The procedures specified in [RFC7117] also apply
	wildcard functionality), except that the granularity level is per		(including wildcard functionality), except that the granularity level
	Ethernet Tag.		is per Ethernet Tag.
	3.3. Leaf A-D route		3.3. Leaf A-D Route
	The Route Type specific field of a Leaf A-D route consists of the		The Route Type specific field of a Leaf A-D route consists of the
	following:		following:
	+-----------------------------------+		+-----------------------------------+
	| 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) |
	+-----------------------------------+		+-----------------------------------+
	A Leaf A-D route is originated in response to a PMSI route, which		A Leaf A-D route is originated in response to a PMSI route, which
	could be an Inclusive Multicast Tag route, a per-region I-PMSI A-D		could be an IMET A-D route, a per-region I-PMSI A-D route, an S-PMSI
	route, an S-PMSI A-D route, or some other types of routes that may be		A-D route, or some other types of routes that may be defined in the
	defined in the future that triggers Leaf A-D routes. The Route Key		future that trigger Leaf A-D routes. The Route Key is the NLRI of
	is the NLRI of the route for which this Leaf A-D route is generated.		the route for which this Leaf A-D route is generated.
	The general procedures of Leaf A-D route are first specified in		The general procedures for Leaf A-D routes were first specified in
	[RFC6514] for MVPN. The principles apply to VPLS and EVPN as well.		[RFC6514] for MVPNs. The principles therein apply to VPLSs and EVPNs
	[RFC7117] has details for VPLS Multicast, and this document points		as well. [RFC7117] provides details regarding VPLS multicast, and
	out some specifics for EVPN, e.g. in Section 5.		this document points out some specifics for EVPNs, e.g., in
			Section 5.
	4. Selective Multicast		4. Selective Multicast
	[I-D.ietf-bess-evpn-igmp-mld-proxy] specifies procedures for EVPN		[RFC9251] specifies procedures for EVPN selective forwarding of IP
	selective forwarding of IP multicast using SMET routes. It assumes		multicast traffic using SMET routes. It assumes that selective
	selective forwarding is always used with IR for all flows (though the		forwarding is always used with ingress replication for all flows
	same signaling can also be used for an ingress PE to find out the set		(though the same signaling can also be used for an ingress PE to
	of egress PEs for selective forwarding with BIER). An NVE proxies		learn the set of egress PEs for selective forwarding with BIER). A
	the IGMP/MLD state that it learns on its ACs to (C-S,C-G) or		Network Virtualization Edge (NVE) proxies the IGMP/MLD state ("MLD"
	(C-*,C-G) SMET routes that advertises to other NVEs, and a receiving		stands for "Multicast Listener Discovery") that it learns on its
	NVE converts the SMET routes back to IGMP/MLD messages and sends them		Attachment Circuits (ACs) to (C-S,C-G) or (C-*,C-G) SMET routes that
	out of its ACs. The receiving NVE also uses the SMET routes to		are advertised to other NVEs, and a receiving NVE converts the SMET
	identify which NVEs need to receive traffic for a particular		routes back to IGMP/MLD messages and sends them out of its ACs. The
	(C-S,C-G) or (C-*,C-G) to achieve selective forwarding using IR or		receiving NVE also uses the SMET routes to identify which NVEs need
	BIER.		to receive traffic for a particular (C-S,C-G) or (C-*,C-G) to achieve
			selective forwarding using ingress replication or BIER.
	With the above procedures, selective forwarding is done for all flows		With the above procedures, selective forwarding is done for all
	and the SMET routes are advertised for all flows. It is possible		flows, and the SMET routes are advertised for all flows. It is
	that an operator may not want to track all those (C-S, C-G) or		possible that an operator may not want to track all those (C-S, C-G)
	(C-*,C-G) state on the NVEs, and the multicast traffic pattern allows		or (C-*,C-G) states on the NVEs, and the multicast traffic pattern
	inclusive forwarding for most flows while selective forwarding is		allows inclusive forwarding for most flows while selective forwarding
	needed only for a few high-rate flows. For that, or for tunnel types		is needed only for a few high-rate flows. For that reason, or for
	other than IR/BIER, S-PMSI/Leaf A-D procedures defined for Selective		tunnel types other than ingress replication or BIER, S-PMSI/Leaf A-D
	Multicast for VPLS in [RFC7117] are used. Other than that different		procedures defined for selective multicast for VPLS in [RFC7117] are
	route types and formats are specified with EVPN SAFI for S-PMSI A-D		used. Other than the fact that different route types and formats are
	and Leaf A-D routes (Section 3), all procedures in [RFC7117] with		specified with an EVPN SAFI for S-PMSI A-D and Leaf A-D routes
	respect to Selective Multicast apply to EVPN as well, including		(Section 3), all procedures specified in [RFC7117] with respect to
	wildcard procedures. In a nutshell, a source NVE advertises S-PMSI		selective multicast apply to EVPNs as well, including wildcard
	A-D routes to announce the tunnels used for certain flows, and		procedures. In a nutshell, a source NVE advertises S-PMSI A-D routes
	receiving NVEs either join the announced PIM/mLDP tunnel or respond		to announce the tunnels used for certain flows, and receiving NVEs
	with Leaf A-D routes if the Leaf Information Required flag is set in		either join the announced PIM/mLDP tunnel or respond with Leaf A-D
	the S-PMSI A-D route's PTA (so that the source NVE can include them		routes if the L flag is set in the S-PMSI A-D route's PTA (so that
	as tunnel leaves).		the source NVE can include them as tunnel leaves).
	An optimization to the [RFC7117] procedures may be applied. Even if		An optimization to the procedures provided in [RFC7117] may be
	a source NVE sets the L flag to request Leaf A-D routes, an egress		applied. Even if a source NVE sets the L flag to request Leaf A-D
	NVE MAY omit the Leaf A-D route if it has already advertised a		routes, an egress NVE MAY omit the Leaf A-D route if it has already
	corresponding SMET route, and the source NVE MUST use that in lieu of		advertised a corresponding SMET route, and the source NVE MUST use
	the Leaf A-D route.		that in lieu of the Leaf A-D route.
	The optional optimizations specified for MVPN in [RFC8534] are also		The optional optimizations specified for MVPNs in [RFC8534] are also
	applicable to EVPN when the S-PMSI/Leaf A-D routes procedures are		applicable to EVPNs when the procedures for S-PMSI/Leaf A-D routes
	used for EVPN selective multicast forwarding.		are used for EVPN selective multicast forwarding.
	5. Inter-AS Segmentation		5. Inter-AS Segmentation
	5.1. Differences from Section 7.2.2 of [RFC7117] When Applied to EVPN		5.1. Differences from Section 7.2.2 of RFC 7117 when Applied to EVPNs
	The first paragraph of Section 7.2.2.2 of [RFC7117] says:		The first paragraph of Section 7.2.2.2 of [RFC7117] says:
	"... The best route procedures ensure that if multiple		| ... The best route procedures ensure that if multiple ASBRs, in an
	ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP		| AS, receive the same Inter-AS A-D route from their EBGP neighbors,
	neighbors, only one of these ASBRs propagates this route in Internal		| only one of these ASBRs propagates this route in Internal BGP
	BGP (IBGP). This ASBR becomes the root of the intra-AS segment of		| (IBGP). This ASBR becomes the root of the intra-AS segment of the
	the inter-AS tree and ensures that this is the only ASBR that accepts		| 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.
	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 is		for the ASBRs to reach agreement. For EVPNs, a different approach is
	used and the above quoted text is not applicable to EVPN.		used; the above text from [RFC7117] is not applicable to EVPNs.
	With the different approach for EVPN/MVPN, each ASBR will re-		With the different approach for EVPNs/MVPNs, each ASBR will re-
	advertise its received Inter-AS A-D route to its IBGP peers and		advertise 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		becomes the root of an intra-AS segment of the inter-AS tree. The
	intra-AS segment rooted at one ASBR is disjoint with another intra-AS		intra-AS segment rooted at one ASBR is disjoint from another intra-AS
	segment rooted at another ASBR. This is the same as the procedures		segment rooted at another ASBR. This is the same as the procedures
	for S-PMSI in [RFC7117] itself.		for S-PMSI routes in [RFC7117] itself.
	The following bullet in Section 7.2.2.2 of [RFC7117] does not apply		The following bullet in Section 7.2.2.2 of [RFC7117] does not apply
	to EVPN.		to EVPNs.
	+ If the ASBR uses ingress replication to instantiate the intra-AS		| * If the ASBR uses ingress replication to instantiate the intra-
	segment of the inter-AS tunnel, the re-advertised route MUST NOT		| AS segment of the inter-AS tunnel, the re-advertised route MUST
	carry the PMSI Tunnel attribute.		| NOT carry the PMSI Tunnel attribute.
	The following bullet in Section 7.2.2.2 of [RFC7117]:		The following bullet in Section 7.2.2.2 of [RFC7117]:
	+ If the ASBR uses a P-multicast tree to instantiate the intra-AS		| * If the ASBR uses a P-multicast tree to instantiate the intra-AS
	segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST		| segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST
	contain the identity of the tree that is used to instantiate the		| contain the identity of the tree that is used to instantiate
	segment (note that the ASBR could create the identity of the tree		| the segment (note that the ASBR could create the identity of
	prior to the actual instantiation of the segment). If, in order		| the tree prior to the actual instantiation of the segment).
	to instantiate the segment, the ASBR needs to know the leaves of		| If, in order to instantiate the segment, the ASBR needs to know
	the tree, then the ASBR obtains this information from the A-D		| the leaves of the tree, then the ASBR obtains this information
	routes received from other PEs/ASBRs in the ASBR's own AS.		| from the A-D routes received from other PEs/ASBRs in the ASBR's
			| own AS.
	is changed to the following when applied to EVPN:		is changed to the following when applied to EVPNs:
	"The PMSI Tunnel attribute MUST specify the tunnel for the segment.		| * The PTA MUST specify the tunnel for the segment. If and only
	If and only if, in order to establish the tunnel, the ASBR needs to		| if, in order to establish the tunnel, the ASBR needs to know
	know the leaves of the tree, then the ASBR MUST set the L flag to		| the leaves of the tree, then the ASBR MUST set the L flag to 1
	1 in the PTA to trigger Leaf A-D routes from egress PEs and		| 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 MUST be (auto-)configured with an import
	which controls acceptance of leaf A-D routes by the ASBR."		| RT, which controls acceptance of Leaf A-D routes by the ASBR.
	Accordingly, the following paragraph in Section 7.2.2.4 of [RFC7117]:		Accordingly, the following paragraph in Section 7.2.2.4 of [RFC7117]:
	"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
	with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR		| attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then
	that originated the route MUST establish an RSVP-TE P2MP LSP with the		| the ASBR that originated the route MUST establish an RSVP-TE P2MP
	local PE/ASBR as a leaf. This LSP MAY have been established before		| LSP with the local PE/ASBR as a leaf. This LSP MAY have been
	the local PE/ASBR receives the route, or it MAY be established after		| established before the local PE/ASBR receives the route, or it MAY
	the local PE receives the route."		| be established after the local PE receives the route.
	is changed to the following when applied to EVPN:		is changed to the following when applied to EVPNs:
	"If the received Inter-AS A-D route has the L flag set in its PTA,		| If the received Inter-AS A-D route has the L flag set in its PTA,
	then a receiving PE MUST originate a corresponding Leaf A-D route,		| then a receiving PE MUST originate a corresponding Leaf A-D route.
	while a receiving ASBR MUST originate a corresponding Leaf A-D route		| A receiving ASBR MUST originate a corresponding Leaf A-D route if
	if and only if it received and imported one or more corresponding		| and only if one of the following conditions is met: (1) it
	Leaf A-D routes from its downstream IBGP or EBGP peers, or it has		| received and imported one or more corresponding Leaf A-D routes
	non-null downstream forwarding state for the PIM/mLDP tunnel that		| from its downstream IBGP or EBGP peers or (2) it has non-null
	instantiates its downstream intra-AS segment. The targeted ASBR for		| downstream forwarding state for the PIM/mLDP tunnel that
	the Leaf A-D route, which (re-)advertised the Inter-AS A-D route,		| instantiates its downstream intra-AS segment. The targeted ASBR
	MUST establish a tunnel to the leaves discovered by the Leaf A-D		| for the Leaf A-D route, which (re-)advertised the Inter-AS A-D
	routes."		| route, MUST establish a tunnel to the leaves discovered by the
			| Leaf A-D routes.
	5.2. I-PMSI Leaf Tracking		5.2. I-PMSI Leaf Tracking
	An ingress PE does not set the L flag in its Inclusive Multicast		An ingress PE does not set the L flag in its IMET A-D route's PTA,
	Ethernet Tag (IMET) A-D route's PTA, even with Ingress Replication or		even with Ingress Replication tunnels or RSVP-TE P2MP tunnels. It
	RSVP-TE P2MP tunnels. It does not rely on the Leaf A-D routes to		does not rely on the Leaf A-D routes to discover leaves in its AS,
	discover leaves in its AS, and Section 11.2 of [RFC7432] explicitly		and Section 11.2 of [RFC7432] explicitly states that the L flag must
	states that the L flag must be set to zero.		be set to 0.
	An implementation of [RFC7432] might have used the Originating		An implementation of [RFC7432] might have used the Originating
	Router's IP Address field of the IMET A-D routes to determine the		Router's IP Address field of the IMET A-D routes to determine the
	leaves, or might have used the Next Hop field instead. Within the		leaves or might have used the Next Hop field instead. Within the
	same AS, both will lead to the same result.		same AS, both will lead to the same result.
	With segmentation, an ingress PE MUST determine the leaves in its AS		With segmentation, an ingress PE MUST determine the leaves in its AS
	from the BGP next hops in all its received IMET A-D routes, so it		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. PEs		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 in their IMET		within the same AS will all have different next hops in their IMET
	A-D routes (hence will all be considered as leaves), and PEs from		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 routes set to		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 ASBRs will be		addresses of ASBRs in this local AS; hence, only those ASBRs will be
	considered as leaves (as proxies for those PEs in other ASes). Note		considered as leaves (as proxies for those PEs in other ASes). Note
	that in case of Ingress Replication, when an ASBR re-advertises IMET		that in the case of ingress replication, when an ASBR re-advertises
	A-D routes to IBGP peers, it MUST advertise the same label for all		IMET A-D routes to IBGP peers, it MUST advertise the same label for
	those for the same Ethernet Tag ID and the same EVI. Otherwise,		all those routes for the same Ethernet Tag ID and the same EVI.
	duplicated copies will be sent by the ingress PE and received by		Otherwise, duplicated copies will be sent by the ingress PE and
	egress PEs in other regions. For the same reason, when an ingress PE		received by egress PEs in other regions. For the same reason, when
	builds its flooding list, if multiple routes have the same (nexthop,		an ingress PE builds its flooding list, if multiple routes have the
	label) tuple they MUST only be added as a single branch in the		same (nexthop, label) tuple, they MUST only be added as a single
	flooding list.		branch in the flooding list.
	5.3. Backward Compatibility		5.3. Backward Compatibility
	The above procedures assume that all PEs are upgraded to support the		The above procedures assume that all PEs are upgraded to support the
	segmentation procedures:		segmentation procedures:
	o An ingress PE uses the Next Hop and not Originating Router's IP		* An ingress PE uses the Next Hop and not the Originating Router's
	Address to determine leaves for the I-PMSI tunnel.		IP Address to determine leaves for the I-PMSI tunnel.
	o An egress PE sends Leaf A-D routes in response to I-PMSI routes,		* 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.
	o In case of Ingress Replication, when an ingress PE builds its		* In the case of ingress replication, when an ingress PE builds its
	flooding list, multiple I-PMSI routes may have the same (nexthop,		flooding list, multiple I-PMSI routes may have the same (nexthop,
	label) tuple and only a single branch for those will be added in		label) tuple, and only a single branch for those routes will be
	the flooding list.		added in the flooding list.
	If a deployment has legacy PEs that does not support the above, then		If a deployment has legacy PEs that do not support the above, then a
	a legacy ingress PE would include all PEs (including those in remote		legacy ingress PE would include all PEs (including those in remote
	ASes) as leaves of the inclusive tunnel and try to send traffic to		ASes) as leaves of the inclusive tunnel and try to send traffic to
	them directly (no segmentation), which is either undesired or not		them directly (no segmentation), which is either undesirable or
	possible; a legacy egress PE would not send Leaf A-D routes so the		impossible; a legacy egress PE would not send Leaf A-D routes so the
	ASBRs would not know to send external traffic to them.		ASBRs would not know to send external traffic to them.
	If this backward compatibility problem needs to be addressed, the		If this backward-compatibility problem needs to be addressed, the
	following procedure MUST be used (see Section 6.2 for per-PE/AS/		following procedure MUST be used (see Section 6.2 for per-PE/AS/
	region I-PMSI A-D routes):		region I-PMSI A-D routes):
	o An upgraded PE indicates in its per-PE I-PMSI A-D route that it		* An upgraded PE indicates in its per-PE I-PMSI A-D route that it
	supports the new procedures. This is done by setting a flag bit		supports the new procedures. This is done by setting a flag bit
	in the EVPN Multicast Flags Extended Community.		in the EVPN Multicast Flags Extended Community.
	o All per-PE I-PMSI A-D routes are restricted to the local AS and		* All per-PE I-PMSI A-D routes are restricted to the local AS and
	not propagated to external peers.		not propagated to external peers.
	o The ASBRs in an AS originate per-region I-PMSI A-D routes and		* The ASBRs in an AS originate per-region I-PMSI A-D routes and
	advertise them to their external peers to specify tunnels used to		advertise them to their external peers to specify tunnels used to
	carry traffic from the local AS to other ASes. Depending on the		carry traffic from the local AS to other ASes. Depending on the
	types of tunnels being used, the L flag in the PTA may be set, in		types of tunnels being used, the L flag in the PTA may be set, in
	which case the downstream ASBRs and upgraded PEs will send Leaf		which case the downstream ASBRs and upgraded PEs will send Leaf
	A-D routes to pull traffic from their upstream ASBRs. In a		A-D routes to pull traffic from their upstream ASBRs. In a
	particular downstream AS, one of the ASBRs is elected, based on		particular downstream AS, one of the ASBRs is elected, based on
	the per-region I-PMSI A-D routes for a particular source AS, to		the per-region I-PMSI A-D routes for a particular source AS, to
	send traffic from that source AS to legacy PEs in the downstream		send traffic from that source AS to legacy PEs in the downstream
	AS. The traffic arrives at the elected ASBR on the tunnel		AS. The traffic arrives at the elected ASBR on the tunnel
	announced in the best per-region I-PMSI A-D route for the source		announced in the best per-region I-PMSI A-D route for the source
	AS, that the ASBR has selected of all those that it received over		AS, as selected by the ASBR from all the routes that it received
	EBGP or IBGP sessions. The election procedure is described in		over EBGP or IBGP sessions. The election procedure is described
	Section 5.3.1.		in Section 5.3.1.
	o In an ingress/upstream AS, if and only if an ASBR has active		* In an ingress/upstream AS, if and only if an ASBR has active
	downstream receivers (PEs and ASBRs), which are learned either		downstream receivers (PEs and ASBRs), which are learned either
	explicitly via Leaf A-D routes or implicitly via PIM join or mLDP		explicitly 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		label mapping, the ASBR originates a per-PE I-PMSI A-D route
	(i.e., regular Inclusive Multicast Ethernet Tag route) into the		(i.e., a regular IMET route) into the local AS and stitches
	local AS, and stitches incoming per-PE I-PMSI tunnels into its		incoming per-PE I-PMSI tunnels into its per-region I-PMSI tunnel.
	per-region I-PMSI tunnel. With this, it gets traffic from local		Via this process, it gets traffic from local PEs and sends the
	PEs and send to other ASes via the tunnel announced in its per-		traffic to other ASes via the tunnel announced in its per-region
	region I-PMSI A-D route.		I-PMSI A-D route.
	Note that, even if there is no backward compatibility issue, the use		Note that even if there are no backward-compatibility issues, the use
	of per-region I-PMSI has the benefit of keeping all per-PE I-PMSI A-D		of per-region I-PMSI A-D routes provides the benefit of keeping all
	routes in their local ASes, greatly reducing the flooding of the		per-PE I-PMSI A-D routes in their local ASes, greatly reducing the
	routes and their corresponding Leaf A-D routes (when needed), and the		flooding of the routes and their corresponding Leaf A-D routes (when
	number of inter-as tunnels.		needed) and reducing the number of inter-AS tunnels.
	5.3.1. Designated ASBR Election		5.3.1. Designated ASBR Election
	When an ASBR re-advertises a per-region I-PMSI A-D route into an AS		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 to the		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. The EC and		legacy PEs in the AS, it MUST include a Designated Forwarder (DF)
	its use is specified in [RFC8584]. The AC-DF bit in the DF Election		Election EC. The EC and its use are specified in [RFC8584]. The AC-
	EC MUST be cleared. If it is known that no legacy PEs exist in the		DF bit in the DF Election EC MUST be cleared. If it is known that no
	AS, the ASBR MUST NOT include the EC and MUST remove the DF Election		legacy PEs exist in the AS, the ASBR MUST NOT include the EC and MUST
	EC if one is carried in the per-region I-PMSI A-D routes that it		remove the DF Election EC if one is carried in the per-region I-PMSI
	receives. Note that this is done for each set of per-region I-PMSI		A-D routes that it receives. Note that this is done for each set of
	A-D routes with the same NLRI.		per-region I-PMSI A-D routes with the same NLRI.
	Based on the procedures in [RFC8584], an election algorithm is		Based on the procedures specified in [RFC8584], an election algorithm
	determined according to the DF Election ECs carried in the set of		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 the AS.		per-region I-PMSI routes of the same NLRI re-advertised into the AS.
	The algorithm is then applied to a candidate list, which is the set		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		of ASBRs that re-advertised the per-region I-PMSI routes of the same
	NLRI carrying the DF Election EC.		NLRI carrying the DF Election EC.
	6. Inter-Region Segmentation		6. Inter-Region Segmentation
	6.1. Area/AS vs. Region		6.1. Area/AS vs. Region
	[RFC7524] is for MVPN/VPLS inter-area segmentation and does not		[RFC7524] addresses MVPN/VPLS inter-area segmentation and does not
	explicitly cover EVPN. However, if "area" is replaced by "region"		explicitly cover EVPNs. However, if "area" is replaced by "region"
	and "ABR" is replaced by "RBR" (Regional Border Router) then		and "ABR" is replaced by "RBR" (Regional Border Router), then
	everything still works, and can be applied to EVPN as well.		everything still works and can be applied to EVPNs as well.
	A region can be a sub-area, or can be an entire AS including its		A region can be a sub-area, or it can be an entire AS, including its
	external links. Instead of automatic region definition based on IGP		external links. Instead of automatically defining a region based on
	areas, a region would be defined as a BGP peer group. In fact, even		IGP areas, a region would be defined as a BGP peer group. In fact,
	with IGP area based region definition, a BGP peer group listing the		even with a region definition based on an IGP area, a BGP peer group
	PEs and ABRs in an area is still needed.		listing the PEs and ABRs in an area is still needed.
	Consider the following example diagram for inter-as segmentation:		Consider the following example diagram for inter-AS segmentation:
	--------- ------ ---------		--------- ------ ---------
	/ \ / \ / \		/ \ / \ / \
	/ \ / \ / \		/ \ / \ / \
	| 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
	The inter-as segmentation procedures specified so far ([RFC6513]		The inter-AS segmentation procedures specified so far ([RFC6513],
	[RFC6514], [RFC7117], and Section 5 of this document) require all		[RFC6514], [RFC7117], and Section 5 of this document) require all
	ASBRs to be involved, and Ingress Replication is used between two		ASBRs to be involved, and ingress replication is used between two
	ASBRs in different ASes.		ASBRs in different ASes.
	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 entire		segmentation procedures can be used instead -- a region is the entire
	(AS100 + ASBR1-ASBR2 link) or (AS300 + ASBR3-ASBR4 link). ASBR2/3		AS100 plus the ASBR1-ASBR2 link or the entire AS300 plus the
	would be the RBRs, and ASBR1/4 will just be a transit core router		ASBR3-ASBR4 link. ASBR2/3 would be the RBRs, and ASBR1/4 will just
	with respect to provider tunnels.		be a transit core router with respect to provider tunnels.
	As illustrated in the diagram below, ASBR2/3 will establish a		As illustrated in the diagram below, ASBR2/3 will establish a
	multihop EBGP session with either a RR or directly with PEs in the		multihop EBGP session, either with a Route Reflector (RR) or directly
	neighboring AS. I/S-PMSI A-D routes from ingress PEs will not be		with PEs in the neighboring AS. I/S-PMSI A-D routes from ingress PEs
	processed by ASBR1/4. When ASBR2 re-advertises the routes into AS		will not be processed by ASBR1/4. When ASBR2 re-advertises the
	200, it changes the next hop to its own address and changes PTA to		routes into AS 200, it changes the next hop to its own address and
	specify the tunnel type/identification in its own AS. When ASBR3 re-		changes its PTA to specify the tunnel type/identification in its own
	advertises I/S-PMSI A-D routes into the neighboring AS 300, it		AS. When ASBR3 re-advertises I/S-PMSI A-D routes into the
	changes the next hop to its own address and changes PTA to specify		neighboring AS 300, it changes the next hop to its own address and
	the tunnel type/identification in the neighboring region. Now the		changes its PTA to specify the tunnel type/identification in the
	segment is rooted at ASBR3 and extends across the external link to		neighboring region. Now, the segment is rooted at ASBR3 and extends
	PEs.		across the external link to PEs.
	--------- ------ ---------		--------- ------ ---------
	/ 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
	6.2. Per-region Aggregation		6.2. Per-Region Aggregation
	Notice that every I/S-PMSI route from each PE will be propagated		Notice that every I/S-PMSI route from each PE will be propagated
	throughout all the ASes or regions. They may also trigger		throughout all the ASes or regions. They may also trigger
	corresponding Leaf A-D routes depending on the types of tunnels used		corresponding Leaf A-D routes, depending on the types of tunnels used
	in each region. This may become too many - routes and corresponding		in each region. This may result in too many routes and corresponding
	tunnels. To address this concern, the I-PMSI routes from all PEs in		tunnels. To address this concern, the I-PMSI routes from all PEs in
	a AS/region can be aggregated into a single I-PMSI route originated		an AS/region can be aggregated into a single I-PMSI route originated
	from the RBRs, and traffic from all those individual I-PMSI tunnels		from the RBRs, 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.
	The MVPN Inter-AS I-PMSI A-D route can be better called as per-AS		The MVPN Inter-AS I-PMSI A-D route can be better called a "per-AS
	I-PMSI A-D route, to be compared against the (per-PE) Intra-AS I-PMSI		I-PMSI A-D route", to be compared against the (per-PE) Intra-AS
	A-D routes originated by each PE. In this document we will call it		I-PMSI A-D routes originated by each PE. In this document, we will
	as per-region I-PMSI A-D route, in case we want to apply the		call it a "per-region I-PMSI A-D route" in cases where we want to
	aggregation at regional level. The per-PE I-PMSI routes will not be		apply aggregation at the regional level. The per-PE I-PMSI routes
	propagated to other regions. If multiple RBRs are connected to a		will not be propagated to other regions. If multiple RBRs are
	region, then each will advertise such a route, with the same Region		connected to a region, then each will advertise such a route, with
	ID and Ethernet Tag ID (Section 3.1). Similar to the per-PE I-PMSI		the same Region ID and Ethernet Tag ID (Section 3.1). Similar to the
	A-D routes, RBRs/PEs in a downstream region will each select a best		per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each
	one from all those re-advertised by the upstream RBRs, hence will		select the best route from all those re-advertised by the upstream
	only receive traffic injected by one of them.		RBRs and hence will only receive traffic injected by one of them.
	MVPN does not aggregate S-PMSI routes from all PEs in an AS like it		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		do for I-PMSI routes, because the number of PEs that will advertise
	advertise S-PMSI routes for the same (s,g) or (*,g) is small. This		S-PMSI routes for the same (S,G) or (*,G) is small. This is also the
	is also the case for EVPN, i.e., there is no per-region S-PMSI		case for EVPNs, i.e., there are no per-region S-PMSI routes.
	routes.
	Notice that per-region I-PMSI routes can also be used to address		Notice that per-region I-PMSI routes can also be used to address
	backwards compatibility issue, as discussed in Section 5.3.		backward-compatibility issues, as discussed in Section 5.3.
	The Region ID in the per-region I-PMSI route's NLRI is encoded like		The Region ID in the per-region I-PMSI route's NLRI is encoded like
	an EC. For example, the Region ID can encode an AS number or area ID		an EC. For example, the Region ID can encode an AS number or area ID
	in the following EC format:		in the following EC format:
	o For a two-octet AS number, a Transitive Two-Octet AS-Specific EC		* For a two-octet AS number, a Transitive Two-Octet AS-specific EC
	of sub-type 0x09 (Source AS), with the Global Administrator sub-		of sub-type 0x09 (Source AS), with the Global Administrator sub-
	field set to the AS number and the Local Administrator sub-field		field set to the AS number and the Local Administrator sub-field
	set to 0.		set to 0.
	o For a four-octet AS number, a Transitive Four-Octet AS-Specific EC		* For a four-octet AS number, a Transitive Four-Octet AS-specific EC
	of sub-type 0x09 (Source AS), with the Global Administrator sub-		of sub-type 0x09 (Source AS), with the Global Administrator sub-
	field set to the AS number and the Local Administrator sub-field		field set to the AS number and the Local Administrator sub-field
	set to 0.		set to 0.
	o For an area ID, a Transitive IPv4-Address-Specific EC of any sub-		* For an area ID, a Transitive IPv4-Address-specific EC of any sub-
	type, with the Global Administrator sub-field set to the area ID		type, with the Global Administrator sub-field set to the area ID
	and the Local Administrator sub-field set to 0.		and the Local Administrator sub-field set to 0.
	Uses of other EC encoding MAY be allowed as long as it uniquely		The use of other EC encodings MAY be allowed as long as they uniquely
	identifies the region and the RBRs for the same region uses the same		identify the region and the RBRs for the same region use the same
	Region ID.		Region ID.
	6.3. Use of S-NH-EC		6.3. Use of S-NH-EC
	[RFC7524] specifies the use of S-NH-EC because it does not allow ABRs		[RFC7524] specifies the use of the S-NH-EC because it does not allow
	to change the BGP next hop when they re-advertise I/S-PMSI A-D routes		ABRs to change the BGP next hop when they re-advertise I/S-PMSI A-D
	to downstream areas. That is only to be consistent with the MVPN		routes to downstream areas. That behavior is only to be consistent
	Inter-AS I-PMSI A-D routes, whose next hop must not be changed when		with the MVPN Inter-AS I-PMSI A-D routes, whose next hop must not be
	they're re-advertised by the segmenting ABRs for reasons specific to		changed when they're re-advertised by the segmenting ABRs for reasons
	MVPN. For EVPN, it is perfectly fine to change the next hop when		specific to MVPNs. For EVPNs, it is perfectly fine to change the
	RBRs re-advertise the I/S-PMSI A-D routes, instead of relying on S-		next hop when RBRs re-advertise the I/S-PMSI A-D routes, instead of
	NH-EC. As a result, this document specifies that RBRs change the BGP		relying on the S-NH-EC. As a result, this document specifies that
	next hop when they re-advertise I/S-PMSI A-D routes and do not use S-		RBRs change the BGP next hop when they re-advertise I/S-PMSI A-D
	NH-EC. The advantage of this is that neither ingress nor egress PEs		routes and do not use the S-NH-EC. This provides the advantage that
	need to understand/use S-NH-EC, and a consistent procedure (based on		neither ingress PEs nor egress PEs need to understand/use the S-NH-
	BGP next hop) is used for both inter-as and inter-region		EC, and a consistent procedure (based on BGP next hops) is used for
	segmentation.		both inter-AS and inter-region segmentation.
	If a downstream PE/RBR needs to originate Leaf A-D routes, it		If a downstream PE/RBR needs to originate Leaf A-D routes, it
	constructs an IP-based Route Target Extended Community by placing the		constructs an IP-based Route Target Extended Community by placing the
	IP address carried in the Next Hop of the received I/S-PMSI A-D route		IP address carried in the Next Hop of the received I/S-PMSI A-D route
	in the Global Administrator field of the Community, with the Local		in the Global Administrator field of the extended community, with the
	Administrator field of this Community set to 0 and setting the		Local Administrator field of this extended community set to 0, and
	Extended Communities attribute of the Leaf A-D route to that		also setting the Extended Communities attribute of the Leaf A-D route
	Community.		to that extended community.
	Similar to [RFC7524], the upstream RBR MUST (auto-)configure a RT		Similar to [RFC7524], the upstream RBR MUST (auto-)configure an RT
	with the Global Administrator field set to the Next Hop in the re-		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 field		advertised I/S-PMSI A-D route and with the Local Administrator field
	set to 0. With this, the mechanisms specified in [RFC4684] for		set to 0. Using this technique, the mechanisms specified in
	constrained BGP route distribution can be used along with this		[RFC4684] for constrained BGP route distribution can be used along
	specification to ensure that only the needed PE/ABR will have to		with this specification to ensure that only the needed PE/ABR will
	process a said Leaf A-D route.		have to process a particular Leaf A-D route.
	6.4. Ingress PE's I-PMSI Leaf Tracking		6.4. Ingress PE's I-PMSI Leaf Tracking
	[RFC7524] specifies that when an ingress PE/ASBR (re-)advertises an		[RFC7524] specifies that when an ingress 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 for		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 does		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, and		not set the L flag in its originated I-PMSI A-D routes, and it
	determines the leaves based on the BGP next hops in its received		determines the leaves based on the BGP next hops in its received
	I-PMSI A-D routes, as specified in Section 5.2.		I-PMSI A-D routes, as specified in Section 5.2.
	The same backward compatibility issue exists, and the same solution		The same backward-compatibility issue exists, and the same solution
	as in the inter-as case applies, as specified in Section 5.3.		as that for the inter-AS case applies, as specified in Section 5.3.
	7. Multi-homing Support		7. Multihoming Support
	To support multi-homing with segmentation, ESI labels SHOULD be		To support multihoming with segmentation, Ethernet Segment Identifier
	allocated from "Domain-wide Common Block" (DCB)		(ESI) labels SHOULD be allocated from a "Domain-wide Common Block"
	[I-D.ietf-bess-mvpn-evpn-aggregation-label] for all tunnel types		(DCB) [RFC9573] for all tunnel types, including Ingress Replication
	including Ingress Replication. Via means outside the scope of this		tunnels [RFC7988]. Via means outside the scope of this document, PEs
	document, PEs know that ESI labels are from DCB and then existing		know that ESI labels are from a DCB, and existing multihoming
	multi-homing procedures work as is (whether a multi-homed Ethernet		procedures will then work "as is" (whether a multihomed Ethernet
	Segment spans across segmentation regions or not).		Segment spans segmentation regions or not).
	Not using DCB-allocated ESI labels is outside the scope of this		Not using DCB-allocated ESI labels is outside the scope of this
	document.		document.
	8. IANA Considerations		8. IANA Considerations
	IANA has temporarily assigned the following new EVPN route types in		IANA has assigned the following new EVPN route types in the "EVPN
	the EVPN Route Types registry:		Route Types" registry:
	o 9 - Per-Region I-PMSI A-D route		+=======+=============================+===========+
			| Value | Description | Reference |
			+=======+=============================+===========+
			| 9 | Per-Region I-PMSI A-D route | RFC 9572 |
			+-------+-----------------------------+-----------+
			| 10 | S-PMSI A-D route | RFC 9572 |
			+-------+-----------------------------+-----------+
			| 11 | Leaf A-D route | RFC 9572 |
			+-------+-----------------------------+-----------+
	o 10 - S-PMSI A-D route		Table 3: New Route Types
	o 11 - Leaf A-D route		IANA has assigned one flag bit from the "Multicast Flags Extended
			Community" registry created by [RFC9251]:
	This document requests IANA to assign one flag bit from the EVPN		+=====+======================+===========+===================+
	Multicast Flags Extended Community Flags registry to be created in		| Bit | Name | Reference | Change Controller |
	[draft-ietf-bess-evpn-igmp-mld-proxy]:		+=====+======================+===========+===================+
			| 8 | Segmentation Support | RFC 9572 | IETF |
			+-----+----------------------+-----------+-------------------+
	o Bit-S - Segmentation Procedure Support		Table 4: New Multicast Flag
	9. Security Considerations		9. Security Considerations
	The Selective Forwarding procedures via S-PMSI/Leaf A-D routes in		The procedures specified in this document for selective forwarding
	this document are based on the same procedures for MVPN [RFC6513]		via S-PMSI/Leaf A-D routes are based on the same procedures as those
	[RFC6514] and VPLS Multicast [RFC7117]. The tunnel segmentation		used for MVPNs [RFC6513] [RFC6514] and VPLS multicast [RFC7117]. The
	procedures in this document are based on the similar procedures for		procedures for tunnel segmentation as specified in this document are
	MVPN inter-AS [RFC6514] and inter-area [RFC7524] tunnel segmentation,		based on similar procedures used for MVPN inter-AS tunnel
	and procedures for VPLS Multicast [RFC7117] inter-as tunnel		segmentation [RFC6514] and inter-area tunnel segmentation [RFC7524],
	segmentation. When applied to EVPN, they do not introduce new		as well as procedures for VPLS multicast inter-AS tunnel segmentation
	security concerns besides what have been discussed in [RFC6513],		[RFC7117]. When applied to EVPNs, they do not introduce new security
	[RFC6514], [RFC7117], and [RFC7524]. They also do not introduce new		concerns beyond those discussed in [RFC6513], [RFC6514], [RFC7117],
	security concerns compared to [RFC7432].		and [RFC7524]. They also do not introduce new security concerns
			compared to [RFC7432].
	10. Acknowledgements
	The authors thank Eric Rosen, John Drake, and Ron Bonica for their
	comments and suggestions.
	11. Contributors
	The following also contributed to this document through their earlier
	work in EVPN selective multicast.
	Junlin Zhang
	Huawei Technologies
	Huawei Bld., No.156 Beiqing Rd.
	Beijing 100095
	China
	Email: jackey.zhang@huawei.com
	Zhenbin Li
	Huawei Technologies
	Huawei Bld., No.156 Beiqing Rd.
	Beijing 100095
	China
	Email: lizhenbin@huawei.com
	12. References
	12.1. Normative References
	[I-D.ietf-bess-evpn-igmp-mld-proxy]		10. References
	Sajassi, A., Thoria, S., Mishra, M., Drake, J., and W.
	Lin, "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-
	igmp-mld-proxy-14 (work in progress), October 2021.
	[I-D.ietf-bess-mvpn-evpn-aggregation-label]		10.1. Normative References
	Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands,
	"MVPN/EVPN Tunnel Aggregation with Common Labels", draft-
	ietf-bess-mvpn-evpn-aggregation-label-06 (work in
	progress), April 2021.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/		[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
	BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February		BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
	2012, <https://www.rfc-editor.org/info/rfc6513>.		2012, <https://www.rfc-editor.org/info/rfc6513>.
	skipping to change at page 19, line 36 ¶		skipping to change at line 889 ¶
	"Explicit Tracking with Wildcard Routes in Multicast VPN",		"Explicit Tracking with Wildcard Routes in Multicast VPN",
	RFC 8534, DOI 10.17487/RFC8534, February 2019,		RFC 8534, DOI 10.17487/RFC8534, February 2019,
	<https://www.rfc-editor.org/info/rfc8534>.		<https://www.rfc-editor.org/info/rfc8534>.
	[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,		[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
	J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet		J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
	VPN Designated Forwarder Election Extensibility",		VPN Designated Forwarder Election Extensibility",
	RFC 8584, DOI 10.17487/RFC8584, April 2019,		RFC 8584, DOI 10.17487/RFC8584, April 2019,
	<https://www.rfc-editor.org/info/rfc8584>.		<https://www.rfc-editor.org/info/rfc8584>.
	12.2. Informative References		[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
			and W. Lin, "Internet Group Management Protocol (IGMP) and
			Multicast Listener Discovery (MLD) Proxies for Ethernet
			VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
			<https://www.rfc-editor.org/info/rfc9251>.
	[I-D.ietf-bess-evpn-prefix-advertisement]		[RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands,
	Rabadan, J., Henderickx, W., Drake, J. E., Lin, W., and A.		"MVPN/EVPN Tunnel Aggregation with Common Labels",
	Sajassi, "IP Prefix Advertisement in Ethernet VPN (EVPN)",		RFC 9573, DOI 10.17487/RFC9573, April 2024,
	draft-ietf-bess-evpn-prefix-advertisement-11 (work in		<https://www.rfc-editor.org/info/rfc9573>.
	progress), May 2018.
			10.2. Informative References
	[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,		[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
	R., Patel, K., and J. Guichard, "Constrained Route		R., Patel, K., and J. Guichard, "Constrained Route
	Distribution for Border Gateway Protocol/MultiProtocol		Distribution for Border Gateway Protocol/MultiProtocol
	Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual		Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
	Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,		Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
	November 2006, <https://www.rfc-editor.org/info/rfc4684>.		November 2006, <https://www.rfc-editor.org/info/rfc4684>.
	[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.		[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
	Yasukawa, Ed., "Extensions to Resource Reservation		Yasukawa, Ed., "Extensions to Resource Reservation
	skipping to change at page 20, line 29 ¶		skipping to change at line 933 ¶
	Replication Tunnels in Multicast VPN", RFC 7988,		Replication Tunnels in Multicast VPN", RFC 7988,
	DOI 10.17487/RFC7988, October 2016,		DOI 10.17487/RFC7988, October 2016,
	<https://www.rfc-editor.org/info/rfc7988>.		<https://www.rfc-editor.org/info/rfc7988>.
	[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,		[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Przygienda, T., and S. Aldrin, "Multicast Using Bit Index		Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
	Explicit Replication (BIER)", RFC 8279,		Explicit Replication (BIER)", RFC 8279,
	DOI 10.17487/RFC8279, November 2017,		DOI 10.17487/RFC8279, November 2017,
	<https://www.rfc-editor.org/info/rfc8279>.		<https://www.rfc-editor.org/info/rfc8279>.
			[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
			A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
			(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
			<https://www.rfc-editor.org/info/rfc9136>.
			Acknowledgements
			The authors thank Eric Rosen, John Drake, and Ron Bonica for their
			comments and suggestions.
			Contributors
			The following people also contributed to this document through their
			earlier work in EVPN selective multicast.
			Junlin Zhang
			Huawei Technologies
			Huawei Bld., No. 156 Beiqing Rd.
			Beijing
			100095
			China
			Email: jackey.zhang@huawei.com
			Zhenbin Li
			Huawei Technologies
			Huawei Bld., No. 156 Beiqing Rd.
			Beijing
			100095
			China
			Email: lizhenbin@huawei.com
	Authors' Addresses		Authors' Addresses
	Zhaohui Zhang		Zhaohui Zhang
	Juniper Networks		Juniper Networks
			Email: zzhang@juniper.net
	EMail: zzhang@juniper.net
	Wen Lin		Wen Lin
	Juniper Networks		Juniper Networks
			Email: wlin@juniper.net
	EMail: wlin@juniper.net
	Jorge Rabadan		Jorge Rabadan
	Nokia		Nokia
			Email: jorge.rabadan@nokia.com
	EMail: jorge.rabadan@nokia.com
	Keyur Patel		Keyur Patel
	Arrcus		Arrcus
			Email: keyur@arrcus.com
	EMail: keyur@arrcus.com
	Ali Sajassi		Ali Sajassi
	Cisco Systems		Cisco Systems
			Email: sajassi@cisco.com
	EMail: sajassi@cisco.com
End of changes. 139 change blocks.
	506 lines changed or deleted		552 lines changed or added
This html diff was produced by rfcdiff 1.48.