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