<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-mpls-1stnibble-13" number="9790" consensus="true" category="std" ipr="trust200902" obsoletes="" updates="4928" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">

<!-- xml2rfc v2v3 conversion 3.16.0 -->
  <!-- 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>
    <title abbrev="1st nibble">IANA abbrev="First Nibble Following Label Stack">IANA Registry and Processing Recommendations
    for the First Nibble Following a Label Stack</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-1stnibble-13"/> name="RFC" value="9790"/>
    <author initials="K." surname="Kompella" fullname="Kireeti Kompella">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>1133 Innovation Way</street>
          <street>Sunnyvale,  94089</street>
          <street>United
          <city>Sunnyvale</city> <region>CA</region> <code>94089</code>
          <country>United States of America</street> America</country>
        </postal>
        <email>kireeti.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Bryant" fullname="Stewart Bryant">
      <organization>University of Surrey 5GIC</organization>
        <address>
        <email>sb@stewartbryant.com</email>
        </address>
    </author>
    <author initials="M." surname="Bocci" fullname="Matthew Bocci">
      <organization>Nokia</organization>
        <address>
        <email>matthew.bocci@nokia.com</email>
        </address>
    </author>
    <author initials="G." surname="Mirsky" fullname="Greg Mirsky" role="editor">
      <organization>Ericsson</organization>
        <address>
        <email>gregimirsky@gmail.com</email>
        </address>
    </author>
    <author initials="L." surname="Andersson" fullname="Loa Andersson">
      <organization>Huawei Technologies</organization>
        <address>
        <email>loa@pi.nu</email>
        </address>
    </author>
    <author initials="J." surname="Dong" fullname="Jie Dong">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>
          <street>Beijing, 100095</street>
          <street>China</street>
          <city>Beijing</city> <code>100095</code>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <date year="2024"/>
    <workgroup>MPLS Working Group</workgroup> year="2025" month="May"/>
    <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>
      <t>
   This document creates a new IANA registry (called the
   Post-stack
   "Post-Stack First Nibble Nibble" registry) for the first nibble (4-bit field)
   immediately following an MPLS label stack. Furthermore, this document
   sets out
   presents some documentation requirements for registering new values, values
   and requirements that make making the processing of MPLS
   packets easier and more robust.
   </t>
<t>The relationship between the IANA IP Version Numbers (RFC 2780) "Post-Stack First Nibble" registry and the Post-stack First Nibble "IP Version Numbers" registry (RFC 2780)
is described in this document.</t>
<t>This document updates RFC 4928 by deprecating
   the heuristic method for identifying the type of packet encapsulated
   in MPLS.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
<!-- [rfced] Please clarify "in the context associated". Should this text
align more closely with a similar sentence in the IANA section?

Original:
   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 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.
-->
<t>
   An MPLS packet consists of a label stack, an optional "post-stack header" (PSH) Post-Stack Header (PSH), and an optional embedded packet (in that order).  Examples of
   PSH include existing artifacts such as Control Words control words <xref target="RFC4385"/>, BIER (Bit-Indexed (Bit Index Explicit Replication) headers <xref target="RFC8296"/>
   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 regarding the PSH, PSH and no clue as to the type of embedded
   packet; this information is communicated via other means, such as the
   routing protocols that signal the labels in the stack.  Nonetheless,
   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
   packet.  Such equipment may also need to process the PSH.
  Both of 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 label stack) is often used. 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 Entry (LSE) or group
    of LSEs in the preceding label stack that characterize characterizes the type of
    the PSH, and that any PSH. 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 itself, itself and the space of PFN values is limited,
    the re-use reuse of PFN values, where that is possible, values is encouraged.</t> encouraged when possible.</t>
      <t>
   The semantics and usage of the first nibble are not well documented,
   nor are the assignments of values.  This document serves four purposes:</t>
<!-- [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 provide a mechanism to document future assignments through the
        creation of a new IANA "Post-stack "Post-Stack First Nibble registry", Nibble" registry and document
        describe the relationship between it and the IANA IP "IP Version Numbers Numbers" registry
        <xref target="RFC2780"/>.</li>
        <li>Provide a method for tracking usage by requiring more detailed
        documentation.</li>
        <li>To stress the importance that any MPLS packet not carrying plain
        IPv4 or IPv6 packets contains a PSH, including any new version of IP
        (<xref target="sect-2.3"/>).</li>
      </ul>

            <t>

<!-- [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 <xref target="sect-2.1.1"/>, 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>
   <xref target="sect-2.1.1.1"/>, target="sect-2.1.1"/> of this document includes an analysis of load-balancing techniques; based on this,
   <xref target="sect-2.1.1.1"/> introduces a requirement that deprecates the use of the
   heuristic and recommends using a dedicated label value for load balancing. The intent of both is for
   legacy routers to continue operating as they have, with no new problems
   introduced as a result of this document.  However, new implementations
   that follow this document enable a more robust network operation.
   </t>
<t>Furthermore, this document updates <xref target="RFC4928"/>
   by deprecating the heuristic method for identifying the type of packet
   encapsulated in MPLS. This document clearly states that the type of
   encapsulated packet cannot be determined based on the PFN alone.</t>

         <section anchor="sect-1.1" anchor="req-lang" numbered="true" toc="default">
        <name>Conventions and Definitions</name>
           <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
   BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
	 </section>
      <section anchor="definitions" numbered="true" toc="default">
        <name>Definitions</name>

        <dl newline="false" spacing="normal">
          <dt>MPLS packet:</dt>
          <dd>
            <t>
    one
          <dd>A packet whose Layer 2 header declares the type to be MPLS.  For
          example, for Ethernet the Ethertype is 0x8847 or 0x8848, and 0x8848 for PPP Ethernet, and
          the Protocol field is 0x0281 or 0x0283.
            </t>
          </dd> 0x0283 for PPP.</dd>
          <dt>Label Stack:</dt>
          <dd>
            <t>
    (of
          <dd>For an MPLS packet) packet, all labels (four-octet fields) after the
          Layer 2 header, up to and including the label with the Bottom of
          Stack bit set (<xref <xref target="RFC3032" format="default"/>).
            </t>
          </dd> format="default"/>.</dd>
          <dt>Post-stack First Nibble (PFN):</dt>
          <dd>
            <t>
    the
          <dd>The most significant four bits of the first octet following the
          label stack.
            </t>
          </dd> stack.</dd>
          <dt>MPLS Payload:</dt>
          <dd>
            <t>
    all
          <dd>All data after the label stack, including the PFN, an optional
          post-stack header, and the embedded packet.
            </t>
          </dd>
          <dt>Post-stack packet.</dd>
          <dt>Post-Stack Header (PSH):</dt>
          <dd>
            <t>
    optional
          <dd>Optional field of interest to the egress Label Switching Router
          (LSR) (and possibly to transit LSRs).  Examples include a control
          word <xref target="RFC4385"/>, target="RFC4385"/> <xref target="RFC8964"/> or an
          associated channel <xref target="RFC4385"/>, target="RFC4385"/> <xref target="RFC5586"/>,
          target="RFC5586"/> <xref target="RFC9546"/>.  The PSH MUST
          <bcp14>MUST</bcp14> indicate its length, so that a parser knows
          where the embedded packet starts.
            </t>
          </dd> starts.</dd>
          <dt>Embedded Packet:</dt>
          <dd>
            <t>
    an embedded
          <dd>A packet that follows immediately after the MPLS
Label Stack label
          stack and an optional PSH.  That  The embedded packet could be an IPv4 or IPv6 packet, an
          Ethernet packet (for
      VPLS (<xref Virtual Private LAN Service (VPLS) <xref target="RFC4761" format="default"/>,
          format="default"/> <xref target="RFC4762" format="default"/>) format="default"/> or
          EVPN <xref target="RFC7432" format="default"/>), or some other type
          of Layer 2 frame <xref target="RFC4446" format="default"/>.
            </t> </dd>
          <dt>Deprecation:</dt>
          <dd>
          <t>
          regardless
          <dd>Regardless of how the deprecation is understood in other IETF
          documents, the interpretation in this document is that if a practice
          has been deprecated, that practice should not be included in new
          implementations or deployed in new deployments.
          </t>
          </dd> deployments.</dd>
        </dl>
        </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">
      <name>Abbreviations</name>
      <t>LSR:     Label

      <dl spacing="normal" newline="false">
	<dt>LSR:</dt><dd>Label Switching Router</t>
      <t>LSE:      Label Router</dd>
	<dt>LSE:</dt><dd>Label Stack Element</t>
      <t>PSH:      Post-Stack Header</t>
      <t>PFN:      Post-stack Entry</dd>
	<dt>PSH:</dt><dd>Post-Stack Header</dd>
	<dt>PFN:</dt><dd>Post-stack First Nibble</t>
      <t>FAT:       Flow-Aware Transport</t>
      <t>SPL:      Special Purpose Label</t>
      <t>PW:        Pseudowire</t>
      <t>MNA:      MPLS Nibble</dd>
	<dt>FAT:</dt><dd>Flow-Aware Transport</dd>
	<dt>SPL:</dt><dd>Special-Purpose Label</dd>
	<dt>PW:</dt><dd>Pseudowire</dd>
	<dt>MNA:</dt><dd>MPLS Network Action</t>
      <t>BIER:     Bit-Indexed Action</dd>
	<dt>BIER:</dt><dd>Bit Index Explicit Replication</t> Replication</dd>
      </dl>
     </section>

      <section anchor="sect-figs" numbered="true" toc="default">
        <name>Reference Figures</name>

        <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"/>
           that replaced the EXP (Experimental Use) field, S is the Bottom-of-Stack Bottom of Stack flag, and TTL
           is the Time to Live field.</t>

        <figure anchor="mpls-packet-fig">
          <name>Example of an MPLS Packet With with Label Stack</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
X |                        Layer 2 Header                         | |
  |                                                               | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
                                            TC   S       TTL
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
Y |             Label-1                   | TC  |0|      TTL      | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             Label-2                   | TC  |0|      TTL      | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               ...                     | TC  |0|      TTL      | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             Label-n                   | TC  |1|      TTL      | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
]]></artwork>
        </figure>
        <figure anchor="examples-fig">
        <name>Examples of an MPLS Packet Payload With and Without Post-Stack Header</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
A | (PFN) |                   IP header                           | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                             data                              | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...                                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        end of IP packet                       | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
B | (PFN) |                 non-IP packet                         | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                             data                              | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...                                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      end of non-IP packet                     | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
C | (PFN) |                      PSH                              | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                              PSH                              | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...                                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          end of PSH                           | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        embedded packet                        | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
]]></artwork>
        </figure>
        <t>
   <xref target="mpls-packet-fig"/>

<!-- [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
   payload displayed in <xref target="examples-fig"/>. Figure 2.  The complete MPLS packet thus would
   consist of [X Y A], or [X Y B], or [X Y C].</t>
        <t> C].

   A.  The first payload is a bare IP packet, i.e., no PSH.  The PFN in
   this case overlaps with the IP version number.</t>
        <t> number.

   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>
        <t> be.

   C.  The last 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.</t> 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 header 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 anchor="sect-2" numbered="true" toc="default">
      <name>Rationale</name>
      <section anchor="sect-2.1" numbered="true" toc="default">
        <name>Why Look at the First Nibble</name>
        <t>
   An MPLS packet can contain one of many types of embedded packets. Three common types are:</t>
        <ol spacing="normal" type="1">
          <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>A Layer 2 Ethernet frame (i.e., not including the Preamble or the
       Start frame delimiter), starting with the destination MAC Media Access Control (MAC) address.</li>
        </ol>
        <t>
 Many other packet types are possible; in principle, any Layer 2 embedded packet is permissible.
 Indeed, at some points in time, packets of the Point-to-Point Protocol, Frame Relay,
 and Asynchronous Transfer Mode protocols were reasonably common, common and may become so again.
 </t>
        <t>
   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.
   </t>

        <section anchor="sect-2.1.1" numbered="true" toc="default">

          <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>
   There are four common ways to load balance an MPLS packet:</t>
          <ol spacing="normal" type="1">
            <li>One can use the top label alone.</li>
            <li>One can do better by using all of the non-SPLs (Special Purpose Labels) <xref target="RFC7274"/> in the stack.</li>
            <li>One can do even better by "divining" the type of embedded packet, packet
       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>
            <li>One can do best by using either an Entropy Label <xref target="RFC6790" 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>
          </ol>
          <t>
   Load balancing based on just the top label means that all packets
   with that top label will go the same way -- this way, which is far from ideal.
   Load balancing based on the entire label stack (not including SPLs)
   is better, but it may still be uneven.  If, however,  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 port&gt;)
   from the IP header of the embedded packet forms an excellent basis
   for load-balancing. load balancing.  This is what is typically used for load balancing IP packets.</t>
          <t>
   An MPLS packet doesn't, however, carry a payload type identifier.
   There is a simple (but risky) heuristic that is commonly used to
   guess the type of the embedded packet.  The first nibble, nibble of an IP header, i.e., the
   four most significant bits of the first octet, of an IP header
   contains the IP version number.  That, in turn, indicates where to find
   the relevant fields for load-balancing. load balancing. The heuristic goes roughly
   as described in <xref target="sect-2.1.1.1"/>.</t>

          <section anchor="sect-2.1.1.1" numbered="true" toc="default">
            <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">
              <li>If the PFN is 0x4 (0100b), treat the payload as an IPv4 packet,
       and find the relevant fields for load-balancing load balancing on that basis.</li>
              <li>If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet,
       and find the relevant fields for load-balancing load balancing on that basis.</li>
              <li>If the PFN is anything else, the MPLS payload is not an IP
       packet; fall back to load-balancing load balancing using the label stack.</li>
            </ol>

            <t>
   This heuristic has been implemented in many (legacy) routers, routers and
   performs well in the case of example A in <xref target="examples-fig"/>, A. target="examples-fig"/>.  However, this heuristic
   can work very badly for non-IP packet as shown in example B in <xref target="examples-fig"/>, B. target="examples-fig"/>.  For example, if payload B is an
   Ethernet frame, then the PFN is the first nibble of the Organizationally Unique Identifier of the
   destination MAC address, which can be 0x4 or 0x6, and if so 0x6. This would lead to the packet being treated as an IPv4 or IPv6 packet such
   that data at the offsets of specific relevant fields would be used as
   input to the load-balancing heuristic heuristic, resulting in unpredictable load
   balancing. This behavior can happen to other
   types of non-IP payloads as well.</t>
<t>
   That, in turn, led to the idea of inserting a PSH (e.g., a pseudowire
   control word <xref target="RFC4385" format="default"/>, a DetNet Deterministic Networking (DetNet) control word <xref target="RFC8964" format="default"/>,
   a Network Service Header (NSH) <xref target="RFC8300"/>, or a BIER
   header <xref target="RFC8296" format="default"/>) where the PFN is not 0x4 or 0x6, to 0x6; this
   explicitly prevent prevents forwarding engines from confusing the MPLS payload
   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  <xref target="RFC8469" format="default"/> was
   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
   contain the control word.</t>

             <t>
   It is RECOMMENDED that where load-balancing
   Where load balancing of MPLS
   packets is desired, it is <bcp14>RECOMMENDED</bcp14> that the load-balancing mechanism uses use the value of a dedicated label, for example,
   either an Entropy Label <xref target="RFC6790"/> or a FAT Pseudowire Label <xref target="RFC6391"/>.
   Furthermore, the heuristic of guessing the type of the embedded packet,
   as discussed above, SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used.</t>
          <t>
   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 any other PFN, PFN for load-balancing purposes, regardless of what future IP version numbers
    will be, for load-balancing purposes. be. This means that the values 0x4 and
   0x6 are used to (sometimes incorrectly) identify IPv4 and IPv6
   packets, but no other of PFN values will be used to identify IP
   packets.</t>
  <t>This document creates a new PFN Registry registry for all 16 possible values.</t> values (see <xref target="sect-3"/>).</t>
          </section>
        </section>

      </section>

      <section anchor="sect-2.1.2" numbered="true" toc="default">
	<name>Updates of to RFC 4928</name>

        <t>
     The
        <t>The text in RFC 4928 <xref target="RFC4928"/> concerning the first
        nibble after the MPLS
     Label Stack label stack has been updated by this document document,
        and the heuristic for snooping this nibble has been deprecated.
     RFC 4928  <xref section="3" sectionFormat="of" target="RFC4928"/> is now updated as follows:</t>

     <t>OLD TEXT</t> TEXT:</t>
     <blockquote>
          <t>
    It
          <t>It is REQUIRED, <bcp14>REQUIRED</bcp14>, however, that applications dependent
          depend upon in-order packet delivery restrict the first nibble
          values to 0x0 and 0x1.  This will ensure that their traffic flows
          will not be affected if some future routing equipment does similar
          snooping on some future version(s) of IP.
   </t> IP.</t>
     </blockquote>

     <t>NEW TEXT:</t>
     <blockquote>
   <t>
     Network
       <t>Network equipment MUST <bcp14>MUST</bcp14> use a PSH (Post-Stack Header)
       with a PFN (Post-stack First Nibble) value that is neither 0x4 nor 0x6
       in all cases when where the MPLS payload is neither an IPv6 nor an IPv4 packet.
   </t>
       packet.</t>
     </blockquote>

<!--  <t>[RFC Ed.: Throughout the docuemnt, replace XXXX with the actual RFC number assigned to this document and remove this note.]</t> -->

          <t>
   The

<t>The following requirement (see (discussed is <xref target="sect-2.1.1.1"/>) replaces the
          paragraph 4 in Section 3 of RFC 4928 <xref section="3" sectionFormat="of" target="RFC4928"
          format="default"/> as follows:</t>

   <t>OLD TEXT:</t>
   <blockquote>
      <t>
   This
      <t>This behavior implies that if in the future an IP version is defined
      with a version number of 0x0 or 0x1, then equipment complying with this
      BCP would be unable to look past one or more MPLS headers, and load-split
      loadsplit traffic from a single LSP across multiple paths based on a
      hash of specific fields in the IPv0 or IPv1 headers.  That is, IP
      traffic employing these version numbers would be safe from disturbances
      caused by inappropriate load-splitting, loadsplitting, but would also not be able to
      get the performance benefits.</t>
   </blockquote>

   <t>NEW TEXT:</t>
   <blockquote>
<t>
   The
     <t>The practice of deducing the payload type based on the PFN value is
     deprecated to avoid inaccurate load balancing.  This
    MUST NOT <bcp14>MUST
     NOT</bcp14> be part of new implementations or deployments.  It  This also means
     that concerns about load balancing for future IP versions with a version
     number of 0x0 or 0x1 are no longer relevant.
  </t> relevant.</t>
   </blockquote>
  <t>END</t>

   <t>Furthermore, the following text is appended to Section 1.1 of RFC 4928 <xref section="1.1" sectionFormat="of" target="RFC4928"/>:</t>
   <t>NEW TEXT:</t>
   <blockquote>
      <t>PSH:      Post-Stack Header</t>
      <t>PFN:      Post-stack
     <dl spacing="normal" newline="false">
       <dt>PSH:</dt><dd>Post-Stack Header</dd>
       <dt>PFN:</dt><dd>Post-stack First Nibble</t> Nibble</dd>
     </dl>
   </blockquote>
        <t>END</t>

        </section>

      <section anchor="sect-2.2" numbered="true" toc="default">
        <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>
    Support for MPLS Network Actions (MNAs) is described in
   <xref target="I-D.ietf-mpls-mna-fwk"/> target="RFC9789"/> and is an enhancement to the MPLS
   architecture.  The use of post-stack data Post-Stack Data (PSD) to encode the MNA
   indicators and ancillary data is described (described in section 3.6 <xref section="3.6" sectionFormat="of" target="RFC9789"/>) might place
   data in the PFN that PFN, which could conflict with other uses of that nibble.
   This issue is described in section 3.6.1 of <xref target="I-D.ietf-mpls-mna-fwk"/> section="3.6.1" sectionFormat="of" target="RFC9789"/>
   and is further illustrated by the PFN value of 0x0 0x0, which has two
   different formats depending on whether the PSH is a pseudowire
   control word or a DetNet control word: word; disambiguation requires the
   context of the service label.
   </t>
   <t>
    With a registry, PSHs become easier to identify and parse; parse. In addition, they do not needing any need a means
   outside the data plane to interpret them correctly; correctly, and their
   semantics and usage are documented and referenced from in the registry.
   </t>
      </section>
      <section anchor="sect-2.3" numbered="true" toc="default">
        <name>IP Version Numbers versus Post-stack 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>
   The use of the PFN stemmed from the desire to
   heuristically identify IP packets for load-balancing purposes.  It
   was then discovered that non-IP packets, misidentified as IP when the
   heuristic failed, were being badly load balanced, leading to
   <xref target="RFC4928" format="default"/>.  This situation may confuse some as to the relationship
   between the Post-stack "Post-Stack First Nibble Registry Nibble" registry and the IP "IP Version Numbers Numbers"
   registry.  These registries are quite different:</t>
        <ol spacing="normal" type="1">
        <li>The IP Version Numbers registry's explicit purpose of the "IP Version Numbers" registry is to track IP
       version numbers in an IP header.</li>
          <li>The Post-stack First Nibble registry's purpose of the "Post-Stack First Nibble" registry is to track PSH types.</li>
        </ol>
        <t>
   The only intersection points between the two registries is for are the values
   0x4 and 0x6 (for backward compatibility).
   </t>
      </section>

      <section anchor="sect-2.5" numbered="true" toc="default">
        <name>Next Step to More Deterministic Load-balancing Load Balancing in MPLS Networks</name>

<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 could lead to undesired effects affecting on data flows.
In doing so, it limits the scope of future protocol developments, developments and so thus helps 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 MPLS 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
evidence that there are no marketed or deployed implementations using the heuristic practice to load-balancing MPLS data flows.</t>

<t>The

<t>Therefore, the next step, therefore, steps toward more deterministic load-balancing load balancing in MPLS networks is are to gradulally gradually deprecate non-PSH MPLS encapsulations
of non-IP data, to cease using heuristic load-balancing, load balancing, and to survey the available and deployed implementations to determine when obsoletion
may be achieved.</t>

        </section>

    </section>

    <section anchor="sect-3" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section anchor="sect-3.1" numbered="true" toc="default">
        <name>The Post-stack First Nibble Registry</name>

        <t>
   This document requests
   Per this document, IANA to create has created a registry group called "Post-Stack First Nibble Registry" Nibble"
   that consists of a single registry called the "Post-Stack First Nibble Registry". Nibble" registry.
   The initial contents of the registry should be created as are shown in <xref target="iana-pfn-value-tbl"/>.
   The assignment policy for the registry is Standards Action <xref target="RFC8126"/>. It is important to note, note that
   the same PFN value can be used in more than one protocol. The correct interpretation of the PFN in a PSH
   can be made only in the context of the LSE or a group of LSEs in the preceding label stack that characterize characterizes the type
   of the PSH and, consequently, the PFN.
        </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">
          <name>Post-stack
          <name>Post-Stack First Nibble Values</name> Registry</name>
          <thead>
            <tr>
              <th align="left">Protocol</th>
              <th align="left">Value</th>
              <th align="center">Description</th> align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">DetNet</td>
              <td align="left">0x0</td>
              <td align="center">DetNet align="left">DetNet Control Word</td>
              <td align="left">RFC 8964</td> align="left"><xref target="RFC8964"/></td>
            </tr>
            <tr>
              <td align="left">NSH</td>
              <td align="left">0x0</td>
              <td align="center">NSH (Network Service Header) align="left">NSH Base Header, payload</td>
              <td align="left">RFC 8300</td> align="left"><xref target="RFC8300"/></td>
            </tr>
            <tr>
              <td align="left">PW</td>
              <td align="left">0x0</td>
              <td align="center">PW align="left">PW Control Word</td>
              <td align="left">RFC 4385</td> align="left"><xref target="RFC4385"/></td>
            </tr>
            <tr>
              <td align="left">DetNet</td>
              <td align="left">0x1</td>
              <td align="center">DetNet align="left">DetNet Associated Channel</td>
              <td align="left">RFC 9546</td> align="left"><xref target="RFC9546"/></td>
            </tr>
            <tr>
              <td align="left">MPLS</td>
              <td align="left">0x1</td>
              <td align="center">MPLS align="left">MPLS Generic Associated Channel</td>
              <td align="left">RFC 5586</td> align="left"><xref target="RFC5586"/></td>
            </tr>
            <tr>
              <td align="left">PW</td>
              <td align="left">0x1</td>
              <td align="center">PW align="left">PW Associated Channel</td>
              <td align="left">RFC 4385</td> align="left"><xref target="RFC4385"/></td>
            </tr>
            <tr>
              <td align="left">NSH</td>
              <td align="left">0x2</td>
              <td align="center">NSH align="left">NSH Base Header, OAM</td>
              <td align="left">RFC 8300</td> align="left"><xref target="RFC8300"/></td>
            </tr>
            <tr>
              <td align="left"/>
              <td align="left">0x3</td>
              <td align="center">Unassigned</td> align="left">Unassigned</td>
              <td align="left"/>
            </tr>
            <tr>
              <td align="left"/>
              <td align="left">0x4</td>
              <td align="center">Reserved, not to be assigned</td> align="left">Reserved</td>
              <td align="left"/> align="left">this document</td>
            </tr>
            <tr>
              <td align="left">BIER</td>
              <td align="left">0x5</td>
              <td align="center">BIER align="left">BIER Header</td>
              <td align="left">RFC 8296</td> align="left"><xref target="RFC8296"/></td>
            </tr>
            <tr>
              <td align="left"/>
              <td align="left">0x6</td>
              <td align="center">Reserved, not to be assigned</td> align="left">Reserved</td>
              <td align="left"/> align="left">this document</td>
            </tr>
            <tr>
              <td align="left"/>
              <td align="left">0x7 - 0xF</td>
              <td align="center">Unassigned</td> align="left">Unassigned</td>
              <td align="left"/>
            </tr>
	  </tbody>
	</table>

    </section>
    </section>

    <section anchor="sec-sect" numbered="true" toc="default">
    <name>Security Considerations</name>
    <t>
This document creates a new IANA registry for PFNs and specifies changes to the treatment of packets in the data plane
of packets
 based on the first nibble of data beyond the MPLS label stack. One intent of this is to reduce
or eliminate errors in determining whether or not a packet being transported by MPLS is IP or not. IP.
While such errors have primarily caused unbalanced and, thus, inefficient multi-pathing, unbalanced, and thus inefficient, multipathing,
they have the potential to cause more severe security problems.
    </t>
    <t>
     For general security considerations involving the MPLS label stack security considerations, stack, see <xref target="RFC3032"/>.
     </t>
    </section>

     </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4385.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4928.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8469.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6391.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2780.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml"/>

<!-- draft-ietf-mpls-mna-fwk-15 - companion doc RFC 9789  -->
<reference anchor="RFC9789" target="https://www.rfc-editor.org/info/rfc9789">
   <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>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4761.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4762.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7274.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9546.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
    </references>

    <section anchor="Ack-sec" numbered="true" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors express their appreciation and gratitude to Donald <contact
      fullname="Donald E. Eastlake 3rd 3rd"/> for the review, insightful
      questions, and helpful comments.  Also, the authors are gateful grateful to Amanda Baber
      <contact fullname="Amanda Baber"/> for helping organize the IANA
      registry in a clear and consise concise manner.</t>
      <t>Eric Vyncke, John Scudder, Warren Kumari, Murray Kucherawy,
      <t><contact fullname="Éric Vyncke"/>, <contact fullname="John
      Scudder"/>, <contact fullname="Warren Kumari"/>, <contact
      fullname="Murray Kucherawy"/>, and Gunter <contact fullname="Gunter Van de Velde
      Velde"/> provided helpful comments during IESG review.</t>
      </section>

     </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4385.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4928.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8469.xml"/>

<!--       <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/> [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)
-->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6391.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2780.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mpls-mna-fwk.xml"/>
        </references>

      <references>
        <name>Informative References</name>

<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/> [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.
-->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4761.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4762.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7274.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9546.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
    </references>

  </back>

</rfc>