Stateless MNA-based Egress Protection (SMEP)
draft-ihle-mpls-mna-stateless-egress-protection-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Fabian Ihle , Michael Menth | ||
| Last updated | 2024-09-24 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ihle-mpls-mna-stateless-egress-protection-00
Multiprotocol Label Switching F. Ihle
Internet-Draft M. Menth
Intended status: Standards Track University of Tuebingen
Expires: 28 March 2025 24 September 2024
Stateless MNA-based Egress Protection (SMEP)
draft-ihle-mpls-mna-stateless-egress-protection-00
Abstract
The MPLS Network Action (MNA) framework provides a general mechanism
for the encoding and processing of network actions and their data.
The MPLS Egress Protection Framework specifies a fast reroute
framework for protecting IP/MPLS services. To that, end bypass
tunnels have to be signaled to the Point of Local Repair (PLR).
Further, the PLR must maintain the bypass forwarding state on a per-
transport-tunnel basis.
This document defines the encoding for the Stateless MNA-based Egress
Protection (SMEP) network action. The SMEP network action protects
egress routers by providing an alternative MPLS egress label in-
stack. SMEP does not require a bypass forwarding state in PLRs.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://uni-tue-
kn.github.io/mpls-mna-stateless-egress-protection/draft-ihle-mpls-
mna-stateless-egress-protection.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-ihle-
mpls-mna-stateless-egress-protection/.
Discussion of this document takes place on the Multiprotocol Label
Switching Working Group mailing list (mailto:mpls@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/mpls/.
Subscribe at https://www.ietf.org/mailman/listinfo/mpls/.
Source for this draft and an issue tracker can be found at
https://github.com/uni-tue-kn/mpls-mna-stateless-egress-protection.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Ihle & Menth Expires 28 March 2025 [Page 1]
Internet-Draft SMEP September 2024
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 28 March 2025.
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 4
2. MPLS Network Action for Stateless Egress Protection . . . . . 4
2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 5
3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Ihle & Menth Expires 28 March 2025 [Page 2]
Internet-Draft SMEP September 2024
1. Introduction
The MPLS egress protection framework in [RFC8679] establishes bypass
tunnels for egress routers on an egress failure, i.e., on a node or a
link failure. This is referred to as egress protection. The
protection mechanism relies on a Point of Local Repair (PLR) to
perform local failure detection and local repair. Typically, this
PLR is the penultimate router. When an egress failure occurs,
packets are rerouted to an alternative egress router. The PLR node
maintains the bypass forwarding state, which is a mapping of specific
labels to bypass tunnels. The bypass tunnels are signaled using
existing mechanisms, i.e., via an IGP, or topology-driven label
distribution protocols such as LDP.
With the MPLS Network Action (MNA) framework, network actions are
encoded in the MPLS stack. [I-D.ietf-mpls-mna-hdr] defines the
encoding of such network actions and their data in the MPLS stack.
These network actions are processed by all nodes on a path (hop-by-
hop), by only selected nodes, or on an ingress-to-egress basis.
This document defines the Stateless MNA-based Egress Protection
(SMEP) network action. With SMEP, egress bypass tunnels are carried
in a network action in the MPLS stack. The egress bypass tunnel is
indicated by one or multiple alternative MPLS forwarding labels in-
stack. We call those labels Bypass MPLS Labels (BML). The ingress
router pushes the MPLS stack containing the SMEP network action. On
an egress failure, the BML in the network action is used to protect
the egress tunnel. The PLR node is required to install the MPLS
forwarding entries for the bypass tunnels using the BML. Besides
that, no signaling between the egress node / the protector, and the
PLR is required. The PLR is not required to maintain the state of
bypass tunnel mappings.
The egress protection framework defined in [RFC8679] is
comprehensive. It provides a mechanism for rerouting traffic in the
event of an egress failure, and explains how rerouted services and
their associated context can be restored. SMEP provides an
alternative to the rerouting mechanism defined for the PLR, allowing
the PLR to be stateless. Thus, the PLR does not need to maintain a
table that maps transport tunnels to backup paths. Likewise, the PLR
is not involved in the signaling of such information. Instead, this
information is supplied from the ingress to the PLR in the network
action. Signaling is only needed between ingress, egress, and the
protector, but not with the PLR anymore. Details of the signaling
are not contained in this draft. The general concepts and mechanisms
described in [RFC8679] still apply.
Ihle & Menth Expires 28 March 2025 [Page 3]
Internet-Draft SMEP September 2024
1.1. Terminology
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.
1.1.1. Abbreviations
This document makes use of the terms defined in [RFC8679] and in
[I-D.ietf-mpls-mna-hdr].
Further abbreviations used in this document:
+==============+=====================+===============+
| Abbreviation | Meaning | Reference |
+==============+=====================+===============+
| BML | BML | This document |
+--------------+---------------------+---------------+
| SMEP | Stateless MNA-based | This document |
| | Egress Protection | |
+--------------+---------------------+---------------+
Table 1: Abbreviations.
2. MPLS Network Action for Stateless Egress Protection
In this section, we describe the encoding of SMEP and the processing
of SMEP in an LSR.
2.1. Encoding
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opcode=SMEP | Bypass MPLS Label (BML) |S|U| BML |NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MNA for Stateless Egress Protection.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opcode=SMEP | Bypass MPLS Label (BML) |S|U| BML |NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|00 Bypass MPLS Label (BML) |S| Data=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ihle & Menth Expires 28 March 2025 [Page 4]
Internet-Draft SMEP September 2024
Figure 2: MNA for Stateless Egress Protection using a list of
bypass labels.
The network action for stateless MNA-based egress protection is
encoded as follows:
* Network Action Indication: The SMEP network action is indicated by
opcode TBA1.
* Format: The SMEP network action MUST be encoded using an Format C
LSE as defined in [I-D.ietf-mpls-mna-hdr], see Figure 1.
Optionally, a list of BMLs MAY be carried as Format D LSE, see
Figure 2.
* Scope: The SMEP network action is only valid in the select scope.
* Ancillary Data: The SMEP network action requires 20 bits of in-
stack ancillary data to encode the BML. The most-significant 16
bits of the BML are located in the first data field of an Format C
LSE. The least-significant 4 bits are located in the second
datafield of an Format C LSE. If Format D LSEs are provided, the
BML is encoded in the least-significant bits of the first data
field of an Format D LSE. The two most-significant bits of the
first data field, and the 8 bits of the second data field MUST be
set to zero. No post-stack data is required.
2.2. Processing
The ingress LER which pushes an MPLS label stack onto a packet
includes the BML in a network action. The BML encodes the bypass
tunnel to an alternative egress router. The SMEP network action MUST
be placed in the MPLS stack such that the PLR (Point of Local
Repair), i.e., the penultimate node, is able to process the network
action. This means that the SMEP network action is only processed by
the penultimate node using the select scope. On an egress node
failure or an egress link failure, the penultimate node MUST use the
BML to route traffic to an alternative egress router. To that end,
the PLR pushes the BML from the Format C and D LSEs to the MPLS stack
and pops the incoming label. A list of BMLs MAY be provided as
Format D LSEs to encode a bypass tunnel constructed by Segment
Routing.
Ihle & Menth Expires 28 March 2025 [Page 5]
Internet-Draft SMEP September 2024
3. Example
A simple example topology using MNA-based egress protection with an
SR bypass tunnel is shown in Figure 3. Labels A and B are used to
forward to the penultimate router. From here, one path is available
to the egress node, and one path to the protector. Label C is used
to route to the egress node, and labels C' and C'' are used to route
to the protector. If the egress link or router C fails, the PLR can
use the bypass tunnel of router C' and C''. The MPLS stack pushed by
the ingress LER that encodes this functionality for the example
topology is shown in Figure 4. The Network Action Sub-Stack (NAS)
for SMEP contains an Format A LSE to indicate the MNA sub-stack and
an Format B LSE. This is required by [I-D.ietf-mpls-mna-hdr]. The
Format B LSE can contain arbitrary network actions.
In the example, LSR A and B pop the labels A and B. On an egress
failure, the PLR pops the incoming label C, and the NAS, and pushes
the list of BMLs onto the stack. The label stack after SMEP is
applied is shown in Figure 5.
/--C'-- LSR ---C''--- egress C''
/ C'
LSR
Ingress ───A─── LSR ───B─── B ───C─── egress C
LER A (PLR)
Figure 3: Example network topology with protected egress routers.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-Label = A | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-Label = B | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-Label = C | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA-Label=bSPL (TBA) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode = *| Data |R|IHS|S|U| NASL=2|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opcode = SMEP| Bypass MPLS Label (BML) = C' |S|U| BML |NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|00 Bypass MPLS Label (BML) = C''|S| Data=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ihle & Menth Expires 28 March 2025 [Page 6]
Internet-Draft SMEP September 2024
Figure 4: Example MPLS stack pushed by the ingress LER for above
topology.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-Label = C' | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-Label = C'' | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example MPLS stack after SMEP is applied.
4. Security Considerations
The security issues discussed in [I-D.ietf-mpls-mna-hdr] and in
[RFC8679] apply to this document.
5. IANA Considerations
This document requests that IANA allocates a new codepoint with the
name "Stateless MNA-based Egress Protection" in the "Network Action
Opcodes Registry".
+============+=======================================+===========+
| MNA Opcode | Description | Reference |
+============+=======================================+===========+
| TBA1 | Stateless MNA-based Egress Protection | This |
| | | document |
+------------+---------------------------------------+-----------+
Table 2: SMEP Opcode IANA allocation.
6. References
6.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>.
[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>.
6.2. Informative References
Ihle & Menth Expires 28 March 2025 [Page 7]
Internet-Draft SMEP September 2024
[I-D.ietf-mpls-mna-hdr]
Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K.
Kompella, "MPLS Network Action (MNA) Sub-Stack Solution",
Work in Progress, Internet-Draft, draft-ietf-mpls-mna-hdr-
08, 30 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-hdr-08>.
[RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H.,
Michel, C., and H. Chen, "MPLS Egress Protection
Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019,
<https://www.rfc-editor.org/rfc/rfc8679>.
Authors' Addresses
Fabian Ihle
University of Tuebingen
Tuebingen
Germany
Email: fabian.ihle@uni-tuebingen.de
Michael Menth
University of Tuebingen
Tuebingen
Germany
Email: michael.menth@uni-tuebingen.de
Ihle & Menth Expires 28 March 2025 [Page 8]