idnits 2.17.1 draft-chandra-mpls-rsvp-shared-labels-np-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 3, 2021) is 1201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group C. Ramachandran 3 Internet-Draft V. Beeram 4 Intended status: Standards Track Juniper Networks 5 Expires: July 7, 2021 H. Sitaraman 6 Individual 7 January 3, 2021 9 Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane 10 draft-chandra-mpls-rsvp-shared-labels-np-05 12 Abstract 14 Segment Routed RSVP-TE tunnels provide the ability to use a shared 15 MPLS forwarding plane at every hop of the Label Switched Path (LSP). 16 The shared forwarding plane is realized with the use of 'Traffic 17 Engineering (TE) link labels' that get shared by LSPs traversing 18 these TE links. This paradigm helps significantly reduce the 19 forwarding plane state required to support a large number of LSPs on 20 a Label Switching Router (LSR). These tunnels require the ingress 21 Label Edge Router (LER) to impose a stack of labels. If the ingress 22 LER cannot impose the full label stack, it can use the assistance of 23 one or more delegation hops along the path of the LSP to impose parts 24 of the label stack. 26 The procedures for a Point of Local Repair (PLR) to provide local 27 protection against link failures using facility backup for Segment 28 Routed RSVP-TE tunnels are well defined and do not require specific 29 protocol extensions. This document defines the procedures for a PLR 30 to provide local protection against transit node failures using 31 facility backup for these tunnels. The procedures defined in this 32 document include protection against delegation hop failures. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 38 "OPTIONAL" in this document are to be interpreted as described in BCP 39 14 [RFC2119] [RFC8174] when, and only when, they appear in all 40 capitals, as shown here. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on July 7, 2021. 59 Copyright Notice 61 Copyright (c) 2021 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 3. Node Protection Specific Procedures . . . . . . . . . . . . . 4 79 3.1. Applicability of this Document . . . . . . . . . . . . . 4 80 3.2. PLR Procedures for Protecting Next-Hop Non-Delegation LSR 4 81 3.3. PLR Procedures for Protecting Next-Hop Delegation LSR . . 5 82 3.3.1. Label Allocation and Stacking . . . . . . . . . . . . 7 83 3.4. Backwards Compatibility . . . . . . . . . . . . . . . . . 7 84 3.4.1. LSR does not Support Node Protection for Shared 85 Labels . . . . . . . . . . . . . . . . . . . . . . . 7 86 3.4.2. Protected Hop does not Support Shared Labels . . . . 9 87 3.4.3. PLR does not Support Shared Labels . . . . . . . . . 9 88 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 9 89 4.1. DHLD Encoding in ETLD Attributes TLV . . . . . . . . . . 9 90 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 95 8.2. Informative References . . . . . . . . . . . . . . . . . 11 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 98 1. Introduction 100 With the advent of Traffic Engineering (TE) link labels and Segment 101 Routed RSVP-TE Tunnels [RFC8577], a shared MPLS forwarding plane can 102 be realized by allowing the TE link label to be shared by MPLS RSVP- 103 TE Label Switched Paths (LSPs) traversing the link. The shared 104 forwarding plane behavior helps reduce the amount of forwarding plane 105 state required to support a large number of LSPs on a Label Switching 106 Router (LSR). 108 Segment Routed RSVP-TE tunnels request the use of a shared forwarding 109 plane at every hop of the LSP. The TE link label used at each hop is 110 recorded in the Record Route object (RRO) of the Resv message. The 111 ingress Label Edge Router (LER) uses this recorded information to 112 construct a stack of labels that can be imposed on the packets 113 steered on to the tunnel. In the scenario where the ingress LER 114 cannot impose the full label stack, it can use the assistance of one 115 or more delegation hops along the path of the LSP to impose parts of 116 the label stack. 118 Facility backup is a local repair method [RFC4090] in which a bypass 119 tunnel is used to provide protection against link or node failures 120 for MPLS RSVP-TE LSPs at the Point of Local Repair (PLR). The 121 facility backup procedures that provide protection against link 122 failures for Segment Routed RSVP-TE LSPs are defined in [RFC8577]. 123 This document defines the facility backup procedures that provide 124 protection against node failures for these LSPs. These procedures 125 include protection against delegation hop failures. The document 126 also discusses the procedures for handling backwards compatibility 127 scenarios where a node along the path of the LSP does not support the 128 procedures defined in this document. 130 The procedures discussed in this document do not cover protection 131 against ingress/egress node failures. They also do not apply to 132 Point to Multipoint (P2MP) RSVP-TE Tunnels. 134 2. Terminology 136 The reader is expected to be familiar with the terminology specified 137 in [RFC3209], [RFC4090] and [RFC8577]. Unless otherwise stated, the 138 term LSPs in this document refer to Segment Routed RSVP-TE LSPs. The 139 following additional terms are used in this document: 141 Primary forwarding action: The outbound label forwarding action 142 performed at a PLR for a protected LSP before the occurrence of 143 local failure. 145 Backup forwarding action: The outbound label forwarding action 146 performed at a PLR for a protected LSP after the occurrence of 147 local failure. 149 3. Node Protection Specific Procedures 151 A set of Segment Routed RSVP-TE LSPs can share a TE link label on an 152 LSR only if all the LSPs in the set share the same outbound label 153 forwarding action. For protected LSPs, having the same outbound 154 label forwarding action means having the same primary forwarding 155 action and the same backup forwarding action. In the case of LSPs 156 that do not request local protection or LSPs that request only link 157 protection, they can use the same outbound label forwarding action if 158 they reach a common next-hop LSR via a common outgoing TE link. 159 However, in the case of LSPs that request node protection, they can 160 use the same outbound label forwarding action only if they reach a 161 common next-next-hop LSR via a common outgoing TE link and a common 162 next-hop LSR. 164 3.1. Applicability of this Document 166 The label allocation and signaling procedures defined in [RFC8577] 167 can sufficiently cater to the following scenarios on an LSR: 169 (a) Offer no protection to LSPs that do not request local protection 171 (b) Offer no protection or link protection to LSPs that request link 172 protection 174 (c) Offer no protection or link protection to LSPs that request node 175 protection 177 The label allocation and signaling procedures defined in this 178 document are meant to enable LSRs to offer node protection to LSPs 179 that request node protection. 181 3.2. PLR Procedures for Protecting Next-Hop Non-Delegation LSR 183 If the protected next-hop LSR signals a TE link label for the LSP but 184 does not set the Delegation Label flag in the RRO Label Subobject 185 carried in Resv message, then the PLR SHOULD allocate multiple shared 186 labels for the same TE link such that a unique label is allocated for 187 every unique next-next-hop LSR that is reachable via the protected 188 next-hop LSR. 190 326 348 191 +---+ +---+ 321+---+345 +---+ +---+ 192 | A |-----| B |-----| C |-----| D |-----| E | 193 +---+ +---+ +---+ +---+ +---+ 194 | | |376 | | 195 | | |378 | | 196 | | | | | 197 | +---+ +---+ +---+ +---+ 198 +-------| F |-----|G |-----|H |-----|I | 199 +---+ +---+ +---+ +---+ 201 Figure 1: Per-nhop-nnhop label allocation 203 In the example shown in Figure 1, LSR C has allocated the following 204 TE link labels: 206 321 for the TE link C-B to reach the next-next-hop LSR A 207 326 for the TE link C-B to reach the next-next-hop LSR F 208 345 for the TE link C-D to reach the next-next-hop LSR E 209 348 for the TE link C-D to reach the next-next-hop LSR H 210 376 for the TE link C-G to reach the next-next-hop LSR F 211 378 for the TE link C-G to reach the next-next-hop LSR H 213 If a LSP requesting node protection transits PLR C and if the 214 protected next-hop LSR after C along the LSP path is not a delegation 215 hop, then LSR C signals the respective TE link label depending on the 216 next-next-hop LSR on the LSP path. 218 LSP path: A -> B -> C -> D -> E : Label = 345 219 LSP path: A -> B -> C -> D -> H : Label = 348 220 LSP path: A -> B -> C -> G -> H : Label = 378 222 In all LSP paths above, at PLR C, the protected next-hop LSRs D and G 223 along the LSP paths signal TE link labels but are not delegation 224 hops. 226 If the primary TE link is operational, LSR C will pop the TE link 227 label and forward the packet to the corresponding next-hop LSR over 228 that TE link. During local repair, LSR C will pop the TE link label 229 and also the label beneath the top label, and forward the packet over 230 the node protecting bypass tunnel to the appropriate next-next-hop 231 LSR, which is the Merge Point (MP). 233 3.3. PLR Procedures for Protecting Next-Hop Delegation LSR 235 The outgoing backup label forwarding action corresponding to a label 236 shared by LSPs requesting node protection MUST bypass the protected 237 next-hop LSR. The PLR MUST push the label stack on behalf of the 238 next-hop delegation LSR. Hence, the number of labels that a 239 delegation hop chooses to push also depends on the number of labels 240 that the upstream hop (acting as PLR) along the primary LSP can push. 241 This section extends the Effective Transport Label-Stack Depth (ETLD) 242 signaling procedure specified in [RFC8577] for LSPs requesting node 243 protection. 245 Considering Figure 2, assume LER A and LSR B can push a maximum of 3 246 labels on an MPLS packet while the remaining nodes can push a maximum 247 of 5 labels. LER A originates a Path message with an ETLD of 2 after 248 reserving space for the bypass tunnel label that should be pushed for 249 backup forwarding action. In addition to setting the ETLD, LER A 250 also sets the Delegation Helper Label Depth (DHLD) to 2 in the Path 251 message. The DHLD is computed as the maximum number of labels that 252 the node can push after reserving space for the NNHOP bypass tunnel 253 label that should be pushed for backup forwarding action. The ETLD 254 procedures dictate that each LSR add its own ETLD value before 255 sending the Path message downstream. LSRs C, E and I are 256 automatically selected as delegation hops by the time the Path 257 message reaches the egress LER L. LSR C uses the DHLD signaled by 258 the upstream LSR B as input when calculating the outgoing ETLD in the 259 Path message. 261 ETLD:2 ETLD:1 ETLD:2 ETLD:1 ETLD:4 262 DHLD:2 DHLD:2 DHLD:4 DHLD:4 DHLD:4 263 -----> -----> -----> -----> -----> 264 1300d 1500d 265 +---+ +---+ +---+ +---+ +---+ +---+ 266 | A |-----| B |-----| C |-----| D |-----| E |-----| F | ETLD:3 267 +---+ +---+ +---+ +---+ +---+ +---+ DHLD:4 268 | | | | 269 | | | | 270 | | 1900d | | 271 +---+ +---+ +---+ +---+ +---+ +---+ v 272 | L |-----| K |-----| J |-----| I |-----| H |-----+ G + 273 +---+ +---+ +---+ +---+ +---+ +---+ 275 DHLD:4 DHLD:4 DHLD:4 DHLD:4 DHLD:4 276 ETLD:2 ETLD:3 ETLD:4 ETLD:1 ETLD:2 277 <----- <----- <----- <----- <----- 279 Notation :