MPLS Working Group C. Ramachandran Internet-Draft V. Beeram Intended status: Standards Track Juniper Networks Expires: July 12, 2020 H. Sitaraman Individual January 9, 2020 Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane draft-chandra-mpls-rsvp-shared-labels-np-03 Abstract Segment Routed RSVP-TE tunnels provide the ability to use a shared MPLS forwarding plane at every hop of the Label Switched Path (LSP). The shared forwarding plane is realized with the use of 'Traffic Engineering (TE) link labels' that get shared by LSPs traversing these TE links. This paradigm helps significantly reduce the forwarding plane state required to support a large number of LSPs on a Label Switching Router (LSR). These tunnels require the ingress Label Edge Router (LER) to impose a stack of labels. If the ingress LER cannot impose the full label stack, it can use the assistance of one or more delegation hops along the path of the LSP to impose parts of the label stack. The procedures for a Point of Local Repair (PLR) to provide local protection against link failures using facility backup for Segment Routed RSVP-TE tunnels are well defined and do not require specific protocol extensions. This document defines the procedures for a PLR to provide local protection against transit node failures using facility backup for these tunnels. The procedures defined in this document include protection against delegation hop failures. 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. 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 Ramachandran, et al. Expires July 12, 2020 [Page 1] Internet-Draft NP for Segment Routed RSVP-TE Tunnels January 2020 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 July 12, 2020. Copyright Notice Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Node Protection Specific Procedures . . . . . . . . . . . . . 4 3.1. Applicability of this Document . . . . . . . . . . . . . 4 3.2. PLR Procedures for Protecting Next-Hop Non-Delegation LSR 4 3.3. PLR Procedures for Protecting Next-Hop Delegation LSR . . 5 3.3.1. Label Allocation and Stacking . . . . . . . . . . . . 7 3.4. Backwards Compatibility . . . . . . . . . . . . . . . . . 7 3.4.1. LSR does not Support Node Protection for Shared Labels . . . . . . . . . . . . . . . . . . . . . . . 7 3.4.2. Protected Hop does not Support Shared Labels . . . . 9 3.4.3. PLR does not Support Shared Labels . . . . . . . . . 9 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 9 4.1. DHLD Encoding in ETLD Attributes TLV . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Ramachandran, et al. Expires July 12, 2020 [Page 2] Internet-Draft NP for Segment Routed RSVP-TE Tunnels January 2020 1. Introduction With the advent of Traffic Engineering (TE) link labels and Segment Routed RSVP-TE Tunnels [RFC8577], a shared MPLS forwarding plane can be realized by allowing the TE link label to be shared by MPLS RSVP- TE Label Switched Paths (LSPs) traversing the link. The shared forwarding plane behavior helps reduce the amount of forwarding plane state required to support a large number of LSPs on a Label Switching Router (LSR). Segment Routed RSVP-TE tunnels request the use of a shared forwarding plane at every hop of the LSP. The TE link label used at each hop is recorded in the Record Route object (RRO) of the Resv message. The ingress Label Edge Router (LER) uses this recorded information to construct a stack of labels that can be imposed on the packets steered on to the tunnel. In the scenario where the ingress LER cannot impose the full label stack, it can use the assistance of one or more delegation hops along the path of the LSP to impose parts of the label stack. Facility backup is a local repair method [RFC4090] in which a bypass tunnel is used to provide protection against link or node failures for MPLS RSVP-TE LSPs at the Point of Local Repair (PLR). The facility backup procedures that provide protection against link failures for Segment Routed RSVP-TE LSPs are defined in [RFC8577]. This document defines the facility backup procedures that provide protection against node failures for these LSPs. These procedures include protection against delegation hop failures. The document also discusses the procedures for handling backwards compatibility scenarios where a node along the path of the LSP does not support the procedures defined in this document. The procedures discussed in this document do not cover protection against ingress/egress node failures. They also do not apply to Point to Multipoint (P2MP) RSVP-TE Tunnels. 2. Terminology The reader is expected to be familiar with the terminology specified in [RFC3209], [RFC4090] and [RFC8577]. Unless otherwise stated, the term LSPs in this document refer to Segment Routed RSVP-TE LSPs. The following additional terms are used in this document: Primary forwarding action: The outbound label forwarding action performed at a PLR for a protected LSP before the occurrence of local failure. Ramachandran, et al. Expires July 12, 2020 [Page 3] Internet-Draft NP for Segment Routed RSVP-TE Tunnels January 2020 Backup forwarding action: The outbound label forwarding action performed at a PLR for a protected LSP after the occurrence of local failure. 3. Node Protection Specific Procedures A set of Segment Routed RSVP-TE LSPs can share a TE link label on an LSR only if all the LSPs in the set share the same outbound label forwarding action. For protected LSPs, having the same outbound label forwarding action means having the same primary forwarding action and the same backup forwarding action. In the case of LSPs that do not request local protection or LSPs that request only link protection, they can use the same outbound label forwarding action if they reach a common next-hop LSR via a common outgoing TE link. However, in the case of LSPs that request node protection, they can use the same outbound label forwarding action only if they reach a common next-next-hop LSR via a common outgoing TE link and a common next-hop LSR. 3.1. Applicability of this Document The label allocation and signaling procedures defined in [RFC8577] can sufficiently cater to the following scenarios on an LSR: (a) Offer no protection to LSPs that do not request local protection (b) Offer no protection or link protection to LSPs that request link protection (c) Offer no protection or link protection to LSPs that request node protection The label allocation and signaling procedures defined in this document are meant to enable LSRs to offer node protection to LSPs that request node protection. 3.2. PLR Procedures for Protecting Next-Hop Non-Delegation LSR If the protected next-hop LSR signals a TE link label for the LSP but does not set the Delegation Label flag in the RRO Label Subobject carried in Resv message, then the PLR SHOULD allocate multiple shared labels for the same TE link such that a unique label is allocated for every unique next-next-hop LSR that is reachable via the protected next-hop LSR. Ramachandran, et al. Expires July 12, 2020 [Page 4] Internet-Draft NP for Segment Routed RSVP-TE Tunnels January 2020 326 348 +---+ +---+ 321+---+345 +---+ +---+ | A |-----| B |-----| C |-----| D |-----| E | +---+ +---+ +---+ +---+ +---+ | | |376 | | | | |378 | | | | | | | | +---+ +---+ +---+ +---+ +-------| F |-----|G |-----|H |-----|I | +---+ +---+ +---+ +---+ Figure 1: Per-nhop-nnhop label allocation In the example shown in Figure 1, LSR C has allocated the following TE link labels: 321 for the TE link C-B to reach the next-next-hop LSR A 326 for the TE link C-B to reach the next-next-hop LSR F 345 for the TE link C-D to reach the next-next-hop LSR E 348 for the TE link C-D to reach the next-next-hop LSR H 376 for the TE link C-G to reach the next-next-hop LSR F 378 for the TE link C-G to reach the next-next-hop LSR H If a LSP requesting node protection transits PLR C and if the protected next-hop LSR after C along the LSP path is not a delegation hop, then LSR C signals the respective TE link label depending on the next-next-hop LSR on the LSP path. LSP path: A -> B -> C -> D -> E : Label = 345 LSP path: A -> B -> C -> D -> H : Label = 348 LSP path: A -> B -> C -> G -> H : Label = 378 In all LSP paths above, at PLR C, the protected next-hop LSRs D and G along the LSP paths signal TE link labels but are not delegation hops. If the primary TE link is operational, LSR C will pop the TE link label and forward the packet to the corresponding next-hop LSR over that TE link. During local repair, LSR C will pop the TE link label and also the label beneath the top label, and forward the packet over the node protecting bypass tunnel to the appropriate next-next-hop LSR, which is the Merge Point (MP). 3.3. PLR Procedures for Protecting Next-Hop Delegation LSR The outgoing backup label forwarding action corresponding to a label shared by LSPs requesting node protection MUST bypass the protected next-hop LSR. The PLR MUST push the label stack on behalf of the Ramachandran, et al. Expires July 12, 2020 [Page 5] Internet-Draft NP for Segment Routed RSVP-TE Tunnels January 2020 next-hop delegation LSR. Hence, the number of labels that a delegation hop chooses to push also depends on the number of labels that the upstream hop (acting as PLR) along the primary LSP can push. This section extends the Effective Transport Label-Stack Depth (ETLD) signaling procedure specified in [RFC8577] for LSPs requesting node protection. Considering Figure 2, assume LER A and LSR B can push a maximum of 3 labels on an MPLS packet while the remaining nodes can push a maximum of 5 labels. LER A originates a Path message with an ETLD of 2 after reserving space for the bypass tunnel label that should be pushed for backup forwarding action. In addition to setting the ETLD, LER A also sets the Delegation Helper Label Depth (DHLD) to 2 in the Path message. The DHLD is computed as the maximum number of labels that the node can push after reserving space for the NNHOP bypass tunnel label that should be pushed for backup forwarding action. The ETLD procedures dictate that each LSR add its own ETLD value before sending the Path message downstream. LSRs C, E and I are automatically selected as delegation hops by the time the Path message reaches the egress LER L. LSR C uses the DHLD signaled by the upstream LSR B as input when calculating the outgoing ETLD in the Path message. ETLD:2 ETLD:1 ETLD:2 ETLD:1 ETLD:4 DHLD:2 DHLD:2 DHLD:4 DHLD:4 DHLD:4 -----> -----> -----> -----> -----> 1300d 1500d +---+ +---+ +---+ +---+ +---+ +---+ | A |-----| B |-----| C |-----| D |-----| E |-----| F | ETLD:3 +---+ +---+ +---+ +---+ +---+ +---+ DHLD:4 | | | | | | | | | | 1900d | | +---+ +---+ +---+ +---+ +---+ +---+ v | L |-----| K |-----| J |-----| I |-----| H |-----+ G + +---+ +---+ +---+ +---+ +---+ +---+ DHLD:4 DHLD:4 DHLD:4 DHLD:4 DHLD:4 ETLD:2 ETLD:3 ETLD:4 ETLD:1 ETLD:2 <----- <----- <----- <----- <----- Notation :