rfc9789xml2.original.xml   rfc9789.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.14 (Ruby 2.
6.10) -->
<!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://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml">
<!ENTITY RFC3031 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.30
31.xml">
<!ENTITY RFC3032 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.30
32.xml">
<!ENTITY RFC4385 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43
85.xml">
<!ENTITY RFC5920 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
20.xml">
<!ENTITY RFC7274 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.72
74.xml">
<!ENTITY RFC8174 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml">
<!ENTITY RFC9017 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
17.xml">
<!ENTITY RFC9613 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.96
13.xml">
<!ENTITY I-D.ietf-mpls-opportunistic-encrypt SYSTEM "https://bib.ietf.org/public
/rfc/bibxml3/reference.I-D.ietf-mpls-opportunistic-encrypt.xml">
<!ENTITY I-D.ietf-mpls-1stnibble SYSTEM "https://bib.ietf.org/public/rfc/bibxml3
/reference.I-D.ietf-mpls-1stnibble.xml">
<!ENTITY RFC4928 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.49
28.xml">
<!ENTITY RFC5714 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.57
14.xml">
<!ENTITY RFC6790 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.67
90.xml">
<!ENTITY RFC8279 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
79.xml">
<!ENTITY RFC8296 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
96.xml">
<!ENTITY RFC8402 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
02.xml">
<!ENTITY RFC8491 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
91.xml">
<!ENTITY RFC8662 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
62.xml">
<!ENTITY RFC9088 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
88.xml">
<!ENTITY RFC9089 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
89.xml">
<!ENTITY RFC9522 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
22.xml">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-mpls-mna-fwk-15" category="info" subm <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
issionType="IETF"> -ietf-mpls-mna-fwk-15" number="9789" consensus="true" category="info" submission
<front> Type="IETF" version="3" updates="" obsoletes="" xml:lang="en" symRefs="true" toc
<title abbrev="MNA Framework">MPLS Network Actions (MNA) Framework</title> Include="true">
<!-- [rfced] Per use in RFCs 9613, we updated the expansion for MNA from "MPLS
Network Actions" (plural "Actions") to "MPLS Network Action" (singular
"Action"). Note that we also made this change in the abstract and
introduction. If you prefer to use the plural, perhaps we can update as
follows.
Original (document title):
MPLS Network Actions (MNA) Framework
Current:
MPLS Network Action (MNA) Framework
Perhaps:
Framework for MPLS Network Actions (MNAs)
-->
<front>
<title abbrev="MNA Framework">MPLS Network Action (MNA) Framework</title>
<seriesInfo name="RFC" value="9789"/>
<author initials="L." surname="Andersson" fullname="Loa Andersson"> <author initials="L." surname="Andersson" fullname="Loa Andersson">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<email>loa@pi.nu</email> <email>loa@pi.nu</email>
</address> </address>
</author> </author>
<author initials="S." surname="Bryant" fullname="Stewart Bryant"> <author initials="S." surname="Bryant" fullname="Stewart Bryant">
<organization>University of Surrey 5GIC</organization> <organization>University of Surrey 5GIC</organization>
<address> <address>
<email>sb@stewartbryant.com</email> <email>sb@stewartbryant.com</email>
skipping to change at line 63 skipping to change at line 55
<address> <address>
<email>matthew.bocci@nokia.com</email> <email>matthew.bocci@nokia.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Li" fullname="Tony Li"> <author initials="T." surname="Li" fullname="Tony Li">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>tony.li@tony.li</email> <email>tony.li@tony.li</email>
</address> </address>
</author> </author>
<date year="2025" month="May"/>
<area>RTG</area>
<workgroup>mpls</workgroup>
<date year="2024" month="December" day="27"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<workgroup>MPLS Working Group</workgroup> <keyword>example</keyword>
<abstract> <abstract>
<t>This document describes an architectural framework for MPLS
<t>This document describes an architectural framework for the MPLS Network Action (MNA) technologies. MNA technologies are used to
Network Actions (MNA) technologies. MNA technologies are used to indicate actions that impact the forwarding or other processing (such as
indicate actions that impact the forwarding or other processing (such monitoring) of the packet along the Label Switched Path (LSP) of the
as monitoring) of the packet along the Label Switched Path (LSP) of packet and to transfer any additional data needed for these actions.</t>
the packet and to transfer any additional data needed for these <t>This document provides the foundation for the development of a common
actions.</t> set of network actions and information elements supporting additional
operational models and capabilities of MPLS networks.</t>
<t>The document provides the foundation for the development of a common
set of network actions and information elements supporting additional
operational models and capabilities of MPLS networks.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<section anchor="introduction"><name>Introduction</name> <name>Introduction</name>
<t>This document describes an architectural framework for MPLS
<t>This document describes an architectural framework for the MPLS Network Action (MNA) technologies. MNA technologies are used to
Network Actions (MNA) technologies. MNA technologies are used to
indicate actions for Label Switched Paths (LSPs) and/or MPLS packets indicate actions for Label Switched Paths (LSPs) and/or MPLS packets
and to transfer data needed for these actions.</t> and to transfer data needed for these actions.</t>
<t>This document provides the foundation for the development of a common
<t>The document provides the foundation for the development of a common
set of network actions and information elements supporting additional set of network actions and information elements supporting additional
operational models and capabilities of MPLS networks. MNA solutions operational models and capabilities of MPLS networks. MNA solutions
derived from this framework are intended to address the requirements derived from this framework are intended to address the requirements
found in <xref target="RFC9613"/>. In addition, MNA may found in <xref target="RFC9613"/>. In addition, MNA may
support actions that overlap existing MPLS functionality. This may be support actions that overlap existing MPLS functionality. This may be
beneficial for numerous reasons, such as making it more efficient to beneficial for numerous reasons, such as making it more efficient to
combine existing functionality and new functions in the same MPLS combine existing functionality and new functions in the same MPLS
packet.</t> packet.</t>
<!-- [rfced] Will readers understand which items are part of the series here?
Does one of the following accurately convey the intended meaning?
Original:
These might include
load-balancing a packet given its entropy, whether or not to perform
fast-reroute on a failure, and whether or not a packet has metadata
relevant to the forwarding actions along the path.
Perhaps (entropy, whether or not..., whether or not...):
These might include
load-balancing a packet given its entropy, whether or not
fast-reroute is performed on a failure, and whether or not a packet has metad
ata
relevant to the forwarding actions along the path.
Or (load-balancing, indicating, indicating):
These might include
load-balancing a packet given its entropy, indicating whether or not to perfo
rm
Fast Reroute on a failure, and indicating whether or not a packet has metadat
a
relevant to the forwarding actions along the path.
-->
<t>MPLS forwarding actions are instructions to MPLS routers to apply <t>MPLS forwarding actions are instructions to MPLS routers to apply
additional actions when forwarding a packet. These might include additional actions when forwarding a packet. These might include
load-balancing a packet given its entropy, whether or not to perform load-balancing a packet given its entropy, whether or not to perform
fast-reroute on a failure, and whether or not a packet has metadata Fast Reroute on a failure, and whether or not a packet has metadata
relevant to the forwarding actions along the path.</t> relevant to the forwarding actions along the path.</t>
<t>This document generalizes the concept of MPLS "forwarding actions" to
<t>This document generalizes the concept of MPLS "forwarding actions" into "network actions" that include any action that an MPLS router is
"network actions" to include any action that an MPLS router is requested to take on the packet. Network actions include any MPLS forwarding
requested to take on the packet. That includes any MPLS forwarding actions but may also include other operations (such as security functions,
action, but may include other operations (such as security functions, Operations, Administration, and Maintenance (OAM) procedures, etc.) that are not
OAM procedures, etc.) that are not directly related to forwarding of directly related to forwarding of
the packet. MPLS network actions are always triggered by an MNA the packet. MPLS network actions are always triggered by an MNA
packet but may have implications for subsequent traffic, including packet but may have implications for subsequent traffic, including
non-MNA packets, as discussed in <xref target="State"/>.</t> non-MNA packets, as discussed in <xref target="State"/>.</t>
<t>MNA technologies may redefine the semantics of the Label, Traffic
<t>MNA technologies may redefine the semantics of the Label, Traffic
Class (TC), and Time to Live (TTL) fields in an MPLS Label Stack Entry Class (TC), and Time to Live (TTL) fields in an MPLS Label Stack Entry
(LSE) within a Network Action Sub-Stack (NAS).</t> (LSE) within a Network Action Sub-Stack (NAS).</t>
<section anchor="REQ-lang">
<name>Requirements Language</name>
<section anchor="REQ-lang"><name>Requirement Language</name> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", ",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
only when, they "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
appear in all capitals, as shown here. be
These words may also appear in this document in interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
lower case as plain English words, absent their normative meanings.</t> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t>Although this is an Informational document, these conventions are <t>Although this is an Informational document, these conventions are
applied to achieve clarity in the requirements that are presented.</t> applied to achieve clarity in the requirements that are presented.</t>
</section>
</section> <section anchor="normative-definitions">
<section anchor="terminology"><name>Terminology</name> <name>Normative Definitions</name>
<!-- [rfced] We have a few questions about the similar text below from
Sections 1.2 and 2.
<section anchor="normative-definitions"><name>Normative Definitions</name> a) Please confirm that NSI is the correct acronym for "Network Action
Sub-Stack Indicator". Should it be "NASI" rather than "NSI" to correspond with
"Network Action Indicator (NAI)" and "Network Action Sub-Stack (NAS)"?
<t>This document adopts the definitions of the following terms and b) Is the NSI the special-purpose label? If so, may we update the definition
abbreviations from <xref target="RFC9613"/> as below as follows?
normative: "Network Action", "Network Action Indication (NAI)",
"Ancillary Data (AD)", and "Scope".</t>
<t>In addition, this document also defines the following terms:</t> c) The second definition below mentions "MNA label", but the first does
not. Also, one definition uses "special label", and the other uses
"special-purpose label". Are any updates needed?
<t><list style="symbols"> Original:
<t>Network Action Sub-Stack (NAS): A set of related, contiguous LSEs in * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
the MPLS label stack for carrying information related to network contains a special label that indicates the start of the NAS.
actions. The Label, TC, and TTL values in the LSEs in the NAS may be ...
redefined, but the meaning of the S bit is unchanged.</t> * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
<t>Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS contains a special purpose label, called the MNA label, which is
contains a special label that indicates the start of the NAS.</t> used to indicate the start of a network action sub-stack.
</list></t>
</section> Perhaps:
<section anchor="abbreviations"><name>Abbreviations</name> Network Action Sub-Stack Indicator (NASI): The special-purpose label contain
ed
in the first LSE in the NAS. The NSI, also called the MNA label, indicates
the start of the NAS.
...
* Network Action Sub-Stack Indicator (NASI): The special-purpose label conta
ined
in the first LSE in the NAS. The NSI, also called the MNA label, indicates
the start of the NAS.
-->
<t>This document adopts the definitions of the following terms and
abbreviations from <xref target="RFC9613"/> as
normative: "Network Action", "Network Action Indicator (NAI)",
"Ancillary Data (AD)", and "Scope".</t>
<t>In addition, this document defines the following terms:</t>
<dl spacing="normal" newline="false">
<dt>Network Action Sub-Stack (NAS):</dt><dd>A set of related,
contiguous LSEs in the MPLS label stack for carrying information
related to network actions. The Label, TC, and TTL values in the
LSEs in the NAS may be redefined, but the meaning of the S bit is
unchanged.</dd>
<dt>Network Action Sub-Stack Indicator (NSI):</dt><dd>The first
LSE in the NAS contains a special label that indicates the start
of the NAS.</dd>
</dl>
</section>
<section anchor="abbreviations">
<name>Abbreviations</name>
<table anchor="Tab-apprev">
<name>Abbreviations</name>
<thead>
<tr>
<th align="left">Abbreviation</th>
<th align="left">Meaning</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">AD</td>
<td align="left">Ancillary Data</td>
<td align="left">
<xref target="RFC9613"/></td>
</tr>
<tr>
<td align="left">BIER</td>
<td align="left">Bit Index Explicit Replication</td>
<td align="left">
<xref target="RFC8279"/></td>
</tr>
<tr>
<td align="left">BoS</td>
<td align="left">Bottom of Stack</td>
<td align="left">
<xref target="RFC6790"/></td>
</tr>
<tr>
<td align="left">bSPL</td>
<td align="left">Base Special-Purpose Label</td>
<td align="left">
<xref target="RFC9017"/></td>
</tr>
<tr>
<td align="left">ECMP</td>
<td align="left">Equal-Cost Multipath</td>
<td align="left">
<xref target="RFC9522"/></td>
</tr>
<tr>
<td align="left">EL</td>
<td align="left">Entropy Label</td>
<td align="left">
<xref target="RFC6790"/></td>
</tr>
<tr>
<td align="left">ERLD</td>
<td align="left">Entropy Readable Label Depth</td>
<td align="left">
<xref target="RFC8662"/></td>
</tr>
<tr>
<td align="left">eSPL</td>
<td align="left">Extended Special-Purpose Label</td>
<td align="left">
<xref target="RFC9017"/></td>
</tr>
<tr>
<td align="left">HbH</td>
<td align="left">Hop by Hop</td>
<td align="left">In the MNA context, this document.</td>
</tr>
<tr>
<td align="left">I2E</td>
<td align="left">Ingress to Egress</td>
<td align="left">In the MNA context, this document.</td>
</tr>
<tr>
<td align="left">IGP</td>
<td align="left">Interior Gateway Protocol</td>
<td align="left"></td>
</tr>
<tr>
<td align="left">ISD</td>
<td align="left">In-Stack Data</td>
<td align="left">
<xref target="RFC9613"/></td>
</tr>
<tr>
<td align="left">LSE</td>
<td align="left">Label Stack Entry</td>
<td align="left">
<xref target="RFC3032"/></td>
</tr>
<tr>
<td align="left">MNA</td>
<td align="left">MPLS Network Action</td>
<td align="left">
<xref target="RFC9613"/></td>
</tr>
<tr>
<td align="left">MSD</td>
<td align="left">Maximum SID Depth</td>
<td align="left">
<xref target="RFC8491"/></td>
</tr>
<tr>
<td align="left">NAI</td>
<td align="left">Network Action Indicator</td>
<td align="left">
<xref target="RFC9613"/></td>
</tr>
<tr>
<td align="left">NAS</td>
<td align="left">Network Action Sub-Stack</td>
<td align="left">This document</td>
</tr>
<tr>
<td align="left">NSI</td>
<td align="left">Network Action Sub-Stack Indicator</td>
<td align="left">This document</td>
</tr>
<tr>
<td align="left">PSD</td>
<td align="left">Post-Stack Data</td>
<td align="left">
<xref target="RFC9613"/> and <xref target="PSD"/></td>
</tr>
<tr>
<td align="left">RLD</td>
<td align="left">Readable Label Depth</td>
<td align="left">This document</td>
</tr>
<tr>
<td align="left">SID</td>
<td align="left">Segment Identifier</td>
<td align="left">
<xref target="RFC8402"/></td>
</tr>
<tr>
<td align="left">SPL</td>
<td align="left">Special-Purpose Label</td>
<td align="left">
<xref target="RFC9017"/></td>
</tr>
</tbody>
</table>
</section>
</section>
<texttable title="Abbreviations" anchor="Tab-apprev"> <section anchor="structure">
<ttcol align='left'>Abbreviation</ttcol> <name>Structure</name>
<ttcol align='left'>Meaning</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>AD</c>
<c>Ancillary Data</c>
<c><xref target="RFC9613"/></c>
<c>BIER</c>
<c>Bit Index Explicit Replication</c>
<c><xref target="RFC8279"/></c>
<c>BoS</c>
<c>Bottom of Stack</c>
<c><xref target="RFC6790"/></c>
<c>bSPL</c>
<c>Base Special Purpose Label</c>
<c><xref target="RFC9017"/></c>
<c>ECMP</c>
<c>Equal Cost Multipath</c>
<c><xref target="RFC9522"/></c>
<c>EL</c>
<c>Entropy Label</c>
<c><xref target="RFC6790"/></c>
<c>ERLD</c>
<c>Entropy Readable Label Depth</c>
<c><xref target="RFC8662"/></c>
<c>eSPL</c>
<c>Extended Special Purpose Label</c>
<c><xref target="RFC9017"/></c>
<c>HBH</c>
<c>Hop by hop</c>
<c>In the MNA context, this document.</c>
<c>I2E</c>
<c>Ingress to Egress</c>
<c>In the MNA context, this document.</c>
<c>IGP</c>
<c>Interior Gateway Protocol</c>
<c>&#160;</c>
<c>ISD</c>
<c>In-stack data</c>
<c><xref target="RFC9613"/></c>
<c>LSE</c>
<c>Label Stack Entry</c>
<c><xref target="RFC3032"/></c>
<c>MNA</c>
<c>MPLS Network Actions</c>
<c><xref target="RFC9613"/></c>
<c>MSD</c>
<c>Maximum SID Depth</c>
<c><xref target="RFC8491"/></c>
<c>NAI</c>
<c>Network Action Indicator</c>
<c><xref target="RFC9613"/></c>
<c>NAS</c>
<c>Network Action Sub-Stack</c>
<c>This document</c>
<c>NSI</c>
<c>Network Action Sub-Stack Indicator</c>
<c>This document</c>
<c>PSD</c>
<c>Post-stack data</c>
<c><xref target="RFC9613"/> and <xref target="PSD"/></c>
<c>RLD</c>
<c>Readable Label Depth</c>
<c>This document</c>
<c>SID</c>
<c>Segment Identifier</c>
<c><xref target="RFC8402"/></c>
<c>SPL</c>
<c>Special Purpose Label</c>
<c><xref target="RFC9017"/></c>
</texttable>
</section> <!-- [rfced] We see that "sub-stacks" (plural) is used early in the sentence
</section> and "sub-stack" (singular) is used later. Is the current correct, or
</section> should both instances be either plural or singular?
<section anchor="structure"><name>Structure</name>
<t>An MNA solution specifies one or more network actions to apply to an Original:
A solution must specify where in the label stack the network
actions sub-stacks occur, if and how frequently they should be
replicated within the label stack, and how the network action sub-
stack and post-stack data are encoded.
-->
<t>An MNA solution specifies one or more network actions to apply to an
MPLS packet. These network actions and their ancillary data may be carried in MPLS packet. These network actions and their ancillary data may be carried in
sub-stacks within the MPLS label stack and/or post-stack sub-stacks within the MPLS label stack and/or post-stack
data. A solution must specify where in the label stack the network data. A solution must specify where the network
actions sub-stacks occur, if and how frequently they should be action sub-stacks occur in the label stack, if and how frequently they should be
replicated within the label stack, and how the network action replicated within the label stack, and how the network action
sub-stack and post-stack data are encoded.</t> sub-stack and post-stack data are encoded.</t>
<t>It seems highly likely that some ancillary data will be needed at many
<t>It seems highly likely that some ancillary data will be needed at many
points along an LSP. Replication of ancillary data throughout the points along an LSP. Replication of ancillary data throughout the
label stack would be highly inefficient, as would a full rewrite of label stack would be highly inefficient, as would a full rewrite of
the label stack at each hop, so MNA allows encoding of network actions the label stack at each hop; thus, MNA allows encoding of network actions
and ancillary data deeper in the label stack, requiring and ancillary data deeper in the label stack, requiring
implementations to look past the first LSE. Processing of the label implementations to look past the first LSE. Processing of the label
stack past the top of stack LSE was first introduced with the Entropy stack past the top-of-stack LSE was first introduced with the Entropy
Label <xref target="RFC6790"/>.</t> Label (EL) <xref target="RFC6790"/>.</t>
<t>A network action sub-stack contains:</t>
<t>A network action sub-stack contains:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
<t>Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS contains a special-purpose label, called the MNA label, which
contains a special purpose label, called the MNA label, which
is used to indicate the start of a network action sub-stack.</t> is used to indicate the start of a network action sub-stack.</t>
<t>Network Action Indicators (NAI): Optionally, a set of indicators that </li>
<li>
<t>Network Action Indicators (NAIs): Optionally, a set of indicators t
hat
describes the set of network actions. If the set of indicators is not describes the set of network actions. If the set of indicators is not
in the sub-stack, a solution could encode them in post-stack data. A in the sub-stack, a solution could encode them in post-stack data. A
network action is said to be present if there is an indicator in the network action is said to be present if there is an indicator in the
packet that invokes the action.</t> packet that invokes the action.</t>
<t>In-Stack Data (ISD): A set of zero or more LSEs that carry ancillary data </li>
<li>
<t>In-Stack Data (ISD): A set of zero or more LSEs that carry ancillar
y data
for the network actions that are present. Network action indicators for the network actions that are present. Network action indicators
are not considered ancillary data.</t> are not considered ancillary data.</t>
</list></t> </li>
</ul>
<t>Each network action present in the network action sub-stack may have <t>Each network action present in the network action sub-stack may have
zero or more LSEs of in-stack data. The ordering of the in-stack data zero or more LSEs of in-stack data. The ordering of the in-stack data
LSEs corresponds to the ordering of the network action indicators. The LSEs corresponds to the ordering of the network action indicators. The
encoding of the in-stack data, if any, for a network action must be encoding of the in-stack data, if any, for a network action must be
specified in the document that defines the network action. In-stack specified in the document that defines the network action. In-stack
data may be referenced by multiple network actions.</t> data may be referenced by multiple network actions.</t>
<t>As an example, in-stack data might look like the following label stack
<t>As an example, in-stack data might look like the following label stack with a with an
n
embedded NAS:</t> embedded NAS:</t>
<figure><artwork><![CDATA[ <figure>
<name>A Label Stack with an Embedded Network Action Sub-Stack</name>
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |0| TTL | | Label | TC |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |0| TTL | | Label | TC |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |0| TTL | | Label | TC |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Action Sub-Stack |0| | | Network Action Sub-Stack |0| |
~ ~ ~ ~
| Network Action Sub-Stack continued |0| | | Network Action Sub-Stack continued |0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |0| TTL | | Label | TC |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |1| TTL | | Label | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload | | Payload |
]]></artwork>
Figure 1: A label stack with an embedded Network Action Sub-Stack </figure>
]]></artwork></figure> <t>Certain network actions may also specify that data is carried after
<t>Certain network actions may also specify that data is carried after
the label stack. This is called post-stack data. The encoding of the the label stack. This is called post-stack data. The encoding of the
post-stack data, if any, for a network action must be specified in the post-stack data, if any, for a network action must be specified in the
document that defines the network action. If multiple network actions document that defines the network action. If multiple network actions
are present and have post-stack data, the ordering of their post-stack are present and have post-stack data, the ordering of their post-stack
data corresponds to the ordering of the network action indicators.</t> data corresponds to the ordering of the network action indicators.</t>
<!-- [rfced] This sentence includes two instances of "post-stack data". Please
comfirm that this is correct.
Original:
As an example, post-stack data might appear as a label stack followed
by post-stack data, followed by the payload:
Perhaps:
As an example, post-stack data might appear in a label stack, followed
by the payload:
-->
<t>As an example, post-stack data might appear as a label stack followed by post -stack data, followed by the payload:</t> <t>As an example, post-stack data might appear as a label stack followed by post -stack data, followed by the payload:</t>
<figure><artwork><![CDATA[ <figure>
<name>A Label Stack Followed by Post-Stack Data</name>
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |0| TTL | | Label | TC |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |1| TTL | | Label | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Post-stack data | | Post-Stack Data |
~ ~ ~ ~
| Post-stack data continued | | Post-Stack Data continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload | | Payload |
]]></artwork>
Figure 2: A label stack followed by post-stack data </figure>
]]></artwork></figure> <t>A solution must specify the order for network actions to be
<t>A solution must specify the order for network actions to be
applied to the packet for the actions to have consistent applied to the packet for the actions to have consistent
semantics. Since there are many possible orderings, especially with semantics. Since there are many possible orderings, especially with
bit catalogs (<xref target="Catalogs"/>), the solution must provide an unambiguo us bit catalogs (<xref target="Catalogs"/>), the solution must provide an unambiguo us
specification. The precise semantics of an action are dependent on the specification. The precise semantics of an action are dependent on the
contents of the packet, including any ancillary data, and the state of contents of the packet, including any ancillary data, and the state of
the router.</t> the router.</t>
<!-- [rfced] Would updating "not more than one" to simply "one" or "a single"
improve readability of this sentence?
Original:
This document assumes that the MPLS WG will select not more than one
solution for the encoding of ISD and not more than one solution for
the encoding of PSD.
Perhaps:
This document assumes that the MPLS WG will select a single
solution for the encoding of ISD and a single solution for
the encoding of PSD.
-->
<t>This document assumes that the MPLS WG will select not more than one <t>This document assumes that the MPLS WG will select not more than one
solution for the encoding of ISD and not more than one solution for solution for the encoding of ISD and not more than one solution for
the encoding of PSD.</t> the encoding of PSD.</t>
<section anchor="scopes">
<section anchor="scopes"><name>Scopes</name> <name>Scopes</name>
<t>A network action may need to be processed by every node along the
<t>A network action may need to be processed by every node along the path or some subset of the nodes along its path. Some of the scopes
path, or some subset of the nodes along its path. Some of the scopes
that an action may have are:</t> that an action may have are:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Hop-by-hop (HBH): Every node along the path will perform the action.</t> <t>Hop by Hop (HbH): Every node along the path will perform the acti
<t>Ingress-to-Egress (I2E): Only the last node on the path will perform on.</t>
</li>
<li>
<t>Ingress to Egress (I2E): Only the last node on the path will perf
orm
the action.</t> the action.</t>
<t>Select: Only specific nodes along the path will perform the action.</t> </li>
</list></t> <li>
<t>Select: Only specific nodes along the path will perform the actio
<t>If a solution supports the select scope, it must describe how it n.</t>
</li>
</ul>
<t>If a solution supports the select scope, it must describe how it
specifies the set of nodes to perform the actions.</t> specifies the set of nodes to perform the actions.</t>
<t>This framework does not place any constraints on the scope of, or the <t>This framework does not place any constraints on the scope of, or the
ancillary data for, a network action. Any network action may appear ancillary data for, a network action. Any network action may appear
in any scope or combination of scopes, may have no ancillary data, and in any scope or combination of scopes, may have no ancillary data, and
may require in-stack data, and/or post-stack data. Some combinations may require in-stack data and/or post-stack data. Some combinations
may be sub-optimal, but this framework does not restrict the combinations may be suboptimal, but this framework does not restrict the combinations
in an MNA solution. A specific MNA solution may define such in an MNA solution. A specific MNA solution may define such
constraints.</t> constraints.</t>
</section>
</section> <section anchor="partial-processing">
<section anchor="partial-processing"><name>Partial Processing</name> <name>Partial Processing</name>
<t>As described in <xref target="RFC3031"/>, legacy devices that do not
<t>As described in <xref target="RFC3031"/>, legacy devices that do not recogniz recognize the
e the
MNA label will discard the packet if the top label is the MNA label.</t> MNA label will discard the packet if the top label is the MNA label.</t>
<t>Devices that do recognize the MNA label might not implement all of th
<t>Devices that do recognize the MNA label might not implement all of the e
network actions that are present. A solution must specify how network actions that are present. A solution must specify how
unrecognized network actions that are present should be handled.</t> unrecognized network actions that are present should be handled.</t>
<t>One alternative is that an implementation should stop processing
<t>One alternative is that an implementation should stop processing
network actions when it encounters an unrecognized network network actions when it encounters an unrecognized network
action. Subsequent present network actions would not be action. Subsequent present network actions would not be
applied. The result is dependent on the solution's order of applied. The result is dependent on the solution's order of
operations.</t> operations.</t>
<t>Another alternative is that an implementation should drop any packet
<t>Another alternative is that an implementation should drop any packet
that contains any unrecognized present network actions.</t> that contains any unrecognized present network actions.</t>
<t>A third alternative is that an implementation should perform all
<t>A third alternative is that an implementation should perform all recognized present network actions but ignore all unrecognized
recognized present network actions, but ignore all unrecognized
present network actions.</t> present network actions.</t>
<t>Other alternatives may also be possible. The solution should specify
<t>Other alternatives may also be possible. The solution should specify the the
alternative adopted.</t> alternative adopted.</t>
<t>In some solutions, an indication may be provided in the packet or in
<t>In some solutions, an indication may be provided in the packet or in
the action as to how the forwarder should proceed if it does not the action as to how the forwarder should proceed if it does not
recognize the action. Where an action needs to be processed at every hop, recognize the action. Where an action needs to be processed at every hop,
it is recommended that care be taken not to construct an LSP that it is recommended that care be taken not to construct an LSP that
traverses nodes that do not support that action. It is recognised that traverses nodes that do not support that action. It is recognized that,
in some circumstances it may not be possible to construct an LSP that in some circumstances, it may not be possible to construct an LSP that
avoids such nodes, such as when a network is re-converging avoids such nodes, such as when a network is reconverging
following a failure or when IPFRR <xref target="RFC5714"/> is taking place.</t> following a failure or when IP Fast Reroute (IPFRR) <xref target="RFC5714"/> is
taking place.</t>
</section> </section>
<section anchor="signaling"><name>Signaling</name> <section anchor="signaling">
<name>Signaling</name>
<t>A node that wishes to make use of MNA and apply network actions to a <t>A node that wishes to make use of MNA and apply network actions to a
packet must understand the nodes that the packet will transit, whether packet must understand the nodes that the packet will transit, whether
or not the nodes support MNA, and the network actions that are to be or not the nodes support MNA, and the network actions that are to be
invoked. These capabilities are presumed to be signaled by protocols invoked. These capabilities are presumed to be signaled by protocols
that are out-of-scope for this document and are presumed to have that are out of scope for this document and are presumed to have
per-network action granularity. If a solution requires alternate per-network-action granularity. If a solution requires alternate
signaling, it must specify that explicitly.</t> signaling, it must specify that explicitly.</t>
<section anchor="readable-label-depth">
<section anchor="readable-label-depth"><name>Readable Label Depth</name> <name>Readable Label Depth</name>
<t>Readable Label Depth (RLD) is defined as the number of LSEs, starti
<t>Readable Label Depth (RLD) is defined as the number of LSEs, starting ng
from the top of the stack, that a router can read in an incoming MPLS from the top of the stack, that a router can read in an incoming MPLS
packet with no performance impact. <xref target="RFC8662"/> introduced Entropy packet with no performance impact. <xref target="RFC8662"/> introduced Entropy
Readable Label Depth (ERLD). Readable Label Depth is the same concept, Readable Label Depth (ERLD). Readable Label Depth is the same concept,
but generalized and not specifically associated with the Entropy Label but it is generalized and not specifically associated with the Entropy Label
(EL) or MNA.</t> (EL) or MNA.</t>
<t>ERLD is not redundant with RLD because ERLD
<t>ERLD is not redundant with RLD because ERLD specifically
specifies a value of zero if a system does not support the Entropy specifies a value of zero if a system does not support the Entropy
Label. Since a system could reasonably support MNA or other MPLS Label. Since a system could reasonably support MNA or other MPLS
functions and needs to advertise an RLD value but not support the functions and needs to advertise an RLD value but not support the
Entropy Label, another advertised value is required.</t> Entropy Label, another advertised value is required.</t>
<!-- [rfced] FYI - We updated the parenthetical as shown below.
Original:
A node SHOULD use signaling
(e.g., [RFC9088], [RFC9089]) to determine this.
Updated:
A node SHOULD use signaling
(e.g., the signaling described in [RFC9088] and [RFC9089]) to determine this.
-->
<t>A node that pushes an NAS onto the label stack is responsible for <t>A node that pushes an NAS onto the label stack is responsible for
ensuring that all nodes that are expected to process the NAS will have ensuring that all nodes that are expected to process the NAS will have
the entire NAS within their RLD. A node SHOULD use signaling (e.g., the entire NAS within their RLD. A node <bcp14>SHOULD</bcp14> use signaling (e.g
<xref target="RFC9088"/>, <xref target="RFC9089"/>) to determine this. An excep ., the signaling described in
tion might be, <xref target="RFC9088"/> and <xref target="RFC9089"/>) to determine this. An ex
ception might be,
for example, when the node has out-of-band knowledge that all nodes for example, when the node has out-of-band knowledge that all nodes
along the path do not have RLD limitations and thus could avoid the along the path do not have RLD limitations and thus could avoid the
unnecessary overhead of using signaling.</t> unnecessary overhead of using signaling.</t>
<t>Per <xref target="RFC8662"/>, a node that does not support EL will
<t>Per <xref target="RFC8662"/>, a node that does not support EL will advertise advertise a
a
value of zero for its ERLD, so advertising ERLD alone does not suffice value of zero for its ERLD, so advertising ERLD alone does not suffice
in all cases. A node MAY advertise both ERLD and RLD and SHOULD do so in all cases. A node <bcp14>MAY</bcp14> advertise both ERLD and RLD, and it <bcp 14>SHOULD</bcp14> do so
if its ERLD and RLD values are different. Again, if a node has if its ERLD and RLD values are different. Again, if a node has
out-of-band knowledge that all nodes do not have RLD limitations, then out-of-band knowledge that all nodes do not have RLD limitations, then
signaling can be avoided. If a node's ERLD and RLD values are the signaling can be avoided. If a node's ERLD and RLD values are the
same, it MAY only advertise ERLD for efficiency reasons. If a node same, it <bcp14>MAY</bcp14> only advertise ERLD for efficiency reasons. If a nod
supports MNA but does not support EL, then it SHOULD advertise RLD e
supports MNA but does not support EL, then it <bcp14>SHOULD</bcp14> advertise RL
D
unless it has out-of-band knowledge that no nodes in the domain have unless it has out-of-band knowledge that no nodes in the domain have
RLD restrictions.</t> RLD restrictions.</t>
<t>RLD is advertised by an IGP MSD-Type value of 3 and <bcp14>MAY</bcp
<t>RLD is advertised by an IGP MSD-Type value of (TBA) and MAY be 14> be
advertised as a Node Maximum Segment Identifier (SID) Depth (MSD), advertised as a Node MSD,
Link MSD, or both.</t> Link MSD, or both.</t>
<t>An MNA node MUST use the RLD determined by selecting the first <!-- [rfced] Should the text introducing the list indicate if the value is
advertised non-zero value from:</t> "from one of the following" or "each of the following"? Or will readers
understand?
<t><list style="symbols"> Original:
<t>The RLD advertised for the link.</t> An MNA node MUST use the RLD determined by selecting the first
<t>The RLD advertised for the node.</t> advertised non-zero value from:
<t>The non-zero ERLD for the node.</t>
</list></t>
<t>A node's RLD is a function of its hardware capabilities and is not * The RLD advertised for the link.
expected to depend on the specifics of the MNA solution.</t>
</section> * The RLD advertised for the node.
</section>
<section anchor="State"><name>State</name>
<t>A network action can affect the state stored in the network. This * The non-zero ERLD for the node.
Perhaps:
An MNA node MUST use the RLD determined by selecting the first
advertised non-zero value from one of the following:
* The RLD advertised for the link
* The RLD advertised for the node
* The non-zero ERLD for the node
Or:
An MNA node MUST use the RLD determined by selecting the first
advertised non-zero value from each of the following:
* The RLD advertised for the link
* The RLD advertised for the node
* The non-zero ERLD for the node
-->
<t>An MNA node <bcp14>MUST</bcp14> use the RLD determined by selecting the first
advertised non-zero value from:</t>
<ul spacing="normal">
<li>
<t>The RLD advertised for the link</t>
</li>
<li>
<t>The RLD advertised for the node</t>
</li>
<li>
<t>The non-zero ERLD for the node</t>
</li>
</ul>
<t>A node's RLD is a function of its hardware capabilities and is not
expected to depend on the specifics of the MNA solution.</t>
</section>
</section>
<section anchor="State">
<name>State</name>
<t>A network action can affect the state stored in the network. This
implies that a packet may affect how subsequent packets are implies that a packet may affect how subsequent packets are
handled. In particular, one packet may affect subsequent packets in handled. In particular, one packet may affect subsequent packets in
the same LSP.</t> the same LSP.</t>
</section>
</section> </section>
</section> <section anchor="carry">
<section anchor="carry"><name>Encoding</name> <name>Encoding</name>
<t>Several possible ways to encode NAIs have been proposed. This
<t>Several possible ways to encode NAIs have been proposed. This
section summarizes the proposals and some considerations for section summarizes the proposals and some considerations for
the various alternatives.</t> the various alternatives.</t>
<t>When network actions are carried in the MPLS label stack, then <t>When network actions are carried in the MPLS label stack, then
regardless of their type, they are represented by a set of LSEs termed regardless of their type, they are represented by a set of LSEs termed
a network action sub-stack (NAS). An NAS consists of a special label, a Network Action Sub-Stack (NAS). An NAS consists of a special label,
optionally followed by LSEs that specify which network actions are to optionally followed by LSEs that specify which network actions are to
be performed on the packet and the in-stack ancillary data for each be performed on the packet and the in-stack ancillary data for each
indicated network action. Different network actions may be placed indicated network action. Different network actions may be placed
together in one NAS or may be carried in different sub-stacks.</t> together in one NAS or may be carried in different sub-stacks.</t>
<t><xref target="RFC9613"/> requires that a solution not add unnecessary
<t><xref target="RFC9613"/> requires that a solution not add LSEs to the sub-stack (see requirement 9 in <xref section="3.1" sectionFor
unnecessary LSEs to the sub-stack (Section 3.1, requirement mat="of"
9). Accordingly, solutions should also make efficient use of the bits target="RFC9613"/>). Accordingly, solutions should also
within the sub-stack (except the S-bit), as inefficient use of the make efficient use of the bits within the sub-stack (except the S-bit),
bits could result in the addition of unnecessary LSEs.</t> as inefficient use of the bits could result in the addition of
unnecessary LSEs.</t>
<section anchor="NAI"><name>The MNA Label</name> <section anchor="NAI">
<name>The MNA Label</name>
<t>The first LSE in a network action sub-stack contains a special label <t>The first LSE in a network action sub-stack contains a special label
that indicates a network action sub-stack. A solution has several that indicates a network action sub-stack. A solution has several
choices for this special label.</t> choices for this special label.</t>
<section anchor="existing-base-spl">
<section anchor="existing-base-spl"><name>Existing Base SPL</name> <name>Existing Base SPL</name>
<t>A solution may reuse an existing Base SPL (bSPL). If it elects to d
<t>A solution may reuse an existing Base SPL (bSPL). If it elects to do o
so, it must explain how the usage is backward compatible, including so, it must explain how the usage is backward compatible, including
in the case where there is ISD.</t> in the case where there is ISD.</t>
<t>If an existing inactive bSPL is selected that will not be
<t>If an existing inactive bSPL is selected that will not be
backward compatible, then it must first be retired per backward compatible, then it must first be retired per
<xref target="RFC7274"/> and then reallocated.</t> <xref target="RFC7274"/> and then reallocated.</t>
</section>
</section> <section anchor="new-base-spl">
<section anchor="new-base-spl"><name>New Base SPL</name> <name>New Base SPL</name>
<t>A solution may select a new bSPL.</t>
<t>A solution may select a new bSPL.</t> </section>
<section anchor="new-extended-spl">
</section> <name>New Extended SPL</name>
<section anchor="new-extended-spl"><name>New Extended SPL</name> <t>A solution may select a new Extended SPL (eSPL). If it elects to do
so, it must
<t>A solution may select a new Extended SPL (eSPL). If it elects to do so, it mu
st
address the requirement for the minimal number of LSEs.</t> address the requirement for the minimal number of LSEs.</t>
</section>
</section> <section anchor="user-defined-label">
<section anchor="user-defined-label"><name>User-Defined Label</name> <name>User-Defined Label</name>
<t>A solution may allow the network operator to define the label that
<t>A solution may allow the network operator to define the label that
indicates the network action sub-stack. This creates management indicates the network action sub-stack. This creates management
overhead for the network operator to coordinate the use of this label overhead for the network operator to coordinate the use of this label
across all nodes on the path using management or signaling across all nodes on the path using management or signaling
protocols. The user-defined label could be network-wide or protocols. The user-defined label could be network-wide or
LSP-specific. If a solution elects to use a user-defined label, the LSP-specific. If a solution elects to use a user-defined label, the
solution should justify this overhead.</t> solution should justify this overhead.</t>
</section>
</section>
<section anchor="tc-and-ttl">
<name>TC and TTL</name>
</section> <t>In the first LSE of the network action sub-stack, only the 20 bits of
</section> the Label value and the Bottom of Stack bit are used by the NSI; the TC field
<section anchor="tc-and-ttl"><name>TC and TTL</name>
<t>In the first LSE of the network action sub-stack, only the 20 bits of
Label Value and the Bottom of Stack bit are used by NSI; the TC field
(3 bits) and the TTL (8 bits) are not used. This could leave 11 bits (3 bits) and the TTL (8 bits) are not used. This could leave 11 bits
that could be used for MNA purposes.</t> that could be used for MNA purposes.</t>
<section anchor="tc-and-ttl-retained">
<section anchor="tc-and-ttl-retained"><name>TC and TTL retained</name> <name>TC and TTL Retained</name>
<t>If the solution elects to retain the TC and TTL fields, then the fi
<t>If the solution elects to retain the TC and TTL fields, then the first rst
LSE of the network action sub-stack would appear as described in <xref target="R FC3032"/>:</t> LSE of the network action sub-stack would appear as described in <xref target="R FC3032"/>:</t>
<figure><artwork><![CDATA[ <figure>
<name>A Label Stack Entry</name>
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label value, 20 bits ]]></artwork>
TC: Traffic Class, 3 bits </figure>
S: Bottom of Stack, 1 bit
TTL: Time To Live
Figure 3: A Label Stack Entry <!-- [rfced] Each definition below includes a number of bits except for
]]></artwork></figure> TTL. Should the TTL definition also include a number of bits?
<t>Further LSEs would be needed to encode NAIs. If a solution elects to
retain these fields, it must address the requirement for the minimal Original:
Label: Label value, 20 bits
TC: Traffic Class, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time To Live
Perhaps:
Label: Label value, 20 bits
TC: Traffic Class, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time To Live, 8 bits
-->
<dl spacing="compact" newline="false">
<dt>Label:</dt><dd>Label value, 20 bits</dd>
<dt>TC:</dt><dd>Traffic Class, 3 bits</dd>
<dt>S:</dt><dd>Bottom of Stack, 1 bit</dd>
<dt>TTL:</dt><dd>Time To Live</dd>
</dl>
<t>Further LSEs would be needed to encode NAIs. If a solution elects
to
retain the TC and TTL fields, it must address the requirement for the minimal
number of LSEs.</t> number of LSEs.</t>
</section>
<section anchor="tc-and-ttl-repurposed">
<name>TC and TTL Repurposed</name>
<t>If the solution elects to reuse the TC and TTL fields, then the fir
st
LSE of the network action sub-stack would appear as follows:</t>
</section> <!-- [rfced] Figure 4 does not have a title; all the other figures do. What
<section anchor="tc-and-ttl-repurposed"><name>TC and TTL Repurposed</name> title should we add for Figure 4? Also, would it be helpful to revise the
title of Figure 3 to be more descriptive?
<t>If the solution elects to reuse the TC and TTL fields, then the first Current:
LSE of the network action sub-stack would appear as:</t> Figure 3: A Label Stack Entry
Figure 4
<figure><artwork><![CDATA[ Perhaps:
Figure 3: A Label Stack Entry with TC and TTL Retained
Figure 4: A Label Stack Entry with TC and TTL Repurposed
-->
<figure>
<name></name>
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |x x x|S|x x x x x x x x| | Label |x x x|S|x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label value, 20 bits ]]></artwork>
x: Bit available for use in solution definition </figure>
S: Bottom of Stack, 1 bit
]]></artwork></figure>
<t>The solution may use more LSEs to contain NAIs. If a solution elects <dl spacing="compact" newline="false">
to use more LSEs it must address the requirement for the minimal <dt>Label:</dt><dd>Label value, 20 bits</dd>
<dt>x:</dt><dd>Bit available for use in solution definition</dd>
<dt>S:</dt><dd>Bottom of Stack, 1 bit</dd>
</dl>
<t>The solution may use more LSEs to contain NAIs. If a solution elec
ts
to use more LSEs, it must address the requirement for the minimal
number of LSEs.</t> number of LSEs.</t>
</section>
</section> </section>
</section> <section anchor="length-of-the-nas">
<section anchor="length-of-the-nas"><name>Length of the NAS</name> <name>Length of the NAS</name>
<t>A solution must have a mechanism (such as an indication of the length
<t>A solution must have a mechanism (such as an indication of the length
of the NAS) to enable an implementation to find the end of the NAS. of the NAS) to enable an implementation to find the end of the NAS.
This must be easily processed even by implementations that do not This must be easily processed even by implementations that do not
understand the full contents of the NAS. Two options are described understand the full contents of the NAS. Two options are described
below, other solutions may be possible.</t> below; other solutions may be possible.</t>
<section anchor="lastcontinuation-bits">
<section anchor="lastcontinuation-bits"><name>Last/Continuation Bits</name> <name>Last/Continuation Bits</name>
<t>A solution may use a bit per LSE to indicate whether or not the NAS
<t>A solution may use a bit per LSE to indicate whether the NAS continues continues
into the next LSE or not. The bit may indicate continuation by being into the next LSE. The bit may indicate continuation by being
set or by being clear. The overhead of this approach is one bit per set or by being clear. The overhead of this approach is one bit per
LSE and has the advantage that it can effectively encode an LSE and has the advantage that it can effectively encode an
arbitrarily sized NAS. This approach is efficient if the NAS is small.</t> arbitrarily sized NAS. This approach is efficient if the NAS is small.</t>
</section>
</section> <section anchor="length-field">
<section anchor="length-field"><name>Length Field</name> <name>Length Field</name>
<t>A solution may opt to have a fixed-size Length field at a fixed
<t>A solution may opt to have a fixed size length field at a fixed location within the NAS. The fixed size of the Length field may not be
location within the NAS. The fixed size of the length field may not be
large enough to support all possible NAS contents. This approach may large enough to support all possible NAS contents. This approach may
be more efficient if the NAS is longer but not longer than can be be more efficient if the NAS is long, but not longer than can be
described by the length field.</t> described by the Length field.</t>
<t>Advice from one hardware designer recommends a length field as this <t>One hardware designer recommends a Length field as this
minimizes branching in the logic.</t> minimizes branching in the logic.</t>
</section>
</section> </section>
</section> <section anchor="encoding-of-scopes">
<section anchor="encoding-of-scopes"><name>Encoding of Scopes</name> <name>Encoding of Scopes</name>
<t>A solution may choose to explicitly encode the scope of each action
<t>A solution may choose to explicitly encode the scope of each action
contained in a network action sub-stack. For example, a NAS might contained in a network action sub-stack. For example, a NAS might
contain Action A (HBH), Action B (HBH), and Action C (HBH). A contain Action A (HbH), Action B (HbH), and Action C (HbH). A
solution may alternately choose to have the scope encoded implicitly, solution may alternately choose to have the scope encoded implicitly,
based on the actions present in the network action sub-stack. For based on the actions present in the network action sub-stack. For
example, a NAS might contain HBH scope actions: A, B, C. This choice example, a NAS might contain the following actions with HbH scope: A, B, and C. This choice
may have performance implications as an implementation might have to may have performance implications as an implementation might have to
parse the network actions that are present in a network action parse the network actions that are present in a network action
sub-stack only to discover that there are no actions for it to sub-stack only to discover that there are no actions for it to
perform.</t> perform.</t>
<t>For example, suppose that an NAS is embedded in a label stack at a
<t>For example, suppose that an NAS is embedded in a label stack at a depth of six LSEs and the NAS contains three actions, each with Select
depth of 6 LSEs and that the NAS contains 3 actions, each with Select
scope. These actions are not applicable at the current node and should scope. These actions are not applicable at the current node and should
be ignored. If the scope is encoded explicitly with each action, then be ignored. If the scope is encoded explicitly with each action, then
an implementation must parse each action. However, if the scope is an implementation must parse each action. However, if the scope is
encoded as part of the NAS, then an implementation need only parse the encoded as part of the NAS, then an implementation only needs to parse the
start of the NAS and need not parse individual actions.</t> start of the NAS and not individual actions.</t>
<t>Solutions need to consider the order of scoped NAIs and their
<t>Solutions need to consider the order of scoped NAIs and their
associated AD within individual sub-stacks and the order of per-scope associated AD within individual sub-stacks and the order of per-scope
sub-stacks so that network actions and the AD can be most sub-stacks, so that network actions and the AD can be
readily found and need not be processed by nodes that are not required readily found and not be processed by nodes that are not required
to handle those actions.</t> to handle those actions.</t>
</section>
</section> <section anchor="INDEX">
<section anchor="INDEX"><name>Encoding a Network Action</name> <name>Encoding a Network Action</name>
<t>Two options for encoding NAIs are described below; other solutions ma
<t>Two options for encoding NAIs are described below, other solutions may y
be possible. Any solution should allow the encoding of an arbitrary be possible. Any solution should allow the encoding of an arbitrary
number of NAIs.</t> number of NAIs.</t>
<section anchor="Catalogs">
<section anchor="Catalogs"><name>Bit Catalogs</name> <name>Bit Catalogs</name>
<t>A solution may opt to encode the set of network actions as a list o
<t>A solution may opt to encode the set of network actions as a list of f
bits, sometimes known as a catalog. The solution must provide a bits, sometimes known as a catalog. The solution must provide a
mechanism to determine how many LSEs are devoted to the catalog when mechanism to determine how many LSEs are devoted to the catalog when
the NAIs are carried in-stack. A set bit in the catalog would indicate the NAIs are carried in-stack. A set bit in the catalog would indicate
that the corresponding network action is present.</t> that the corresponding network action is present.</t>
<t>Catalogs are efficient if the number of present network actions is
<t>Catalogs are efficient if the number of present network actions is
relatively high and if the size of the necessary catalog is small. For relatively high and if the size of the necessary catalog is small. For
example, if the first 16 actions are all present, a catalog can encode example, if the first 16 actions are all present, a catalog can encode
this in 16 bits. However, if the number of possible actions is large, this in 16 bits. However, if the number of possible actions is large,
then a catalog can become inefficient. Selecting only one action that then a catalog can become inefficient. Selecting only one action that
is the 256th action would require a catalog of 256 bits, which would is the 256th action would require a catalog of 256 bits, which would
require more than one LSE when the NAIs are carried in-stack.</t> require more than one LSE when the NAIs are carried in-stack.</t>
<t>A solution may include a bit-remapping mechanism so that a given
<t>A solution may include a bit remapping mechanism so that a given
domain may optimize for its commonly used actions.</t> domain may optimize for its commonly used actions.</t>
</section>
</section> <section anchor="operation-codes">
<section anchor="operation-codes"><name>Operation Codes</name> <name>Operation Codes</name>
<t>A solution may opt to encode the set of present network actions as
<t>A solution may opt to encode the set of present network actions as a a
list of operation codes (opcodes). Each opcode is a fixed number of list of operation codes (opcodes). Each opcode is a fixed number of
bits. The size of the opcode bounds the number of network actions bits. The size of the opcode bounds the number of network actions
that the solution can support.</t> that the solution can support.</t>
<t>Opcodes are efficient if there are only one or two active network
<t>Opcodes are efficient if there are only one or two active network
actions. For example, if an opcode is 8 bits, then two active network actions. For example, if an opcode is 8 bits, then two active network
actions could be encoded in 16 bits. However, if 16 actions could be encoded in 16 bits. However, if 16
actions are required, then opcodes would consume 128 bits. Opcodes are actions are required, then opcodes would consume 128 bits. Opcodes are
efficient at encoding a large number of possible actions. If only efficient at encoding a large number of possible actions. If only
the 256th action is to be selected, that still requires 8 bits.</t> the 256th action is to be selected, that still requires 8 bits.</t>
</section>
</section>
<section anchor="PSD">
<name>Encoding of Post-Stack Data</name>
</section> <!-- [rfced] Should "NAI" here be plural (i.e., "NAIs")?
</section>
<section anchor="PSD"><name>Encoding of Post-Stack Data</name>
<t>A solution may carry some NAI and AD as PSD. For ease of parsing, all Original:
AD should be co-located with its NAI.</t> A solution may carry some NAI and AD as PSD.
<t>If there are multiple instances of post-stack data, they should occur Perhaps (change to "NAIs"):
A solution may carry some NAIs and AD as PSD.
Or (remove "some"):
A solution may carry NAI and AD as PSD.
-->
<t>A solution may carry some NAI and AD as PSD. For ease of parsing, all
AD should be co-located with its NAI.</t>
<t>If there are multiple instances of post-stack data, they should occur
in the same order as their relevant network action sub-stacks and then in the same order as their relevant network action sub-stacks and then
in the same order as their relevant network actions occur within the in the same order as their relevant network actions occur within the
network action sub-stacks.</t> network action sub-stacks.</t>
<section anchor="first-nibble-considerations">
<section anchor="first-nibble-considerations"><name>First Nibble Considerations< <name>First Nibble Considerations</name>
/name> <t>The first nibble after the label stack has been used to convey
information in certain cases <xref target="RFC4385"/>. A consolidated view of
<t>The first nibble after the label stack has been used to convey the uses of the
information in certain cases <xref target="RFC4385"/>. A consolidated view of first nibble is provided in <xref target="RFC9790"/>.</t>
first nibble uses is provided in <xref target="I-D.ietf-mpls-1stnibble"/>.</t <t>For example, in <xref target="RFC4928"/>, this nibble is investigat
> ed to find out
if it has the value "4" or "6". If it does not, it is assumed that
<t>For example, in <xref target="RFC4928"/> this nibble is investigated to find the packet payload is not IPv4 or IPv6, and Equal-Cost Multipath
out
if it has the value "4" or "6". If it is not, it is assumed that
the packet payload is not IPv4 or IPv6, and Equal Cost Multipath
(ECMP) is not performed.</t> (ECMP) is not performed.</t>
<!-- [rfced] "ECMP'ed" has not been used in published RFCs. Will readers
understand what this means? Perhaps rephrasing would be helpful.
<t>It should be noted that this is an inexact method. For example, an Ethernet Original:
Pseudowire without a control word might have "4" or "6" in the first For example, an
Ethernet Pseudowire without a control word might have "4" or "6" in
the first nibble and thus will be ECMP'ed.
-->
<t>It should be noted that this is an inexact method. For example, an Etherne
t
pseudowire without a control word might have "4" or "6" in the first
nibble and thus will be ECMP'ed.</t> nibble and thus will be ECMP'ed.</t>
<t>Nevertheless, the method is implemented and deployed; it is used
<t>Nevertheless, the method is implemented and deployed, it is used
today and will be for the foreseeable future.</t> today and will be for the foreseeable future.</t>
<t>The use of the first nibble for Bit Index Explicit Replication <!-- [rfced] We are having trouble understanding the text starting with "to
determine...". Please clarify.
Original:
However, the BIER approach meets
the design goal of [RFC8296] to determine that the payload is IPv4,
IPv6 or with the header of a pseudowire packet with a control word,
rather than being a payload belonging to a BIER or some other type of
packet.
-->
<t>The use of the first nibble for Bit Index Explicit Replication
(BIER) is specified in <xref target="RFC8296"/>. BIER sets the first nibble t o (BIER) is specified in <xref target="RFC8296"/>. BIER sets the first nibble t o
5. The same is true for a BIER payload as for any use of the first 5. The same is true for a BIER payload as for any use of the first
nibble: it is not possible to conclude that the payload is BIER nibble: it is not possible to conclude that the payload is BIER
even if the first nibble is set to 5 because an Ethernet pseudowire even if the first nibble is set to 5 because an Ethernet pseudowire
without a control word might begin with a 5. However, the BIER without a control word might begin with a 5. However, the BIER
approach meets the design goal of <xref target="RFC8296"></xref> to determine that the approach meets the design goal of <xref target="RFC8296"/> to determine that the
payload is IPv4, IPv6 or with the header of a pseudowire packet payload is IPv4, IPv6 or with the header of a pseudowire packet
with a control word, rather than being a payload belonging to a with a control word, rather than being a payload belonging to a
BIER or some other type of packet.</t> BIER or some other type of packet.</t>
<t><xref target="RFC4385"/> allocates 0b0000 for the pseudowire contro
<t><xref target="RFC4385"/> allocates 0b0000 for the pseudowire control word and l word and 0b0001
0b0001
as the control word for the pseudowire Associated Channel Header as the control word for the pseudowire Associated Channel Header
(ACH).</t> (ACH).</t>
<t>A PSD solution should specify the contents of the first nibble, the
<t>A PSD solution should specify the contents of the first nibble, the
actions to be taken for the value, and the interaction with post-stack actions to be taken for the value, and the interaction with post-stack
data used concurrently by other MPLS applications.</t> data used concurrently by other MPLS applications.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="semantics">
<section anchor="semantics"><name>Semantics</name> <name>Semantics</name>
<t>For MNA to be consistent across implementations and predictable in
<t>For MNA to be consistent across implementations and predictable in
operational environments, its semantics need to be entirely operational environments, its semantics need to be entirely
predictable. An MNA solution MUST specify a deterministic order for predictable. An MNA solution <bcp14>MUST</bcp14> specify a deterministic order f
processing each of the Network Actions in a packet. Each network or
processing each of the network actions in a packet. Each network
action must specify how it interacts with all other previously defined action must specify how it interacts with all other previously defined
network actions. Private network actions are network actions that are network actions. Private network actions are network actions that are
not publicly documented. Private network actions MUST be included in not publicly documented. Private network actions <bcp14>MUST</bcp14> be included in
the ordering of network actions, but the interactions of private the ordering of network actions, but the interactions of private
actions with other actions are outside of the scope of this document.</t> actions with other actions are outside of the scope of this document.</t>
</section>
<section anchor="definition-of-a-network-action">
<name>Definition of a Network Action</name>
<!-- [rfced] How may we update this sentence for clarity?
</section> Original:
<section anchor="definition-of-a-network-action"><name>Definition of a Network A Network actions should be defined in a document that must contain:
ction</name>
<t>Network actions should be defined in a document that must contain:</t> Perhaps:
The definition of a network action in a document must contain the following:
<t><list style="symbols"> Or:
<t>Name: The name of the network action.</t> Network actions should be defined in a document using the format below:
<t>Network Action Indicator: The bit position or opcode that indicates -->
that the network action is active.</t> <!-- [rfced] The "Scope", "State", and "Required/Optional" items below include
<t>Scope: The document should specify which nodes should perform the complete sentences starting with "The document should..."; the other
network action as described in <xref target="scopes"/>.</t> items in the list do not. How may we update these three items to create
<t>State: The document should specify if the network action can modify parallel structure in this list?
state in the network, and if so, the state that may be modified and
its side effects.</t>
<t>Required/Optional: The document should specify whether a node is
required to perform the network action.</t>
<t>In-Stack Data: The number of LSEs of in-stack data, if any, and its
encoding. If this is of a variable length, then the solution must
specify how an implementation can determine this length without
implementing the network action.</t>
<t>Post-Stack Data: The encoding of post-stack data, if any. If this is of a
variable length, then the solution must specify how an
implementation can determine this length without implementing the
network action.</t>
</list></t>
<t>A solution should create an IANA registry for network Original:
actions.</t> * Name: The name of the network action.
</section> * Network Action Indicator: The bit position or opcode that
<section anchor="management-considerations"><name>Management Considerations</nam indicates that the network action is active.
e>
<t>Network operators will need to be cognizant of which network actions * Scope: The document should specify which nodes should perform the
network action as described in Section 2.1.
* State: The document should specify if the network action can
modify state in the network, and if so, the state that may be
modified and its side effects.
* Required/Optional: The document should specify whether a node is
required to perform the network action.
* In-Stack Data: The number of LSEs of in-stack data, if any, and
its encoding. If this is of a variable length, then the solution
must specify how an implementation can determine this length
without implementing the network action.
* Post-Stack Data: The encoding of post-stack data, if any. If this
is of a variable length, then the solution must specify how an
implementation can determine this length without implementing the
network action.
Perhaps:
Name: The name of the network action.
Network Action Indicator: The bit position or opcode that indicates
that the network action is active.
Scope: Description of which nodes should perform the
network action as described in Section 2.1.
State: Indication of whether the network action can modify
state in the network and, if so, the state that may be modified
and its side effects.
Required/Optional: Indication of whether a node is
required to perform the network action.
In-Stack Data: The number of LSEs of in-stack data, if any, and its
encoding. If this is of a variable length, then the solution must
specify how an implementation can determine this length without
implementing the network action.
Post-Stack Data: The encoding of post-stack data, if any. If this
is of a variable length, then the solution must specify how an
implementation can determine this length without implementing the
network action.
-->
<!-- [rfced] May we update this text to clarify "its" and "this"?
Original:
In-Stack Data: The number of LSEs of in-stack data, if any, and its
encoding. If this is of a variable length, then the solution must
specify how an implementation can determine this length without
implementing the network action.
Post-Stack Data: The encoding of post-stack data, if any. If this
is of a variable length, then the solution must specify how an
implementation can determine this length without implementing the
network action.
Perhaps:
In-Stack Data: The number of LSEs of in-stack data, if any, and the
encoding of the in-stack data. If the in-stack data is of a variable
length, then the solution must
specify how an implementation can determine the length without
implementing the network action.
Post-Stack Data: The encoding of post-stack data, if any. If the post-stack
data
is of a variable length, then the solution must specify how an
implementation can determine the length without implementing the
network action.
-->
<t>Network actions should be defined in a document that must contain:</t>
<dl spacing="normal" newline="false">
<dt>Name:</dt><dd>The name of the network action.</dd>
<dt>Network Action Indicator:</dt><dd>The bit position or opcode that
indicates that the network action is active.</dd>
<dt>Scope:</dt><dd>The document should specify which nodes should
perform the network action as described in <xref
target="scopes"/>.</dd>
<dt>State:</dt><dd>The document should specify if the network action
can modify state in the network and, if so, the state that may be
modified and its side effects.</dd>
<dt>Required/Optional:</dt><dd>The document should specify whether a
node is required to perform the network action.</dd>
<dt>In-Stack Data:</dt><dd>The number of LSEs of in-stack data, if
any, and its encoding. If this is of a variable length, then the
solution must specify how an implementation can determine this length
without implementing the network action.</dd>
<dt>Post-Stack Data:</dt><dd>The encoding of post-stack data, if
any. If this is of a variable length, then the solution must specify
how an implementation can determine this length without implementing
the network action.</dd>
</dl>
<t>A solution should create an IANA registry for network
actions.</t>
</section>
<section anchor="management-considerations">
<name>Management Considerations</name>
<t>Network operators will need to be cognizant of which network actions
are supported by which nodes and will need to ensure that this is are supported by which nodes and will need to ensure that this is
signaled. Some solutions may require network-wide signaled. Some solutions may require network-wide
configuration to synchronize the use of the labels that indicate the configuration to synchronize the use of the labels that indicate the
start of an NAS. Solution documents must make clear what management start of an NAS. Solution documents must clearly state what management
considerations apply to the solutions they are describing. Solutions considerations apply to the solutions they are describing. Solution
documents must describe mechanisms for performing network diagnostics documents must describe mechanisms for performing network diagnostics
in the presence of MNAs.</t> in the presence of MNAs.</t>
</section>
</section> <section anchor="security-considerations">
<section anchor="security-considerations"><name>Security Considerations</name> <name>Security Considerations</name>
<t>An analysis of the security of MPLS systems is provided in
<t>An analysis of the security of MPLS systems is provided in
<xref target="RFC5920"/>, which also notes that the MPLS forwarding plane has no <xref target="RFC5920"/>, which also notes that the MPLS forwarding plane has no
built-in security mechanisms.</t> built-in security mechanisms.</t>
<t>Central to the security of MPLS networks is operational security of <t>Central to the security of MPLS networks is operational security of
the network; something that operators of MPLS networks are well versed the network, something that operators of MPLS networks are well versed
in. The deployment of link-level security (e.g., <xref target="MACsec"/>) preve in. The deployment of link-level security (e.g., Media Access Control Security
nts (MACsec) <xref target="MACsec"/>) prevents
link traffic observation covertly acquiring the label stack for an link traffic observation covertly acquiring the label stack for an
attack. This is particularly important in the case of a network attack. This is particularly important in the case of a network
deploying MNA, because the MNA information may be sensitive. Thus the deploying MNA, because the MNA information may be sensitive. Thus, the
confidentiality and authentication achieved through the use of confidentiality and authentication achieved through the use of
link-level security is particularly advantageous.</t> link-level security is particularly advantageous.</t>
<t>Some additional proposals to add encryption to the MPLS forwarding
plane have been suggested <xref
target="I-D.ietf-mpls-opportunistic-encrypt"/>, but no mechanisms have
been agreed upon at the time of publication of this document. <xref
target="I-D.ietf-mpls-opportunistic-encrypt"/> offers hop-by-hop
security that encrypts the label stack and is functionally equivalent to
that provided by MACsec <xref target="MACsec"/>. Alternatively, it also o
ffers
end-to-end encryption of the MPLS payload with no cryptographic
integrity protection of the MPLS label stack.</t>
<t>Some additional proposals to add encryption to the MPLS forwarding <t>Particular care is needed when introducing any end-to-end
plane have been suggested <xref target="I-D.ietf-mpls-opportunistic-encrypt"/>, security mechanism to allow an in-stack MNA solution that needs to
but employ on-path modification of the MNA data or where post-stack
no mechanisms have been agreed upon at the time of publication of MNA data needs to be examined on-path.</t>
this document. <xref target="I-D.ietf-mpls-opportunistic-encrypt"/> offers hop- <t>A cornerstone of MPLS security is to protect the network from
by- processing MPLS labels that originated outside the network.</t>
hop security that encrypts the label stack and is functionally <t>Operators have considerable experience in excluding MPLS-encoded
equivalent to that provided by <xref target="MACsec"/>. Alternatively, it also packets at the network boundaries, for example, by excluding all MPLS
offers end-to-end encryption of the MPLS payload with no
cryptographic integrity protection of the MPLS label stack.</t>
<t>Particular care would be needed when introducing any end-to-end
security mechanism to allow an in-stack MNA solution that needed to
employ on-path modification of the MNA data, or where post-stack
MNA data needed to be examined on-path.</t>
<t>A cornerstone of MPLS security is to protect the network from
processing MPLS labels originated outside the network.</t>
<t>Operators have considerable experience in excluding MPLS-encoded
packets at the network boundaries for example, by excluding all MPLS
packets and all packets that are revealed to be carrying an MPLS packets and all packets that are revealed to be carrying an MPLS
packet as the payload of IP tunnels. Where such packets are accepted packet as the payload of IP tunnels. Where such packets are accepted
into an MPLS network from an untrusted third party, non-MPLS packets into an MPLS network from an untrusted third party, non-MPLS packets
are immediately encapsulated in an MPLS label stack specified by the are immediately encapsulated in an MPLS label stack specified by the
MPLS network operator and MPLS packets have additional label MPLS network operator, and MPLS packets have additional label
stack entries imported as specified by the MPLS network operator. stack entries imported as specified by the MPLS network operator.
Thus, it is difficult for an attacker to pass an MPLS-encoded Thus, it is difficult for an attacker to pass an MPLS-encoded
packet into a network or to present any instructions to the network packet into a network or to present any instructions to the network
forwarding system.</t> forwarding system.</t>
<t>Within a single well-managed domain, an adjacent domain may be
<t>Within a single well-managed domain, an adjacent domain may be
considered to be trusted provided that it is sufficiently shielded considered to be trusted provided that it is sufficiently shielded
from third-party traffic ingress and third-party traffic observation. from third-party traffic ingress and third-party traffic observation.
In such a situation, no new security vulnerabilities are introduced by In such a situation, no new security vulnerabilities are introduced by
MNA.</t> MNA.</t>
<t>In some inter-domain applications (including carrier's carrier) where
<t>In some inter-domain applications (including carrier's carrier) where
a first network's MPLS traffic is encapsulated directly over a second a first network's MPLS traffic is encapsulated directly over a second
MPLS network by simply pushing additional MPLS LSEs, the contents of MPLS network by simply pushing additional MPLS LSEs, the contents of
the first network's payload and label stack may be visible to the the first network's payload and label stack may be visible to the
forwarders in the second network. Historically this has been benign, forwarders in the second network. Historically, this has been benign
and indeed useful for ECMP. However, if the first network's traffic and indeed useful for ECMP. However, if the first network's traffic
has MNA information this may be exposed to MNA-capable forwarders has MNA information, this may be exposed to MNA-capable forwarders and
causing unpredictable behavior or modification of the customer MPLS cause unpredictable behavior or modification of the customer MPLS
label stack or MPLS payload. This is an increased vulnerability label stack or MPLS payload. This is an increased vulnerability
introduced by MNA that SHOULD be addressed in any MNA solution.</t> introduced by MNA that <bcp14>SHOULD</bcp14> be addressed in any MNA solution.</
t>
<t>Several mitigations are available to an operator:</t> <t>Several mitigations are available to an operator:</t>
<ol type="a">
<t>a) Reject all incoming packets containing MNA information that do not <li>Reject all incoming packets containing MNA information that do not
come from a trusted network. Note that it may be acceptable to accept come from a trusted network. Note that it may be acceptable to accept
and process MNA information from a trusted network.</t> and process MNA information from a trusted network.</li>
<li>Fully encapsulate the inbound packet in a new additional MPLS
<t>b) Fully encapsulate the inbound packet in a new additional MPLS label label stack such that the forwarder finds a Bottom of Stack (BoS) bit
stack such that the forwarder finds a Bottom of Stack (BoS) bit imposed by the carrier network and only finds MNA information added by
imposed by the carrier network and only finds MNA information added by the carrier network.</li>
the carrier network.</t> </ol>
<t>A mitigation that we reject as unsafe is having the ingress Label Switc
<t>A mitigation that we reject as unsafe is having the ingress LSR push hing Router (LSR) push
sufficient additional labels such that any MNA information received in sufficient additional labels such that any MNA information received in
packets entering the network from a third-party network is made packets entering the network from a third-party network is made
inaccessible due to it being below the RLD. This is unsafe in the inaccessible due to it being below the RLD. This is unsafe in the
presence of an overly conservative RLD value which can result in the presence of an overly conservative RLD value and can result in the
third-party MNA information becoming visible to and acted on by an third-party MNA information becoming visible to and acted on by an
MNA forwarder in the carrier network.</t> MNA forwarder in the carrier network.</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>IANA has allocated the following code point in the "IGP
MSD-Types" registry <xref target="MSD"/> within the "Interior Gateway Protocol (
IGP)
Parameters" registry group:
</t>
</section> <table anchor="igp-msp-reg">
<section anchor="iana-considerations"><name>IANA Considerations</name> <name>New IGP MSD-Type</name>
<thead>
<tr>
<th>Value</th>
<th>Name</th>
<th>Data Plane</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>3</td>
<td>Readable Label Depth</td>
<td>MPLS</td>
<td>RFC 9789</td>
</tr>
</tbody>
</table>
<t>This document requests that IANA allocate a code point from the "IGP </section>
MSD-Types" registry <xref target="MSD"/> in the "Interior Gateway Protocol (IGP) </middle>
Parameters" namespace for "Readable Label Depth", referencing this <back>
document. The "Data-Plane" value for this entry should be "MPLS".</t>
</section> <displayreference target="I-D.ietf-mpls-opportunistic-encrypt" to="MPLS-OPP-
<section anchor="acknowledgements"><name>Acknowledgements</name> SEC"/>
<t>This document is the result of work started in MPLS Open Design <references>
Team, with participation by the MPLS, PALS, and DETNET working groups.</t> <name>References</name>
<!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
<t>The authors would like to thank Adrian Farrel for his contributions <references>
and to John Drake, Toerless Eckert, and Jie Dong for their comments.</t> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
031.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
385.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
920.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
274.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
017.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
613.xml"/>
</references>
<references>
<name>Informative References</name>
<!-- [I-D.ietf-mpls-opportunistic-encrypt] Expired -->
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-mpls-opportunistic-encrypt.xml"/>
</middle> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
928.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
714.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
790.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
279.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
491.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
662.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
088.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
089.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
522.xml"/>
<back> <!-- [I-D.ietf-mpls-1stnibble] RFC9790 - cluster 520 document -->
<references title='Normative References'> <reference anchor="RFC9790" target="https://www.rfc-editor.org/info/rfc9790">
<front>
<title>IANA Registry and Processing Recommendations for the First Ni
bble Following a Label Stack</title>
<author fullname="Kireeti Kompella" initials="K." surname="Kompella"
>
<organization>Juniper Networks</organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization>University of Surrey 5GIC</organization>
</author>
<author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization>Nokia</organization>
</author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky" role="
editor">
<organization>Ericsson</organization>
</author>
<author fullname="Loa Andersson" initials="L." surname="Andersson">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization>
</author>
&RFC2119; <date month='May' year='2025'/>
&RFC3031; </front>
&RFC3032; <seriesInfo name="RFC" value="9790"/>
&RFC4385; <seriesInfo name="DOI" value="10.17487/RFC9790"/>
&RFC5920; </reference>
&RFC7274;
&RFC8174;
&RFC9017;
&RFC9613;
</references> <!-- [rfced] The following reference appears to point to IEEE Std 802.1AE with
a date of August 2006. However, that version has been superseded by a new
version dated December 2018. See https://ieeexplore.ieee.org/document/8585421.
<references title='Informative References'> We have updated this reference entry to current version. Please let us know
if you have any objections.
&I-D.ietf-mpls-opportunistic-encrypt; Original:
&I-D.ietf-mpls-1stnibble; [MACsec] IEEE Computer Society, "IEEE 802.1AE Media Access Control
&RFC4928; (MAC) Security", August 2006.
&RFC5714;
&RFC6790;
&RFC8279;
&RFC8296;
&RFC8402;
&RFC8491;
&RFC8662;
&RFC9088;
&RFC9089;
&RFC9522;
<reference anchor="MACsec" >
<front>
<title>IEEE 802.1AE Media Access Control (MAC) Security</title>
<author >
<organization>IEEE Computer Society</organization>
</author>
<date year="2006" month="August"/>
</front>
</reference>
<reference anchor="MSD" >
<front>
<title>IGP MSD-Types</title>
<author >
<organization></organization>
</author>
<date year="2024" month="December"/>
</front>
<format type="url" target="https://www.iana.org/assignments/igp-parameters/igp
-parameters.xhtml#igp-msd-types"/>
</reference>
Updated:
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security", IEEE Std
802.1AE-2018, DOI 10.1109/ieeestd.2018.8585421, 26
December 2018,
<https://ieeexplore.ieee.org/document/8585421>.
-->
<reference anchor="MACsec" target="https://ieeexplore.ieee.org/document/
8585421">
<front>
<title>
IEEE Standard for Local and metropolitan area networks-Media Acces
s Control (MAC) Security
</title>
<author>
<organization>IEEE</organization>
</author>
<date day="26" month="December" year="2018"/>
</front>
<seriesInfo name="IEEE Std" value="802.1AE-2018"/>
<seriesInfo name="DOI" value="10.1109/ieeestd.2018.8585421"/>
</reference>
<reference anchor="MSD" target="https://www.iana.org/assignments/igp-par
ameters/">
<front>
<title>IGP MSD-Types</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>This document is the result of work started in MPLS Open Design Team,
with participation by the MPLS, PALS, and DETNET Working Groups.</t>
<t>The authors would like to thank <contact fullname="Adrian Farrel"/>
for his contributions. The authors would also like to thank <contact fulln
ame="John Drake"/>, <contact
fullname="Toerless Eckert"/>, and <contact fullname="Jie Dong"/> for
their comments.</t>
</section>
</back> </back>
<!-- ##markdown-source: <!-- [rfced] Terminology
H4sIAP7UbmcAA+1963LbSJbm/3yKXPlHS7Mky5IvZWtiI1qW5LI6ZFtrqrZ2
YmN/gECKRJsEOLhIZtuuZ9ln2Sfb851zMpEASdu9Mz0xMdPq6DJFAXk5ee63 a) If no objections, we will update instances of "sub-stack" (with hyphen) to
HI/HJi2zvJif2ra5G78wTd4s3al9e3M9te9c81BWH+1Z2uRlUdvDt+/Ojuzr "substack" (no hyphen).
Klk5fG+S2axy9/Twu7Po26xMC/p8arMquWvGuaNxV+tlPV4Vyfju4eP4+Jl5
mOsUv9EbNLv9pSrbtUmTxs3LanNq8+KuNHU7W+V1TXM3mzUNeHV5+9rk6+rU
NlVbNyePH798fGJM0jaLsjo11o7p//yTF/WpvZ7YsyJzVV2Xhf+DrOy6TLb/
VFa0qDdt8uBye+vSRVEuy3nuav93t0ry5aldlskf1/mkaLfmm07sq2qTFE1/
smnjHpKqGfyNZ/u1yO9pEXmzseWdnbZV5Tb22S9X54M569kfaxllxoNM0nK1
Nf1bmr5M07w/+9ukaRbuof8nnvxd+TFPBhOt5OnJDE//scATO+e6ndjrwUS3
ZbGJvuQp/tQW+dpVHpGGoGzolcky/6P+a0xRVrQCggkO88Pr85Pj45f68cnj
J8fdxxP9+PTJi2f68dnLk8f68eeTn5/qxxfH4ePLx8c/+4/Pj5/gowGaRVNe
jS8mHb6W63VZNbSFusnTsSvSarNuth87rpsin82WftFPX5688Gv6+djP/vzn
l355L05+fhk+vnzuPz59fBI+vvR7ffH8+UlY/4sX3Uc/wstnJ/zA27Pz2qWn
DGGl4avLy0v74vHJ5Pjs0r51WU5In6auru05UVRVLomgz86P7NSlbUU4yO9m
RIKn9qydE4FZorDn/G1HYuFsefTzcrVuGzrhaZkSRDDE2+lFbxUHV7/c4Mvx
LdFwfRBNcuFSt5rRyyePT57y93IYfpq2Ihw5WDTNuj796aeHh4dJnhTJhGb/
KSGuMC9Wrmjqn/L5erxOwH5oIcNfJ58WzWr5CF+u6mzcyBrG47FNZnVTJWlj
zO0iry1xrRbj2czVaZXPXG2TwiZVusgblzZtlSztnedxWKglQmEeZnazySZi
IRPLPDL+ioZ2tq1dRlRAaJjl4H020SGaRdLYfLWm33kemo+oH3yagG9L+qqy
66rEYeK7w7pNFyap7aos8qas6LsjcBS8SmN8dI1NliU9iC+uk5lb2ulD3qQL
mv4maRb28Hp6gzdM/EaBtRGrTYr6juZLiL6TLMuxQgIGnWFiC+cyGkPBUTuj
G5gAqq4DKq31PifI6mbagt6m5wIcM3fvluWan6V1J5aYDu3F1I5/LxTCHjxY
WiBdGsYtHeOCrVumWcCkW6opiQcluuxVmbmljJAm62SWL+kpWhjNwgJJp8KR
GcaTVZ5lS2fMI3sFoslaXsO/S6zB+DtOt+bjrY+w6Z/oEd6nHHJthqe881jt
f6RjBUzrctnynIaUAGL+tNeqXNGa6Uy78wKw86JxRcYAx9wV2Ce2Vrl/bvNK
1md46/So/fxZpcvXrxPCl7DaEc+6SjZGt9Kn9JK0gGWytu4TZA3tktd81xap
bI+Y88QywtEQdubMzBXuLk9zoBfBuqDjIAWqplUlpNHUIwuGYMEQElav8oYg
RLtxd3gLx0H4Q4cxywvXzdqbkGFZkObgv62xQWy9JvgIDgsSEVbIejsmFU6U
IUiMtvXbLWVvtFqwZ4bqer3cmIiz+JcfFq7oDapIC1AAKVf5fEFcskiXbeYM
6WXZeJYskyKNH7ZzOt6CAFBbB/pdb0YYmDkoIFcCFJYwCWhn7pK6GVeOV2cJ
AxN7R5pKW7kRg2PwYphjAUi7JgHxmIrQ9j5hEA95dwBLYMZros/JkJnM6XSJ
c+R/UcpKyyJ16yYg88H2kAdA1NIcDEjqAItQCAkD5+8F64hTRWdh89oAqR1p
msISko8Mg04kAPBJgHjNAw5OXgXAyM7ahpHVTy4yK5BsLTILKFqr+tEh2si8
P3sr8i0j2BM6uyadHOmqCaUA/IyoL22WG8L5ZaJLjsVkLMsmPSbQw85k+ZBs
CMxVPp+7ioaZbRgw784Uu8NOFsm9g0xegukGfks2Sg2o4bzJ3iHyGumeAY2i
LMagfOW2I+w3y+u0rcHDmWFMG1o9sQsioiGzx6y0JKJ0olKmPFKcC1JGay/c
mduP7K3MbM6XpBjZw9vzI8HX25woleByTTRAX99eH9m73C0zJmV//CoxGlqi
vSQS2RgSF5dHlkTIAo8NzEAyU2Zjefrw3dn0iBb+6JH90LFDGrCYt8nc2c+P
Plz+9zFR5PyrCI6PZN7QUDT/wdtfp7cHI/nXvnvPn+npX68+XF7g8/TN2fV1
+GD0iemb979eX3SfujfP3799e/nuQl6mb23vK3Pw9uyfDgQoB+9vbq/evzu7
PhCGFlMeMILgNRO+X60rB8xKICZEvvOhvTq/+b//5/gpHd5/USPl61f9BfYG
/QLWJbOVBaGo/EoHRnxuvXZJxfBfLiGr8iZZCmLUi/KhsEQmbmKEwwmsgAb0
DHNKfbe/6rwg7vdA5JUmkNW1XS8TeuiymC/zeiGjjKDwMpYuXA72pWYP8a2k
IFSFbDdnS1Lz2/lCxs9ZmbnqBDK0Pp1zpIoBsSZir4GcsL1lrtKSlCCS/zZd
JkzeKj1iwdlRNEEaq3OZoNOtq1Y508EGvz8iY9Wv9wLkkIvwHvDNJCvXTa2a
R3jK08pduSQogTfQya5YV1APRu7pGTpAJMJx8J1JSmjVIwRGtD5pXIlGho9E
G1dHQLwzkkdLAsHGXkC1Ojy7OPKIOE2JHx7QjnuawgAjcfDCAupd2zg15h++
Q6FkzlnVuJRXjnBuTT5voTMQsYMfGK+Z2iUzhJoHAItLk6rasBYR6WYR11W2
GnR/iOfAmc6VE91e2/tkSdLF44FOy59plV6z8fwuExGCvyqG+nOc2hmpMwQj
EhcL4i2MM9+AgR4KbeTw3fSKoIHl3eUV2be0hmgJBkAhwiHUsPXasXYlsBBz
TNVtOQYCT9X4JdHLE8HTsxihiKK+9L6xX8gOl818IZZJ+rYjyW6/mC/j3s+X
HZ/oM0a7sN0P/dpHri897MXzr64uP0TPvyLIETzcJ3v5CYKMfv3ggkTz78NB
4d8vp/F8r8qmIRqBs4phqy/AuaEvzKY31/EL4EhTBeZNW63L2lugfrGPj3/W
dy/P397Q15f/3NLD5yUd0Nt22eTQkcLTz05O8LTF49d4WJS6/pjRei4/kJTo
HvvgSEmbLf0aLkitCmPD16JvOeyC3vqkyv++HWxt4c2rN/T1m3INPWJB/3yB
GcCkRdIdCOY+NQMan+DFq5NLfnYuFkZpL+XTD7//yw0/S0whJ1T/JYG/cGNv
qrIp0xJr5aemF/zUWKg72400IIsv23qBfxL+N30Si/qy21m8Pexbnvxt8ilf
tSs7vboYgP/py2N9kngnfbubudLmtocGA9l6oWMBX2xfUPAr0x1z7OIau16+
4a3cEIruhyTY3ufP9KSuURBxDwJuTwH40H/dnL+5yiBlSXmrOnA99qcgyPpj
VPb51D66TWZjEtTElsRJ998OemzrwH6FB848osOH4UYqOKkGRc9wFgZ5xyY2
KacEJrYvhxq2N+/4Q2EizwMZ4qLj7HICiI6SBObG0BUBwdIoZz0M8QEBf+2V
1Z0yTN0e63BaBuPRAqLtrODulD2xusZ2Kw8Xj4TfB9LORosoU7JkSP2/402Q
NkcahdgGgABpf1Dx2mUmck7YLu0kWns02SgMEs2qUOp2zg+tB3gIhYoES5mx
aLyijTlHCs+C7GVayDL/6Hg9JNPqcuWGcH6gXwBodQIlsH6KjVmXOTQ2MV1J
L7ye3hAIY+kBD09/qGZRQZ0sRZCbGJQPCgi/KhL53jfByrD8nezvllZTuQdS
IZ036nqH21hHmiZ47Yi2w0iaQEOqBQSqOAywjN1eg8VmziFWseskRGeFQQf7
j3XXJCD4siw/ElLX6qn1igUB56bz0KqiwKMaWXl4pSExQX+Xb8F7H2j/Mk6u
LkfFEn5cRZkR+o7kHZ312WCjHXZar9yQwjj+11CWrN2hLq2V9yxF+0vpJFwW
xJd++7DI0wW9DxVOXJlBt+qrVsne3Ux2bCIsvRbl+9S+X4vVstyMsEZRgfPu
MZCA6Ty3YmHv8kxO7NVd/OdoDNpEUTbGu8b8AnlCz1xSxmWhSDy2AhwHRDux
Z2awWxq6TvJMDVK1kMBdGuFPbJ6FpejZeK+Fqqz35UfdmQzKgCP5L6ctFgkp
BbGN8BdXlYGhs5bOY7EVMKAZ4x29W3x/YNdNwmH5vQUIGu/QIXSq84x9MP1Z
aM2XIPEBeAJAih1LiBDf+27M9sb4KHuHAHQnc9lVEdH2HjH8YlpWNPu6LLLa
u/mGbw0PM2yYJzExc9qaRGUIoS0AvEUGLKxIhngZnHkYBAWC4R9bjf0RJkEF
NLForbxFwl6wFevey63DBZth1HOfEnDDUX/t6pZlrghRMzBaezIALI3UAkQB
M8ga4ivEnn7//XeOAD622z/HO7472fHdEx3hmP76xD61z+xz+7N9YV/+Nd9h
jP86/hf+z7Ad1P8R1r39Q3rgOf33sT4Po1m+//tK/g1Xsl868ryPh8/zSn7f
sfS/5uf3/kr2LoEdN0VLxLJvJf/BT+c7Kzn+N8ST6Ocm2SAA9Y0nsBIa5XU+
J3vKHp/C/NjBDG3HDPegAPNHc+4qKF9bkjc4i70xI6IAjJkUBm88JXeNq4a6
tIYY+THW27ZUFEjHgeAyg4d+THTZoegyPy66oIvtk00m0jnEfkLQZmuJO+R1
vmUg/suE/JaQHBppIibVpZ9Aie77XSEwRRBvLT/+owS5GPn+Ljr/kzOioT9q
38/fQmDtXUQksPas5N8Pc9Yf5dEnWzz6G1QpXHmfRynwDknX2PaSzXqhsygL
y1tY0bPM09haqhvicyZEhSd2miOeIPYhWCE8N1hpncPl6LkXAupqsSM4SYLH
IKRCnCtZlnMynz9/PtfPX78eCbvs70sTf8Dg2iJZzSSU5A0S8QeJuCBmnOb1
IHSNHCnhmFhk5tbwsiNHSGQBu7nhbOqlsEVxdUll6BmJI+84xFF1riLJbdjK
sEjqmj6onRqchr/9Is6v2i1d2rBRyrYiPVXAzWkCEPypxMIQvnXOmRm+ZuPX
zPC1m+mFxDw5Gljbz49q/vB1hzcHwh1uueASYP+S4KO7dwSKAi6GkF5iEDoZ
weZlRx/nKoSgFR71/jykx3Aqip3iQX1CFmJ8ski0CEZBOjuOPr4p1+PZZoxo
x+GbV2+OTu3ljrXw+AJfzbbpuyX+wQc/xk051uDH4dXJJfw4hfhPiRbrRoYN
eSmDMYmIB6NO+TB1EI+gvc3/wOKu7mJ/juZweY8RIwvDasSJViAQ71ViB27e
mM5dHnuZeBFd+lFM6B5lu2y0rHTsa0J0P5VsHjCBpkrYMasQ4XXQ4HzqQIGB
l5PmGW2pZfCFF5td2Cb6ieF0kY0fvLKSOhbcvoIoow41inIXeRpJaOH4/9Dh
seWkV5VTEDKarzbqrYCHp1w3+SpZ+ljxbngRKjVVrpm0vZE0CyaKa0hUwGNJ
L+KBaTUXh9NtI+ALAd8kVcMBmOD2ZSWwlzriA2jHX7+O7NLNkxSD3uepZ0ZZ
qWtOy3mR/4WZuQnOU0FRZBAlVRaLCfEKsitZHszrvtuVlngxmKc3R/ekaqZY
RfB2c7KKKvzf9/Xtk4JEC6YtwrTZd92GXbyE0KrIlhzPeF+AqxBXLyQhJPfv
Fbbvnfdv14BKly29tQHOMyTCBVduC05LZLm2vVDjyWXaZX35pW6NynMDip1s
F5FIL5D5gnUPJV+A2x9qVRdIjHU5czAqCkmk+6sAkFUEANYEGFmEoXfee/pD
b7N7dsThBaIxQry/anbP3AiFzPdnEVLO50XJyXnL3tLM/qW9H4IlMoVnLuhA
cgIdJ1cM6dQ0E++NE4okiFaoCPWJw6PI+e65g4hkKEbBI6vkye5507F3GHzQ
5DS6p3mLtAEPM2ArRrkDYnpOZvoU65HxN1H3goCGhlBvqQgIlLFYRqTMSAYN
xlutNL9ZnfwOryH3s/DJscLo2rTRsJ/ETYj1oXaJV5YNuJdPchbE8C7nMCVt
odYZwYIZsGlekW5GnL8Ai8ol5VKop1Ng9y4muS/zrJasZ15OlwHN1N0JPF7C
mNPWqjm4QeeaDsm+OC5+7erm9YcPwrNRyvP1K2O7pFSzFFbNjdA1WQq/F/WE
N/6Q1wuR7yuk0rY1K1YcoET0kePiuwLmPoTDvLPlMrXGK7cRrCP0YqnAKfx5
E9KbjU9vDq/5Y6EldOryXh4sVomEkDKfc91LrvecmlRpr5LWDAq1kDT3xGuQ
AGzbjMu7segRokT31HLAZTAoh26Ih4wH2smctttKaiGH5yL9TFWMOrAD0tz9
EXUqWs9B5jQdarnRRK5deRrG7MzeOPxwfXEk7Jwz15i4AdmWq5vozBEzGklc
k1FOag1C5FetFkQNBVI+JTtNsJkk03Rdsn/KlS8PMOHsG+C8Z7OgH60cmthe
XlMUS/Yh5N3bQcrU0WR3poqqFVwCoGnpIwOO3eWsZ8EKCuYgzEwyuUqyOH3C
QxzKlhnM4eX1EUiP0BMhP+TL5F6Dy1BbUuhu8ZeZSxNQFD8WTxSp2omkHIag
Zs5YsiGredVphx2vGoTWvTUdXpEwrpRYEGA2MT11ZVl8Nl3NhFRRKENOMuI6
DcxhOk0sXNYH+A2WYnqgAbWq3PcjZPou8zNG92zSZz/rltkPzYTsKJL25VY+
C78MD6ewV5inrqhb9nAKJhJfiVgOJ5Z8Ivhq5qdKF58TIHyICVas3AaKvvzB
p7jkFTYOHZFXqmncOMlAovbQTeaTkdHEpRcvoCv7X15+/XqEqTOU960kMT6v
2YChpQEfWRqzCjtzI45QBx8sM3XPD7lqQxnSDMf0sSgfiHXN3WDvZmAmqpBj
QweHuMxXuc8HEa7a1oosLJf4PNuicIAVDCKU+yxA1oSYLaeHhL3TGd7QMUd0
y9ZaONQttL28FqhHqGX6WA8IwL4HpXCKjH8UEzP5YH8uHhqZOM6EHPUatWh6
YG/P/imaa0ZYqWPQxv2/eqgEp7o0rMLU/Yc0E5idP/kdB51hNsxJH5X4QTgg
8yMH9K0TYe9V0fF/5qkkqPhkINeu/HR/2L9IHCBYHgsPQICz+jsw8HuMaZrD
lG58KVY0gQl+AzAMEP2O05T1Yh6FYjcLTUJotATB5c33sLcoFTYhNWCFcBET
J1brjWJVn5XZRuxF6mDi4t2Omx7evjrjckIGBuyb7j0OZbxjVPGZnts5jIfT
KxKZKm9o/KORuc6Lj5iKHRfAq0lIOhTEQ6EI+AR2g+UGDsBrFTdMrnTKGUvx
qlCIw9Qge4AEZt/VrQ4WPep9e4QtHyffeQYrC8+EOQI6RI+ceRzzkA7lTpyF
QkixIAvgAdjW17FQWCjaf8x5xXIMZqPKv+Ax7bk0REdlr+jnR1JutMO3CLpI
iBbVTyJeVDKdq86Y0TckTsipcHmQDF4VZaNLhoF1E5VHaQ0Ul4l4ax7JzWto
RSlUuRF7S7cH2jGIWlOshyATEfW5l96r+vkRJyvRLqcweZCX5i0IKfYqfTLW
u7OrWtjGzDmkFJVIX8s4OZW2WDufTLRakabp6/HksUTrTcV80eSlrjKM13dP
b6HGIrZLJ9aY30Dju8rRuuzWzi3dS0Vkbla5OSELc4IQvURpu9QY8UCVCyU1
TMre5ygJXUQ4ZE3vz6/T0i6WqpDfGm0Q532/OGJkypBm1wuQdKljXV5tvpXG
pQy2NLDzRIV1Wb/sMJgqwWW47dPkJNBQET30LE3shRczOwPmmBvmXGaaci4l
nrm47ll1qrZzjzu5FSUAExbGCeDBDFEKCfYJ145mWU8nEGiJihYdw1Qx8Mnk
eBSXTpmXdDpnaVpytSMSHINnwvsQ2PXBlmdX9as2KCaZEc8xUepxNKnoUfzt
dEzPHXFGbpShG42DyFEdVGNxbMmAvqKJtZzBTrXKSzmVZrI+ImrUQsFexuk3
0HRfxY4ZVOx8I5M09lYuuByVWYZJFyV7S4OV2ptArcRLXzotdS4317YfA2R/
dyv6vtt69hDFMkesIcD9CAHGOJCVpi47QxW2Kctu9Ra1NYoraUUzWj/8RnBq
k2YKBhcXn+o5cFGgpLSHxNErDjpd3fXWlRcADnghFocd85K8b4jVTPVn7pzZ
Ky68aDlBTiqEFcBuQKEOdGfR8gh+gxQlYhpMtgrVd+hXo0DagqfGWxKuTcdK
wU/9W13BzvfejJ8kjN93EDY6CLOn/j+IelJGEI0YGP66qV9rV40v1EMgBu9w
gZy33nPKiO8Xw/siwMiGU/9ZXJW2H8s5mJQSrBv2jBaEQsxHgi0yTOWNp05L
5jM+QTtQPw0p5JakFUnYSCOP43Ni4nRzcjwyuMyCl0hcsy3A5B0pss/UxwB0
aeMHhJ5JwpLgH3vVR/KCIibbnSLT346BR6LXD3zBf6aTFrcQ7c5DR/nVua9l
ZIdw02NUuzOCooTw0kcxTx4z84VvXzjf/2Cd1Eu5YY0dQvOh7QfJ1XfTq3/k
B2k5XM1tDp/wgEdhCOScHL7wX2p+ddspNgrSpYPmc3wsskCjAgrr1qu5XL4u
af0elTs4gLoTQJSZSS9PoIO/POOX7N+UQnTlGp3O/gOg9LUhIXVqZ4SNTOe/
J0TZL9O/XRrSroWc+gWxnTXyuL7j8dvzU/lXehdY7l0wsk/2PT+Vx4fkMbKM
vrsmuL3mV7gJwq00QTA7ngv5Pk9QBLHdDQEo9LqtWCtkLe2h40dOO8NE5sR+
RmQ6QqhdwH8vMH9QuJidwiWiqw9OqfU7NOlN6b8JSf6noLx9pPflk6X/EeXx
v93//laU99cR3idPRxAr90m+TNT1y3KSw3GKLV0Phe1RvkONnAzXi7RCv8EE
UVVR6dX3b9GNUQHevfevQDD22hVz0ky68n1mDMO8BclysiuHPgN5vep61vRj
v764jwfFQN24R8IdGMbbEXK0rMlVZrM7J2onYFVU+4xpl9T5chMFdB36GpE+
sFWS2AViMcgggMj1lMMEO0xI0z2UVmx5dc16sYphCLXKh5HGODpb01vPPrwu
7Og6qZufziXxU3b6Crg41HdFMYN+sxbe2isF9M2WfHDBJ5IibUcN5cJ9UuWL
Q52iQc5y33lIB0rjhcywXuidtYTl/e82JW2o0gKwyD/PaiCKpUuUoOVS7qxL
Zs4oWeZaY5eh8VPifbCcU1nA/HZsWNHxqaBICpNUNEqVVDjUmsNmfAq3w/k6
ozsPh8XGGeG2N0MVnV+zNjiEcrluQtZoQvj2iabChIqvwvUteyj4j4aNMbwd
eQd0bS5+v4f2OkwXtTfLpJoDraWhTBl83DASgj/OHyywcbh5tEubuWHjsj4U
EJkhHPERNP2VMy/F0R917tFs+Xi9cMxmyIqS3i842+CGpRfJSKHRQpYEJ+n3
gFYzfhhmNewenFVJkS7EmpbZyjkZJ8x0LqOsT0n23DqrdFGifBY8IwSko8LR
kN0nNc9aDK5cVNTfb3k6XsexsES6riBQ5kfwpSZnksc58r+/8r8D1/W7c/kO
LkIzMGI15r6Mt8PY1+1Aq9O1nRZ2OTKzpO48f94794NFnrw3s2tvQcagM4dM
rmOTtjeyr0b2PBhF7PExIYlxEFHv+n6pAOjzcplN9lmadVKpfvXdHLcdhxbV
94vVWHLOH/hSyP3QDG9kWkbtH3Pu7KcrJ7TrHTlTYO2jZ4WnoVBxxCsZFNcn
REBrEZXPRf6KJNEEFE+/7IR70iVxMX5ysF7ybw2D3meRxK5fdoauGbosJDVN
E72QC032ZS87W+fgB5IblnU12XyoeR2QKiIdXkFEK+o/33F6nNXOhxY9PrFv
ygf4A0ee7fjJjJ8M3bb6nYBUf96egzO3+TwDdphhG6GQLyCZvvwcBNl9nrVd
a0Q62GkQwT4h3IcgeCifPSgLziTQEVprmCgZ4+zC8/lonqiphVccwojIxeFR
4/4bdalhx93dPDCLBl5XZY1EtiTLOV7QFll/z8O89kH6gaSDSMKDYcaCSBL9
vey1KY3Z7VYHu8+Prt5dXP5P+JojlYejCP4dgVesBH1DAzK9BENkUg+dSp1n
L07951axogVsIjWVtWER7FDSfSkGLTtUZewT8rGo2NNjlYVYXuOP7LsfcQCr
yVEOgRhyIY9oMcggX7Jf/GE6zbiXkQFHNVeeCL9gKN6Xvq0ku6R5cM7HMIL5
V8P4V+SeRxPGPMiA8DJD1mt5JrCkrmwPYN7uqeDTlI0JkE12aRjdgexL8eWO
mctEVTs0MpFwrbKKSEfqoh9+9UGD60sufVfcisfPB60ql34po+6ERMXkczfS
tq/AizjabfYV7clrYN1mLGtsIyPsqzf+DCqQi0NAE2XsjMrgadCdou6iRjPF
Tp49bzw71SPzFQDdFLQees4KOkqUkB81/tF+PQ33SPE+iv2os0UkoREqoxOZ
iyR32DUd0NizsUTaxhrNmlAKYx0v5NNIL+PlRlylMet5ZN/7nG17zhlEP0yu
+1ANNGmUbLsuqjZl5nhYrvkDtDHulCG/a5oBK+zh4I0gxu0AQfWNGfjxMHtx
WGMbKK1rcJKEohikYstqdlKVai0BY2CrP4gKc7/VW2mgsXJhcbS3F4ow4q7a
O0rn0w5a5x4KOX5uYnrzYkZnUCArEkPatkQSxycvdKRo26bbdtJ0LD8RCvsG
FbJSA+CYLdrJfUq3j8ppsmjd5NwhSWPNupotg4PLMqOuL58foTPZtgHCXV44
pQFN2FjhvwD2oUxNjiOR6A90E86nRV4/PdOVaqTlWON5on+BWGiwifdH+tpE
X8ONBtGS9i0Q2arVDn2zuMFW6LWD3A/RSsT8zmGqae/lfYZC0EiK/49htMNX
ZBcPW/b0cgHACF4zI3/H90Pg2oUoScSIi8cze7lDQirzoyCfgAIOBs5Q8Q2T
OIGdb2yIm3LSolLtC8BZexIMwSUZ6EfO/QPptPOMz+Y+dw9gCDRGbwUtXmQ5
2ZUyfP68584L7jpFI/QJVaMwuAnj61dxoejgLJ/uHSHtPDRthgesbNlZJfUO
3p0iuVoHTw/AJg6eH/gAreRDjfSj1HJqOYG1Nkoc0cJ4n0Z8dXP/FEPRv8/F
mN3VahJjHKIV5ZF/L+SlyF6v4rqkogwB8qhpLgnKT4QSaAq+KLOh5V3YS5AB
4Q6Gu6ldm5UPEHNALDRLk6pp3NCB3r2xadkBw6tD4qOncTwC+QxU38cNW/mD
X/s7MDt6DblDUtgrS+SD8eaKpnCT4bcsN2A02m+1FldgU2aJtIf3U3iXK/1L
4suJR7lF48BJwPIo9aSHbnj3221J+UDQyJQPpNc5QtuVvnwO/OZep7XTusze
JGQT0yDPVO6B4sFOq9Zplwp+1WNLIrYA10UNFt3B+bRDxGF9iigZUY1GQEJM
gyHYdZvvAAYnXbBq8CxkuEfoYtcBVzDMN9Fl5uZ5oV1FsPNO0nGQWVfSOduc
C62T4fey8zLhkr//pRD+38Osa9keBol2CBIbMYFxEY1P9Ic3VSReEu3B16Pp
Vgb7GFlilAvvzRMnbRLmgjVWzDnfEyUzCEXgDH2ps1hpyIkTWaX3FMQM0fq0
k9o+nj2mn4DG0Qp7gAXK86PHxtd49P6+4/2zztA+p20UxNHfMCyMPTw7f3PE
Siq6iX6jJG3LXR+jjCQx9DoJaPWWX40GhLokOjpCr48D6sO2JyxigMbigiFF
jazwrrbBO2uCukuGgJb2i7uJ29iXogj4HgVWE0SGsQruXkkqVp42zDTyoner
hyvu86qUe35GrEd0bQSiOngpNCClKRoKdni/fpcTiD1Yk4DKfLtT15zBRNfq
sCfI+2YG7W3ZV+Zbmcbt6Uzc6SaqfGV+obCvFd9RVNvIXT7uHomiS19inA2r
VCf2psrvEc7YlT+5z8lomD21MzowDK11VnCe7RuNocT975mNZT7TNu58s7Nk
c4BboszJJAE9eddayBKtnnhYzSk9sY/Nx15Cl2OgWtf8XXhJ/1RMuFQnNGcN
ctpn/vC59ZsN8UmpE1PaqcuFZjCCklVkw/dSSnf0HA8dKE9DIIqIS5dbecul
n5rIDQtUUmz7KsSikT4GgIoMHJY/4BWaXyu1fv3iW+XUwym2k2e0+cRXmbPh
i7q+NWe+MzEABuGKbI87qKiSSt734I+8pwT5dXzojWSXJY2PKfL7uegi6BYK
6geWSDit5gXqtRPZT77V5/cAJCFFrS/JAX1v5Q37MOw47l7fTEWQXnB5q6Fk
1w2Lt8vxeG8OqgNbdEbGZmSLMxuUIFOUiNFzwAGkEV/ZdjQD+v36KB+2Uo0B
4PSv+JKJHfsd2IynW/2/9vT+2toZzfeDexvsLF7oD+5ta2dmiPV9x5CiiKRG
csnLGUmNirSnGj3Po3490eVmj+zbLp1xaNZ5ruAzKFUVjwSWVHEncivWzqx4
bmSmLhXxg8fEHXRvPyZX7QWljAFvfCmu9nTpx+y9Yy1OqUQY8A6pUCE5od4U
6YIEsK84j9Rhtk7rPjPrRzQkwITZfT6JUqXmNHBqOkfdaW/SZdonpQ6qKUIL
8RhdavEMRD56pqkQFzGD6UJHluDtEzVfaT72FWd5Mi/KmlUaX8fPfrnUV3B7
xUdvLhpiwBnCP8lyU+dBZwu3HPlLnKSodGhpS4o07rJE5Z+cOSfyw84c9iuK
rjtaL5NCKhqL0szafNmMkcrjJ+32DLc3LsIi7coDdLgyf1caU2+kjUUPmohj
/KMEEBahaLTD+60RcVoPjhCXWwdkBF3pA6+2pr8oDqVX4yUuj+smlaJQklBy
0yXKQKE18f1reN5fv2TLWe2qe+8fhbmLWr1UO3hvuVbE1DNJI+GG0AOxK0ta
co4NEWJSREEIIYUQuTWyA67ORnm9t974sIihxG4a38DGoV4f8h2ztozQQoNc
KNfdwobbN/GNpmXoxTpQ5yu9rceTptkFueFmQpYKKZwTYw2zh+j+ta68Se68
s3r1qTKFXehnPP75Sqq6nc/lJrGh62jnrapAdlIiSV2NybMbLplX4HTtGtvX
rum5qGai3YZELNNXGu2Pzk/v3qHzy0KaWRl0swoQlBYB8mi9hUFaotfdnkcw
NuCvZHk5fw9c0nRkTty8Q2NkUHTVYajkyfXWH6NLckWGnlhIEItOwlf6yZUK
YhT7XgCGnyrnVbImDsJq+Zw3gmR7l26932sCagklbgK+SEuQYcqrtMzRhgK+
IVu3TrPNeBiXOArK7jHVGnoGmgaQNafWuBUIypbFmKsIRB3sZ9zhdVE8pGNH
Fff6NP6vUZ4ujMVPiRSN6sCsDaRlVSBLjkMSnkFH9CO17o0vjvSCAklDscHY
ARP9e/I5l0xkwb6JXgXdvQ98suvoByECLQm1nlXOEifnwnZtfIcZxhrHMKGi
sr8qDuKQuqXFS8HvSGgXjQTjM+ojIUoFhxj19xByB5flnh6qvPjroPwFcr4T
hbpEPDKiJd6NbVD6heIObVPDGZRRKShxMxSbsSzgS0L6V/VxWhZ3Y+Irv5np
oQMRGBqRCt+vF11nallvylcr3HbcaMJdsq5buawquvUuJuDOpSgpYqa3hFAI
w/XO8WSSUtcxzvh2B8hYnIBIDkkUGc5jd84zsQbSwHtdUWgIUmxUUlmRVI4L
c9a470+3NEALK/DshpcXQm/czdbFnBEOmYi3i6JCZPKbvxAQuL4UQT4WrS3T
+nJ2bifZn5MUk0TR05kLSl1AJH+igS/6pEl4QVsfQUN65ALZdrQzf0lrlY0Z
AYLMz/XeJHFybf890gkm3MuJ83hpI42khY64Xt49dER/3y7R0KTX6ybqoDLb
GGlT4htDsetjrDuOXWT2sGtbKSHq6g++EXN1JFzLJN6nJ+CnBxg1wvbqPh6H
uy85Iwy1vQTcrI+2qImHKbThRiD9q3P14kfuSjNwMJrIwRgWEzzjRdYjHFVk
7vPg/gb1hG5W3Y2xvL6ufty+yVFZrp1hWGKHCNfMFWS4jIxcBpyx2K/dXSs3
3SKYEfuy+070sGAFnMGoQ+2r6e7RBZstNaJGj4258n4Z9eOqDbQ4AK8tYj/l
zBHt454tvk5iWzClhNmEFdoNJgZZd/8ygzRSOKXBD9pGIDgXod/G9BBPHKwg
Fe0QMXM+F96zuM2wAYCvg1/lHHjrUkpCAYDwXs+DTo1JjuwH92cumCShEFoP
ed6n/jLVdwcA7hLQOW1EmHig94AG78qmy5TWExFxEJbEvxlxE0uvmeFsewY3
ZnZkX7fLvghQLyVLyNA6sdCS0CF9xOycGUawvrp+bQheIstiWLR3+KqcHnEp
BARA3bF8JfzO3vd3hMpIw90lmSiMZse7rLl0JyrLe4C8lmPDDYl1csdRJaCr
Gj+eV15PPzBrMB2v3RJmdbRxj1b9WyBTx9dnk+XqMcPxHXQDr5I/pYg3Rx3Z
VkmGdjM4bY2kZS2ff95o4IeT73hE7h4UiMbvUO++iax0YDOu1ZYuqcL9tT2M
xJXFuJYWW1HduonXONwv50FhPRHLY72Jy6SlvAD3nNFrHY4Ek3F4eo/E1zT0
HvRbFeudzKqP8Qs+cMUBsww6b466F99V7ODqlxvjm7bUB50vi4wOvo1OF3Sw
/7bAQxriCFZAsoKvjQaBJ7xeo/Es2PDBruZgB6Nwg4wcf945YSTyegA34vgG
tuKB78Tiy+sdXzHYOewPQIMHDKWzNDS3kfvWByDKfREQHyNcasArdkQJR2Ry
JnW7oIXCLWZuXbIaafiLTR1E/nM5P6+YjezNGf6L8724vH13ecvjYmtzsrvX
0qLXsXXOTj6pqeUrb9jiKz7as6zKCcFe09E7EWBSfQvlcKZ+KtZZSvunckHL
q5KPpKnfloS4oNFLKHqNrOFPubMXaESlgb2c2/AyQGgl/w8qGsldyocAAA==
b) Please review use of "special label". Should instances of
"special label" be updated to "special-purpose label"?
-->
<!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations per Section
3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the
document carefully to ensure correctness.
Operations, Administration, and Maintenance (OAM)
IP Fast Reroute (IPFRR)
Fast Reroute (FRR)
Label Switching Router (LSR)
Media Access Control Security (MACsec)
b) Is the abbreviation NAS read as "nass" or as "en-ay-ess"? We ask in order to
choose the appropriate indefinite article for it to follow. Currently, both
"an NAS" and "a NAS" are used in the document.
c) The following abbreviations appear in the text but do not appear in Table 1.
Would you like for them to be added to Table 1?
LSP
TC
TTL
d) Throughout the document, the expanded form of the following terms are often
used although the abbreviations are introduced in Section 1. Would you like to
use the abbreviations after the introduction in Section 1? Or do you prefer the
current?
network action sub-stack
post-stack data
ancillary data
Entropy Label
-->
<!-- [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.
--> -->
</rfc> </rfc>
 End of changes. 163 change blocks. 
864 lines changed or deleted 1089 lines changed or added

This html diff was produced by rfcdiff 1.48.