MPLS Working Group L. Andersson Internet-Draft Bronze Dragon Consulting Intended status: Standards Track J. Guichard Expires: 30 March 2023 H. Song Futurewei Technologies S. Bryant University of Surrey 26 September 2022 MPLS Label Stack Operations in Networks with MNA Incremental Deployment draft-andersson-mpls-mna-label-stack-operations-00 Abstract MPLS Network Action (MNA) allows MPLS packet to carry instruction and data for in-network services and functions in an MPLS network. This document describes the FEC-based optimized operations on the MPLS label stack when the network is mixed with LSRs which are capable or incapable of processing MNAs. 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 30 March 2023. Copyright Notice Copyright (c) 2022 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 Andersson, et al. Expires 30 March 2023 [Page 1] Internet-Draft MNA Label Stack Operations September 2022 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. Requirement Language . . . . . . . . . . . . . . . . . . 3 2. Operations on an MPLS Label Stack in an MNA capable network . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Physical Topology . . . . . . . . . . . . . . . . . . . . 3 2.2. A day in the life of a packet . . . . . . . . . . . . . . 5 2.2.1. Non-VPN Case . . . . . . . . . . . . . . . . . . . . 6 2.2.1.1. Non-VPN with an MNA in the packet . . . . . . . . 6 2.2.1.2. Non-VPN without any MNA in the packet . . . . . . 7 2.3. The VPN case . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. VPN with MNA in the packet . . . . . . . . . . . . . 8 2.3.2. VPN without MNA in the packet . . . . . . . . . . . . 9 2.4. RSVP-TE Tunnel case . . . . . . . . . . . . . . . . . . . 10 2.4.1. RSVP Tunnel and MNA present in the packet . . . . . . 12 2.4.2. RSVP Tunnel and no MNA present in the packet . . . . 12 2.4.3. EH capable RSVP-TE tunnel . . . . . . . . . . . . . . 13 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction MPLS Network Actions (MNA) is used to support actions for Label Switched Paths (LSPs) and/or MPLS packets in addition to the normal forwarding. [I-D.ietf-mpls-mna-fwk] provides the architectural framework for MNA and [I-D.ietf-mpls-mna-requirements] provides the design requirements for MNA. MNA can support actions encoded within or below the label stack. [I-D.andersson-mpls-eh-architecture] describes some further architectural concepts for MNA. This document provides the operating procedures for MNA-capable and non-MNA-capable LSRs where MNA encoding are carried within or below the MPLS label stack. We show that MNAs can be gradually introduced into an existing MPLS network. The capability to handle MNAs is announced throughout the MPLS network, and LSRs that do not understand this information simply ignore it. Andersson, et al. Expires 30 March 2023 [Page 2] Internet-Draft MNA Label Stack Operations September 2022 The MNAs are carried below the top label and the presence of MNAs are indicated by a bSPL in the label stack. The MNA use cases can be found in [I-D.ietf-mpls-mna-usecases]. A post-stack extension header may for example be used when it is required that the packet carry a large instruction header and/or metadata for an MNA [I-D.song-mpls-extension-header]. Only MNA capable LSRs will process MNAs, LSRs that are non-MNA- capable will ignore the MNA and forward the packet as if the information was not there. 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. 2. Operations on an MPLS Label Stack in an MNA capable network This document provides a set of examples to show the operations performed on MPLS encapsulated packets in a network where MPLS MNAs are used. The document does also illustrated the procedures for processing of the information carried within the MPLS label stack to indicate the presence of MNAs below the top label. 2.1. Physical Topology Assume a physical topology that includes both MNA capable LSRs and non-MNA capable LSRs. The topology is intentionally kept quite simple. Andersson, et al. Expires 30 March 2023 [Page 3] Internet-Draft MNA Label Stack Operations September 2022 +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | | | A +------+ b +------+ c +------+ D +------+ E +------+ F + | | | | | | | | | | | | +---+ +---+ +---+ +---+ +---+ +---+ Legend: A, D, E, and F are MNA capable LSRs b and c are non-MNA capable LSRs. Figure 1: MNA topology I LDP Downstream on Demand (DoD) or Downstream Unsolicited (DU), RSVP- TE, an IGP or a centralized controller could be used to create the label mappings between the LSRs in an MNA capable network. Referring to Figure 1, and using LDP DU for illustration, creation of an MNA path used by A to send MPLS encapsulated packets with MNAs to F is as show below. For prefix F reachable at LSR F: * F advertises labels F:[ldp: implicit-null, MNA-FEC: implicit-null] to E * E advertises labels F:[ldp: 101, MNA-FEC: 201] to D * D advertises label F:[ldp: 102] to c * c advertises label F:[ldp: 103] to b * b advertises label F:[ldp: 104] to A This will result in installed labels as shown in Figure 2. Andersson, et al. Expires 30 March 2023 [Page 4] Internet-Draft MNA Label Stack Operations September 2022 +---+ +---+ +---+ +---+ +---+ +---+ | |..104..| |..103..| |..102..| |..101..| |..php..| | | A +-------+ b +-------+ c +-------+ D +-------+ E +-------+ F + | | | | | | | |..201..| |..php..| | +---+ +---+ +---+ +---+ +---+ +---+ Legend: A, D, E and F are MNA capable nodes. b and are non-MNA capable nodes. Figure 2: MNA topology II 2.2. A day in the life of a packet This section provides examples of forwarding for some common scenarios in networks with a mix of MNA-capable and non-MNA-capable LSRs and packets with and without MNAs encoded. The examples assume the use of post-stack extension headers. The process is equally applicable to in-stack MNAs. Andersson, et al. Expires 30 March 2023 [Page 5] Internet-Draft MNA Label Stack Operations September 2022 For reference the following shows the full MPLS MNA stack, i.e. including also the post-stack EH specific information and the payload. 0 31 +--------+--------+--------+--------+ | | ~ MPLS Label Stack ~ | | +--------+--------+--------+--------+ | bSPL for MNA | +--------+--------+--------+--------+ | | ~ MPLS Label Stack ~ | | +--------+--------+--------+--------+ | Header of Extension Headers (HEH) | +--------+--------+--------+--------+ | | ~ Extension Header (EH) for MNA 1 ~ | | +--------+--------+--------+--------+ | | ~ Extension Header (EH) for MNA N ~ | | +--------+--------+--------+--------+ | | ~ Upper Layer Protocols/Payload ~ | | +--------+--------+--------+--------+ Figure 3: Label Stack with MNA 2.2.1. Non-VPN Case For non-VPN there are two variants, either the MNA is present or it is not. 2.2.1.1. Non-VPN with an MNA in the packet * A sends packet to b - stack = [104, bSPL, HEH, EH, IP] * b is a legacy router so just swaps [104] to [103], and sends the packet to c Andersson, et al. Expires 30 March 2023 [Page 6] Internet-Draft MNA Label Stack Operations September 2022 - stack = [103, bSPL, HEH, EH, IP] * c is a legacy router so just swaps [103] to [102], and sends the packet to D - stack = [102, bSPL, HEH, EH, IP] * D is an MNA capable LSR and receives the packet with [102] on top of the stack; D scans the packet for an MNA; D finds the MNA and processes it and then swaps the top label to [101] and then sends the packet on to E i Note: this goes on the standard FEC because we only announce in the packet there is NO MNA. In this case MNA is present. - stack = [101, bSPL, HEH, EH, IP] * E receives [101] and scans the packet for MNA; it finds the MNA and processes it and then pops the top label and send the packet to F - stack = [bSPL, HEH, EH, IP] o Note: E is the penultimate hop router so it pops the standard LDP label, and send on the standard FEC to F. * F receives the packet and scans the packet for MNA; it finds the MNA and processes it. As F is the ultimate hop it pops GAL, and removes bSPL, HEH and EH, processes IP and forwards the packet. 2.2.1.2. Non-VPN without any MNA in the packet In this example there is no MNA present in the packet. * A sends packet to b - stack = [104, IP] * b receives the packet, b is a legacy router so it just swaps [104] to [103] and sends the packet to c - stack = [103, IP] * c receives the packet, c is a legacy router so it just swaps [103] to [102], and sends the packet to D - stack = [102, IP] Andersson, et al. Expires 30 March 2023 [Page 7] Internet-Draft MNA Label Stack Operations September 2022 * D receives the packet. Since D is an MNA capable router, it searches the packet for MNA but finds nothing, so D swaps [102] to [201], and sends the packet to E - stack = [201, IP] o Note: in this case D sends the packet using the MNA-FEC as MNA is *not* present. o Note: If downstream is not MNA capable then D sends the packet on the standard FEC. * E receives the packet [201] and bypasses MNA searching and processing (received on the "no MNA present" FEC; E is penultimate node so it pops MNA-FEC label; and send the packet to F. - stack = [IP]; not exactly a "label stack", but listed here for symmetry * F receives [IP] and routes the packet 2.3. The VPN case In these two examples there is VPN information in the label stack, in the first there also MNAs in the packet. 2.3.1. VPN with MNA in the packet * A sends packet to b - stack = [104, VPN, bSPL, HEH, EH, IP] * b receives the packet; b is a legacy router and just swaps [104] to [103] and sends the packet to c - stack = [103, VPN, bSPL, HEH, EH, IP] * c receives the packet; c is a legacy router and just swaps [103] to [102] and sends the packet to D - stack = [102, VPN, bSPL, HEH, EH, IP] * D receives the packet; D is an MNA capable LSR; D will search the packet for MNA and will find and process the MNA; D will then swap [102] to [101] and sends the packet to E - stack = [101, VPN, bSPL, HEH, EH, IP] Andersson, et al. Expires 30 March 2023 [Page 8] Internet-Draft MNA Label Stack Operations September 2022 o Note: This packet will be sent normal IP standard FEC; only packets that does not include any MNA will be sent on the "no MNA present" FEC. * E receives the packet; E is MNA capable LSR; E will search the packet for MNA and will find and process the MNA; E will then pop [101] and sends the packet to F - stack = [VPN, bSPL, HEH, EH, IP] o Note: E is penultimate hop so pops the LDP label and send the packet on normal IP standard FEC; only packets that does not include any MNA will be sent on the "no MNA present" FEC. * F receives and scans the packet for MNA; it finds an MNA and processes it. As F is the ultimate hop it pops the bSPL and removes HEH and EH, processes the VPN label and forwards the packet. 2.3.2. VPN without MNA in the packet * A sends packet to b - stack = [104, VPN, IP] * b receives the packet; b is a legacy router and just swaps [104] to [103] and sends the packet to c - stack = [103, VPN, IP] * c receives the packet; c is a legacy router and just swaps [103] to [102] and sends the packet to D - stack = [102, VPN, IP] * D receives the packet; D is MNA capable LSR; D will search the packet for MNA; D will not find any MNA; D will then swap [102] to [201] and sends the packet to E on the "no MNA present" FEC. - stack = [101, VPN, IP] o Note: This packet will be sent on the "no MNA pesent" FEC; * E receives the packet [201] and bypasses MNA processing (received on the "no MNA present" FEC; E is the penultimate node so it pops MNA- FEC label; and send the packet to F on the "no MNA present" FEC. Andersson, et al. Expires 30 March 2023 [Page 9] Internet-Draft MNA Label Stack Operations September 2022 - stack = [VPN, IP] o Note: E is penultimate hop so E pops the "no MNA present" label and send the packet to F. * F receives and scans the packet for MNA; finds no MNA and bypasses MNA processing. As F is the ultimate hop it processes the VPN label and forwards the packet. 2.4. RSVP-TE Tunnel case The RSVP-TE tunnel is not MNA capable or the capability has been disabled. Assume a physical topology that includes both MNA capable LSRs and non-MNA capable LSRs, as in the earlier examples. This topology also includes a low cost RSVP-TE tunnel between b and D. +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | | | A +------+ b +------+ c +------+ D +------+ E +------+ F + | | | | | | | | | | | | +---+ +---+ +---+ +---+ +---+ +---+ | | | | | |___________________| | |_______________________| Legend: A, D, E, and F are MNA capable LSRs b and c are non-MNA capable LSRs. Nodes that transport the RSVP-TE tunnel are not MNA capable, or the MNA capability is disabled. Figure 4: MNA topology III For this example the following assumptions are made: * An RSVP-TE tunnel has been established between b and D (packets will bypass c) * F is reachable at b through RSVP-TE tunnel Andersson, et al. Expires 30 March 2023 [Page 10] Internet-Draft MNA Label Stack Operations September 2022 * LDP is enabled on the RSVP-TE tunnel For prefix [F]: The following label mappings are sent by the LSRs in the network. * F advertises labels F: [ldp: implicit-null, MNA-FEC: implicit- null] to E * E advertises labels F: [ldp: 101, MNA-FEC: 201] to D * D advertises label F: [ldp: 102] to c and F:[ldp: 102] to b * c advertises label F: [ldp: 103] to b * b advertises label F: [ldp: 104] to A This will result in label mappings like this. +---+ +---+ +---+ +---+ +---+ +---+ | |--104..| |..103..| |..102..| |..101..| |..php..| | | A +-------+ b +-------+ c +-------+ D +-- ----+ E +-------+ F + | | | | | | | |..201..| |..php..| | +---+ - +---+ +---+ +---+ +---+ +---+ | | | | | +---------------------+ | | [RSVP, 102] | +-------------------------+ Legend: A, D, E, and F are MNA capable LSRs b and c are non-MNA capable LSRs. Nodes that transport the RSVP-TE tunnel are not MNA capable, or the MNA capability is disabled. [RSVP] represents the series of tunnel top labels. Figure 5: MNA topology IV To describe the label stack operations in this case the VPN label stack is used, starting with the case where an MNA is present in the packet. Andersson, et al. Expires 30 March 2023 [Page 11] Internet-Draft MNA Label Stack Operations September 2022 2.4.1. RSVP Tunnel and MNA present in the packet * A sends packet to b - stack = [104, VPN, bSPL, HEH, EH, IP] * b receives the packet, since b is a legacy router it swaps [104] to [102], the next-hop reachable through the RSVP-TE tunnel; push the ingress RSVP-TE tunnel label and send it via the tunnel to the tunnel endpoint D - stack = [RSVP, 102, VPN, bSPL, HEH, EH, IP] * Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE label. * D receives the packet, D will pop the last RSVP-TE label; since D is an MNA capable router it will search the stack and find the MNA, after processing the MNA it will swap [102] to [101], and send the packet to E over the normal FEC - stack = [101, VPN, bSPL, HEH, EH, IP] o Note: this will be forwarded on the standard FEC because since the MNA is present in the packet, only packet without any MNA is forwarded on the "no MNA present" FEC. * E receives the packet [101]; since E is an MNA capable router it will search the stack and find the MNA; after processing the MNA it will pop [101], and send the packet to E over the normal FEC - stack = [VPN, bSPL, HEH, EH, IP] o Note: As E is the penultimate hop it will pop the standard LDP label. * F receives the packet with the VPN label on top [VPN]; E scans the packet for MNA; it finds the MNA and processes it. As F is the ultimate hop it pops bSPL, and removes HEH and EH, processes VPN label and forwards the packet. 2.4.2. RSVP Tunnel and no MNA present in the packet * A sends packet to b - stack = [104, VPN, IP] Andersson, et al. Expires 30 March 2023 [Page 12] Internet-Draft MNA Label Stack Operations September 2022 * b receives the packet [104]; be is legacy router and will not search for an MNA; b swaps [104] to [102]; pushes [RSVP] sends packet to D over the RSVP-TE tunnel. - stack = [RSVP, 102, VPN, IP] * Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE label. * D receives pops the tunnel label [RSVP], D is MNA capable and scans the packet for MNA; D finds no MNA is present; pops RSVP-TE label, and then swaps LDP label [102 ]to [201] and sends the packet to E - stack = [201, VPN, IP] o Note: in this case D sends the packet using the "no MNA present" FEC, since there is no MNA in the packet. o Note: If the downstream LSR is not MNA capable then D will sends the packet on the standard FEC. * E receives [201] and bypasses MNA processing since the packet is received on the "no MNA present" FEC; E is the pen-ultimate hop so it pops the MNA-FEC label and forward the packet to F - stack = [VPN, IP] * F receives the packet [VPN]; and scans the packet for MNA; it does not find any MNA, and it processes VPN label and forwards the packet. 2.4.3. EH capable RSVP-TE tunnel The case where an RSVP-TE tunnel is both MNA capable and MNA enabled is for further study. 3. Security Considerations TBA 4. IANA Considerations There are no requests for IANA actions in this document. Note to the RFC Editor - this section can be removed before publication. Andersson, et al. Expires 30 March 2023 [Page 13] Internet-Draft MNA Label Stack Operations September 2022 5. Acknowledgments TBA - 6. References 6.1. Normative References [I-D.andersson-mpls-eh-architecture] Andersson, L., Guichard, J. N., Song, H., and S. Bryant, "MPLS Extension Header Architecture", Work in Progress, Internet-Draft, draft-andersson-mpls-eh-architecture-03, 5 April 2022, . [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-01, 8 September 2022, . [I-D.ietf-mpls-mna-requirements] Bocci, M., Bryant, S., and J. Drake, "Requirements for MPLS Network Action Indicators and MPLS Ancillary Data", Work in Progress, Internet-Draft, draft-ietf-mpls-mna- requirements-03, 19 August 2022, . [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-00, 19 May 2022, . [I-D.song-mpls-eh-indicator] Song, H., Li, Z., Zhou, T., and L. Andersson, "Options for MPLS Extension Header Indicator", Work in Progress, Internet-Draft, draft-song-mpls-eh-indicator-05, 27 June 2022, . Andersson, et al. Expires 30 March 2023 [Page 14] Internet-Draft MNA Label Stack Operations September 2022 [I-D.song-mpls-extension-header] Song, H., Li, Z., Zhou, T., Andersson, L., Zhang, Z., Gandhi, R., Rajamanickam, J., and J. Bhattacharya, "Support MPLS Network Actions using Post-Stack Extension Headers", Work in Progress, Internet-Draft, draft-song- mpls-extension-header-10, 1 September 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, . 6.2. Informative References [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Loa Andersson Bronze Dragon Consulting Email: loa@pi.nu James N Guichard Futurewei Technologies Email: james.n.guichard@futurewei.com Haoyu Song Futurewei Technologies Email: haoyu.song@futurewei.com Andersson, et al. Expires 30 March 2023 [Page 15] Internet-Draft MNA Label Stack Operations September 2022 Stewart Bryant University of Surrey Email: stewart.bryant@gmail.com Andersson, et al. Expires 30 March 2023 [Page 16]