rfc9613.original   rfc9613.txt 
MPLS Working Group M. Bocci, Ed. Internet Engineering Task Force (IETF) M. Bocci, Ed.
Internet-Draft Nokia Request for Comments: 9613 Nokia
Intended status: Informational S. Bryant Category: Informational S. Bryant
Expires: 1 December 2024 University of Surrey ISC ISSN: 2070-1721 University of Surrey ICS
J. Drake J. Drake
Independent Independent
30 May 2024 August 2024
Requirements for Solutions that Support MPLS Network Actions (MNA) Requirements for Solutions that Support MPLS Network Actions (MNAs)
draft-ietf-mpls-mna-requirements-16
Abstract Abstract
This document specifies requirements for the development of MPLS This document specifies requirements for the development of MPLS
Network Actions (MNA) which affect the forwarding or other processing Network Actions (MNAs) that affect the forwarding or other processing
of MPLS packets. These requirements are informed by a number of 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 to allow such actions to be performed, either by a transit or
terminating Label Switching Router (i.e., the Label Edge Router - terminating Label Switching Router (i.e., the Label Edge Router -
LER). LER).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 1 December 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9613.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language
3. MPLS Network Action Requirements . . . . . . . . . . . . . . 4 3. MPLS Network Action Requirements
3.1. General Requirements . . . . . . . . . . . . . . . . . . 4 3.1. General Requirements
3.2. Requirements on the MNA Alert Mechanism . . . . . . . . . 6 3.2. Requirements on the MNA Alert Mechanism
3.3. Requirements on Network Actions . . . . . . . . . . . . . 6 3.3. Requirements on Network Actions
3.4. Requirements on Network Action Indicators . . . . . . . . 6 3.4. Requirements on Network Action Indicators
3.5. Requirements on Ancillary Data . . . . . . . . . . . . . 8 3.5. Requirements on Ancillary Data
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses
1. Introduction 1. Introduction
There is significant interest in developing the MPLS data plane to There is significant interest in developing the MPLS data plane to
address the requirements of new use cases address the requirements of new use cases [MNA-USECASES]. This
[I-D.ietf-mpls-mna-usecases]. This requires a general mechanism, requires a general mechanism, termed MPLS Network Actions (MNAs), to
termed MPLS Network Actions (MNA), to allow the network to make a allow the network to make a forwarding or processing decision based
forwarding or processing decision based on information other than the on information other than the top label and Traffic Class (TC) bits,
top label and Traffic Class (TC) bits, and also make use of the and to also make use of the Network Action Indicator (NAI) and
Network Action Indicator and ancillary data (MNA information). These ancillary data (MNA information). These use cases require the
use cases require the definition of extensions to the MPLS definition of extensions to the MPLS architecture and label-stack
architecture and label stack operations that can be used across these operations that can be used across these use cases in order to
use cases in order to minimize implementation complexity and promote minimize implementation complexity and promote interoperability and
interoperability and extensibility. These protocol extensions need extensibility. These protocol extensions need to conform to the
to conform to the existing MPLS architecture as specified by existing MPLS architecture as specified by [RFC3031], [RFC3032], and
[RFC3031], [RFC3032], and [RFC6790]. [RFC6790].
Note that the MPLS architecture specified in [RFC3031] describes a Note that the MPLS architecture specified in [RFC3031] describes a
mechanism for forwarding MPLS packets through a network without mechanism for forwarding MPLS packets through a network without
requiring any analysis of the MPLS packet payload's network layer requiring any analysis of the MPLS packet payload's network layer
header by intermediate nodes (Label Switching Routers - LSRs). header by intermediate nodes (Label Switching Routers - LSRs).
Formally, inspection may only occur at network ingress (the Label Formally, inspection may only occur at network ingress (the Label
Edge Router - LER) where the MPLS packet is assigned to a Forwarding Edge Router - LER) where the MPLS packet is assigned to a Forwarding
Equivalence Class (FEC). Equivalence Class (FEC).
This document specifies the requirements for solutions that encode This document specifies the requirements for solutions that encode
MPLS Network Actions and ancillary data that may be needed by the MNAs and ancillary data that may be needed to process those actions.
processing of those actions. These requirements are informed by a These requirements are informed by a number of proposals to allow
number of proposals for additions to the MPLS information in the additions to the MPLS information in the labeled packet so that such
labeled packet to allow such actions to be performed, either by a actions can be performed, either by a transit or terminating LSR. It
transit or terminating LSR. It is anticipated that these will result is anticipated that these will result in two types of solution
in two types of solution specification: specifications:
1. A specification that describes a common protocol that supports MNA solution specification: A specification that describes a common
all forms of MPLS Network Actions. This is referred to as the protocol that supports all forms of MNAs.
MNA Solution.
2. One or more specifications describing the protocol extensions, Network Action solution specifications: One or more specifications
and utilising (1), for network action(s) to realise a use case. describing the protocol extensions for the MNA solution to address
These are referred to as Network Action solutions. a use case.
The term 'solutions', in isolation, refers to both MNA and Network The term 'solutions', in isolation, refers to both MNA and Network
Action solutions. The requirements constrain the MNA solution design Action solutions. The requirements constrain the MNA solution design
to enable interoperability between implementations. to enable interoperability between implementations.
1.1. Terminology 1.1. Terminology
* Network Action: An operation to be performed on an MPLS packet or Network Action (NA): An operation to be performed on an MPLS packet
as a consequence of an MPLS packet being processed by a router. A or as a consequence of an MPLS packet being processed by a router.
network action may affect router state, MPLS packet forwarding, or An NA may affect router state or MPLS packet forwarding, or it may
it may affect the MPLS packet in some other way. affect the MPLS packet in some other way.
* Network Action Indicator (NAI): An indication in the MPLS packet Network Action Indicator (NAI): An indication in the MPLS packet
that a certain network action is to be performed. that a certain NA is to be performed.
* Ancillary Data (AD): Data in an MPLS packet associated with a Ancillary Data (AD): Data in an MPLS packet associated with a given
given network action that may be used as input to the processing NA that may be used as input to process the NA or may result from
of the network action or results from the processing of the processing the NA. Ancillary data may be associated with:
network action. Ancillary data may be associated with:
- Both control or maintenance information and the data traffic * Both the control or maintenance information and the data
carried by the Label Switched Path (LSP). traffic carried by the Label Switched Path (LSP).
- Only the control or maintenance information. * Only the control or maintenance information.
- Only the data traffic carried by the LSP. * Only the data traffic carried by the LSP.
* In-Stack Data: Ancillary data carried within the MPLS label stack. In-Stack Data: Ancillary data carried within the MPLS label stack.
* Post-Stack Data: Ancillary data carried in an MPLS packet between 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 the bottom of the MPLS label stack and the first octet of the user
payload. This document does not prescribe whether post-stack data payload. This document does not prescribe whether post-stack data
precedes or follows any other post-stack header such as a Control precedes or follows any other post-stack header such as a Control
Word or Associated Channel Header (ACH). Word or Associated Channel Header (ACH).
* Scope: The set of nodes that should perform a given action. Scope: The set of nodes that should perform a given action.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Although this document is not a protocol specification, this Although this document is not a protocol specification, this
convention is adopted for clarity of description of requirements. convention is adopted for clarity of description of requirements.
3. MPLS Network Action Requirements 3. MPLS Network Action Requirements
This document specifies requirements on MPLS network actions and the This document specifies requirements on MNAs and the technology to
technology to support them in MPLS, such as the Network Action support them in MPLS, such as NAIs, the associated AD, and the alert
Indicators (NAIs), the associated ancillary data (AD), and the alert
mechanism to indicate to an LSR that NAIs are present in an MPLS mechanism to indicate to an LSR that NAIs are present in an MPLS
packet. packet.
The requirements are for the behavior of the protocol mechanisms and The requirements are for the behavior of the protocol mechanisms and
procedures that constitute building blocks out of which indicators procedures that constitute building blocks out of which indicators
for network actions and associated ancillary data are constructed. for a NA and associated ancillary data are constructed. It does not
It does not specify the detailed actions and processing of any specify the detailed actions and processing of any NAs or ancillary
network actions or ancillary data by an LSR or LER. data by an LSR or LER.
The size of the ancillary data carried post-stack end-to-end in an 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 MPLS packet is a matter for agreement between the ingress and egress
PEs, and is not part of these requirements. Since in-stack ancillary provider edges (PEs), and is not part of these requirements. Since
data and per-hop post-stack data need to be parsed and processed by in-stack ancillary data and per-hop post-stack data need to be parsed
transit LSRs along the LSP, requirements on the size of such and processed by transit LSRs along the Label Switched Path (LSP),
ancillary data are documented in the following sections. requirements on the size of such ancillary data are documented in the
following sections.
3.1. General Requirements 3.1. General Requirements
1. Any MNA and Network Action solution MUST maintain the properties 1. Any solutions MUST maintain the properties of extensibility,
of extensibility, flexibility, and efficiency inherent in the flexibility, and efficiency inherent in the split between the
split between the control plane context and simple data plane control plane context and simple data plane used in MPLS and the
used in MPLS, and SHOULD describe how this is achieved. specification SHOULD describe how this is achieved.
2. Any solutions to these requirements MUST be based on and MUST 2. Any solutions to these requirements MUST be based on and MUST
NOT restrict the generality of the MPLS architecture [RFC3031], NOT restrict the generality of the MPLS architecture [RFC3031]
[RFC3032] and [RFC5331]. [RFC3032] [RFC5331].
3. If extensions to the MPLS data plane are required, they MUST NOT 3. If extensions to the MPLS data plane are required, they MUST be
be inconsistent with the MPLS architecture [RFC3031], [RFC3032] consistent with the MPLS architecture [RFC3031] [RFC3032]
and [RFC5331]. [RFC5331].
4. Solutions meeting the requirements set out in this document MUST 4. Solutions meeting the requirements set out in this document MUST
be able to coexist with existing MPLS mechanisms. be able to coexist with existing MPLS mechanisms.
5. Subject to the constraints in these requirements a Network 5. Subject to the constraints in these requirements, a Network
Action solution MAY carry MNA information in-stack, post-stack Action solution MAY carry MNA information in-stack, post-stack,
or both in-stack and post-stack. or both in-stack and post-stack.
6. Solutions MUST NOT require an implementation to support in-stack 6. Solution specifications MUST NOT require an implementation to
ancillary data, unless the implementation chooses to support a support in-stack ancillary data, unless the implementation
network action that uses in-stack ancillary data. chooses to support an NA that uses in-stack ancillary data.
7. Solutions MUST NOT require an implementation to support post- 7. Solution specifications MUST NOT require an implementation to
stack ancillary data, unless the implementation chooses to support post-stack ancillary data, unless the implementation
support a network action that uses post-stack ancillary data. chooses to support an NA that uses post-stack ancillary data.
8. The design of any MNA solution MUST minimize the amount of 8. The design of any MNA solution MUST minimize the amount of
processing required to parse the label stack at an LSR. processing required to parse the label stack at an LSR.
9. Solutions MUST minimize any additions to the size of the MPLS 9. Solutions MUST minimize any additions to the size of the MPLS
label stack. label stack.
10. Solutions that increase the size of the MPLS label stack in a 10. Solution specifications that increase the size of the MPLS label
way that is not controlled by the ingress LER MUST discuss the stack in a way that is not controlled by the ingress LER MUST
consequences. discuss the consequences.
11. Solution specifications MUST discuss the ECMP consequences of 11. Solution specifications MUST discuss the ECMP consequences of
the design. the design.
12. A network action solution MUST NOT expose information to the 12. A Network Action solution MUST NOT expose information to the
LSRs that is not already exposed to the LER. LSRs that is not already exposed to the LER.
13. The design of any network action MUST NOT expose any information 13. The design of any NA MUST NOT expose any information that a user
that a user of any service using the LSP considers confidential of any service using the LSP considers confidential [RFC6973]
[RFC6973] [RFC3552]. [RFC3552].
14. Solution specifications MUST document any new security 14. Solution specifications MUST document any new security
considerations that they introduce. considerations that they introduce.
15. An MNA solution MUST allow MPLS packets carrying NAI and 15. An MNA solution MUST allow MPLS packets carrying NAI and
ancillary data (where it exists) to coexist with MPLS packets ancillary data (where it exists) to coexist with MPLS packets
that do not carry this information on the same LSP. that do not carry this information on the same LSP.
3.2. Requirements on the MNA Alert Mechanism 3.2. Requirements on the MNA Alert Mechanism
16. An MNA solution MUST define how a node determines whether NAIs 16. An MNA solution specification MUST define how a node determines
are present in the MPLS packet. whether NAIs are present in the MPLS packet.
17. Special Purpose Labels (SPLs) are a mechanism of last resort, and 17. Special Purpose Labels (SPLs) are a mechanism of last resort;
therefore an MNA solution that uses them MUST minimize the number therefore, an MNA solution specification that defines their use
of new SPLs that are allocated. MUST minimize the number of new SPLs that are allocated.
3.3. Requirements on Network Actions 3.3. Requirements on Network Actions
18. It is RECOMMENDED that an MNA specification support network 18. It is RECOMMENDED that an MNA solution include support for NAs
actions for private use (See Section 4.1 of [RFC8126]). for Private Use (see Section 4.1 of [RFC8126]).
19. Network action specifications MUST specify if the network action 19. Network Action solution specifications MUST define if the NA
needs to be processed as a part of the immediate forwarding needs to be processed as a part of the immediate forwarding
operation and whether MPLS packet mis-ordering is allowed to operation and whether MPLS packet misordering is allowed to occur
occur as a result of the time taken to process the network as a result of the time taken to process the NA.
action.
20. If a network action solution allows more than one scope for a 20. If a Network Action solution specification allows more than one
network action, it MUST provide a mechanism to specify the scope for an NA, it MUST define a mechanism to indicate the
precedence of the scopes or any combination of the scopes. precedence of the scopes or any combination of the scopes.
21. If a Network Action (NA) requires an NAI with in-stack ancillary 21. If a network action requires an NAI with in-stack ancillary data
data that needs to be imposed at an LSR on an LSP, then the that needs to be imposed at an LSR on an LSP, then the Network
network action solution specification MUST specify how this is Action solution MUST specify how this is achieved in all
achieved in all circumstances. circumstances.
22. If a network action requires an NAI with post-stack ancillary 22. If a network action requires an NAI with post-stack ancillary
data to be imposed at an LSR on an LSP, then the network action data to be imposed at an LSR on an LSP, then the Network Action
solution specification MUST specify how this is achieved in all solution specification MUST describe how this is achieved in all
circumstances. circumstances.
3.4. Requirements on Network Action Indicators 3.4. Requirements on Network Action Indicators
23. Insertion, parsing, processing and disposition of NAIs SHOULD 23. Insertion, parsing, processing, and disposition of NAIs SHOULD
make use of existing MPLS data plane operations. make use of existing MPLS data plane operations.
24. Without constraining the mechanism, an MNA solution MUST enable 24. Without constraining the mechanism, an MNA solution MUST enable
a node inserting or modifying NAIs to determine if the target of 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 the NAI, or any other LSR that may expose the NAI, can accept
and process an MPLS packet containing the NAI. and process an MPLS packet containing the NAI.
25. An NAI MUST NOT be imposed for delivery to a node unless it is 25. An NAI MUST NOT be imposed for delivery to a node unless it is
known that the node supports processing the NAI. known that the node supports processing the NAI.
26. The NAI design MUST support setting the scope of network 26. The NAI design MUST support setting the scope of network
actions. actions.
27. A given network action specification MUST specify which scope or 27. A given Network Action solution specification MUST define which
scopes are applicable to the associated NAI. scope or scopes are applicable to the associated NAI.
28. An MNA solution SHOULD support NAIs for both Point-to-Point 28. An MNA solution specification SHOULD define the support of NAIs
(P2P) and Point-to-Multipoint (P2MP) paths, but a specific NAI for both Point-to-Point (P2P) and Point-to-Multipoint (P2MP)
MAY be limited by the network action specification to only one paths, but the Network Action solution specification MAY limit a
or the other of these path types if there is a clear reason to specific NAI to only one of these path types if there is a clear
do so. reason to do so.
29. An MNA solution defining data plane mechanisms for NAIs MUST be 29. An MNA solution specification defining data plane mechanisms for
consistent across different control plane protocols. NAIs MUST be consistent across different control plane
protocols.
30. An MNA solution MUST allow the deployed MPLS control and 30. An MNA solution MUST allow the deployed MPLS control and
management planes to determine the ability of downstream LSRs to management planes to determine the ability of downstream LSRs to
accept and/or process a given NAI. accept and/or process a given NAI.
31. An MNA solution MUST allow indicators for multiple network 31. An MNA solution MUST allow indicators for multiple network
actions in the same MPLS actions in the same MPLS packet.
packet.
32. An MNA solution MUST NOT require an implementation to process 32. An MNA solution specification MUST NOT require an implementation
all NAIs present in an MPLS packet. to process all NAIs present in an MPLS packet.
33. NAIs MUST only be inserted at LSRs that push a label onto the 33. NAIs MUST only be inserted at LSRs that push a label onto the
stack, but can be processed by LSRs along the path of the LSP. stack, but they can be processed by LSRs along the path of the
Two examples of LSRs that push a label onto the stack are head LSP. Two examples of LSRs that push a label onto the stack are
end LSRs and points of local repair (PLRs). head-end LSRs and points of local repair (PLRs).
34. If an NA requires in-stack ancillary data, the NAI that 34. If a network action requires in-stack ancillary data, the NAI
indicates this NA MUST be present in the label stack. that indicates this network action MUST be present in the label
stack.
35. All NAIs MUST be encoded in a manner consistent with [RFC3031] 35. All NAIs MUST be encoded in a manner consistent with [RFC3031].
36. If there is post-stack ancillary data for an NAI that is present 36. 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 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 ancillary data without having to parse below the bottom of
the label stack. the label stack.
37. Any processing that removes an NAI from the label stack MUST 37. Any processing that removes an NAI from the label stack MUST
also remove all associated ancillary data from the MPLS packet also remove all associated ancillary data from the MPLS packet
unless the ancillary data is required by any remaining NAIs. unless the ancillary data is required by any remaining NAIs.
38. MNA solution specifications MUST request IANA to create 38. MNA solution specifications MUST request that IANA create
registries and make allocations from those registries for NAIs registries and make allocations from those registries for NAIs
as necessary to ensure unambiguous identification of as necessary to ensure unambiguous identification of
standardized NAs. An MNA solution MAY request IANA to reserve a standardized network actions. An MNA solution specification MAY
range of a registry for private use. request that IANA reserve a range of a registry for Private Use.
39. A network action solution specification MUST state where the 39. A Network Action solution specification MUST state where the
NAIs are to be placed in the MPLS packet, that is whether they NAIs are to be placed in the MPLS packet, that is whether they
are placed in-stack or post-stack. are placed in-stack or post-stack.
3.5. Requirements on Ancillary Data 3.5. Requirements on Ancillary Data
40. Network action specifications MUST specify whether ancillary 40. Network Action solution specifications MUST state whether
data is required to fulfil the action and whether it is in-stack ancillary data is required to fulfill the action and whether it
and/or post-stack. is in-stack and/or post-stack.
41. Network action specifications MUST specify if in-stack or post- 41. Network Action solution specifications MUST state if in-stack or
stack ancillary data that is already present in the MPLS packet post-stack ancillary data that is already present in the MPLS
MAY be rewritten by an LSR. packet MAY be rewritten by an LSR.
42. Solutions for in-stack ancillary data MUST be able to coexist 42. Solutions for in-stack ancillary data MUST be able to coexist
with and MUST NOT obsolete existing MPLS mechanisms. Such with and MUST NOT obsolete existing MPLS mechanisms. Such
solutions MUST be described in a Standards Track RFC. solutions MUST be described in a Standards Track RFC.
43. Network action solutions MUST take care to limit the quantity of 43. Network Action solutions MUST take care to limit the quantity of
in-stack ancillary data to the minimum amount required. in-stack ancillary data to the minimum amount required.
44. A network action solution SHOULD NOT use post-stack ancillary 44. A Network Action solution SHOULD NOT use post-stack ancillary
data unless the size of that ancillary data if it was inserted data unless the size of that ancillary data could prevent the
into the label stack could prevent the coexistence of the coexistence of the network action with other in-use MPLS network
network action with other in-use MPLS network functions. functions if it were inserted into the label stack.
45. The structure of the NAI and any associated ancillary data MUST 45. The structure of the NAI and any associated ancillary data MUST
enable skipping of unknown NAIs and any associated AD. enable skipping of unknown NAIs and any associated AD.
46. Any MNA solution specification MUST describe whether it can 46. Any MNA solution specification MUST describe whether the
coexist with existing post-stack data mechanisms (e.g., control solution can coexist with existing post-stack data mechanisms
words and the Generic Associated Channel Header), and if so how (e.g., control words and the Generic Associated Channel Header
this coexistence operates. [RFC5586]), and if so how coexistence operates.
47. An MNA solution MUST allow an LER that inserts ancillary data to 47. An MNA solution MUST allow an LER that inserts ancillary data to
determine whether each node that needs to process the ancillary determine whether each node that needs to process the ancillary
data can read the required distance into the MPLS packet at that data can read the required distance into the MPLS packet at that
node (compare with the mechanism in [RFC9088]). node (compare with the mechanism in [RFC9088]).
48. For scoped in-stack or post-stack ancillary data, any MNA 48. For scoped in-stack or post-stack ancillary data, any MNA
solution MUST allow an LER inserting NAIs whose network actions solution MUST allow an LER inserting NAIs whose network actions
make use of that ancillary data to determine if the NAI and make use of that ancillary data to determine if the NAI and
ancillary data will be processed by LSRs within the scope along ancillary data will be processed by LSRs within the scope along
the path. Such a solution may need to determine if LSRs along the path. Such a solution may need to determine if LSRs along
the path can process a specific type of AD implied by the NAI at the path can process a specific type of AD implied by the NAI at
the depth in the stack that it will be presented to the LSR. the depth in the stack that it will be presented to the LSR.
49. A mechanism MUST exist to notify an egress LER of the presence 49. A mechanism MUST exist to notify an egress LER of the presence
of ancillary data so that it can dispose of it appropriately. of ancillary data so that it can dispose of it appropriately.
50. In-stack ancillary data MUST only be inserted in conjunction 50. In-stack ancillary data MUST only be inserted in conjunction
with an operation conforming to [RFC3031]. with an operation conforming with [RFC3031].
51. Post-stack ancillary data MUST only be inserted in conjunction 51. Post-stack ancillary data MUST only be inserted in conjunction
with an operation conforming to [RFC3031]. with an operation conforming with [RFC3031].
52. Processing of ancillary data below a swapped label MAY include 52. Processing of ancillary data below a swapped label MAY include
rewriting the ancillary data. rewriting the ancillary data.
53. A network action solution that needs to change the size of the 53. If a Network Action solution needs to change the size of the
ancillary data MUST analyze the implications on MPLS packet ancillary data, its specification MUST analyze the implications
forwarding and specify how these are addressed. on MPLS packet forwarding and specify how these are addressed.
54. Not more than one standards track solution SHOULD be defined for 54. Not more than one Standards Track solution specification SHOULD
encoding in-stack ancillary data. be defined for encoding in-stack ancillary data.
55. Not more than one standards track solution SHOULD be defined for 55. Not more than one Standards Track solution specification SHOULD
encoding post-stack ancillary data. be defined for encoding post-stack ancillary data.
4. IANA Considerations 4. IANA Considerations
This document makes no request of IANA. This document has no IANA actions.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations 5. Security Considerations
Solutions designed according to the requirements in this document may Solutions designed according to the requirements in this document may
introduce new security considerations to MPLS, whose forwarding plane introduce new security considerations to MPLS, whose forwarding plane
on its own does not provide any built-in security mechanisms on its own does not provide any built-in security mechanisms
[RFC5920]. [RFC5920].
In particular, such solutions may embed information derived from the In particular, such solutions may embed information derived from the
MPLS payload in the MPLS headers. This may expose data that a user MPLS payload in the MPLS headers. This may expose data that a user
of the MPLS-based service might otherwise assume is opaque to the of the MPLS-based service might otherwise assume is opaque to the
MPLS network. Furthermore, an LSR may insert information into the MPLS network. Furthermore, an LSR may insert information into the
labeled packet such that the forwarding behavior is no longer purely labeled packet such that the forwarding behavior is no longer purely
a function of the top label or another label with forwarding context. a function of the top label or another label with forwarding context.
Instead, the forwarding behavior may be the result of a more complex Instead, the forwarding behavior may be the result of a more complex
heuristic. This creates an implicit trust relationship between the heuristic. This creates an implicit trust relationship between the
LSR whose forwarding behavior is being changed and the upstream LSR LSR whose forwarding behavior is being changed and the upstream LSR
inserting the data causing that change. inserting the data causing that change.
Several requirements above address some of these considerations. The Several requirements above address some of these considerations. The
MNA framework [I-D.ietf-mpls-mna-fwk] also provides security MNA framework [MNA-FRAMEWORK] also provides security considerations
considerations resulting from any extensions to the MPLS resulting from any extensions to the MPLS architecture, and these
architecture, and these SHOULD be taken together with the security SHOULD be taken together with the security considerations herein.
considerations herein.
Individual solution specifications meeting the requirements in this Individual solution specifications meeting the requirements in this
document MUST address any security considerations introduced by the document MUST address any security considerations introduced by the
MNA design. MNA design.
6. Acknowledgements 6. Acknowledgements
The authors gratefully acknowledge the contributions from Joel The authors gratefully acknowledge the contributions from Joel
Halpern, Greg Mirsky, Yingzhen Qu, Haoyu Song, Tarek Saad, Loa Halpern, Greg Mirsky, Yingzhen Qu, Haoyu Song, Tarek Saad, Loa
Andersson, Tony Li, Adrian Farrel, Jie Dong and Bruno Decraene, and Andersson, Tony Li, Adrian Farrel, Jie Dong, Bruno Decraene, and
participants in the MPLS working group who have provided comments. participants in the MPLS Working Group who have provided comments.
The authors also gratefully acknowledge the input of the members of The authors also gratefully acknowledge the input of the members of
the MPLS Open Design Team. the MPLS Open Design Team.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/rfc/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/rfc/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008, RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/rfc/rfc5331>. <https://www.rfc-editor.org/info/rfc5331>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-mpls-mna-fwk] [MNA-FRAMEWORK]
Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Network Actions (MNA) Framework", Work in Progress, Network Actions (MNA) Framework", Work in Progress,
Internet-Draft, draft-ietf-mpls-mna-fwk-08, 7 May 2024, Internet-Draft, draft-ietf-mpls-mna-fwk-10, 6 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls- <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-fwk-08>. mna-fwk-10>.
[I-D.ietf-mpls-mna-usecases] [MNA-USECASES]
Saad, T., Makhijani, K., Song, H., and G. Mirsky, "Use Saad, T., Makhijani, K., Song, H., and G. Mirsky, "Use
Cases for MPLS Network Action Indicators and MPLS Cases for MPLS Network Action Indicators and MPLS
Ancillary Data", Work in Progress, Internet-Draft, draft- Ancillary Data", Work in Progress, Internet-Draft, draft-
ietf-mpls-mna-usecases-07, 20 May 2024, ietf-mpls-mna-usecases-10, 20 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls- <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-usecases-07>. mna-usecases-10>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/rfc/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/rfc/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/rfc/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/rfc/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC9088] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., [RFC9088] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
and M. Bocci, "Signaling Entropy Label Capability and and M. Bocci, "Signaling Entropy Label Capability and
Entropy Readable Label Depth Using IS-IS", RFC 9088, Entropy Readable Label Depth Using IS-IS", RFC 9088,
DOI 10.17487/RFC9088, August 2021, DOI 10.17487/RFC9088, August 2021,
<https://www.rfc-editor.org/rfc/rfc9088>. <https://www.rfc-editor.org/info/rfc9088>.
Authors' Addresses Authors' Addresses
Matthew Bocci (editor) Matthew Bocci (editor)
Nokia Nokia
Email: matthew.bocci@nokia.com Email: matthew.bocci@nokia.com
Stewart Bryant Stewart Bryant
University of Surrey ISC University of Surrey ICS
Email: sb@stewartbryant.com Email: sb@stewartbryant.com
John Drake John Drake
Independent Independent
Email: je_drake@yahoo.com Email: je_drake@yahoo.com
 End of changes. 87 change blocks. 
216 lines changed or deleted 214 lines changed or added

This html diff was produced by rfcdiff 1.48.