rfc9573v3.txt		rfc9573.txt
	skipping to change at line 12 ¶		skipping to change at line 12 ¶
	Internet Engineering Task Force (IETF) Z. Zhang		Internet Engineering Task Force (IETF) Z. Zhang
	Request for Comments: 9573 Juniper Networks		Request for Comments: 9573 Juniper Networks
	Updates: 6514, 7432, 7582 E. Rosen		Updates: 6514, 7432, 7582 E. Rosen
	Category: Standards Track Individual		Category: Standards Track Individual
	ISSN: 2070-1721 W. Lin		ISSN: 2070-1721 W. Lin
	Juniper Networks		Juniper Networks
	Z. Li		Z. Li
	Huawei Technologies		Huawei Technologies
	IJ. Wijnands		IJ. Wijnands
	Individual		Individual
	April 2024		May 2024
	MVPN/EVPN Tunnel Aggregation with Common Labels		MVPN/EVPN Tunnel Aggregation with Common Labels
	Abstract		Abstract
	The Multicast VPN (MVPN) specifications allow a single Point-to-		The Multicast VPN (MVPN) specifications allow a single Point-to-
	Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs		Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs
	(referred to as VPNs in this document). The EVPN specifications		(referred to as VPNs in this document). The EVPN specifications
	allow a single P2MP tunnel to carry traffic of multiple Broadcast		allow a single P2MP tunnel to carry traffic of multiple Broadcast
	Domains (BDs). These features require the ingress router of the P2MP		Domains (BDs). These features require the ingress router of the P2MP
	skipping to change at line 296 ¶		skipping to change at line 296 ¶
	One method of achieving this is to reserve a portion of the default		One method of achieving this is to reserve a portion of the default
	label space for assignment by a central entity. We refer to this		label space for assignment by a central entity. We refer to this
	reserved portion as the DCB of labels. This is analogous to the		reserved portion as the DCB of labels. This is analogous to the
	concept of using identical SRGBs on all nodes, as described in		concept of using identical SRGBs on all nodes, as described in
	[RFC8402]. A PE that is attached (via L3VPN Virtual Routing and		[RFC8402]. A PE that is attached (via L3VPN Virtual Routing and
	Forwarding (VRF) interfaces or EVPN Attachment Circuits) would know		Forwarding (VRF) interfaces or EVPN Attachment Circuits) would know
	by provisioning which label from the DCB corresponds to which of its		by provisioning which label from the DCB corresponds to which of its
	locally attached VPNs, BDs, or ESs.		locally attached VPNs, BDs, or ESs.
	For example, all PEs could reserve a DCB [1000~2000], and they are		For example, all PEs could reserve a DCB [1000~2000], and they would
	all provisioned that label 1000 maps to VPN 0, 1001 to VPN 1, and so		all be provisioned so that label 1000 maps to VPN 0, label 1001 maps
	forth. Now, only 1000 labels instead of 1,000,000 labels are needed		to VPN 1, and so forth. Now, only 1000 labels instead of 1,000,000
	for 1000 VPNs.		labels are needed for 1000 VPNs.
	In this document, "domain" is defined loosely; it simply includes all		In this document, "domain" is defined loosely; it simply includes all
	the routers that share the same DCB, and it only needs to include all		the routers that share the same DCB, and it only needs to include all
	PEs of an MVPN/EVPN.		PEs of an MVPN/EVPN.
	The "domain" could also include all routers in the provider network,		The "domain" could also include all routers in the provider network,
	making it not much different from a common SRGB across all the		making it not much different from a common SRGB across all the
	routers. However, that is not necessary, as the labels used by PEs		routers. However, that is not necessary, as the labels used by PEs
	for the purposes defined in this document will only rise to the top		for the purposes defined in this document will only rise to the top
	of the label stack when traffic arrives at the PEs. Therefore, it is		of the label stack when traffic arrives at the PEs. Therefore, it is
	better to not include internal P routers in the "domain". That way,		better to not include internal P routers in the "domain". That way,
	they do not have to set aside the same DCB used for the purposes		they do not have to set aside the same DCB used for the purposes
	defined in this document.		defined in this document.
	In some deployments, it may be impractical to allocate a DCB that is		In some deployments, it may be impractical to allocate a DCB that is
	large enough to contain labels for all the VPNs/BDs/ESs. In this		large enough to contain labels for all the VPNs/BDs/ESs. In this
	case, it may be necessary to allocate those labels from one label		case, it may be necessary to allocate those labels from one or a few
	space or the few separate context-specific label spaces that are		context-specific label spaces that are independent of each PE. For
	independent of each PE. For example, if it is too difficult to have		example, if it is too difficult to have a DCB of 10,000 labels across
	a DCB of 10,000 labels across all PEs for all the VPNs/BDs/ESs that		all PEs for all the VPNs/BDs/ESs that need to be supported, a
	need to be supported, a separate context-specific label space can be		separate context-specific label space can be dedicated to those
	dedicated to those 10,000 labels. Each separate context-specific		10,000 labels. Each separate context-specific label space is
	label space is identified in the forwarding plane by a label from the		identified in the forwarding plane by a label from the DCB (which
	DCB (which does not need to be large). Each PE is provisioned with		does not need to be large). Each PE is provisioned with the label-
	the label-space-identifying DCB label and the common VPN/BD/ES labels		space-identifying DCB label and the common VPN/BD/ES labels allocated
	allocated from that context-specific label space. When sending		from that context-specific label space. When sending traffic, an
	traffic, an ingress PE imposes all necessary service labels (for the		ingress PE imposes all necessary service labels (for the VPN/BD/ES)
	VPN/BD/ES) first, then imposes the label-space-identifying DCB label.		first, then imposes the label-space-identifying DCB label. From the
	From the label-space-identifying DCB label, an egress PE can		label-space-identifying DCB label, an egress PE can determine the
	determine the label space where the inner VPN/BD/ES label is looked		label space where the inner VPN/BD/ES label is looked up.
	up.
	The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes		The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes
	that certain MPLS labels are allocated from a context-specific label		that certain MPLS labels are allocated from a context-specific label
	space for a particular ingress PE. In this document, we augment the		space for a particular ingress PE. In this document, we augment the
	signaling procedures so that it is possible to signal that a		signaling procedures so that it is possible to signal that a
	particular label is from the DCB, rather than from a context-specific		particular label is from the DCB, rather than from a context-specific
	label space for an ingress PE. We also augment the signaling so that		label space for an ingress PE. We also augment the signaling so that
	it is possible to indicate that a particular label is from an		it is possible to indicate that a particular label is from an
	identified context-specific label space that is not for an ingress		identified context-specific label space that is not for an ingress
	PE.		PE.
	skipping to change at line 357 ¶		skipping to change at line 356 ¶
	from allocating VNIs and is especially feasible with controllers.		from allocating VNIs and is especially feasible with controllers.
	3.1. MP2MP Tunnels		3.1. MP2MP Tunnels
	Multipoint-to-Multipoint (MP2MP) tunnels present the same problem		Multipoint-to-Multipoint (MP2MP) tunnels present the same problem
	(Section 2) that can be solved the same way (Section 3), with the		(Section 2) that can be solved the same way (Section 3), with the
	following additional requirement.		following additional requirement.
	Per [RFC7582] ("Multicast Virtual Private Network (MVPN): Using		Per [RFC7582] ("Multicast Virtual Private Network (MVPN): Using
	Bidirectional P-Tunnels"), when MP2MP tunnels are used for an MVPN,		Bidirectional P-Tunnels"), when MP2MP tunnels are used for an MVPN,
	the root of the MP2MP tunnel may need to allocate and advertise "PE		the root of the MP2MP tunnel is required to allocate and advertise
	Distinguisher Labels" (Section 4 of [RFC6513]). These labels are		"PE Distinguisher Labels" (Section 4 of [RFC6513]). These labels are
	assigned from the label space used by the root node for its upstream-		assigned from the label space used by the root node for its upstream-
	assigned labels.		assigned labels.
	It is REQUIRED by this document that the PE Distinguisher Labels		It is REQUIRED by this document that the PE Distinguisher Labels
	allocated by a particular node come from the same label space that		allocated by a particular node come from the same label space that
	the node uses to allocate its VPN-identifying labels.		the node uses to allocate its VPN-identifying labels.
	3.2. Segmented Tunnels		3.2. Segmented Tunnels
	There are some additional issues to be considered when an MVPN or		There are some additional issues to be considered when an MVPN or
	skipping to change at line 761 ¶		skipping to change at line 760 ¶
	[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,		[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
	Decraene, B., Litkowski, S., and R. Shakir, "Segment		Decraene, B., Litkowski, S., and R. Shakir, "Segment
	Routing with the MPLS Data Plane", RFC 8660,		Routing with the MPLS Data Plane", RFC 8660,
	DOI 10.17487/RFC8660, December 2019,		DOI 10.17487/RFC8660, December 2019,
	<https://www.rfc-editor.org/info/rfc8660>.		<https://www.rfc-editor.org/info/rfc8660>.
	[RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.		[RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
	Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or		Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or
	Multicast (BUM) Procedures", RFC 9572,		Multicast (BUM) Procedures", RFC 9572,
	DOI 10.17487/RFC9572, April 2024,		DOI 10.17487/RFC9572, May 2024,
	<https://www.rfc-editor.org/info/rfc9572>.		<https://www.rfc-editor.org/info/rfc9572>.
	Acknowledgements		Acknowledgements
	The authors thank Stephane Litkowski, Ali Sajassi, and Jingrong Xie		The authors thank Stephane Litkowski, Ali Sajassi, and Jingrong Xie
	for their reviews of, comments on, and suggestions for this document.		for their reviews of, comments on, and suggestions for this document.
	Contributors		Contributors
	The following individual also contributed to this document:		The following individual also contributed to this document:
End of changes. 5 change blocks.
	23 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.48.