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 " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<?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> | |||
<!-- [rfced] May we update the abbreviation MNA be plural to align with the expa | ||||
nsion "MPLS Network Actions"? Note that we would not add an "s" to phrases like | ||||
"MNA solution" or "MNA information." | ||||
Current: Network Actions (MNA) | ||||
Perhaps: Network Actions (MNAs) | ||||
--> | ||||
<title abbrev="MNA Requirements">Requirements for Solutions that Support MPL S Network Actions (MNA)</title> | <title abbrev="MNA Requirements">Requirements for Solutions that Support MPL S Network Actions (MNA)</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 ISC</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="July"/> | |||
<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 | <!-- [rfced] Please insert any keywords (beyond those that appear in | |||
ons (MNA) which affect the forwarding | the title) for use on https://www.rfc-editor.org/search. --> | |||
<keyword>example</keyword> | ||||
<abstract> | ||||
<t>This document specifies requirements for the development of MPLS Network Acti | ||||
ons (MNA) 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 ke a forwarding or | general mechanism, termed MPLS Network Actions (MNA), to allow the network to ma ke a forwarding or | |||
processing decision based on information other than the top label and Traffic Cl ass (TC) bits, and | processing decision based on information other than the top label and Traffic Cl ass (TC) bits, and to | |||
also make use of the Network Action Indicator and ancillary data (MNA informatio n). | also make use of the Network Action Indicator and ancillary data (MNA informatio n). | |||
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 with the existing MPLS architecture as specified by <xref target="RFC 3031"/>, <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 | <!-- [rfced] We are having trouble parsing "that may be needed by the processing | |||
Network Actions | of those actions." Does this mean "to process those actions"? | |||
Original: | ||||
This document specifies the requirements for solutions that encode | ||||
MPLS Network Actions and ancillary data that may be needed by the | ||||
processing of those actions. | ||||
Perhaps: | ||||
This document specifies the requirements for solutions that encode | ||||
MPLS Network Actions and ancillary data that may be needed to process | ||||
those actions. | ||||
--> | ||||
<!-- [rfced] We find this sentence a bit tough to parse. Please consider whethe | ||||
r the suggested update is more clear. | ||||
Original: | ||||
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 LSR. | ||||
Perhaps: | ||||
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. | ||||
--> | ||||
<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 requirements are informed by a number of | and ancillary data that may be needed by the processing of those actions. 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 LSR. I t is | to allow such actions to be performed, either by a transit or terminating LSR. I t 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 | <!-- [rfced] We converted this list to a definition list to highlight the name o | |||
forms of MPLS Network Actions. | f the solution. Please let us know if you prefer this be reverted. | |||
This is referred to as the MNA Solution.</t> | ||||
</li> | Note that we have lowercased "solution" in "MNA solution", as this was the only | |||
<li> | place it appeared with a capital 's'. In addition, we updated the text to use " | |||
<t>One or more specifications describing the protocol extensions, and | Network Action solutions" consistently. Please let us know if corrections are n | |||
utilising (1), for network action(s) | eeded.. | |||
to realise a use case. These are referred to as Network Action solutions.</t> | ||||
</li> | In addition, for Network Action solutions, what does "to realise a use case" mea | |||
</ol> | n? Please consider the suggested update below. | |||
Original: | ||||
It is anticipated that these will result | ||||
in two types of solution specification: | ||||
1. A specification that describes a common protocol that supports | ||||
all forms of MPLS Network Actions. This is referred to as the | ||||
MNA Solution. | ||||
2. One or more specifications describing the protocol extensions, | ||||
and utilising (1), for network action(s) to realise a use case. | ||||
These are referred to as Network Action solutions. | ||||
Current: | ||||
It is anticipated that these will result | ||||
in two types of solution specifications: | ||||
MNA solution: A specification that describes a common protocol that | ||||
supports all forms of MPLS Network Actions. | ||||
Network Action solutions: One or more specifications describing the | ||||
protocol extensions, and utilizing (1), for network action(s) to | ||||
realize a use case. | ||||
Perhaps: | ||||
Network Action solutions: One or more specifications describing the | ||||
protocol extensions for the MNA solution (1) to address a use case. | ||||
--> | ||||
<dl spacing="normal"> | ||||
<dt>MNA solution:</dt><dd>A specification that describes a common prot | ||||
ocol that supports all forms of MPLS Network Actions.</dd> | ||||
<dt>Network Action solutions:</dt><dd>One or more specifications descr | ||||
ibing the protocol extensions, and utilizing (1), for network action(s) to reali | ||||
ze a use case.</dd> | ||||
</dl> | ||||
<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"> | <!-- [rfced] "(NA)" was previously introduced in the body of the document. We i | |||
<li> | ntroduced it where Network Action is defined in in the Terminology section. Ple | |||
<t>Network Action: An operation to be performed on an MPLS packet or | ase note that "network action" is heavily used in the document and "NA" is only | |||
as a consequence of an MPLS packet | used in a few places. Please let us know if you would like to use "network acti | |||
on" consistently. | ||||
Original: | ||||
21. If a Network Action (NA) requires ... | ||||
34. If an NA requires in-stack ancillary data, the NAI that | ||||
indicates this NA MUST be present in the label stack. | ||||
38. MNA solution specifications MUST request IANA to create | ||||
registries and make allocations from those registries for NAIs | ||||
as necessary to ensure unambiguous identification of | ||||
standardized NAs. | ||||
--> | ||||
<dl spacing="normal"> | ||||
<dt>Network Action (NA):</dt><dd> An operation to be performed on an | ||||
MPLS packet or as a consequence of an MPLS packet | ||||
being processed by a router. A network action may | being processed by a router. A network action 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 network action | |||
<t>Network Action Indicator (NAI): An indication in the MPLS packet | is to be performed.</dd> | |||
that a certain network action | <!-- [rfced] We suggest the following update for clarity. Please review and let | |||
is to be performed.</t> | us know if the suggested text accurately captures the intended meaning. | |||
</li> | ||||
<li> | Original: | |||
<t>Ancillary Data (AD): Data in an MPLS packet associated with a giv | * Ancillary Data (AD): Data in an MPLS packet associated with a | |||
en network action that | given network action that may be used as input to the processing | |||
of the network action or results from the processing of the | ||||
network action. | ||||
Perhaps: | ||||
* Ancillary Data (AD): Data in an MPLS packet associated with a | ||||
given network action that may be used as input to process | ||||
the network action or may result from processing the | ||||
network action. | ||||
--> | ||||
<dt>Ancillary Data (AD):</dt><dd><t>Data in an MPLS packet associate | ||||
d with a given network action that | ||||
may be used as input to the processing of the network action or results from the processing | 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: | of the network action. Ancillary data may be associated with:</t> | |||
</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 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 | <!-- [rfced] We have removed instances of <br/> from the XML fiile because they | |||
chnology to support | were causing odd line breaks in the outputs. Please let us know any concerns. | |||
them in MPLS, such as the Network Action Indicators (NAIs), the associated ancil | ||||
lary data (AD), and the alert mechanism | Original: | |||
<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 | ||||
constructed.<br/> | ||||
It does not specify the detailed actions and processing of any network actions o | ||||
r ancillary | ||||
data by an LSR or LER.</t> | ||||
<t>An MNA solution <bcp14>MUST</bcp14> allow indicators for multiple | ||||
network | ||||
actions in the same MPLS<br/> | ||||
packet.</t> | ||||
--> | ||||
<t>This document specifies requirements on MPLS Network Actions and the te | ||||
chnology 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> | 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 nstructed.<br/> | out of which indicators for network actions and associated ancillary data are co nstructed. | |||
It does not specify the detailed actions and processing of any network actions o r 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 | <!-- [rfced] Note that we have expanded the following abbreviations: | |||
packet is a matter for | ||||
agreement between the ingress and egress PEs, and is not part of these requireme | PEs: provider edges (PEs) | |||
nts. | LSP: Label Switched Path (LSP) | |||
Original: | ||||
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 | ||||
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 LSP, requirements on the size of such | ||||
ancillary data are documented in the following sections. | ||||
--> | ||||
<t>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 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 | <!-- [rfced] Because "solutions" is defined as referring to both MNA and network | |||
of extensibility, | action solutions, should this say "Any solutions MUST maintain..."? | |||
1. Any MNA and Network Action solution MUST maintain the properties... | ||||
--> | ||||
<t>Any MNA and Network Action solutions <bcp14>MUST</bcp14> maintain | ||||
the properties of extensibility, | ||||
flexibility, and efficiency inherent in the split between the control plane cont ext and simple | flexibility, and efficiency inherent in the split between the control plane cont ext and simple | |||
data plane used in MPLS, and SHOULD describe how this is achieved.</t> | data plane used in MPLS and <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> | |||
<!-- [rfced] For clarity, can this be made into a positive statement? | ||||
Original: | ||||
3. If extensions to the MPLS data plane are required, they <bcp14>MUST NOT< | ||||
/bcp14> | ||||
be inconsistent with the MPLS architecture [RFC3031], [RFC3032] | ||||
and [RFC5331]. | ||||
Suggested: | ||||
3. If extensions to the MPLS data plane are required, they <bcp14>MUST</bcp | ||||
14> | ||||
be consistent with the MPLS architecture [RFC3031] [RFC3032] | ||||
[RFC5331]. | ||||
--> | ||||
<li> | <li> | |||
<t>If extensions to the MPLS data plane are required, they MUST NOT be inconsistent | <t>If extensions to the MPLS data plane are required, they <bcp14>MU ST NOT</bcp14> be inconsistent | |||
with the MPLS architecture <xref target="RFC3031"/>, <xref target="RFC3032"/> an d <xref target="RFC5331"/>.</t> | with the MPLS architecture <xref target="RFC3031"/>, <xref target="RFC3032"/> an d <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 ancillary data, | <t>Solutions <bcp14>MUST NOT</bcp14> require an implementation to su pport in-stack ancillary data, | |||
unless the implementation chooses to support a network action that uses in-stack ancillary data.</t> | unless the implementation chooses to support a network action that uses in-stack ancillary data.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>Solutions MUST NOT require an implementation to support post-stac k ancillary data, | <t>Solutions <bcp14>MUST NOT</bcp14> require an implementation to su pport post-stack ancillary data, | |||
unless the implementation chooses to support a network action that uses post-sta ck ancillary data.</t> | unless the implementation chooses to support a network action that uses post-sta ck 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 that is not | <t>Solutions that increase the size of the MPLS label stack in a way that is not | |||
controlled by the ingress LER MUST discuss the consequences.</t> | controlled by the ingress LER <bcp14>MUST</bcp14> discuss 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 network action <bcp14>MUST NOT</bcp14> expose a ny information 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 e present in the MPLS packet.</t> | <t>An MNA solution <bcp14>MUST</bcp14> define how a node 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; the | |||
therefore an MNA solution | refore, an MNA solution | |||
that uses them MUST minimize the number of new SPLs that are allocated.</t> | that uses them <bcp14>MUST</bcp14> minimize the number of new SPLs that are allo | |||
cated.</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 | <!-- [rfced] Are instances of "MNA specification" and "Network action specificat | |||
ns for | ions" intended? Or should these refer to "MNA solution" and "Network Action sol | |||
private use (See Section 4.1 of <xref target="RFC8126"/>).</t> | utions"? | |||
For example: | ||||
Original: | ||||
18. It is RECOMMENDED that an MNA specification support network... | ||||
19. Network action specifications MUST specify if the network action... | ||||
27. A given network action specification MUST specify which scope ... | ||||
Similarly, is "specification" needed when it follows MNA solution or "Network Ac | ||||
tion solution"? | ||||
For example: | ||||
Original: | ||||
21. If a Network Action (NA) requires an NAI with in-stack ancillary | ||||
data that needs to be imposed at an LSR on an LSP, then the | ||||
network action solution specification MUST specify how this is | ||||
achieved in all circumstances. | ||||
39. A network action solution specification MUST state where the... | ||||
38. MNA solution specifications MUST request ... | ||||
46. Any MNA solution specification MUST describe whether it can... | ||||
--> | ||||
<t>It is <bcp14>RECOMMENDED</bcp14> that an MNA specification suppor | ||||
t network actions for | ||||
Private 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 needs to | <t>Network action specifications <bcp14>MUST</bcp14> specify if the network action needs to | |||
be processed as a part of the immediate forwarding operation and whether MPLS pa cket | be processed as a part of the immediate forwarding operation and whether MPLS pa cket | |||
mis-ordering is allowed to occur as a result of the time taken to process the ne twork action.</t> | misordering is allowed to occur as a result of the time taken to process the net work action.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>If a network action solution allows more than one scope for a net work action, it MUST provide a mechanism to specify the precedence | <t>If a Network Action solution allows more than one scope for a net work action, it <bcp14>MUST</bcp14> provide a mechanism to specify the precedenc e | |||
of the scopes or any combination of the scopes.</t> | 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 specification <bcp14>MUST</bcp14> s | |||
is achieved in all circumstances.</t> | pecify how this is achieved in all circumstances.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>If a network action requires an NAI with post-stack ancillary dat a to be imposed at an LSR | <t>If a network action requires an NAI with post-stack ancillary dat a to be imposed at an LSR | |||
on an LSP, then the network action solution specification MUST specify how this is achieved in all circumstances.</t> | on an LSP, then the Network Action solution specification <bcp14>MUST</bcp14> sp ecify how this is achieved 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 scopes are applicable to the associated NAI.</t> | <t>A given network action specification <bcp14>MUST</bcp14> specify which scope or scopes are applicable to the associated NAI.</t> | |||
</li> | </li> | |||
<!--[rfced] For clarity, we suggest the following update to the text after the c | ||||
omma. | ||||
Original: | ||||
28. An MNA solution SHOULD support NAIs for both Point-to-Point | ||||
(P2P) and Point-to-Multipoint (P2MP) paths, but a specific NAI | ||||
MAY be limited by the network action specification to only one | ||||
or the other of these path types if there is a clear reason to | ||||
do so. | ||||
Perhaps: | ||||
28. An MNA solution SHOULD support NAIs for both Point-to-Point | ||||
(P2P) and Point-to-Multipoint (P2MP) paths, but the network action speci | ||||
fication | ||||
MAY limit a specific NAI to only one | ||||
of these path types if there is a clear reason to | ||||
do so. | ||||
--> | ||||
<li> | <li> | |||
<t>An MNA solution SHOULD support NAIs for both Point-to-Point (P2P) and Point-to-Multipoint (P2MP) paths, but a specific NAI MAY | <t>An MNA solution <bcp14>SHOULD</bcp14> support NAIs for both Point -to-Point (P2P) and Point-to-Multipoint (P2MP) paths, but a specific NAI <bcp14> MAY</bcp14> | |||
be limited by the network action specification to only one or the other of these path types if there is a clear reason to do so.</t> | be limited by the network action specification to only one or the other 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 onsistent across different control | <t>An MNA solution defining data plane mechanisms for NAIs <bcp14>MU ST</bcp14> be consistent across different control | |||
plane protocols.</t> | 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 NAIs present in an MPLS packet.</t> | <t>An MNA solution <bcp14>MUST NOT</bcp14> require an 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 an NA requires in-stack ancillary data, the NAI that indicates this NA <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 allocations from those registries for NAIs | |||
as necessary to ensure unambiguous identification of standardized NAs. An MNA so | as necessary to ensure unambiguous identification of standardized NAs. An MNA so | |||
lution MAY request IANA to reserve a range | lution <bcp14>MAY</bcp14> request that IANA reserve a range | |||
of a registry for private use.</t> | of a registry for Private Use.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>A network action solution specification MUST state where the NAIs are to be placed in the MPLS | <t>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> | packet, that is whether they are placed in-stack or post-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 specifications <bcp14>MUST</bcp14> specify whether | |||
is | 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 specifications <bcp14>MUST</bcp14> specify if in-s | |||
ack ancillary data that is | tack or post-stack ancillary data that is | |||
already present in the MPLS packet MAY be rewritten by an LSR.</t> | already present in the MPLS packet <bcp14>MAY</bcp14> 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 | <!-- [rfced] For clarity, may we update the text as follows? | |||
a unless the size of that ancillary data if it was inserted into | ||||
Original: | ||||
44. A network action solution SHOULD NOT use post-stack ancillary | ||||
data unless the size of that ancillary data if it was inserted | ||||
into the label stack could prevent the coexistence of the | ||||
network action with other in-use MPLS network functions. | ||||
Suggested: | ||||
44. A Network Action solution SHOULD NOT 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 inser | ||||
ted into the label stack. | ||||
--> | ||||
<t>A Network Action solution <bcp14>SHOULD NOT</bcp14> use post-stac | ||||
k ancillary data unless the size of that ancillary data if it was inserted into | ||||
the label stack could prevent the coexistence of the network action with other i n-use MPLS network functions.</t> | the label stack could prevent the coexistence of the network action with other i n-use MPLS network functions.</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 it can coexist with existing post-stack data | |||
mechanisms (e.g., control words and the Generic Associated Channel Header), and | mechanisms (e.g., control words and the Generic Associated Channel Header), and | |||
if so how this coexistence operates.</t> | if so how 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 cillary data MUST analyze the | <t>A Network Action solution that needs to change the size of the an cillary data <bcp14>MUST</bcp14> analyze the | |||
implications on MPLS packet forwarding and specify how these are addressed.</t> | implications 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 encoding in-stack ancillary data.</t> | <t>Not more than one Standards Track solution <bcp14>SHOULD</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 encoding post-stack ancillary data.</t> | <t>Not more than one Standards Track solution <bcp14>SHOULD</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, | <!-- [I-D.ietf-mpls-mna-usecases] IESG state: I-D Exists as of 06/05/24 --> | |||
but rather the ones that are actively discussed by members of the | <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mp | |||
IETF MPLS, PALS, and DetNet working groups. | ls-mna-usecases.xml"/> | |||
</t> | <!-- [I-D.ietf-mpls-mna-fwk] 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-fwk.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 | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59 | |||
set of network actions and information elements supporting additional | 20.xml"/> | |||
operational models and capabilities of MPLS networks. Some of these | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.67 | |||
actions are defined in existing MPLS specifications, while others | 90.xml"/> | |||
require extensions to existing specifications to meet the | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69 | |||
requirements found in "Requirements for MPLS Network Actions". | 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?> | <!-- [rfced] Please review the "Inclusive Language" portion of the online | |||
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> | ||||
</back> | and let us know if any changes are needed. | |||
<!-- ##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= | ||||
Note that our script did not flag any words in particular, but this should | ||||
still be reviewed as a best practice. | ||||
--> | --> | |||
</back> | ||||
</rfc> | </rfc> | |||
End of changes. 96 change blocks. | ||||
623 lines changed or deleted | 451 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |