rfc9790v1.txt		rfc9790.txt
	skipping to change at line 104 ¶		skipping to change at line 104 ¶
	information is communicated via other means, such as the routing		information is communicated via other means, such as the routing
	protocols that signal the labels in the stack. Nonetheless, in order		protocols that signal the labels in the stack. Nonetheless, in order
	to better handle an MPLS packet in the data plane, it is common		to better handle an MPLS packet in the data plane, it is common
	practice for network equipment to "guess" the type of embedded		practice for network equipment to "guess" the type of embedded
	packet. Such equipment may also need to process the PSH. Both of		packet. Such equipment may also need to process the PSH. Both of
	these require parsing the data after the label stack. To do this,		these require parsing the data after the label stack. To do this,
	the "first nibble" (the top four bits of the first octet following		the "first nibble" (the top four bits of the first octet following
	the label stack) is often used. Although some existing network		the label stack) is often used. Although some existing network
	devices may use such a method, it needs to be stressed that the		devices may use such a method, it needs to be stressed that the
	correct interpretation of the Post-stack First Nibble (PFN) in a PSH		correct interpretation of the Post-stack First Nibble (PFN) in a PSH
	can be made only in the context associated using the control or		can be made only in the context established through the control or
	management plane with the Label Stack Entry (LSE) or group of LSEs in		management plane with the Label Stack Entry (LSE) or group of LSEs in
	the preceding label stack that characterizes the type of the PSH.		the preceding label stack that characterizes the type of the PSH.
	Any attempt to rely on the value in any other context is unreliable.		Any attempt to rely on the value in any other context is unreliable.
	Because the PFN value should not be used to deduce the type of PSH by		Because the PFN value should not be used to deduce the type of PSH by
	itself and the space of PFN values is limited, the reuse of PFN		itself and the space of PFN values is limited, the reuse of PFN
	values is encouraged when possible.		values is encouraged when possible.
	The semantics and usage of the first nibble are not well documented,		The semantics and usage of the first nibble are not well documented,
	nor are the assignments of values. This document serves four		nor are the assignments of values. This document serves four
	purposes:		purposes:
	skipping to change at line 126 ¶		skipping to change at line 126 ¶
	* To document the values already in use.		* To document the values already in use.
	* To provide a mechanism to document future assignments through the		* To provide a mechanism to document future assignments through the
	creation of a new IANA "Post-Stack First Nibble" registry and		creation of a new IANA "Post-Stack First Nibble" registry and
	describe the relationship between it and the IANA "IP Version		describe the relationship between it and the IANA "IP Version
	Numbers" registry [RFC2780].		Numbers" registry [RFC2780].
	* Provide a method for tracking usage by requiring more detailed		* Provide a method for tracking usage by requiring more detailed
	documentation.		documentation.
	* To stress the importance that any MPLS packet not carrying plain		* To stress that any MPLS packet not carrying plain IPv4 or IPv6
	IPv4 or IPv6 packets contains a PSH, including any new version of		packets contains a PSH. This also applies to packets of any new
	IP (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 and recommends using a		that deprecates the use of the heuristic method for identifying the
	dedicated label value for load balancing. The intent is for legacy		type of packet encapsulated in MPLS and recommends using a dedicated
	routers to continue operating as they have, with no new problems		label value for load balancing. The intent is for legacy routers to
	introduced as a result of this document. However, new		continue operating as they have, with no new problems introduced as a
	implementations that follow this document enable a more robust		result of this document. However, new implementations that follow
	network operation.		this document enable a 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
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	1.2. Definitions		1.2. Definitions
	MPLS packet: A packet whose Layer 2 header declares the type to be		Deprecation: Regardless of how the deprecation is understood in
	MPLS. For example, the Ethertype is 0x8847 or 0x8848 for		other IETF documents, the interpretation in this document is that
	Ethernet, and the Protocol field is 0x0281 or 0x0283 for PPP.		if a practice has been deprecated, that practice should not be
			included in new implementations or deployed in new deployments.
			Embedded Packet: A packet that follows immediately after the MPLS
			label stack and an optional PSH. The embedded packet could be an
			IPv4 or IPv6 packet, an Ethernet packet (for Virtual Private LAN
			Service (VPLS) [RFC4761] [RFC4762] or EVPN [RFC7432]), or some
			other type of Layer 2 frame [RFC4446].
	Label Stack: For an MPLS packet, all labels (four-octet fields)		Label Stack: For an MPLS packet, all labels (four-octet fields)
	after the Layer 2 header, up to and including the label with the		after the Layer 2 header, up to and including the label with the
	Bottom of Stack bit set [RFC3032].		Bottom of Stack bit set [RFC3032].
	Post-stack First Nibble (PFN): The most significant four bits of the		MPLS Packet: A packet whose Layer 2 header declares the type to be
	first octet following the label stack.		MPLS. For example, the Ethertype is 0x8847 or 0x8848 for
			Ethernet, and the Protocol field is 0x0281 or 0x0283 for PPP.
	MPLS Payload: All data after the label stack, including the PFN, an		MPLS Payload: All data after the label stack, including the PFN, an
	optional post-stack header, and the embedded packet.		optional post-stack header, and the embedded packet.
			Post-stack First Nibble (PFN): The most significant four bits of the
			first octet following the label stack.
	Post-Stack Header (PSH): Optional field of interest to the egress		Post-Stack Header (PSH): Optional field of interest to the egress
	Label Switching Router (LSR) (and possibly to transit LSRs).		Label Switching Router (LSR) (and possibly to transit LSRs).
	Examples include a control word [RFC4385] [RFC8964] or an		Examples include a control word [RFC4385] [RFC8964] or an
	associated channel [RFC4385] [RFC5586] [RFC9546]. The PSH MUST		associated channel [RFC4385] [RFC5586] [RFC9546]. The PSH MUST
	indicate its length, so that a parser knows where the embedded		indicate its length, so that a parser knows where the embedded
	packet starts.		packet starts.
	Embedded Packet: A packet that follows immediately after the MPLS
	label stack and an optional PSH. The embedded packet could be an
	IPv4 or IPv6 packet, an Ethernet packet (for Virtual Private LAN
	Service (VPLS) [RFC4761] [RFC4762] or EVPN [RFC7432]), or some
	other type of Layer 2 frame [RFC4446].
	Deprecation: Regardless of how the deprecation is understood in
	other IETF documents, the interpretation in this document is that
	if a practice has been deprecated, that practice should not be
	included in new implementations or deployed in new deployments.
	1.3. Abbreviations		1.3. Abbreviations
	LSR: Label Switching Router		BIER: Bit Index Explicit Replication
	LSE: Label Stack Entry		FAT: Flow-Aware Transport
	PSH: Post-Stack Header		LSE: Label Stack Entry
	PFN: Post-stack First Nibble		LSR: Label Switching Router
	FAT: Flow-Aware Transport		MNA: MPLS Network Action
	SPL: Special-Purpose Label		PFN: Post-stack First Nibble
	PW: Pseudowire		PSH: Post-Stack Header
	MNA: MPLS Network Action		PW: Pseudowire
	BIER: Bit Index Explicit Replication		SPL: Special-Purpose Label
	1.4. Reference Figures		1.4. Reference Figures
	Figure 1 echoes the format of MPLS packets as defined in [RFC3032]		Figure 1 echoes the format of MPLS packets as defined in [RFC3032]
	where TC indicates the Traffic Class field [RFC5462] that replaced		where TC indicates the Traffic Class field [RFC5462] that replaced
	the EXP (Experimental Use) field, S is the Bottom of Stack flag, and		the EXP (Experimental Use) field, S is the Bottom of Stack flag, and
	TTL is the Time to Live field.		TTL is the Time to Live field.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	skipping to change at line 313 ¶		skipping to change at line 313 ¶
	Transfer Mode were reasonably common and may become so again.		Transfer Mode were reasonably common and may become so again.
	In addition, there may be a PSH ahead of the embedded packet. The		In addition, there may be a PSH ahead of the embedded packet. The
	value of PFN is considered to ensure that the PSH can be correctly		value of PFN is considered to ensure that the PSH can be correctly
	parsed.		parsed.
	2.1.1. ECMP Load Balancing		2.1.1. ECMP Load Balancing
	There are four common ways to load balance an MPLS packet:		There are four common ways to load balance an MPLS packet:
	1. One can use the top label alone.		1. Use the top label alone.
	2. One can do better by using all of the non-SPLs [RFC7274] in the		2. Use all of the non-SPLs [RFC7274] in the stack. This is better
	stack.		than using the top label alone.
	3. One can do even better by "divining" the type of embedded packet		3. "Divine" the type of embedded packet and use fields from the
	and using fields from the guessed header. The ramifications of		guessed header. The ramifications of using this load-balancing
	using this load-balancing technique are discussed in detail in		technique are discussed in detail in Section 2.1.1.1. This way
	Section 2.1.1.1.		is better than the two ways above.
	4. One can do best by using either an Entropy Label [RFC6790] or a		4. Use either an Entropy Label [RFC6790] or a Flow-Aware Transport
	Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see		(FAT) Pseudowire Label [RFC6391] (see Section 2.1.1.1). This is
	Section 2.1.1.1).		the best way.
	Load balancing based on just the top label means that all packets		Load balancing based on just the top label means that all packets
	with that top label will go the same way, which is far from ideal.		with that top label will go the same way, which is far from ideal.
	Load balancing based on the entire label stack (not including SPLs)		Load balancing based on the entire label stack (not including SPLs)
	is better, but it may still be uneven. However, if the embedded		is better, but it may still be uneven. However, if the embedded
	packet is an IP packet, then the combination of (<source IP address>,		packet is an IP packet, then the combination of (<source IP address>,
	<dest IP address>, <transport protocol>, <source port>, and <dest		<dest IP address>, <transport protocol>, <source port>, and <dest
	port>) from the IP header of the embedded packet forms an excellent		port>) from the IP header of the embedded packet forms an excellent
	basis for load balancing. This is what is typically used for load		basis for load balancing. This is what is typically used for load
	balancing IP packets.		balancing IP packets.
	skipping to change at line 452 ¶		skipping to change at line 452 ¶
	[RFC4928]:		[RFC4928]:
	NEW TEXT:		NEW TEXT:
	| PSH: Post-Stack Header		| PSH: Post-Stack Header
	|		|
	| PFN: Post-stack First Nibble		| PFN: Post-stack First Nibble
	2.3. Why Create a Registry		2.3. Why Create a Registry
	Support for MPLS Network Actions (MNAs) is described in [RFC9789] and		The framework for MPLS Network Actions (MNAs) is described in
	is an enhancement to the MPLS architecture. The use of Post-Stack		[RFC9789] and is an enhancement to the MPLS architecture. The use of
	Data (PSD) to encode the MNA indicators and ancillary data (described		Post-Stack Data (PSD) to encode the MNA indicators and ancillary data
	in Section 3.6 of [RFC9789]) might place data in the PFN, which could		(described in Section 3.6 of [RFC9789]) might place data in the PFN,
	conflict with other uses of that nibble. This issue is described in		which could conflict with other uses of that nibble. This issue is
	Section 3.6.1 of [RFC9789] and is further illustrated by the PFN		described in Section 3.6.1 of [RFC9789] and is further illustrated by
	value of 0x0, which has two different formats depending on whether		the PFN value of 0x0, which has two different formats depending on
	the PSH is a pseudowire control word or a DetNet control word;		whether the PSH is a pseudowire control word or a DetNet control
	disambiguation requires the context of the service label.		word; disambiguation requires the context of the service label.
	With a registry, PSHs become easier to identify and parse. In		With a registry, PSHs become easier to identify and parse. In
	addition, they do not need a means outside the data plane to		addition, they do not need a means outside the data plane to
	interpret them correctly, and their semantics and usage are		interpret them correctly, and their semantics and usage are
	documented and referenced in the registry.		documented and referenced in the registry.
	2.4. IP Version Numbers Versus Post-Stack First Nibble Values		2.4. IP Version Numbers Versus Post-Stack First Nibble Values
	The use of the PFN stemmed from the desire to heuristically identify		The use of the PFN stemmed from the desire to heuristically identify
	IP packets for load-balancing purposes. It was then discovered that		IP packets for load-balancing purposes. It was then discovered that
	non-IP packets, misidentified as IP when the heuristic failed, were		non-IP packets, misidentified as IP when the heuristic failed, were
	being badly load balanced, leading to [RFC4928]. This situation may		being badly load balanced, leading to the scenario described in
	confuse some as to the relationship between the "Post-Stack First		[RFC4928]. This situation may confuse some as to the relationship
	Nibble" registry and the "IP Version Numbers" registry. These		between the "Post-Stack First Nibble" registry and the "IP Version
	registries are quite different:		Numbers" registry. These registries are quite different:
	1. The explicit purpose of the "IP Version Numbers" registry is to		1. The explicit purpose of the "IP Version Numbers" registry is to
	track IP version numbers in an IP header.		track IP version numbers in an IP header.
	2. The purpose of the "Post-Stack First Nibble" registry is to track		2. The purpose of the "Post-Stack First Nibble" registry is to track
	PSH types.		PSH types.
	The only intersection points between the two registries are the		The only intersection points between the two registries are the
	values 0x4 and 0x6 (for backward compatibility).		values 0x4 and 0x6 (for backward compatibility).
	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.
	It would assist with the progress toward a simpler, more coherent		Obsoleting the use of a PSH for non-IP payloads encapsulated in MPLS
	system of MPLS data encapsulation if the use a PSH for non-IP		would assist with the progress toward a simpler, more coherent system
	payloads encapsulated in MPLS was obsoleted. However, before that		of MPLS data encapsulation. However, before that can be done, it is
	can be done, it is important to collect sufficient evidence that		important to collect sufficient evidence that there are no marketed
	there are no marketed or deployed implementations using the heuristic		or deployed implementations using the heuristic practice to load-
	practice to load-balancing MPLS data flows.		balancing 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-
End of changes. 23 change blocks.
	64 lines changed or deleted		64 lines changed or added
This html diff was produced by rfcdiff 1.48.