rfc9790v1.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 July 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 89 skipping to change at line 89
5. References 5. References
5.1. Normative References 5.1. Normative References
5.2. Informative References 5.2. Informative References
Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
An MPLS packet consists of a label stack, an optional Post-Stack An MPLS packet consists of a label stack, an optional Post-Stack
Header (PSH), and an optional embedded packet (in that order). Header (PSH), and an optional embedded packet (in that order).
Examples of PSH include existing artifacts such as control words Examples of PSHs include existing headers such as control words
[RFC4385], BIER (Bit Index Explicit Replication) headers [RFC8296] [RFC4385], BIER (Bit Index Explicit Replication) headers [RFC8296]
and the like, as well as new types of PSH being discussed by the MPLS and the like, as well as new types of PSH being discussed by the MPLS
Working Group. However, in the data plane, there are very few clues Working Group. However, in the data plane, there are very few clues
regarding the PSH and no clue as to the type of embedded packet; this regarding the PSH and no clue as to the type of embedded packet; this
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 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.
Label Stack: For an MPLS packet, all labels (four-octet fields)
after the Layer 2 header, up to and including the label with the
Bottom of Stack bit set [RFC3032].
Post-stack First Nibble (PFN): The most significant four bits of the
first octet following the label stack.
MPLS Payload: All data after the label stack, including the PFN, an
optional post-stack header, and the embedded packet.
Post-Stack Header (PSH): Optional field of interest to the egress
Label Switching Router (LSR) (and possibly to transit LSRs).
Examples include a control word [RFC4385] [RFC8964] or an
associated channel [RFC4385] [RFC5586] [RFC9546]. The PSH MUST
indicate its length, so that a parser knows where the embedded
packet starts.
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].
Deprecation: Regardless of how the deprecation is understood in Label Stack: A label stack is represented as a consecutive sequence
other IETF documents, the interpretation in this document is that of "label stack entries" (four-octet fields) after the Layer 2
if a practice has been deprecated, that practice should not be header but before any network layer header. The last label stack
included in new implementations or deployed in new deployments. 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. 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 and any optional PSHs.
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
first octet following the label stack.
Post-Stack Header (PSH): A field containing information that may be
of interest to the egress Label Switching Router (LSR) or transit
LSRs. Examples include a control word [RFC4385] [RFC8964] or an
associated channel header [RFC4385] [RFC5586] [RFC9546].
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 264 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 313 skipping to change at line 314
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 358 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 452 skipping to change at line 453
[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 Section 2 of [RFC4385] suggests the use of a PSH solely for the
system of MPLS data encapsulation if the use a PSH for non-IP purpose of avoiding IP ECMP treatment of non-IP payloads encapsulated
payloads encapsulated in MPLS was obsoleted. However, before that in MPLS. Obsoleting this use of a PSH would assist with the progress
can be done, it is important to collect sufficient evidence that toward a simpler, more coherent system of MPLS data encapsulation.
there are no marketed or deployed implementations using the heuristic (Other uses of a PSH may still be valid.) However, before that can
practice to load-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 642 skipping to change at line 645
Use the Ethernet Control Word", RFC 8469, Use the Ethernet Control Word", RFC 8469,
DOI 10.17487/RFC8469, November 2018, DOI 10.17487/RFC8469, November 2018,
<https://www.rfc-editor.org/info/rfc8469>. <https://www.rfc-editor.org/info/rfc8469>.
[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
S., and J. Korhonen, "Deterministic Networking (DetNet) S., and J. Korhonen, "Deterministic Networking (DetNet)
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 Action (MNA) Framework", RFC 9789, Network Actions (MNAs) Framework", RFC 9789,
DOI 10.17487/RFC9789, May 2025, DOI 10.17487/RFC9789, July 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 704 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. 29 change blocks. 
90 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.48.