rfc9613.original.xml   rfc9613.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- draft submitted in xml v3 -->
<!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;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.13 (Ruby 3.0. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-mpls-mna-requirements-16" number="9613" updates="" obsoletes="" category="
<?rfc comments="yes"?> info" submissionType="IETF" consensus="true" tocInclude="true" sortRefs="true" s
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ymRefs="true" version="3" xml:lang="en">
-ietf-mpls-mna-requirements-16" category="info" submissionType="IETF" tocInclude
="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.21.0 -->
<front> <front>
<title abbrev="MNA Requirements">Requirements for Solutions that Support MPL <title abbrev="MNA Requirements">Requirements for Solutions that Support MPL
S Network Actions (MNA)</title> S Network Actions (MNAs)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-requirements-16 <seriesInfo name="RFC" value="9613"/>
"/>
<author initials="M." surname="Bocci" fullname="Matthew Bocci" role="editor" > <author initials="M." surname="Bocci" fullname="Matthew Bocci" role="editor" >
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>matthew.bocci@nokia.com</email> <email>matthew.bocci@nokia.com</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 ISC</organization> <organization>University of Surrey ICS</organization>
<address> <address>
<email>sb@stewartbryant.com</email> <email>sb@stewartbryant.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Drake" fullname="John Drake"> <author initials="J." surname="Drake" fullname="John Drake">
<organization>Independent</organization> <organization>Independent</organization>
<address> <address>
<email>je_drake@yahoo.com</email> <email>je_drake@yahoo.com</email>
</address> </address>
</author> </author>
<date year="2024" month="May" day="30"/> <date year="2024" month="August"/>
<workgroup>MPLS Working Group</workgroup> <area>RTG</area>
<abstract> <workgroup>mpls</workgroup>
<?line 53?>
<t>This document specifies requirements for the development of MPLS Network Acti <keyword>Network Action</keyword>
ons (MNA) which affect the forwarding <keyword>NA</keyword>
<keyword>Network Action indicator</keyword>
<keyword>NAI</keyword>
<keyword>Ancillary Data</keyword>
<keyword>AD</keyword>
<abstract>
<t>This document specifies requirements for the development of MPLS Network Acti
ons (MNAs) that affect the forwarding
or other processing of MPLS packets. These requirements are informed by a number of 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 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 to allow such actions to be performed, either by a transit or terminating Label Switching Router
(i.e., the Label Edge Router - LER).</t> (i.e., the Label Edge Router - LER).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 63?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>There is significant interest in developing the MPLS data plane to <t>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-usecas es"/>. This requires a address the requirements of new use cases <xref target="I-D.ietf-mpls-mna-usecas es"/>. This requires a
general mechanism, termed MPLS Network Actions (MNA), to allow the network to ma general mechanism, termed MPLS Network Actions (MNAs), to allow the network to m
ke a forwarding or ake a forwarding or
processing decision based on information other than the top label and Traffic Cl processing decision based on information other than the top label and Traffic Cl
ass (TC) bits, and ass (TC) bits, and to
also make use of the Network Action Indicator and ancillary data (MNA informatio also make use of the Network Action Indicator (NAI) and ancillary data (MNA info
n). rmation).
These use cases require the definition of extensions to the MPLS architecture an These use cases require the definition of extensions to the MPLS architecture an
d label d label-stack operations that can be used across these use cases in order to min
stack operations that can be used across these use cases in order to minimize im imize implementation
plementation
complexity and promote interoperability and extensibility. These protocol extens ions need complexity and promote interoperability and extensibility. These protocol extens ions need
to conform to the existing MPLS architecture as specified by <xref target="RFC30 31"/>, <xref target="RFC3032"/>, and <xref target="RFC6790"/>.</t> to conform to the existing MPLS architecture as specified by <xref target="RFC30 31"/>, <xref target="RFC3032"/>, and <xref target="RFC6790"/>.</t>
<t>Note that the MPLS architecture specified in <xref target="RFC3031"/> d escribes a mechanism for forwarding <t>Note that the MPLS architecture specified in <xref target="RFC3031"/> d escribes a mechanism for forwarding
MPLS packets through a network without requiring any analysis of the MPLS packet payload's 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). Fo rmally, network layer header by intermediate nodes (Label Switching Routers - LSRs). Fo rmally,
inspection may only occur at network ingress (the Label Edge Router - LER) where the MPLS 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> packet is assigned to a Forwarding Equivalence Class (FEC).</t>
<t>This document specifies the requirements for solutions that encode MPLS
Network Actions <t>This document specifies the requirements for solutions that encode MNAs
and ancillary data that may be needed by the processing of those actions. These and ancillary data that may be needed to process those actions.
requirements are informed by a number of These requirements are informed by a
proposals for additions to the MPLS information in the labeled packet number of proposals to allow additions to the MPLS information in the
to allow such actions to be performed, either by a transit or terminating LSR. I labeled packet so that such actions can be performed, either by a
t is transit or terminating LSR. It is
anticipated that these will result in two types of solution specification:</t> anticipated that these will result in two types of solution specifications:</t>
<ol spacing="normal" type="1"><li>
<t>A specification that describes a common protocol that supports all <dl spacing="normal">
forms of MPLS Network Actions. <dt>MNA solution specification:</dt><dd>A specification that describes
This is referred to as the MNA Solution.</t> a common protocol that supports all forms of MNAs.</dd>
</li> <dt>Network Action solution specifications:</dt><dd> One or more speci
<li> fications describing the protocol extensions for the MNA solution to address a u
<t>One or more specifications describing the protocol extensions, and se case.</dd>
utilising (1), for network action(s) </dl>
to realise a use case. These are referred to as Network Action solutions.</t>
</li>
</ol>
<t>The term 'solutions', in isolation, refers to both MNA and Network Acti on solutions. <t>The term 'solutions', in isolation, refers to both MNA and Network Acti on solutions.
The requirements constrain the MNA solution design to enable interoperability be tween implementations.</t> The requirements constrain the MNA solution design to enable interoperability be tween implementations.</t>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<ul spacing="normal">
<li> <dl spacing="normal">
<t>Network Action: An operation to be performed on an MPLS packet or <dt>Network Action (NA):</dt><dd> An operation to be performed on an
as a consequence of an MPLS packet MPLS packet or as a consequence of an MPLS packet
being processed by a router. A network action may being processed by a router. An NA may
affect router state, MPLS packet forwarding, or it may affect the MPLS packet in affect router state or MPLS packet forwarding, or it may affect the MPLS packet
some other way.</t> in some other way.</dd>
</li> <dt>Network Action Indicator (NAI):</dt><dd>An indication in the MPL
<li> S packet that a certain NA
<t>Network Action Indicator (NAI): An indication in the MPLS packet is to be performed.</dd>
that a certain network action
is to be performed.</t> <dt>Ancillary Data (AD):</dt><dd><t>
</li> Data in an MPLS packet associated with a
<li> given NA that may be used as input to process
<t>Ancillary Data (AD): Data in an MPLS packet associated with a giv the NA or may result from processing the
en network action that NA. Ancillary data may be associated with:</t>
may be used as input to the processing of the network action or results from the
processing
of the network action. Ancillary data may be associated with:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Both control or maintenance information and the data traffic carried by the Label Switched Path (LSP).</t> <t>Both the control or maintenance information and the data traf fic carried by the Label Switched Path (LSP).</t>
</li> </li>
<li> <li>
<t>Only the control or maintenance information.</t> <t>Only the control or maintenance information.</t>
</li> </li>
<li> <li>
<t>Only the data traffic carried by the LSP.</t> <t>Only the data traffic carried by the LSP.</t>
</li> </li>
</ul> </ul>
</li> </dd>
<li> <dt>In-Stack Data:</dt><dd>Ancillary data carried within the MPLS la
<t>In-Stack Data: Ancillary data carried within the MPLS label stack bel stack.</dd>
.</t> <dt>Post-Stack Data:</dt><dd>Ancillary data carried in an MPLS packe
</li> t between the bottom of the MPLS label
<li>
<t>Post-Stack Data: 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 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 Contro l Word or post-stack data precedes or follows any other post-stack header such as a Contro l Word or
Associated Channel Header (ACH).</t> Associated Channel Header (ACH).</dd>
</li> <dt>Scope:</dt><dd> The set of nodes that should perform a given act
<li> ion.</dd>
<t>Scope: The set of nodes that should perform a given action.</t> </dl>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="requirements-language"> <section anchor="requirements-language">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appe ",
ar in all "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
capitals, as shown here.</t> "<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&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t>Although this document is not a protocol specification, this convention is adopted <t>Although this document is not a protocol specification, this convention is adopted
for clarity of description of requirements.</t> for clarity of description of requirements.</t>
</section> </section>
<section anchor="mpls-network-action-requirements"> <section anchor="mpls-network-action-requirements">
<name>MPLS Network Action Requirements</name> <name>MPLS Network Action Requirements</name>
<t>This document specifies requirements on MPLS network actions and the te
chnology to support <t>This document specifies requirements on MNAs and the technology to supp
them in MPLS, such as the Network Action Indicators (NAIs), the associated ancil ort
lary data (AD), and the alert mechanism 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> to indicate to an LSR that NAIs are present in an MPLS packet.</t>
<t>The requirements are for the behavior of the protocol mechanisms and pr ocedures that constitute building blocks <t>The requirements are for the behavior of the protocol mechanisms and pr ocedures that constitute building blocks
out of which indicators for network actions and associated ancillary data are co out of which indicators for a NA and associated ancillary data are constructed.
nstructed.<br/> It does not specify the detailed actions and processing of any NAs or ancillary
It does not specify the detailed actions and processing of any network actions o
r ancillary
data by an LSR or LER.</t> data by an LSR or LER.</t>
<t>The size of the ancillary data carried post-stack end-to-end in an MPLS
packet is a matter for <t>The size of the ancillary data carried post-stack end to end in an MPLS
agreement between the ingress and egress PEs, and is not part of these requireme packet is a matter for
nts. agreement between the ingress and egress provider edges (PEs), and is not part o
f these requirements.
Since in-stack ancillary data and per-hop post-stack data need to be parsed and processed Since in-stack ancillary data and per-hop post-stack data need to be parsed and processed
by transit LSRs along the LSP, requirements on the size of such ancillary data a re documented in the following sections.</t> 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"> <section anchor="general-requirements">
<name>General Requirements</name> <name>General Requirements</name>
<ol spacing="normal" type="1" start="1"><li> <ol spacing="normal" type="1" start="1"><li>
<t>Any MNA and Network Action solution MUST maintain the properties <t>Any solutions <bcp14>MUST</bcp14> maintain the properties of exte
of extensibility, nsibility,
flexibility, and efficiency inherent in the split between the control plane cont flexibility, and efficiency inherent in the split between the
ext and simple control plane context and simple data plane used in MPLS and the specifi
data plane used in MPLS, and SHOULD describe how this is achieved.</t> cation
<bcp14>SHOULD</bcp14> describe how this is achieved.</t>
</li> </li>
<li> <li>
<t>Any solutions to these requirements MUST be based on and MUST NOT <t>Any solutions to these requirements <bcp14>MUST</bcp14> be based
restrict the on and <bcp14>MUST NOT</bcp14> restrict the
generality of the MPLS architecture <xref target="RFC3031"/>, <xref target="RFC3 generality of the MPLS architecture <xref target="RFC3031"/> <xref target="RFC30
032"/> and <xref target="RFC5331"/>.</t> 32"/> <xref target="RFC5331"/>.</t>
</li> </li>
<li> <li>
<t>If extensions to the MPLS data plane are required, they MUST NOT <t>If extensions to the MPLS data plane are required, they <bcp14>MU
be inconsistent ST</bcp14>
with the MPLS architecture <xref target="RFC3031"/>, <xref target="RFC3032"/> an be consistent with the MPLS architecture <xref target="RFC3031"/> <xref
d <xref target="RFC5331"/>.</t> target="RFC3032"/> <xref target="RFC5331"/>.</t>
</li> </li>
<li> <li>
<t>Solutions meeting the requirements set out in this document MUST be able to coexist <t>Solutions meeting the requirements set out in this document <bcp1 4>MUST</bcp14> be able to coexist
with existing MPLS mechanisms.</t> with existing MPLS mechanisms.</t>
</li> </li>
<li> <li>
<t>Subject to the constraints in these requirements a Network Action <t>Subject to the constraints in these requirements, a Network Actio
solution MAY carry MNA n solution <bcp14>MAY</bcp14> carry MNA
information in-stack, post-stack or both in-stack and post-stack.</t> information in-stack, post-stack, or both in-stack and post-stack.</t>
</li> </li>
<li> <li>
<t>Solutions MUST NOT require an implementation to support in-stack <t>Solution specifications <bcp14>MUST NOT</bcp14> require an implem
ancillary data, entation to support in-stack
unless the implementation chooses to support a network action that uses in-stack ancillary data, unless the implementation chooses to support an
ancillary data.</t> NA that uses in-stack ancillary data.</t>
</li> </li>
<li> <li>
<t>Solutions MUST NOT require an implementation to support post-stac <t>Solution specifications <bcp14>MUST NOT</bcp14> require an implem
k ancillary data, entation to support post-stack ancillary data, unless the implementation chooses
unless the implementation chooses to support a network action that uses post-sta to
ck ancillary data.</t> support an NA that uses post-stack ancillary data.</t>
</li> </li>
<li> <li>
<t>The design of any MNA solution MUST minimize the amount of proces sing required to parse <t>The design of any MNA solution <bcp14>MUST</bcp14> minimize the a mount of processing required to parse
the label stack at an LSR.</t> the label stack at an LSR.</t>
</li> </li>
<li> <li>
<t>Solutions MUST minimize any additions to the size of the MPLS lab el stack.</t> <t>Solutions <bcp14>MUST</bcp14> minimize any additions to the size of the MPLS label stack.</t>
</li> </li>
<li> <li>
<t>Solutions that increase the size of the MPLS label stack in a way <t>Solution specifications that increase the size of the MPLS label
that is not stack in a
controlled by the ingress LER MUST discuss the consequences.</t> way that is not controlled by the ingress LER <bcp14>MUST</bcp14> discus
s the
consequences.</t>
</li> </li>
<li> <li>
<t>Solution specifications MUST discuss the ECMP consequences of the design.</t> <t>Solution specifications <bcp14>MUST</bcp14> discuss the ECMP cons equences of the design.</t>
</li> </li>
<li> <li>
<t>A network action solution MUST NOT expose information to the LSRs that is not already exposed to the LER.</t> <t>A Network Action solution <bcp14>MUST NOT</bcp14> expose informat ion to the LSRs that is not already exposed to the LER.</t>
</li> </li>
<li> <li>
<t>The design of any network action MUST NOT expose any information that a user of any service using the LSP considers <t>The design of any NA <bcp14>MUST NOT</bcp14> expose any informati on that a user of any service using the LSP considers
confidential <xref target="RFC6973"/> <xref target="RFC3552"/>.</t> confidential <xref target="RFC6973"/> <xref target="RFC3552"/>.</t>
</li> </li>
<li> <li>
<t>Solution specifications MUST document any new security considerat ions that they <t>Solution specifications <bcp14>MUST</bcp14> document any new secu rity considerations that they
introduce.</t> introduce.</t>
</li> </li>
<li> <li>
<t>An MNA solution MUST allow MPLS packets carrying NAI and ancillar y data (where it exists) to coexist <t>An MNA solution <bcp14>MUST</bcp14> allow MPLS packets carrying N AI and ancillary data (where it exists) to coexist
with MPLS packets that do not carry this information on the same LSP.</t> with MPLS packets that do not carry this information on the same LSP.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="requirements-on-the-mna-alert-mechanism"> <section anchor="requirements-on-the-mna-alert-mechanism">
<name>Requirements on the MNA Alert Mechanism</name> <name>Requirements on the MNA Alert Mechanism</name>
<ol spacing="normal" type="1" start="16"><li> <ol spacing="normal" type="1" start="16"><li>
<t>An MNA solution MUST define how a node determines whether NAIs ar <t>An MNA solution specification <bcp14>MUST</bcp14> define how a no
e present in the MPLS packet.</t> de determines whether NAIs
are present in the MPLS packet.</t>
</li> </li>
<li> <li>
<t>Special Purpose Labels (SPLs) are a mechanism of last resort, and <t>Special Purpose Labels (SPLs) are a mechanism of last resort;
therefore an MNA solution therefore, an MNA solution specification that defines their use <bcp14>MU
that uses them MUST minimize the number of new SPLs that are allocated.</t> ST</bcp14> minimize the
number of new SPLs that are allocated.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="requirements-on-network-actions"> <section anchor="requirements-on-network-actions">
<name>Requirements on Network Actions</name> <name>Requirements on Network Actions</name>
<ol spacing="normal" type="1" start="18"><li> <ol spacing="normal" type="1" start="18"><li>
<t>It is RECOMMENDED that an MNA specification support network actio <t>It is <bcp14>RECOMMENDED</bcp14> that an MNA solution include sup
ns for port for NAs for Private
private use (See Section 4.1 of <xref target="RFC8126"/>).</t> Use (see <xref target="RFC8126" sectionFormat="of" section="4.1"/>).</t>
</li> </li>
<li> <li>
<t>Network action specifications MUST specify if the network action <t>Network Action solution specifications <bcp14>MUST</bcp14> define
needs to if the NA needs to be
be processed as a part of the immediate forwarding operation and whether MPLS pa processed as a part of the immediate forwarding operation and
cket whether MPLS packet misordering is allowed to occur as a result
mis-ordering is allowed to occur as a result of the time taken to process the ne of the time taken to process the NA.</t>
twork action.</t>
</li> </li>
<li> <li>
<t>If a network action solution allows more than one scope for a net <t>If a Network Action solution specification allows more than one s
work action, it MUST provide a mechanism to specify the precedence cope for an
of the scopes or any combination of the scopes.</t> NA, it <bcp14>MUST</bcp14> define a mechanism to indicate the precedence
of the
scopes or any combination of the scopes.</t>
</li> </li>
<li> <li>
<t>If a Network Action (NA) requires an NAI with in-stack ancillary <t>If a network action requires an NAI with in-stack ancillary data
data that needs to be imposed at an LSR that needs to be imposed at an LSR
on an LSP, then the network action solution specification MUST specify how this on an LSP, then the Network Action solution <bcp14>MUST</bcp14> specify how thi
is achieved in all circumstances.</t> s is achieved in all circumstances.</t>
</li> </li>
<li> <li>
<t>If a network action requires an NAI with post-stack ancillary dat <t>If a network action requires an NAI with post-stack ancillary
a to be imposed at an LSR data to be imposed at an LSR on an LSP, then the Network Action
on an LSP, then the network action solution specification MUST specify how this solution specification <bcp14>MUST</bcp14> describe how this is achieved
is achieved in all circumstances.</t> in all circumstances.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="requirements-on-network-action-indicators"> <section anchor="requirements-on-network-action-indicators">
<name>Requirements on Network Action Indicators</name> <name>Requirements on Network Action Indicators</name>
<ol spacing="normal" type="1" start="23"><li> <ol spacing="normal" type="1" start="23"><li>
<t>Insertion, parsing, processing and disposition of NAIs SHOULD mak e use of existing MPLS <t>Insertion, parsing, processing, and disposition of NAIs <bcp14>SH OULD</bcp14> make use of existing MPLS
data plane operations.</t> data plane operations.</t>
</li> </li>
<li> <li>
<t>Without constraining the mechanism, an MNA solution MUST enable a node inserting or modifying NAIs <t>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 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> and process an MPLS packet containing the NAI.</t>
</li> </li>
<li> <li>
<t>An NAI MUST NOT be imposed for delivery to a node unless it is kn own that the node <t>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> supports processing the NAI.</t>
</li> </li>
<li> <li>
<t>The NAI design MUST support setting the scope of network actions. </t> <t>The NAI design <bcp14>MUST</bcp14> support setting the scope of n etwork actions.</t>
</li> </li>
<li> <li>
<t>A given network action specification MUST specify which scope or <t>A given Network Action solution specification <bcp14>MUST</bcp14>
scopes are applicable to the associated NAI.</t> define which scope or
scopes are applicable to the associated NAI.</t>
</li> </li>
<li> <li>
<t>An MNA solution SHOULD support NAIs for both Point-to-Point (P2P) <t>An MNA solution specification <bcp14>SHOULD</bcp14> define the su
and Point-to-Multipoint (P2MP) paths, but a specific NAI MAY pport of NAIs for both Point-to-Point
be limited by the network action specification to only one or the other of these (P2P) and Point-to-Multipoint (P2MP) paths, but the Network
path types if there is a clear reason to do so.</t> 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>
<li> <li>
<t>An MNA solution defining data plane mechanisms for NAIs MUST be c <t>An MNA solution specification defining data plane mechanisms for
onsistent across different control NAIs <bcp14>MUST</bcp14> be
plane protocols.</t> consistent across different control plane protocols.</t>
</li> </li>
<li> <li>
<t>An MNA solution MUST allow the deployed MPLS control and manageme nt planes to determine the ability of downstream LSRs <t>An MNA solution <bcp14>MUST</bcp14> allow the deployed MPLS contr ol and management planes to determine the ability of downstream LSRs
to accept and/or process a given NAI.</t> to accept and/or process a given NAI.</t>
</li> </li>
<li> <li>
<t>An MNA solution MUST allow indicators for multiple network action s in the same MPLS<br/> <t>An MNA solution <bcp14>MUST</bcp14> allow indicators for multiple network actions in the same MPLS
packet.</t> packet.</t>
</li> </li>
<li> <li>
<t>An MNA solution MUST NOT require an implementation to process all <t>An MNA solution specification <bcp14>MUST NOT</bcp14> require an
NAIs present in an MPLS packet.</t> implementation to process
all NAIs present in an MPLS packet.</t>
</li> </li>
<li> <li>
<t>NAIs MUST only be inserted at LSRs that push a label onto the sta <t>NAIs <bcp14>MUST</bcp14> only be inserted at LSRs that push a lab
ck, but can be processed by el 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 LSRs along the path of the LSP. Two examples of LSRs that push a label onto the
stack are head end LSRs stack are head-end LSRs
and points of local repair (PLRs).</t> and points of local repair (PLRs).</t>
</li> </li>
<li> <li>
<t>If an NA requires in-stack ancillary data, the NAI that indicates this NA MUST be <t>If a network action requires in-stack ancillary data, the NAI tha t indicates this network action <bcp14>MUST</bcp14> be
present in the label stack.</t> present in the label stack.</t>
</li> </li>
<li> <li>
<t>All NAIs MUST be encoded in a manner consistent with <xref target ="RFC3031"/></t> <t>All NAIs <bcp14>MUST</bcp14> be encoded in a manner consistent wi th <xref target="RFC3031"/>.</t>
</li> </li>
<li> <li>
<t>If there is post-stack ancillary data for an NAI that is present in the label stack, <t>If there is post-stack ancillary data for an NAI that is present in the label stack,
it MUST be possible to infer the presence of the ancillary data without having to parse below the bottom of the label stack.</t> 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>
<li> <li>
<t>Any processing that removes an NAI from the label stack MUST also remove all associated <t>Any processing that removes an NAI from the label stack <bcp14>MU ST</bcp14> also remove all associated
ancillary data from the MPLS packet unless the ancillary data is required by any remaining NAIs.</t> ancillary data from the MPLS packet unless the ancillary data is required by any remaining NAIs.</t>
</li> </li>
<li> <li>
<t>MNA solution specifications MUST request IANA to create registrie <t>MNA solution specifications <bcp14>MUST</bcp14> request that IANA
s and make allocations from those registries for NAIs create registries and make
as necessary to ensure unambiguous identification of standardized NAs. An MNA so allocations from those registries for NAIs as necessary to
lution MAY request IANA to reserve a range ensure unambiguous identification of standardized network
of a registry for private use.</t> actions. An MNA solution specification <bcp14>MAY</bcp14> request that
IANA reserve a range
of a registry for Private Use.
</t>
</li> </li>
<li> <li>
<t>A network action solution specification MUST state where the NAIs <t>A Network Action solution specification <bcp14>MUST</bcp14> state
are to be placed in the MPLS where the NAIs are to be
packet, that is whether they are placed in-stack or post-stack.</t> placed in the MPLS packet, that is whether they are placed in-stack or p
ost-stack.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="requirements-on-ancillary-data"> <section anchor="requirements-on-ancillary-data">
<name>Requirements on Ancillary Data</name> <name>Requirements on Ancillary Data</name>
<ol spacing="normal" type="1" start="40"><li> <ol spacing="normal" type="1" start="40"><li>
<t>Network action specifications MUST specify whether ancillary data <t>Network Action solution specifications <bcp14>MUST</bcp14> state
is whether ancillary data is
required to fulfil the action and whether it is in-stack and/or post-stack.</t> required to fulfill the action and whether it is in-stack and/or
post-stack.</t>
</li> </li>
<li> <li>
<t>Network action specifications MUST specify if in-stack or post-st <t>Network Action solution specifications <bcp14>MUST</bcp14> state
ack ancillary data that is if in-stack or post-stack
already present in the MPLS packet MAY be rewritten by an LSR.</t> ancillary data that is already present in the MPLS packet <bcp14>MAY</bc
p14> be
rewritten by an LSR.</t>
</li> </li>
<li> <li>
<t>Solutions for in-stack ancillary data MUST be able to coexist wit <t>Solutions for in-stack ancillary data <bcp14>MUST</bcp14> be able
h and to coexist with and
MUST NOT obsolete existing MPLS mechanisms. Such solutions MUST be described in <bcp14>MUST NOT</bcp14> obsolete existing MPLS mechanisms. Such solutions <bcp14
a Standards >MUST</bcp14> be described in a Standards
Track RFC.</t> Track RFC.</t>
</li> </li>
<li> <li>
<t>Network action solutions MUST take care to limit the quantity of in-stack ancillary data to the minimum amount required.</t> <t>Network Action solutions <bcp14>MUST</bcp14> take care to limit t he quantity of in-stack ancillary data to the minimum amount required.</t>
</li> </li>
<li> <li>
<t>A network action solution SHOULD NOT use post-stack ancillary dat <t>A Network Action solution <bcp14>SHOULD NOT</bcp14> use post-stac
a unless the size of that ancillary data if it was inserted into k ancillary data unless the size of that ancillary data
the label stack could prevent the coexistence of the network action with other i could prevent the coexistence of the
n-use MPLS network functions.</t> network action with other in-use MPLS network functions if it
were inserted into the label stack.
</t>
</li> </li>
<li> <li>
<t>The structure of the NAI and any associated ancillary data MUST e nable skipping of <t>The structure of the NAI and any associated ancillary data <bcp14 >MUST</bcp14> enable skipping of
unknown NAIs and any associated AD.</t> unknown NAIs and any associated AD.</t>
</li> </li>
<li> <li>
<t>Any MNA solution specification MUST describe whether it can coexi <t>Any MNA solution specification <bcp14>MUST</bcp14> describe wheth
st with existing post-stack data er the solution can coexist with
mechanisms (e.g., control words and the Generic Associated Channel Header), and existing post-stack data mechanisms (e.g., control words and the
if so how this coexistence operates.</t> Generic Associated Channel Header <xref target="RFC5586"/>), and if so h
ow coexistence
operates.</t>
</li> </li>
<li> <li>
<t>An MNA solution MUST allow an LER that inserts ancillary data to determine <t>An MNA solution <bcp14>MUST</bcp14> allow an LER that inserts anc illary data to determine
whether each node that needs to process the ancillary data can read the required distance into the 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"/> ).</t> MPLS packet at that node (compare with the mechanism in <xref target="RFC9088"/> ).</t>
</li> </li>
<li> <li>
<t>For scoped in-stack or post-stack ancillary data, any MNA solutio n MUST allow an LER inserting NAIs whose <t>For scoped in-stack or post-stack ancillary data, any MNA solutio n <bcp14>MUST</bcp14> allow an LER inserting NAIs whose
network actions make use of that ancillary data to determine if the NAI and anci llary data network actions make use of that ancillary data to determine if the NAI and anci llary data
will be processed by LSRs within the scope along the path. 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 speci fic type Such a solution may need to determine if LSRs along the path can process a speci fic type
of AD implied by the NAI at the depth in the stack that it will be presented to the LSR.</t> of AD implied by the NAI at the depth in the stack that it will be presented to the LSR.</t>
</li> </li>
<li> <li>
<t>A mechanism MUST exist to notify an egress LER of the presence of ancillary data so <t>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> that it can dispose of it appropriately.</t>
</li> </li>
<li> <li>
<t>In-stack ancillary data MUST only be inserted in conjunction with <t>In-stack ancillary data <bcp14>MUST</bcp14> only be inserted in c
an operation conforming onjunction with an operation conforming
to <xref target="RFC3031"/>.</t> with <xref target="RFC3031"/>.</t>
</li> </li>
<li> <li>
<t>Post-stack ancillary data MUST only be inserted in conjunction wi <t>Post-stack ancillary data <bcp14>MUST</bcp14> only be inserted in
th an operation conforming conjunction with an operation conforming
to <xref target="RFC3031"/>.</t> with <xref target="RFC3031"/>.</t>
</li> </li>
<li> <li>
<t>Processing of ancillary data below a swapped label MAY include re writing the ancillary data.</t> <t>Processing of ancillary data below a swapped label <bcp14>MAY</bc p14> include rewriting the ancillary data.</t>
</li> </li>
<li> <li>
<t>A network action solution that needs to change the size of the an <t>If a Network Action solution needs to change the size of the
cillary data MUST analyze the ancillary data, its specification <bcp14>MUST</bcp14> analyze the implic
implications on MPLS packet forwarding and specify how these are addressed.</t> ations on MPLS packet
forwarding and specify how these are addressed.</t>
</li> </li>
<li> <li>
<t>Not more than one standards track solution SHOULD be defined for <t>Not more than one Standards Track solution specification <bcp14>S
encoding in-stack ancillary data.</t> HOULD</bcp14> be defined for
encoding in-stack ancillary data.</t>
</li> </li>
<li> <li>
<t>Not more than one standards track solution SHOULD be defined for <t>Not more than one Standards Track solution specification <bcp14>S
encoding post-stack ancillary data.</t> HOULD</bcp14> be defined for
encoding post-stack ancillary data.</t>
</li> </li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no request of IANA.</t> <t>This document has no IANA actions.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Solutions designed according to the requirements in this document may i ntroduce new security <t>Solutions designed according to the requirements in this document may i ntroduce new security
considerations to MPLS, whose forwarding plane on its own does not provide any b uilt-in considerations to MPLS, whose forwarding plane on its own does not provide any b uilt-in
security mechanisms <xref target="RFC5920"/>.</t> security mechanisms <xref target="RFC5920"/>.</t>
<t>In particular, such solutions may embed information derived from the MP LS payload <t>In particular, such solutions may embed information derived from the MP LS payload
in the MPLS headers. This may expose data that a user of the MPLS-based service might otherwise 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 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 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 b e the result of a more complex heuristic. or another label with forwarding context. Instead, the forwarding behavior may b e the result of a more complex heuristic.
This creates an implicit trust relationship between the LSR whose forwarding beh avior is being changed This creates an implicit trust relationship between the LSR whose forwarding beh avior is being changed
and the upstream LSR inserting the data causing that change.</t> and the upstream LSR inserting the data causing that change.</t>
<t>Several requirements above address some of these considerations. The MN A framework <xref target="I-D.ietf-mpls-mna-fwk"/> <t>Several requirements above address some of these considerations. The MN A framework <xref target="I-D.ietf-mpls-mna-fwk"/>
also provides security considerations resulting from any extensions to the MPLS architecture, and these SHOULD be taken 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> together with the security considerations herein.</t>
<t>Individual solution specifications meeting the requirements in this doc ument MUST address any <t>Individual solution specifications meeting the requirements in this doc ument <bcp14>MUST</bcp14> address any
security considerations introduced by the MNA design.</t> security considerations introduced by the MNA design.</t>
</section> </section>
<section anchor="acknowledgements"> <section anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors gratefully acknowledge the contributions from Joel Halpern, <t>The authors gratefully acknowledge the contributions from <contact full
Greg Mirsky, Yingzhen Qu, Haoyu Song, name="Joel Halpern"/>, <contact fullname="Greg Mirsky"/>, <contact fullname="Yin
Tarek Saad, Loa Andersson, Tony Li, Adrian Farrel, Jie Dong and Bruno Decraene, gzhen Qu"/>, <contact fullname="Haoyu Song"/>,
and participants in the <contact fullname="Tarek Saad"/>, <contact fullname="Loa Andersson"/>, <contact
MPLS working group who have provided comments.</t> fullname="Tony Li"/>, <contact fullname="Adrian Farrel"/>, <contact fullname="Ji
e Dong"/>, <contact fullname="Bruno Decraene"/>, and participants in the
MPLS Working Group who have provided comments.</t>
<t>The authors also gratefully acknowledge the input of the members of the <t>The authors also gratefully acknowledge the input of the members of the
MPLS Open Design Team.</t> MPLS Open Design Team.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-mpls-mna-usecases" to="MNA-USECASES"/>
<displayreference target="I-D.ietf-mpls-mna-fwk" to="MNA-FRAMEWORK"/>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 19.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<author fullname="S. Bradner" initials="S." surname="Bradner"/> 74.xml"/>
<date month="March" year="1997"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.30
<abstract> 31.xml"/>
<t>In many standards track documents several words are used to sig <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.30
nify the requirements in the specification. These words are often capitalized. T 32.xml"/>
his document defines these words as they should be interpreted in IETF documents <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.53
. This document specifies an Internet Best Current Practices for the Internet Co 31.xml"/>
mmunity, and requests discussion and suggestions for improvements.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
</abstract> 26.xml"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l 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>
<reference anchor="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>This document specifies the architecture for Multiprotocol Labe
l Switching (MPLS). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3031"/>
<seriesInfo name="DOI" value="10.17487/RFC3031"/>
</reference>
<reference anchor="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>This document specifies the encoding to be used by an LSR in or
der 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 spe
cifies 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">
<front>
<title>MPLS Upstream Label Assignment and Context-Specific Label Spa
ce</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>RFC 3031 limits the MPLS architecture to downstream-assigned MP
LS labels. This document introduces the notion of upstream-assigned MPLS labels.
It describes the procedures for upstream MPLS label assignment and introduces t
he 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">
<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>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n 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 Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.ietf-mpls-mna-usecases">
<front>
<title>Use Cases for MPLS Network Action Indicators and MPLS Ancilla
ry Data</title>
<author fullname="Tarek Saad" initials="T." surname="Saad">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Kiran Makhijani" initials="K." surname="Makhijani"
>
<organization>Futurewei Technologies</organization>
</author>
<author fullname="Haoyu Song" initials="H." surname="Song">
<organization>Futurewei Technologies</organization>
</author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization>Ericsson</organization>
</author>
<date day="20" month="May" year="2024"/>
<abstract>
<t> 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> <!-- [I-D.ietf-mpls-mna-usecases] IESG state: I-D Exists as of 06/05/24 -->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mp
</front> ls-mna-usecases.xml"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-usecases-
07"/>
</reference>
<reference anchor="I-D.ietf-mpls-mna-fwk">
<front>
<title>MPLS Network Actions (MNA) Framework</title>
<author fullname="Loa Andersson" initials="L." surname="Andersson">
<organization>Huawei Technologies</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="Tony Li" initials="T." surname="Li">
<organization>Juniper Networks</organization>
</author>
<date day="7" month="May" year="2024"/>
<abstract>
<t> This document specifies an architectural framework for the M
PLS
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 <!-- [I-D.ietf-mpls-mna-fwk] IESG state: I-D Exists as of 06/05/24 -->
set of network actions and information elements supporting additional <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mp
operational models and capabilities of MPLS networks. Some of these ls-mna-fwk.xml"/>
actions are defined in existing MPLS specifications, while others <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.55
require extensions to existing specifications to meet the 86.xml"/>
requirements found in "Requirements for MPLS Network Actions". <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
20.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.67
90.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69
73.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.35
52.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
88.xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-fwk-08"/>
</reference>
<reference anchor="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>This document provides a security framework for Multiprotocol L
abel Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Netw
orks. This document addresses the security aspects that are relevant in the cont
ext of MPLS and GMPLS. It describes the security threats, the related defensive
techniques, and the mechanisms for detection and reporting. This document emphas
izes RSVP-TE and LDP security considerations, as well as inter-AS and inter-prov
ider security considerations for building and maintaining MPLS and GMPLS network
s across different domains or different Service Providers. This document is not
an Internet Standards Track specification; it is published for informational pur
poses.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5920"/>
<seriesInfo name="DOI" value="10.17487/RFC5920"/>
</reference>
<reference anchor="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>Load balancing is a powerful tool for engineering traffic acros
s a network. This memo suggests ways of improving load balancing across MPLS net
works using the concept of "entropy labels". It defines the concept, describes w
hy entropy labels are useful, enumerates properties of entropy labels that allow
maximal benefit, and shows how they can be signaled and used for various applic
ations. 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">
<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>This document offers guidance for developing privacy considerat
ions for inclusion in protocol specifications. It aims to make designers, implem
enters, and users of Internet protocols aware of privacy-related design choices.
It suggests that whether any individual RFC warrants a specific privacy conside
rations 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="RFC3552">
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</t
itle>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="B. Korver" initials="B." surname="Korver"/>
<date month="July" year="2003"/>
<abstract>
<t>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 Co
mmunity, 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="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>Multiprotocol Label Switching (MPLS) has defined a mechanism to
load-balance traffic flows using Entropy Labels (EL). An ingress Label Switchin
g Router (LSR) cannot insert ELs for packets going into a given Label Switched P
ath (LSP) unless an egress LSR has indicated via signaling that it has the capab
ility 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 capabi
lity for reading the maximum label stack depth and performing EL-based load-bala
ncing, referred to as Entropy Readable Label Depth (ERLD). This document defines
a mechanism to signal these two capabilities using IS-IS and Border Gateway Pro
tocol - Link State (BGP-LS).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9088"/>
<seriesInfo name="DOI" value="10.17487/RFC9088"/>
</reference>
</references> </references>
</references> </references>
<?line 368?>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA8VcbW/bRrb+LkD/YZB+qI1K2jpp08TABaraTuvCTryWi6K4
uFiMyJE0NcXhcki7auD/vudlZjhDUU4Wt3tvCySURM6cOa/PeWGm0+l4lJlc
l+tT0Tar6ZvxaDxqdFOoU3Gr/tnqWm1V2VixMrVYmKJttCmtaDayEYu2qkzd
iOubq4V4r5pHU9+LecZ3HF2/nx+PR3K5rNXDqYBPyXrjUW6yUm5hm7yWq2aq
Fey+rQo73ZZyWke3Tk9ej0ePQB/t8ytsAtSKH2vTVkC7bNTa1LtTocuVQeJt
I8v8H7IwJay9U7BTpU/FfzcmmwgL5NZqZeFqt+WLzGxpl//BZ4FQ3My2y622
Fs7R7CpY5fLi7h3+LNtmY+rT8UiIKf5B/+nSAmkz8YPJMi3C13y2a9k0G/XI
P4bfTA2neW/utQxf1QY5rnLdmDp8qbZSF6diy4vMlrjI9yU+NwOyB8hYABn1
TpZNj4xFox4lSKr3I9HxS6kfVG11sxNmBTKta7UTl4uzPhV2+b3lZZa0ygES
fp6J81reqx4FP5tN2fuBdr8sc1Up+CMiy234u/pHjg98v5MbY3g7/L80NXAE
iCZB3L47e3ly8tZfvzn57ht//errVyfR9Ut//e0r+B72CY+8fE0/wReoRPHq
l9PzWaqZrVWZtMoe+Hn1eB+2efvya3/9+ru33fXb714Fsr79NpD19us3b/Aa
zzidToVc2qaWWYOf7zbaCrCYFnVV2EpleqWVFXXfREFRRK4eVGEquhVEetg8
xeNGZxshVyuVNfQoLAESRncAZMByBr6sRVWbTIE9wLd+vUpm96qxM3G3UVal
dMhaCWakysVyJ6Qo2+0S1oGHwRprUxkrC6ZX5qDy7FIMUUCrBzGYEq7p+0Iu
VQHr8cYoO3hAFoV5FLbFQ2RhmaUSlap5/4lQms5AdAA/S9B0gYxS9VaXsAUc
6grXFotH3WQb/HxrWvgZ9zjSMzWbEAF800W+Vv73qbi6uD2esVayzLY6zwuF
n74A1W5qk7dEF8tQIWOssHpdgvgyMCI4HaykLF54uSEFgRO5bKSoClkqOBl4
oDyHuy39nvAcWFuCnwHtFKSe4uPHw7r79IRy00F9QGRw2LUqVS0LsVXZRpba
bifEJOD5YQ2adFJAkkp3D3y5BcuFZSOFMjVL36tSDkqMPlYsgaZckKg7sbPm
QZxh8TemYhUQ4N3FHYQMYKA4KyQw4+ju7FgsdQPeHH8ELhXWEYD8ANbgCin9
6HhAAg2qIDwjy0wXhax3zHA8W0wNCpkVvWOw452zuJUuNdO9EuqPRpV2T6ll
DdrVgKW18BRuyuehiJXdCwM6K6PoCuqBmtwib2RWG5Z6QgLojKlzZBMcFwjY
6j9BwUDcpBSSFQ/8JnzxB/p33BQEsDWNYsWjPZe68D86yvkbb9vwBARPU8Tn
KpVCRsO+mSE2+ZPCRpZsauDINjgucgsfPzof/fQ0CR9e4gckhb5At4nKSl7x
PZJNrBlmabc48CVaHKRjs1ovSc2DcpP3Sdxd7NdgC8AX6w36Lqc34B02YPdO
7viILJFrsthZbb2WRYvAX7vCyPxLC4v7VQq5A3ltlMzZJ5EYwMY04BhRGiBV
HA27I4v+ZnFrj2dCvEPFLIrdBCMWnptUbyshhJcF/JFlLeh1E2iHVchtHD3n
yCAaKKfPdAowVj4HnA7MDJwWsBbNHbf3bLsAZjzIQpWZ8tb47uLseCaei1p7
3gtlYVNwCSsCN4ZdD1j4vs3SU8iCpSL1ZCXDrdLwBVIEpXbh4v8xfv2F4Wtx
OxOXJCfkTKMzXYE65cFY4ICPwCo4pW0LCjXAT4HYlvTWc95LKCPCGYqczMQ8
/Z5XjW0KITR8H/wE3WA5ObB4SOTU1h7CIqgrpCkUkFYKACjrGSsKumKfeMyI
oA8QDIEFW9MZfeY8pyPLh9AB18XeBVYrNGnE0QkEMZSktxWWxJE9dhijVhJu
xVjmHa9XGtSTHsG9IBN0ekbMvMNABoITX4YfvpygODR8phNMeEHWAwiBdHok
+JmF7/rWBC4ZkaNTPFwhSBj4A3aMq6tSLouBMLCEjZQqe2HEEsr54gtxR3pn
CrPeIWwdj77qkXYq5mUXy/r6jFEe4lrsJdGIWItKC6cgTwKakt41Hi0VSsuZ
srfLmvwXOMR5T3zkCMAYGNnybQLibKMmyeZdAJggIZo9SASI45s18n2rHDR5
lBAhyc31WRBhi6P388tjYonm7yKPEC9NJgM8UHWDcusdBrz8nmeYua3nwQue
E3KZn8N+dKn3WA3u2WSaXANGM9hwDYnO3nZEzHjkfCkDEAQbFUQ/5+X6LlX1
14Czs7cBNwmIo/8QJBdDj6EkU6/uiOhRTinTV5BVwyFAbwBnF+QRJKpzKVGF
YheMBkQwjeKEw46ZrGvdBYk46MK3NxKWPrpa3BzPOFH8CtxOwbd+esdZ74ln
N17czFiUl+V0QVAQxXfa54R/DM8faxCjSMKQbp0bY5vPWWlfQbzx4+LgfhoQ
XIxrUsDqubrSNeQvJmtU4+8Gnak9/AH+pTggNxA1SgP4qHZBBJEH2RREV6Sd
1+fUp1aZQlREaA3jpSXc5RLT7m4HqTiYoj85c1L6FSAy5x7zTonOAASWcJaf
+Kmj+dlPx457i8xgzQe9quUTMSzjqAYQsMi9FQYDctrLeV9SNruS5bqVa+US
QHGvdgIUPrfixfUvi7sXE/5bvP9A17cXf//l8vbiHK8XP82vrsIF3zEewacP
v1y5G/Cqe/Tsw/X1xftzfhq+Fb2vrue/vaDwB6t8uLm7/PB+fvWCvVEsHwxr
7GwoOIAEGvYAPuaT5vxwdiNOvhmPCGhjBQaANl1jBQauQaQlx1qCpPwRhAbe
taqUrEn7igIreJVuAE5NKEHYmMdSIA4lZs4LxNwAw1MKNeuP7OJ7AgMmfDuY
KciGPS4oRG6qhpIWDPYZWIOrePGpKp+8xZHUpfZfDMGWXjXzM0s0xtlb6vZs
sCXIZTYcXVEEDkMBVtyoLTIMn50EHX8uq7UUeuwx1y4i99nPdCFeTML2AOTr
JsqRCKW6yEVKAf4C0CbbAq5PyoJ2TGLp+xMXH/cACj7ki1VLtZEP2tTedQSR
Biqsz1vBEbS1t0QCObqBwC6WrS4oGVkWJrsHYWCaBstxdUt3LNmHebz2YfYg
pQynWvBvOR3oMnJhLGbn5BXE7oKy9W7pNFCi5+oTQBUIt+l4RLsitmFGw4+Q
mkV8tJjiO1bJYbceOUVV5tPGTOGvAWevKR+WDUKjFTlICVkiiSgJBD55pAIB
X95cOBztLLHC4jJT1UumwIQWmqPj1IeNlMMludPpxlSi7/ypyuBwj6wJh3Qs
JVvGGOqSIsyNBZb91z6sTvZsr4k4yFa0L25vwuzmuCiKcQdFaFXWoWHCwz+6
olnfG3w8hXPUzX+9OHnxxFkUiP4TYF5QJCBI4cF7Rdi80ZyoJeWZCboyLOz4
jyQfRBgaMDRWFtCNslnSuSu4LRGsxzFcXsRPsAEtYwn9C6eO/DvhwOCD8C4X
f3xYEBuqAnIiJ7ONVg9gMcgMd/wowzcDqsLHh3VCPRA38dER4WRTa4bloVjp
fPhwQehQgamrL2En4OnJ03h5sHQXsYGTPqI6dwEtkEghE92Ftg1yfjwimP3X
UNc137ZKNT7DTRhIeKVt9kO65yylfFS0ozqdJzAt2nWON2zdLn+nhMh4veH8
srFOufYqKIdVfP4bOSoyhqjfQmkR2/4k9gPglygPjtxH7OH2mRPpC9dnZT+X
jSLrIa+EttWWha+0957PNsZg+TVaRw7mUC0XaQe3+N9SHvHoP0f7wU089XcU
96im4MJbUm5gh+Yr0xSztqbltlQUGb09IVXk6AVBnji1wWomx8QDjAu7UFW2
X5WLw+Zg1pQsSAwAS64VeKJPPk+hFcsB7jkOiVh4J/dadKmej6QQ0pnoXNus
dYKK6h+2T1K/zLX38MXZ9U2ygieWhcPFAqrl9WSdigq1T/1RYYE0tkzHRIqw
8RllARzKd+6RPNx3cXtYP3r797fFW5KtuTBCCaVbAS4fdIYBSXexng6vcyyd
EedXGlvKGiIzNxLefvfKJyjYc913q8MsDjkRUf6IAKClxMFvF3dsKBigT+O+
n+q4Xg6YBRd/k6YDOUY8FEDrwbYUV+ghjJPHtscDvrzXxcBSrSFhsdfl+Bz3
2Rw6kFsuRYgAbW4HwBMeY05JwnVIEkSKd14HwDNwaGqUMVKQlFcjaqaSIqis
rwIMJRa9gtnMF6cXKDWQ8k1bk/5QGQeSn8XNFbAHF4l7PqBBhbTYw8FJkJD3
1Gpl2N8mFKMT8p6QMrB9d9Y1BlA7cFOnsbgcCBjzpnx2gKG9OnjKxjeOjVzX
jzJ5t4GjNanMe4/eTzFWrvWqHzCNwzL20UIpsXB9o29mJ3gCl72/fP30dBxU
933PXQwYic+B9GAhEDE8uWEs4UbYnWo0Ud4Agcq3weKecSgko6i8gsRZzHi0
1XZKbVB8QFs2LPZGrhGGW7neh9us0aDujbxX5NwcVUMFyQ4a7oXJoCeSy1LU
j6CGtQEVt1hG4hZR78EJGjBxDvZ9ACeSqCgG5iipdPUvcOmhZEoru7wRHdF2
SY0gLl90NwQREu09PHaE0x9d978kj0P+41CeRloXhLkkYEFOPwRmMEmu7lPq
BYSUQ/ow3GxKNWkokXD1IpHpGnwyDnlFcXJIPIOnOwhoDh/q//xM4rPcRVTq
SRzHy1fecQAYqFnfEFNRiyPCXGhPgCDguGFugfyuS+ri6Yk0PUiSwm5oIajb
r65PHrIEH6WjuZK+pyVOuY6Uiwuayee5ka3JgYcuMlruy4XA4R0PnH/dlaDh
xom3ES4Wh8IV9hQc3Ah34rSFzDJV0WhRVGboV00Q1UWHgoe7FJf0LMkGnTqh
G8hVgYN2O26h0xkdTNfk4u9LLH2G+Qa6AUcRXRs1El1v3zv+6HEWa52LBJAR
hlSRPRKFqiQ8BPqHu0HP6DQX2Ny6tXdMFPuqqoBHXLrZK0GmPEsUwWmfJ580
cuVzwBsD0ArrWXQhjm5e3hyTqMIP1+DideV/vYafK9ls7EQsW0SR/igsJ8hE
KSYVEM6bDqQ/e3yMKTRhwS1ovJ+VKxS/cEPXWme95JkvKbICq96YUvA6AMus
OcQHHijCIanO1qKCKLKEeOMT+6jo4GaFwGBWXP9xeQgAAFrGF1jt58BTTiGq
wuz8GJgvGiHft7KUay4Y0to2tUsSu2srY6Ed9Bs8gpJbziR4BIJtDlb7m6k7
m3Oq+IymRET2KrxbUoKiL0kbCmEIdeksYcTl2U0+mZIHqsGVk1QOF8Q9qgqy
I21aenfHkafLs6rWYpeWk01gvEtmuUqCOu2GxJK2+HjUK4WSSjq3SBD/7tGA
A5R4EEoUP2tDsmvssmFV2UuQqzHaTSAi3sUpk0rqGgzwioaVohCNAu3i8sHa
i/NvPg3n7oPl6AkLeJ1HRJvkBwM5/dyLxD/EY0UceVF/S7DdyHgIJESVuY74
YMmHIQSBvTIi3fYzmIhCLNMEIIgiBKPVzl9CfqZqD/+sn4gYKPn7mTRsoaCw
ffkEdnHGm3ZxYw511r9Lg4vE/GhrHjroFDr4cdXDGaA17m5S/8jLo3Kk7PGr
xOE0qlT1bu/GU3nYA8iscTK89DDAyzix2KEEBZfBEdvLOdyJGTP4oAYrlmuN
JWVlnTO7DzkbZ01Mr7HJrcH1wvlwDhL5Jjmqq9JiYbctJUDydWta0HGqQoTw
gW0HfD0Bs5s/KRLaAacDgalPMqpBjTwWtSzXiucnpKdrR1RF+d3sk+WeoaiO
4zHREGBIw10HppBZ1xNJJgQnQd99hsaN3jp6qqvn9qq3A0i3N9OS4Ntvvnb4
9t/ITD1V+xo2HsW1x1VbrHTBypjtZZ0M0+JC9N/2T/Nvp8zDnBnMvni+z9Xc
DtdGSIGWqLSPtW7ArXX9xP1SJyrOoZTvUNeAZ4do0joESLME1YLIf7iXIBbY
cLNp1Xap0qkCKRbOPvCsdzVSBc44lHv6vE1Xw4Qe61xELcE64s0/WxyKZBBy
ML3lSEfFnXbry9ReOT5tT90sBmVNhyUZObyuqEzpZqqbK9S3R5q7cshAl1RF
6fvhjCdSaoXDDq6STEKI40aPbJIgA1dgCBKcTCWs2jJNDajzTD1wdHBdhuWK
lLtnOuhxamfvdVW5Vjg2KTjlYT+zv9D8PG4eHvbyvrLYmyXSjI4SpQ3K2e80
j0cRuj5Ss/VsEpAuj+v4EQlq+EIKcXCYyI1TaJyr7bL+RCaUNKvPAuBotxe3
HgqhJtgB1e0w93jkz68kmBtlkWnpJi527U0QYNlE5nFnkaoEjRtwYytJRuWF
dNOLtNURvm2ABhgan11ly0/l43tOWGJ0h3/nM8dDUWIPHw63mRJ+ddUD0q5H
iuLdFL7PCNJ3RPatcKjMcKA2j+V3AEB9ME44ORrZ42Q5xeaoB+QcZXckrFH4
8YeEhCFsj3LrUqeQ5WIWykhhfk5pSzR1SKdofH5Hdb8I6rO6NaI7EgWbqMXT
xZJ5JGI2drK3hroOGOSAONX1vcKYTwdse5y0xhXenQVzlYruhG9khTMRNVpe
seuyi+dC2F6OpdEtlL87L+fjWVRsdi+1gP5QkholBP7UNwcd/H9uy94oUbIr
I35g3iOO1/l3ixAJ6DIr2tzDAV8M6rVzP90fTJ0ICny93xodYgW9IePaJeMR
qaHHQiYtrUV1fxpCSSqnfuDevQHnB6ARE5imX3sPGKIhBNGP0kv3xparzFFO
SM2D51v1f91Gz/fV6eVBBP5nSZNxf8gQ3Rd2YkO6AGLAB2kVfl3KIHwSF/Re
8SmHIhu9LkQwEbM3mrep2qUXDjVNyvGIwRdStPCtz32qOjjJNUiagcsMi9J5
jGQ+ZG9ABWkJfdOk00rd3KTVatwIEjv1SGlcSboENwG6BcgimjR2jRaIHDgt
2Ew1nC00c6PYz4M3b1/Sa2ekYZcltal01oKU3PBlhzuplrxl9No1VbEZhTzt
p7w0EE0t4u5bHly27o3MqDbdAf+u/+2fmvKMlG+Fb/V60zCge9QU6QBHAWcx
ZTCVBOVIxpmcjUPsbWt8BpV64kcOWRTotuIjUVvbdEWA7k0mYkgoW0fiCJOd
NC0gMGThyDYgyALf3fAgM7Tkwhue9OaxLBmf8lfkL6O13bAadTkaYODk4OZO
y1kFfQtQsh27VyNBBKAHAAyzmbMwrhBYX+7TGWYSdUudY35Rx250lQzTIev2
NDJmAb/Awo4z58oZPtdWXU00gi0UmBmTtV1dhp8mg1wA3q+p2hbPXS2pEONe
EuaXVXxhOjUjxvSIola13Cpy+UOvDK8e75+e/Cu1zozswTEI5jCSS5qP5vYZ
L8OGPjxQ2TlO6s5iLFwzng2I8tDmWLjQbtQFm2NAagsMOlQaOjhFNzw955mK
Z4pcR4+G4MMC0EIWuyEc9qPzDNMeMKB1PDsOUqN/XMKKNeYGq7ZAI+ludYkd
LK+XPnVHFv9sMPGQBeCIciJ+rBUk3rq297uJ+A1O9yd2LP/eTuAWs2sh78cu
IOwHkfReLCQazpWRkICgC7LYK7wzcMArPRHzHEBWKd7JGnR+In7WSpwbF5p/
qFuw6HOV1RLSIZYfO0ldyW4s0CUKj+6f7FjjP9mBRoL1SuW1KQ//BId/abTj
BWndMwzhd5KcA9miH6795JPb+0MFDDjnztgdmNnMv6m/hLU42P4LF7m4TwRF
AAA=
</rfc> </rfc>
 End of changes. 85 change blocks. 
682 lines changed or deleted 302 lines changed or added

This html diff was produced by rfcdiff 1.48.