<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-mpls-mna-requirements-16" number="9613" updates="" obsoletes="" category="info" submissionType="IETF" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2024-08-26T21:55:29" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-requirements-16" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9613" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="MNA Requirements">Requirements for Solutions that Support MPLS Network Actions (MNAs)</title>
    <seriesInfo name="RFC" value="9613" stream="IETF"/>
    <author initials="M." surname="Bocci" fullname="Matthew Bocci" role="editor">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <email>matthew.bocci@nokia.com</email>
      </address>
    </author>
    <author initials="S." surname="Bryant" fullname="Stewart Bryant">
      <organization showOnFrontPage="true">University of Surrey ICS</organization>
      <address>
        <email>sb@stewartbryant.com</email>
      </address>
    </author>
    <author initials="J." surname="Drake" fullname="John Drake">
      <organization showOnFrontPage="true">Independent</organization>
      <address>
        <email>je_drake@yahoo.com</email>
      </address>
    </author>
    <date month="08" year="2024"/>
    <area>RTG</area>
    <workgroup>mpls</workgroup>
    <keyword>Network Action</keyword>
    <keyword>NA</keyword>
    <keyword>Network Action indicator</keyword>
    <keyword>NAI</keyword>
    <keyword>Ancillary Data</keyword>
    <keyword>AD</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document specifies requirements for the development of MPLS Network Actions (MNAs) that affect the forwarding 
or other processing of MPLS packets. These requirements are informed by a number of 
proposals for additions to the MPLS information in the labeled packet 
 to allow such actions to be performed, either by a transit or terminating Label Switching Router 
 (i.e., the Label Edge Router - LER).</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9613" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mpls-network-action-require">MPLS Network Action Requirements</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-requirements">General Requirements</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-on-the-mna-ale">Requirements on the MNA Alert Mechanism</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-on-network-act">Requirements on Network Actions</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-on-network-acti">Requirements on Network Action Indicators</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-on-ancillary-d">Requirements on Ancillary Data</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">There is significant interest in developing the MPLS data plane to
address the requirements of new use cases <xref target="I-D.ietf-mpls-mna-usecases" format="default" sectionFormat="of" derivedContent="MNA-USECASES"/>. This requires a 
general mechanism, termed MPLS Network Actions (MNAs), to allow the network to make a forwarding or 
processing decision based on information other than the top label and Traffic Class (TC) bits, and to 
also make use of the Network Action Indicator (NAI) and ancillary data (MNA information).
These use cases require the definition of extensions to the MPLS architecture and label-stack operations that can be used across these use cases in order to minimize implementation
complexity and promote interoperability and extensibility. These protocol extensions need 
to conform to the existing MPLS architecture as specified by <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/>, <xref target="RFC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/>, and <xref target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/>.</t>
      <t indent="0" pn="section-1-2">Note that the MPLS architecture specified in <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/> describes a mechanism for forwarding 
MPLS packets through a network without requiring any analysis of the MPLS packet payload's 
network layer header by intermediate nodes (Label Switching Routers - LSRs).  Formally,
inspection may only occur at network ingress (the Label Edge Router - LER) where the MPLS 
packet is assigned to a Forwarding Equivalence Class (FEC).</t>
      <t indent="0" pn="section-1-3">This document specifies the requirements for solutions that encode MNAs 
and ancillary data that may be needed to process those actions. 
   These requirements are informed by a
   number of proposals to allow additions to the MPLS information in the
   labeled packet so that such actions can be performed, either by a
   transit or terminating LSR. It is 
anticipated that these will result in two types of solution specifications:</t>
      <dl spacing="normal" indent="3" newline="false" pn="section-1-4">
        <dt pn="section-1-4.1">MNA solution specification:</dt>
        <dd pn="section-1-4.2">A specification that describes a common protocol that supports all forms of MNAs.</dd>
        <dt pn="section-1-4.3">Network Action solution specifications:</dt>
        <dd pn="section-1-4.4"> One or more specifications describing the protocol extensions for the MNA solution to address a use case.</dd>
      </dl>
      <t indent="0" pn="section-1-5">The term 'solutions', in isolation, refers to both MNA and Network Action solutions.
The requirements constrain the MNA solution design to enable interoperability between implementations.</t>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <dl spacing="normal" indent="3" newline="false" pn="section-1.1-1">
          <dt pn="section-1.1-1.1">Network Action (NA):</dt>
          <dd pn="section-1.1-1.2"> An operation to be performed on an MPLS packet or as a consequence of an MPLS packet
being processed by a router.  An NA may 
affect router state or MPLS packet forwarding, or it may affect the MPLS packet in some other way.</dd>
          <dt pn="section-1.1-1.3">Network Action Indicator (NAI):</dt>
          <dd pn="section-1.1-1.4">An indication in the MPLS packet that a certain NA
is to be performed.</dd>
          <dt pn="section-1.1-1.5">Ancillary Data (AD):</dt>
          <dd pn="section-1.1-1.6">
            <t indent="0" pn="section-1.1-1.6.1">
Data in an MPLS packet associated with a
      given NA that may be used as input to process
      the NA or may result from processing the
      NA. Ancillary data may be associated with:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.1-1.6.2">
              <li pn="section-1.1-1.6.2.1">
                <t indent="0" pn="section-1.1-1.6.2.1.1">Both the control or maintenance information and the data traffic carried by the Label Switched Path (LSP).</t>
              </li>
              <li pn="section-1.1-1.6.2.2">
                <t indent="0" pn="section-1.1-1.6.2.2.1">Only the control or maintenance information.</t>
              </li>
              <li pn="section-1.1-1.6.2.3">
                <t indent="0" pn="section-1.1-1.6.2.3.1">Only the data traffic carried by the LSP.</t>
              </li>
            </ul>
          </dd>
          <dt pn="section-1.1-1.7">In-Stack Data:</dt>
          <dd pn="section-1.1-1.8">Ancillary data carried within the MPLS label stack.</dd>
          <dt pn="section-1.1-1.9">Post-Stack Data:</dt>
          <dd pn="section-1.1-1.10">Ancillary data carried in an MPLS packet between the bottom of the MPLS label 
stack and the first octet of the user payload.  This document does not prescribe whether 
post-stack data precedes or follows any other post-stack header such as a Control Word or 
Associated Channel Header (ACH).</dd>
          <dt pn="section-1.1-1.11">Scope:</dt>
          <dd pn="section-1.1-1.12"> The set of nodes that should perform a given action.</dd>
        </dl>
      </section>
    </section>
    <section anchor="requirements-language" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
      </t>
      <t indent="0" pn="section-2-2">Although this document is not a protocol specification, this convention is adopted 
for clarity of description of requirements.</t>
    </section>
    <section anchor="mpls-network-action-requirements" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-mpls-network-action-require">MPLS Network Action Requirements</name>
      <t indent="0" pn="section-3-1">This document specifies requirements on MNAs and the technology to support
them in MPLS, such as NAIs, the associated AD, and the alert mechanism 
to indicate to an LSR that NAIs are present in an MPLS packet.</t>
      <t indent="0" pn="section-3-2">The requirements are for the behavior of the protocol mechanisms and procedures that constitute building blocks
out of which indicators for a NA and associated ancillary data are constructed.
It does not specify the detailed actions and processing of any NAs or ancillary
data by an LSR or LER.</t>
      <t indent="0" pn="section-3-3">The size of the ancillary data carried post-stack end to end in an MPLS packet is a matter for 
agreement between the ingress and egress provider edges (PEs), and is not part of these requirements.
Since in-stack ancillary data and per-hop post-stack data need to be parsed and processed 
by transit LSRs along the Label Switched Path (LSP), requirements on the size of such ancillary data are documented in the following sections.</t>
      <section anchor="general-requirements" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-general-requirements">General Requirements</name>
        <ol spacing="normal" type="1" start="1" indent="adaptive" pn="section-3.1-1"><li pn="section-3.1-1.1" derivedCounter="1.">
            <t indent="0" pn="section-3.1-1.1.1">Any solutions <bcp14>MUST</bcp14> maintain the properties of extensibility,
        flexibility, and efficiency inherent in the split between the
        control plane context and simple data plane used in MPLS and the specification
        <bcp14>SHOULD</bcp14> describe how this is achieved.</t>
          </li>
          <li pn="section-3.1-1.2" derivedCounter="2.">
            <t indent="0" pn="section-3.1-1.2.1">Any solutions to these requirements <bcp14>MUST</bcp14> be based on and <bcp14>MUST NOT</bcp14> restrict the
generality of the MPLS architecture <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/> <xref target="RFC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/> <xref target="RFC5331" format="default" sectionFormat="of" derivedContent="RFC5331"/>.</t>
          </li>
          <li pn="section-3.1-1.3" derivedCounter="3.">
            <t indent="0" pn="section-3.1-1.3.1">If extensions to the MPLS data plane are required, they <bcp14>MUST</bcp14>
         be consistent with the MPLS architecture <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/> <xref target="RFC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/> <xref target="RFC5331" format="default" sectionFormat="of" derivedContent="RFC5331"/>.</t>
          </li>
          <li pn="section-3.1-1.4" derivedCounter="4.">
            <t indent="0" pn="section-3.1-1.4.1">Solutions meeting the requirements set out in this document <bcp14>MUST</bcp14> be able to coexist 
with existing MPLS mechanisms.</t>
          </li>
          <li pn="section-3.1-1.5" derivedCounter="5.">
            <t indent="0" pn="section-3.1-1.5.1">Subject to the constraints in these requirements, a Network Action solution <bcp14>MAY</bcp14> carry MNA
information in-stack, post-stack, or both in-stack and post-stack.</t>
          </li>
          <li pn="section-3.1-1.6" derivedCounter="6.">
            <t indent="0" pn="section-3.1-1.6.1">Solution specifications <bcp14>MUST NOT</bcp14> require an implementation to support in-stack
        ancillary data, unless the implementation chooses to support an
        NA that uses in-stack ancillary data.</t>
          </li>
          <li pn="section-3.1-1.7" derivedCounter="7.">
            <t indent="0" pn="section-3.1-1.7.1">Solution specifications <bcp14>MUST NOT</bcp14> require an implementation to support post-stack ancillary data, unless the implementation chooses to
        support an NA that uses post-stack ancillary data.</t>
          </li>
          <li pn="section-3.1-1.8" derivedCounter="8.">
            <t indent="0" pn="section-3.1-1.8.1">The design of any MNA solution <bcp14>MUST</bcp14> minimize the amount of processing required to parse 
the label stack at an LSR.</t>
          </li>
          <li pn="section-3.1-1.9" derivedCounter="9.">
            <t indent="0" pn="section-3.1-1.9.1">Solutions <bcp14>MUST</bcp14> minimize any additions to the size of the MPLS label stack.</t>
          </li>
          <li pn="section-3.1-1.10" derivedCounter="10.">
            <t indent="0" pn="section-3.1-1.10.1">Solution specifications that increase the size of the MPLS label stack in a
        way that is not controlled by the ingress LER <bcp14>MUST</bcp14> discuss the
        consequences.</t>
          </li>
          <li pn="section-3.1-1.11" derivedCounter="11.">
            <t indent="0" pn="section-3.1-1.11.1">Solution specifications <bcp14>MUST</bcp14> discuss the ECMP consequences of the design.</t>
          </li>
          <li pn="section-3.1-1.12" derivedCounter="12.">
            <t indent="0" pn="section-3.1-1.12.1">A Network Action solution <bcp14>MUST NOT</bcp14> expose information to the LSRs that is not already exposed to the LER.</t>
          </li>
          <li pn="section-3.1-1.13" derivedCounter="13.">
            <t indent="0" pn="section-3.1-1.13.1">The design of any NA <bcp14>MUST NOT</bcp14> expose any information that a user of any service using the LSP considers 
confidential <xref target="RFC6973" format="default" sectionFormat="of" derivedContent="RFC6973"/> <xref target="RFC3552" format="default" sectionFormat="of" derivedContent="RFC3552"/>.</t>
          </li>
          <li pn="section-3.1-1.14" derivedCounter="14.">
            <t indent="0" pn="section-3.1-1.14.1">Solution specifications <bcp14>MUST</bcp14> document any new security considerations that they 
introduce.</t>
          </li>
          <li pn="section-3.1-1.15" derivedCounter="15.">
            <t indent="0" pn="section-3.1-1.15.1">An MNA solution <bcp14>MUST</bcp14> allow MPLS packets carrying NAI and ancillary data (where it exists) to coexist 
with MPLS packets that do not carry this information on the same LSP.</t>
          </li>
        </ol>
      </section>
      <section anchor="requirements-on-the-mna-alert-mechanism" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-requirements-on-the-mna-ale">Requirements on the MNA Alert Mechanism</name>
        <ol spacing="normal" type="1" start="16" indent="adaptive" pn="section-3.2-1"><li pn="section-3.2-1.1" derivedCounter="16.">
            <t indent="0" pn="section-3.2-1.1.1">An MNA solution specification <bcp14>MUST</bcp14> define how a node determines whether NAIs
       are present in the MPLS packet.</t>
          </li>
          <li pn="section-3.2-1.2" derivedCounter="17.">
            <t indent="0" pn="section-3.2-1.2.1">Special Purpose Labels (SPLs) are a mechanism of last resort;
       therefore, an MNA solution specification that defines their use <bcp14>MUST</bcp14> minimize the
       number of new SPLs that are allocated.</t>
          </li>
        </ol>
      </section>
      <section anchor="requirements-on-network-actions" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-requirements-on-network-act">Requirements on Network Actions</name>
        <ol spacing="normal" type="1" start="18" indent="adaptive" pn="section-3.3-1"><li pn="section-3.3-1.1" derivedCounter="18.">
            <t indent="0" pn="section-3.3-1.1.1">It is <bcp14>RECOMMENDED</bcp14> that an MNA solution include support for NAs for Private
       Use (see <xref target="RFC8126" sectionFormat="of" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.1" derivedContent="RFC8126"/>).</t>
          </li>
          <li pn="section-3.3-1.2" derivedCounter="19.">
            <t indent="0" pn="section-3.3-1.2.1">Network Action solution specifications <bcp14>MUST</bcp14> define if the NA needs to be
       processed as a part of the immediate forwarding operation and
       whether MPLS packet misordering is allowed to occur as a result
       of the time taken to process the NA.</t>
          </li>
          <li pn="section-3.3-1.3" derivedCounter="20.">
            <t indent="0" pn="section-3.3-1.3.1">If a Network Action solution specification allows more than one scope for an
       NA, it <bcp14>MUST</bcp14> define a mechanism to indicate the precedence of the
       scopes or any combination of the scopes.</t>
          </li>
          <li pn="section-3.3-1.4" derivedCounter="21.">
            <t indent="0" pn="section-3.3-1.4.1">If a network action requires an NAI with in-stack ancillary data that needs to be imposed at an LSR
 on an LSP, then the Network Action solution <bcp14>MUST</bcp14> specify how this is achieved in all circumstances.</t>
          </li>
          <li pn="section-3.3-1.5" derivedCounter="22.">
            <t indent="0" pn="section-3.3-1.5.1">If a network action requires an NAI with post-stack ancillary
       data to be imposed at an LSR on an LSP, then the Network Action
       solution specification <bcp14>MUST</bcp14> describe how this is achieved in all circumstances.</t>
          </li>
        </ol>
      </section>
      <section anchor="requirements-on-network-action-indicators" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-requirements-on-network-acti">Requirements on Network Action Indicators</name>
        <ol spacing="normal" type="1" start="23" indent="adaptive" pn="section-3.4-1"><li pn="section-3.4-1.1" derivedCounter="23.">
            <t indent="0" pn="section-3.4-1.1.1">Insertion, parsing, processing, and disposition of NAIs <bcp14>SHOULD</bcp14> make use of existing MPLS 
data plane operations.</t>
          </li>
          <li pn="section-3.4-1.2" derivedCounter="24.">
            <t indent="0" pn="section-3.4-1.2.1">Without constraining the mechanism, an MNA solution <bcp14>MUST</bcp14> enable a node inserting or modifying NAIs
 to determine if the target of the NAI, or any other LSR that may expose the NAI, can accept 
 and process an MPLS packet containing the NAI.</t>
          </li>
          <li pn="section-3.4-1.3" derivedCounter="25.">
            <t indent="0" pn="section-3.4-1.3.1">An NAI <bcp14>MUST NOT</bcp14> be imposed for delivery to a node unless it is known that the node 
supports processing the NAI.</t>
          </li>
          <li pn="section-3.4-1.4" derivedCounter="26.">
            <t indent="0" pn="section-3.4-1.4.1">The NAI design <bcp14>MUST</bcp14> support setting the scope of network actions.</t>
          </li>
          <li pn="section-3.4-1.5" derivedCounter="27.">
            <t indent="0" pn="section-3.4-1.5.1">A given Network Action solution specification <bcp14>MUST</bcp14> define which scope or
        scopes are applicable to the associated NAI.</t>
          </li>
          <li pn="section-3.4-1.6" derivedCounter="28.">
            <t indent="0" pn="section-3.4-1.6.1">An MNA solution specification <bcp14>SHOULD</bcp14> define the support of NAIs for both Point-to-Point
        (P2P) and Point-to-Multipoint (P2MP) paths, but the Network
        Action solution specification <bcp14>MAY</bcp14> limit a specific NAI to only one of these
        path types if there is a clear reason to do so.</t>
          </li>
          <li pn="section-3.4-1.7" derivedCounter="29.">
            <t indent="0" pn="section-3.4-1.7.1">An MNA solution specification defining data plane mechanisms for NAIs <bcp14>MUST</bcp14> be
        consistent across different control plane protocols.</t>
          </li>
          <li pn="section-3.4-1.8" derivedCounter="30.">
            <t indent="0" pn="section-3.4-1.8.1">An MNA solution <bcp14>MUST</bcp14> allow the deployed MPLS control and management planes to determine the ability of downstream LSRs 
to accept and/or process a given NAI.</t>
          </li>
          <li pn="section-3.4-1.9" derivedCounter="31.">
            <t indent="0" pn="section-3.4-1.9.1">An MNA solution <bcp14>MUST</bcp14> allow indicators for multiple network actions in the same MPLS
packet.</t>
          </li>
          <li pn="section-3.4-1.10" derivedCounter="32.">
            <t indent="0" pn="section-3.4-1.10.1">An MNA solution specification <bcp14>MUST NOT</bcp14> require an implementation to process
        all NAIs present in an MPLS packet.</t>
          </li>
          <li pn="section-3.4-1.11" derivedCounter="33.">
            <t indent="0" pn="section-3.4-1.11.1">NAIs <bcp14>MUST</bcp14> only be inserted at LSRs that push a label onto the stack, but they can be processed by 
LSRs along the path of the LSP. Two examples of LSRs that push a label onto the stack are head-end LSRs 
and points of local repair (PLRs).</t>
          </li>
          <li pn="section-3.4-1.12" derivedCounter="34.">
            <t indent="0" pn="section-3.4-1.12.1">If a network action requires in-stack ancillary data, the NAI that indicates this network action <bcp14>MUST</bcp14> be 
present in the label stack.</t>
          </li>
          <li pn="section-3.4-1.13" derivedCounter="35.">
            <t indent="0" pn="section-3.4-1.13.1">All NAIs <bcp14>MUST</bcp14> be encoded in a manner consistent with <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/>.</t>
          </li>
          <li pn="section-3.4-1.14" derivedCounter="36.">
            <t indent="0" pn="section-3.4-1.14.1">If there is post-stack ancillary data for an NAI that is present in the label stack, 
 it <bcp14>MUST</bcp14> be possible to infer the presence of the ancillary data without having to parse below the bottom of the label stack.</t>
          </li>
          <li pn="section-3.4-1.15" derivedCounter="37.">
            <t indent="0" pn="section-3.4-1.15.1">Any processing that removes an NAI from the label stack <bcp14>MUST</bcp14> also remove all associated 
ancillary data from the MPLS packet unless the ancillary data is required by any remaining NAIs.</t>
          </li>
          <li pn="section-3.4-1.16" derivedCounter="38.">
            <t indent="0" pn="section-3.4-1.16.1">MNA solution specifications <bcp14>MUST</bcp14> request that IANA create registries and make
        allocations from those registries for NAIs as necessary to
        ensure unambiguous identification of standardized network
        actions.  An MNA solution specification <bcp14>MAY</bcp14> request that IANA reserve a range
        of a registry for Private Use.
            </t>
          </li>
          <li pn="section-3.4-1.17" derivedCounter="39.">
            <t indent="0" pn="section-3.4-1.17.1">A Network Action solution specification <bcp14>MUST</bcp14> state where the NAIs are to be
        placed in the MPLS packet, that is whether they are placed in-stack or post-stack.</t>
          </li>
        </ol>
      </section>
      <section anchor="requirements-on-ancillary-data" numbered="true" removeInRFC="false" toc="include" pn="section-3.5">
        <name slugifiedName="name-requirements-on-ancillary-d">Requirements on Ancillary Data</name>
        <ol spacing="normal" type="1" start="40" indent="adaptive" pn="section-3.5-1"><li pn="section-3.5-1.1" derivedCounter="40.">
            <t indent="0" pn="section-3.5-1.1.1">Network Action solution specifications <bcp14>MUST</bcp14> state whether ancillary data is
        required to fulfill the action and whether it is in-stack and/or
        post-stack.</t>
          </li>
          <li pn="section-3.5-1.2" derivedCounter="41.">
            <t indent="0" pn="section-3.5-1.2.1">Network Action solution specifications <bcp14>MUST</bcp14> state if in-stack or post-stack
        ancillary data that is already present in the MPLS packet <bcp14>MAY</bcp14> be
        rewritten by an LSR.</t>
          </li>
          <li pn="section-3.5-1.3" derivedCounter="42.">
            <t indent="0" pn="section-3.5-1.3.1">Solutions for in-stack ancillary data <bcp14>MUST</bcp14> be able to coexist with and 
<bcp14>MUST NOT</bcp14> obsolete existing MPLS mechanisms. Such solutions <bcp14>MUST</bcp14> be described in a Standards 
Track RFC.</t>
          </li>
          <li pn="section-3.5-1.4" derivedCounter="43.">
            <t indent="0" pn="section-3.5-1.4.1">Network Action solutions <bcp14>MUST</bcp14> take care to limit the quantity of in-stack ancillary data to the minimum amount required.</t>
          </li>
          <li pn="section-3.5-1.5" derivedCounter="44.">
            <t indent="0" pn="section-3.5-1.5.1">A Network Action solution <bcp14>SHOULD NOT</bcp14> use post-stack ancillary data unless the size of that ancillary data 
        could prevent the coexistence of the
        network action with other in-use MPLS network functions if it
        were inserted into the label stack.
            </t>
          </li>
          <li pn="section-3.5-1.6" derivedCounter="45.">
            <t indent="0" pn="section-3.5-1.6.1">The structure of the NAI and any associated ancillary data <bcp14>MUST</bcp14> enable skipping of 
unknown NAIs and any associated AD.</t>
          </li>
          <li pn="section-3.5-1.7" derivedCounter="46.">
            <t indent="0" pn="section-3.5-1.7.1">Any MNA solution specification <bcp14>MUST</bcp14> describe whether the solution can coexist with
        existing post-stack data mechanisms (e.g., control words and the
        Generic Associated Channel Header <xref target="RFC5586" format="default" sectionFormat="of" derivedContent="RFC5586"/>), and if so how coexistence
        operates.</t>
          </li>
          <li pn="section-3.5-1.8" derivedCounter="47.">
            <t indent="0" pn="section-3.5-1.8.1">An MNA solution <bcp14>MUST</bcp14> allow an LER that inserts ancillary data to determine 
whether each node that needs to process the ancillary data can read the required distance into the
MPLS packet at that node (compare with the mechanism in <xref target="RFC9088" format="default" sectionFormat="of" derivedContent="RFC9088"/>).</t>
          </li>
          <li pn="section-3.5-1.9" derivedCounter="48.">
            <t indent="0" pn="section-3.5-1.9.1">For scoped in-stack or post-stack ancillary data, any MNA solution <bcp14>MUST</bcp14> allow an LER inserting NAIs whose 
network actions make use of that ancillary data to determine if the NAI and ancillary data 
will be processed by LSRs within the scope along the path. 
Such a solution may need to determine if LSRs along the path can process a specific type 
of AD implied by the NAI at the depth in the stack that it will be presented to the LSR.</t>
          </li>
          <li pn="section-3.5-1.10" derivedCounter="49.">
            <t indent="0" pn="section-3.5-1.10.1">A mechanism <bcp14>MUST</bcp14> exist to notify an egress LER of the presence of ancillary data so
that it can dispose of it appropriately.</t>
          </li>
          <li pn="section-3.5-1.11" derivedCounter="50.">
            <t indent="0" pn="section-3.5-1.11.1">In-stack ancillary data <bcp14>MUST</bcp14> only be inserted in conjunction with an operation conforming
with <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/>.</t>
          </li>
          <li pn="section-3.5-1.12" derivedCounter="51.">
            <t indent="0" pn="section-3.5-1.12.1">Post-stack ancillary data <bcp14>MUST</bcp14> only be inserted in conjunction with an operation conforming
with <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/>.</t>
          </li>
          <li pn="section-3.5-1.13" derivedCounter="52.">
            <t indent="0" pn="section-3.5-1.13.1">Processing of ancillary data below a swapped label <bcp14>MAY</bcp14> include rewriting the ancillary data.</t>
          </li>
          <li pn="section-3.5-1.14" derivedCounter="53.">
            <t indent="0" pn="section-3.5-1.14.1">If a Network Action solution needs to change the size of the
        ancillary data, its specification <bcp14>MUST</bcp14> analyze the implications on MPLS packet
        forwarding and specify how these are addressed.</t>
          </li>
          <li pn="section-3.5-1.15" derivedCounter="54.">
            <t indent="0" pn="section-3.5-1.15.1">Not more than one Standards Track solution specification <bcp14>SHOULD</bcp14> be defined for
        encoding in-stack ancillary data.</t>
          </li>
          <li pn="section-3.5-1.16" derivedCounter="55.">
            <t indent="0" pn="section-3.5-1.16.1">Not more than one Standards Track solution specification <bcp14>SHOULD</bcp14> be defined for
        encoding post-stack ancillary data.</t>
          </li>
        </ol>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">This document has no IANA actions.</t>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">Solutions designed according to the requirements in this document may introduce new security
considerations to MPLS, whose forwarding plane on its own does not provide any built-in
security mechanisms <xref target="RFC5920" format="default" sectionFormat="of" derivedContent="RFC5920"/>.</t>
      <t indent="0" pn="section-5-2">In particular, such solutions may embed information derived from the MPLS payload 
in the MPLS headers. This may expose data that a user of the MPLS-based service might otherwise 
assume is opaque to the MPLS network. Furthermore, an LSR may insert information
into the labeled packet such that the forwarding behavior is no longer purely a function of the top label 
or another label with forwarding context. Instead, the forwarding behavior may be the result of a more complex heuristic.
This creates an implicit trust relationship between the LSR whose forwarding behavior is being changed
and the upstream LSR inserting the data causing that change.</t>
      <t indent="0" pn="section-5-3">Several requirements above address some of these considerations. The MNA framework <xref target="I-D.ietf-mpls-mna-fwk" format="default" sectionFormat="of" derivedContent="MNA-FRAMEWORK"/> 
also provides security considerations resulting from any extensions to the MPLS architecture, and these <bcp14>SHOULD</bcp14> be taken
together with the security considerations herein.</t>
      <t indent="0" pn="section-5-4">Individual solution specifications meeting the requirements in this document <bcp14>MUST</bcp14> address any 
security considerations introduced by the MNA design.</t>
    </section>
    <section anchor="acknowledgements" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-6-1">The authors gratefully acknowledge the contributions from <contact fullname="Joel Halpern"/>, <contact fullname="Greg Mirsky"/>, <contact fullname="Yingzhen Qu"/>, <contact fullname="Haoyu Song"/>, 
<contact fullname="Tarek Saad"/>, <contact fullname="Loa Andersson"/>, <contact fullname="Tony Li"/>, <contact fullname="Adrian Farrel"/>, <contact fullname="Jie Dong"/>, <contact fullname="Bruno Decraene"/>, and participants in the
MPLS Working Group who have provided comments.</t>
      <t indent="0" pn="section-6-2">The authors also gratefully acknowledge the input of the members of the
MPLS Open Design Team.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-mpls-mna-usecases" to="MNA-USECASES"/>
    <displayreference target="I-D.ietf-mpls-mna-fwk" to="MNA-FRAMEWORK"/>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3031" quoteTitle="true" derivedAnchor="RFC3031">
          <front>
            <title>Multiprotocol Label Switching Architecture</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="A. Viswanathan" initials="A." surname="Viswanathan"/>
            <author fullname="R. Callon" initials="R." surname="Callon"/>
            <date month="January" year="2001"/>
            <abstract>
              <t indent="0">This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3031"/>
          <seriesInfo name="DOI" value="10.17487/RFC3031"/>
        </reference>
        <reference anchor="RFC3032" target="https://www.rfc-editor.org/info/rfc3032" quoteTitle="true" derivedAnchor="RFC3032">
          <front>
            <title>MPLS Label Stack Encoding</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="D. Tappan" initials="D." surname="Tappan"/>
            <author fullname="G. Fedorkow" initials="G." surname="Fedorkow"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <date month="January" year="2001"/>
            <abstract>
              <t indent="0">This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3032"/>
          <seriesInfo name="DOI" value="10.17487/RFC3032"/>
        </reference>
        <reference anchor="RFC5331" target="https://www.rfc-editor.org/info/rfc5331" quoteTitle="true" derivedAnchor="RFC5331">
          <front>
            <title>MPLS Upstream Label Assignment and Context-Specific Label Space</title>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <date month="August" year="2008"/>
            <abstract>
              <t indent="0">RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5331"/>
          <seriesInfo name="DOI" value="10.17487/RFC5331"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-mpls-mna-fwk" target="https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-fwk-10" quoteTitle="true" derivedAnchor="MNA-FRAMEWORK">
          <front>
            <title>MPLS Network Actions (MNA) Framework</title>
            <author initials="L." surname="Andersson" fullname="Loa Andersson">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="S." surname="Bryant" fullname="Stewart Bryant">
              <organization showOnFrontPage="true">University of Surrey 5GIC</organization>
            </author>
            <author initials="M." surname="Bocci" fullname="Matthew Bocci">
              <organization showOnFrontPage="true">Nokia</organization>
            </author>
            <author initials="T." surname="Li" fullname="Tony Li">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <date month="August" day="6" year="2024"/>
            <abstract>
              <t indent="0">   This document specifies an architectural framework for the MPLS
   Network Actions (MNA) technologies.  MNA technologies are used to
   indicate actions that impact the forwarding or other processing (such
   as monitoring) of the packet along the Label Switched Path (LSP) of
   the packet and to transfer any additional data needed for these
   actions.

   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.  Some of these
   actions are defined in existing MPLS specifications, while others
   require extensions to existing specifications to meet the
   requirements found in "Requirements for Solutions that Support MPLS
   Network Actions (MNA)".

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-fwk-10"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-mpls-mna-usecases" target="https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-usecases-10" quoteTitle="true" derivedAnchor="MNA-USECASES">
          <front>
            <title>Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data</title>
            <author initials="T." surname="Saad" fullname="Tarek Saad">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author initials="K." surname="Makhijani" fullname="Kiran Makhijani">
              <organization showOnFrontPage="true">Independent</organization>
            </author>
            <author initials="H." surname="Song" fullname="Haoyu Song">
              <organization showOnFrontPage="true">Futurewei Technologies</organization>
            </author>
            <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
              <organization showOnFrontPage="true">Ericsson</organization>
            </author>
            <date month="June" day="20" year="2024"/>
            <abstract>
              <t indent="0">   This document presents use cases that have a common feature in that
   they may be addressed by encoding network action indicators and
   associated ancillary data within MPLS packets.  There are interest in
   extending the MPLS data plane to carry such indicators and ancillary
   data to address the use cases that are described in this document.

   The use cases described in this document are not an exhaustive set,
   but rather the ones that are actively discussed by members of the
   IETF MPLS, PALS, and DetNet working groups.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-usecases-10"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552" quoteTitle="true" derivedAnchor="RFC3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="B. Korver" initials="B." surname="Korver"/>
            <date month="July" year="2003"/>
            <abstract>
              <t indent="0">All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
        <reference anchor="RFC5586" target="https://www.rfc-editor.org/info/rfc5586" quoteTitle="true" derivedAnchor="RFC5586">
          <front>
            <title>MPLS Generic Associated Channel</title>
            <author fullname="M. Bocci" initials="M." role="editor" surname="Bocci"/>
            <author fullname="M. Vigoureux" initials="M." role="editor" surname="Vigoureux"/>
            <author fullname="S. Bryant" initials="S." role="editor" surname="Bryant"/>
            <date month="June" year="2009"/>
            <abstract>
              <t indent="0">This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5586"/>
          <seriesInfo name="DOI" value="10.17487/RFC5586"/>
        </reference>
        <reference anchor="RFC5920" target="https://www.rfc-editor.org/info/rfc5920" quoteTitle="true" derivedAnchor="RFC5920">
          <front>
            <title>Security Framework for MPLS and GMPLS Networks</title>
            <author fullname="L. Fang" initials="L." role="editor" surname="Fang"/>
            <date month="July" year="2010"/>
            <abstract>
              <t indent="0">This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5920"/>
          <seriesInfo name="DOI" value="10.17487/RFC5920"/>
        </reference>
        <reference anchor="RFC6790" target="https://www.rfc-editor.org/info/rfc6790" quoteTitle="true" derivedAnchor="RFC6790">
          <front>
            <title>The Use of Entropy Labels in MPLS Forwarding</title>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="S. Amante" initials="S." surname="Amante"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="L. Yong" initials="L." surname="Yong"/>
            <date month="November" year="2012"/>
            <abstract>
              <t indent="0">Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6790"/>
          <seriesInfo name="DOI" value="10.17487/RFC6790"/>
        </reference>
        <reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6973" quoteTitle="true" derivedAnchor="RFC6973">
          <front>
            <title>Privacy Considerations for Internet Protocols</title>
            <author fullname="A. Cooper" initials="A." surname="Cooper"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <author fullname="J. Peterson" initials="J." surname="Peterson"/>
            <author fullname="J. Morris" initials="J." surname="Morris"/>
            <author fullname="M. Hansen" initials="M." surname="Hansen"/>
            <author fullname="R. Smith" initials="R." surname="Smith"/>
            <date month="July" year="2013"/>
            <abstract>
              <t indent="0">This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6973"/>
          <seriesInfo name="DOI" value="10.17487/RFC6973"/>
        </reference>
        <reference anchor="RFC9088" target="https://www.rfc-editor.org/info/rfc9088" quoteTitle="true" derivedAnchor="RFC9088">
          <front>
            <title>Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS</title>
            <author fullname="X. Xu" initials="X." surname="Xu"/>
            <author fullname="S. Kini" initials="S." surname="Kini"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="M. Bocci" initials="M." surname="Bocci"/>
            <date month="August" year="2021"/>
            <abstract>
              <t indent="0">Multiprotocol Label Switching (MPLS) has defined a mechanism to load-balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using IS-IS and Border Gateway Protocol - Link State (BGP-LS).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9088"/>
          <seriesInfo name="DOI" value="10.17487/RFC9088"/>
        </reference>
      </references>
    </references>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="M." surname="Bocci" fullname="Matthew Bocci" role="editor">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <email>matthew.bocci@nokia.com</email>
        </address>
      </author>
      <author initials="S." surname="Bryant" fullname="Stewart Bryant">
        <organization showOnFrontPage="true">University of Surrey ICS</organization>
        <address>
          <email>sb@stewartbryant.com</email>
        </address>
      </author>
      <author initials="J." surname="Drake" fullname="John Drake">
        <organization showOnFrontPage="true">Independent</organization>
        <address>
          <email>je_drake@yahoo.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
