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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [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, . 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]