rfc9994.original.xml   rfc9994.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.2119.xml">
<!ENTITY RFC3031 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.3031.xml">
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.3032.xml">
<!ENTITY RFC3270 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.3270.xml">
<!ENTITY RFC3443 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.3443.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8126.xml">
<!ENTITY RFC7942 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.7942.xml">
<!ENTITY RFC4385 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.4385.xml">
<!ENTITY RFC5462 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5462.xml">
<!ENTITY RFC5586 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5586.xml">
<!ENTITY RFC6291 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.6291.xml">
<!ENTITY RFC6790 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.6790.xml">
<!ENTITY RFC7325 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.7325.xml">
<!ENTITY RFC8664 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8664.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8174.xml">
<!ENTITY RFC9017 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9017.xml">
<!ENTITY RFC9613 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9613.xml">
<!ENTITY RFC9714 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9714.xml">
<!ENTITY RFC9789 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9789.xml">
<!ENTITY RFC9791 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9791.xml">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
raft-ietf-mpls-mna-hdr-21" category="std" ipr="trust200902" obsoletes="" updates <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
="" xml:lang="en" sortRefs="false" symRefs="true" tocInclude="true" version="3" raft-ietf-mpls-mna-hdr-21" number="9994" category="std" ipr="trust200902" obsole
consensus="true"> tes="" updates="" xml:lang="en" sortRefs="false" symRefs="true" tocInclude="true
<!-- xml2rfc v2v3 conversion 3.12.0 --> " version="3" consensus="true">
<!-- Generated by id2xml 1.5.0 on 2020-03-06T17:47:05Z -->
<front> <front>
<title abbrev="In-Stack MNA Sub-Stack">MPLS Network Action (MNA) Sub-Stack S <title abbrev="In-Stack MNA Sub-Stack">MPLS Network Action (MNA) Sub-Stack S
pecification including In-Stack Network Actions and Data</title> pecification Including In-Stack Network Actions and Data</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-hdr-21"/> <seriesInfo name="RFC" value="9994"/>
<author fullname="Jaganbabu Rajamanickam" initials="J." role="editor" surnam e="Rajamanickam"> <author fullname="Jaganbabu Rajamanickam" initials="J." role="editor" surnam e="Rajamanickam">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Canada</street> <country>Canada</country>
</postal> </postal>
<email>jrajaman@cisco.com</email> <email>jrajaman@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi "> <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi ">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Canada</street> <country>Canada</country>
</postal> </postal>
<email>rgandhi@cisco.com</email> <email>rgandhi@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Royi Zigler" initials="R." surname="Zigler"> <author fullname="Royi Zigler" initials="R." surname="Zigler">
<organization>Broadcom</organization> <organization>Broadcom</organization>
<address> <address>
<email>royi.zigler@broadcom.com</email> <email>royi.zigler@broadcom.com</email>
</address> </address>
</author> </author>
skipping to change at line 71 skipping to change at line 51
<organization>Futurewei Technologies</organization> <organization>Futurewei Technologies</organization>
<address> <address>
<email>haoyu.song@futurewei.com</email> <email>haoyu.song@futurewei.com</email>
</address> </address>
</author> </author>
<author fullname="Kireeti Kompella" initials="K." surname="Kompella"> <author fullname="Kireeti Kompella" initials="K." surname="Kompella">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>United States</street> <country>United States</country>
</postal> </postal>
<email>kireeti.ietf@gmail.com</email> <email>kireeti.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date year="2026"/> <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> <abstract>
<t> <t>
This document specifies the MPLS Network Actions (MNA) sub-stack for carryin This document specifies the MPLS Network Action (MNA) sub-stack for carrying
g Network Actions and Ancillary Data (AD) in the MPLS label stack. MNA can
Network Actions and Ancillary Data in the MPLS label stack. MNA can be used to influence packet-forwarding decisions, carry additional
be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance (OAM) information in the MPLS
Operations, Administration, and Maintenance information in the MPLS packet, or perform user-defined operations.
packet or perform user-defined operations.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" numbered="true" toc="default"> <section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
<xref target="RFC3032" format="default"/> defines the <xref target="RFC3032" format="default"/> defines the
encoding of the MPLS label stack, the basic structure used encoding of the MPLS label stack, the basic structure used
to define a forwarding path. There are applications that to define a forwarding path. There are applications that
require MPLS packets to perform special network actions and require MPLS packets to perform special network actions and
carry optional Ancillary Data (AD) that can affect the carry optional Ancillary Data (AD) that can affect the
packet forwarding decision or trigger Operations, Administration, and Main packet-forwarding decision or trigger Operations, Administration, and Main
tenance (OAM) tenance (OAM)
logging, for example as described in <xref target="RFC9791" format="defaul logging, for example, as described in <xref target="RFC9791" format="defau
t"/>. lt"/>.
Ancillary Data can be used to carry additional AD can be used to carry additional
information, for network slice purpose, as an example <xref target="RFC979 information, for example, for network slice purposes (see <xref target="RF
1" format="default"/>. C9791" format="default"/>).
</t> </t>
<t> <t>
The requirements for In-stack network action and In-stack data (ISD) are d escribed in The requirements for In-stack network action and In-Stack Data (ISD) are d escribed in
<xref target="RFC9613" format="default"/>. <xref target="RFC9613" format="default"/>.
</t> </t>
<t> <t>
This document defines the syntax This document defines the syntax
and semantics of network actions and ancillary data encoded in an and semantics of network actions and AD encoded in an
MPLS label stack. In-stack actions and ancillary data are contained MPLS label stack. In-stack actions and AD are contained
in a Network Action Sub-Stack (NAS), which is recognized by a new in a Network Action Sub-Stack (NAS), which is recognized by a new
base Special Purpose Label (bSPL). base Special-Purpose Label (bSPL).
This document follows the This document follows the
framework specified in <xref target="RFC9789" format="default"/>. framework specified in <xref target="RFC9789" format="default"/>.
</t> </t>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default"> <section anchor="sect-2" numbered="true" toc="default">
<name>Conventions Used in This Document</name> <name>Conventions Used in This Document</name>
<section anchor="sect-2.1" numbered="true" toc="default"> <section anchor="sect-2.1" numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
described in BCP 14, <xref target="RFC2119" format="default"/> <xref RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
target="RFC8174" format="default"/> when, and only when, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
they appear in all capitals, as shown here. be interpreted as
</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="sect-2.2" numbered="true" toc="default"> <section anchor="sect-2.2" numbered="true" toc="default">
<name>Abbreviations</name> <name>Abbreviations</name>
<t> <t>
The abbrevations defined in <xref The abbreviations defined in <xref
target="RFC9789" format="default"/> and <xref target="RFC9789" format="default"/> and <xref
target="RFC9613" format="default"/> are target="RFC9613" format="default"/> are
used in this document. used in this document.
</t> </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"> <table anchor="abbreviations">
<name>Abbreviations</name> <name>Abbreviations</name>
<thead> <thead>
<tr> <tr>
<th align='left'>Abbreviation</th> <th align='left'>Abbreviation</th>
<th align='left'>Meaning</th> <th align='left'>Meaning</th>
<th align='left'>Reference</th> <th align='left'>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>AD</td> <td>AD</td>
<td>Ancillary Data</td> <td>Ancillary Data</td>
<td><xref target="RFC9613"/></td> <td><xref target="RFC9613"/></td>
</tr> </tr>
<tr> <tr>
<td>bSPL</td> <td>bSPL</td>
<td>Base Special Purpose Label</td> <td>base Special Purpose Label</td>
<td><xref target="RFC9017"/></td> <td><xref target="RFC9017"/></td>
</tr> </tr>
<tr> <tr>
<td>BOS</td> <td>BoS</td>
<td>Bottom Of Stack</td> <td>Bottom of Stack</td>
<td><xref target="RFC9789"/></td> <td><xref target="RFC9789"/></td>
</tr> </tr>
<tr> <tr>
<td>ECMP</td> <td>ECMP</td>
<td>Equal Cost Multi-Path</td> <td>Equal-Cost Multipath</td>
<td><xref target="RFC6790"/></td> <td><xref target="RFC6790"/></td>
</tr> </tr>
<tr> <tr>
<td>HBH</td> <td>HbH</td>
<td>Hop-By-Hop Scope</td> <td>Hop-by-Hop</td>
<td><xref target="RFC9789"/></td> <td><xref target="RFC9789"/></td>
</tr> </tr>
<tr> <tr>
<td>I2E</td> <td>I2E</td>
<td>Ingress-To-Egress Scope</td> <td>Ingress to Egress</td>
<td><xref target="RFC9789"/></td> <td><xref target="RFC9789"/></td>
</tr> </tr>
<tr> <tr>
<td>IHS</td> <td>IHS</td>
<td>I2E, HBH, or Select Scope</td> <td>I2E, HbH, or Select</td>
<td><xref target="RFC9789"/>, This document</td> <td><xref target="RFC9789"/>, This document</td>
</tr> </tr>
<tr> <tr>
<td>ISD</td> <td>ISD</td>
<td>In-stack Data</td> <td>In-Stack Data</td>
<td><xref target="RFC9613"/></td> <td><xref target="RFC9613"/></td>
</tr> </tr>
<tr> <tr>
<td>LSE</td> <td>LSE</td>
<td>Label Stack Entry</td> <td>Label Stack Entry</td>
<td><xref target="RFC9789"/></td> <td><xref target="RFC9789"/></td>
</tr> </tr>
<tr> <tr>
<td>LSP</td> <td>LSP</td>
<td>Label Switched Path</td> <td>Label Switched Path</td>
<td><xref target="RFC3031"/></td> <td><xref target="RFC3031"/></td>
</tr> </tr>
<tr> <tr>
<td>MNA</td> <td>MNA</td>
<td>MPLS Network Actions</td> <td>MPLS Network Action</td>
<td><xref target="RFC9789"/></td> <td><xref target="RFC9789"/></td>
</tr> </tr>
<tr> <tr>
<td>NAI</td> <td>NAI</td>
<td>Network Action Indicator</td> <td>Network Action Indicator</td>
<td><xref target="RFC9613"/></td> <td><xref target="RFC9613"/></td>
</tr> </tr>
<tr> <tr>
<td>NAL</td> <td>NAL</td>
<td>Network Action Length</td> <td>Network Action Length</td>
skipping to change at line 254 skipping to change at line 286
<td><xref target="RFC9789"/> </td> <td><xref target="RFC9789"/> </td>
</tr> </tr>
<tr> <tr>
<td>TC</td> <td>TC</td>
<td>Traffic Class</td> <td>Traffic Class</td>
<td><xref target="RFC5462"/></td> <td><xref target="RFC5462"/></td>
</tr> </tr>
<tr> <tr>
<td>TTL</td> <td>TTL</td>
<td>Time To Live</td> <td>Time to Live</td>
<td><xref target="RFC3032"/></td> <td><xref target="RFC3032"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sect-2.3" numbered="true" toc="default"> <section anchor="sect-2.3" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t> <t>
The following terms are used in this document. The following terms are used in this document.
</t> </t>
<dl newline="true"> <dl newline="true">
<dt>MPLS egress node:</dt> <dt>MPLS Egress Node:</dt>
<dd>An MPLS edge node in its role in handling traffic as it leaves an MP LS domain <xref <dd>An MPLS edge node in its role in handling traffic as it leaves an MP LS domain <xref
target="RFC3031" format="default"/>.</dd> target="RFC3031" format="default"/>.</dd>
<dt>MPLS ingress node:</dt> <dt>MPLS Ingress Node:</dt>
<dd>An MPLS edge node in its role in handling traffic as it enters an MP LS domain <xref <dd>An MPLS edge node in its role in handling traffic as it enters an MP LS domain <xref
target="RFC3031" format="default"/>.</dd> target="RFC3031" format="default"/>.</dd>
<dt>MPLS domain:</dt> <dt>MPLS Domain:</dt>
<dd> A contiguous set of nodes which operate MPLS routing and forwarding <dd> A contiguous set of nodes that operate MPLS routing and forwarding
and which are also in one Routing or Administrative Domain <xref and that are also in one Routing or Administrative Domain <xref
target="RFC3031" format="default"/>.</dd> target="RFC3031" format="default"/>.</dd>
<dt>Encapsulating Node:</dt> <dt>Encapsulating Node:</dt>
<dd> An encapsulating node is a node that adds an NAS to the label stack .</dd> <dd> A node that adds a NAS to the label stack.</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default"> <section anchor="sect-3" numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t> <t>
The MPLS Network Action Sub-Stack is a set of Label Stack The MPLS NAS is a set of Label Stack
Entries (LSEs) that appear as part of an MPLS label stack and Entries (LSEs) that appear as part of an MPLS label stack and
serve to encode information about the network actions that serve to encode information about the network actions that
should be invoked for the packet. Multiple NASes may should be invoked for the packet. Multiple NASes may
appear in a label stack and be placed as described in Section 5. appear in a label stack and be placed as described in <xref target="sect-3 .1"/>.
</t> </t>
<t> <t>
This document specifies how network actions and their optional ancillary data ar e encoded as part of a NAS as a stack of LSEs. Mechanisms that allow sharing of ancillary data (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 th e encodings described in this document. This document specifies how network actions and their optional AD are encoded as part of a NAS as a stack of LSEs. Mechanisms that allow sharing of AD between m ultiple network actions encoded in the same NAS can be described in other docume nts and do not rely on any explicit provision in the encodings described in this document.
</t> </t>
<t> <t>
This document defines new LSE formats beyond <xref target="RFC3032"/> This document defines new LSE formats beyond those in <xref target="RFC3032"
that define behaviors or are processed in different ways to MPLS labels as />
that define behaviors or are processed in different ways than MPLS labels as
defined in <xref target="RFC3031"/>. defined in <xref target="RFC3031"/>.
Three new LSE formats are defined to carry 7 bits of network action opcodes and varying Three new LSE formats are defined to carry 7 bits of network action opcodes and varying
amounts of opcode-specific ancillary data. Specifically, Format-B LSE carries up amounts of opcode-specific AD. Specifically, Format-B LSE carries up to 13 bits
to 13 bits of AD in an LSE. Format-C LSE carries up to 20 bits of AD in an LSE.
of ancillary data in an LSE and Format-C LSE carries up to 20 bits of ancillary Format-D LSE is used when additional AD is needed by the opcodes in Format-B or
data in an LSE. Format-C LSEs.
Format-D LSE is used when additional ancillary data is needed by the opcodes in
Format-B or Format-C LSEs.
</t> </t>
<t> <t>
As shown in an example in the <xref target="In-stack-Ext-Hdr-Example"/>, As shown in <xref target="In-stack-Ext-Hdr-Example"/>,
the first LSE in an MNA Sub-Stack uses Format-A. 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 addition al data. The second LSE uses Format-B and is followed by a Format-D LSE to carry addition al data.
Next, there may be a Format-C LSE for an additional network action followed by a nother Format-D LSE for additional data. Next, there may be a Format-C LSE for an additional network action followed by a nother Format-D LSE for additional data.
You can add more Format-C and Format-D LSEs as needed for additional network act ions and data. Additional Format-C and Format-D LSEs may be added as needed for additional netw ork actions and data.
</t> </t>
<figure anchor="In-stack-Ext-Hdr-Example" align="center"> <figure anchor="In-stack-Ext-Hdr-Example" align="center">
<name>An MNA Sub-Stack Encoding Example</name> <name>An MNA Sub-Stack Encoding Example</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| MNA-Label=bSPL | TC |S| TTL |A | MNA-Label=bSPL | TC |S| TTL |A
skipping to change at line 337 skipping to change at line 369
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| Opcode | 16-bit Data |S|4b Data|U| NAL |C | Opcode | 16-bit Data |S|4b Data|U| NAL |C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|1| 22-bit Data |S| 8-bit Data |D* |1| 22-bit Data |S| 8-bit Data |D*
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| Opcode | 16-bit Data |S|4b Data|U| NAL |C | Opcode | 16-bit Data |S|4b Data|U| NAL |C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
Legend: * Format-D LSE presence indicated by NAL greater than one * Format-D LSE presence indicated by NAL greater than one
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section> <section>
<name>Label Stack Entry Formats</name> <name>Label Stack Entry Formats</name>
<t> <t>
The NAS uses a variety of different formats of LSEs for The NAS uses a variety of different formats of LSEs for
different purposes. This section describes the syntax of the different purposes. This section describes the syntax of the
various formats while the overall structure of the NAS and the various formats while the overall structure of the NAS and the
semantics of the various LSEs are described in the sections below. semantics of the various LSEs are described in the sections below.
</t> </t>
<section anchor="LSE-A"> <section anchor="LSE-A">
<name>LSE Format A: The MNA Sub-Stack Indicator</name> <name>LSE Format A: The MNA Sub-Stack Indicator</name>
<t> <t>
LSE Format A is an LSE as described in <xref LSE Format A is an LSE as described in <xref
target="RFC3032"/> and <xref target="RFC5462"/>. target="RFC3032"/> and <xref target="RFC5462"/>.
The label value is an IANA-assigned value (TBA) for the MNA bSPL label The label value is 4 for the MNA bSPL label
from the "Base Special-Purpose MPLS Label Values" registry to from the "Base Special-Purpose MPLS Label Values" IANA registry (see <xref targe
indicate the presence of MNA in the packet and the beginning of an MNA t="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. Sub-Stack in the label stack.
</t> </t>
<figure> <figure>
<name>LSE Format A: The MNA Sub-Stack Indicator</name> <name>LSE Format A: The MNA Sub-Stack Indicator</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA-Label=bSPL | TC |S| TTL | | MNA-Label=bSPL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<ul> <dl spacing="normal" newline="false">
<li> <dt>S (1 bit):</dt><dd>The BoS <xref target="RFC3032"/>.
S (1 bit): The Bottom of Stack <xref target="RFC3032"/>. <bcp14>MUST</bcp14> be set to 0 on transmitted packets.
MUST be set to 0 on transmitted packets. If a packet is received with an LSE containing the bSPL (4) and
If a packet is received with an LSE containing the bSPL (value TBA) and with S bit set to 1, then the packet <bcp14>MUST</bcp14> be dropped.
with S bit set to 1, then the packet MUST be dropped. </dd>
</li> </dl>
</ul>
</section> </section>
<section anchor="LSE-B"> <section anchor="LSE-B">
<name>LSE Format B: The initial opcode</name> <name>LSE Format B: The Initial Opcode</name>
<t> <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, LSE Format B is used to encode the first opcode in the NAS,
plus a number of other fields about the NAS. plus a number of other fields about the NAS.
This LSE can carry up to 13 bits of ancillary data. This LSE can carry up to 13 bits of AD.
</t> </t>
<figure> <figure>
<name>LSE Format B: The initial opcode</name> <name>LSE Format B: The Initial Opcode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | 13-bit Data |R|IHS|S| NASL |U| NAL | | Opcode | 13-bit Data |R|IHS|S| NASL |U| NAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<ul> <dl spacing="normal" newline="false">
<li> <dt>
Opcode (7 bits): The operation code for this LSE. See Opcode (7 bits):</dt><dd>The operation code for this LSE. See
<xref target="Opcodes"/>. <xref target="Opcodes"/>.
</li> </dd>
<li> <dt>
Data (13 bits): Opcode-specific ancillary data. Data (13 bits):</dt><dd>Opcode-specific AD.
</li> </dd>
<li> <dt>
R (1 bit): Reserved. This bit MUST be set to zero on transmission and ign R (1 bit): Reserved.</dt><dd>This bit <bcp14>MUST</bcp14> be set to zero
ored upon receipt. on transmission and ignored upon receipt.
</li> </dd>
<li> <dt>
IHS (2 bits): The scope of all the network actions in this NAS. See <xref IHS (2 bits):</dt><dd>The scope of all the network actions in this NAS. Se
target="Scope"/>. e <xref target="Scope"/>.
</li> </dd>
<li> <dt>
S (1 bit): The Bottom of Stack <xref target="RFC3032"/>. S (1 bit):</dt><dd>The BoS <xref target="RFC3032"/>.
If NASL value is non-zero, then S bit MUST be 0. If the NASL value is non-zero, then the S bit <bcp14>MUST</bcp14> be 0.
If a packet is received with S bit set to 1 and a non-zero NASL value, If a packet is received with the S bit set to 1 and a non-zero NASL value,
then the packet MUST be dropped. The encapsulating node MUST ensure that t then the packet <bcp14>MUST</bcp14> be dropped. The encapsulating node <bc
he S bit is set to 1 only in the Last LSE in the MPLS header. p14>MUST</bcp14> ensure that the S bit is set to 1 only in the Last LSE in the M
</li> PLS header.
<li> </dd>
NASL (4 bits): The Network Action Sub-Stack Length <dt>
(NASL). The number of Format C and Format D LSEs in the NAS, i.e., not NASL (4 bits):</dt><dd>The Network Action Sub-Stack 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. including the leading Format A LSE and the Format B LSE.
</li> </dd>
<li> <dt>
U (1 bit): Unknown Network Action Handling. See <xref target="UOH" />. U (1 bit):</dt><dd>Unknown Network Action Handling. See <xref target="UOH"
</li> />.
<li> </dd>
NAL (3 bits): Network Action Length. The number of LSEs of <dt>
additional data, encoded in Format D LSEs (<xref target="LSE-D"/>) NAL (3 bits):</dt><dd>Network Action Length. The number of LSEs of
following this Format B LSE. The NAL value MUST be less than or equal to t additional data, encoded in Format D LSEs (<xref target="LSE-D"/>),
he NASL value in the Format B LSE, if not the packet MUST be dropped. following this Format B LSE. The NAL value <bcp14>MUST</bcp14> be less tha
n or equal to the NASL value in the Format B LSE. If not, the packet <bcp14>MUS
T</bcp14> be dropped.
A Format C LSE would be following when the NAL value is less than the NASL value. A Format C LSE would be following when the NAL value is less than the NASL value.
</li> </dd>
</ul> </dl>
</section> </section>
<section anchor="LSE-C"> <section anchor="LSE-C">
<name>LSE Format C: Subsequent opcodes</name> <name>LSE Format C: Subsequent Opcodes</name>
<t> <t>
LSE Format C is used to encode the subsequent opcodes in the NAS. LSE Format C is used to encode the subsequent opcodes in the NAS.
</t> </t>
<figure> <figure>
<name>LSE Format C: Subsequent opcodes</name> <name>LSE Format C: Subsequent Opcodes</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | 16-bit Data |S|4b Data|U| NAL | | Opcode | 16-bit Data |S|4b Data|U| NAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<ul> <dl spacing="normal" newline="false">
<li>Opcode (7 bits): The operation code for this LSE. See <dt>Opcode (7 bits):</dt><dd>The operation code for this LSE. See
<xref target="Opcodes"/>.</li> <xref target="Opcodes"/>.</dd>
<li>Data (16 bits + 4 bits): Opcode-specific ancillary data.</li> <dt>Data (16 bits + 4 bits):</dt><dd>Opcode-specific AD.</dd>
<li> <dt>
S (1 bit): The Bottom of Stack <xref target="RFC3032"/>. S (1 bit):</dt><dd>The BoS <xref target="RFC3032"/>.
If NAL value is non-zero and if S bit is set to 1, then the packet MUST be d If the NAL value is non-zero and if the S bit is set to 1, then the packet <
ropped. bcp14>MUST</bcp14> be dropped.
If this is not the last LSE in the NAS and if S bit is set to 1 then the pac If this is not the last LSE in the NAS and if the S bit is set to 1, then th
ket MUST be dropped. e packet <bcp14>MUST</bcp14> be dropped.
The encapsulating node MUST ensure that the S bit is set to 1 only in the La The encapsulating node <bcp14>MUST</bcp14> ensure that the S bit is set to 1
st LSE. only in the Last LSE.
</li> </dd>
<li> <dt>
U (1 bit): Unknown Network Action Handling. See <xref target="UOH" />. U (1 bit):</dt><dd>Unknown Network Action Handling. See <xref target="UOH"
</li> />.
<li> </dd>
NAL (3 bits): Network Action Length. The number of LSEs of <dt>
NAL (3 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. additional data, encoded in Format D LSEs (<xref target="LSE-D"/>) following this Format C LSE.
The NAL value MUST be less than or equal to the NASL value in the Format B L The NAL value <bcp14>MUST</bcp14> be less than or equal to the NASL value in
SE, if not the packet MUST be dropped. the Format B LSE. If not, the packet <bcp14>MUST</bcp14> be dropped.
</li> </dd>
</ul> </dl>
<t> <t>
A Format A and a Format B LSE MUST be present when a Format C LSE is car ried in the NAS. A Format A and a Format B LSE <bcp14>MUST</bcp14> be present when a Form at C LSE is carried in the NAS.
</t> </t>
</section> </section>
<section anchor="LSE-D"> <section anchor="LSE-D">
<name>LSE Format D: Additional Data</name> <name>LSE Format D: Additional Data</name>
<t> <t>
LSE Format D is used to encode additional data that LSE Format D is used to encode additional data that
did not fit in the LSE with the preceding opcode. did not fit in the LSE with the preceding opcode.
</t> </t>
<figure> <figure>
<name>LSE Format D: Additional Data</name> <name>LSE Format D: Additional Data</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 22-bit Data |S| 8-bit Data | |1| 22-bit Data |S| 8-bit Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<ul> <dl spacing="normal" newline="false">
<li> <dt>
1 (1 bit): The most significant bit MUST be set. This 1 (1 bit):</dt><dd>The most significant bit <bcp14>MUST</bcp14> be set. Th
is
prevents legacy implementations from misinterpreting this prevents legacy implementations from misinterpreting this
LSE as containing a special purpose label if the data begins with zeros. LSE as containing a special purpose label if the data begins with zeros.
</li> </dd>
<li> <dt>
S (1 bit): The Bottom of Stack <xref target="RFC3032"/>. S (1 bit):</dt><dd>The BoS <xref target="RFC3032"/>.
If this is not the last LSE for the Network Action based on the NAL value an If this is not the last LSE for the Network Action based on the NAL value an
d if S bit is d if the S bit is
set to 1 then the packet MUST be dropped. If this is not the last LSE in the set to 1, then the packet <bcp14>MUST</bcp14> be dropped. If this is not the
NAS and last LSE in the NAS and
if S bit is set to 1 then the packet MUST be dropped. The encapsulating node if the S bit is set to 1, then the packet <bcp14>MUST</bcp14> be dropped. Th
MUST ensure that the S bit is set to 1 only in the Last LSE. e encapsulating node <bcp14>MUST</bcp14> ensure that the S bit is set to 1 only
in the Last LSE.
</li> </dd>
<li>Data (22 bits + 8 bits): Opcode-specific ancillary data.</li> <dt>Data (22 bits + 8 bits):</dt><dd>Opcode-specific AD.</dd>
</ul> </dl>
<t> <t>
A Format A and a Format B LSE MUST be present when a Format D LSE is car ried in the NAS. A Format A and a Format B LSE <bcp14>MUST</bcp14> be present when a Form at D LSE is carried in the NAS.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sect-3.1" numbered="true" toc="default"> <section anchor="sect-3.1" numbered="true" toc="default">
<name>The MNA Sub-Stack</name> <name>The MNA Sub-Stack</name>
<t> <t>
The MNA Sub-Stack MUST begin with a Format A LSE (<xref target="LSE-A"/>). The MNA Sub-Stack <bcp14>MUST</bcp14> begin with a Format A LSE (<xref targe t="LSE-A"/>).
The label value of the LSE contains the MNA bSPL The label value of the LSE contains the MNA bSPL
(value TBA) to indicate the presence of the MNA Sub-Stack. (4) to indicate the presence of the MNA Sub-Stack.
</t> </t>
<t> <t>
The TC and TTL values of the Format A LSE retain their semantics as The TC and TTL values of the Format A LSE retain their semantics as
defined in <xref target="RFC3032" format="default"/> and defined in <xref target="RFC3032" format="default"/> and
<xref target="RFC5462" format="default"/>. The TTL and TC values in the Fo rmat A LSE are copied from the forwarding label at the top of the label stack. <xref target="RFC5462" format="default"/>. The TTL and TC values in the Fo rmat A LSE are copied from the forwarding label at the top of the label stack.
The penultimate node on the path copies the TTL The penultimate node on the path copies the TTL
and TC values from the preceding LSE to the next LSE on the 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, label stack, overwriting the TTL and TC values of the next LSE,
as specified in Section 3.5 of <xref target="RFC3443" format="default"/> a nd Section 2.6.3 of <xref target="RFC3270" format="default"/> as specified in <xref target="RFC3443" section="3.5"/> and <xref target="R FC3270" section="2.6.3"/>
in the Uniform Mode LSPs. If the node performing this copy is not 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 N AS. aware of MNA, this could overwrite the values in the Format-A LSE of the N AS.
</t> </t>
<t> <t>
The second LSE in a NAS MUST be a Format B LSE (<xref The second LSE in a NAS <bcp14>MUST</bcp14> be a Format B LSE (<xref
target="LSE-B"/>). This LSE contains an initial opcode plus target="LSE-B"/>). This LSE contains an initial opcode plus
additional fields that describe the NAS. additional fields that describe the NAS.
</t> </t>
<t> <t>
The Format B LSE (<xref target="LSE-B"/>) could optionally carry additiona l data in The Format B LSE (<xref target="LSE-B"/>) could optionally carry additiona l data in
Format D (<xref target="LSE-D"/>) LSEs, up to the length encoded Format D (<xref target="LSE-D"/>) LSEs, up to the length encoded
in the LSE's NAL value. in the LSE's NAL value.
</t> </t>
<t> <t>
A NAS MAY contain more Format C (<xref target="LSE-C"/>) and A NAS <bcp14>MAY</bcp14> contain more Format C (<xref target="LSE-C"/>) an d
Format D (<xref target="LSE-D"/>) LSEs, up to the length encoded Format D (<xref target="LSE-D"/>) LSEs, up to the length encoded
in the NASL value. All Format D LSEs MUST follow a Format C or B LSE in the NASL value. All Format D LSEs <bcp14>MUST</bcp14> follow a Format C or Format B LSE
and be included in that LSE's NAL value. and be included in that LSE's NAL value.
</t> </t>
<section anchor="Opcodes"> <section anchor="Opcodes">
<name>Opcodes</name> <name>Opcodes</name>
<t> <t>
The opcode is a 7-bit field that indicates the semantics of The opcode is a 7-bit field that indicates the semantics of
its LSE. Several opcodes are assigned special semantics (<xref target="Speci its LSE. Several opcodes are assigned special semantics (<xref target="Speci
alOpcodes"/>), others act as Network Action alOpcodes"/>). Other opcodes act as NAIs and are assigned through IANA (see Sec
Indicators and are assigned through IANA (<xref target="Allocation"/> and <x tions <xref target="Allocation" format="counter"/> and <xref target="IANAOpcodes
ref target="IANAOpcodes"/>). " format="counter"/>).
</t> </t>
</section> </section>
<section anchor="Data"> <section anchor="Data">
<name>Ancillary Data</name> <name>Ancillary Data</name>
<t> <t>
The data field carries opcode-specific data that is ancillary data The data field carries opcode-specific data that is AD
for a network action. for a network action.
In the case of opcode 1, the data field carries In the case of opcode 1, the data field carries
Flag-Based Network Action Indicators without ancillary data. Flag-Based Network Action Indicators without AD.
</t> </t>
<t> <t>
The label value (most significant 20 bits) in one or more consecutive LSEs is commonly used The label value (most significant 20 bits) in one or more consecutive LSEs is commonly used
for load balancing data flows in an ECMP environment. Modifying the first 20 bits in an LSE might alter a for 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 g iven flow. packet's path and result in out-of-order delivery of packets belonging to a g iven flow.
To maintain the stability of deployed services in ECMP environments To maintain the stability of deployed services in ECMP environments
that rely on label value information for load-balancing, care must be taken w hen that rely on label value information for load-balancing, care must be taken w hen
encoding network action data in the given LSE. If the network action data may differ among 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 be placed in the most significant 20 bits packets in the same flow or change during forwarding across the MPLS network, it <bcp14>MUST NOT</bcp14> be placed in the most significant 20 bits
of a Format B LSE of a Format B LSE
(Section 4.2), a Format C LSE (Section 4.3), or a Format D LSE (<xref target="LSE-B"/>), a Format C LSE (<xref target="LSE-C"/>), or a Forma
(Section 4.4). Thus, the available bits for data that can change by t D LSE
(<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 a transit node or differ among packets of the same flow
in Format A and Format B LSEs are 0, Format C LSE is 7 in Format A and Format B LSEs is 0, in a Format C LSE 7
(bits 20-22 and 25-28) and Format D LSE is 11 (bits 20-22 and 24-31). (bits 20-22 and 25-28), and in a Format D LSE 11 (bits 20-22 and 24-31).
</t> </t>
<t> <t>
Similarly, to preserve service stability, Similarly, to preserve service stability,
such data also MUST NOT be carried in such data also <bcp14>MUST NOT</bcp14> be carried in
the most significant 23 bits of these LSEs when the 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 legacy implementation also uses the TC value, in addition to the label value, in all LSEs
when computing ECMP decisions. when computing ECMP decisions.
</t> </t>
<t> <t>
The available mitigations for these problems are to use additional Format D The available mitigations for these problems are to use additional Format D
LSEs to carry the data, or to place the data in Post-Stack Data as LSEs to carry the data or to place the data in Post-Stack Data as
described in <xref target="RFC9789"/>. described in <xref target="RFC9789"/>.
</t> </t>
<t> <t>
In network deployments where it is known that a load-balancing of data flows is not used, In network deployments where it is known that a load-balancing of data flows is not used,
or, otherwise, if only the explicitly signaled entropy value is used, and it is certain 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 o f that the load-balancing path selection will not be based on the label value o f
the LSEs, then the data in the label value of the LSEs in ISD MAY be the LSEs, then the data in the label value of the LSEs in the ISD <bcp14>MAY< /bcp14> be
mutable within the data flow without causing the out-of-order delivery of pac kets. mutable within the data flow without causing the out-of-order delivery of pac kets.
</t> </t>
</section> </section>
<section anchor="Scope"> <section anchor="Scope">
<name>Scope</name> <name>Scope</name>
<t> <t>
The IHS field in the Format B LSE indicates the scope of all the NAIs encode d in the NAS. The IHS field in the Format B LSE indicates the scope of all the NAIs encode d in the NAS.
Scope defines which nodes along the MPLS path should perform the network Scope defines which nodes along the MPLS path should perform the network
skipping to change at line 650 skipping to change at line 683
<th align="left"> Scope </th> <th align="left"> Scope </th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">00</td> <td align="left">00</td>
<td align="left">I2E</td> <td align="left">I2E</td>
</tr> </tr>
<tr> <tr>
<td align="left">01</td> <td align="left">01</td>
<td align="left">HBH</td> <td align="left">HbH</td>
</tr> </tr>
<tr> <tr>
<td align="left">10</td> <td align="left">10</td>
<td align="left">Select</td> <td align="left">Select</td>
</tr> </tr>
<tr> <tr>
<td align="left">11</td> <td align="left">11</td>
<td align="left">Reserved for future use</td> <td align="left">Reserved for future use</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
</t> </t>
<ul empty="true" spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>Ingress to Egress (I2E):</dt><dd>The Network Actions in this NAS <bcp
Ingress To Egress (I2E) - The Network Actions in this NAS MUST NOT be proc 14>MUST NOT</bcp14> be processed by any node except the egress node.</dd>
essed by any node except the egress node. <dt>Hop-by-Hop (HbH):</dt><dd>All nodes along the path <bcp14>MUST</bcp14
</li> > process the NAS.</dd>
<li> <dt>Select:</dt><dd>Only specific nodes along the path that bring NAS to
Hop-By-Hop (HBH) - All nodes along the path MUST process the NAS. the top of the stack will perform the action.</dd>
</li> </dl>
<li>
Select - Only specific nodes along the path that brings NAS to top of the
stack will perform the action.
</li>
</ul>
<t> <t>
A given NAS can only carry NAIs with the same scope (I2E/HBH/Select). To sup A given NAS can only carry NAIs with the same scope (I2E/HbH/Select). To sup
port multiple scopes for a single port multiple scopes for a single
packet, multiple NASes MAY be included in a single label stack. packet, multiple NASes <bcp14>MAY</bcp14> be included in a single label stac
k.
</t> </t>
<t> <t>
The egress node is included in the HBH scope. This implies
that the penultimate node MUST NOT remove a HBH NAS. The <!--[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 scope. This implies
that the penultimate node <bcp14>MUST NOT</bcp14> remove 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 "/>. egress node may receive a NAS at the top of the label stack as discussed in <xref target="sect-J12.1a "/>.
</t> </t>
<t> <t>
An I2E scope NAS, if present, MUST be encoded after any HBH or Select-scope An I2E scope NAS, if present, <bcp14>MUST</bcp14> be encoded after any HbH o r Select-scope
NASes. This makes it easier for the transit nodes to process a NASes. This makes it easier for the transit nodes to process a
NAS with HBH or Select scope. NAS with HbH or Select scope.
</t> </t>
<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. 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> </t>
</section> </section>
<section anchor="UOH"> <section anchor="UOH">
<name>Unknown Network Action Handling</name> <name>Unknown Network Action Handling</name>
skipping to change at line 731 skipping to change at line 770
<td align="left">Skip to the next NA </td> <td align="left">Skip to the next NA </td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">Drop the packet</td> <td align="left">Drop the packet</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
When a packet with an unknown Network Action is dropped, the node should main When a packet with an Unknown Network Action Handling is dropped, the node sh
tain a local counter for this event, and may send a rate-limited notification to ould maintain a local counter for this event and may send a rate-limited notific
the operator. ation to the operator.
</t> </t>
</section> </section>
<section anchor="Ordering"> <section anchor="Ordering">
<name>Ordering</name> <name>Ordering</name>
<t> <t>
The network actions encoded in the NAS MUST be processed in the order The network actions encoded in the NAS <bcp14>MUST</bcp14> be processed in th e order
that they appear in the NAS, from the top of the NAS to the bottom. 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 be processed fr om the NAIs encoded as flags (see <xref target="sect-J5.2b" />) <bcp14>MUST</bcp14> be processed from the
most significant bit to the least significant bit. If a label stack most significant bit to the least significant bit. If a label stack
contains multiple NASes, they MUST be processed in the order that contains multiple NASes, they <bcp14>MUST</bcp14> be processed in the order t hat
they appear in the label stack, subject to the restrictions in they appear in the label stack, subject to the restrictions in
<xref target="Placement" />. <xref target="Placement" />.
</t> </t>
</section> </section>
</section> </section>
<section anchor="SpecialOpcodes" numbered="true" toc="default"> <section anchor="SpecialOpcodes" numbered="true" toc="default">
<name>Special Opcodes</name> <name>Special Opcodes</name>
<t> <t>
Below are the special opcodes defined to build a basic In-stack MNA solution Below are the special opcodes defined to build a basic In-stack MNA solution
and has been assigned through IANA registry (<xref target="IANAOpcodes"/>). and assigned in the "Network Action Opcodes" IANA registry (see <xref target="I
In the future, additional special opcodes can be defined and their code-poin ANAOpcodes"/>).
ts assigned from the "Network Action Opcodes" IANA registry (<xref target="IANAO In the future, additional special opcodes may be defined and their code poin
pcodes"/>). ts assigned from this registry.
</t> </t>
<section> <section>
<name>bSPL Protection</name> <name>bSPL Protection</name>
<dl spacing="normal" newline="false">
<t> <dt>Opcode:</dt><dd>0</dd>
Opcode: 0 <dt>Purpose:</dt><dd>Legacy implementations may scan the label stack
</t> looking for bSPL values. As long as the opcode field is non-zero, an
<t> LSE cannot be misinterpreted as containing a bSPL. Therefore, opcode 0 is
Purpose: Legacy implementations may scan the label stack reserved and not to be used.</dd>
looking for bSPL values. As long as the opcode field is </dl>
non-zero, an LSE cannot be misinterpreted as containing a
bSPL. Opcode 0 is therefore reserved and not to be used.
</t>
</section> </section>
<section anchor="sect-J5.2b" numbered="true" toc="default"> <section anchor="sect-J5.2b" numbered="true" toc="default">
<name>Flag-Based NAIs without AD</name> <name>Flag-Based NAIs Without AD</name>
<t> <dl spacing="normal" newline="false">
Opcode: 1 <dt>Opcode:</dt><dd>1</dd>
</t> <dt>Purpose:</dt><dd>This opcode is used for Network actions that do
<t> not require AD. A single flag can be used to indicate each
Purpose: This opcode is used for Network actions that do not require Ancilla of these network actions.</dd>
ry Data. A single flag can be used to <dt>LSE Formats:</dt><dd>B, C, D</dd>
indicate each of these network actions. <dt>Data:</dt><dd>The data field carries NAIs, which
</t>
<t>
LSE Formats: B, C, D
</t>
<t>
Data: The data field carries Network Action Indicators, which
should be evaluated from the most significant bit to the least should be evaluated from the most significant bit to the least
significant bit. significant bit.
If this opcode is used with LSE Format B only, then up to 13 flags may be ca rried. If this opcode is used with LSE Format B only, then up to 13 flags may be ca rried.
If this opcode is used with LSE Format C only, then up to 20 flags may be ca rried. If this opcode is used with LSE Format C only, then up to 20 flags may be ca rried.
Format D LSEs can be used with format C LSEs to encode more than 20 flags. Format D LSEs can be used with format C LSEs to encode more than 20 flags.
Flags are assigned from the "Network Action Flags Flags are assigned from the "Network Action Flags
Without Ancillary Data" registry (<xref Without Ancillary Data" registry (<xref
target="IANAFlags"/>). If flags need to be evaluated in a target="IANAFlags"/>). If flags need to be evaluated in a
different order, multiple LSEs using this opcode may be used different order, multiple LSEs using this opcode may be used
to specify the requested order. to specify the requested order.
The Flag-Based Network Action Indicators MUST follow the procedure for data The Flag-Based NAIs <bcp14>MUST</bcp14> follow the procedure for data specif
specified in Section 5.2. ied in <xref target="Data"/>.</dd>
</t> <dt>Scope:</dt><dd>This opcode can be used with any scope.</dd>
</dl>
<t>
Scope: This opcode can be used with any scope.
</t>
</section> </section>
<section anchor="sect-J5.2c" numbered="true" toc="default"> <section anchor="sect-J5.2c" numbered="true" toc="default">
<name>No-Operation Opcode</name> <name>No-Operation Opcode</name>
<dl spacing="normal" newline="false">
<t> <dt>Opcode:</dt><dd>2</dd>
Opcode: 2 <dt>Purpose:</dt><dd>This opcode is used to indicate that it
</t> does not perform any Network Action and <bcp14>MUST</bcp14> be
<t> skipped.</dd>
Purpose: This opcode is used to indicate that this opcode does not perform a <dt>LSE Format:</dt><dd>B</dd>
ny Network Action and MUST be skipped. <dt>Scope:</dt><dd>Any scope value may be set and <bcp14>MUST</bcp14> be
</t> ignored.</dd>
</dl>
<t>
LSE Format: B
</t>
<t>
Scope: Any scope value may be set and MUST be ignored.
</t>
</section> </section>
<section anchor="sect-J5.2g" numbered="true" toc="default"> <section anchor="sect-J5.2g" numbered="true" toc="default">
<name>Extension Opcode</name> <name>Extension Opcode</name>
<dl spacing="normal" newline="false">
<t> <dt>Opcode:</dt><dd>127</dd>
Opcode: 127 <dt>Purpose:</dt><dd>This opcode is used to extend the current opcode
</t> range beyond 127 in the future. If this opcode is not supported, then
<t> the packet with opcode 127 <bcp14>MUST</bcp14> be dropped
Purpose: This opcode is used to extend the current opcode regardless of the setting of the U bit. Use of this opcode is outside
range beyond 127 in the future. If this opcode is not supported, then the pa the scope of this document.</dd>
cket with the opcode 127 MUST be dropped </dl>
regardless of the setting of the U bit.
Use of this opcode is outside the scope of this document.
</t>
</section> </section>
</section> </section>
<section anchor="Placement" numbered="true" toc="default"> <section anchor="Placement" numbered="true" toc="default">
<name>NAS placement in the Label Stack</name> <name>NAS Placement in the Label Stack</name>
<t> <t>
The node adding a NAS to the label stack places a copy of the NAS 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 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 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 be placed by a downstream MNA-capable node, then the entire NAS <bcp14>MUST</bcp14> be placed
so that it is within RLD by the time the packet reaches the so that it is within RLD by the time the packet reaches the
downstream MNA-capable node. downstream MNA-capable node.
The RLD of the downstream MNA-capable node MUST be learned as described in Se ction 2.3.1 of <xref target="RFC9789"/>. The RLD of the downstream MNA-capable node <bcp14>MUST</bcp14> be learned as described in <xref target="RFC9789" section="2.3.1"/>.
</t> </t>
<t> <t>
If the label stack is deep, several copies of the NAS may need to be If the label stack is deep, several copies of the NAS may need to be
encoded in the label stack. encoded in the label stack.
</t> </t>
<t> <t>
For a NAS with HBH scope, every node will process the top copy of For a NAS with HbH scope, every node will process the top copy of
the NAS, but the NAS MUST NOT appear at the top of the stack at any the NAS. However, the NAS <bcp14>MUST NOT</bcp14> appear at the top of the s
MNA-incapable node on the path, that is ensured by the encapsulating node usi tack at any
ng the node capability, as described in <xref target="Signaling"/>. MNA-incapable node on the path that is ensured by the encapsulating node usin
g the node capability, as described in <xref target="Signaling"/>.
</t> </t>
<t> <t>
A NAS MUST NOT appear at the top of the stack after popping the forwarding la bel on an MNA-incapable node on the path. A NAS <bcp14>MUST NOT</bcp14> appear at the top of the stack after popping th e forwarding label on an MNA-incapable node on the path.
</t> </t>
<t> <t>
The node behaviour, where a NAS with I2E and HBH scopes is also removed along with popping the forwarding label on a PHP node, is outside the scope of this d ocument. The behavior of a node where a NAS with I2E and HbH scopes is also removed al ong with popping the forwarding label on a PHP 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> <t>
For a NAS with Select scope, it is processed by the node that 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 brings it to the top of the stack (for example, in the case of using
MPLS label pop operation in Segment Routing) and then the NAS is removed from 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 la bel the stack. The select-scoped NAS needs to be inserted after the forwarding la bel
and before the next forwarding label. It could be inserted before or after a and before the next forwarding label. It could be inserted before or after an
HBH NAS. HbH NAS.
Note that the case of a NAS with Select scope with MPLS label swap operation Note that the case of a NAS with Select scope with an MPLS label swap operati
(for example, with RSVP Traffic Engineering LSPs) is for future study. on (for example, with RSVP-TE LSPs) is for future study.
</t> </t>
<t> <t>
For I2E scope, only one copy of the NAS needs to be added at the bottom of th e stack. For I2E scope, only one copy of the NAS needs to be added at the bottom of th e stack.
</t> </t>
<t> <t>
Transit, non-penultimate nodes that pop a forwarding label and expose a copy of a NAS MUST remove it. A transit node that is not the penultimate node that pops a forwarding label and exposes a copy of a NAS <bcp14>MUST</bcp14> remove that NAS.
</t> </t>
<t> <t>
An MNA-capable node performing Penultimate Hop Popping (PHP) that pops the fo rwarding label with only An MNA-capable node performing Penultimate Hop Popping (PHP) that pops the fo rwarding label with only
the NAS(es) remaining on the stack MUST NOT remove the NAS(es). Instead, it f the NAS(es) remaining on the stack <bcp14>MUST NOT</bcp14> remove the NAS(es)
orwards the packet with the NAS(es) at . Instead, it forwards the packet with the NAS(es) at
the top of stack to the next node. the top of the stack to the next node.
Note that the behavior of the PHP node, as defined in <xref target="RFC3270"/ Note that the behavior of the PHP node, as defined in <xref target="RFC3270"/
> for TC processing, and as defined in > for TC processing and as defined in
<xref target="RFC3443"/> for TTL processing, is not modified regardless of wh ether the PHP node supports MNA. <xref target="RFC3443"/> for TTL processing, is not modified regardless of wh ether the PHP node supports MNA.
</t> </t>
<t> <t>
The node that receives the NAS at the top of the label stack MUST process and remove it. The node that receives the NAS at the top of the label stack <bcp14>MUST</bcp 14> process and remove it.
</t> </t>
<section anchor="ActionsWhenPushingLabels" numbered="true" toc="default"> <section anchor="ActionsWhenPushingLabels" numbered="true" toc="default">
<name>Actions when Pushing Labels</name> <name>Actions When Pushing Labels</name>
<t> <t>
An MNA-capable node may need to push additional labels as well as push new n etwork actions onto a received packet. An MNA-capable node may need to push additional labels as well as push new n etwork actions onto a received packet.
</t> </t>
<t> <t>
While pushing additional labels on to the label stack of the received packet While pushing additional labels onto the label stack of the received packet,
, the MNA-capable node MUST the MNA-capable node <bcp14>MUST</bcp14>
verify that the entire top-most NAS with HBH scope is still within the RLD o verify that the entire topmost NAS with HbH scope is still within the RLD of
f the downstream MNA-capable nodes. the downstream MNA-capable nodes.
If required, the MNA-capable node MAY create a copy of the top-most NAS with If required, the MNA-capable node <bcp14>MAY</bcp14> create a copy of the to
HBH scope and insert it within the RLD of the downstream MNA-capable nodes on t pmost NAS with HbH scope and insert it within the RLD of the downstream MNA-capa
he label stack. ble nodes on the label stack.
</t> </t>
<t> <t>
When an MNA-capable node needs to push a new NAS with HBH scope on to a rece When an MNA-capable node needs to push a new NAS with HbH scope on to a rece
ived packet that already has a NAS with HBH scope, ived packet that already has a NAS with HbH scope,
it SHOULD copy (and merge) the network actions (including their Ancillary Da it <bcp14>SHOULD</bcp14> copy (and merge) the network actions (including the
ta) from the received top-most NAS with HBH ir AD) from the received topmost NAS with HbH
scope in the new NAS with HBH scope. The new NAS MUST be placed within the R scope in the new NAS with HbH scope. The new NAS <bcp14>MUST</bcp14> be plac
LD of the downstream MNA-capable nodes. ed within the RLD of the downstream MNA-capable nodes.
This behavior can be based on local policy. This behavior can be based on local policy.
</t> </t>
<t> <t>
The new network actions added MUST NOT conflict with the network actions in The new network actions added <bcp14>MUST NOT</bcp14> conflict with the netw
the received NAS with HBH scope. ork actions in the received NAS with HbH scope.
The mechanism to resolve such conflicts depend on the network actions and ca The mechanism to resolve such conflicts depends on the network actions and c
n be based on local policy. an be based on local policy.
The MNA-capable node that pushes entries MUST understand The MNA-capable node that pushes entries <bcp14>MUST</bcp14> understand
any network actions which it is pushing which may result in a conflict, and any network actions that it is pushing that may result in a conflict and
MUST resolve any conflicts between new and received network actions. In the <bcp14>MUST</bcp14> resolve any conflicts between new and received network a
ctions. In the
usual case of a conflict of duplicating a network action, the definition of usual case of a conflict of duplicating a network action, the definition of
a network action MUST give guidance on conflict resolution. a network action <bcp14>MUST</bcp14> give guidance on conflict resolution.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Signaling" numbered="true" toc="default"> <section anchor="Signaling" numbered="true" toc="default">
<name>Node Capability Signaling</name> <name>Node Capability Signaling</name>
<t> <t>
The encapsulating node MUST make sure that the NAS can be processed by the t The encapsulating node <bcp14>MUST</bcp14> make sure that the NAS can be pro
ransit and egress nodes. cessed by the transit and egress nodes.
In addition, the encapsulated packet MUST NOT exceed the path MTU as describ In addition, the encapsulated packet <bcp14>MUST NOT</bcp14> exceed the path
ed in <xref target="RFC3032"/>. MTU as described in <xref target="RFC3032"/>.
</t> </t>
<ul> <ul>
<li> <li>
The node responsible for selecting a path through the MPLS network needs to know and consider the 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 the MNA-capabilities of t MNA-capabilities and RLD of the transit nodes as well as the MNA-capabilitie
he egress node as s of the egress node as
described in Section 2.3 of <xref target="RFC9789"/>. described in <xref target="RFC9789" section="2.3"/>.
</li> </li>
<li> <li>
Information about the capabilities of the nodes may be configured, collected through management protocols, or distributed by control protocols (such as adve rtising by routing protocols). Information about the capabilities of the nodes may be configured, collected through management protocols, or distributed by control protocols (such as adve rtising by routing protocols).
</li> </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> <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. 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>
<li> <li>
In the case of MPLS Segment Routing (SR-MPLS), as well as the In the case of Segment Routing over MPLS (SR-MPLS), as well as the
RLD, the path computation system needs to know the MSD <xref target="RFC8664 RLD, the path computation system needs to know the Maximum SID Depth (MSD) <
"/> xref target="RFC8664"/>
that can be imposed at the ingress node of a given SR path. This 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 ensures that the label stack depth of a computed path does not
exceed the maximum number of labels (i.e., MSD) the node is exceed the maximum number of labels (i.e., MSD) the node is
capable of imposing and the maximum number of labels that can be capable of imposing and the maximum number of labels that can be
read by the MNA-processing nodes in the path. The MSD MUST include the MNA Sub-Stacks that will be added. read by the MNA-processing nodes in the path. The MSD <bcp14>MUST</bcp14> i nclude the MNA Sub-Stacks that will be added.
</li> </li>
<li> <li>
The encapsulating node MUST learn about the RLD of the nodes in the path as d escribed in Section 2.3.1 of <xref target="RFC9789"/>. The encapsulating node <bcp14>MUST</bcp14> learn about the RLD of the nodes i n the path as described in <xref target="RFC9789" section="2.3.1"/>.
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="sect-J12.1a" numbered="true" toc="default"> <section anchor="sect-J12.1a" numbered="true" toc="default">
<name>Processing the Network Action Sub-Stack</name> <name>Processing the Network Action Sub-Stack</name>
<t> <t>
This section defines the specific responsibilities for nodes This section defines the specific responsibilities for nodes
along an LSP <xref target="RFC3031"/>. along an LSP <xref target="RFC3031"/>.
</t> </t>
<section> <section>
<name> Encapsulating Node Responsibilities </name> <name> Encapsulating Node Responsibilities </name>
<t> <t>
The encapsulating node MAY add NASes to the label stack in The encapsulating node <bcp14>MAY</bcp14> add NASes to the label stack in
accordance with its policies, the placement restrictions in accordance with its policies, the placement restrictions in
<xref target="Placement"/>, and the capabilities learned <xref target="Placement"/>, and the capabilities learned
from <xref target="Signaling"/>. from <xref target="Signaling"/>.
</t> </t>
<t> <t>
If there is an existing label stack, the encapsulating node MUST NOT modif If there is an existing label stack, the encapsulating node <bcp14>MUST NO
y the first 20 bits of T</bcp14> modify the first 20 bits of
any LSE in the label stack when the ECMP technique in the network is using any LSE in the label stack when the ECMP technique in the network uses has
the hashing of the labels on the label stack. hing of the labels on the label stack.
</t> </t>
</section> </section>
<section anchor="Transit-Node-Responsibilities" numbered="true" toc="default " > <section anchor="Transit-Node-Responsibilities" numbered="true" toc="default " >
<name> Transit Node Responsibilities </name> <name> Transit Node Responsibilities </name>
<t> <t>
The transit node is the node that processes a NAS in the Label stack but d oes not push any new NAS. The transit node is the node that processes a NAS in the Label stack but d oes not push any new NAS.
</t> </t>
<t> <t>
The transit node MUST follow the procedure for data specified in Section 5 .2. The transit node <bcp14>MUST</bcp14> follow the procedure for data specifi ed in <xref target="Data"/>.
</t> </t>
<t> <t>
Transit nodes MUST process the NASes in the label stack, Transit nodes <bcp14>MUST</bcp14> process the NASes in the label stack
according to the rules set out in <xref target="Ordering"/>. according to the rules set out in <xref target="Ordering"/>.
</t> </t>
<t> <t>
A transit node that processes a NAS and does not recognize the value of an A transit node that processes a NAS and does not recognize the value of an
opcode MUST follow the rules opcode <bcp14>MUST</bcp14> follow the rules
according to the setting of the Unknown Action Handling value in the NAS a according to the setting of the Unknown Network Action Handling value in t
s described in (<xref target="UOH"/>). he NAS as described in <xref target="UOH"/>.
</t> </t>
</section> </section>
<section> <section>
<name> Penultimate Node Responsibilities </name> <name> Penultimate Node Responsibilities </name>
<t> <t>
In addition to the transit node responsibilities, the In addition to the transit node responsibilities, the
penultimate node and penultimate SR-MPLS segment node MUST NOT remove the la st copy of an HBH or I2E penultimate node and penultimate SR-MPLS segment node <bcp14>MUST NOT</bcp14 > remove the last copy of an HbH or I2E
NAS when it is exposed after removing the forwarding NAS when it is exposed after removing the forwarding
(transport) label. This allows the egress node to process the (transport) label. This allows the egress node to process the
NAS. NAS.
</t> </t>
</section> </section>
<section> <section>
<name> Egress Node Responsibilities </name> <name> Egress Node Responsibilities </name>
<t> <t>
The egress node MUST remove any NAS it receives. The egress node <bcp14>MUST</bcp14> remove any NAS it receives.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Allocation" numbered="true" toc="default"> <section anchor="Allocation" numbered="true" toc="default">
<name>Network Action Indicator Opcode Definition</name> <name>Network Action Indicator Opcode Definition</name>
<t> The following information MUST be defined for a new Network Action Indi
cator opcode request in the document that specifies the Network Action.
</t>
<t> <!--[rfced] May we update this text as follows?
A request for a new NAI opcode MUST include the following information:
</t>
<ul> Original:
<li> The following information MUST be defined for a new Network Action
Format: The definition of the new Network Action MUST Indicator opcode request in the document that specifies the Network
specify the LSE Formats. The opcode can define Network Action in Format Action.
B or C or both Format B and C.
Both Format B and C LSEs MAY optionally carry Format D LSEs. Perhaps:
</li> The following information MUST be defined in documentation for any new
<li> NAI opcode request.
Scope: The definition of the new Network Action MUST specify at -->
least one scope (I2E, HBH, Select) for the Network Action, and MAY <t> The following information <bcp14>MUST</bcp14> be defined for a new NAI
opcode request in the document that specifies the Network Action.
</t>
<dl>
<dt>Format:</dt><dd>The definition of the new Network Action <bcp14>MUST
</bcp14>
specify the LSE formats. The opcode can define Network Action in Format
B or C or both Formats B and C.
Both Format B and C LSEs <bcp14>MAY</bcp14> optionally carry Format D LS
Es.
</dd>
<dt>Scope:</dt><dd>The definition of the new Network Action <bcp14>MUST</bcp
14> specify at
least one scope (I2E, HbH, Select) for the Network Action and <bcp14>MAY</
bcp14>
specify more than one scope. specify more than one scope.
</li> </dd>
<li> <dt>Ancillary Data:</dt><dd>The definition of the new Network Action <bcp14>
Ancillary Data: The definition of the new Network Action MUST MUST</bcp14>
specify the quantity, syntax, and semantics of any associated specify the quantity, syntax, and semantics of any associated
Ancillary Data. The Ancillary Data MAY be variable length, but AD. The AD <bcp14>MAY</bcp14> be variable length, but
the NAL MUST be computable based on the data added in the the NAL <bcp14>MUST</bcp14> be computable based on the data added in the
NAS. NAS.
</li> </dd>
<li> <dt>Processing:</dt><dd>The definition of the new Network Action <bcp14>
Processing: The definition of the new Network Action MUST specify MUST</bcp14> specify
the detailed procedure for processing the network action. the detailed procedure for processing the network action.
</li> </dd>
<li> <dt>Interactions:</dt><dd>The definition of the new Network Action <bcp1
Interactions: The definition of the new Network Action MUST specify its 4>MUST</bcp14> specify its
interaction including merging with other currently defined Network Action if there is any. interaction including merging with other currently defined Network Action if there is any.
</li> </dd>
</ul> </dl>
<t> <t>
An assignment for a NAI MAY make An assignment for a NAI <bcp14>MAY</bcp14> make
requests from any combination of the "Network Action Opcodes" requests from any combination of the "Network Action Opcodes"
or "Network Action Flags Without Ancillary Data" assignments. or "Network Action Flags Without Ancillary Data" assignments (see <xref targ et="sect-J13"/>).
This decision should optimize for eventual This decision should optimize for eventual
encoding efficiency. If the NAI does not require any ancillary encoding efficiency. If the NAI does not require any AD, then a flag is pref
data, then a flag is preferred as only one bit is used in the erred as only one bit is used in the
encoding. encoding.
</t> </t>
</section> </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 impl
emented 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"> <section anchor="sect-J11" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
The security considerations in <xref target="RFC3032" format="default"/> a nd <xref target="RFC9789" format="default"/> also apply to this document. The security considerations in <xref target="RFC3032" format="default"/> a nd <xref target="RFC9789" format="default"/> also apply to this document.
</t> </t>
<t> <t>
In addition, MNA creates a new dimension in security In addition, MNA creates a new dimension in security
concerns: concerns:
</t> </t>
<ul> <ul>
<li> <li>
The actions of an encapsulating node can affect any or all The actions of an encapsulating node can affect any or all
of the nodes along the path. In the most common and benign of the nodes along the path. In the most common and benign
situations, such as a syntactically incorrect packet situations, a syntactically incorrect packet
could result in packet loss or corruption. could result in packet loss or corruption, for example.
</li> </li>
<li> <li>
The semantics of a network action are unbounded and may be The semantics of a network action are unbounded and may be
insecure. A network action could be defined that made insecure. A network action could be defined that makes
arbitrary changes to the memory of the forwarding router, arbitrary changes to the memory of the forwarding router,
which could then be used by the encapsulating node to which could then be used by the encapsulating node to
compromise every MNA-capable router in the network. compromise every MNA-capable router in the network.
</li> </li>
<li> <li>
The MNA architecture supports locally-defined network The MNA architecture supports locally defined network
actions. For such actions, there will be limited oversight actions. For such actions, there will be limited oversight
to ensure that the semantics do not create security to ensure that the semantics do not create security
issues. Implementors and network operators will need to issues. Implementors and network operators will need to
ensure that even the locally-defined network actions do not ensure that even the locally defined network actions do not
compromise the security of the network by following the security considera tions specified in this document. compromise the security of the network by following the security considera tions specified in this document.
</li> </li>
<li> <li>
The MPLS domain border nodes MUST ensure that the MPLS packets with MNA from The MPLS domain border nodes <bcp14>MUST</bcp14> ensure that the MPLS packet s with MNA from
any domain with a different administrative control can be any domain with a different administrative control can be
filtered to prevent entering the provider MPLS domain. The filtering capabil filtered to prevent entering the provider MPLS domain. The filtering capabil
ity MAY be enabled on a per network ity <bcp14>MAY</bcp14> be enabled on a per-network-action basis, and it can be b
action basis and it can be based on a local policy. ased on a local policy.
The filtering capability MUST be implemented on those nodes before deploying The filtering capability <bcp14>MUST</bcp14> be implemented on those nodes b
MNA in the provider MPLS domain. efore deploying MNA in the provider MPLS domain.
The RLD on the filtering node MUST be higher than the RLD on all other nodes The RLD on the filtering node <bcp14>MUST</bcp14> be higher than the RLD on
in the provider MPLS domain. all other nodes in the provider MPLS domain.
</li> </li>
<li> <li>
The MNA architecture supports modifying the AD on the intermediate nodes, so The MNA architecture supports modifying the AD on the intermediate nodes so
the critical network the critical network
functions should either not rely on the data or should be aware of the risks functions 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. and use other means to verify the security of the whole network.
</li> </li>
<li> <li>
The "private Use" opcodes in "Network Action Opcodes" <xref target="IANAOpco The "Private Use" opcodes in the "Network Action Opcodes" registry (see <xre
des"/> f target="IANAOpcodes"/>)
and "Network Action Flags Without Ancillary Data" <xref target="IANAFlags"/> and the "Network Action Flags Without Ancillary Data" registry (see <xref ta
Registry are subject to the considerations described in <xref target="RFC8126"/ rget="IANAFlags"/>) are subject to the considerations described in <xref target
>. ="RFC8126"/>.
</li> </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> <li>
System designers must be aware that information included in Ancillary System designers must be aware that information included in AD may be transmi
Data may be transmitted "in the clear." Network actions that require tted "in the clear". Network actions that require
the exchange of sensitive data, must be defined in such a way that 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 trans the data is encrypted in transit. Otherwise, sensitive data <bcp14>MUST NOT</
mitted using these mechanisms. bcp14> be transmitted using these mechanisms.
</li> </li>
<li> <li>
Mis-delivery of a packet due to malformed forwarding action data could be con sidered a security risk. Mis-delivery of a packet due to malformed forwarding action data could be con sidered a security risk.
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="sect-J11b" numbered="true" toc="default"> <section anchor="sect-J11b" numbered="true" toc="default">
<name>Operational Considerations</name> <name>Operational Considerations</name>
<section anchor="sect-Manag-J11b" numbered="true" toc="default"> <section anchor="sect-Manag-J11b" numbered="true" toc="default">
<name>Manageability Considerations</name> <name>Manageability Considerations</name>
<t> <t>
An MNA implementation MAY collect the following counters: An MNA implementation <bcp14>MAY</bcp14> collect the following counters:
</t> </t>
<ul> <ul>
<li> <li>
Packets with MNA received Packets with MNA received
</li> </li>
<li> <li>
MNA sub-stacks processed MNA sub-stacks processed
</li> </li>
<li> <li>
MNA per-network-action counters MNA per-network-action counters
skipping to change at line 1222 skipping to change at line 1249
</li> </li>
<li> <li>
Packets with MNA skipped due to unknown actions Packets with MNA skipped due to unknown actions
</li> </li>
<li> <li>
Packets with MNA dropped due to malformed NAS Packets with MNA dropped due to malformed NAS
</li> </li>
</ul> </ul>
<t> <t>
Additionally, tracking both successful invocations and failures for each spe Additionally, tracking both successful invocations and failures for each spe
cific Network Action, are RECOMMENDED to provide granular visibility. cific Network Action is <bcp14>RECOMMENDED</bcp14> to provide granular visibilit
Nodes MAY generate rate-limited notifications or alarms for significant oper y.
ational events, such as sustained high rates of MNA packet drops, Nodes <bcp14>MAY</bcp14> generate rate-limited notifications or alarms for s
ignificant operational events, such as sustained high rates of MNA packet drops
or
frequent encounters of malformed MNA sub-stacks, to alert operators to poten tial issues. frequent encounters of malformed MNA sub-stacks, to alert operators to poten tial issues.
Comprehensive logging of MNA processing details and outcomes can aid in the network diagnostics and post-mortem analysis. Comprehensive logging of MNA processing details and outcomes can aid in the network diagnostics and post-mortem analysis.
</t> </t>
</section> </section>
<section anchor="sect-Perf-J11b" numbered="true" toc="default"> <section anchor="sect-Perf-J11b" numbered="true" toc="default">
<name>Performance and Scale Considerations </name> <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> <t>
The considerations for performance and scale assessments are outside the s cope of this document but are encouraged to be addressed in the MNA application documents. The considerations for performance and scale assessments are outside the s cope of this document but are encouraged to be addressed in the MNA application documents.
</t> </t>
</section> </section>
<section anchor="sect-J12" numbered="true" toc="default"> <section anchor="sect-J12" numbered="true" toc="default">
<name>Backward Compatibility</name> <name>Backward Compatibility</name>
<t> <t>
This section discusses interactions between MNA-capable and This section discusses interactions between MNA-capable and
MNA-incapable nodes. MNA-incapable nodes.
</t> </t>
<t> <t>
An MNA-encapsulating node MUST ensure that the MPLS An MNA encapsulating node <bcp14>MUST</bcp14> ensure that the MPLS
Network Action Sub-Stack indicator is not at the top of the MPLS label 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 stack when the packet arrives at an MNA-incapable node. If such
a packet did arrive at an MNA-incapable node, it 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"/>. will most likely be dropped as described in <xref target="RFC7325" section ="2.1.1"/>.
</t> </t>
<t> <t>
Any node could scan the label stack, potentially looking for a label value containing a bSPL. To ensure that the LSE formats 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 described herein do not appear to contain a bSPL value, the
opcode value of 0 has been reserved. By ensuring that there is a opcode value of 0 has been reserved. By ensuring that there is a
non-zero value in the high order 7 bits, we are assured that the non-zero value in the high-order 7 bits, we are assured that the
high order 20 bits cannot be misinterpreted as containing a bSPL high-order 20 bits cannot be misinterpreted as containing a bSPL
value (0-15). value (0-15).
</t> </t>
<t> <t>
The TC and TTL values of the Format A LSE are not re-purposed The TC and TTL values of the Format A LSE are not repurposed
for encoding, as the penultimate node on the MPLS packet path for encoding, as the penultimate node on the MPLS packet path
may propagate TTL from the transport (or forwarding) label to may propagate TTL from the transport (or forwarding) label to
the next label on the label stack, overwriting the TTL on the the next label on the label stack, overwriting the TTL on the
next label. If the penultimate node is a legacy node, it might next label. If the penultimate node is a legacy node, it might
perform this action, potentially corrupting other values stored perform this action, potentially corrupting other values stored
in the TC and TTL values. To protect against this, we retain the in the TC and TTL values. To protect against this, we retain the
TC and TTL values in the Format A LSE. TC and TTL values in the Format A LSE.
</t> </t>
<t> <t>
When adding the Entropy Label Indicator (ELI) (bSPL 7) and Entropy 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 be Label (EL) as defined in <xref target="RFC6790"/>, along with an MNA NAS, the RLD <bcp14>MUST</bcp14> be
considered for the placement of both, and they both can be placed in any o rder. considered for the placement of both, and they both can be placed in any o rder.
If a transit LSR chooses to use If a transit LSR chooses to use
as much of the whole label stack as feasible as keys for the load-balancin as much of the whole label stack as feasible as a key for the load-balanci
g function, ng function,
the MNA reserved label MUST NOT be used as a key for the load-balancing fu the MNA-reserved label <bcp14>MUST NOT</bcp14> be used as a key for the lo
nction, as specified in Section 4.3 of <xref target="RFC6790"/>. ad-balancing function, as specified in <xref target="RFC6790" section="4.3"/>.
Note that the behavior of an MNA-incapable transit LSR that scans the labe l stack for Note that the behavior of an MNA-incapable transit LSR that scans the labe l stack for
ELI and EL but encounters a different, unrecognized reserved label first, is not modified ELI and EL but encounters a different, unrecognized reserved label first, is not modified
by this document. by this document.
</t> </t>
<t> <t>
Similarly, when adding the Flow-ID Label Indicator (FLI) (including the ex tension label 15) and Similarly, when adding the Flow-ID Label Indicator (FLI) (including the ex tension label 15) and
Flow-ID Label (FL) as defined in <xref target="RFC9714"/>, along with an M NA NAS, the RLD MUST be Flow-ID Label (FL) as defined in <xref target="RFC9714"/>, along with an M NA NAS, the RLD <bcp14>MUST</bcp14> be
considered for the placement of both, and they both can be placed in any o rder. considered for the placement of both, and they both can be placed in any o rder.
Note that the behavior of an MNA-incapable transit LSR that scans the labe l stack for Note that the behavior of an MNA-incapable transit LSR that scans the labe l stack for
FLI (including the extension label 15) and FL, but encounters a different, unrecognized reserved label first, is not modified FLI (including the extension label 15) and FL, but encounters a different, unrecognized reserved label first, is not modified
by this document. by this document.
</t> </t>
<t> <t>
However, as the existing behavior is not specified for transit LSRs, upon encountering any unrecognized bSPLs However, as the existing behavior is not specified for transit LSRs, upon encountering any unrecognized bSPLs
or eSPLs below the top of the label stack, or extended SPLs (eSPLs) below the top of the label stack,
some existing implementations may have chosen to implement non-standardize d actions, such as discarding packets. some existing implementations may have chosen to implement non-standardize d actions, such as discarding packets.
Any uses of a new bSPL or eSPL would cause issues with such existing Any uses of a new bSPL or eSPL would cause issues with such existing
implementations using the non-standardized actions upon encountering implementations using the non-standardized actions upon encountering
unrecognized bSPLs or eSPLs below the top of the label stack. Since this i s a generic problem, any unrecognized bSPLs or eSPLs below the top of the label stack. Since this i s a generic problem, any
clarifications for the treatment of unrecognized bSPL or clarifications for the treatment of unrecognized bSPL or
eSPL are outside the scope of this document. eSPL are outside the scope of this document.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sect-J13" numbered="true" toc="default"> <section anchor="sect-J13" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="sect-J13.6" numbered="true" toc="default"> <section anchor="sect-J13.6" numbered="true" toc="default">
<name>MNA bSPL Label</name> <name>MNA bSPL Label</name>
<t> <t>
This document requests that IANA allocate a value (TBA) for IANA has allocated the value 4 for
the MNA bSPL label from the "Base Special-Purpose MPLS Label the MNA bSPL label from the "Base Special-Purpose MPLS Label
Values" registry to indicate the presence of an MNA Sub-Stack in Values" registry to indicate the presence of an MNA Sub-Stack in
the label stack. The description of the value should be "MPLS the label stack. The description of the value is "MPLS
Network Actions". The reference should be this document. Network Actions".
</t> </t>
</section> </section>
<section> <section>
<name>MPLS Network Actions Parameters</name> <name>MPLS Network Actions Parameters</name>
<!--[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.
-->
<t> <t>
This document requests that IANA create a new registry group IANA has created a registry group
called "MPLS Network Actions Parameters" within the called "MPLS Network Actions" within the
"Multiprotocol Label Switching Architecture (MPLS)" category. "Multiprotocol Label Switching Architecture (MPLS)" category.
The registries described below should belong to This registry group contains the "Network Action Flags Without Ancillary Dat
this new registry group. a" registry (see <xref target="IANAFlags"/>) and the "Network Action Opcodes" re
gistry (see <xref target="IANAOpcodes" />).
</t> </t>
</section>
<section anchor="IANAFlags"> <section anchor="IANAFlags">
<name>Network Action Flags Without Ancillary Data</name> <name>Network Action Flags Without Ancillary Data</name>
<t> <t>
This document requests that IANA create a new registry with For the "Network Action Flags Without Ancillary
the name "Network Action Flags Without Ancillary Data" registry, registration requests should comply with <xref
Data". Registration requests should comply with <xref target="Allocation"/>. Depending on the range, the registration procedure f
target="Allocation"/>. The registration procedure for this or this
registry is "IETF Review", "Experimental Use" and "Private Use" as defined i registry is "IETF Review", "Experimental Use", or "Private Use" (as defined
n <xref target="RFC8126"/>. The fields in this registry are in <xref target="RFC8126"/>). The fields in this registry are
"Bit Position" (integer), "Description" (string), and "Bit Position" (integer), "Description" (string), and
"Reference" (string). "Reference" (string).
</t> </t>
<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 Bit Position refers to the position relative to the most
significant bit in LSE Format B or C Data fields and any significant bit in LSE Format B or C Data fields and any
subsequent Format D LSEs. Bit Position 0 is the most subsequent Format D LSEs. Bit Position 0 is the most
significant bit in an LSE Format B or C Data field. Bit Position 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 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 field. There are 20 bits available in LSE Format C and 30 bits
available in LSE Format D. There are at most 14 Format D LSEs available in LSE Format D. There are, at most, 14 Format D LSEs
per opcode (due to NASL limit of 15 and Format D requires Format C LSE), so per opcode (due to the NASL limit of 15 and Format D requires Format C LSE),
there are at most 20 + 14 * 30 = 440 bit so there are at most 20 + 14 * 30 = 440 bit
positions. The Bit Position is an integer with value 0-439. positions. The value listed in the Bit Position column is an integer with va
lue between 0-439.
</t> </t>
<t> <t>
The registration procedures for the code points allocation for this registry The registration procedures for code point allocation for this registry are
are defined in <xref target="iana-nafif-tbl-1"/>: defined in <xref target="iana-nafif-tbl-1"/>:
</t> </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"> <table anchor="iana-nafif-tbl-1" align="center">
<name>Network Action Flags Without Ancillary Data Registry</name> <name>Registration Procedures for the "Network Action Flags Without Anci llary Data" Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left"> Bit Position</th> <th align="left">Range</th>
<th align="left"> Description</th> <th align="left">Registration Procedure</th>
<th align="left"> Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0-14</td> <td align="left">0-14</td>
<td align="left">IETF Review </td> <td align="left">IETF Review </td>
<td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">15-16</td> <td align="left">15-16</td>
<td align="left">Experimental Use</td> <td align="left">Experimental Use</td>
<td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">17-19</td> <td align="left">17-19</td>
<td align="left">Private Use</td> <td align="left">Private Use</td>
<td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">20-439</td> <td align="left">20-439</td>
<td align="left">IETF Review</td> <td align="left">IETF Review</td>
<td align="left">This document</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="IANAOpcodes" numbered="true" toc="default"> <section anchor="IANAOpcodes" numbered="true" toc="default">
<name> Network Action Opcodes</name> <name> Network Action Opcodes</name>
<!--[rfced] We had some questions related to the following text:
Original:
Registration requests 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> <t>
This document requests that IANA create a new registry with For the "Network Action Opcodes" registry, registration requests
the name "Network Action Opcodes". Registration requests should comply with <xref target="Allocation"/> as well as security review. D
should comply with <xref target="Allocation"/> as well as security review. T epending on the range, the registration procedure for this registry is "IETF Rev
he iew", "Experimental Use", or "Private Use" (as defined in <xref target="RFC8126"
registration procedure for this registry is "IETF Review", "Experimental Use />). The
" and "Private Use" as defined in <xref target="RFC8126"/>. The
fields are "Opcode" (integer), "Description" (string), and fields are "Opcode" (integer), "Description" (string), and
"Reference" (string). Opcode is an integer with value 1-126. "Reference" (string). Opcode is an integer with value 1-126.
</t> </t>
<table anchor="iana-is-fioc-reg-tbl" align="center"> <table anchor="iana-is-fioc-reg-tbl" align="center">
<name> Network Action Opcodes Registry</name> <name>Registration Procedures for the "Network Action Opcodes" Registry< /name>
<thead> <thead>
<tr> <tr>
<th align="left">Opcode</th> <th align="left">Range</th>
<th align="center">Description</th> <th align="center">Registration Procedure</th>
<th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">1-110</td> <td align="left">1-110</td>
<td align="left">IETF Review </td> <td align="left">IETF Review </td>
<td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">111-114</td> <td align="left">111-114</td>
<td align="left">Experimental Use</td> <td align="left">Experimental Use</td>
<td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">115-126</td> <td align="left">115-126</td>
<td align="left">Private Use</td> <td align="left">Private Use</td>
<td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">127</td> <td align="left">127</td>
<td align="left">IETF Review </td> <td align="left">IETF Review </td>
<td align="left">This document</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
IANA has allocated values for the following Network Action Opcodes from the "Net work Action Opcodes" registry. IANA has allocated values for the following Network Action Opcodes from the "Net work Action Opcodes" registry.
</t> </t>
<table anchor="iana-is-fioc-reg-tbl-values" align="center"> <table anchor="iana-is-fioc-reg-tbl-values" align="center">
<name>Network Action Opcodes </name> <name>Initial Contents of the "Network Action Opcodes" Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Opcode</th> <th align="left">Opcode</th>
<th align="center">Description</th> <th align="center">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="left">This document</td> <td align="left">RFC 9994</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">Flag-Based Network Action Indicators without AD</td > <td align="left">Flag-Based Network Action Indicators without AD</td >
<td align="left">This document</td> <td align="left">RFC 9994</td>
</tr> </tr>
<tr> <tr>
<td align="left">2</td> <td align="left">2</td>
<td align="left">No operation Opcode</td> <td align="left">No operation Opcode</td>
<td align="left">This document</td> <td align="left">RFC 9994</td>
</tr> </tr>
<tr> <tr>
<td align="left">127</td> <td align="left">127</td>
<td align="left">Opcode Range Extension Beyond 127</td> <td align="left">Opcode Range Extension Beyond 127</td>
<td align="left">This document</td> <td align="left">RFC 9994</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
&RFC2119; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.
&RFC3032; xml"/>
&RFC3270; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.
&RFC3443; xml"/>
&RFC5462; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3270.
&RFC6790; xml"/>
&RFC8126; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3443.
&RFC8174; xml"/>
&RFC9017; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5462.
xml"/>
&RFC9789; <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>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
&RFC3031; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.
&RFC6291; xml"/>
&RFC7325; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6291.
&RFC7942; xml"/>
&RFC8664; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7325.
&RFC9613; xml"/>
&RFC9714; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8664.
&RFC9791; 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>
</references> </references>
<section anchor="sect-J14" numbered="true" toc="default"> <section anchor="sect-J14" numbered="true" toc="default">
<name>Examples</name> <name>Examples</name>
<section anchor="sect-J7" numbered="true" toc="default"> <section anchor="sect-J7" numbered="true" toc="default">
<name>Network Action Encoding Examples</name> <name>Network Action Encoding Examples</name>
<section anchor="sect-J7.1" numbered="true" toc="default"> <section anchor="sect-J7.1" numbered="true" toc="default">
<name>Network Action Flags without AD</name> <name>Network Action Flags Without AD</name>
<figure anchor="In-stack-Ext-Hdr-1-a"> <figure anchor="In-stack-Ext-Hdr-1-a">
<name>NAS with Network Action Flags</name> <name>NAS with Network Action Flags</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA-Label=bSPL | TC |S| TTL | | MNA-Label=bSPL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1 | 13-bit Flags |R|IHS|S|NASL=0 |U|NAL=0| | Opcode=1 | 13-bit Flags |R|IHS|S|NASL=0 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
This is an example of a NAS with Flag-Based NAIs without This is an example of a NAS with Flag-Based NAIs without
Ancillary Data. AD.
</t> </t>
<t> <t>
Details: Details:
</t> </t>
<ul empty="true" spacing="normal"> <dl spacing="normal" newline="false">
<li> Opcode=1: This opcode to indicates that the LSE carries Flag-Base <dt>Opcode=1:</dt><dd>This opcode indicates that the LSE carries Flag-
d NAIs without AD. </li> Based NAIs without AD. </dd>
<li> Data: The data field carries the Flag-Based NAIs. </li> <dt>Data:</dt><dd>The data field carries the Flag-Based NAIs. </dd>
<li> <dt>S:</dt><dd>This is the bottom of the stack bit. Set if and only if
S: This is the bottom of stack bit. Set if and only if this LSE is the bottom of the stack.</dd>
this LSE is the bottom of the stack. <dt>U:</dt><dd>Action to be taken if one of the NAIs is not recognized
</li> by the processing node.</dd>
<li> U: Action to be taken if one of the NAIs are not recognized by th <dt>NASL:</dt><dd>The NASL value is set to 0, as there are no addition
e processing node.</li> al LSEs. </dd>
<li> NASL: The NASL value is set to 0, as there are no additional LSEs <dt>NAL:</dt><dd>The NAL value is set to 0, as there are no additional
. </li> AD encoded using Format D. </dd>
<li> NAL: The NAL value is set to 0, as there are no additional AD enc </dl>
oded using Format D. </li>
</ul>
<figure anchor="In-stack-Ext-Hdr-1-a-ext"> <figure anchor="In-stack-Ext-Hdr-1-a-ext">
<name>Network Action Flags without AD using LSE Format D</name> <name>Network Action Flags Without AD Using LSE Format D</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA-Label=bSPL | TC |S| TTL | | MNA-Label=bSPL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=2 | Data=0 |R|IHS|S|NASL=2 |U|NAL=0| | Opcode=2 | Data=0 |R|IHS|S|NASL=2 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1 | Flag-Based NAIs |S| NAIs |U|NAL=1| | Opcode=1 | Flag-Based NAIs |S| NAIs |U|NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Additional Flag-Based NAIs |S|Flag-Based-NAIs| |1| Additional Flag-Based NAIs |S|Flag-Based-NAIs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
In this example, the NAS contains a Format B LSE with No-Operation Opcode va lue 2. The next LSE uses Format C, but 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 the Network Action Flag is not in a bit position contained
within the Format C LSE, so a single Format D LSE has been within the Format C LSE, so a single Format D LSE has been
added to the NAS to carry the flag. added to the NAS to carry the flag.
</t> </t>
<t> <t>
NAL is set to 1 to indicate that Flag-Based NAIs are also NAL is set to 1 to indicate that Flag-Based NAIs are also
encoded in the next LSE. encoded in the next LSE.
</t> </t>
<t> <t>
NASL is set to 2 to indicate that 2 additional LSEs are NASL is set to 2 to indicate that two additional LSEs are
used. used.
</t> </t>
</section> </section>
<section anchor="sect-J7.2" numbered="true" toc="default"> <section anchor="sect-J7.2" numbered="true" toc="default">
<name>Network Action Opcode with AD </name> <name>Network Action Opcode with AD </name>
<figure anchor="In-stack-Ext-Hdr-2a"> <figure anchor="In-stack-Ext-Hdr-2a">
<name>Network action opcode with Ancillary Data</name> <name>Network Action Opcode with Ancillary Data</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA-Label=bSPL | TC |S| TTL | | MNA-Label=bSPL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=8 | Ancillary Data |R|IHS|S|NASL=0 |U|NAL=0| | Opcode=8 | Ancillary Data |R|IHS|S|NASL=0 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
In this example, the NAS is carrying only one Network In this example, the NAS is carrying only one Network
Action that requires 13 bits of Ancillary Data. Action that requires 13 bits of AD.
</t> </t>
<t> <t>
Details on the Second LSE Details on the Second LSE:
</t> </t>
<ul empty="true" spacing="normal"> <dl spacing="normal" newline="false">
<li> Opcode=8: A network action allocation is outside of this document <dt>Opcode=8:</dt><dd>A network action allocation is outside of this d
.</li> ocument.</dd>
<li> Data: The data field contains 13 bits of ancillary data. </li> <dt>Data:</dt><dd>The data field contains 13 bits of AD.</dd>
</ul> </dl>
</section> </section>
<section anchor="sect-J7.4.a" numbered="true" toc="default"> <section anchor="sect-J7.4.a" numbered="true" toc="default">
<name>Network Action Opcode with more AD with Format-B</name> <name>Network Action Opcode with More AD with Format-B</name>
<t> <t>
A network action may require more Ancillary Data than can fit A network action may require more AD than can fit
in a single LSE. In this example, a Format D LSE is added to in a single LSE. In this example, a Format D LSE is added to
carry additional Ancillary Data. carry additional AD.
</t> </t>
<figure anchor="In-stack-Ext-Hdr-Format-4-with-more-AD.a"> <figure anchor="In-stack-Ext-Hdr-Format-4-with-more-AD.a">
<name>Network Action With Additional Ancillary Data</name> <name>Network Action with Additional Ancillary Data</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA-Label=bSPL | TC |S| TTL | | MNA-Label=bSPL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=10 | Ancillary Data |R|IHS|S|NASL=1 |U|NAL=1| | Opcode=10 | Ancillary Data |R|IHS|S|NASL=1 |U|NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Ancillary Data |S|Ancillary Data | |1| Ancillary Data |S|Ancillary Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
In this example, opcode 10 is encoded in Format B and it requires more than In this example, opcode 10 is encoded in Format B, and it requires more than
one LSE's worth of one LSE's worth of
Ancillary Data, so a Format D LSE is added. AD, so a Format D LSE is added.
</t> </t>
<t> <t>
Details on the second LSE: Details on the second LSE:
</t> </t>
<ul empty="true" spacing="normal"> <dl spacing="normal" newline="false">
<li> Opcode=10: An opcode allocation is outside of this document.</li> <dt>Opcode=10:</dt><dd>An opcode allocation is outside of this document.
<li> Ancillary Data: Ancillary data required to process the Network Acti </dd>
on opcode 10.</li> <dt>Ancillary Data:</dt><dd>AD required to process the Network Action op
<li> NAL: Length of additional LSEs used to encode its Ancillary data.</ code 10.</dd>
li> <dt>NAL:</dt><dd>Length of additional LSEs used to encode its AD.</dd>
</ul> </dl>
<t> Details on the third LSE: </t> <t> Details on the third LSE: </t>
<ul empty="true" spacing="normal"> <dl spacing="normal" newline="false">
<li> Ancillary Data: 22 bits of additional Ancillary data.</li> <dt>Ancillary Data:</dt><dd>22 bits of additional AD.</dd>
<li> Ancillary Data: 8 bits of additional Ancillary Data.</li> <dt>Ancillary Data:</dt><dd>8 bits of additional AD.</dd>
</ul> </dl>
</section> </section>
<section anchor="sect-J7.4.b" numbered="true" toc="default"> <section anchor="sect-J7.4.b" numbered="true" toc="default">
<name>Network Action Opcode with more AD with Format C</name> <name>Network Action Opcode with More AD with Format C</name>
<t> <t>
A network action may require more Ancillary Data than can fit A network action may require more AD than can fit
in a single LSE. In this example, a Format D LSE is added to in a single LSE. In this example, a Format D LSE is added to
carry additional Ancillary Data. carry additional AD.
</t> </t>
<figure anchor="In-stack-Ext-Hdr-Format-4-with-more-AD.b"> <figure anchor="In-stack-Ext-Hdr-Format-4-with-more-AD.b">
<name>Network Action With Additional Ancillary Data</name> <name>Network Action with Additional Ancillary Data</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA-Label=bSPL | TC |S| TTL | | MNA-Label=bSPL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=2 | Data=0 |R|IHS|S|NASL=2 |U|NAL=0| | Opcode=2 | Data=0 |R|IHS|S|NASL=2 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=9 | Ancillary Data |S| AD |U|NAL=1| | Opcode=9 | Ancillary Data |S| AD |U|NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Ancillary Data |S|Ancillary Data | |1| Ancillary Data |S|Ancillary Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
In this example, opcode 9 requires more than one LSE's worth of In this example, opcode 9 requires more than one LSE's worth of
Ancillary Data, so a Format D LSE is added. AD, so a Format D LSE is added.
</t> </t>
<t> <t>
Details on the third LSE: Details on the third LSE:
</t> </t>
<ul empty="true" spacing="normal"> <dl spacing="normal" newline="false">
<li> Opcode=9: An opcode allocation is outside of this document</li> <dt>Opcode=9:</dt><dd>An opcode allocation is outside of this document</
<li> Ancillary Data: Most significant bits of Ancillary data</li> dd>
<li> AD: 4 bits of additional Ancillary Data</li> <dt>Ancillary Data:</dt><dd>Most significant bits of AD</dd>
</ul> <dt>AD:</dt><dd>4 bits of additional AD</dd>
</dl>
<t> Details on the fourth LSE: </t> <t> Details on the fourth LSE: </t>
<ul empty="true" spacing="normal"> <dl spacing="normal" newline="false">
<li> Ancillary Data: 22 bits of additional Ancillary data.</li> <dt>Ancillary Data:</dt><dd>22 bits of additional AD.</dd>
<li> Ancillary Data: 8 bits of additional Ancillary Data.</li> <dt>Ancillary Data:</dt><dd>8 bits of additional AD.</dd>
</ul> </dl>
</section> </section>
</section> </section>
<section anchor="sect-J6.a" numbered="true" toc="default"> <section anchor="sect-J6.a" numbered="true" toc="default">
<name>Network Action Processing Order</name> <name>Network Action Processing Order</name>
<t> <t>
The semantics of a network action can vary widely and the The semantics of a network action can vary widely and the
results of processing one network action may affect the results of processing one network action may affect the
processing of a subsequent network action. See <xref processing of a subsequent network action. See <xref
target="Ordering"/>. target="Ordering"/>.
</t> </t>
<section anchor="sect-J6.a1" numbered="true" toc="default"> <section anchor="sect-J6.a1" numbered="true" toc="default">
<name>Network Action Processing Order</name> <name>Network Action Processing Order</name>
<figure anchor="In-stack-NA-Ordering-1"> <figure anchor="In-stack-NA-Ordering-1">
<name>In-stack NA processing order</name> <name>In-Stack NA Processing Order</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA-Label=bSPL | TC |S| TTL | | MNA-Label=bSPL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=8 | Ancillary Data |R|IHS|S|NASL=2 |U|NAL=0| | Opcode=8 | Ancillary Data |R|IHS|S|NASL=2 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=7 | Ancillary Data7 |S| AD7 |U|NAL=0| | Opcode=7 | Ancillary Data7 |S| AD7 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1 | Flag-Based NAIs |S| NAI |U|NAL=0| | Opcode=1 | Flag-Based NAIs |S| NAI |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
In this example, opcode 8 is processed first, then opcode 7, In this example, opcode 8 is processed first, then opcode 7,
and then the network action flags are processed from most and then the network action flags are processed from most
significant to least significant. significant to least significant.
</t> </t>
<t> <t>
In a different case, some Flag-Based NAIs may need to be In a different case, some Flag-Based NAIs may need to be
processed before opcode 7 and some Flag-Based NAIs processed before opcode 7, and some Flag-Based NAIs
may need to be processed after Opcode 7. This can be done may need to be processed after opcode 7. This can be done
by causing some NAIs to appear earlier in the NAS. by causing some NAIs to appear earlier in the NAS.
</t> </t>
<figure anchor="In-stack-NA-Ordering-2"> <figure anchor="In-stack-NA-Ordering-2">
<name>Interleaving network actions</name> <name>Interleaving Network Actions</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA-Label=bSPL | TC |S| TTL | | MNA-Label=bSPL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=8 | Ancillary Data |R|IHS|S|NASL=3 |U|NAL=0| | Opcode=8 | Ancillary Data |R|IHS|S|NASL=3 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1 | 0x01 |S| NAI |U|NAL=0| | Opcode=1 | 0x01 |S| NAI |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=7 | Ancillary Data7 |S| AD7 |U|NAL=0| | Opcode=7 | Ancillary Data7 |S| AD7 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1 | 0x02 |S| NAI |U|NAL=0| | Opcode=1 | 0x02 |S| NAI |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
In the above example, opcode 8 is processed first, then In the above example, opcode 8 is processed first, then
Flag-Based NAI 0x01 is processed, then opcode 7 is processed, and Flag-Based NAI 0x01 is processed, then opcode 7 is processed, and
finally NAI 0x02 is processed. finally NAI 0x02 is processed.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments" toc="default"> <section numbered="false" anchor="acknowledgments" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t> <t>
The authors of this document would like to thank the MPLS The authors of this document would like to thank the MPLS Working Group
Working Group Open Design Team for the discussions and comments Open Design Team for the discussions and comments on this document. The
on this document. The authors would also like to thank Amanda authors would also like to thank <contact fullname="Amanda Baber"/> for
Baber for reviewing the IANA Considerations and providing many reviewing the IANA Considerations and providing many useful
useful suggestions. The authors would like to thank Loa suggestions. The authors would like to thank <contact fullname="Loa
Andersson, Stewart Bryant, Greg Mirsky, Joel M. Halpern and Adrian Farrel Andersson"/>, <contact fullname="Stewart Bryant"/>, <contact
for reviewing this fullname="Greg Mirsky"/>, <contact fullname="Joel M. Halpern"/>, and
document and providing many useful suggestions. The authors would like to <contact fullname="Adrian Farrel"/> for reviewing this document and
thank Fabian Ihle and Michael Menth, providing many useful suggestions. The authors would like to thank
both from University of Tuebingen, for reviewing and implementing the solu <contact fullname="Fabian Ihle"/> and <contact fullname="Michael
tion defined in this document in P4 pipeline. Menth"/>, both from the University of Tuebingen, for reviewing and
Also, thank you, Tarek Saad for the Shepherd's review, Joe Clarke for OpsD implementing the solution defined in this document in P4 pipeline.
ir review, Also, thank you to <contact fullname="Tarek Saad"/> for the Shepherd's
Matthew Bocci for Rtgdir review, Derrell Piper for Secdir review, and Jame review, <contact fullname="Joe Clarke"/> for the OpsDir review, <contact
s Guichard for the AD review, fullname="Matthew Bocci"/> for the Rtgdir review, <contact fullname="Derre
Mohamed Boucadair, Eric Vyncke, Deb Cooley, Ketan Talaulikar, Mahesh Jetha ll
nandani for IESG review, which helped improve this document. Piper"/> for the Secdir review, and <contact fullname="James Guichard"/> f
or
the AD review, <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> </t>
</section> </section>
<section numbered="false" anchor="contributors" toc="default"> <section numbered="false" anchor="contributors" toc="default">
<name>Contributors</name> <name>Contributors</name>
<t>The following people have substantially contributed to this document:</ t> <t>The following people have substantially contributed to this document:</ t>
<figure anchor="contrib"> <contact fullname="Jisu Bhattacharya">
<artwork name="" type="" align="left" alt=""><![CDATA[ <organization>Cisco Systems, Inc.</organization>
<address>
<email>jisu@cisco.com</email>
</address>
</contact>
Jisu Bhattacharya <contact fullname="Bruno Decraene">
Cisco Systems, Inc. <organization>Orange</organization>
Email: jisu@cisco.com <address>
<email>bruno.decraene@orange.com</email>
</address>
</contact>
Bruno Decraene <contact fullname="Weiqiang Cheng">
Orange <organization>China Mobile</organization>
Email: bruno.decraene@orange.com <address>
<email>chengweiqiang@chinamobile.com</email>
</address>
</contact>
Weiqiang Cheng <contact fullname="Xiao Min">
China Mobile <organization>ZTE Corp.</organization>
Email: chengweiqiang@chinamobile.com <address>
<email>xiao.min2@zte.com.cn</email>
</address>
</contact>
Xiao Min <contact fullname="Luay Jalil">
ZTE Corp. <organization>Verizon</organization>
Email: xiao.min2@zte.com.cn <address>
<email>luay.jalil@verizon.com</email>
</address>
</contact>
Luay Jalil <contact fullname="Jie Dong">
Verizon <organization>Huawei Technologies</organization>
Email: luay.jalil@verizon.com <address>
<postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street>
<city>Beijing</city><code>100095</code>
<country>China</country>
</postal>
<email>jie.dong@huawei.com</email>
</address>
</contact>
Jie Dong <contact fullname="Tianran Zhou">
Huawei Technologies <organization>Huawei Technologies</organization>
Huawei Campus, No. 156 Beiqing Rd. <address>
Beijing 100095 <postal>
China <country>China</country>
Email: jie.dong@huawei.com </postal>
<email>zhoutianran@huawei.com</email>
</address>
</contact>
Tianran Zhou <contact fullname="Bin Wen">
Huawei Technologies <organization>Comcast</organization>
China <address>
Email: zhoutianran@huawei.com <email>Bin_Wen@cable.comcast.com</email>
</address>
</contact>
Bin Wen <contact fullname="Sami Boutros">
Comcast <organization>Ciena</organization>
Email: Bin_Wen@cable.comcast.com <address>
<email>sboutros@ciena.com</email>
</address>
</contact>
Sami Boutros <contact fullname="Tony Li">
Ciena <organization>Juniper Networks</organization>
Email: sboutros@ciena.com <address>
<postal>
<country>United States of America</country>
</postal>
<email>tony.li@tony.li</email>
</address>
</contact>
Tony Li <contact fullname="John Drake">
Juniper Networks <organization>Juniper Networks</organization>
United States <address>
Email: tony.li@tony.li <postal>
<country>United States of America</country>
</postal>
<email>jdrake@juniper.net</email>
</address>
</contact>
John Drake <!--[rfced] We had the following questions related to references:
Juniper Networks
United States
Email: jdrake@juniper.net
]]></artwork> a) Would you like the reference entries to be alphabetized or left in
</figure> 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> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 237 change blocks. 
724 lines changed or deleted 934 lines changed or added

This html diff was produced by rfcdiff 1.48.