rfc9790.original.xml   rfc9790.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
raft-ietf-mpls-1stnibble-13" category="std" ipr="trust200902" obsoletes="" updat <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
es="4928" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version raft-ietf-mpls-1stnibble-13" number="9790" consensus="true" category="std" ipr="
="3"> trust200902" obsoletes="" updates="4928" xml:lang="en" symRefs="true" sortRefs="
<!-- xml2rfc v2v3 conversion 3.16.0 --> true" tocInclude="true" version="3">
<!-- Generated by id2xml 1.5.0 on 2023-03-09T15:36:48Z -->
<!-- [rfced] Please note that the abbreviated title of the document has been
updated as follows. The abbreviated title only appears in the running
header in the pdf output.
Original:
1st nibble
Current:
First Nibble Following Label Stack
-->
<front> <front>
<title abbrev="1st nibble">IANA Registry and Processing Recommendations for <title abbrev="First Nibble Following Label Stack">IANA Registry and Process
the First Nibble Following a Label Stack</title> ing Recommendations
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-1stnibble-13"/> for the First Nibble Following a Label Stack</title>
<seriesInfo name="RFC" value="9790"/>
<author initials="K." surname="Kompella" fullname="Kireeti Kompella"> <author initials="K." surname="Kompella" fullname="Kireeti Kompella">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way</street> <street>1133 Innovation Way</street>
<street>Sunnyvale, 94089</street> <city>Sunnyvale</city> <region>CA</region> <code>94089</code>
<street>United States of America</street> <country>United States of America</country>
</postal> </postal>
<email>kireeti.ietf@gmail.com</email> <email>kireeti.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Bryant" fullname="Stewart Bryant"> <author initials="S." surname="Bryant" fullname="Stewart Bryant">
<organization>University of Surrey 5GIC</organization> <organization>University of Surrey 5GIC</organization>
<address> <address>
<email>sb@stewartbryant.com</email> <email>sb@stewartbryant.com</email>
</address> </address>
</author> </author>
skipping to change at line 49 skipping to change at line 62
<address> <address>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<author initials="L." surname="Andersson" fullname="Loa Andersson"> <author initials="L." surname="Andersson" fullname="Loa Andersson">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<email>loa@pi.nu</email> <email>loa@pi.nu</email>
</address> </address>
</author> </author>
<author initials="J." surname="Dong" fullname="Jie Dong"> <author initials="J." surname="Dong" fullname="Jie Dong">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street> <street>Huawei Campus, No. 156 Beiqing Rd.</street>
<street>Beijing, 100095</street> <city>Beijing</city> <code>100095</code>
<street>China</street> <country>China</country>
</postal> </postal>
<email>jie.dong@huawei.com</email> <email>jie.dong@huawei.com</email>
</address> </address>
</author> </author>
<date year="2024"/> <date year="2025" month="May"/>
<workgroup>MPLS Working Group</workgroup> <area>RTG</area>
<workgroup>mpls</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t> <t>
This document creates a new IANA registry (called the This document creates a new IANA registry (called the
Post-stack First Nibble registry) for the first nibble (4-bit field) "Post-Stack First Nibble" registry) for the first nibble (4-bit field)
immediately following an MPLS label stack. Furthermore, this document immediately following an MPLS label stack. Furthermore, this document
sets out some documentation requirements for registering new values, presents some requirements for registering new values
and requirements that make processing MPLS and making the processing of MPLS
packets easier and more robust. packets easier and more robust.
</t> </t>
<t>The relationship between the IANA IP Version Numbers (RFC 2780) <t>The relationship between the IANA "Post-Stack First Nibble" registry and the
and the Post-stack First Nibble registry is described in this document.</t> "IP Version Numbers" registry (RFC 2780)
is described in this document.</t>
<t>This document updates RFC 4928 by deprecating <t>This document updates RFC 4928 by deprecating
the heuristic method for identifying the type of packet encapsulated the heuristic method for identifying the type of packet encapsulated
in MPLS.</t> in MPLS.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" numbered="true" toc="default"> <section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <!-- [rfced] Please clarify "in the context associated". Should this text
An MPLS packet consists of a label stack, an optional "post-stack header" (PS align more closely with a similar sentence in the IANA section?
H) and an optional embedded packet (in that order). Examples of
PSH include existing artifacts such as Control Words <xref target="RFC4385"/> Original:
, BIER (Bit-Indexed Explicit Replication) headers <xref target="RFC8296"/> Although some existing network
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
can be made only in the context associated using the control or
management plane with the Label Stack Element (LSE) or group of LSEs
in the preceding label stack that characterize the type of the PSH,
and that any attempt to rely on the value in any other context is
unreliable.
Perhaps:
Although some existing network
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
can be made only in the context of using the control or
management plane with the Label Stack Entry (LSE) or group of LSEs
in the preceding label stack that characterizes the type of the PSH.
Any attempt to rely on the value in any other context is
unreliable.
Or (similar to sentence in IANA section):
Although some existing network
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
can be made only in the context of the Label Stack Entry (LSE) or group of LS
Es
in the preceding label stack that characterizes the type of the PSH.
Any attempt to rely on the value in any other context is
unreliable.
-->
<t>
An MPLS packet consists of a label stack, an optional Post-Stack Header (PSH)
, and an optional embedded packet (in that order). Examples of
PSH include existing artifacts such as control words <xref target="RFC4385"/>
, BIER (Bit Index Explicit Replication) headers <xref target="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 Working Group. However, in the data plane, there are
very few clues regarding the PSH, and no clue as to the type of embedded very few clues regarding the PSH and no clue as to the type of embedded
packet; this information is communicated via other means, such as the packet; this information is communicated via other means, such as the
routing protocols that signal the labels in the stack. Nonetheless, routing protocols that signal the labels in the stack. Nonetheless,
in order to better handle an MPLS packet in the data plane, it is in order to better handle an MPLS packet in the data plane, it is
common practice for network equipment to "guess" the type of embedded common practice for network equipment to "guess" the type of embedded
packet. Such equipment may also need to process the PSH. packet. Such equipment may also need to process the PSH.
Both of these require parsing the data after the label Both of these require parsing the data after the label
stack. To do this, the "first nibble" (the top four bits of the stack. To do this, the "first nibble" (the top four bits of the
first octet following the label stack) is often used. Although some first octet following the label stack) is often used. Although some
existing network devices may use such a method, it needs to be existing network devices may use such a method, it needs to be
stressed that the correct interpretation of the Post-stack First Nibble stressed that the correct interpretation of the Post-stack First Nibble
(PFN) in a PSH can be made only in the context associated (PFN) in a PSH can be made only in the context associated
using the control or management plane with the Label Stack Element (LSE) or using the control or management plane with the Label Stack Entry (LSE) or gr
group oup
of LSEs in the preceding label stack that characterize the type of of LSEs in the preceding label stack that characterizes the type of
the PSH, and that any attempt to rely on the value in any other the PSH. Any attempt to rely on the value in any other
context is unreliable. Because the PFN value context is unreliable. Because the PFN value
should not be used to deduce the type of PSH by itself, and the space of PFN should not be used to deduce the type of PSH by itself and the space of PFN
values is limited, values is limited,
the re-use of PFN values, where that is possible, is encouraged.</t> the reuse of PFN values is encouraged when possible.</t>
<t> <t>
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 purposes:</t> nor are the assignments of values. This document serves four purposes:</t>
<ul spacing="normal"> <!-- [rfced] How may we update the text starting with "including..." to
improve clarity?
Original:
* To stress the importance that any MPLS packet not carrying plain
IPv4 or IPv6 packets contains a PSH, including any new version of
IP (Section 2.4).
Perhaps:
* To stress that any MPLS packet not carrying plain
IPv4 or IPv6 packets contains a PSH. This also applies to packets of
any new version of IP (see Section 2.4).
-->
<ul spacing="normal">
<li>To document the values already in use.</li> <li>To document the values already in use.</li>
<li>To provide a mechanism to document future assignments <li>To provide a mechanism to document future assignments through the
through the creation of a new IANA "Post-stack First Nibble registry", and creation of a new IANA "Post-Stack First Nibble" registry and
document the relationship describe the relationship between it and the IANA "IP Version Numbers" r
between it and the IANA IP Version Numbers <xref target="RFC2780"/>.</li> egistry
<xref target="RFC2780"/>.</li>
<li>Provide a method for tracking usage by requiring more detailed <li>Provide a method for tracking usage by requiring more detailed
documentation.</li> documentation.</li>
<li>To stress the importance that any MPLS packet not carrying <li>To stress the importance that any MPLS packet not carrying plain
plain IPv4 or IPv6 packets contains a PSH, including any new version of IP IPv4 or IPv6 packets contains a PSH, including any new version of IP
(<xref target="sect-2.3"/>).</li> (<xref target="sect-2.3"/>).</li>
</ul> </ul>
<!-- [rfced] The sentences below are from the last two paragraphs of Section 1.
In the first sentence, will readers understand what is meant by "the
heuristic"? Would it be helpful to add more context, like that included
in the second sentence?
Original:
Based on the analysis of load-balancing techniques in Section 2.1.1,
this document, in Section 2.1.1.1, introduces a requirement that
deprecates the use of the heuristic and recommends using a dedicated
label value for load balancing.
...
Furthermore, this document updates [RFC4928] by deprecating the
heuristic method for identifying the type of packet encapsulated in
MPLS.
Perhaps:
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
that deprecates the use of the heuristic method for identifying the type
of packet encapsulated in MPLS and recommends using a
dedicated label value for load balancing.
...
Furthermore, this document updates [RFC4928] by deprecating this
heuristic method.
-->
<t> <t>
Based on the analysis of load-balancing techniques in <xref target="sect-2.1. <xref target="sect-2.1.1"/> of this document includes an analysis of load-bal
1"/>, ancing techniques; based on this,
this document, in <xref target="sect-2.1.1.1"/>, introduces a requirement tha <xref target="sect-2.1.1.1"/> introduces a requirement that deprecates the us
t deprecates the use of the e of the
heuristic and recommends using a dedicated label value for load balancing. Th heuristic and recommends using a dedicated label value for load balancing. Th
e intent of both is for e intent is for
legacy routers to continue operating as they have, with no new problems legacy routers to continue operating as they have, with no new problems
introduced as a result of this document. However, new implementations introduced as a result of this document. However, new implementations
that follow this document enable a more robust network operation. that follow this document enable a more robust network operation.
</t> </t>
<t>Furthermore, this document updates <xref target="RFC4928"/> <t>Furthermore, this document updates <xref target="RFC4928"/>
by deprecating the heuristic method for identifying the type of packet by deprecating the heuristic method for identifying the type of packet
encapsulated in MPLS. This document clearly states that the type of encapsulated in MPLS. This document clearly states that the type of
encapsulated packet cannot be determined based on the PFN alone.</t> encapsulated packet cannot be determined based on the PFN alone.</t>
<section anchor="sect-1.1" numbered="true" toc="default"> <section anchor="req-lang" numbered="true" toc="default">
<name>Conventions and Definitions</name> <name>Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
they appear in all "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
capitals, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="definitions" numbered="true" toc="default">
<name>Definitions</name>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>MPLS packet:</dt> <dt>MPLS packet:</dt>
<dd> <dd>A packet whose Layer 2 header declares the type to be MPLS. For
<t> example, the Ethertype is 0x8847 or 0x8848 for Ethernet, and
one whose Layer 2 header declares the type to be MPLS. the Protocol field is 0x0281 or 0x0283 for PPP.</dd>
For example, for Ethernet the Ethertype is 0x8847 or 0x8848, and for PPP the
Protocol field is 0x0281 or 0x0283.
</t>
</dd>
<dt>Label Stack:</dt> <dt>Label Stack:</dt>
<dd> <dd>For an MPLS packet, all labels (four-octet fields) after the
<t> Layer 2 header, up to and including the label with the Bottom of
(of an MPLS packet) all labels (four-octet fields) Stack bit set <xref target="RFC3032" format="default"/>.</dd>
after the Layer 2 header, up to and including the label with the
Bottom of Stack bit set (<xref target="RFC3032" format="default"/>).
</t>
</dd>
<dt>Post-stack First Nibble (PFN):</dt> <dt>Post-stack First Nibble (PFN):</dt>
<dd> <dd>The most significant four bits of the first octet following the
<t> label stack.</dd>
the most significant four bits of the first
octet following the label stack.
</t>
</dd>
<dt>MPLS Payload:</dt> <dt>MPLS Payload:</dt>
<dd> <dd>All data after the label stack, including the PFN, an optional
<t> post-stack header, and the embedded packet.</dd>
all data after the label stack, including the PFN, an <dt>Post-Stack Header (PSH):</dt>
optional post-stack header, and the embedded packet. <dd>Optional field of interest to the egress Label Switching Router
</t> (LSR) (and possibly to transit LSRs). Examples include a control
</dd> word <xref target="RFC4385"/> <xref target="RFC8964"/> or an
<dt>Post-stack Header (PSH):</dt> associated channel <xref target="RFC4385"/> <xref
<dd> target="RFC5586"/> <xref target="RFC9546"/>. The PSH
<t> <bcp14>MUST</bcp14> indicate its length, so that a parser knows
optional field of interest to the egress Label Switching Router (LSR) (and p where the embedded packet starts.</dd>
ossibly to transit LSRs). Examples include a control
word <xref target="RFC4385"/>, <xref target="RFC8964"/> or an associated c
hannel <xref target="RFC4385"/>,
<xref target="RFC5586"/>, <xref target="RFC9546"/>. The PSH MUST indicate
its length,
so that a parser knows where the embedded packet starts.
</t>
</dd>
<dt>Embedded Packet:</dt> <dt>Embedded Packet:</dt>
<dd> <dd>A packet that follows immediately after the MPLS label
<t> stack and an optional PSH. The embedded packet could be an IPv4 or IP
an embedded packet follows immediately after the MPLS v6 packet, an
Label Stack and an optional PSH. That could be Ethernet packet (for Virtual Private LAN Service (VPLS) <xref target="
an IPv4 or IPv6 packet, an Ethernet packet (for RFC4761"
VPLS (<xref target="RFC4761" format="default"/>, <xref target="RFC4762" fo format="default"/> <xref target="RFC4762" format="default"/> or
rmat="default"/>) EVPN <xref target="RFC7432" format="default"/>), or some other type
or EVPN <xref target="RFC7432" format="default"/>), or some other type of Layer 2 frame <xref target="RFC4446" format="default"/>. </dd>
of Layer 2 frame <xref target="RFC4446" format="default"/>.
</t>
</dd>
<dt>Deprecation:</dt> <dt>Deprecation:</dt>
<dd> <dd>Regardless of how the deprecation is understood in other IETF
<t> documents, the interpretation in this document is that if a practice
regardless of how the deprecation is understood in other IETF document has been deprecated, that practice should not be included in new
s, implementations or deployed in new deployments.</dd>
the interpretation in this document is that if a practice has been dep
recated,
that practice should not be included in new implementations or deploye
d in new deployments.
</t>
</dd>
</dl> </dl>
</section> </section>
<!-- [rfced] Would you like to alphabetize the list of abbreviations in Section
1.3
("Abbreviations")? Or do you prefer the current order?
Similarly, would you like to alphabetize the terms in Section 1.2
("Defintions") or keep the current order?
-->
<section anchor="abbrev-sec" numbered="true" toc="default"> <section anchor="abbrev-sec" numbered="true" toc="default">
<name>Abbreviations</name> <name>Abbreviations</name>
<t>LSR: Label Switching Router</t>
<t>LSE: Label Stack Element</t> <dl spacing="normal" newline="false">
<t>PSH: Post-Stack Header</t> <dt>LSR:</dt><dd>Label Switching Router</dd>
<t>PFN: Post-stack First Nibble</t> <dt>LSE:</dt><dd>Label Stack Entry</dd>
<t>FAT: Flow-Aware Transport</t> <dt>PSH:</dt><dd>Post-Stack Header</dd>
<t>SPL: Special Purpose Label</t> <dt>PFN:</dt><dd>Post-stack First Nibble</dd>
<t>PW: Pseudowire</t> <dt>FAT:</dt><dd>Flow-Aware Transport</dd>
<t>MNA: MPLS Network Action</t> <dt>SPL:</dt><dd>Special-Purpose Label</dd>
<t>BIER: Bit-Indexed Explicit Replication</t> <dt>PW:</dt><dd>Pseudowire</dd>
<dt>MNA:</dt><dd>MPLS Network Action</dd>
<dt>BIER:</dt><dd>Bit Index Explicit Replication</dd>
</dl>
</section> </section>
<section anchor="sect-figs" numbered="true" toc="default"> <section anchor="sect-figs" numbered="true" toc="default">
<name>Reference Figures</name> <name>Reference Figures</name>
<t><xref target="mpls-packet-fig"/> echoes the format of MPLS packets as defined in <t><xref target="mpls-packet-fig"/> echoes the format of MPLS packets as defined in
<xref target="RFC3032"/> where TC indicates the Traffic Class field < xref target="RFC5462"/> <xref target="RFC3032"/> where TC indicates the Traffic Class field < xref target="RFC5462"/>
that replaced the EXP (Experimental Use) field, S is the Bottom-of-St ack flag, and TTL that replaced the EXP (Experimental Use) field, S is the Bottom of St ack flag, and TTL
is the Time to Live field.</t> is the Time to Live field.</t>
<figure anchor="mpls-packet-fig"> <figure anchor="mpls-packet-fig">
<name>Example of an MPLS Packet With Label Stack</name> <name>Example of an MPLS Packet with Label Stack</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
X | Layer 2 Header | | X | Layer 2 Header | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
TC S TTL TC S TTL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
Y | Label-1 | TC |0| TTL | | Y | Label-1 | TC |0| TTL | |
skipping to change at line 280 skipping to change at line 365
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end of PSH | | | end of PSH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| embedded packet | | | embedded packet | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
<xref target="mpls-packet-fig"/> shows an MPLS packet with Layer 2 header X a
nd a label stack <!-- [rfced] We updated this text as shown below. Specifically, we moved the
third sentence of the first paragraph to follow the list and updated "A."
to read "Example A:". Let us know any concerns.
Original:
Figure 1 shows an MPLS packet with Layer 2 header X and a label stack
Y ending with Label-n. Then, there are three examples of an MPLS Y ending with Label-n. Then, there are three examples of an MPLS
payload displayed in <xref target="examples-fig"/>. payload displayed in Figure 2. The complete MPLS packet thus would
The complete MPLS packet thus would consist of [X Y A], or [X Y B], or [X Y C consist of [X Y A], or [X Y B], or [X Y C].
].</t>
<t> A. The first payload is a bare IP packet, i.e., no PSH. The PFN in
A. The first payload is a bare IP packet, i.e., no PSH. The PFN in this cas this case overlaps with the IP version number.
e overlaps with the IP version number.</t>
<t>
B. The next payload is a bare non-IP packet; again, no PSH. The PFN 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 happens to be.</t> here is the first nibble of the payload, whatever it happens to be.
<t>
C. The last example is an MPLS Payload that starts with a PSH C. The last example is an MPLS Payload that starts with a PSH
followed by the embedded packet. Here, the embedded packet could be followed by the embedded packet. Here, the embedded packet could be
IP or non-IP.</t> IP or non-IP.
Updated:
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
MPLS payload:
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.
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
happens to be.
Example C: This example is an MPLS Payload that starts with a PSH
followed by the embedded packet. Here, the embedded packet could
be IP or non-IP.
Thus, the complete MPLS packet would consist of [X Y A], [X Y B], or
[X Y C].
-->
<xref target="mpls-packet-fig"/> shows an MPLS packet with a Layer 2 he
ader X and a label stack
Y ending with Label-n. <xref target="examples-fig"/> displays three examples
of an MPLS
payload:</t>
<dl spacing="normal" newline="false">
<dt>Example A:</dt><dd>The first payload is a bare IP packet, i.e., no PSH.
The
PFN in this case overlaps with the IP version number.</dd>
<dt>Example B:</dt><dd>The next payload is a bare non-IP packet; again, no
PSH.
The PFN here is the first nibble of the payload, whatever it happens to
be.</dd>
<dt>Example C: </dt><dd>This example is an MPLS Payload that starts with a
PSH
followed by the embedded packet. Here, the embedded packet could be IP
or non-IP.</dd>
</dl>
<t>Thus, the complete MPLS packet would consist of [X Y A], [X Y B], or [X
Y C].</t>
</section> </section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default"> <section anchor="sect-2" numbered="true" toc="default">
<name>Rationale</name> <name>Rationale</name>
<section anchor="sect-2.1" numbered="true" toc="default"> <section anchor="sect-2.1" numbered="true" toc="default">
<name>Why Look at the First Nibble</name> <name>Why Look at the First Nibble</name>
<t> <t>
An MPLS packet can contain one of many types of embedded packets. Three commo n types are:</t> An MPLS packet can contain one of many types of embedded packets. Three commo n types are:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>An IPv4 packet (whose IP header has version number 4).</li> <li>An IPv4 packet (whose IP header has version number 4).</li>
<li>An IPv6 packet (whose IP header has version number 6).</li> <li>An IPv6 packet (whose IP header has version number 6).</li>
<li>A Layer 2 Ethernet frame (i.e., not including the Preamble or the <li>A Layer 2 Ethernet frame (i.e., not including the Preamble or the
Start frame delimiter), starting with the destination MAC address.</li> Start frame delimiter), starting with the destination Media Access Contro l (MAC) address.</li>
</ol> </ol>
<t> <t>
Many other packet types are possible; in principle, any Layer 2 embedded packet is permissible. Many other packet types are possible; in principle, any Layer 2 embedded packet is permissible.
Indeed, at some points in time, packets of Point-to-Point Protocol, Frame Relay Indeed, at some points in time, packets of the Point-to-Point Protocol, Frame R
, elay,
and Asynchronous Transfer Mode protocols were reasonably common, and may become and Asynchronous Transfer Mode were reasonably common and may become so again.
so again.
</t> </t>
<t> <t>
In addition, there may be a PSH ahead of the embedded packet. 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 parsed . The value of PFN is considered to ensure that the PSH can be correctly parsed .
</t> </t>
<section anchor="sect-2.1.1" numbered="true" toc="default"> <section anchor="sect-2.1.1" numbered="true" toc="default">
<name>ECMP Load Balancing</name> <name>ECMP Load Balancing</name>
<!-- [rfced] For readability, may we update this list as follows?
Original:
There are four common ways to load balance an MPLS packet:
1. One can use the top label alone.
2. One can do better by using all of the non-SPLs (Special Purpose
Labels) [RFC7274] in the stack.
3. One can do even better by "divining" the type of embedded packet,
and using fields from the guessed header. The ramifications of
using this load-balancing technique are discussed in detail in
Section 2.1.1.1.
4. One can do best by using either an Entropy Label [RFC6790] or a
Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see
Section 2.1.1.1).
Perhaps:
There are four common ways to load balance an MPLS packet:
1. Use the top label alone.
2. Use all of the non-SPLs (Special Purpose
Labels) [RFC7274] in the stack. This is better than using the
top label alone.
3. Divine the type of embedded packet
and use fields from the guessed header. The ramifications of
using this load-balancing technique are discussed in detail in
Section 2.1.1.1. This way is better than the two ways above.
4. Use either an Entropy Label [RFC6790] or a
Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see
Section 2.1.1.1). This is the best way.
-->
<t> <t>
There are four common ways to load balance an MPLS packet:</t> There are four common ways to load balance an MPLS packet:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>One can use the top label alone.</li> <li>One can use the top label alone.</li>
<li>One can do better by using all of the non-SPLs (Special Purpose <li>One can do better by using all of the non-SPLs <xref target="RFC
Labels) <xref target="RFC7274"/> in the stack.</li> 7274"/> in the stack.</li>
<li>One can do even better by "divining" the type of embedded packet <li>One can do even better by "divining" the type of embedded packet
,
and using fields from the guessed header. The ramifications of using this load-balancing technique and using fields from the guessed header. The ramifications of using this load-balancing technique
are discussed in detail in <xref target="sect-2.1.1.1"/>.</li> are discussed in detail in <xref target="sect-2.1.1.1"/>.</li>
<li>One can do best by using either an Entropy Label <xref target="R FC6790" format="default"/> or a <li>One can do best by using either an Entropy Label <xref target="R FC6790" format="default"/> or a
Flow-Aware Transport (FAT) Pseudowire Label <xref target="RFC6391" format ="default"/> (see <xref target="sect-2.1.1.1" format="default"/>).</li> Flow-Aware Transport (FAT) Pseudowire Label <xref target="RFC6391" format ="default"/> (see <xref target="sect-2.1.1.1" format="default"/>).</li>
</ol> </ol>
<t> <t>
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 -- this 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. If, however, the embedded packet is better, but it may still be uneven. However, if the embedded packet
is an IP packet, then the combination of (&lt;source IP address&gt;, &lt;dest IP address&gt;, &lt;transport protocol&gt;, &lt;source port&gt;, and &lt;dest p ort&gt;) is an IP packet, then the combination of (&lt;source IP address&gt;, &lt;dest IP address&gt;, &lt;transport protocol&gt;, &lt;source port&gt;, and &lt;dest p ort&gt;)
from the IP header of the embedded packet forms an excellent basis from the IP header of the embedded packet forms an excellent basis
for load-balancing. This is what is typically used for load for load balancing. This is what is typically used for load balancing IP pac
balancing IP packets.</t> kets.</t>
<t> <t>
An MPLS packet doesn't, however, carry a payload type identifier. An MPLS packet doesn't, however, carry a payload type identifier.
There is a simple (but risky) heuristic that is commonly used to There is a simple (but risky) heuristic that is commonly used to
guess the type of the embedded packet. The first nibble, i.e., the guess the type of the embedded packet. The first nibble of an IP header, i.e
four most significant bits of the first octet, of an IP header ., the
four most significant bits of the first octet,
contains the IP version number. That, in turn, indicates where to find contains the IP version number. That, in turn, indicates where to find
the relevant fields for load-balancing. The heuristic goes roughly the relevant fields for load balancing. The heuristic goes roughly
as described in <xref target="sect-2.1.1.1"/>.</t> as described in <xref target="sect-2.1.1.1"/>.</t>
<section anchor="sect-2.1.1.1" numbered="true" toc="default"> <section anchor="sect-2.1.1.1" numbered="true" toc="default">
<name>Heuristic for ECMP Load Balancing</name> <name>Heuristic for ECMP Load Balancing</name>
<!-- [rfced] Would including some text to introduce the numbered list in
Section 2.1.1.1 be helpful? If so, please provide the text.
-->
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>If the PFN is 0x4 (0100b), treat the payload as an IPv4 packet , <li>If the PFN is 0x4 (0100b), treat the payload as an IPv4 packet ,
and find the relevant fields for load-balancing on that basis.</li> and find the relevant fields for load balancing on that basis.</li>
<li>If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet , <li>If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet ,
and find the relevant fields for load-balancing on that basis.</li> and find the relevant fields for load balancing on that basis.</li>
<li>If the PFN is anything else, the MPLS payload is not an IP <li>If the PFN is anything else, the MPLS payload is not an IP
packet; fall back to load-balancing using the label stack.</li> packet; fall back to load balancing using the label stack.</li>
</ol> </ol>
<t> <t>
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 <xref target="examples-fig"/>, A. However, this performs well in the case of example A in <xref target="examples-fig"/>. How
heuristic ever, this heuristic
can work very badly for non-IP packet as shown in <xref target="examples-fig" can work very badly for non-IP packet as shown in example B in <xref target="
/>, B. For example, if payload B is an examples-fig"/>. For example, if payload B is an
Ethernet frame, then the PFN is the first nibble of the Organizationally Uniq ue Identifier of the Ethernet frame, then the PFN is the first nibble of the Organizationally Uniq ue Identifier of the
destination MAC address, which can be 0x4 or 0x6, and if so would lead to the packet being treated as an IPv4 or IPv6 packet such destination MAC address, which can be 0x4 or 0x6. This would lead to the pack et being treated as an IPv4 or IPv6 packet such
that data at the offsets of specific relevant fields would be used as that data at the offsets of specific relevant fields would be used as
input to the load-balancing heuristic resulting in unpredictable load input to the load-balancing heuristic, resulting in unpredictable load
balancing. This behavior can happen to other balancing. This behavior can happen to other
types of non-IP payloads as well.</t> types of non-IP payloads as well.</t>
<t> <t>
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 <xref target="RFC4385" format="default"/>, a DetNet control word control word <xref target="RFC4385" format="default"/>, a Deterministic Netwo
<xref target="RFC8964" format="default"/>, rking (DetNet) control word <xref target="RFC8964" format="default"/>,
a Network Service Header <xref target="RFC8300"/>, or a BIER a Network Service Header (NSH) <xref target="RFC8300"/>, or a BIER
header <xref target="RFC8296" format="default"/>) where the PFN is not 0x4 or header <xref target="RFC8296" format="default"/>) where the PFN is not 0x4 or
0x6, to 0x6; this
explicitly prevent forwarding engines from confusing the MPLS payload explicitly prevents forwarding engines from confusing the MPLS payload
with an IP packet. <xref target="RFC8469" format="default"/> recommends the use of a control word with an IP packet. <xref target="RFC8469" format="default"/> recommends the use of a control word
when the embedded packet is an Ethernet frame. RFC 8469 was when the embedded packet is an Ethernet frame. <xref target="RFC8469" format ="default"/> was
published at the request of the operator community and the IEEE Registration Authority Committee published at the request of the operator community and the IEEE Registration Authority Committee
as a result of operational difficulties with pseudowires that did not as a result of operational difficulties with pseudowires that did not
contain the control word.</t> contain the control word.</t>
<t> <t>
It is RECOMMENDED that where load-balancing of MPLS Where load balancing of MPLS
packets is desired, the load-balancing mechanism uses the value of a dedicate packets is desired, it is <bcp14>RECOMMENDED</bcp14> that the load-balancing
d label, for example, mechanism use the value of a dedicated label, for example,
either an Entropy Label <xref target="RFC6790"/> or a FAT Pseudowire Label <x ref target="RFC6391"/>. either an Entropy Label <xref target="RFC6790"/> or a FAT Pseudowire Label <x ref target="RFC6391"/>.
Furthermore, the heuristic of guessing the type of the embedded packet, Furthermore, the heuristic of guessing the type of the embedded packet,
as discussed above, SHOULD NOT be used.</t> as discussed above, <bcp14>SHOULD NOT</bcp14> be used.</t>
<t> <t>
A consequence of the heuristic approach is that while legacy routers may A consequence of the heuristic approach is that while legacy routers may
look for a PFN of 0x4 <xref target="RFC0791"/> or 0x6 <xref target="RFC8200"/ >, no legacy router will look for a PFN of 0x4 <xref target="RFC0791"/> or 0x6 <xref target="RFC8200"/ >, no legacy router will
look for any other PFN, regardless of what future IP version numbers look for any other PFN for load-balancing purposes, regardless of what futur
will be, for load-balancing purposes. This means that the values 0x4 and e IP version numbers
will be. This means that the values 0x4 and
0x6 are used to (sometimes incorrectly) identify IPv4 and IPv6 0x6 are used to (sometimes incorrectly) identify IPv4 and IPv6
packets, but no other of PFN values will be used to identify IP packets, but no other PFN values will be used to identify IP
packets.</t> packets.</t>
<t>This document creates a new PFN Registry for all 16 possible values.</t> <t>This document creates a new registry for all 16 possible values (see <xref target="sect-3"/>).</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sect-2.1.2" numbered="true" toc="default"> <section anchor="sect-2.1.2" numbered="true" toc="default">
<name>Updates of RFC 4928</name> <name>Updates to RFC 4928</name>
<t>The text in RFC 4928 <xref target="RFC4928"/> concerning the first
nibble after the MPLS label stack has been updated by this document,
and the heuristic for snooping this nibble has been deprecated. <xref s
ection="3" sectionFormat="of" target="RFC4928"/> is updated as follows:</t>
<t> <t>OLD TEXT:</t>
The text in RFC 4928 <xref target="RFC4928"/> concerning the first nibble a
fter the MPLS
Label Stack has been updated by this document and
the heuristic for snooping this nibble has been deprecated.
RFC 4928 is now updated as follows:</t>
<t>OLD TEXT</t>
<blockquote> <blockquote>
<t> <t>It is <bcp14>REQUIRED</bcp14>, however, that applications
It is REQUIRED, however, that applications dependent upon in-order depend upon in-order packet delivery restrict the first nibble
packet delivery restrict the first nibble values to 0x0 and 0x1. values to 0x0 and 0x1. This will ensure that their traffic flows
This will ensure that their traffic flows will not be affected if will not be affected if some future routing equipment does similar
some future routing equipment does similar snooping on some future snooping on some future version(s) of IP.</t>
version(s) of IP.
</t>
</blockquote> </blockquote>
<t>NEW TEXT:</t> <t>NEW TEXT:</t>
<blockquote> <blockquote>
<t> <t>Network equipment <bcp14>MUST</bcp14> use a PSH (Post-Stack Header)
Network equipment MUST use a PSH with a PFN (Post-stack First Nibble) value that is neither 0x4 nor 0x6
(Post-Stack Header) with a PFN (Post-stack First Nibble) value in all cases where the MPLS payload is neither an IPv6 nor an IPv4
that is neither 0x4 nor 0x6 in all cases when the MPLS packet.</t>
payload is neither an IPv6 nor an IPv4 packet.
</t>
</blockquote> </blockquote>
<!-- <t>[RFC Ed.: Throughout the docuemnt, replace XXXX with the actual RFC num <t>The following requirement (discussed is <xref target="sect-2.1.1.1"/>) replac
ber assigned to this document and remove this note.]</t> --> es
paragraph 4 in <xref section="3" sectionFormat="of" target="RFC4928"
format="default"/> as follows:</t>
<t>
The requirement (see <xref target="sect-2.1.1.1"/>) replaces the paragraph 4
in Section 3 of RFC 4928 <xref target="RFC4928" format="default"/> as follows:</
t>
<t>OLD TEXT:</t> <t>OLD TEXT:</t>
<blockquote> <blockquote>
<t> <t>This behavior implies that if in the future an IP version is defined
This behavior implies that if in the future an IP version is defined with a v with a version number of 0x0 or 0x1, then equipment complying with this
ersion number of 0x0 or 0x1, BCP would be unable to look past one or more MPLS headers, and
then equipment complying with this BCP would be unable to look past one or mo loadsplit traffic from a single LSP across multiple paths based on a
re MPLS headers, hash of specific fields in the IPv0 or IPv1 headers. That is, IP
and load-split traffic from a single LSP across multiple paths based on a has traffic employing these version numbers would be safe from disturbances
h of specific fields in the IPv0 or IPv1 headers. caused by inappropriate loadsplitting, but would also not be able to
That is, IP traffic employing these version numbers would be safe from distur get the performance benefits.</t>
bances caused by inappropriate load-splitting,
but would also not be able to get the performance benefits.</t>
</blockquote> </blockquote>
<t>NEW TEXT:</t> <t>NEW TEXT:</t>
<blockquote> <blockquote>
<t> <t>The practice of deducing the payload type based on the PFN value is
The practice of deducing the payload type based on the PFN value deprecated to avoid inaccurate load balancing. This <bcp14>MUST
is deprecated to avoid inaccurate load balancing. This NOT</bcp14> be part of new implementations or deployments. This also means
MUST NOT be part of new implementations or that concerns about load balancing for future IP versions with a version
deployments. It also means that concerns about number of 0x0 or 0x1 are no longer relevant.</t>
load balancing for future IP versions with a version number of 0x0 </blockquote>
or 0x1 are no longer relevant.
</t>
</blockquote>
<t>END</t>
<t>Furthermore, the following text is appended to Section 1.1 of RFC 4928 <xr ef target="RFC4928"/>:</t> <t>Furthermore, the following text is appended to <xref section="1.1" section Format="of" target="RFC4928"/>:</t>
<t>NEW TEXT:</t> <t>NEW TEXT:</t>
<blockquote> <blockquote>
<t>PSH: Post-Stack Header</t> <dl spacing="normal" newline="false">
<t>PFN: Post-stack First Nibble</t> <dt>PSH:</dt><dd>Post-Stack Header</dd>
<dt>PFN:</dt><dd>Post-stack First Nibble</dd>
</dl>
</blockquote> </blockquote>
<t>END</t>
</section> </section>
<section anchor="sect-2.2" numbered="true" toc="default"> <section anchor="sect-2.2" numbered="true" toc="default">
<name>Why Create a Registry</name> <name>Why Create a Registry</name>
<!-- [rfced] Would it be helpful to update "Support for" to "The framework
for" in this sentence?
Original:
Support for MPLS Network Actions (MNAs) is described in
[I-D.ietf-mpls-mna-fwk] and is an enhancement to the MPLS
architecture.
Perhaps:
The framework for MPLS Network Actions (MNAs) is described in [RFC9789] and
is an enhancement to the MPLS architecture.
-->
<!-- [rfced] This sentence notes that the PFN value of 0x0 has two different
formats, but the IANA registry in Section 3 lists the value 0x0 three
times. Please review and let us know if any updates are needed.
Original:
This issue is described in section 3.6.1 of [I-D.ietf-mpls-mna-fwk]
and is further illustrated by the PFN value of 0x0 which has two
different formats depending on whether the PSH is a pseudowire
control word or a DetNet control word ...
-->
<t> <t>
Support for MPLS Network Actions (MNAs) is described in Support for MPLS Network Actions (MNAs) is described in
<xref target="I-D.ietf-mpls-mna-fwk"/> and is an enhancement to the MPLS <xref target="RFC9789"/> and is an enhancement to the MPLS
architecture. The use of post-stack data (PSD) to encode the MNA architecture. The use of Post-Stack Data (PSD) to encode the MNA
indicators and ancillary data is described in section 3.6 might place indicators and ancillary data (described in <xref section="3.6" sectionFormat
data in the PFN that could conflict with other uses of that nibble. ="of" target="RFC9789"/>) might place
This issue is described in section 3.6.1 of <xref target="I-D.ietf-mpls-mna-f data in the PFN, which could conflict with other uses of that nibble.
wk"/> This issue is described in <xref section="3.6.1" sectionFormat="of" target="R
and is further illustrated by the PFN value of 0x0 which has two FC9789"/>
and is further illustrated by the PFN value of 0x0, which has two
different formats depending on whether the PSH is a pseudowire different formats depending on whether the PSH is a pseudowire
control word or a DetNet control word: disambiguation requires the control word or a DetNet control word; disambiguation requires the
context of the service label. context of the service label.
</t> </t>
<t> <t>
With a registry, PSHs become easier to identify and parse; not needing any m With a registry, PSHs become easier to identify and parse. In addition, they
eans do not need a means
outside the data plane to interpret them correctly; and their outside the data plane to interpret them correctly, and their
semantics and usage are documented and referenced from the registry. semantics and usage are documented and referenced in the registry.
</t> </t>
</section> </section>
<section anchor="sect-2.3" numbered="true" toc="default"> <section anchor="sect-2.3" numbered="true" toc="default">
<name>IP Version Numbers versus Post-stack First Nibble Values</name> <name>IP Version Numbers Versus Post-Stack First Nibble Values</name>
<!-- [rfced] How may we clarify "leading to [RFC4928]"?
Original:
It was then discovered that
non-IP packets, misidentified as IP when the heuristic failed, were
being badly load balanced, leading to [RFC4928].
Perhaps:
It was then discovered that
non-IP packets, misidentified as IP when the heuristic failed, were
being badly load-balanced, leading to the scenario described in [RFC4928].
-->
<t> <t>
The use of the PFN stemmed from the desire to The use of the PFN stemmed from the desire to
heuristically identify IP packets for load-balancing purposes. It heuristically identify IP packets for load-balancing purposes. It
was then discovered that non-IP packets, misidentified as IP when the was then discovered that non-IP packets, misidentified as IP when the
heuristic failed, were being badly load balanced, leading to heuristic failed, were being badly load balanced, leading to
<xref target="RFC4928" format="default"/>. This situation may confuse some a s to the relationship <xref target="RFC4928" format="default"/>. This situation may confuse some a s to the relationship
between the Post-stack First Nibble Registry and the IP Version Numbers between the "Post-Stack First Nibble" registry and the "IP Version Numbers"
registry. These registries are quite different:</t> registry. These registries are quite different:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The IP Version Numbers registry's explicit purpose is to track IP <li>The explicit purpose of the "IP Version Numbers" registry is to trac k IP
version numbers in an IP header.</li> version numbers in an IP header.</li>
<li>The Post-stack First Nibble registry's purpose is to track PSH typ es.</li> <li>The purpose of the "Post-Stack First Nibble" registry is to track PSH types.</li>
</ol> </ol>
<t> <t>
The only intersection points between the two registries is for values The only intersection points between the two registries are the values
0x4 and 0x6 (for backward compatibility). 0x4 and 0x6 (for backward compatibility).
</t> </t>
</section> </section>
<section anchor="sect-2.5" numbered="true" toc="default"> <section anchor="sect-2.5" numbered="true" toc="default">
<name>Next Step to More Deterministic Load-balancing in MPLS Networks</n ame> <name>Next Step to More Deterministic Load Balancing in MPLS Networks</n ame>
<t>Network evolution is impossible to control, but it develops over a period of time determined by various factors.</t> <t>Network evolution is impossible to control, but it develops over a period of time determined by various factors.</t>
<t>This document discourages further proliferation of the implementations that c <t>This document discourages further proliferation of the implementations that c
ould lead to undesired effects affecting data flows. ould lead to undesired effects on data flows.
In doing so, it limits the scope of future protocol developments, and so helps t In doing so, it limits the scope of future protocol developments and thus helps
o ensure that future network evolution will be smoother.</t> to ensure that future network evolution will be smoother.</t>
<!-- [rfced] What does "it" refer to here?
Original:
It would assist with the progress toward a simpler, more coherent
system of MPLS data encapsulation if the use a PSH for non-IP
payloads encapsulated in MPLS was obsoleted.
Perhaps:
If the use a PSH for non-IP
payloads encapsulated in MPLS were obsoleted, this would assist with
the progress toward a simpler, more coherent
system of MPLS data encapsulation
Or:
Obsoleting the use a PSH for non-IP
payloads encapsulated in MPLS would assist with the progress toward a simpler
, more coherent
system of MPLS data encapsulation.
-->
<!-- [rfced] Please review "to load-balancing MPLS data flows". Should the
verb "load balance" be used instead of the adjective "load-balancing"? Or
is the current correct?
Original:
However, before that
can be done, it is important to collect sufficient evidence that
there are no marketed or deployed implementations using the heuristic
practice to load-balancing MPLS data flows.
Perhaps:
However, before that
can 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.
-->
<t>It would assist with the progress toward a simpler, more coherent system of M PLS data encapsulation if the use a PSH for <t>It would assist with the progress toward a simpler, more coherent system of M PLS data encapsulation if the use a PSH for
non-IP payloads encapsulated in MPLS was obsoleted. However, before that can be done, it is important to collect sufficient non-IP payloads encapsulated in MPLS was obsoleted. However, before that can be done, it is important to collect sufficient
evidence that there are no marketed or deployed implementations using the heuris tic practice to load-balancing MPLS data flows.</t> evidence that there are no marketed or deployed implementations using the heuris tic practice to load-balancing MPLS data flows.</t>
<t>The next step, therefore, toward more deterministic load-balancing in MPLS ne <t>Therefore, the next steps toward more deterministic load balancing in MPLS ne
tworks is to gradulally deprecate non-PSH MPLS encapsulations tworks are to gradually deprecate non-PSH MPLS encapsulations
of non-IP data, to cease using heuristic load-balancing, and to survey the avail of non-IP data, to cease using heuristic load balancing, and to survey the avail
able and deployed implementations to determine when obsoletion able and deployed implementations to determine when obsoletion
may be achieved.</t> may be achieved.</t>
</section> </section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default"> <section anchor="sect-3" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="sect-3.1" numbered="true" toc="default">
<name>The Post-stack First Nibble Registry</name>
<t> <t>
This document requests IANA to create a registry group called "Post-Stack Fir Per this document, IANA has created a registry group called "Post-Stack First
st Nibble Registry" Nibble"
that consists of a single registry called "Post-Stack First Nibble Registry". that consists of a single registry called the "Post-Stack First Nibble" regis
The registry should be created as shown in <xref target="iana-pfn-value-tbl"/ try.
>. The initial contents of the registry are shown in <xref target="iana-pfn-valu
The assignment policy for the registry is Standards Action <xref target="RFC8 e-tbl"/>.
126"/>. It is important to note, that The assignment policy is Standards Action <xref target="RFC8126"/>. It is imp
ortant to note that
the same PFN value can be used in more than one protocol. The correct interpr etation of the PFN in a PSH the same PFN value can be used in more than one protocol. The correct interpr etation of the PFN in a PSH
can be made only in the context of the LSE or a group of LSEs in the precedin can be made only in the context of the LSE or group of LSEs in the preceding
g label stack that characterize the type label stack that characterizes the type
of the PSH and, consequently, PFN. of the PSH and, consequently, the PFN.
</t> </t>
<!-- [rfced] We removed the expansion "Network Service Header" in Table 1 as
this is expanded previously in the document. If no objections, we will
ask IANA to update the "Post-Stack First Nibble" registry accordingly
prior to publication.
Link to registry: https://www.iana.org/assignments/post-stack-first-nibble
Original:
| NSH | 0x0 | NSH (Network Service Header)
| | | Base Header, payload
Current:
| NSH | 0x0 | NSH Base Header, paylod
-->
<table anchor="iana-pfn-value-tbl" align="center"> <table anchor="iana-pfn-value-tbl" align="center">
<name>Post-stack First Nibble Values</name> <name>Post-Stack First Nibble Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Protocol</th> <th align="left">Protocol</th>
<th align="left">Value</th> <th align="left">Value</th>
<th align="center">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">DetNet</td> <td align="left">DetNet</td>
<td align="left">0x0</td> <td align="left">0x0</td>
<td align="center">DetNet Control Word</td> <td align="left">DetNet Control Word</td>
<td align="left">RFC 8964</td> <td align="left"><xref target="RFC8964"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">NSH</td> <td align="left">NSH</td>
<td align="left">0x0</td> <td align="left">0x0</td>
<td align="center">NSH (Network Service Header) Base Header, paylo <td align="left">NSH Base Header, payload</td>
ad</td> <td align="left"><xref target="RFC8300"/></td>
<td align="left">RFC 8300</td>
</tr> </tr>
<tr> <tr>
<td align="left">PW</td> <td align="left">PW</td>
<td align="left">0x0</td> <td align="left">0x0</td>
<td align="center">PW Control Word</td> <td align="left">PW Control Word</td>
<td align="left">RFC 4385</td> <td align="left"><xref target="RFC4385"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">DetNet</td> <td align="left">DetNet</td>
<td align="left">0x1</td> <td align="left">0x1</td>
<td align="center">DetNet Associated Channel</td> <td align="left">DetNet Associated Channel</td>
<td align="left">RFC 9546</td> <td align="left"><xref target="RFC9546"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">MPLS</td> <td align="left">MPLS</td>
<td align="left">0x1</td> <td align="left">0x1</td>
<td align="center">MPLS Generic Associated Channel</td> <td align="left">MPLS Generic Associated Channel</td>
<td align="left">RFC 5586</td> <td align="left"><xref target="RFC5586"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">PW</td> <td align="left">PW</td>
<td align="left">0x1</td> <td align="left">0x1</td>
<td align="center">PW Associated Channel</td> <td align="left">PW Associated Channel</td>
<td align="left">RFC 4385</td> <td align="left"><xref target="RFC4385"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">NSH</td> <td align="left">NSH</td>
<td align="left">0x2</td> <td align="left">0x2</td>
<td align="center">NSH Base Header, OAM</td> <td align="left">NSH Base Header, OAM</td>
<td align="left">RFC 8300</td> <td align="left"><xref target="RFC8300"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"/> <td align="left"/>
<td align="left">0x3</td> <td align="left">0x3</td>
<td align="center">Unassigned</td> <td align="left">Unassigned</td>
<td align="left"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left"/> <td align="left"/>
<td align="left">0x4</td> <td align="left">0x4</td>
<td align="center">Reserved, not to be assigned</td> <td align="left">Reserved</td>
<td align="left"/> <td align="left">this document</td>
</tr> </tr>
<tr> <tr>
<td align="left">BIER</td> <td align="left">BIER</td>
<td align="left">0x5</td> <td align="left">0x5</td>
<td align="center">BIER Header</td> <td align="left">BIER Header</td>
<td align="left">RFC 8296</td> <td align="left"><xref target="RFC8296"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"/> <td align="left"/>
<td align="left">0x6</td> <td align="left">0x6</td>
<td align="center">Reserved, not to be assigned</td> <td align="left">Reserved</td>
<td align="left"/> <td align="left">this document</td>
</tr> </tr>
<tr> <tr>
<td align="left"/> <td align="left"/>
<td align="left">0x7 - 0xF</td> <td align="left">0x7 - 0xF</td>
<td align="center">Unassigned</td> <td align="left">Unassigned</td>
<td align="left"/> <td align="left"/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section>
</section> </section>
<section anchor="sec-sect" numbered="true" toc="default"> <section anchor="sec-sect" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
This document creates a new IANA registry for and specifies changes to the treat This document creates a new IANA registry for PFNs and specifies changes to the
ment in the data plane treatment of packets in the data plane
of packets based on the first nibble of data beyond the MPLS label stack. One in based on the first nibble of data beyond the MPLS label stack. One intent of th
tent of this is to reduce is is to reduce
or eliminate errors in determining whether a packet being transported by MPLS is or eliminate errors in determining whether or not a packet being transported by
IP or not. MPLS is IP.
While such errors have primarily caused unbalanced and, thus, inefficient multi- While such errors have primarily caused unbalanced, and thus inefficient, multip
pathing, athing,
they have the potential to cause more severe security problems. they have the potential to cause more severe security problems.
</t> </t>
<t> <t>
For general MPLS label stack security considerations, see <xref target="RFC 3032"/>. For general security considerations involving the MPLS label stack, see <xr ef target="RFC3032"/>.
</t> </t>
</section> </section>
<section anchor="Ack-sec" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>The authors express their appreciation and gratitude to Donald E. Eastl
ake 3rd for the review, insightful questions, and helpful comments.
Also, the authors are gateful to Amanda Baber for helping organize the IAN
A registry in clear and consise manner.</t>
<t>Eric Vyncke, John Scudder, Warren Kumari, Murray Kucherawy, and Gunter
Van de Velde provided helpful comments during IESG review.</t>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
FC.2119.xml"/> 119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8174.xml"/> 174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
FC.3032.xml"/> 032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4385.xml"/> 385.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8200.xml"/> 200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4928.xml"/> 928.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.6790.xml"/> 790.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8469.xml"/> 469.xml"/>
<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ce.RFC.8300.xml"/> --> 296.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8296.xml"/> 964.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.8964.xml"/> 391.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
FC.6391.xml"/> 791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.27
FC.0791.xml"/> 80.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2780. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54
xml"/> 62.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5462.
xml"/> <!-- draft-ietf-mpls-mna-fwk-15 - companion doc RFC 9789 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mp <reference anchor="RFC9789" target="https://www.rfc-editor.org/info/rfc9789">
ls-mna-fwk.xml"/> <front>
<title>MPLS Network Action (MNA) Framework</title>
<author initials="L." surname="Andersson" fullname="Loa Andersson">
<organization>Huawei Technologies</organization>
</author>
<author initials="S." surname="Bryant" fullname="Stewart Bryant">
<organization>University of Surrey 5GIC</organization>
</author>
<author initials="M." surname="Bocci" fullname="Matthew Bocci">
<organization>Nokia</organization>
</author>
<author initials="T." surname="Li" fullname="Tony Li">
<organization>Juniper Networks</organization>
</author>
<date month="May" year="2025" />
</front>
<seriesInfo name="RFC" value="9789"/>
<seriesInfo name="DOI" value="10.17487/RFC9789"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refere <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
nce.RFC.4364.xml"/> --> 761.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.4761.xml"/> 432.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.7432.xml"/> 446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4446.xml"/> 762.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.4762.xml"/> 586.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.5586.xml"/> 274.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
FC.7274.xml"/> 00.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300. 46.xml"/>
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9546. 26.xml"/>
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
</references> </references>
</references> </references>
<section anchor="Ack-sec" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors express their appreciation and gratitude to <contact
fullname="Donald E. Eastlake 3rd"/> for the review, insightful
questions, and helpful comments. Also, the authors are grateful to
<contact fullname="Amanda Baber"/> for helping organize the IANA
registry in a clear and concise manner.</t>
<t><contact fullname="Éric Vyncke"/>, <contact fullname="John
Scudder"/>, <contact fullname="Warren Kumari"/>, <contact
fullname="Murray Kucherawy"/>, and <contact fullname="Gunter Van de
Velde"/> provided helpful comments during IESG review.</t>
</section>
<!-- [rfced] Abbreviations
a) FYI - We updated the expansion for LSE as follows to align with the
expansion used in RFCs-to-be 9789 and 9791. Also, "Label Stack Element" has
not been used in published RFCs.
Original:
Label Stack Element
Updated:
Label Stack Entry
b) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Deterministic Networking (DetNet)
Virtual Private LAN Service (VPLS)
Media Access Control (MAC)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 110 change blocks. 
377 lines changed or deleted 674 lines changed or added

This html diff was produced by rfcdiff 1.48.