rfc9790v4.txt		rfc9790.txt
	skipping to change at line 13 ¶		skipping to change at line 13 ¶
	Request for Comments: 9790 Juniper Networks		Request for Comments: 9790 Juniper Networks
	Updates: 4928 S. Bryant		Updates: 4928 S. Bryant
	Category: Standards Track University of Surrey 5GIC		Category: Standards Track University of Surrey 5GIC
	ISSN: 2070-1721 M. Bocci		ISSN: 2070-1721 M. Bocci
	Nokia		Nokia
	G. Mirsky, Ed.		G. Mirsky, Ed.
	Ericsson		Ericsson
	L. Andersson		L. Andersson
	J. Dong		J. Dong
	Huawei Technologies		Huawei Technologies
	May 2025		June 2025
	IANA Registry and Processing Recommendations for the First Nibble		IANA Registry and Processing Recommendations for the First Nibble
	Following a Label Stack		Following a Label Stack
	Abstract		Abstract
	This document creates a new IANA registry (called the "Post-Stack		This document creates a new IANA registry (called the "Post-Stack
	First Nibble" registry) for the first nibble (4-bit field)		First Nibble" registry) for the first nibble (4-bit field)
	immediately following an MPLS label stack. Furthermore, this		immediately following an MPLS label stack. Furthermore, this
	document presents some requirements for registering new values and		document presents some requirements for registering new values and
	skipping to change at line 137 ¶		skipping to change at line 137 ¶
	packets contains a PSH. This also applies to packets of any new		packets contains a PSH. This also applies to packets of any new
	version of IP (see Section 2.4).		version of IP (see Section 2.4).
	Section 2.1.1 of this document includes an analysis of load-balancing		Section 2.1.1 of this document includes an analysis of load-balancing
	techniques; based on this, Section 2.1.1.1 introduces a requirement		techniques; based on this, Section 2.1.1.1 introduces a requirement
	that deprecates the use of the heuristic method for identifying the		that deprecates the use of the heuristic method for identifying the
	type of packet encapsulated in MPLS and recommends using a dedicated		type of packet encapsulated in MPLS and recommends using a dedicated
	label value for load balancing. The intent is for legacy routers to		label value for load balancing. The intent is for legacy routers to
	continue operating as they have, with no new problems introduced as a		continue operating as they have, with no new problems introduced as a
	result of this document. However, new implementations that follow		result of this document. However, new implementations that follow
	this document enable a more robust network operation.		this document enable more robust network operation.
	Furthermore, this document updates [RFC4928] by deprecating the		Furthermore, this document updates [RFC4928] by deprecating the
	heuristic method for identifying the type of packet encapsulated in		heuristic method for identifying the type of packet encapsulated in
	MPLS. This document clearly states that the type of encapsulated		MPLS. This document clearly states that the type of encapsulated
	packet cannot be determined based on the PFN alone.		packet cannot be determined based on the PFN alone.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	skipping to change at line 166 ¶		skipping to change at line 166 ¶
	if a practice has been deprecated, that practice should not be		if a practice has been deprecated, that practice should not be
	included in new implementations or deployed in new deployments.		included in new implementations or deployed in new deployments.
	Embedded Packet: A packet that follows immediately after the MPLS		Embedded Packet: A packet that follows immediately after the MPLS
	label stack and an optional PSH. The embedded packet could be an		label stack and an optional PSH. The embedded packet could be an
	IPv4 or IPv6 packet, an Ethernet packet (for Virtual Private LAN		IPv4 or IPv6 packet, an Ethernet packet (for Virtual Private LAN
	Service (VPLS) [RFC4761] [RFC4762] or EVPN [RFC7432]), or some		Service (VPLS) [RFC4761] [RFC4762] or EVPN [RFC7432]), or some
	other type of Layer 2 frame [RFC4446].		other type of Layer 2 frame [RFC4446].
	Label Stack: A label stack is represented as a consecutive sequence		Label Stack: A label stack is represented as a consecutive sequence
	of "label stack entries (four-octet fields)" after the Layer 2		of "label stack entries" (four-octet fields) after the Layer 2
	header but before any network layer header. The last label stack		header but before any network layer header. The last label stack
	entry of a label stack has its Bottom of Stack bit set.		entry of a label stack has its Bottom of Stack bit set.
	MPLS Packet: A packet whose Layer 2 header declares the type to be		MPLS Packet: A packet whose Layer 2 header declares the type to be
	MPLS. For example, the Ethertype is 0x8847 or 0x8848 for		MPLS. For example, the Ethertype is 0x8847 or 0x8848 for
	Ethernet, and the Protocol field is 0x0281 or 0x0283 for PPP.		Ethernet, and the Protocol field is 0x0281 or 0x0283 for PPP.
	MPLS Payload: All data after the label stack and the optional Post-		MPLS Payload: All data after the label stack and any optional PSHs.
	Stack header.		It is possible that more than one type of PSH may be present in a
			packet, and some PSH specifications might allow multiple PSHs of
			the same type. The presence rules for multiple PSHs are a matter
			for the documents that define those PSHs, e.g., [MNA-PS-HDR].
	Post-stack First Nibble (PFN): The most significant four bits of the		Post-stack First Nibble (PFN): The most significant four bits of the
	first octet following the label stack.		first octet following the label stack.
	Post-Stack Header (PSH): A field containing information that may be		Post-Stack Header (PSH): A field containing information that may be
	of interest to the egress Label Switching Router (LSR) or transit		of interest to the egress Label Switching Router (LSR) or transit
	LSRs. Examples include a control word [RFC4385] [RFC8964] or an		LSRs. Examples include a control word [RFC4385] [RFC8964] or an
	associated channel header [RFC4385] [RFC5586] [RFC9546]. A parser		associated channel header [RFC4385] [RFC5586] [RFC9546].
	needs to be able to determine where the PSH ends in order to find
	the embedded packet.
	1.3. Abbreviations		1.3. Abbreviations
	BIER: Bit Index Explicit Replication		BIER: Bit Index Explicit Replication
	FAT: Flow-Aware Transport		FAT: Flow-Aware Transport
	LSE: Label Stack Entry		LSE: Label Stack Entry
	LSR: Label Switching Router		LSR: Label Switching Router
	skipping to change at line 265 ¶		skipping to change at line 266 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PSH | |		| PSH | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... |		... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| end of PSH | |		| end of PSH | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| embedded packet | |		| embedded packet | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	Figure 2: Examples of an MPLS Packet Payload With and Without		Figure 2: Examples of an MPLS Packet Payload With and Without a
	Post-Stack Header		Preceding Post-Stack Header
	Figure 1 shows an MPLS packet with a Layer 2 header X and a label		Figure 1 shows an MPLS packet with a Layer 2 header X and a label
	stack Y ending with Label-n. Figure 2 displays three examples of an		stack Y ending with Label-n. Figure 2 displays three examples of an
	MPLS payload:		MPLS payload:
	Example A: The first payload is a bare IP packet, i.e., no PSH. The		Example A: The first payload is a bare IP packet, i.e., no PSH. The
	PFN in this case overlaps with the IP version number.		PFN in this case overlaps with the IP version number.
	Example B: The next payload is a bare non-IP packet; again, no PSH.		Example B: The next payload is a bare non-IP packet; again, no PSH.
	The PFN here is the first nibble of the payload, whatever it		The PFN here is the first nibble of the payload, whatever it
	happens to be.		happens to be.
	Example C: This example is an MPLS Payload that starts with a PSH		Example C: This example is an MPLS Payload that follows a PSH.
	followed by the embedded packet. Here, the embedded packet could		Here, the embedded packet could be IP or non-IP.
	be IP or non-IP.
	Thus, the complete MPLS packet would consist of [X Y A], [X Y B], or		Thus, the complete MPLS packet would consist of [X Y A], [X Y B], or
	[X Y C].		[X Y C].
	2. Rationale		2. Rationale
	2.1. Why Look at the First Nibble		2.1. Why Look at the First Nibble
	An MPLS packet can contain one of many types of embedded packets.		An MPLS packet can contain one of many types of embedded packets.
	Three common types are:		Three common types are:
	skipping to change at line 359 ¶		skipping to change at line 359 ¶
	and find the relevant fields for load balancing on that basis.		and find the relevant fields for load balancing on that basis.
	2. If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet,		2. If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet,
	and find the relevant fields for load balancing on that basis.		and find the relevant fields for load balancing on that basis.
	3. If the PFN is anything else, the MPLS payload is not an IP		3. If the PFN is anything else, the MPLS payload is not an IP
	packet; fall back to load balancing using the label stack.		packet; fall back to load balancing using the label stack.
	This heuristic has been implemented in many (legacy) routers and		This heuristic has been implemented in many (legacy) routers and
	performs well in the case of example A in Figure 2. However, this		performs well in the case of example A in Figure 2. However, this
	heuristic can work very badly for non-IP packet as shown in example B		heuristic can work very badly for the non-IP packet as shown in
	in Figure 2. For example, if payload B is an Ethernet frame, then		example B in Figure 2. For example, if payload B is an Ethernet
	the PFN is the first nibble of the Organizationally Unique Identifier		frame, then the PFN is the first nibble of the Organizationally
	of the destination MAC address, which can be 0x4 or 0x6. This would		Unique Identifier of the destination MAC address, which can be 0x4 or
	lead to the packet being treated as an IPv4 or IPv6 packet such that		0x6. This would lead to the packet being treated as an IPv4 or IPv6
	data at the offsets of specific relevant fields would be used as		packet such that data at the offsets of specific relevant fields
	input to the load-balancing heuristic, resulting in unpredictable		would be used as input to the load-balancing heuristic, resulting in
	load balancing. This behavior can happen to other types of non-IP		unpredictable load balancing. This behavior can happen to other
	payloads as well.		types of non-IP payloads as well.
	That, in turn, led to the idea of inserting a PSH (e.g., a pseudowire		That, in turn, led to the idea of inserting a PSH (e.g., a pseudowire
	control word [RFC4385], a Deterministic Networking (DetNet) control		control word [RFC4385], a Deterministic Networking (DetNet) control
	word [RFC8964], a Network Service Header (NSH) [RFC8300], or a BIER		word [RFC8964], a Network Service Header (NSH) [RFC8300], or a BIER
	header [RFC8296]) where the PFN is not 0x4 or 0x6; this explicitly		header [RFC8296]) where the PFN is not 0x4 or 0x6; this explicitly
	prevents forwarding engines from confusing the MPLS payload with an		prevents forwarding engines from confusing the MPLS payload with an
	IP packet. [RFC8469] recommends the use of a control word when the		IP packet. [RFC8469] recommends the use of a control word when the
	embedded packet is an Ethernet frame. [RFC8469] was published at the		embedded packet is an Ethernet frame. [RFC8469] was published at the
	request of the operator community and the IEEE Registration Authority		request of the operator community and the IEEE Registration Authority
	Committee as a result of operational difficulties with pseudowires		Committee as a result of operational difficulties with pseudowires
	skipping to change at line 497 ¶		skipping to change at line 497 ¶
	2.5. Next Step to More Deterministic Load Balancing in MPLS Networks		2.5. Next Step to More Deterministic Load Balancing in MPLS Networks
	Network evolution is impossible to control, but it develops over a		Network evolution is impossible to control, but it develops over a
	period of time determined by various factors.		period of time determined by various factors.
	This document discourages further proliferation of the		This document discourages further proliferation of the
	implementations that could lead to undesired effects on data flows.		implementations that could lead to undesired effects on data flows.
	In doing so, it limits the scope of future protocol developments and		In doing so, it limits the scope of future protocol developments and
	thus helps to ensure that future network evolution will be smoother.		thus helps to ensure that future network evolution will be smoother.
	Obsoleting the use of a PSH for non-IP payloads encapsulated in MPLS		Section 2 of [RFC4385] suggests the use of a PSH solely for the
	would assist with the progress toward a simpler, more coherent system		purpose of avoiding IP ECMP treatment of non-IP payloads encapsulated
	of MPLS data encapsulation. However, before that can be done, it is		in MPLS. Obsoleting this use of a PSH would assist with the progress
	important to collect sufficient evidence that there are no marketed		toward a simpler, more coherent system of MPLS data encapsulation.
	or deployed implementations using the heuristic practice to load-		(Other uses of a PSH may still be valid.) However, before that can
	balancing MPLS data flows.		be done, it is important to collect sufficient evidence that there
			are no marketed or deployed implementations using the heuristic
			practice to load balance MPLS data flows.
	Therefore, the next steps toward more deterministic load balancing in		Therefore, the next steps toward more deterministic load balancing in
	MPLS networks are to gradually deprecate non-PSH MPLS encapsulations		MPLS networks are to gradually deprecate non-PSH MPLS encapsulations
	of non-IP data, to cease using heuristic load balancing, and to		of non-IP data, to cease using heuristic load balancing, and to
	survey the available and deployed implementations to determine when		survey the available and deployed implementations to determine when
	obsoletion may be achieved.		obsoletion may be achieved.
	3. IANA Considerations		3. IANA Considerations
	Per this document, IANA has created a registry group called "Post-		Per this document, IANA has created a registry group called "Post-
	skipping to change at line 649 ¶		skipping to change at line 651 ¶
	Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January		Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
	2021, <https://www.rfc-editor.org/info/rfc8964>.		2021, <https://www.rfc-editor.org/info/rfc8964>.
	[RFC9789] Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS		[RFC9789] Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
	Network Actions (MNAs) Framework", RFC 9789,		Network Actions (MNAs) Framework", RFC 9789,
	DOI 10.17487/RFC9789, May 2025,		DOI 10.17487/RFC9789, May 2025,
	<https://www.rfc-editor.org/info/rfc9789>.		<https://www.rfc-editor.org/info/rfc9789>.
	5.2. Informative References		5.2. Informative References
			[MNA-PS-HDR]
			Rajamanickam, J., Ed., Gandhi, R., Ed., Zigler, R., Li,
			T., and J. Dong, "Post-Stack MPLS Network Action (MNA)
			Solution", Work in Progress, Internet-Draft, draft-ietf-
			mpls-mna-ps-hdr-01, 30 May 2025,
			<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
			mna-ps-hdr-01>.
	[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge		[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
	Emulation (PWE3)", BCP 116, RFC 4446,		Emulation (PWE3)", BCP 116, RFC 4446,
	DOI 10.17487/RFC4446, April 2006,		DOI 10.17487/RFC4446, April 2006,
	<https://www.rfc-editor.org/info/rfc4446>.		<https://www.rfc-editor.org/info/rfc4446>.
	[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private		[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
	LAN Service (VPLS) Using BGP for Auto-Discovery and		LAN Service (VPLS) Using BGP for Auto-Discovery and
	Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,		Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
	<https://www.rfc-editor.org/info/rfc4761>.		<https://www.rfc-editor.org/info/rfc4761>.
	skipping to change at line 705 ¶		skipping to change at line 715 ¶
	Acknowledgements		Acknowledgements
	The authors express their appreciation and gratitude to Donald		The authors express their appreciation and gratitude to Donald
	E. Eastlake 3rd for the review, insightful questions, and helpful		E. Eastlake 3rd for the review, insightful questions, and helpful
	comments. Also, the authors are grateful to Amanda Baber for helping		comments. Also, the authors are grateful to Amanda Baber for helping
	organize the IANA registry in a clear and concise manner.		organize the IANA registry in a clear and concise manner.
	Éric Vyncke, John Scudder, Warren Kumari, Murray Kucherawy, and		Éric Vyncke, John Scudder, Warren Kumari, Murray Kucherawy, and
	Gunter Van de Velde provided helpful comments during IESG review.		Gunter Van de Velde provided helpful comments during IESG review.
			The authors would also like to thank Adrian Farrel for his patient
			and careful shepherding and for helping to finalize the text.
	Authors' Addresses		Authors' Addresses
	Kireeti Kompella		Kireeti Kompella
	Juniper Networks		Juniper Networks
	1133 Innovation Way		1133 Innovation Way
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	United States of America		United States of America
	Email: kireeti.ietf@gmail.com		Email: kireeti.ietf@gmail.com
	Stewart Bryant		Stewart Bryant
End of changes. 11 change blocks.
	28 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.48.