<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC3031 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml">
  <!ENTITY RFC3032 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml">
  <!ENTITY RFC3270 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3270.xml">
  <!ENTITY RFC3443 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3443.xml">
  <!ENTITY RFC8126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
  <!ENTITY RFC7942 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml">
  <!ENTITY RFC4385 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4385.xml">
  <!ENTITY RFC5462 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml">
  <!ENTITY RFC5586 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml">
  <!ENTITY RFC6291 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml">
  <!ENTITY RFC6790 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml">
  <!ENTITY RFC7325 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7325.xml">
  <!ENTITY RFC8664 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml">
  <!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
  <!ENTITY RFC9017 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9017.xml">
  <!ENTITY RFC9613 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9613.xml">
  <!ENTITY RFC9714 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9714.xml">
  <!ENTITY RFC9789 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9789.xml">
  <!ENTITY RFC9791 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9791.xml">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-mpls-mna-hdr-21" number="9994" category="std" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="false" symRefs="true" tocInclude="true" version="3" consensus="true">
  <!-- xml2rfc v2v3 conversion 3.12.0 -->
  <!-- Generated by id2xml 1.5.0 on 2020-03-06T17:47:05Z -->

    <front>
    <title abbrev="In-Stack MNA Sub-Stack">MPLS Network Action (MNA) Sub-Stack Specification including Including In-Stack Network Actions and Data</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-hdr-21"/> name="RFC" value="9994"/>
    <author fullname="Jaganbabu Rajamanickam" initials="J." role="editor" surname="Rajamanickam">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Canada</street>
          <country>Canada</country>
        </postal>
        <email>jrajaman@cisco.com</email>
      </address>
    </author>
    <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Canada</street>
          <country>Canada</country>
        </postal>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author fullname="Royi Zigler" initials="R." surname="Zigler">
      <organization>Broadcom</organization>
      <address>
        <email>royi.zigler@broadcom.com</email>
      </address>
    </author>

    <author fullname="Haoyu Song" initials="H." surname="Song">
      <organization>Futurewei Technologies</organization>
      <address>
        <email>haoyu.song@futurewei.com</email>
      </address>
    </author>

    <author fullname="Kireeti Kompella" initials="K." surname="Kompella">
      <organization>Juniper Networks</organization>
      <address>
     <postal>
          <street>United States</street>
          <country>United States</country>
        </postal>
        <email>kireeti.ietf@gmail.com</email>
      </address>
    </author>

    <date month="May" year="2026"/>
    <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>
      <t>
    This document specifies the MPLS Network Actions Action (MNA) sub-stack for carrying
    Network Actions and Ancillary Data (AD) in the MPLS label stack.  MNA can
    be used to influence packet forwarding packet-forwarding  decisions, carry additional
    Operations, Administration, and Maintenance (OAM) information in the MPLS
    packet
    packet, or perform user-defined operations.
      </t>
    </abstract>
    </front>
    <middle>
      <section anchor="sect-1" numbered="true" toc="default">
    <name>Introduction</name>
    <t>
      <xref target="RFC3032" format="default"/> defines the
      encoding of the MPLS label stack, the basic structure used
      to define a forwarding path. There are applications that
      require MPLS packets to perform special network actions and
      carry optional Ancillary Data (AD) that can affect the
      packet forwarding
      packet-forwarding decision or trigger Operations, Administration, and Maintenance (OAM)
      logging, for example example, as described in <xref target="RFC9791" format="default"/>.
      Ancillary Data
      AD can be used to carry additional
      information, for example, for network slice purpose, as an example purposes (see <xref target="RFC9791" format="default"/>. format="default"/>).
    </t>

    <t>
      The requirements for In-stack network action and In-stack data In-Stack Data (ISD) are described in
      <xref target="RFC9613" format="default"/>.
      </t>

          <t>
      This document defines the syntax
      and semantics of network actions and ancillary data AD encoded in an
      MPLS label stack.  In-stack actions and ancillary data AD are contained
      in a Network Action Sub-Stack (NAS), which is recognized by a new
      base Special Purpose Special-Purpose Label (bSPL).
      This document follows the
      framework specified in <xref target="RFC9789" format="default"/>.
      </t>

    </section>
    <section anchor="sect-2" numbered="true" toc="default">
      <name>Conventions Used in This Document</name>
      <section anchor="sect-2.1" numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
      "SHALL NOT", "SHOULD", "SHOULD 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" format="default"/> target="RFC2119"/> <xref
      target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    <section anchor="sect-2.2" numbered="true" toc="default">
      <name>Abbreviations</name>

      <t>
    The abbrevations abbreviations defined in <xref
    target="RFC9789" format="default"/> and <xref
    target="RFC9613" format="default"/> are
    used in this document.
      </t>
<!--[rfced] We had the following questions/comments regarding the
     abbreviations table:

a) We note that RFC 9789 uses "NSI" for "Network Action Sub-Stack
Indicator", while this document uses "NASI" for the same expansion.
Please let us know if any updates for uniformity are desired.

b) We have updated the following to match their use in the relevant
normative reference (with regard to capitalization, hyphenation,
pluralization, etc.).  Please let us know any objections:

Current:
Bottom of Stack (BoS)
Hop-by-Hop (HbH)
Ingress to Egress (I2E)
In-Stack Data (ISD)
base Special-Purpose Label (bSPL)
MPLS Network Action (MNA)
Time to Live (TTL)

c) We see NAS expanded as "Network Action Sub-Stack" in this document
and RFC 9789.  However, we see past uses in RFCs as "Network Action
Substack" (Substack is a closed compound).  Please review and let us
know if any updates are necessary.

d) The text above the table says:

Original:
The abbreviations defined in [RFC9789] and [RFC9613] are used in this
document.

As the table that follows then lists abbreviations from those
documents and many others, should this sentence be cut?  Or is the
meaning that some abbreviations in those documents that do not appear
in the table are also used?

Please review.

e) We note that RFC 9789 does not use the abbreviation "IHS".  How may
we update for accuracy?

Original:
      | IHS          | I2E, HbH, or Select         | [RFC9789],    |
      |              |                             | This document |
-->

      <table anchor="abbreviations">
    <name>Abbreviations</name>
    <thead>
      <tr>
        <th align='left'>Abbreviation</th>
        <th align='left'>Meaning</th>
        <th align='left'>Reference</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td>AD</td>
        <td>Ancillary Data</td>
        <td><xref target="RFC9613"/></td>
      </tr>
      <tr>
        <td>bSPL</td>
        <td>Base
        <td>base Special Purpose Label</td>
        <td><xref target="RFC9017"/></td>
      </tr>
      <tr>
        <td>BOS</td>
        <td>BoS</td>
        <td>Bottom Of of Stack</td>
        <td><xref target="RFC9789"/></td>
      </tr>
      <tr>
        <td>ECMP</td>
        <td>Equal Cost Multi-Path</td>
        <td>Equal-Cost Multipath</td>
        <td><xref target="RFC6790"/></td>
      </tr>
      <tr>
        <td>HBH</td>
        <td>Hop-By-Hop Scope</td>
        <td>HbH</td>
        <td>Hop-by-Hop</td>
        <td><xref target="RFC9789"/></td>
      </tr>
      <tr>
        <td>I2E</td>
        <td>Ingress-To-Egress Scope</td>
        <td>Ingress to Egress</td>
        <td><xref target="RFC9789"/></td>
      </tr>
      <tr>
        <td>IHS</td>
        <td>I2E, HBH, HbH, or Select Scope</td> Select</td>
        <td><xref target="RFC9789"/>, This document</td>
      </tr>
      <tr>
        <td>ISD</td>
        <td>In-stack
        <td>In-Stack Data</td>
        <td><xref target="RFC9613"/></td>
      </tr>
      <tr>
        <td>LSE</td>
        <td>Label Stack Entry</td>
        <td><xref target="RFC9789"/></td>
      </tr>

      <tr>
        <td>LSP</td>
        <td>Label Switched Path</td>
        <td><xref target="RFC3031"/></td>
      </tr>

      <tr>
        <td>MNA</td>
        <td>MPLS Network Actions</td> Action</td>
        <td><xref target="RFC9789"/></td>
      </tr>
      <tr>
        <td>NAI</td>
        <td>Network Action Indicator</td>
        <td><xref target="RFC9613"/></td>
      </tr>
      <tr>
        <td>NAL</td>
        <td>Network Action Length</td>
        <td>This document</td>
      </tr>
      <tr>
        <td>NAS</td>
        <td>Network Action Sub-Stack</td>
        <td><xref target="RFC9789"/></td>
      </tr>
      <tr>
        <td>NASI</td>
        <td>Network Action Sub-Stack Indicator</td>
        <td>This document</td>
      </tr>
      <tr>
        <td>NASL</td>
        <td>Network Action Sub-Stack Length</td>
        <td>This document</td>
      </tr>
      <tr>
        <td>OAM</td>
        <td>Operations, Administration, and Maintenance</td>
        <td> <xref target="RFC6291"/></td>
      </tr>

      <tr>
        <td>RLD</td>
        <td>Readable Label Depth </td>
        <td><xref target="RFC9789"/> </td>
      </tr>

      <tr>
        <td>TC</td>
        <td>Traffic Class</td>
        <td><xref target="RFC5462"/></td>
      </tr>
      <tr>
        <td>TTL</td>
        <td>Time To to Live</td>
        <td><xref target="RFC3032"/></td>
      </tr>
    </tbody>
      </table>
    </section>

    <section anchor="sect-2.3" numbered="true" toc="default">
      <name>Terminology</name>
        <t>
        The following terms are used in this document.
        </t>
        <dl newline="true">
        <dt>MPLS egress node:</dt> Egress Node:</dt>
        <dd>An MPLS edge node in its role in handling traffic as it leaves an MPLS domain <xref
    target="RFC3031" format="default"/>.</dd>
        <dt>MPLS ingress node:</dt> Ingress Node:</dt>
        <dd>An MPLS edge node in its role in handling traffic as it enters an MPLS domain <xref
    target="RFC3031" format="default"/>.</dd>
        <dt>MPLS domain:</dt> Domain:</dt>
        <dd> A contiguous set of nodes which that operate MPLS routing and forwarding and which that are also in one Routing or Administrative Domain <xref
    target="RFC3031" format="default"/>.</dd>
        <dt>Encapsulating Node:</dt>
        <dd> An encapsulating node is a A node that adds an a NAS to the label stack.</dd>
  </dl>
    </section>
  </section>

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

    <t>
      The MPLS Network Action Sub-Stack NAS is a set of Label Stack
      Entries (LSEs) that appear as part of an MPLS label stack and
      serve to encode information about the network actions that
      should be invoked for the packet. Multiple NASes may
      appear in a label stack and be placed as described in Section 5. <xref target="sect-3.1"/>.
    </t>

    <t>
This document specifies how network actions and their optional ancillary data AD are encoded as part of a NAS as a stack of LSEs. Mechanisms that allow sharing of ancillary data (AD) AD between multiple network actions encoded in the same NAS can be described in other documents and do not rely on any explicit provision in the encodings described in this document.

    </t>
    <t>
    This document defines new LSE formats beyond those in <xref target="RFC3032"/>
    that define behaviors or are processed in different ways to than MPLS labels as
    defined in <xref target="RFC3031"/>.
Three new LSE formats are defined to carry 7 bits of network action opcodes and varying
amounts of opcode-specific ancillary data. AD. Specifically, Format-B LSE carries up to 13 bits
of ancillary data AD in an LSE and LSE.  Format-C LSE carries up to 20 bits of ancillary data AD in an LSE.
Format-D LSE is used when additional ancillary data AD is needed by the opcodes in Format-B or Format-C LSEs.

    </t>
        <t>
As shown in an example in the <xref target="In-stack-Ext-Hdr-Example"/>,
the first LSE in an MNA Sub-Stack uses Format-A.
The second LSE uses Format-B and is followed by a Format-D LSE to carry additional data.
Next, there may be a Format-C LSE for an additional network action followed by another Format-D LSE for additional data.
You can add more
Additional Format-C and Format-D LSEs may be added as needed for additional network actions and data.

    </t>

      <figure anchor="In-stack-Ext-Hdr-Example" align="center">
        <name>An MNA Sub-Stack Encoding Example</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|      MNA-Label=bSPL                   | TC  |S|    TTL        |A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|   Opcode    |        13-bit Data      |R|IHS|S|  NASL |U| NAL |B
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|1|                    22-bit Data            |S|  8-bit Data   |D*
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|   Opcode    |        16-bit Data            |S|4b Data|U| NAL |C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|1|                    22-bit Data            |S|  8-bit Data   |D*
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|   Opcode    |        16-bit Data            |S|4b Data|U| NAL |C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--

Legend:

* Format-D LSE presence indicated by NAL greater than one
]]></artwork>
      </figure>
  </section>

  <section>
    <name>Label Stack Entry Formats</name>

    <t>
The NAS uses a variety of different formats of LSEs for
different purposes. This section describes the syntax of the
various formats while the overall structure of the NAS and the
semantics of the various LSEs are described in the sections below.
    </t>

    <section anchor="LSE-A">
      <name>LSE Format A: The MNA Sub-Stack Indicator</name>

      <t>
    LSE Format A is an LSE as described in <xref
    target="RFC3032"/> and <xref target="RFC5462"/>.
The label value is an IANA-assigned value (TBA) 4 for the MNA bSPL label
from the "Base Special-Purpose MPLS Label Values" IANA registry (see <xref target="sect-J13.6"/>) to
indicate the presence of an MNA in the packet and the beginning of an MNA
Sub-Stack in the label stack.
      </t>

      <figure>
        <name>LSE Format A: The MNA Sub-Stack Indicator</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MNA-Label=bSPL                   | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>

 <ul>
    <li>
      S

 <dl spacing="normal" newline="false">
      <dt>S (1 bit): The Bottom of Stack bit):</dt><dd>The BoS <xref target="RFC3032"/>.
      MUST
      <bcp14>MUST</bcp14> be set to 0 on transmitted packets.
      If a packet is received with an LSE containing the bSPL (value TBA) (4) and
      with S bit set to 1, then the packet MUST <bcp14>MUST</bcp14> be dropped.
    </li>
  </ul>
    </dd>
  </dl>
    </section>

    <section anchor="LSE-B">
      <name>LSE Format B: The initial opcode</name> Initial Opcode</name>

      <t>

<!--[rfced] Please consider if an update like the following makes sense:

Original:
This LSE can carry up to 13 bits of ancillary data.

Perhaps:
The Data field of this LSE can carry up to 13 bits of ancillary data.
-->

    LSE Format B is used to encode the first opcode in the NAS,
    plus a number of other fields about the NAS.
    This LSE can carry up to 13 bits of ancillary data. AD.
      </t>

      <figure>
        <name>LSE Format B: The initial opcode</name> Initial Opcode</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Opcode    |        13-bit Data      |R|IHS|S|  NASL |U| NAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>

      <ul>
    <li>

      <dl spacing="normal" newline="false">
    <dt>
      Opcode (7 bits): The bits):</dt><dd>The operation code for this LSE. See
      <xref target="Opcodes"/>.
    </li>
    <li>
    </dd>
    <dt>
      Data (13 bits): Opcode-specific ancillary data.
    </li>
    <li> bits):</dt><dd>Opcode-specific AD.
    </dd>
    <dt>
       R (1 bit): Reserved. This Reserved.</dt><dd>This bit MUST <bcp14>MUST</bcp14> be set to zero on transmission and ignored upon receipt.
    </li>
    <li>
    </dd>
    <dt>
      IHS (2 bits): The bits):</dt><dd>The scope of all the network actions in this NAS. See <xref target="Scope"/>.
    </li>
    <li>
    </dd>
    <dt>
      S (1 bit): The Bottom of Stack bit):</dt><dd>The BoS <xref target="RFC3032"/>.
      If the NASL value is non-zero, then the S bit MUST <bcp14>MUST</bcp14> be 0.
      If a packet is received with the S bit set to 1 and a non-zero NASL value,
      then the packet MUST <bcp14>MUST</bcp14> be dropped. The encapsulating node MUST <bcp14>MUST</bcp14> ensure that the S bit is set to 1 only in the Last LSE in the MPLS header.
    </li>
    <li>
    </dd>
    <dt>
      NASL (4 bits): The bits):</dt><dd>The Network Action Sub-Stack Length
      (NASL). Length. The number of Format C and Format D LSEs in the NAS, i.e., not
      including the leading Format A LSE and the Format B LSE.

    </li>
    <li>

    </dd>
    <dt>
      U (1 bit): Unknown bit):</dt><dd>Unknown Network Action Handling. See <xref target="UOH" />.
    </li>
    <li>
    </dd>
    <dt>
      NAL (3 bits): Network bits):</dt><dd>Network Action Length. The number of LSEs of
      additional data, encoded in Format D LSEs (<xref target="LSE-D"/>) target="LSE-D"/>),
      following this Format B LSE. The NAL value MUST <bcp14>MUST</bcp14> be less than or equal to the NASL value in the Format B LSE, if not LSE.  If not, the packet MUST <bcp14>MUST</bcp14> be dropped.
      A Format C LSE would be following when the NAL value is less than the NASL value.
    </li>
      </ul>
    </dd>
      </dl>
    </section>

    <section anchor="LSE-C">
      <name>LSE Format C: Subsequent opcodes</name> Opcodes</name>

      <t>
    LSE Format C is used to encode the subsequent opcodes in the NAS.
      </t>

      <figure>
        <name>LSE Format C: Subsequent opcodes</name> Opcodes</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Opcode    |        16-bit Data            |S|4b Data|U| NAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>

      <ul>
    <li>Opcode

      <dl spacing="normal" newline="false">
    <dt>Opcode (7 bits): The bits):</dt><dd>The operation code for this LSE. See
    <xref target="Opcodes"/>.</li>
    <li>Data target="Opcodes"/>.</dd>
    <dt>Data (16 bits + 4 bits): Opcode-specific ancillary data.</li>
    <li> bits):</dt><dd>Opcode-specific AD.</dd>
    <dt>
    S (1 bit): The Bottom of Stack bit):</dt><dd>The BoS <xref target="RFC3032"/>.
    If the NAL value is non-zero and if the S bit is set to 1, then the packet MUST <bcp14>MUST</bcp14> be dropped.
    If this is not the last LSE in the NAS and if the S bit is set to 1 1, then the packet MUST <bcp14>MUST</bcp14> be dropped.
    The encapsulating node MUST <bcp14>MUST</bcp14> ensure that the S bit is set to 1 only in the Last LSE.
    </li>
    <li>
    </dd>
    <dt>
      U (1 bit): Unknown bit):</dt><dd>Unknown Network Action Handling. See <xref target="UOH" />.
    </li>
    <li>
    </dd>
    <dt>
    NAL (3 bits): Network bits):</dt><dd>Network Action Length. The number of LSEs of
    additional data, encoded in Format D LSEs (<xref target="LSE-D"/>) following this Format C LSE.
    The NAL value MUST <bcp14>MUST</bcp14> be less than or equal to the NASL value in the Format B LSE, if not LSE.  If not, the packet MUST <bcp14>MUST</bcp14> be dropped.
    </li>
      </ul>
    </dd>
      </dl>
      <t>
        A Format A and a Format B LSE MUST <bcp14>MUST</bcp14> be present when a Format C LSE is carried in the NAS.
      </t>
    </section>

    <section anchor="LSE-D">
      <name>LSE Format D: Additional Data</name>

      <t>
    LSE Format D is used to encode additional data that
    did not fit in the LSE with the preceding opcode.
      </t>
      <figure>
        <name>LSE Format D: Additional Data</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|                    22-bit Data            |S|  8-bit Data   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>

      <ul>
    <li>

      <dl spacing="normal" newline="false">
    <dt>
      1 (1 bit): The bit):</dt><dd>The most significant bit MUST <bcp14>MUST</bcp14> be set. This
      prevents legacy implementations from misinterpreting this
      LSE as containing a special purpose label if the data begins with zeros.
    </li>
    <li>
    </dd>
    <dt>
    S (1 bit): The Bottom of Stack bit):</dt><dd>The BoS <xref target="RFC3032"/>.
    If this is not the last LSE for the Network Action based on the NAL value and if the S bit is
    set to 1 1, then the packet MUST <bcp14>MUST</bcp14> be dropped. If this is not the last LSE in the NAS and
    if the S bit is set to 1 1, then the packet MUST <bcp14>MUST</bcp14> be dropped. The encapsulating node MUST <bcp14>MUST</bcp14> ensure that the S bit is set to 1 only in the Last LSE.

    </li>
    <li>Data

    </dd>
    <dt>Data (22 bits + 8 bits): Opcode-specific ancillary data.</li>
      </ul> bits):</dt><dd>Opcode-specific AD.</dd>
      </dl>
      <t>
        A Format A and a Format B LSE MUST <bcp14>MUST</bcp14> be present when a Format D LSE is carried in the NAS.
      </t>
    </section>

  </section>

  <section anchor="sect-3.1" numbered="true" toc="default">
    <name>The MNA Sub-Stack</name>

    <t>
    The MNA Sub-Stack MUST <bcp14>MUST</bcp14> begin with a Format A LSE (<xref target="LSE-A"/>).
    The label value of the LSE contains the MNA bSPL
    (value TBA)
    (4) to indicate the presence of the MNA Sub-Stack.
    </t>
    <t>
      The TC and TTL values of the Format A LSE retain their semantics as
      defined in <xref target="RFC3032" format="default"/> and
      <xref target="RFC5462" format="default"/>. The TTL and TC values in the Format A LSE are copied from the forwarding label at the top of the label stack.

      The penultimate node on the path copies the TTL
      and TC values from the preceding LSE to the next LSE on the
      label stack, overwriting the TTL and TC values of the next LSE,
      as specified in Section 3.5 of <xref target="RFC3443" format="default"/> section="3.5"/> and Section 2.6.3 of <xref target="RFC3270" format="default"/> section="2.6.3"/>
      in the Uniform Mode LSPs.  If the node performing this copy is not
      aware of MNA, this could overwrite the values in the Format-A LSE of the NAS.
    </t>

    <t>
      The second LSE in a NAS MUST <bcp14>MUST</bcp14> be a Format B LSE (<xref
      target="LSE-B"/>). This LSE contains an initial opcode plus
      additional fields that describe the NAS.
    </t>

    <t>
      The Format B LSE (<xref target="LSE-B"/>) could optionally carry additional data in
      Format D (<xref target="LSE-D"/>) LSEs, up to the length encoded
      in the LSE's NAL value.
    </t>

    <t>
      A NAS MAY <bcp14>MAY</bcp14> contain more Format C (<xref target="LSE-C"/>) and
      Format D (<xref target="LSE-D"/>) LSEs, up to the length encoded
      in the NASL value. All Format D LSEs MUST <bcp14>MUST</bcp14> follow a Format C or Format B LSE
      and be included in that LSE's NAL value.
    </t>

    <section anchor="Opcodes">
      <name>Opcodes</name>
      <t>
    The opcode is a 7-bit field that indicates the semantics of
    its LSE. Several opcodes are assigned special semantics (<xref target="SpecialOpcodes"/>), others target="SpecialOpcodes"/>).  Other opcodes act as Network Action
    Indicators NAIs and are assigned through IANA (<xref target="Allocation"/> (see Sections <xref target="Allocation" format="counter"/> and <xref target="IANAOpcodes"/>). target="IANAOpcodes" format="counter"/>).
      </t>
    </section>

    <section anchor="Data">
      <name>Ancillary Data</name>

      <t>
   The data field carries opcode-specific data that is ancillary data AD
   for a network action.
   In the case of opcode 1, the data field carries
   Flag-Based Network Action Indicators without ancillary data. AD.
      </t>

      <t>
   The label value (most significant 20 bits) in one or more consecutive LSEs is commonly used
   for load balancing load-balancing data flows in an ECMP environment. Modifying the first 20 bits in an LSE might alter a
   packet's path and result in out-of-order delivery of packets belonging to a given flow.

   To maintain the stability of deployed services in ECMP environments
   that rely on label value information for load-balancing, care must be taken when
   encoding network action data in the given LSE. If the network action data may differ among
   packets in the same flow or change during forwarding across the MPLS network, it MUST NOT <bcp14>MUST NOT</bcp14> be placed in the most significant 20 bits
   of a Format B LSE
   (Section 4.2),
   (<xref target="LSE-B"/>), a Format C LSE (Section 4.3), (<xref target="LSE-C"/>), or a Format D LSE
   (Section 4.4).
   (<xref target="LSE-D"/>).  Thus, the available bits for data that can change by
   a transit node or differ among packets of the same flow
   in Format A and Format B LSEs are is 0, in a Format C LSE is 7
   (bits 20-22 and 25-28) 25-28), and in a Format D LSE is 11 (bits 20-22 and 24-31).
      </t>

      <t>
   Similarly, to preserve service stability,
   such data also MUST NOT <bcp14>MUST NOT</bcp14> be carried in
   the most significant 23 bits of these LSEs when the
   legacy implementation also uses the TC value, in addition to the label value, in all LSEs
   when computing ECMP decisions.
      </t>

      <t>
   The available mitigations for these problems are to use additional Format D
   LSEs to carry the data, data or to place the data in Post-Stack Data as
   described in <xref target="RFC9789"/>.
      </t>

   <t>
   In network deployments where it is known that a load-balancing of data flows is not used,
   or, otherwise,
   or if only the explicitly signaled entropy value is used, and it is certain
   that the load-balancing path selection will not be based on the label value of
   the LSEs, then the data in the label value of the LSEs in the ISD MAY <bcp14>MAY</bcp14> be
   mutable within the data flow without causing the out-of-order delivery of packets.
   </t>

    </section>

    <section anchor="Scope">
      <name>Scope</name>
      <t>
    The IHS field in the Format B LSE indicates the scope of all the NAIs encoded in the NAS.
    Scope defines which nodes along the MPLS path should perform the network
    actions found within the NAS.  The specific values of the IHS
    field are as follows:
      </t>
      <table anchor="In-stack-scope-tbl" align="center">
    <name>IHS Scope Values</name>
    <thead>
          <tr>
            <th align="left"> Bits </th>
            <th align="left"> Scope </th>
          </tr>
    </thead>
    <tbody>
          <tr>
            <td align="left">00</td>
            <td align="left">I2E</td>
          </tr>
          <tr>
            <td align="left">01</td>
            <td align="left">HBH</td> align="left">HbH</td>
          </tr>
          <tr>
            <td align="left">10</td>
            <td align="left">Select</td>
          </tr>
          <tr>
            <td align="left">11</td>
            <td align="left">Reserved for future use</td>
          </tr>
    </tbody>
      </table>

      <t>
      </t>

      <ul empty="true" spacing="normal">
    <li>
      Ingress To

      <dl spacing="normal" newline="false">
	<dt>Ingress to Egress (I2E) - The (I2E):</dt><dd>The Network Actions in this NAS MUST NOT <bcp14>MUST NOT</bcp14> be processed by any node except the egress node.
    </li>
    <li>
      Hop-By-Hop (HBH) - All node.</dd>
	<dt>Hop-by-Hop (HbH):</dt><dd>All nodes along the path MUST <bcp14>MUST</bcp14> process the NAS.
    </li>
    <li>
      Select - Only NAS.</dd>
	<dt>Select:</dt><dd>Only specific nodes along the path that brings bring NAS to the top of the stack will perform the action.
    </li>

      </ul> action.</dd>
      </dl>

      <t>
    A given NAS can only carry NAIs with the same scope (I2E/HBH/Select). (I2E/HbH/Select). To support multiple scopes for a single
    packet, multiple NASes MAY <bcp14>MAY</bcp14> be included in a single label stack.
      </t>
      <t>

<!--[rfced] Should Section 9.4 "Egress Node REsponsibilities" be
     referenced here instead of Section 9?

Original:
The egress node may receive a NAS at the top of the label stack as
discussed in Section 9.

Perhaps:
The egress node may receive a NAS at the top of the label stack as
discussed in Section 9.4.
-->

    The egress node is included in the HBH HbH scope. This implies
    that the penultimate node MUST NOT <bcp14>MUST NOT</bcp14> remove a HBH an HbH NAS. The
    egress node may receive a NAS at the top of the label stack as discussed in <xref target="sect-J12.1a "/>.
      </t>
      <t>
    An I2E scope NAS, if present, MUST <bcp14>MUST</bcp14> be encoded after any HBH HbH or Select-scope
    NASes. This makes it easier for the transit nodes to process a
    NAS with HBH HbH or Select scope.
      </t>
      <t>
    If a packet is received with the IHS scope set to "Reserved for future use", the packet is processed based on the U bit in the Format B LSE in the NAS.
      </t>

    </section>

    <section anchor="UOH">
      <name>Unknown Network Action Handling</name>

      <t>
    The Unknown Network Action Handling (U) field in a Format B LSE
    (<xref target="LSE-B"/>) and Format C LSE (<xref target="LSE-C"/>) is a 1-bit value that defines the action to
    be taken by a node that does not understand an action within
    the NAS. The different types of Unknown Network Action
    Handling actions are defined below.
      </t>

      <table anchor="UOH-tbl" align="center">
    <name>Unknown Network Action Handling</name>
    <thead>
          <tr>
            <th align="left"> Bit </th>
            <th align="left"> Action </th>
          </tr>
    </thead>
    <tbody>
          <tr>
            <td align="left">0</td>
            <td align="left">Skip to the next NA </td>
          </tr>
          <tr>
            <td align="left">1</td>
            <td align="left">Drop the packet</td>
          </tr>
    </tbody>
      </table>

   <t>
   When a packet with an unknown Unknown Network Action Handling is dropped, the node should maintain a local counter for this event, event and may send a rate-limited notification to the operator.
   </t>

    </section>

    <section anchor="Ordering">
      <name>Ordering</name>

      <t>
   The network actions encoded in the NAS MUST <bcp14>MUST</bcp14> be processed in the order
   that they appear in the NAS, from the top of the NAS to the bottom.
   NAIs encoded as flags (see <xref target="sect-J5.2b" />) MUST <bcp14>MUST</bcp14> be processed from the
   most significant bit to the least significant bit.  If a label stack
   contains multiple NASes, they MUST <bcp14>MUST</bcp14> be processed in the order that
   they appear in the label stack, subject to the restrictions in
   <xref target="Placement" />.
      </t>

    </section>

  </section>

  <section anchor="SpecialOpcodes" numbered="true" toc="default">
    <name>Special Opcodes</name>
    <t>
    Below are the special opcodes defined to build a basic In-stack MNA solution and has been assigned through in the "Network Action Opcodes" IANA registry (<xref (see <xref target="IANAOpcodes"/>).
    In the future, additional special opcodes can may be defined and their code-points code points assigned from the "Network Action Opcodes" IANA registry (<xref target="IANAOpcodes"/>). this registry.
    </t>
    <section>
      <name>bSPL Protection</name>

      <t>
    Opcode: 0
      </t>
      <t>
    Purpose: Legacy
      <dl spacing="normal" newline="false">
	<dt>Opcode:</dt><dd>0</dd>
	<dt>Purpose:</dt><dd>Legacy implementations may scan the label stack
	looking for bSPL values. As long as the opcode field is non-zero, an
	LSE cannot be misinterpreted as containing a bSPL. Opcode Therefore, opcode 0 is therefore
	reserved and not to be used.
      </t> used.</dd>
      </dl>
    </section>

    <section anchor="sect-J5.2b" numbered="true" toc="default">
      <name>Flag-Based NAIs without Without AD</name>
      <t>
    Opcode: 1
      </t>
      <t>
    Purpose: This
      <dl spacing="normal" newline="false">
	<dt>Opcode:</dt><dd>1</dd>
	<dt>Purpose:</dt><dd>This opcode is used for Network actions that do
	not require Ancillary Data. AD. A single flag can be used to indicate each
	of these network actions.
      </t>
      <t>
    LSE Formats: B, actions.</dd>
	<dt>LSE Formats:</dt><dd>B, C, D
      </t>
      <t>
    Data: The D</dd>
	<dt>Data:</dt><dd>The data field carries Network Action Indicators, NAIs, which
    should be evaluated from the most significant bit to the least
    significant bit.
    If this opcode is used with LSE Format B only, then up to 13 flags may be carried.
    If this opcode is used with LSE Format C only, then up to 20 flags may be carried.
    Format D LSEs can be used with format C LSEs to encode more than 20 flags.
    Flags are assigned from the "Network Action Flags
    Without Ancillary Data" registry (<xref
    target="IANAFlags"/>). If flags need to be evaluated in a
    different order, multiple LSEs using this opcode may be used
    to specify the requested order.
    The Flag-Based Network Action Indicators MUST NAIs <bcp14>MUST</bcp14> follow the procedure for data specified in Section 5.2.
      </t>

      <t>
    Scope: This <xref target="Data"/>.</dd>
    <dt>Scope:</dt><dd>This opcode can be used with any scope.
      </t> scope.</dd>
      </dl>
    </section>

    <section anchor="sect-J5.2c" numbered="true" toc="default">
      <name>No-Operation Opcode</name>

      <t>
    Opcode: 2
      </t>
      <t>
    Purpose: This
      <dl spacing="normal" newline="false">
	<dt>Opcode:</dt><dd>2</dd>
	<dt>Purpose:</dt><dd>This opcode is used to indicate that this opcode it
	does not perform any Network Action and MUST <bcp14>MUST</bcp14> be skipped.
      </t>

      <t>
    LSE Format: B
      </t>

      <t>
    Scope: Any
	skipped.</dd>
	<dt>LSE Format:</dt><dd>B</dd>
	<dt>Scope:</dt><dd>Any scope value may be set and MUST <bcp14>MUST</bcp14> be ignored.
      </t> ignored.</dd>
      </dl>

    </section>

    <section anchor="sect-J5.2g" numbered="true" toc="default">
      <name>Extension Opcode</name>

      <t>
    Opcode: 127
      </t>
      <t>
    Purpose: This
      <dl spacing="normal" newline="false">
	<dt>Opcode:</dt><dd>127</dd>
	<dt>Purpose:</dt><dd>This opcode is used to extend the current opcode
	range beyond 127 in the future. If this opcode is not supported, then
	the packet with the opcode 127 MUST <bcp14>MUST</bcp14> be dropped
	regardless of the setting of the U bit.  Use of this opcode is outside
	the scope of this document.
     </t> document.</dd>
      </dl>

    </section>

  </section>

  <section anchor="Placement" numbered="true" toc="default">
    <name>NAS placement Placement in the Label Stack</name>

    <t>
   The node adding a NAS to the label stack places a copy of the NAS
   where the relevant nodes can read it.  Each downstream node along the
   path has a Readable Label Depth (RLD). If the NAS is to be processed
   by a downstream MNA-capable node, then the entire NAS MUST <bcp14>MUST</bcp14> be placed
   so that it is within RLD by the time the packet reaches the
   downstream MNA-capable node.
   The RLD of the downstream MNA-capable node MUST <bcp14>MUST</bcp14> be learned as described in Section 2.3.1 of <xref target="RFC9789"/>. target="RFC9789" section="2.3.1"/>.

    </t>

    <t>
   If the label stack is deep, several copies of the NAS may need to be
   encoded in the label stack.
    </t>

    <t>
   For a NAS with HBH HbH scope, every node will process the top copy of
   the NAS, but NAS.  However, the NAS MUST NOT <bcp14>MUST NOT</bcp14> appear at the top of the stack at any
   MNA-incapable node on the path, path that is ensured by the encapsulating node using the node capability, as described in <xref target="Signaling"/>.
    </t>

    <t>
   A NAS MUST NOT <bcp14>MUST NOT</bcp14> appear at the top of the stack after popping the forwarding label on an MNA-incapable node on the path.
    </t>

   <t>
   The behavior of a node behaviour, where a NAS with I2E and HBH HbH scopes is also removed along with popping the forwarding label on a PHP node, node is outside the scope of this document.
    </t>

    <t>

<!--[rfced] Please clarify the antecedent of "it" in the following
     sentence:

Original:
For a NAS with Select scope, it is processed by the node that brings
it to the top of stack (for example, in the case of using MPLS label
pop operation in Segment Routing) and then the NAS is removed from the
stack.
-->

    <t>
   For a NAS with Select scope, it is processed by the node that
   brings it to the top of the stack (for example, in the case of using
   MPLS label pop operation in Segment Routing); then, the NAS is removed from
   the stack. The select-scoped NAS needs to be inserted after the forwarding label
   and before the next forwarding label. It could be inserted before or after a HBH an HbH NAS.
   Note that the case of a NAS with Select scope with an MPLS label swap operation (for example, with RSVP Traffic Engineering RSVP-TE LSPs) is for future study.
    </t>

    <t>
   For I2E scope, only one copy of the NAS needs to be added at the bottom of the stack.
    </t>

    <t>
   Transit, non-penultimate nodes
   A transit node that pop is not the penultimate node that pops a forwarding label and expose exposes a copy of a NAS MUST <bcp14>MUST</bcp14> remove it. that NAS.
    </t>

   <t>
   An MNA-capable node performing Penultimate Hop Popping (PHP) that pops the forwarding label with only
   the NAS(es) remaining on the stack MUST NOT <bcp14>MUST NOT</bcp14> remove the NAS(es). Instead, it forwards the packet with the NAS(es) at
   the top of the stack to the next node.
   Note that the behavior of the PHP node, as defined in <xref target="RFC3270"/> for TC processing, processing and as defined in
   <xref target="RFC3443"/> for TTL processing, is not modified regardless of whether the PHP node supports MNA.
   </t>

   <t>
   The node that receives the NAS at the top of the label stack MUST <bcp14>MUST</bcp14> process and remove it.
   </t>

  <section anchor="ActionsWhenPushingLabels" numbered="true" toc="default">
    <name>Actions when When Pushing Labels</name>
    <t>
    An MNA-capable node may need to push additional labels as well as push new network actions onto a received packet.
    </t>

    <t>
    While pushing additional labels on to onto the label stack of the received packet, the MNA-capable node MUST <bcp14>MUST</bcp14>
    verify that the entire top-most topmost NAS with HBH HbH scope is still within the RLD of the downstream MNA-capable nodes.
    If required, the MNA-capable node MAY <bcp14>MAY</bcp14> create a copy of the top-most topmost NAS with HBH HbH scope and insert it within the RLD of the downstream MNA-capable nodes on the label stack.
    </t>

    <t>
    When an MNA-capable node needs to push a new NAS with HBH HbH scope on to a received packet that already has a NAS with HBH HbH scope,
    it SHOULD <bcp14>SHOULD</bcp14> copy (and merge) the network actions (including their Ancillary Data) AD) from the received top-most topmost NAS with HBH HbH
    scope in the new NAS with HBH HbH scope. The new NAS MUST <bcp14>MUST</bcp14> be placed within the RLD of the downstream MNA-capable nodes.
    This behavior can be based on local policy.
    </t>

    <t>
    The new network actions added MUST NOT <bcp14>MUST NOT</bcp14> conflict with the network actions in the received NAS with HBH HbH scope.
    The mechanism to resolve such conflicts depend depends on the network actions and can be based on local policy.
    The MNA-capable node that pushes entries MUST <bcp14>MUST</bcp14> understand
    any network actions which that it is pushing which that may result in a conflict, conflict and
    MUST
    <bcp14>MUST</bcp14> resolve any conflicts between new and received network actions.  In the
    usual case of a conflict of duplicating a network action, the definition of
    a network action MUST <bcp14>MUST</bcp14> give guidance on conflict resolution.
    </t>

  </section>
  </section>

  <section anchor="Signaling" numbered="true" toc="default">
    <name>Node Capability Signaling</name>

    <t>
    The encapsulating node MUST <bcp14>MUST</bcp14> make sure that the NAS can be processed by the transit and egress nodes.
    In addition, the encapsulated packet MUST NOT <bcp14>MUST NOT</bcp14> exceed the path MTU as described in <xref target="RFC3032"/>.
    </t>

    <ul>

      <li>
    The node responsible for selecting a path through the MPLS network needs to know and consider the
    MNA-capabilities and RLD of the transit nodes, and nodes as well as the MNA-capabilities of the egress node as
    described in Section 2.3 of <xref target="RFC9789"/>. target="RFC9789" section="2.3"/>.
      </li>

      <li>
    Information about the capabilities of the nodes may be configured, collected through management protocols, or distributed by control protocols (such as advertising by routing protocols).
      </li>

<!--[rfced] This sentence is complex and difficult to follow on a
     quick read.  Please consider rephrasing:

Original:
   *  The mechanisms by which the capabilities of the nodes are known by
      the node responsible for selecting a path through the MPLS network
      are out of scope for this document.

-->

      <li>
    The mechanisms by which the capabilities of the nodes are known by the node responsible for selecting a path through the MPLS network are  out of scope for this document.
      </li>

     <li>
    In the case of MPLS Segment Routing over MPLS (SR-MPLS), as well as the
    RLD, the path computation system needs to know the MSD Maximum SID Depth (MSD) <xref target="RFC8664"/>
    that can be imposed at the ingress node of a given SR path.

<!--[rfced] Please let rephrase "that can be ready by the
     MNA-processing nodes in the path".  Should this be "that can be
     made ready"?

Original:
This ensures that the label stack depth of a computed path does not
exceed the maximum number of labels (i.e., MSD) the node is capable of
imposing and the maximum number of labels that can be read by the
MNA-processing nodes in the path.
-->
    This
    ensures that the label stack depth of a computed path does not
    exceed the maximum number of labels (i.e., MSD) the node is
    capable of imposing and the maximum number of labels that can be
    read by the MNA-processing nodes in the path.  The MSD MUST <bcp14>MUST</bcp14> include the MNA Sub-Stacks that will be added.
     </li>
     <li>
   The encapsulating node MUST <bcp14>MUST</bcp14> learn about the RLD of the nodes in the path as described in Section 2.3.1 of <xref target="RFC9789"/>. target="RFC9789" section="2.3.1"/>.

     </li>

    </ul>

  </section>

  <section anchor="sect-J12.1a" numbered="true" toc="default">
    <name>Processing the Network Action Sub-Stack</name>

    <t>
      This section defines the specific responsibilities for nodes
      along an LSP <xref target="RFC3031"/>.
    </t>

    <section>
      <name> Encapsulating Node Responsibilities </name>

      <t>
    The encapsulating node MAY <bcp14>MAY</bcp14> add NASes to the label stack in
    accordance with its policies, the placement restrictions in
    <xref target="Placement"/>, and the capabilities learned
    from <xref target="Signaling"/>.
      </t>

      <t>
      If there is an existing label stack, the encapsulating node MUST NOT <bcp14>MUST NOT</bcp14> modify the first 20 bits of
      any LSE in the label stack when the ECMP technique in the network is using the uses hashing of the labels on the label stack.
      </t>

    </section>

    <section anchor="Transit-Node-Responsibilities" numbered="true" toc="default" >
      <name> Transit Node Responsibilities </name>

      <t>
      The transit node is the node that processes a NAS in the Label stack but does not push any new NAS.
      </t>

      <t>
      The transit node MUST <bcp14>MUST</bcp14> follow the procedure for data specified in Section 5.2. <xref target="Data"/>.
      </t>

      <t>
      Transit nodes MUST <bcp14>MUST</bcp14> process the NASes in the label stack, stack
      according to the rules set out in <xref target="Ordering"/>.
      </t>

      <t>
      A transit node that processes a NAS and does not recognize the value of an opcode MUST <bcp14>MUST</bcp14> follow the rules
      according to the setting of the Unknown Network Action Handling value in the NAS as described in (<xref target="UOH"/>). <xref target="UOH"/>.
      </t>

    </section>

    <section>
      <name> Penultimate Node Responsibilities </name>
      <t>
    In addition to the transit node responsibilities, the
    penultimate node and penultimate SR-MPLS segment node MUST NOT <bcp14>MUST NOT</bcp14> remove the last copy of an HBH HbH or I2E
    NAS when it is exposed after removing the forwarding
    (transport) label. This allows the egress node to process the
    NAS.
      </t>
    </section>

    <section>
      <name> Egress Node Responsibilities </name>
      <t>
    The egress node MUST <bcp14>MUST</bcp14> remove any NAS it receives.
      </t>
    </section>
  </section>

  <section anchor="Allocation" numbered="true" toc="default">
    <name>Network Action Indicator Opcode Definition</name>
     <t>

<!--[rfced] May we update this text as follows?

Original:
The following information MUST be defined for a new Network Action
Indicator opcode request in the document that specifies the Network
Action.
     </t>

Perhaps:
The following information MUST be defined in documentation for any new
NAI opcode request.
-->
     <t>
    A request The following information <bcp14>MUST</bcp14> be defined for a new NAI opcode MUST include request in the following information: document that specifies the Network Action.
     </t>

      <ul>
        <li>
      Format: The

      <dl>
        <dt>Format:</dt><dd>The definition of the new Network Action MUST <bcp14>MUST</bcp14>
        specify the LSE Formats. formats. The opcode can define Network Action in Format B or C or both Format Formats B and C.
        Both Format B and C LSEs MAY <bcp14>MAY</bcp14> optionally carry Format D LSEs.
    </li>
    <li>
    Scope: The
    </dd>
    <dt>Scope:</dt><dd>The definition of the new Network Action MUST <bcp14>MUST</bcp14> specify at
      least one scope (I2E, HBH, HbH, Select) for the Network Action, Action and MAY <bcp14>MAY</bcp14>
      specify more than one scope.
    </li>
    <li>
    Ancillary Data: The
    </dd>
    <dt>Ancillary Data:</dt><dd>The definition of the new Network Action MUST <bcp14>MUST</bcp14>
      specify the quantity, syntax, and semantics of any associated
      Ancillary Data.
      AD.  The Ancillary Data MAY AD <bcp14>MAY</bcp14> be variable length, but
      the NAL MUST <bcp14>MUST</bcp14> be computable based on the data added in the
      NAS.
    </li>
        <li>
    Processing: The
    </dd>
        <dt>Processing:</dt><dd>The definition of the new Network Action MUST <bcp14>MUST</bcp14> specify
      the detailed procedure for processing the network action.
    </li>
        <li>
    Interactions: The
    </dd>
        <dt>Interactions:</dt><dd>The definition of the new Network Action MUST <bcp14>MUST</bcp14> specify its
    interaction including merging with other currently defined Network Action if there is any.
    </li>
      </ul>
    </dd>
      </dl>

      <t>
    An assignment for a NAI MAY <bcp14>MAY</bcp14> make
    requests from any combination of the "Network Action Opcodes"
    or "Network Action Flags Without Ancillary Data" assignments. assignments (see <xref target="sect-J13"/>).
    This decision should optimize for eventual
    encoding efficiency. If the NAI does not require any ancillary
    data, AD, then a flag is preferred as only one bit is used in the
    encoding.
      </t>
    </section>

  <section anchor="sect-J10.c" numbered="true" toc="default">
    <name>Implementation Status</name>
  <t>
   [Note to the RFC Editor - remove this section before publication, as
   well as remove the reference to <xref target="RFC7942"/>]
   </t>

  <t>
   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in <xref target="RFC7942"/>.
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.
  </t>

  <section anchor="sect-J10.d" numbered="true" toc="default">
    <name>University of Tuebingen Implementation</name>
   <t>
   The solution defined in the document draft-ietf-mpls-mna-hdr-08 has been implemented using P4 pipeline.
   The implementation code can be found at https://github.com/uni-tue-kn/P4-MNA. This implementation uses bSPL value 4 as an MNA label.
   </t>

  </section>

  </section>

  <section anchor="sect-J11" numbered="true" toc="default">
    <name>Security Considerations</name>
    <t>
      The security considerations in <xref target="RFC3032" format="default"/> and <xref target="RFC9789" format="default"/> also apply to this document.
    </t>
    <t>
      In addition, MNA creates a new dimension in security
      concerns:
    </t>
      <ul>
    <li>
      The actions of an encapsulating node can affect any or all
      of the nodes along the path. In the most common and benign
      situations, such as a syntactically incorrect packet
      could result in packet loss or corruption. corruption, for example.
    </li>
    <li>
      The semantics of a network action are unbounded and may be
      insecure. A network action could be defined that made makes
      arbitrary changes to the memory of the forwarding router,
      which could then be used by the encapsulating node to
      compromise every MNA-capable router in the network.
    </li>

    <li>
      The MNA architecture supports locally-defined locally defined network
      actions. For such actions, there will be limited oversight
      to ensure that the semantics do not create security
      issues. Implementors and network operators will need to
      ensure that even the locally-defined locally defined network actions do not
      compromise the security of the network by following the security considerations specified in this document.
    </li>

    <li>
    The MPLS domain border nodes MUST <bcp14>MUST</bcp14> ensure that the MPLS packets with MNA from
    any domain with a different administrative control can be
    filtered to prevent entering the provider MPLS domain. The filtering capability MAY <bcp14>MAY</bcp14> be enabled on a per network
    action basis per-network-action basis, and it can be based on a local policy.
    The filtering capability MUST <bcp14>MUST</bcp14> be implemented on those nodes before deploying MNA in the provider MPLS domain.
    The RLD on the filtering node MUST <bcp14>MUST</bcp14> be higher than the RLD on all other nodes in the provider MPLS domain.
    </li>

    <li>
    The MNA architecture supports modifying the AD on the intermediate nodes, nodes so the critical network
    functions should either should not rely on the data or should be aware of the risks and use other means to verify the security of the whole network.
    </li>

    <li>
    The "private "Private Use" opcodes in the "Network Action Opcodes" registry (see <xref target="IANAOpcodes"/> target="IANAOpcodes"/>)
    and the "Network Action Flags Without Ancillary Data" registry (see <xref target="IANAFlags"/> Registry target="IANAFlags"/>)  are subject to the considerations described in <xref target="RFC8126"/>.
    </li>

<!--[rfced] Please review this quick change between BCP 14 markings in
     back-to-back related sentences and let us know if any updates are
     necessary.

Original:
Network actions that require the exchange of sensitive data, must be
defined in such a way that the data is encrypted in transit.
Otherwise, sensitive data MUST NOT be transmitted using these
mechanisms.

-->
    <li>
   System designers must be aware that information included in Ancillary
   Data AD may be transmitted "in the clear." clear".  Network actions that require
   the exchange of sensitive data, data must be defined in such a way that
   the data is encrypted in transit. Otherwise, sensitive data MUST NOT <bcp14>MUST NOT</bcp14> be transmitted using these mechanisms.
   </li>
   <li>
   Mis-delivery of a packet due to malformed forwarding action data could be considered a security risk.
   </li>

      </ul>
  </section>

  <section anchor="sect-J11b" numbered="true" toc="default">
    <name>Operational Considerations</name>
    <section anchor="sect-Manag-J11b" numbered="true" toc="default">
      <name>Manageability Considerations</name>
    <t>
    An MNA implementation MAY <bcp14>MAY</bcp14> collect the following counters:
    </t>
    <ul>
      <li>
      Packets with MNA received
      </li>
      <li>
      MNA sub-stacks processed
      </li>
      <li>
      MNA per-network-action counters
      </li>
      <li>
      Packets with MNA dropped due to unknown actions
      </li>
      <li>
      Packets with MNA skipped due to unknown actions
      </li>
      <li>
      Packets with MNA dropped due to malformed NAS
      </li>
    </ul>

    <t>
    Additionally, tracking both successful invocations and failures for each specific Network Action, are RECOMMENDED Action is <bcp14>RECOMMENDED</bcp14> to provide granular visibility.
    Nodes MAY <bcp14>MAY</bcp14> generate rate-limited notifications or alarms for significant operational events, such as sustained high rates of MNA packet drops, drops or
    frequent encounters of malformed MNA sub-stacks, to alert operators to potential issues.
    Comprehensive logging of MNA processing details and outcomes can aid in the network diagnostics and post-mortem analysis.
    </t>
    </section>
    <section anchor="sect-Perf-J11b" numbered="true" toc="default">
      <name>Performance and Scale Considerations </name>

<!--[rfced] Will the reader know what the "MNA application documents"
     are?  Maybe a citation would be helpful here?  Additionally, "are
     encouraged to be addressed" reads a bit strangely (who is
     encouraged?).

Original:
The considerations for performance and scale assessments are outside
the scope of this document but are encouraged to be addressed in the
MNA application documents.

Perhaps:
Performance and scale assements are outside the scope of this
document; the authors of the MNA application documents [citation(s)?]
are encouraged to address them.

-->

      <t>
      The considerations for performance and scale assessments are outside the scope of this document but are encouraged to be addressed in the MNA application documents.
      </t>
    </section>
    <section anchor="sect-J12" numbered="true" toc="default">
    <name>Backward Compatibility</name>

    <t>
      This section discusses interactions between MNA-capable and
      MNA-incapable nodes.
    </t>
    <t>
      An MNA-encapsulating MNA encapsulating node MUST <bcp14>MUST</bcp14> ensure that the MPLS
      Network Action Sub-Stack indicator is not at the top of the MPLS label
      stack when the packet arrives at an MNA-incapable node. If such
      a packet did arrive at an MNA-incapable node, it
      will most likely be dropped as described in Section 2.1.1 of <xref target="RFC7325"/>. target="RFC7325" section="2.1.1"/>.
    </t>
    <t>
      Any node could scan the label stack, potentially looking for a label value containing a bSPL. To ensure that the LSE formats
      described herein do not appear to contain a bSPL value, the
      opcode value of 0 has been reserved. By ensuring that there is a
      non-zero value in the high order high-order 7 bits, we are assured that the
      high order
      high-order 20 bits cannot be misinterpreted as containing a bSPL
      value (0-15).
    </t>

    <t>
      The TC and TTL values of the Format A LSE are not re-purposed repurposed
      for encoding, as the penultimate node on the MPLS packet path
      may propagate TTL from the transport (or forwarding) label to
      the next label on the label stack, overwriting the TTL on the
      next label.  If the penultimate node is a legacy node, it might
      perform this action, potentially corrupting other values stored
      in the TC and TTL values. To protect against this, we retain the
      TC and TTL values in the Format A LSE.
    </t>

    <t>
      When adding the Entropy Label Indicator (ELI) (bSPL 7) and Entropy
      Label (EL) as defined in <xref target="RFC6790"/>, along with an MNA NAS, the RLD MUST <bcp14>MUST</bcp14> be
      considered for the placement of both, and they both can be placed in any order.

      If a transit LSR chooses to use
      as much of the whole label stack as feasible as keys a key for the load-balancing function,
      the MNA reserved MNA-reserved label MUST NOT <bcp14>MUST NOT</bcp14> be used as a key for the load-balancing function, as specified in Section 4.3 of <xref target="RFC6790"/>. target="RFC6790" section="4.3"/>.

      Note that the behavior of an MNA-incapable transit LSR that scans the label stack for
      ELI and EL but encounters a different, unrecognized reserved label first, is not modified
      by this document.
    </t>

    <t>
      Similarly, when adding the Flow-ID Label Indicator (FLI) (including the extension label 15) and
      Flow-ID Label (FL) as defined in <xref target="RFC9714"/>, along with an MNA NAS, the RLD MUST <bcp14>MUST</bcp14> be
      considered for the placement of both, and they both can be placed in any order.

      Note that the behavior of an MNA-incapable transit LSR that scans the label stack for
      FLI (including the extension label 15) and FL, but encounters a different, unrecognized reserved label first, is not modified
      by this document.
    </t>

    <t>
      However, as the existing behavior is not specified for transit LSRs, upon encountering any unrecognized bSPLs
      or eSPLs extended SPLs (eSPLs) below the top of the label stack,
      some existing implementations may have chosen to implement non-standardized actions, such as discarding packets.
      Any uses of a new bSPL or eSPL would cause issues with such existing
      implementations using the non-standardized actions upon encountering
      unrecognized bSPLs or eSPLs below the top of the label stack. Since this is a generic problem, any
      clarifications for the treatment of unrecognized bSPL or
      eSPL are outside the scope of this document.
    </t>

  </section>
  </section>

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

    <section anchor="sect-J13.6" numbered="true" toc="default">
      <name>MNA bSPL Label</name>
      <t>
    This document requests that
    IANA allocate a has allocated the value (TBA) 4 for
    the MNA bSPL label from the "Base Special-Purpose MPLS Label
    Values" registry to indicate the presence of an MNA Sub-Stack in
    the label stack. The description of the value should be is "MPLS
    Network Actions". The reference should be this document.
      </t>
    </section>

    <section>
      <name>MPLS Network Actions Parameters</name>

      <t>

<!--[rfced] What does "within the 'Multiprotocol Label Switching
     Architecture (MPLS)' category" mean?  We generally see registry
     names and within a certain registry group.

Original:
   This document requests that IANA create a new registry group called
   "MPLS Network Actions Parameters" within the "Multiprotocol Label
   Switching Architecture (MPLS)" category.
    The registries described below should belong to
    this new
-->
      <t>
    IANA has created a registry group. group
    called "MPLS Network Actions" within the
    "Multiprotocol Label Switching Architecture (MPLS)" category.
    This registry group contains the "Network Action Flags Without Ancillary Data" registry (see <xref target="IANAFlags"/>) and the "Network Action Opcodes" registry (see <xref target="IANAOpcodes" />).
      </t>
    </section>

    <section anchor="IANAFlags">
      <name>Network Action Flags Without Ancillary Data</name>
      <t>
    This document requests that IANA create a new registry with
    For the name "Network Action Flags Without Ancillary
    Data". Registration
    Data" registry, registration requests should comply with <xref
    target="Allocation"/>.  The  Depending on the range, the registration procedure for this
    registry is "IETF Review", "Experimental Use" and Use", or "Private Use" as (as defined in <xref target="RFC8126"/>. target="RFC8126"/>).  The fields in this registry are
    "Bit Position" (integer), "Description" (string), and
    "Reference" (string).
      </t>
      <t>

<!--[rfced] Please clarify this text.  If our suggested text does not
     capture the intended meaning, please rephrase.

Original:
...(due to NASL limit of 15 and Format D requires Format C LSE)...

Perhaps:
...(due to the NASL limit of 15 and the constraint of Format D
requiring a Format C LSE...
-->

    Bit Position refers to the position relative to the most
    significant bit in LSE Format B or C Data fields and any
    subsequent Format D LSEs. Bit Position 0 is the most
    significant bit in an LSE Format B or C Data field. Bit Position
    20 is the most significant bit in the first LSE Format D Data
    field. There are 20 bits available in LSE Format C and 30 bits
    available in LSE Format D. There are are, at most most, 14 Format D LSEs
    per opcode (due to the NASL limit of 15 and Format D requires Format C LSE), so there are at most 20 + 14 * 30 = 440 bit
    positions. The value listed in the Bit Position column is an integer with value between 0-439.
      </t>
      <t>
    The registration procedures for the code points point allocation for this registry are defined in <xref target="iana-nafif-tbl-1"/>:
  </t>

<!--[rfced] We had the following questions/comments related to Table 4:

a) Table 4 contains only the Registration Procedures for the "Network
Action Flags Without Ancillary Data" registry.  We have updated the
column headings and removed the reference column to match what we see
at
https://www.iana.org/assignments/mpls-network-actions/mpls-network-actions.xhtml#network-action-flags-without-ancillary-data.

b) It appears that there are currently no values registered in this
registry.  Please confirm that this is as desired.  If so, perhaps it
makes sense to mention in the document that the original contents of
the registry are empty?

-->

      <table anchor="iana-nafif-tbl-1" align="center">
        <name>Network
        <name>Registration Procedures for the "Network Action Flags Without Ancillary Data Data" Registry</name>
        <thead>
          <tr>
            <th align="left"> Bit Position</th>
            <th align="left"> Description</th> align="left">Range</th>
            <th align="left"> Reference</th> align="left">Registration Procedure</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0-14</td>
            <td align="left">IETF Review </td>
            <td align="left">This document</td>
          </tr>
          <tr>
            <td align="left">15-16</td>
            <td align="left">Experimental Use</td>
            <td align="left">This document</td>
          </tr>
          <tr>
            <td align="left">17-19</td>
            <td align="left">Private Use</td>
            <td align="left">This document</td>
          </tr>
          <tr>
            <td align="left">20-439</td>
            <td align="left">IETF Review</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
    </section>

    <section anchor="IANAOpcodes" numbered="true" toc="default">
      <name> Network Action Opcodes</name>

      <t>
    This document

<!--[rfced] We had some questions related to the following text:

Original:
Registration requests that IANA create a new registry should comply with Section 10 as well as
security review.

a) Might it be helpful to the reader to clarify what "security review"
means (Security Considerations text or is this some kind of other
review)?

b) We do see RFC 8126 mentioned in the Security Considerations section
as follows.  This seems procedural for IANA.  Is there some kind of
risk this text is supposed to address?  Otherwise, perhpas remove this
text as this is already captured in the IANA Considerations section?

Original:
   *  The "private Use" opcodes in "Network Action Opcodes" Section 14.4
      and "Network Action Flags Without Ancillary Data" Section 14.3
      Registry are subject to the considerations described in [RFC8126].
-->
      <t>
    For the name "Network Action Opcodes". Registration Opcodes" registry, registration requests
    should comply with <xref target="Allocation"/> as well as security review. The Depending on the range, the registration procedure for this registry is "IETF Review", "Experimental Use" and Use", or "Private Use" as (as defined in <xref target="RFC8126"/>. target="RFC8126"/>). The
    fields are "Opcode" (integer), "Description" (string), and
    "Reference" (string). Opcode is an integer with value 1-126.
      </t>

      <table anchor="iana-is-fioc-reg-tbl" align="center">
        <name> Network
        <name>Registration Procedures for the "Network Action Opcodes Opcodes" Registry</name>
        <thead>
          <tr>
            <th align="left">Opcode</th>
            <th align="center">Description</th> align="left">Range</th>
            <th align="left">Reference</th> align="center">Registration Procedure</th>
          </tr>
        </thead>
        <tbody>
           <tr>
            <td align="left">1-110</td>
            <td align="left">IETF Review </td>
            <td align="left">This document</td>
          </tr>
          <tr>
            <td align="left">111-114</td>
            <td align="left">Experimental Use</td>
            <td align="left">This document</td>
          </tr>
          <tr>
            <td align="left">115-126</td>
            <td align="left">Private Use</td>
            <td align="left">This document</td>
          </tr>
           <tr>
            <td align="left">127</td>
            <td align="left">IETF Review </td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>

<t>
IANA has allocated values for the following Network Action Opcodes from the "Network Action Opcodes" registry.
</t>

      <table anchor="iana-is-fioc-reg-tbl-values" align="center">
        <name>Network
        <name>Initial Contents of the "Network Action Opcodes </name> Opcodes" Registry</name>
        <thead>
          <tr>
            <th align="left">Opcode</th>
            <th align="center">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0</td>
            <td align="left">Reserved</td>
            <td align="left">This document</td> align="left">RFC 9994</td>
          </tr>
          <tr>
            <td align="left">1</td>
            <td align="left">Flag-Based Network Action Indicators without AD</td>
            <td align="left">This document</td> align="left">RFC 9994</td>
          </tr>
          <tr>
            <td align="left">2</td>
            <td align="left">No operation Opcode</td>
            <td align="left">This document</td> align="left">RFC 9994</td>
          </tr>
          <tr>
            <td align="left">127</td>
            <td align="left">Opcode Range Extension Beyond 127</td>
            <td align="left">This document</td> align="left">RFC 9994</td>
          </tr>
        </tbody>
      </table>

    </section>
</section>
  </section>

 </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
    &RFC2119;
    &RFC3032;
    &RFC3270;
    &RFC3443;
    &RFC5462;
    &RFC6790;
    &RFC8126;
    &RFC8174;
    &RFC9017;

    &RFC9789;
    <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.3032.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3270.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3443.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5462.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.8126.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.9017.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9789.xml"/>
      </references>

      <references>
        <name>Informative References</name>
    &RFC3031;
    &RFC6291;
    &RFC7325;
    &RFC7942;
    &RFC8664;
    &RFC9613;
    &RFC9714;
    &RFC9791;
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7325.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9613.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9714.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9791.xml"/>
      </references>
    </references>
      <section anchor="sect-J14" numbered="true" toc="default">
    <name>Examples</name>

    <section anchor="sect-J7" numbered="true" toc="default">
      <name>Network Action Encoding Examples</name>
      <section anchor="sect-J7.1" numbered="true" toc="default">
        <name>Network Action Flags without Without AD</name>

        <figure anchor="In-stack-Ext-Hdr-1-a">
          <name>NAS with Network Action Flags</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          MNA-Label=bSPL               | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=1   |        13-bit Flags     |R|IHS|S|NASL=0 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>

        <t>
      This is an example of a NAS with Flag-Based NAIs without
      Ancillary Data.
      AD.
    </t>

        <t>
      Details:
    </t>
        <ul empty="true" spacing="normal">
          <li> Opcode=1: This
        <dl spacing="normal" newline="false">
          <dt>Opcode=1:</dt><dd>This opcode to indicates that the LSE carries Flag-Based NAIs without AD. </li>
          <li> Data: The </dd>
          <dt>Data:</dt><dd>The data field carries the Flag-Based NAIs. </li>
          <li>
        S: This </dd>
          <dt>S:</dt><dd>This is the bottom of the stack bit. Set if and only if this LSE is the bottom of the stack.
      </li>
          <li> U: Action stack.</dd>
          <dt>U:</dt><dd>Action to be taken if one of the NAIs are is not recognized by the processing node.</li>
          <li> NASL: The node.</dd>
          <dt>NASL:</dt><dd>The NASL value is set to 0, as there are no additional LSEs. </li>
          <li> NAL: The </dd>
          <dt>NAL:</dt><dd>The NAL value is set to 0, as there are no additional AD encoded using Format D. </li>
      </ul> </dd>
	</dl>

      <figure anchor="In-stack-Ext-Hdr-1-a-ext">
        <name>Network Action Flags without Without AD using Using LSE Format D</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MNA-Label=bSPL                   | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=2   |        Data=0           |R|IHS|S|NASL=2 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=1   |        Flag-Based NAIs        |S| NAIs  |U|NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Additional Flag-Based NAIs                |S|Flag-Based-NAIs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>
      <t>
    In this example, the NAS contains a Format B LSE with a No-Operation Opcode value 2. The next LSE uses Format C, but
    the Network Action Flag is not in a bit position contained
    within the Format C LSE, so a single Format D LSE has been
    added to the NAS to carry the flag.
      </t>
      <t>
    NAL is set to 1 to indicate that Flag-Based NAIs are also
    encoded in the next LSE.
      </t>
      <t>
    NASL is set to 2 to indicate that 2 two additional LSEs are
    used.
      </t>
    </section>

    <section anchor="sect-J7.2" numbered="true" toc="default">
      <name>Network Action Opcode with AD </name>

      <figure anchor="In-stack-Ext-Hdr-2a">
        <name>Network action opcode Action Opcode with Ancillary Data</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MNA-Label=bSPL                   | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=8   |      Ancillary Data     |R|IHS|S|NASL=0 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>
      <t>
    In this example, the NAS is carrying only one Network
    Action that requires 13 bits of Ancillary Data. AD.
      </t>
      <t>
    Details on the Second LSE LSE:
      </t>
      <ul empty="true" spacing="normal">
          <li> Opcode=8: A
      <dl spacing="normal" newline="false">
          <dt>Opcode=8:</dt><dd>A network action allocation is outside of this document.</li>
          <li> Data: The document.</dd>
          <dt>Data:</dt><dd>The data field contains 13 bits of ancillary data. </li>
      </ul> AD.</dd>
      </dl>

    </section>

    <section anchor="sect-J7.4.a" numbered="true" toc="default">
      <name>Network Action Opcode with more More AD with Format-B</name>
      <t>
    A network action may require more Ancillary Data AD than can fit
    in a single LSE. In this example, a Format D LSE is added to
    carry additional Ancillary Data. AD.
      </t>

      <figure anchor="In-stack-Ext-Hdr-Format-4-with-more-AD.a">
        <name>Network Action With with Additional Ancillary Data</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          MNA-Label=bSPL               | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=10  |      Ancillary Data     |R|IHS|S|NASL=1 |U|NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|            Ancillary Data                 |S|Ancillary Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>

      <t>
    In this example, opcode 10 is encoded in Format B B, and it requires more than one LSE's worth of
    Ancillary Data,
    AD, so a Format D LSE is added.
      </t>

      <t>
    Details on the second LSE:
      </t>
      <ul empty="true" spacing="normal">
        <li> Opcode=10: An
      <dl spacing="normal" newline="false">
        <dt>Opcode=10:</dt><dd>An opcode allocation is outside of this document.</li>
        <li> Ancillary Data: Ancillary data document.</dd>
        <dt>Ancillary Data:</dt><dd>AD required to process the Network Action opcode 10.</li>
        <li> NAL: Length 10.</dd>
        <dt>NAL:</dt><dd>Length of additional LSEs used to encode its Ancillary data.</li>
      </ul> AD.</dd>
      </dl>

      <t> Details on the third LSE: </t>
      <ul empty="true" spacing="normal">
        <li> Ancillary Data: 22
      <dl spacing="normal" newline="false">
        <dt>Ancillary Data:</dt><dd>22 bits of additional Ancillary data.</li>
        <li> Ancillary Data: 8 AD.</dd>
        <dt>Ancillary Data:</dt><dd>8 bits of additional Ancillary Data.</li>
      </ul> AD.</dd>
      </dl>

    </section>

    <section anchor="sect-J7.4.b" numbered="true" toc="default">
      <name>Network Action Opcode with more More AD with Format C</name>
      <t>
    A network action may require more Ancillary Data AD than can fit
    in a single LSE. In this example, a Format D LSE is added to
    carry additional Ancillary Data. AD.
      </t>

      <figure anchor="In-stack-Ext-Hdr-Format-4-with-more-AD.b">
        <name>Network Action With with Additional Ancillary Data</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          MNA-Label=bSPL               | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=2   |      Data=0             |R|IHS|S|NASL=2 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=9   |      Ancillary Data           |S|   AD  |U|NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|            Ancillary Data                 |S|Ancillary Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>

      <t>
    In this example, opcode 9 requires more than one LSE's worth of
    Ancillary Data,
    AD, so a Format D LSE is added.
      </t>

      <t>
    Details on the third LSE:
      </t>
      <ul empty="true" spacing="normal">
        <li> Opcode=9: An
      <dl spacing="normal" newline="false">
        <dt>Opcode=9:</dt><dd>An opcode allocation is outside of this document</li>
        <li> Ancillary Data: Most document</dd>
        <dt>Ancillary Data:</dt><dd>Most significant bits of Ancillary data</li>
        <li> AD: 4 AD</dd>
        <dt>AD:</dt><dd>4 bits of additional Ancillary Data</li>
      </ul> AD</dd>
      </dl>

      <t> Details on the fourth LSE: </t>
      <ul empty="true" spacing="normal">
        <li> Ancillary Data: 22
      <dl spacing="normal" newline="false">
        <dt>Ancillary Data:</dt><dd>22 bits of additional Ancillary data.</li>
        <li> Ancillary Data: 8 AD.</dd>
        <dt>Ancillary Data:</dt><dd>8 bits of additional Ancillary Data.</li>
      </ul> AD.</dd>
      </dl>

    </section>

  </section>

  <section anchor="sect-J6.a" numbered="true" toc="default">
    <name>Network Action Processing Order</name>
    <t>
      The semantics of a network action can vary widely and the
      results of processing one network action may affect the
      processing of a subsequent network action. See <xref
      target="Ordering"/>.
    </t>

    <section anchor="sect-J6.a1" numbered="true" toc="default">
      <name>Network Action Processing Order</name>
      <figure anchor="In-stack-NA-Ordering-1">
        <name>In-stack
        <name>In-Stack NA processing order</name> Processing Order</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           MNA-Label=bSPL              | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=8    |      Ancillary Data     |R|IHS|S|NASL=2 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=7    |      Ancillary Data7          |S|  AD7  |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1    |      Flag-Based NAIs          |S|  NAI  |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>

      <t>
    In this example, opcode 8 is processed first, then opcode 7,
    and then the network action flags are processed from most
    significant to least significant.
      </t>
      <t>
    In a different case, some Flag-Based NAIs may need to be
    processed before opcode 7 7, and some Flag-Based NAIs
    may need to be processed after Opcode opcode 7. This can be done
    by causing some NAIs to appear earlier in the NAS.
      </t>

      <figure anchor="In-stack-NA-Ordering-2">
        <name>Interleaving network actions</name> Network Actions</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              MNA-Label=bSPL           | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=8    |      Ancillary Data     |R|IHS|S|NASL=3 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1    |        0x01                   |S|  NAI  |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=7    |      Ancillary Data7          |S|  AD7  |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1    |        0x02                   |S|  NAI  |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>
      <t>
    In the above example, opcode 8 is processed first, then
    Flag-Based NAI 0x01 is processed, then opcode 7 is processed, and
    finally NAI 0x02 is processed.
      </t>

    </section>
    </section>

   </section>

    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>
      The authors of this document would like to thank the MPLS Working Group
      Open Design Team for the discussions and comments on this document. The
      authors would also like to thank Amanda
      Baber <contact fullname="Amanda Baber"/> for
      reviewing the IANA Considerations and providing many useful
      suggestions. The authors would like to thank Loa
      Andersson, Stewart Bryant, Greg Mirsky, Joel <contact fullname="Loa
      Andersson"/>, <contact fullname="Stewart Bryant"/>, <contact
      fullname="Greg Mirsky"/>, <contact fullname="Joel M. Halpern Halpern"/>, and Adrian Farrel
      <contact fullname="Adrian Farrel"/> for reviewing this document and
      providing many useful suggestions. The authors would like to thank Fabian Ihle and Michael Menth,
      <contact fullname="Fabian Ihle"/> and <contact fullname="Michael
      Menth"/>, both from the University of Tuebingen, for reviewing and
      implementing the solution defined in this document in P4 pipeline.
      Also, thank you, Tarek Saad you to <contact fullname="Tarek Saad"/> for the Shepherd's
      review, Joe Clarke <contact fullname="Joe Clarke"/> for the OpsDir review,
      Matthew Bocci <contact
      fullname="Matthew Bocci"/> for the Rtgdir review, Derrell Piper <contact fullname="Derrell
      Piper"/> for the Secdir review, and James Guichard <contact fullname="James Guichard"/> for
      the AD review,
      Mohamed Boucadair, Eric Vyncke, Deb Cooley, Ketan Talaulikar, Mahesh Jethanandani <contact fullname="Mohamed Boucadair"/>, <contact
      fullname="Éric Vyncke"/>, <contact fullname="Deb Cooley"/>, <contact
      fullname="Ketan Talaulikar"/>, and <contact fullname="Mahesh Jethanandani"/>
      for the IESG review, which helped improve this document.
      </t>
    </section>

    <section numbered="false" anchor="contributors" toc="default">
      <name>Contributors</name>
      <t>The following people have substantially contributed to this document:</t>

          <figure anchor="contrib">
     <artwork name="" type="" align="left" alt=""><![CDATA[

Jisu Bhattacharya
Cisco

      <contact fullname="Jisu Bhattacharya">
	<organization>Cisco Systems, Inc.
Email: jisu@cisco.com

Bruno Decraene
Orange
Email: bruno.decraene@orange.com

Weiqiang Cheng
China Mobile
Email: chengweiqiang@chinamobile.com

Xiao Min
ZTE Corp.
Email: xiao.min2@zte.com.cn

Luay Jalil
Verizon
Email: luay.jalil@verizon.com

Jie Dong
Huawei Technologies
Huawei Inc.</organization>
	<address>
	  <email>jisu@cisco.com</email>
	</address>
      </contact>

      <contact fullname="Bruno Decraene">
	<organization>Orange</organization>
	<address>
	  <email>bruno.decraene@orange.com</email>
	</address>
      </contact>

      <contact fullname="Weiqiang Cheng">
	<organization>China Mobile</organization>
	<address>
	  <email>chengweiqiang@chinamobile.com</email>
	</address>
      </contact>

      <contact fullname="Xiao Min">
	<organization>ZTE Corp.</organization>
	<address>
	  <email>xiao.min2@zte.com.cn</email>
	</address>
      </contact>

      <contact fullname="Luay Jalil">
	<organization>Verizon</organization>
	<address>
	  <email>luay.jalil@verizon.com</email>
	</address>
      </contact>

      <contact fullname="Jie Dong">
	<organization>Huawei Technologies</organization>
	<address>
	  <postal>
	    <street>Huawei Campus, No. 156 Beiqing Rd.
Beijing  100095
China
Email: jie.dong@huawei.com

Tianran Zhou
Huawei Technologies
China
Email: zhoutianran@huawei.com

Bin Wen
Comcast
Email: Bin_Wen@cable.comcast.com

Sami Boutros
Ciena
Email: sboutros@ciena.com

Tony Li
Juniper Networks
United Rd.</street>
	    <city>Beijing</city><code>100095</code>
	    <country>China</country>
	  </postal>
	  <email>jie.dong@huawei.com</email>
	</address>
      </contact>

      <contact fullname="Tianran Zhou">
	<organization>Huawei Technologies</organization>
	<address>
	  <postal>
	    <country>China</country>
	  </postal>
	  <email>zhoutianran@huawei.com</email>
	</address>
      </contact>

      <contact fullname="Bin Wen">
	<organization>Comcast</organization>
	<address>
	  <email>Bin_Wen@cable.comcast.com</email>
	</address>
      </contact>

      <contact fullname="Sami Boutros">
	<organization>Ciena</organization>
	<address>
	  <email>sboutros@ciena.com</email>
	</address>
      </contact>

      <contact fullname="Tony Li">
	<organization>Juniper Networks</organization>
	<address>
	  <postal>
	    <country>United States
Email: tony.li@tony.li

John Drake
Juniper Networks
United of America</country>
	  </postal>
	  <email>tony.li@tony.li</email>
	</address>
      </contact>

      <contact fullname="John Drake">
	<organization>Juniper Networks</organization>
	<address>
	  <postal>
	    <country>United States
Email: jdrake@juniper.net

    ]]></artwork>
      </figure> of America</country>
	  </postal>
	  <email>jdrake@juniper.net</email>
	</address>
      </contact>

<!--[rfced] We had the following questions related to references:

a) Would you like the reference entries to be alphabetized or left in
their current order?

b) We happened to notice the RFC 9789 references RFC 3031 normatively.
This document references it informatively.  Please review and confirm
this reference appears as desired.

c) We most frequently see RFC 8126 cited informatively.  Please review
and confirm that this document should remain in the Normative
References section.

-->

<!--[rfced] We had the following questions/comments related to
     abbreviations used throughout the doucment:

a) Please note that we have expanded abbreviations on first use.
Please review for accuracy.

b) We have updated to use abbreviations only after their first
expanded introduction in accordance with
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev.  Please let
us know any objections.

c) We have updated to use "a NAS" instead of "an NAS" as we believe
this is an acronym (i.e., read as a word instead of an initialism).
This tracks with past use in RFCs.  Please let us know any objections.
-->

<!--[rfced] We had the following questions related to terminology used
     throughout the document:

a) We see both Format-B and Format B (and A, C, D, etc.).  How may we
make these consistent?

b) We see multiple forms of the following.  Please let us know if/how
to make them consistent throughout the document:

Last LSE vs. last LSE
MNA Sub-Stack vs. MNA sub-stack
In-Stack vs. in-stack
Network Action vs. network action
Network Action Flag vs. network action flag
Label Stack vs. label stack
Select scope vs. select-scoped

c) We see some possible inconsistencies with the following:

I2E scope NAS
NAS with I2E scope
HbH NAS
HbH scope NAS
NAS with HbH scope

Please let us know if/how to make these uniform.
-->

<!-- [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.
-->

    </section>
  </back>
</rfc>