Diff: rfc9624.original

	rfc9624.original	rfc9624.txt


	BIER Z. Zhang	Internet Engineering Task Force (IETF) Z. Zhang
	Internet-Draft A. Przygienda	Request for Comments: 9624 T. Przygienda
	Intended status: Standards Track Juniper Networks	Category: Standards Track Juniper Networks
	Expires: 5 July 2024 A. Sajassi	ISSN: 2070-1721 A. Sajassi
	Cisco Systems	Cisco Systems
	J. Rabadan	J. Rabadan
	Nokia	Nokia

	2 January 2024	August 2024


	EVPN BUM Using BIER	EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using Bit Index
	draft-ietf-bier-evpn-14	Explicit Replication (BIER)

	Abstract	Abstract

	This document specifies protocols and procedures for forwarding	This document specifies protocols and procedures for forwarding

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

	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 5 July 2024.	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/rfc9624.

	Copyright Notice	Copyright Notice

	Copyright (c) 2024 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 (https://trustee.ietf.org/	Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.	(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights	publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components	carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as	to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are	include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.	Trust Legal Provisions and are provided without warranty as described
		in the Revised BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2	1. Introduction
	1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3	1.1. Terminology
	2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4	1.2. Requirements Language
	2.1. IP-Based Tunnel and BIER PHP . . . . . . . . . . . . . . 6	2. Use of the PMSI Tunnel Attribute
	2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 6	2.1. IP-Based Tunnel and BIER PHP
	2.2.1. Using IMET/SMET routes . . . . . . . . . . . . . . . 6	2.2. Explicit Tracking
	2.2.2. Using S-PMSI/Leaf A-D Routes . . . . . . . . . . . . 7	2.2.1. Using IMET/SMET Routes
	2.3. MPLS Label in PTA . . . . . . . . . . . . . . . . . . . . 8	2.2.2. Using S-PMSI/Leaf A-D Routes
	3. Multihoming Split Horizon . . . . . . . . . . . . . . . . . . 8	2.3. MPLS Label in the PTA
	4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 9	3. Multihoming Split Horizon
	4.1. Encapsulation and Transmission . . . . . . . . . . . . . 9	4. Data Plane
	4.1.1. At a BFIR that is an Ingress PE . . . . . . . . . . . 9	4.1. Encapsulation and Transmission
	4.1.2. At a BFIR that is a P-tunnel Segmentation Point . . . 11	4.1.1. At a BFIR That Is an Ingress PE
	4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 11	4.1.2. At a BFIR That Is a P-Tunnel Segmentation Point
	4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 12	4.2. Disposition
	4.2.2. At a BFER that is a P-tunnel Segmentation Point . . . 12	4.2.1. At a BFER That Is an Egress PE
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12	4.2.2. At a BFER That Is a P-Tunnel Segmentation Point
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12	5. IANA Considerations
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12	6. Security Considerations
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12	7. References
	8.1. Normative References . . . . . . . . . . . . . . . . . . 12	7.1. Normative References
	8.2. Informative References . . . . . . . . . . . . . . . . . 14	7.2. Informative References
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15	Acknowledgements
		Authors' Addresses

	1. Introduction	1. Introduction

	[RFC7432] and [RFC8365] specify the protocols and procedures for	[RFC7432] and [RFC8365] specify the protocols and procedures for

	Ethernet VPNs (EVPNs). For broadcast, unknown unicast and multicast	Ethernet VPNs (EVPNs). For Broadcast, Unknown Unicast, or Multicast
	(BUM) traffic, provider/underlay tunnels are used to carry the BUM	(BUM) traffic, provider/underlay tunnels are used to carry the BUM
	traffic. Several kinds of tunnel technologies can be used as	traffic. Several kinds of tunnel technologies can be used as
	specified in [RFC7432] and [RFC8365], and this document specifies the	specified in [RFC7432] and [RFC8365], and this document specifies the
	protocols and procedures to use Bit Index Explicit Replication (BIER)	protocols and procedures to use Bit Index Explicit Replication (BIER)
	[RFC8279] as provider tunnels for EVPN BUM traffic.	[RFC8279] as provider tunnels for EVPN BUM traffic.

	BIER is an architecture that provides optimal multicast forwarding	BIER is an architecture that provides optimal multicast forwarding

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

	The EVPN BUM procedures specified in [RFC7432] and extended in	The EVPN BUM procedures specified in [RFC7432] and extended in

	[I-D.ietf-bess-evpn-bum-procedure-updates], [RFC9251], and	[RFC9572], [RFC9251], and [CMCAST-ENHANCEMENTS] are much aligned with
	[I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] are much aligned with	Multicast VPN (MVPN) procedures [RFC6514], and an EVPN Broadcast
	Multicast VPN (MVPN) procedures [RFC6514] and an EVPN Broadcast	Domain (BD) corresponds to a VPN in MVPN. As such, this document is
	Domain corresponds to a VPN in MVPN. As such, this document is also	also very much aligned with [RFC8556], which specifies MVPN with
	very much aligned with [RFC8556] that specifies MVPN with BIER. For	BIER. For terseness, some background, terms, and concepts are not
	terseness, some background, terms and concepts are not repeated here.	repeated here. Additionally, some text is borrowed verbatim from
	Additionally, some text is borrowed verbatim from [RFC8556].	[RFC8556].


	1.1. Terminologies	1.1. Terminology


	* ES: Ethernet Segment.	ES: Ethernet Segment


	* ESI: Ethernet Segment Identifier.	ESI: Ethernet Segment Identifier


	* BFR: Bit-Forwarding Router.	BFR: Bit-Forwarding Router


	* BFIR: Bit-Forwarding Ingress Router.	BFIR: Bit-Forwarding Ingress Router


	* BFER: Bit-Forwarding Egress Router.	BFER: Bit-Forwarding Egress Router


	* BFR-Prefix: An IP address that uniquely identifies a BFR and is	BFR-Prefix: An IP address that uniquely identifies a BFR and is
	routable in a BIER domain.	routable in a BIER domain.


	* C-S: A multicast source address identifying a multicast source	C-S: A multicast source address identifying a multicast source
	located at an EVPN customer site. "C-" stands for "Customer-".	located at an EVPN customer site. "C-" stands for "Customer-".


	* C-G: A multicast group address used by an EVPN customer.	C-G: A multicast group address used by an EVPN customer.


	* C-flow: A customer multicast flow. Each C-flow is identified by	C-flow: A customer multicast flow. Each C-flow is identified by the
	the ordered pair (source address, group address), where each	ordered pair (source address, group address), where each address
	address is in the customer's address space. The identifier of a	is in the customer's address space. The identifier of a
	particular C-flow is usually written as (C-S, C-G). Sets of	particular C-flow is usually written as (C-S, C-G). Sets of
	C-flows can be denoted by the use of the "C-*" wildcard (see	C-flows can be denoted by the use of the "C-*" wildcard (see
	[RFC6625]), e.g., (C-*, C-G).	[RFC6625]), e.g., (C-*, C-G).


	* P-tunnel. A multicast tunnel through the network of one or more	P-tunnel: A multicast tunnel through the network of one or more
	service providers used to transport C-flows. "P-" stands for	service providers used to transport C-flows. "P-" stands for
	"Provider-".	"Provider-".


	* IMET Route: Inclusive Multicast Ethernet Tag Auto-Discovery route.	IMET A-D Route: Inclusive Multicast Ethernet Tag Auto-Discovery
	Carried in BGP Update messages, these routes are used to advertise	route. Carried in BGP Update messages, these routes are used to
	the "default" P-tunnel for a particular broadcast domain.	advertise the "default" P-tunnel for a particular BD.


	* SMET Route: Selective Multicast Ethernet Tag Auto-Discovery route.	SMET A-D Route: Selective Multicast Ethernet Tag Auto-Discovery
	Carried in BGP Update messages, these routes are used to advertise	route. Carried in BGP Update messages, these routes are used to
	the C-flows that the advertising PE is interested in.	advertise the C-flows that the advertising Provider Edge (PE) is
		interested in.


	* PMSI [RFC6513]: Provider Multicast Service Interface - a	PMSI: Provider Multicast Service Interface [RFC6513]. A conceptual
	conceptual interface for a PE to send customer multicast traffic	interface used by a PE to send customer multicast traffic to all
	to all or some PEs in the same VPN.	or some PEs in the same VPN.


	* I-PMSI: Inclusive PMSI - to all PEs in the same VPN.	I-PMSI: Inclusive PMSI. For all PEs in the same VPN.


	* S-PMSI: Selective PMSI - to some of the PEs in the same VPN.	S-PMSI: Selective PMSI. For some of the PEs in the same VPN.


	* I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route used to	I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route used to
	advertise the tunnels that instantiate an I-PMSI.	advertise the tunnels that instantiate an I-PMSI.


	* S-PMSI A-D route: Selective PMSI Auto-Discovery route used to	S-PMSI A-D Route: Selective PMSI Auto-Discovery route used to
	advertise that particular C-flows are bound to (i.e., are	advertise that particular C-flows are bound to (i.e., are
	traveling through) particular P-tunnels.	traveling through) particular P-tunnels.


	* PMSI Tunnel attribute (PTA): A BGP attribute used to identify a	PTA: PMSI Tunnel Attribute. A BGP attribute used to identify a
	particular P-tunnel.	particular P-tunnel.


	* VXLAN [RFC7348]: Virtual eXtensible Local Area Network.	VXLAN: Virtual eXtensible Local Area Network [RFC7348]


	* NVGRE [RFC7637]: Network Virtualization using Generic Routing	NVGRE: Network Virtualization Using Generic Routing Encapsulation
	Encapsulation.	[RFC7637]


	* GENEVE [RFC8926]: Generic Network Virtualization Encapsulation.	GENEVE: Generic Network Virtualization Encapsulation [RFC8926]


	* VNI: VXLAN Network Identifier.	VNI: VXLAN Network Identifier


	* VSID: Virtual Subnet IDentifier.	VSID: Virtual Subnet Identifier


	* RSVP-P2MP [RFC4875]: Resource ReserVation Protocol for Point-to-	RSVP-TE P2MP: Resource Reservation Protocol for Point-to-Multipoint
	Multipoint TE Label Switched Paths.	TE Label Switched Paths (LSPs) [RFC4875]


	* mLDP-P2MP [RFC6388]: Label Distribution Protocol Extensions for	mLDP P2MP: Multipoint Label Distribution Protocol extensions for
	Point-to-Multipoint and Multipoint-to-Multipoint Label Switched	Point-to-Multipoint LSPs [RFC6388]
	Paths.
		1.2. 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.

	2. Use of the PMSI Tunnel Attribute	2. Use of the PMSI Tunnel Attribute

	[RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET)	[RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET)
	routes carry a PMSI Tunnel Attribute (PTA) to identify the particular	routes carry a PMSI Tunnel Attribute (PTA) to identify the particular

	P-tunnel to which one or more BUM flows are being assigned, the same	P-tunnel to which one or more BUM flows are being assigned, which is
	as specified in [RFC6514] for MVPN. [RFC8556] specifies the encoding	the same as specified in [RFC6514] for MVPN. [RFC8556] specifies the
	of PTA for the use of BIER with MVPN. Much of that specification is	encoding of the PTA for the use of BIER with MVPN. Much of that
	reused for the use of BIER with EVPN and much of the text below is	specification is reused for the use of BIER with EVPN, and much of
	borrowed verbatim from [RFC8556].	the text below is borrowed verbatim from [RFC8556].


	The PMSI Tunnel Attribute (PTA) contains the following fields:	The PTA contains the following fields:


	* "Tunnel Type". The same codepoint 0x0B that IANA has assigned for	* Tunnel Type. The same codepoint 0x0B that IANA has assigned for
	BIER for MVPN [RFC8556] is used for EVPN as well.	BIER for MVPN [RFC8556] is used for EVPN as well.


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


	1 The first subfield is a single octet, containing the sub-	1. The first subfield is a single octet, containing a BIER sub-
	domain-id of the sub-domain to which the BFIR will assign the	domain-id (see [RFC8279]). This indicates that packets sent
	packets that it transmits on the PMSI identified by the Network	on the PMSI will be sent on the specified BIER sub-domain.
	Layer Reachability Information (NLRI) of the IMET, S-PMSI A-D,	How that sub-domain is chosen is outside the scope of this
	or per-region I-PMSI A-D route that contains this PTA. How	document.
	that sub-domain is chosen is outside the scope of this
	document.


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


	3 The third subfield is the BFR-Prefix (see [RFC8279]) of the	3. The third subfield is the BFR-Prefix (see [RFC8279]) of the
	originator of the route that is carrying this PTA. This will	router (a BFIR) that is constructing the PTA. The BFR-Prefix
	either be a /32 IPv4 address or a /128 IPv6 address. Whether	will either be a /32 IPv4 address or a /128 IPv6 address.
	the address is IPv4 or IPv6 can be inferred from the total	Whether the address is IPv4 or IPv6 can be inferred from the
	length of the PMSI Tunnel attribute.	total length of the PTA.


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


	* "MPLS label". For EVPN-MPLS [RFC7432], this field contains an	* MPLS Label. For EVPN-MPLS [RFC7432], this field contains an
	upstream-assigned MPLS label. It is assigned by the BFIR.	upstream-assigned MPLS label. It is assigned by the BFIR.
	Constraints on how the originating router selects this label are	Constraints on how the originating router selects this label are
	discussed in Section 2.3. For EVPN-VXLAN/NVGRE/GENEVE [RFC8365]	discussed in Section 2.3. For EVPN-VXLAN/NVGRE/GENEVE [RFC8365]
	[RFC7348] [RFC7637] [RFC8926], this field is a 24-bit VNI/VSID of	[RFC7348] [RFC7637] [RFC8926], this field is a 24-bit VNI/VSID of
	global significance.	global significance.


	* "Flags". When the tunnel type is BIER, two of the flags in the	* Flags. When the tunnel type is BIER, two of the flags in the PTA
	PTA Flags field are meaningful. Details about the use of these	Flags field are meaningful. Details about the use of these flags
	flags can be found in Section 2.2.	can be found in Section 2.2.


	- "Leaf Info Required per Flow (LIR-pF)" [RFC8534]	- Leaf Info Required per Flow (LIR-pF) [RFC8534]


	- "Leaf Info Required Bit (LIR)"	- Leaf Info Required (LIR)

	Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI	Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI
	A-D, or per-region I-PMSI A-D route, the route MUST NOT be	A-D, or per-region I-PMSI A-D route, the route MUST NOT be
	distributed beyond the boundaries of a BIER domain. That is, any	distributed beyond the boundaries of a BIER domain. That is, any
	routers that receive the route must be in the same BIER domain as the	routers that receive the route must be in the same BIER domain as the
	originator of the route. If the originator is in more than one BIER	originator of the route. If the originator is in more than one BIER
	domain, the route must be distributed only within the BIER domain in	domain, the route must be distributed only within the BIER domain in
	which the BFR-Prefix in the PTA uniquely identifies the originator.	which the BFR-Prefix in the PTA uniquely identifies the originator.
	As with all MVPN routes, the distribution of these routes is	As with all MVPN routes, the distribution of these routes is
	controlled by the provisioning of Route Targets.	controlled by the provisioning of Route Targets.

	2.1. IP-Based Tunnel and BIER PHP	2.1. IP-Based Tunnel and BIER PHP


	When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP	When VXLAN/NVGRE/GENEVE is used for EVPN, by default, the outer IP
	header (and UDP header in the case of VXLAN/GENEVE) is not included	header (and UDP header in the case of VXLAN/GENEVE) is not included

	in the BIER payload, except when it is known apriori that BIER	in the BIER payload, except when it is known a priori that BIER
	Penultimate Hop Popping (PHP) [I-D.ietf-bier-php] is used in the BIER	Penultimate Hop Popping (PHP) [BIER-PHP] is used in the BIER domain
	domain and the encapsulation (after the BIER header is popped)	and the encapsulation (after the BIER header is popped) between the
	between the BIER Penultimate Hop and the egress PE does not have a	BIER Penultimate Hop and the egress PE does not have a way to
	way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case	indicate the next header is VXLAN/NVGRE/GENEVE. In that case, the
	the full VXLAN/NVGRE/GENEVE encapsulation MUST be used. In the outer	full VXLAN/NVGRE/GENEVE encapsulation MUST be used. In the outer IP
	IP header, a well-known IP multicast address (to be assigned by IANA)	header, a well-known IP multicast address (224.0.0.122 in the case of
	is used as the destination address and the egress PEs MUST be set up	IPv4 or FF02:0:0:0:0:0:0:14 in the case of IPv6) is used as the
	to receive and process packets addressed to the address. The address	destination address, and the egress PEs MUST be set up to receive and
	is used for all Broadcast Domains (BDs) and the inner VXLAN/NVGRE/	process packets addressed to the destination address. The address is
	GENEVE header will be used to identify BDs.	used for all BDs, and the inner VXLAN/NVGRE/GENEVE header will be
		used to identify BDs.

	2.2. Explicit Tracking	2.2. Explicit Tracking

	When using BIER to transport an EVPN BUM data packet through a BIER	When using BIER to transport an EVPN BUM data packet through a BIER
	domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR	domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR
	must determine the set of BFERs to which the packet needs to be	must determine the set of BFERs to which the packet needs to be

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


	2.2.1. Using IMET/SMET routes	2.2.1. Using IMET/SMET Routes

	Both IMET and SMET routes provide explicit tracking functionality.	Both IMET and SMET routes provide explicit tracking functionality.

	For an inclusive PMSI, the set of BFERs (egress PEs) includes the	For an inclusive PMSI, the set of BFERs (egress PEs) includes the

	originators of all IMET routes for a broadcast domain. For a	originators of all IMET routes for a BD. For a selective PMSI, the
	selective PMSI, the set of BFERs (egress PEs) includes the	set of BFERs (egress PEs) includes the originators of corresponding
	originators of corresponding SMET routes.	SMET routes.

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


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

	2.2.2. Using S-PMSI/Leaf A-D Routes	2.2.2. Using S-PMSI/Leaf A-D Routes

	There are two cases where S-PMSI/Leaf A-D routes are used as	There are two cases where S-PMSI/Leaf A-D routes are used as
	discussed in the following two sections.	discussed in the following two sections.

	2.2.2.1. Selective Forwarding Only for Some Flows	2.2.2.1. Selective Forwarding Only for Some Flows


	With the SMET procedure, a PE advertises an SMET route for each (C-S,	With the SMET procedure, a PE advertises a SMET route for each (C-S,
	C-G) or (C-*, C-G) state that it learns on its Attachment Circuits	C-G) or (C-*, C-G) state that it learns on its Attachment Circuits

	(ACs), and each SMET route is tracked by every PE in the same	(ACs), and each SMET route is tracked by every PE in the same BD. It
	broadcast domain. It may be desired that SMET routes are not used,	may be desired that SMET routes are not used in order to reduce the
	in order to reduce the burden of explicit tracking.	burden of explicit tracking.

	In this case, most multicast traffic will follow the I-PMSI	In this case, most multicast traffic will follow the I-PMSI

	(advertised via IMET route) and only some flows follow S-PMSIs. To	(advertised via the IMET route) and only some flows will follow
	achieve that, S-PMSI/Leaf A-D routes can be used, as specified in	S-PMSIs. To achieve that, S-PMSI/Leaf A-D routes can be used, as
	[I-D.ietf-bess-evpn-bum-procedure-updates].	specified in [RFC9572].


	The rules specified in Section 2.2.1 and Section 2.2.2 of [RFC8556]	The rules specified in Sections 2.2.1 and 2.2.2 of [RFC8556] apply.
	apply.

	2.2.2.2. Tunnel Segmentation	2.2.2.2. Tunnel Segmentation

	Another case where S-PMSI/Leaf A-D routes are necessary is tunnel	Another case where S-PMSI/Leaf A-D routes are necessary is tunnel

	segmentation, which is also specified in	segmentation, which is also specified in [RFC9572] and further
	[I-D.ietf-bess-evpn-bum-procedure-updates], and further clarified in	clarified in [CMCAST-ENHANCEMENTS] for segmentation with SMET routes.
	[I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] for segmentation with	This is only applicable to EVPN-MPLS.
	SMET routes. This is only applicable to EVPN-MPLS.

	The rules specified in Section 2.2.1 of [RFC8556] apply.	The rules specified in Section 2.2.1 of [RFC8556] apply.
	Section 2.2.2 of [RFC8556] does not apply, because like in MVPN, the	Section 2.2.2 of [RFC8556] does not apply, because like in MVPN, the
	LIR-pF flag cannot be used with segmentation.	LIR-pF flag cannot be used with segmentation.

	2.2.2.3. Applicability of Additional MVPN Specifications	2.2.2.3. Applicability of Additional MVPN Specifications


	As with the MVPN case, Section "3. Use of the PMSI Tunnel Attribute	As with the MVPN case, "Use of the PMSI Tunnel Attribute in Leaf A-D
	in Leaf A-D routes" of [RFC8556] apply.	Routes" (Section 3 of [RFC8556]) applies.


	Notice that, [RFC8556] refers to procedures specified in [RFC6625]	Notice that [RFC8556] refers to procedures specified in [RFC6625] and
	and [RFC8534]. Those two documents were specified for MVPN but apply	[RFC8534]. Those two documents were specified for MVPN but apply to
	to IP multicast payload in EVPN as well.	IP multicast payload in EVPN as well.


	2.3. MPLS Label in PTA	2.3. MPLS Label in the PTA


	Rules in section 2.1 of [RFC8556] apply, EXCEPT the following three	Rules in Section 2.1 of [RFC8556] apply, EXCEPT the following three
	bullets (they do NOT apply to EVPN) in that section:	bullets (they do NOT apply to EVPN) in that section:

	* If the two routes do not have the same Address Family Identifier	* If the two routes do not have the same Address Family Identifier
	(AFI) value, then their respective PTAs MUST contain different	(AFI) value, then their respective PTAs MUST contain different
	MPLS label values. This ensures that when an egress PE receives a	MPLS label values. This ensures that when an egress PE receives a
	data packet with the given label, the egress PE can infer from the	data packet with the given label, the egress PE can infer from the
	label whether the payload is an IPv4 packet or an IPv6 packet.	label whether the payload is an IPv4 packet or an IPv6 packet.


	* If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900])	* If the BFIR is an ingress PE supporting MVPN extranet [RFC7900]
	functionality, and if the two routes originate from different VRFs	functionality, and if the two routes originate from different VRFs
	on this ingress PE, then the respective PTAs of the two routes	on this ingress PE, then the respective PTAs of the two routes
	MUST contain different MPLS label values.	MUST contain different MPLS label values.

	* If the BFIR is an ingress PE supporting the "Extranet Separation"	* If the BFIR is an ingress PE supporting the "Extranet Separation"
	feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if	feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if
	one of the routes carries the "Extranet Separation" extended	one of the routes carries the "Extranet Separation" extended
	community but the other does not, then the respective PTAs of the	community but the other does not, then the respective PTAs of the
	two routes MUST contain different MPLS label values.	two routes MUST contain different MPLS label values.

	3. Multihoming Split Horizon	3. Multihoming Split Horizon

	For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify	For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify
	the ES from which a BUM packet originates. A PE receiving that	the ES from which a BUM packet originates. A PE receiving that
	packet from the core side will not forward it to the same ES. The	packet from the core side will not forward it to the same ES. The
	procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP	procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP

	P2MP tunnels, using downstream- and upstream-assigned ESI labels	P2MP tunnels, using downstream- and upstream-assigned ESI labels,
	respectively. For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local	respectively. For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local

	bias procedures, with which a PE receiving a BUM packet from the core	bias procedures, where a PE receiving a BUM packet from the core side
	side knows from encapsulation the ingress PE so it does not forward	knows the ingress PE due to encapsulation; therefore, the PE does not
	the packet to any multihoming ESes that the ingress PE is on. This	forward the packet to any multihoming ESes that the ingress PE is on.
	is because the ingress PE already forwarded the packet to those ESes	This is because the ingress PE already forwarded the packet to those
	regardless of whether the ingress PE is a Designated Forwarder for	ESes, regardless of whether the ingress PE is a Designated Forwarder
	those ESes.	for those ESes.

	With BIER, the local bias procedure still applies for EVPN-	With BIER, the local bias procedure still applies for EVPN-

	VXLAN/NVGRE/GENEVE as the BFIR-id in the BIER header identifies the	VXLAN/NVGRE/GENEVE, as the BFIR-id in the BIER header identifies the
	ingress PE. For EVPN-MPLS, ESI label procedures also still apply	ingress PE. For EVPN-MPLS, ESI label procedures also still apply,
	though two upstream-assigned labels will be used (one for identifying	though two upstream-assigned labels will be used (one for identifying

	the broadcast domain and one for identifying the ES) - the same as in	the BD and one for identifying the ES) -- the same as in the case of
	the case of using a single P2MP tunnel for multiple broadcast	using a single P2MP tunnel for multiple BDs. The BFIR-id in the BIER
	domains. The BFIR-id in the BIER header identifies the ingress PE	header identifies the ingress PE that assigned those two labels.
	that assigned those two labels.

	4. Data Plane	4. Data Plane

	Like MVPN, the EVPN application plays the role of the "multicast flow	Like MVPN, the EVPN application plays the role of the "multicast flow
	overlay" as described in [RFC8279].	overlay" as described in [RFC8279].

	4.1. Encapsulation and Transmission	4.1. Encapsulation and Transmission

	A BFIR could be either an ingress PE or a P-tunnel segmentation	A BFIR could be either an ingress PE or a P-tunnel segmentation
	point. The procedures are slightly different as described below.	point. The procedures are slightly different as described below.


	4.1.1. At a BFIR that is an Ingress PE	4.1.1. At a BFIR That Is an Ingress PE

	To transmit a BUM data packet, an ingress PE first determines the	To transmit a BUM data packet, an ingress PE first determines the
	route matched for transmission and routes for tracking leaves	route matched for transmission and routes for tracking leaves
	according to the following rules.	according to the following rules.


	1. If selective forwarding is not used, or it is not an IP Multicast	1. If selective forwarding is not used or is not an IP multicast
	packet after the Ethernet header, the IMET route originated for	packet after the Ethernet header, the IMET route originated for
	the BD by the ingress PE is the route matched for transmission.	the BD by the ingress PE is the route matched for transmission.

	Leaf tracking routes are all other received IMET routes for the	Leaf-tracking routes are all other received IMET routes for the
	BD.	BD.


	2. Otherwise, if selective forwarding is used for all IP Multicast	2. Otherwise, if selective forwarding is used for all IP multicast
	traffic based on SMET routes, the IMET route originated for the	traffic based on SMET routes, the IMET route originated for the
	BD by the ingress PE is the route matched for transmission.	BD by the ingress PE is the route matched for transmission.

	Received SMET routes for the BD whose source and destination	Received SMET routes for the BD, whose source and destination
	address fields match the packet's source and destination IP	address fields match the packet's source and destination IP

	address are leaf tracking routes.	address, are leaf-tracking routes.

	3. Otherwise, the route matched for transmission is the S-PMSI A-D	3. Otherwise, the route matched for transmission is the S-PMSI A-D
	route originated by the ingress PE for the BD, whose source and	route originated by the ingress PE for the BD, whose source and
	destination address fields match the packet's source and	destination address fields match the packet's source and

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


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


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

	Note that in both cases, SMET routes may be used in lieu of Leaf	Note that in both cases, SMET routes may be used in lieu of Leaf
	A-D routes, as a PE may omit the Leaf A-D route in response to an	A-D routes, as a PE may omit the Leaf A-D route in response to an

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

	originated [I-D.ietf-bess-evpn-bum-procedure-updates]. In	originated [RFC9572]. In particular, in the second case above,
	particular, in the second case above, even though the SMET route	even though the SMET route does not have a PTA attached, it is
	does not have a PTA attached, it is still considered a Leaf A-D	still considered a Leaf A-D route in response to a wildcard
	route in response to a wildcard S-PMSI A-D route with the LIR-pF	S-PMSI A-D route with the LIR-pF bit set.
	bit set.


	4. Otherwise, the route matched for transmission and leaf tracking	4. Otherwise, the route matched for transmission and leaf-tracking
	routes are determined as in rule 1.	routes are determined as in rule 1.

	If no route is matched for transmission, the packet is not forwarded	If no route is matched for transmission, the packet is not forwarded
	onto a P-tunnel. If the tunnel that the ingress determines to use	onto a P-tunnel. If the tunnel that the ingress determines to use
	based on the route matched for transmission (and considering	based on the route matched for transmission (and considering
	interworking with PEs that do not support certain tunnel types per	interworking with PEs that do not support certain tunnel types per

	procedures in [RFC9251]) requires leaf tracking (e.g. Ingress	procedures in [RFC9251]) requires leaf tracking (e.g., Ingress
	Replication, RSVP-TE P2MP tunnel, or BIER) but there are no leaf	Replication, RSVP-TE P2MP tunnel, or BIER) but there are no leaf-
	tracking routes, the packet will not be forwarded onto a P-tunnel	tracking routes, the packet will not be forwarded onto a P-tunnel
	either.	either.

	The following text assumes that BIER is the determined tunnel type.	The following text assumes that BIER is the determined tunnel type.
	The ingress PE pushes an upstream-assigned ESI label per [RFC7432] if	The ingress PE pushes an upstream-assigned ESI label per [RFC7432] if
	the following conditions are all met:	the following conditions are all met:

	* The packet is received on a multihomed ES.	* The packet is received on a multihomed ES.


	* It's EVPN-MPLS.	* It is EVPN-MPLS.


	* ESI label procedure is used for split-horizon.	* The ESI label procedure is used for split horizon.

	The MPLS label from the PTA of the route matched for transmission is	The MPLS label from the PTA of the route matched for transmission is
	then pushed onto the packet's label stack for EVPN-MPLS. For EVPN-	then pushed onto the packet's label stack for EVPN-MPLS. For EVPN-
	VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to the	VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to the

	packet with the VNI/VSID set to the value in the PTA's label field,	packet with the VNI/VSID set to the value in the PTA's Label field,
	and then an IP/UDP header is prepended if needed (e.g. for PHP	and then an IP/UDP header is prepended if needed (e.g., for PHP
	purpose).	purposes).


	Then the packet is encapsulated in a BIER header and forwarded,	Then, the packet is encapsulated in a BIER header and forwarded
	according to the procedures of [RFC8279] and [RFC8296]. See	according to the procedures of [RFC8279] and [RFC8296].
	especially Section 4, "Imposing and Processing the BIER	Specifically, see "Imposing and Processing the BIER Encapsulation"
	Encapsulation", of [RFC8296]. The "Proto" field in the BIER header	(Section 3 of [RFC8296]). The Proto field in the BIER header is set
	is set to 2 in the case of EVPN-MPLS, or a value to be assigned in	to 2 in the case of EVPN-MPLS, 7/8/9 in the case of EVPN-VXLAN/NVGRE/
	the case of EVPN-VXLAN/NVGRE/GENEVE (Section 5) when an IP header is	GENEVE (Section 5) when an IP header is not used, or 4/6 if an IP
	not used, or 4/6 if an IP header is used for EVPN-VXLAN/NVGRE/GENEVE.	header is used for EVPN-VXLAN/NVGRE/GENEVE.

	To create the proper BIER header for a given packet, the BFIR must	To create the proper BIER header for a given packet, the BFIR must
	know all the BFERs that need to receive that packet. This is	know all the BFERs that need to receive that packet. This is

	determined from the set of leaf tracking routes.	determined from the set of leaf-tracking routes.


	4.1.2. At a BFIR that is a P-tunnel Segmentation Point	4.1.2. At a BFIR That Is a P-Tunnel Segmentation Point

	In this case, the encapsulation for the upstream segment of the	In this case, the encapsulation for the upstream segment of the
	P-tunnel includes (among other things) a label that identifies the	P-tunnel includes (among other things) a label that identifies the
	x-PMSI or IMET A-D route that is the match for reception on the	x-PMSI or IMET A-D route that is the match for reception on the
	upstream segment. The segmentation point re-advertised the route	upstream segment. The segmentation point re-advertised the route
	into one or more downstream regions. Each instance of the re-	into one or more downstream regions. Each instance of the re-
	advertised route for a downstream region has a PTA that specifies the	advertised route for a downstream region has a PTA that specifies the
	tunnel for that region. For any particular downstream region, the	tunnel for that region. For any particular downstream region, the

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

	* If the route matched for transmission is an x-PMSI route, it must	* If the route matched for transmission is an x-PMSI route, it must

	have the LIR flag set in its PTA and the leaf tracking routes are	have the LIR flag set in its PTA, and the leaf-tracking routes are
	all the matching Leaf A-D and SMET routes received in the	all the matching Leaf A-D and SMET routes received in the
	downstream region.	downstream region.


	* If the route matched for transmission is an IMET route, the leaf	* If the route matched for transmission is an IMET route, the leaf-
	tracking routes are all the IMET routes for the same BD received	tracking routes are all the IMET routes for the same BD received
	in the downstream region.	in the downstream region.

	If the downstream region uses BIER, the packet is forwarded as	If the downstream region uses BIER, the packet is forwarded as
	follows: the upstream segmentation's encapsulation is removed and the	follows: the upstream segmentation's encapsulation is removed and the
	above-mentioned label is swapped to the upstream-assigned label in	above-mentioned label is swapped to the upstream-assigned label in
	the PTA of the route matched for transmission, and then a BIER header	the PTA of the route matched for transmission, and then a BIER header
	is imposed as in Section 4.1.1.	is imposed as in Section 4.1.1.

	4.2. Disposition	4.2. Disposition


	The same procedures in section 4.2 of [RFC8556] are followed for	The same procedures in Section 4.2 of [RFC8556] are followed for
	EVPN-MPLS, except some EVPN specifics discussed in the following two	EVPN-MPLS, except for some EVPN specifics that are discussed in the
	sub-sections in this document.	following two subsections of this document.


	For EVPN-VXLAN/NVGRE/GENEVE, the only difference is that the payload	For EVPN-VXLAN/NVGRE/GENEVE, the only differences are that the
	is VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID	payload is VXLAN/NVGRE/GENEVE (with or without an IP header) and the
	field in the VXLAN/NVGRE/GENEVE header is used to determine the	VNI/VSID field in the VXLAN/NVGRE/GENEVE header is used to determine
	corresponding broadcast domain.	the corresponding BD.


	4.2.1. At a BFER that is an Egress PE	4.2.1. At a BFER That Is an Egress PE


	Once the corresponding broadcast domain is determined from the	Once the corresponding BD is determined from the upstream-assigned
	upstream-assigned label or VNI/VSID, EVPN forwarding procedures per	label or VNI/VSID, EVPN forwarding procedures per [RFC7432] or
	[RFC7432] or [RFC8365] are followed. In the case of EVPN-MPLS, if	[RFC8365] are followed. In the case of EVPN-MPLS, if there is an
	there is an inner label in the label stack following the BIER header,	inner label in the label stack following the BIER header, that inner
	that inner label is considered the upstream-assigned ESI label for	label is considered the upstream-assigned ESI label for split-horizon
	split horizon purpose.	purposes.


	4.2.2. At a BFER that is a P-tunnel Segmentation Point	4.2.2. At a BFER That Is a P-Tunnel Segmentation Point

	This is only applicable to EVPN-MPLS. The same procedures in	This is only applicable to EVPN-MPLS. The same procedures in
	Section 4.2.2 of [RFC8556] are followed, subject to multihoming	Section 4.2.2 of [RFC8556] are followed, subject to multihoming

	procedures specified in [I-D.ietf-bess-evpn-bum-procedure-updates].	procedures specified in [RFC9572].

	5. IANA Considerations	5. IANA Considerations


	This document requests three assignments in "BIER Next Protocol	Per this document, IANA has registered the following three values in
	Identifiers" registry, with the following three recommended values:	the "BIER Next Protocol Identifiers" registry:


	* 7: Payload is VXLAN encapsulated (no IP/UDP header)	+=======+================================+===========+
		\| Value \| Description \| Reference \|
		+=======+================================+===========+
		\| 7 \| Payload is VXLAN encapsulated \| RFC 9624 \|
		\| \| (no IP/UDP header) \| \|
		+-------+--------------------------------+-----------+
		\| 8 \| Payload is NVGRE encapsulated \| RFC 9624 \|
		\| \| (no IP header) \| \|
		+-------+--------------------------------+-----------+
		\| 9 \| Payload is GENEVE encapsulated \| RFC 9624 \|
		\| \| (no IP/UDP header) \| \|
		+-------+--------------------------------+-----------+


	* 8: Payload is NVGRE encapsulated (no IP header)	Table 1: BIER Next Protocol Identifiers Registry


	* 9: Payload is GENEVE encapsulated (no IP/UDP header)	IANA has also assigned an IPv4 and an IPv6 multicast address for the
		case discussed in Section 2.1.


	This document requests assignments of an IPv4 and an IPv6 multicast	The following entry has been added to the "Local Network Control
	address for the case discussed in Section 2.1. Preferably this is	Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry for IPv4:
	assigned from the Local Network Control Block (224.0.0/24) for IPv4
	and Link-Local Scope Multicast Addresses for IPv6. The description	Address(es): 224.0.0.122
	is "NVO BUM Traffic".	Description: Network Virtualization Overlay (NVO) BUM Traffic
		Reference: RFC 9624

		The following entry has been added to the "Link-Local Scope Multicast
		Addresses" registry for IPv6:

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

	6. Security Considerations	6. Security Considerations

	This document is about using BIER as provider tunnels for EVPN. It	This document is about using BIER as provider tunnels for EVPN. It

	is very similar to using BIER as MVPN provider tunnel, and does not	is very similar to using BIER as MVPN provider tunnels and does not
	introduce additional security implications beyond what have been	introduce additional security implications beyond what have been

	discussed in EVPN base protocol specification [RFC7432] and MVPN	discussed in the EVPN base protocol specification [RFC7432] and MVPN
	using BIER [RFC8556].	using BIER [RFC8556].


	7. Acknowledgements	7. References

	The authors thank Eric Rosen for his review and suggestions.
	Additionally, much of the text is borrowed verbatim from [RFC8556].

	8. References

	8.1. Normative References


	[I-D.ietf-bess-evpn-bum-procedure-updates]	7.1. Normative References
	Zhang, Z. J., Lin, W., Rabadan, J., Patel, K., and A.
	Sajassi, "Updates on EVPN BUM Procedures", Work in
	Progress, Internet-Draft, draft-ietf-bess-evpn-bum-
	procedure-updates-14, 18 November 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
	evpn-bum-procedure-updates-14>.

	[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 14, line 38 ¶	skipping to change at line 647 ¶
	"Geneve: Generic Network Virtualization Encapsulation",	"Geneve: Generic Network Virtualization Encapsulation",
	RFC 8926, DOI 10.17487/RFC8926, November 2020,	RFC 8926, DOI 10.17487/RFC8926, November 2020,
	<https://www.rfc-editor.org/info/rfc8926>.	<https://www.rfc-editor.org/info/rfc8926>.

	[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,	[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
	and W. Lin, "Internet Group Management Protocol (IGMP) and	and W. Lin, "Internet Group Management Protocol (IGMP) and
	Multicast Listener Discovery (MLD) Proxies for Ethernet	Multicast Listener Discovery (MLD) Proxies for Ethernet
	VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,	VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
	<https://www.rfc-editor.org/info/rfc9251>.	<https://www.rfc-editor.org/info/rfc9251>.


	8.2. Informative References	[RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
		Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or
		Multicast (BUM) Procedures", RFC 9572,
		DOI 10.17487/RFC9572, May 2024,
		<https://www.rfc-editor.org/info/rfc9572>.


	[I-D.ietf-bier-php]	7.2. Informative References
	Zhang, Z. J., "BIER Penultimate Hop Popping", Work in
	Progress, Internet-Draft, draft-ietf-bier-php-10, 9 March
	2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
	bier-php-10>.


	[I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements]	[BIER-PHP] Zhang, Z., "BIER Penultimate Hop Popping", Work in
	Zhang, Z. J., Kebler, R., Lin, W., and E. C. Rosen, "MVPN/	Progress, Internet-Draft, draft-ietf-bier-php-11, 6
	EVPN C-Multicast Routes Enhancements", Work in Progress,	February 2024, <https://datatracker.ietf.org/doc/html/
		draft-ietf-bier-php-11>.

		[CMCAST-ENHANCEMENTS]
		Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN
		C-Multicast Routes Enhancements", Work in Progress,
	Internet-Draft, draft-zzhang-bess-mvpn-evpn-cmcast-	Internet-Draft, draft-zzhang-bess-mvpn-evpn-cmcast-

	enhancements-03, 1 September 2023,	enhancements-04, 17 March 2024,
	<https://datatracker.ietf.org/doc/html/draft-zzhang-bess-	<https://datatracker.ietf.org/doc/html/draft-zzhang-bess-

	mvpn-evpn-cmcast-enhancements-03>.	mvpn-evpn-cmcast-enhancements-04>.

	[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
	Protocol - Traffic Engineering (RSVP-TE) for Point-to-	Protocol - Traffic Engineering (RSVP-TE) for Point-to-
	Multipoint TE Label Switched Paths (LSPs)", RFC 4875,	Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
	DOI 10.17487/RFC4875, May 2007,	DOI 10.17487/RFC4875, May 2007,
	<https://www.rfc-editor.org/info/rfc4875>.	<https://www.rfc-editor.org/info/rfc4875>.

	[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.	[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
	Thomas, "Label Distribution Protocol Extensions for Point-	Thomas, "Label Distribution Protocol Extensions for Point-

	skipping to change at page 15, line 30 ¶	skipping to change at line 693 ¶
	eXtensible Local Area Network (VXLAN): A Framework for	eXtensible Local Area Network (VXLAN): A Framework for
	Overlaying Virtualized Layer 2 Networks over Layer 3	Overlaying Virtualized Layer 2 Networks over Layer 3
	Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,	Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
	<https://www.rfc-editor.org/info/rfc7348>.	<https://www.rfc-editor.org/info/rfc7348>.

	[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network	[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
	Virtualization Using Generic Routing Encapsulation",	Virtualization Using Generic Routing Encapsulation",
	RFC 7637, DOI 10.17487/RFC7637, September 2015,	RFC 7637, DOI 10.17487/RFC7637, September 2015,
	<https://www.rfc-editor.org/info/rfc7637>.	<https://www.rfc-editor.org/info/rfc7637>.


		Acknowledgements

		The authors thank Eric Rosen for his review and suggestions.
		Additionally, much of the text is borrowed verbatim from [RFC8556].

	Authors' Addresses	Authors' Addresses

	Zhaohui Zhang	Zhaohui Zhang
	Juniper Networks	Juniper Networks
	Email: zzhang@juniper.net	Email: zzhang@juniper.net


	Antoni Przygienda	Tony Przygienda
	Juniper Networks	Juniper Networks
	Email: prz@juniper.net	Email: prz@juniper.net

	Ali Sajassi	Ali Sajassi
	Cisco Systems	Cisco Systems
	Email: sajassi@cisco.com	Email: sajassi@cisco.com

	Jorge Rabadan	Jorge Rabadan
	Nokia	Nokia
	Email: jorge.rabadan@nokia.com	Email: jorge.rabadan@nokia.com

End of changes. 114 change blocks.
	291 lines changed or deleted	304 lines changed or added
This html diff was produced by rfcdiff 1.48.