Internet DRAFT - draft-ietf-mpls-mna-fwk
draft-ietf-mpls-mna-fwk
MPLS Working Group L. Andersson
Internet-Draft Huawei Technologies
Intended status: Informational S. Bryant
Expires: 27 July 2024 University of Surrey 5GIC
M. Bocci
Nokia
T. Li
Juniper Networks
24 January 2024
MPLS Network Actions Framework
draft-ietf-mpls-mna-fwk-06
Abstract
This document specifies an architectural framework for the MPLS
Network Actions (MNA) technologies. MNA technologies are used to
indicate actions for Label Switched Paths (LSPs) and/or MPLS packets
and to transfer data needed for these actions.
The document provides the foundation for the development of a common
set of network actions and information elements supporting additional
operational models and capabilities of MPLS networks. Some of these
actions are defined in existing MPLS specifications, while others
require extensions to existing specifications to meet the
requirements found in "Requirements for MPLS Network Actions".
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 27 July 2024.
Andersson, et al. Expires 27 July 2024 [Page 1]
Internet-Draft MNA Framework January 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Normative Definitions . . . . . . . . . . . . . . . . 4
1.2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . 4
2. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Partial Processing . . . . . . . . . . . . . . . . . . . 7
2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Readable Label Depth . . . . . . . . . . . . . . . . 8
2.4. State . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. The MNA Label . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Existing Base SPL . . . . . . . . . . . . . . . . . . 9
3.1.2. New Base SPL . . . . . . . . . . . . . . . . . . . . 9
3.1.3. New Extended SPL . . . . . . . . . . . . . . . . . . 9
3.1.4. User-Defined Label . . . . . . . . . . . . . . . . . 10
3.2. TC and TTL . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. TC and TTL retained . . . . . . . . . . . . . . . . . 10
3.2.2. TC and TTL Repurposed . . . . . . . . . . . . . . . . 10
3.3. Length of the NAS . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Last/Continuation Bits . . . . . . . . . . . . . . . 11
3.3.2. Length Field . . . . . . . . . . . . . . . . . . . . 11
3.4. Encoding of Scopes . . . . . . . . . . . . . . . . . . . 12
3.5. Encoding a Network Action . . . . . . . . . . . . . . . . 12
3.5.1. Bit Catalogs . . . . . . . . . . . . . . . . . . . . 12
3.5.2. Operation Codes . . . . . . . . . . . . . . . . . . . 12
3.6. Encoding of Post-Stack Data . . . . . . . . . . . . . . . 13
3.6.1. First Nibble Considerations . . . . . . . . . . . . . 13
4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Definition of a Network Action . . . . . . . . . . . . . . . 14
6. Management Considerations . . . . . . . . . . . . . . . . . . 15
Andersson, et al. Expires 27 July 2024 [Page 2]
Internet-Draft MNA Framework January 2024
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
This document specifies an architectural framework for the MPLS
Network Actions (MNA) technologies. MNA technologies are used to
indicate actions for Label Switched Paths (LSPs) and/or MPLS packets
and to transfer data needed for these actions.
The document provides the foundation for the development of a common
set of network actions and information elements supporting additional
operational models and capabilities of MPLS networks. Some of these
actions are defined in existing MPLS specifications, while others
require extensions to existing specifications to meet the
requirements found in [I-D.ietf-mpls-mna-requirements].
Forwarding actions are instructions to MPLS routers to apply
additional actions when forwarding a packet. These might include
load-balancing a packet given its entropy, whether or not to perform
fast reroute on a failure, and whether or not a packet has metadata
relevant to the forwarding decisions along the path.
This document generalizes the concept of "forwarding actions" into
"network actions" to include any action that an MPLS router is
requested to take on the packet. That includes any forwarding
action, but may include other operations (such as security functions,
OAM procedures, etc.) that are not directly related to forwarding of
the packet.
MNA technologies may use the Label, Traffic Class (TC), and Time to
Live (TTL) fields in an MPLS LSE for an alternative purpose.
1.1. Requirement 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. These words may also appear in this
document in lower case as plain English words, absent their normative
meanings.
Andersson, et al. Expires 27 July 2024 [Page 3]
Internet-Draft MNA Framework January 2024
Although this is an Informative document, these conventions are
applied to achieve clarity in the requirements that are presented.
1.2. Terminology
1.2.1. Normative Definitions
This document adopts the definitions of the following terms and
abbreviations from [I-D.ietf-mpls-mna-requirements] as normative:
"Network Action", "Network Action Indication (NAI)", "Ancillary Data
(AD)", and "Scope".
In addition, this document also defines the following terms:
* Network Action Sub-Stack (NAS): A set of related, contiguous Label
Stack Entries (LSEs) in the MPLS label stack for carrying
information related to network actions. The Label, TC, and TTL
values in the LSEs in the NAS may be redefined, but the meaning of
the S bit is unchanged.
* Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
contains a special label that indicates the start of the NAS.
1.2.2. Abbreviations
+==============+===============+==================================+
| Abbreviation | Meaning | Reference |
+==============+===============+==================================+
| AD | Ancillary | [I-D.ietf-mpls-mna-requirements] |
| | Data | |
+--------------+---------------+----------------------------------+
| bSPL | Base Special | [RFC9017] |
| | Purpose Label | |
+--------------+---------------+----------------------------------+
| ECMP | Equal Cost | |
| | Multipath | |
+--------------+---------------+----------------------------------+
| eSPL | Extended | [RFC9017] |
| | Special | |
| | Purpose Label | |
+--------------+---------------+----------------------------------+
| HBH | Hop by hop | In the MNA context, this |
| | | document. |
+--------------+---------------+----------------------------------+
| I2E | Ingress to | In the MNA context, this |
| | Egress | document. |
+--------------+---------------+----------------------------------+
| ISD | In-stack data | [I-D.ietf-mpls-mna-requirements] |
Andersson, et al. Expires 27 July 2024 [Page 4]
Internet-Draft MNA Framework January 2024
+--------------+---------------+----------------------------------+
| LSE | Label Stack | [RFC3032] |
| | Entry | |
+--------------+---------------+----------------------------------+
| MNA | MPLS Network | [I-D.ietf-mpls-mna-requirements] |
| | Actions | |
+--------------+---------------+----------------------------------+
| NAI | Network | [I-D.ietf-mpls-mna-requirements] |
| | Action | |
| | Indicator | |
+--------------+---------------+----------------------------------+
| NAS | Network | This document |
| | Action Sub- | |
| | Stack | |
+--------------+---------------+----------------------------------+
| PSD | Post-stack | [I-D.ietf-mpls-mna-requirements] |
| | data | and Section 3.6 |
+--------------+---------------+----------------------------------+
| RLD | Readable | This document |
| | Label Depth | |
+--------------+---------------+----------------------------------+
| SPL | Special | [RFC9017] |
| | Purpose Label | |
+--------------+---------------+----------------------------------+
Table 1: Abbreviations
2. Structure
An MNA solution specifies one or more actions to apply to an MPLS
packet. These actions and their parameters may be carried in sub-
stacks within the MPLS label stack and/or possibly post-stack data.
A solution must specify where in the label stack the network actions
sub-stacks occur, if and how frequently they should be replicated
within the label stack, and how the network action sub-stack and
post-stack data are encoded.
A network action sub-stack contains:
* Network Action Sub-Stack Indicator: The first LSE in the NAS
contains a label with special semantics, called the MNA label,
that is used to indicate the start of a network action sub-stack.
* Network Action Indicators: Optionally, a set of indicators that
describes the set of network actions. If the set of indicators is
not in the sub-stack, a solution could encode them in post-stack
data. A network action is said to be present if there is an
indicator in the packet that invokes the action.
Andersson, et al. Expires 27 July 2024 [Page 5]
Internet-Draft MNA Framework January 2024
* In-Stack Data: A set of zero or more LSEs that carry ancillary
data for the network actions that are present. Network action
indicators are not considered ancillary data.
Each network action present in the network action sub-stack may have
zero or more LSEs of in-stack data. The ordering of the in-stack
data LSEs corresponds to the ordering of the network action
indicators. The encoding of the in-stack data, if any, for a network
action must be specified in the document that defines the network
action.
Certain network actions may also specify that data is carried after
the label stack. This is called post-stack data. The encoding of
the post-stack data, if any, for a network action must be specified
in the document that defines the network action. If multiple network
actions are present and have post-stack data, the ordering of their
post-stack data corresponds to the ordering of the network action
indicators.
A solution must specify the order that network actions are to be
applied to the packet.
2.1. Scopes
A network action may need to be processed by every node along the
path, or some subset of the nodes along its path. Some of the scopes
that an action may have are:
* Hop-by-hop (HBH): Every node along the path will perform the
action.
* Ingress-to-Egress (I2E): Only the last node on the path will
perform the action.
* Select: Only specific nodes along the path will perform the
action.
If a solution supports the select scope, it must describe how it
specifies the set of nodes to perform the actions.
This framework does not place any constraints on the scope or the
ancillary data for a network action. Any network action may appear
in any scope or combination of scopes, may have no ancillary data,
and may require in-stack data, and/or post-stack data. Some
combinations may be sub-optimal, but this framework does not place
any limitations on an MNA solution. A specific MNA solution may
define such constraints.
Andersson, et al. Expires 27 July 2024 [Page 6]
Internet-Draft MNA Framework January 2024
2.2. Partial Processing
As described in [RFC3031], legacy devices that do not recognize the
MNA label will discard the packet if the top label is the MNA label.
Devices that do recognize the MNA label might not implement all of
the network actions that are present. A solution must specify how
unrecognized network actions that are present should be handled.
One alternative is that an implementation should stop processing
network actions when it encounters an unrecognized network action.
Subsequent present network actions would not be applied. The result
is dependent on the solution's order of operations.
Another alternative is that an implementation should drop any packet
that contains any unrecognized present network actions.
A third alternative is that an implementation should perform all
recognized present network actions, but ignore all unrecognized
present network actions.
Other alternatives may also be possible and should be specified by
the solution.
In some solutions, an indication may be provided in the packet or in
the action as to how the forwarder should proceed if it does not
recognize the action. Where an action needs to be processed at every
hop, it is recommended that care be taken not to construct an LSP
that traverses nodes that do not support that action. It is
recognised that in some circumstances it may not be possible to
construct an LSP that avoids such nodes, such as when a network is
re-converging following a failure or when IPFRR [RFC5714] is taking
place.
2.3. Signaling
A node that wishes to make use of MNA and apply network actions to a
packet must understand the nodes that the packet will transit and
whether or not the nodes support MNA and the network actions that are
to be invoked. These capabilities are presumed to be signaled by
protocols that are out-of-scope for this document and are presumed to
have per-network action granularity. If a solution requires
alternate signaling, it must specify so explicitly.
Andersson, et al. Expires 27 July 2024 [Page 7]
Internet-Draft MNA Framework January 2024
2.3.1. Readable Label Depth
[RFC8662] introduced the concept of Entropy Readable Label Depth
(ERLD). Readable Label Depth (RLD) is the same concept, but
generalized and not specifically associated with the Entropy Label
(EL) or MNA. Readable Label Depth is defined as the number of LSEs,
starting from the top of the stack, that a router can read in an
incoming MPLS packet with no performance impact.
ERLD is not redundant with respect to RLD because ERLD specifically
specifies a value of zero if a system does not support the Entropy
Label. Since a system could reasonably support MNA or other MPLS
functions and need to advertise an RLD value but not support the
Entropy Label, another advertised value is required.
A node that pushes an NAS onto the label stack is responsible for
ensuring that all nodes that are expected to process the NAS will
have the entire NAS within their RLD. A node SHOULD use signaling
(e.g., [RFC9088], [RFC9089]) to determine this.
Per [RFC8662], a node that does not support EL will advertise a value
of zero for its ERLD, so advertising ERLD alone does not suffice in
all cases. A node MAY advertise both ERLD and RLD.
RLD is advertised by an IGP MSD-Type value of (TBA) and MAY be
advertised as a Node MSD, Link MSD, or both.
An MNA node MUST use the RLD determined by selecting the first
advertised non-zero value from:
* The RLD advertised for the link.
* The RLD advertised for the node.
* The non-zero ERLD for the node.
2.4. State
A network action can affect the state stored in the network. This
implies that a packet may affect how subsequent packets are handled.
In particular, one packet may affect subsequent packets in the same
LSP.
Andersson, et al. Expires 27 July 2024 [Page 8]
Internet-Draft MNA Framework January 2024
3. Encoding
Several possible ways to encode NAIs have been proposed. In this
section, we enumerate the possibilities and some considerations for
the various alternatives. In this section, we enumerate the
possibilities and some considerations for the various alternatives.
When network actions are carried in the MPLS label stack, then
regardless of their type, they are represented by a set of LSEs
termed a network action sub-stack (NAS). An NAS consists of a
special label, optionally followed by LSEs that specify which network
actions are to be performed on the packet and the in-stack ancillary
data for each indicated network action. Different network actions
may be placed together in one NAS or may be carried in different sub-
stacks.
[I-D.ietf-mpls-mna-requirements] requires that a solution not add
unnecessary LSEs to the sub-stack (Section 3.1, requirement 9).
Accordingly, solutions should also make efficient use of the bits
within the sub-stack, as inefficient use of the bits could result in
the addition of unnecessary LSEs.
3.1. The MNA Label
The first LSE in a network action sub-stack contains a special label
that indicates a network action sub-stack. A solution has several
choices for this special label.
3.1.1. Existing Base SPL
A solution may reuse an existing Base SPL (bSPL). If it elects to do
so, it must explain how the usage is backward compatible, including
in the case where there is ISD.
If an existing inactive bSPL is selected and its usage would not be
backward compatible, then it must first be retired per [RFC7274] and
then reallocated.
3.1.2. New Base SPL
A solution may select a new bSPL.
3.1.3. New Extended SPL
A solution may select a new eSPL. If it elects to do so, it must
address the requirement for the minimal number of LSEs.
Andersson, et al. Expires 27 July 2024 [Page 9]
Internet-Draft MNA Framework January 2024
3.1.4. User-Defined Label
A solution may allow the network operator to define the label that
indicates the network action sub-stack. This creates management
overhead for the network operator to coordinate the use of this label
across all nodes on the path using management or signaling protocols.
The user-defined label could be network-wide or LSP-specific. If a
solution elects to use a user-defined label, the solution should
justify this overhead.
3.2. TC and TTL
In the first LSE of the network action sub-stack, only the 20 bits of
Label Value and the Bottom of Stack bit are significant for MNA
purposes; the TC field (3 bits) and the TTL (8 bits) are not used.
This could leave 11 bits that could be used for MNA purposes.
3.2.1. TC and TTL retained
If the solution elects to retain the TC and TTL fields, then the
first LSE of the network action sub-stack would appear as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label value, 20 bits
TC: Traffic Class, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time To Live
Further LSEs would be needed to encode NAIs. If a solution elects to
retain these fields, it must address the requirement for the minimal
number of LSEs.
3.2.2. TC and TTL Repurposed
If the solution elects to reuse the TC and TTL fields, then the first
LSE of the network action sub-stack would appear as:
Andersson, et al. Expires 27 July 2024 [Page 10]
Internet-Draft MNA Framework January 2024
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |x x x|S|x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label value, 20 bits
x: Bit available for use in solution definition
S: Bottom of Stack, 1 bit
The solution may use more LSEs to contain NAIs. If a solution elects
to use more LSEs it must address the requirement for the minimal
number of LSEs.
3.3. Length of the NAS
A solution must have a mechanism (such as an indication of the length
of the NAS) to enable an implementation to find the end of the NAS.
This must be easily processed even by implementations that do not
understand the full contents of the NAS. Two options are described
below, other solutions may be possible.
3.3.1. Last/Continuation Bits
A solution may use a bit per LSE to indicate whether the NAS
continues into the next LSE or not. The bit may indicate
continuation by being set or by being clear. The overhead of this
approach is one bit per LSE and has the advantage that it can
effectively encode an arbitrarily sized NAS. This approach is
efficient if the NAS is small.
3.3.2. Length Field
A solution may opt to have a fixed size length field at a fixed
location within the NAS. The fixed size of the length field may not
be large enough to support all possible NAS contents. This approach
may be more efficient if the NAS is longer but not longer than can be
described by the length field.
Advice from hardware designers advocates a length field as this
minimizes branching in the logic.
Andersson, et al. Expires 27 July 2024 [Page 11]
Internet-Draft MNA Framework January 2024
3.4. Encoding of Scopes
A solution may choose to explicitly encode the scope of the actions
contained in a network action sub-stack. A solution may also choose
to have the scope encoded implicitly, based on the actions present in
the network action sub-stack. This choice may have performance
implications as an implementation might have to parse the network
actions that are present in a network action sub-stack only to
discover that there are no actions for it to perform.
Solutions need to consider the order of scoped NAIs and their
associated AD within individual sub-stacks and the order of per-scope
sub-stacks so that network actions and the AD can be most readily
found and not need be processed by nodes that are not required to
handle those actions.
3.5. Encoding a Network Action
Two options for encoding NAIs are described below, other solutions
may be possible. Any solution should allow the encoding of an
arbitrary number of NAIs.
3.5.1. Bit Catalogs
A solution may opt to encode the set of network actions as a list of
bits, sometimes known as a catalog. The solution must provide a
mechanism to determine how many LSEs are devoted to the catalog when
the NAIs are carried in-stack. A set bit in the catalog would
indicate that the corresponding network action is present.
Catalogs are efficient if the number of present network actions is
relatively high and if the size of the necessary catalog is small.
For example, if the first 16 actions are all present, a catalog can
encode this in 16 bits. However, if the number of possible actions
is large, then a catalog can become inefficient. Selecting only one
action that is the 256th action would require a catalog of 256 bits,
which would require more than one LSE when the NAIs are carried in-
stack.
A solution may include a bit remapping mechanism so that a given
domain may optimize for its commonly used actions.
3.5.2. Operation Codes
A solution may opt to encode the set of present network actions as a
list of operation codes (opcodes). Each opcode is a fixed number of
bits. The size of the opcode bounds the number of network actions
that the solution can support.
Andersson, et al. Expires 27 July 2024 [Page 12]
Internet-Draft MNA Framework January 2024
Opcodes are efficient if there are only one or two active network
actions. For example, if an opcode is 8 bits, then two active
network actions could be encoded in 16 bits. However, if 16 actions
are required, then opcodes would consume 128 bits. Opcodes are
efficient at encoding a large number of possible actions. If only
the 256th action is to be selected, that still requires 8 bits.
3.6. Encoding of Post-Stack Data
A solution may carry some NAI and AD as PSD. For ease of parsing,
all AD should be co-located with its NAI.
If there are multiple instances of post-stack data, they should occur
in the same order as their relevant network action sub-stacks and
then in the same order as their relevant network actions occur within
the network action sub-stacks.
3.6.1. First Nibble Considerations
The first nibble after the label stack has been used to convey
information in certain cases [RFC4385]. A consolidated view of first
nibble uses is provided in [I-D.ietf-mpls-1stnibble].
For example, in [RFC4928] this nibble is investigated to find out if
it has the value "4" or "6". If it is not, it is assumed that the
packet payload is not IPv4 or IPv6, and Equal Cost Multipath (ECMP)
is not performed.
It should be noted that this is an inexact method. For example, an
Ethernet Pseudowire without a control word might have "4" or "6" in
the first nibble and thus will be ECMP'ed.
Nevertheless, the method is implemented and deployed, it is used
today and will be for the foreseeable future.
The use of the first nibble for BIER is specified in [RFC8296]. BIER
sets the first nibble to 5. The same is true for a BIER payload as
for any use of the first nibble: it is not possible to conclude that
the payload is BIER even if the first nibble is set to 5 because an
Ethernet pseudowire without a control word might begin with a 5.
However, the BIER approach meets the design goal of [RFC8296] to
determine that the payload is IPv4, IPv6 or a pseudowire using a
control word.
[RFC4385] allocates 0b0000 for the pseudowire control word and 0b0001
as the control word for the pseudowire Associated Channel Header
(ACH).
Andersson, et al. Expires 27 July 2024 [Page 13]
Internet-Draft MNA Framework January 2024
A PSD solution should specify the contents of the first nibble, the
actions to be taken for the value, and the interaction with post-
stack data used concurrently by other MPLS applications.
4. Semantics
For MNA to be consistent across implementations and predictable in
operational environments, its semantics need to be entirely
predictable. An MNA solution MUST specify a deterministic order for
processing each of the Network Actions in a packet. Each network
action must specify how it interacts with all other previously
defined network actions. Private network actions MUST be included in
the ordering of network actions, but the interactions of private
actions with other actions are outside of the scope of this document.
5. Definition of a Network Action
Network actions should be defined in a document and must contain:
* Name: The name of the network action.
* Network Action Indicator: The bit position or opcode that
indicates that the network action is active.
* Scope: The document should specify which nodes should perform the
network action as described in Section 2.1.
* State: The document should specify if the network action can
modify state in the network, and if so, the state that may be
modified and its side effects.
* Required/Optional: The document should specify whether a node is
required to perform the network action.
* In-Stack Data: The number of LSEs of in-stack data, if any, and
its encoding. If this is of a variable length, then the solution
must specify how an implementation can determine this length
without implementing the network action.
* Post-Stack Data: The encoding of post-stack data, if any. If this
is of a variable length, then the solution must specify how an
implementation can determine this length without implementing the
network action.
A solution should create an IANA registry for network actions.
Andersson, et al. Expires 27 July 2024 [Page 14]
Internet-Draft MNA Framework January 2024
6. Management Considerations
Network operators will need to be cognizant of which network actions
are supported by which nodes and will need to ensure that this is
signaled. Some solutions may require network-wide configuration to
synchronize the use of the labels that indicate the start of an NAS.
Solution documents must make clear what management considerations
apply to the solutions they are describing. Solutions documents must
describe mechanisms for performing network diagnostics in the
presence of MNAs.
7. Security Considerations
An analysis of the security of MPLS systems is provided in [RFC5920],
which also notes that the MPLS forwarding plane has no built-in
security mechanisms.
Central to the security of MPLS networks is operational security of
the network; something that operators of MPLS networks are well
versed in. The deployment of link-level security (e.g., [MACsec])
prevents the covert acquisition of the label stack for an attack.
This is particularly important in the case of a network deploying
MNA, because the MNA information may be sensitive. Thus the
confidentiality and authentication achieved through the use of link-
level security is particularly advantageous.
Some additional proposals to add encryption to the MPLS forwarding
plane have been suggested [I-D.ietf-mpls-opportunistic-encrypt], but
no mechanisms have been agreed upon at the time of publication of
this document. [I-D.ietf-mpls-opportunistic-encrypt] offers hop-by-
hop security that encrypts the label stack and is functionally
equivalent to that provided by [MACsec]. Alternatively, it also
offers end-to-end encryption of the MPLS payload with no
cryptographic integrity protection of the MPLS headers.
Particular care would be needed when introducing any end-to-end
security mechanism to allow an in-stack MNA solution that needed to
employ on-path modification of the MNA data, or where post-stack MNA
data needed to be examined on-path.
A cornerstone of MPLS security is to protect the network from
processing MPLS labels originated outside the network.
Operators have considerable experience in excluding raw MPLS-encoded
packets at the network boundaries for example, by excluding all MPLS
packets and all packets that are revealed to be carrying an MPLS
packet as the payload of IP tunnels. Where such packets are accepted
into an MPLS network from an untrusted third party, non-MPLS packets
Andersson, et al. Expires 27 July 2024 [Page 15]
Internet-Draft MNA Framework January 2024
are immediately encapsulated in an MPLS label stack specified by the
MPLS network operator and raw-MPLS packets have additional label
stack entries imported as specified by the MPLS network operator.
Thus, it is difficult for an attacker to pass a raw MPLS-encoded
packet into a network or to present any instructions to the network
forwarding system.
Within a single well-managed domain, an adjacent domain may be
considered to be trusted provided that it is sufficiently shielded
from third-party traffic ingress and third-party traffic observation.
In such a situation, no new security vulnerabilities are introduced
by MNA.
In some inter-domain applications (including carrier's carrier) where
a first network's MPLS traffic is encapsulated directly over a second
MPLS network by simply pushing additional MPLS LSEs, the contents of
the first network's payload and label stack may be visible to the
forwarders in the second network. Historically this has been benign,
and indeed useful for ECMP. However, if the first network's traffic
has MNA information this may be exposed to MNA-capable forwarders
causing unpredictable behaviour or modification of the customer MPLS
label stack or MPLS payload. This is an increased vulnerability
introduced by MNA that SHOULD be addressed in any MNA solution.
Several mitigations are available to an operator:
a) Reject all incoming packets containing MNA information that do not
come from a trusted network. Note that it may be acceptable to
accept and process MNA information from a trusted network.
b) Fully encapsulate the inbound packet in a new additional MPLS
label stack such that the forwarder finds a BoS bit imposed by the
carrier network and only finds MNA information added by the carrier
network.
A mitigation that we reject as unsafe is having the ingress LSR push
sufficient additional labels such that any MNA information received
in packets entering the network from a third-party network is made
inaccessible due to it being below the RLD. This is unsafe in the
presence of an overly conservative RLD value which can result in the
third-party MNA information becoming visible to and acted on by an
MNA forwarder in the carrier network.
Andersson, et al. Expires 27 July 2024 [Page 16]
Internet-Draft MNA Framework January 2024
8. IANA Considerations
This document requests that IANA allocate a code point from the "IGP
MSD-Types" registry in the "Interior Gateway Protocol (IGP)
Parameters" namespace for "Readable Label Depth", referencing this
document.
9. Acknowledgements
This document is the result of work started in MPLS Open Design Team,
with participation by the MPLS, PALS, and DETNET working groups.
The authors would like to thank Adrian Farrel for his contributions
and to John Drake and Jie Dong for their comments.
10. References
10.1. Normative References
[I-D.ietf-mpls-mna-requirements]
Bocci, M., Bryant, S., and J. Drake, "Requirements for
Solutions that Support MPLS Network Actions", Work in
Progress, Internet-Draft, draft-ietf-mpls-mna-
requirements-08, 11 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-requirements-08>.
[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/info/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/info/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/info/rfc3032>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
Andersson, et al. Expires 27 July 2024 [Page 17]
Internet-Draft MNA Framework January 2024
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special-Purpose MPLS Labels", RFC 7274,
DOI 10.17487/RFC7274, June 2014,
<https://www.rfc-editor.org/info/rfc7274>.
[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/info/rfc8174>.
[RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special-
Purpose Label Terminology", RFC 9017,
DOI 10.17487/RFC9017, April 2021,
<https://www.rfc-editor.org/info/rfc9017>.
10.2. Informative References
[I-D.ietf-mpls-opportunistic-encrypt]
Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
Networks", Work in Progress, Internet-Draft, draft-ietf-
mpls-opportunistic-encrypt-03, 28 March 2017,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
opportunistic-encrypt-03>.
[I-D.ietf-mpls-1stnibble]
Kompella, K., Bryant, S., Bocci, M., Mirsky, G.,
Andersson, L., and J. Dong, "IANA Registry for the First
Nibble Following a Label Stack", Work in Progress,
Internet-Draft, draft-ietf-mpls-1stnibble-02, 5 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
1stnibble-02>.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128,
RFC 4928, DOI 10.17487/RFC4928, June 2007,
<https://www.rfc-editor.org/info/rfc4928>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>.
Andersson, et al. Expires 27 July 2024 [Page 18]
Internet-Draft MNA Framework January 2024
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
Shakir, R., and J. Tantsura, "Entropy Label for Source
Packet Routing in Networking (SPRING) Tunnels", RFC 8662,
DOI 10.17487/RFC8662, December 2019,
<https://www.rfc-editor.org/info/rfc8662>.
[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/info/rfc9088>.
[RFC9089] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
and M. Bocci, "Signaling Entropy Label Capability and
Entropy Readable Label Depth Using OSPF", RFC 9089,
DOI 10.17487/RFC9089, August 2021,
<https://www.rfc-editor.org/info/rfc9089>.
[MACsec] IEEE Computer Society, "IEEE 802.1AE Media Access Control
(MAC) Security", August 2006.
Authors' Addresses
Loa Andersson
Huawei Technologies
Email: loa@pi.nu
Stewart Bryant
University of Surrey 5GIC
Email: sb@stewartbryant.com
Matthew Bocci
Nokia
Email: matthew.bocci@nokia.com
Tony Li
Juniper Networks
Email: tony.li@tony.li
Andersson, et al. Expires 27 July 2024 [Page 19]
