rfc9613v4.txt   rfc9613.txt 
Internet Engineering Task Force (IETF) M. Bocci, Ed. Internet Engineering Task Force (IETF) M. Bocci, Ed.
Request for Comments: 9613 Nokia Request for Comments: 9613 Nokia
Category: Informational S. Bryant Category: Informational S. Bryant
ISSN: 2070-1721 University of Surrey ISC ISSN: 2070-1721 University of Surrey ICS
J. Drake J. Drake
Independent Independent
August 2024 August 2024
Requirements for Solutions that Support MPLS Network Actions (MNAs) Requirements for Solutions that Support MPLS Network Actions (MNAs)
Abstract Abstract
This document specifies requirements for the development of MPLS This document specifies requirements for the development of MPLS
Network Actions (MNAs) that affect the forwarding or other processing Network Actions (MNAs) that affect the forwarding or other processing
skipping to change at line 104 skipping to change at line 104
Equivalence Class (FEC). Equivalence Class (FEC).
This document specifies the requirements for solutions that encode This document specifies the requirements for solutions that encode
MNAs and ancillary data that may be needed to process those actions. MNAs and ancillary data that may be needed to process those actions.
These requirements are informed by a number of proposals to allow These requirements are informed by a number of proposals to allow
additions to the MPLS information in the labeled packet so that such additions to the MPLS information in the labeled packet so that such
actions can be performed, either by a transit or terminating LSR. It actions can be performed, either by a transit or terminating LSR. It
is anticipated that these will result in two types of solution is anticipated that these will result in two types of solution
specifications: specifications:
MNA solution: A specification that describes a common protocol that MNA solution specification: A specification that describes a common
supports all forms of MNAs. protocol that supports all forms of MNAs.
Network Action solutions: One or more specifications describing the Network Action solution specifications: One or more specifications
protocol extensions for the MNA solution to address a use case. describing the protocol extensions for the MNA solution to address
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 (NA): An operation to be performed on an MPLS packet Network Action (NA): An operation to be performed on an MPLS packet
or as a consequence of an MPLS packet being processed by a router. or as a consequence of an MPLS packet being processed by a router.
An NA may affect router state or MPLS packet forwarding, or it may An NA may affect router state or MPLS packet forwarding, or it may
skipping to change at line 181 skipping to change at line 182
provider edges (PEs), and is not part of these requirements. Since provider edges (PEs), and is not part of these requirements. Since
in-stack ancillary data and per-hop post-stack data need to be parsed in-stack ancillary data and per-hop post-stack data need to be parsed
and processed by transit LSRs along the Label Switched Path (LSP), and processed by transit LSRs along the Label Switched Path (LSP),
requirements on the size of such ancillary data are documented in the requirements on the size of such ancillary data are documented in the
following sections. following sections.
3.1. General Requirements 3.1. General Requirements
1. Any solutions MUST maintain the properties of extensibility, 1. Any solutions MUST maintain the properties of extensibility,
flexibility, and efficiency inherent in the split between the flexibility, and efficiency inherent in the split between the
control plane context and simple data plane used in MPLS and control plane context and simple data plane used in MPLS and the
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] [RFC5331]. [RFC3032] [RFC5331].
3. If extensions to the MPLS data plane are required, they MUST be 3. If extensions to the MPLS data plane are required, they MUST be
consistent with the MPLS architecture [RFC3031] [RFC3032] consistent with the MPLS architecture [RFC3031] [RFC3032]
[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 an support in-stack ancillary data, unless the implementation
NA 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 an NA 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 NA MUST NOT expose any information that a user 13. The design of any NA MUST NOT expose any information that a user
of any service using the LSP considers confidential [RFC6973] of any service using the LSP considers confidential [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; 17. Special Purpose Labels (SPLs) are a mechanism of last resort;
therefore, an MNA solution that uses them MUST minimize the therefore, an MNA solution specification that defines their use
number 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 solution support NAs for Private 18. It is RECOMMENDED that an MNA solution include support for NAs
Use (see Section 4.1 of [RFC8126]). for Private Use (see Section 4.1 of [RFC8126]).
19. Network Action solutions MUST specify if the NA needs to be 19. Network Action solution specifications MUST define if the NA
processed as a part of the immediate forwarding operation and needs to be processed as a part of the immediate forwarding
whether MPLS packet misordering is allowed to occur as a result operation and whether MPLS packet misordering is allowed to occur
of the time taken to process the NA. as a result of the time taken to process the NA.
20. If a Network Action solution allows more than one scope for an 20. If a Network Action solution specification allows more than one
NA, it MUST provide a mechanism to specify the precedence of the scope for an NA, it MUST define a mechanism to indicate the
scopes or any combination of the scopes. precedence of the scopes or any combination of the scopes.
21. If a network action requires an NAI with in-stack ancillary data 21. If a network action requires an NAI with in-stack ancillary data
that needs to be imposed at an LSR on an LSP, then the Network that needs to be imposed at an LSR on an LSP, then the Network
Action solution MUST specify how this is achieved in all Action solution MUST specify how this is 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 MUST specify how this is achieved in all circumstances. solution specification MUST describe how this is achieved in all
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 solution 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 the Network for both Point-to-Point (P2P) and Point-to-Multipoint (P2MP)
Action solution MAY limit a specific NAI to only one of these paths, but the Network Action solution specification MAY limit a
path types if there is a clear reason to do so. specific NAI to only one of these path types if there is a clear
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 packet. actions in the same MPLS 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 they can be processed by LSRs along the path of the stack, but they can be processed by LSRs along the path of the
LSP. Two examples of LSRs that push a label onto the stack are LSP. Two examples of LSRs that push a label onto the stack are
head-end LSRs and points of local repair (PLRs). head-end LSRs and points of local repair (PLRs).
34. If a network action requires in-stack ancillary data, the NAI 34. If a network action requires in-stack ancillary data, the NAI
that indicates this network action MUST be present in the label that indicates this network action MUST be present in the label
stack. stack.
skipping to change at line 323 skipping to change at line 327
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 solutions MUST request that IANA create registries and make 38. MNA solution specifications MUST request that IANA create
allocations from those registries for NAIs as necessary to registries and make allocations from those registries for NAIs
ensure unambiguous identification of standardized network as necessary to ensure unambiguous identification of
actions. An MNA solution MAY request that IANA reserve a range standardized network actions. An MNA solution specification MAY
of a registry for Private Use. request that IANA reserve a range of a registry for Private Use.
39. A Network Action solution MUST state where the NAIs are to be 39. A Network Action solution specification MUST state where the
placed in the MPLS packet, that is whether they are placed in- NAIs are to be placed in the MPLS packet, that is whether they
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 solutions MUST specify whether ancillary data is 40. Network Action solution specifications MUST state whether
required to fulfill the action and whether it is in-stack and/or ancillary data is required to fulfill the action and whether it
post-stack. is in-stack and/or post-stack.
41. Network Action solutions MUST specify if in-stack or post-stack 41. Network Action solution specifications MUST state if in-stack or
ancillary data that is already present in the MPLS packet MAY be post-stack ancillary data that is already present in the MPLS
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 could prevent the data unless the size of that ancillary data could prevent the
coexistence of the network action with other in-use MPLS network coexistence of the network action with other in-use MPLS network
functions if it were inserted into the label stack. 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 MUST describe whether it can coexist with 46. Any MNA solution specification MUST describe whether the
existing post-stack data mechanisms (e.g., control words and the solution can coexist with existing post-stack data mechanisms
Generic Associated Channel Header), and if so how coexistence (e.g., control words and the Generic Associated Channel Header
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
skipping to change at line 388 skipping to change at line 392
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 with [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 with [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 has no IANA actions. This document has no IANA actions.
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
skipping to change at line 477 skipping to change at line 481
[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/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[MNA-FRAMEWORK] [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-09, 19 June 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-09>. mna-fwk-10>.
[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-10, 20 June 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-10>. 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/info/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/info/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/info/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.,
skipping to change at line 522 skipping to change at line 531
DOI 10.17487/RFC9088, August 2021, DOI 10.17487/RFC9088, August 2021,
<https://www.rfc-editor.org/info/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. 29 change blocks. 
68 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.48.