idnits 2.17.1 draft-chandra-mpls-rsvp-shared-labels-np-00.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 (July 2, 2018) is 2096 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) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-shared-labels-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 H. Sitaraman 5 Expires: January 3, 2019 Juniper Networks 6 July 2, 2018 8 Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane 9 draft-chandra-mpls-rsvp-shared-labels-np-00 11 Abstract 13 Segment Routed RSVP-TE tunnels provide the ability to use a shared 14 MPLS forwarding plane at every hop of the Label Switched Path (LSP). 15 The shared forwarding plane is realized with the use of 'Traffic 16 Engineering (TE) link labels' that get shared by LSPs traversing 17 these TE links. This paradigm helps significantly reduce the 18 forwarding plane state required to support a large number of LSPs on 19 a Label Switching Router (LSR). These tunnels require the ingress 20 Label Edge Router (LER) to impose a stack of labels. If the ingress 21 LER cannot impose the full label stack, it can use the assistance of 22 one or more delegation hops along the path of the LSP to impose parts 23 of the label stack. 25 The procedures for a Point of Local Repair (PLR) to provide local 26 protection against link failures using facility backup for Segment 27 Routed RSVP-TE tunnels are well defined and do not require specific 28 protocol extensions. This document defines the procedures for a PLR 29 to provide local protection against transit node failures using 30 facility backup for these tunnels. The procedures defined in this 31 document include protection against delegation hop failures. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 37 "OPTIONAL" in this document are to be interpreted as described in BCP 38 14 [RFC2119] [RFC8174] when, and only when, they appear in all 39 capitals, as shown here. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on January 3, 2019. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. Node Protection Specific Procedures . . . . . . . . . . . . . 4 78 3.1. Applicability of this Document . . . . . . . . . . . . . 4 79 3.2. PLR Procedures for Protecting Next-Hop Non-Delegation LSR 4 80 3.3. PLR Procedures for Protecting Next-Hop Delegation LSR . . 5 81 3.3.1. Label Allocation and Stacking . . . . . . . . . . . . 7 82 3.4. Backwards Compatibility . . . . . . . . . . . . . . . . . 7 83 3.4.1. LSR does not Support Node Protection for Shared 84 Labels . . . . . . . . . . . . . . . . . . . . . . . 7 85 3.4.2. Protected Hop does not Support Shared Labels . . . . 9 86 3.4.3. PLR does not Support Shared Labels . . . . . . . . . 9 87 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 9 88 4.1. DHLD Encoding in ETLD Attributes TLV . . . . . . . . . . 9 89 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 94 8.2. Informative References . . . . . . . . . . . . . . . . . 11 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 97 1. Introduction 99 With the advent of Traffic Engineering (TE) link labels and Segment 100 Routed RSVP-TE Tunnels [I-D.ietf-mpls-rsvp-shared-labels], a shared 101 MPLS forwarding plane can be realized by allowing the TE link label 102 to be shared by MPLS RSVP-TE Label Switched Paths (LSPs) traversing 103 the link. The shared forwarding plane behavior helps reduce the 104 amount of forwarding plane state required to support a large number 105 of LSPs on a Label Switching Router (LSR). 107 Segment Routed RSVP-TE tunnels request the use of a shared forwarding 108 plane at every hop of the LSP. The TE link label used at each hop is 109 recorded in the Record Route object (RRO) of the Resv message. The 110 ingress Label Edge Router (LER) uses this recorded information to 111 construct a stack of labels that can be imposed on the packets 112 steered on to the tunnel. In the scenario where the ingress LER 113 cannot impose the full label stack, it can use the assistance of one 114 or more delegation hops along the path of the LSP to impose parts of 115 the label stack. 117 Facility backup is a local repair method [RFC4090] in which a bypass 118 tunnel is used to provide protection against link or node failures 119 for MPLS RSVP-TE LSPs at the Point of Local Repair (PLR). The 120 facility backup procedures that provide protection against link 121 failures for Segment Routed RSVP-TE LSPs are defined in 122 [I-D.ietf-mpls-rsvp-shared-labels]. This document defines the 123 facility backup procedures that provide protection against node 124 failures for these LSPs. These procedures include protection against 125 delegation hop failures. The document also discusses the procedures 126 for handling backwards compatibility scenarios where a node along the 127 path of the LSP does not support the procedures defined in this 128 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 [I-D.ietf-mpls-rsvp-shared-labels]. 138 Unless otherwise stated, the term LSPs in this document refer to 139 Segment Routed RSVP-TE LSPs. 141 3. Node Protection Specific Procedures 143 A set of Segment Routed RSVP-TE LSPs can share a TE link label on an 144 LSR only if all the LSPs in the set share the same outbound label 145 forwarding action. For protected LSPs, having the same outbound 146 label forwarding action means having the same primary forwarding 147 action and the same backup forwarding action. In the case of LSPs 148 that do not request local protection or LSPs that request only link 149 protection, they can use the same outbound label forwarding action if 150 they reach a common next-hop LSR via a common outgoing TE link. 151 However, in the case of LSPs that request node protection, they can 152 use the same outbound label forwarding action only if they reach a 153 common next-next-hop LSR via a common outgoing TE link and a common 154 next-hop LSR. 156 3.1. Applicability of this Document 158 The label allocation and signaling procedures defined in 159 [I-D.ietf-mpls-rsvp-shared-labels] can sufficiently cater to the 160 following scenarios on an LSR: 162 (a) Offer no protection to LSPs that do not request local protection 164 (b) Offer no protection or link protection to LSPs that request link 165 protection 167 (c) Offer no protection or link protection to LSPs that request node 168 protection 170 The label allocation and signaling procedures defined in this 171 document are meant to enable LSRs to offer node protection to LSPs 172 that request node protection. 174 3.2. PLR Procedures for Protecting Next-Hop Non-Delegation LSR 176 If the protected next-hop LSR signals a TE link label for the LSP but 177 does not set the Delegation Label flag in the RRO Label Subobject 178 carried in Resv message, then the PLR SHOULD allocate multiple shared 179 labels for the same TE link such that a unique label is allocated for 180 every unique next-next-hop LSR that is reachable via the protected 181 next-hop LSR. 183 326 348 184 +---+ +---+ 321+---+345 +---+ +---+ 185 | A |-----| B |-----| C |-----| D |-----| E | 186 +---+ +---+ +---+ +---+ +---+ 187 | | |376 | | 188 | | |378 | | 189 | | | | | 190 | +---+ +---+ +---+ +---+ 191 +-------| F |-----|G |-----|H |-----|I | 192 +---+ +---+ +---+ +---+ 194 Figure 1: Per-nhop-nnhop label allocation 196 In the example shown in Figure 1, LSR C has allocated the following 197 TE link labels: 199 321 for the TE link C-B to reach the next-next-hop LSR A 200 326 for the TE link C-B to reach the next-next-hop LSR F 201 345 for the TE link C-D to reach the next-next-hop LSR E 202 348 for the TE link C-D to reach the next-next-hop LSR H 203 376 for the TE link C-G to reach the next-next-hop LSR F 204 378 for the TE link C-G to reach the next-next-hop LSR H 206 If a LSP requesting node protection transits PLR C and if the 207 protected next-hop LSR after C along the LSP path is not a delegation 208 hop, then LSR C signals the respective TE link label depending on the 209 next-next-hop LSR on the LSP path. 211 LSP path: A -> B -> C -> D -> E : Label = 345 212 LSP path: A -> B -> C -> D -> H : Label = 348 213 LSP path: A -> B -> C -> G -> H : Label = 378 215 In all LSP paths above, at PLR C, the protected next-hop LSRs D and G 216 along the LSP paths signal TE link labels but are not delegation 217 hops. 219 If the primary TE link is operational, LSR C will pop the TE link 220 label and forward the packet to the corresponding next-hop LSR over 221 that TE link. During local repair, LSR C will pop the TE link label 222 and also the label beneath the top label, and forward the packet over 223 the node protecting bypass tunnel to the appropriate next-next-hop 224 LSR, which is the Merge Point (MP). 226 3.3. PLR Procedures for Protecting Next-Hop Delegation LSR 228 The outgoing backup label forwarding action corresponding to a label 229 shared by LSPs requesting node protection MUST bypass the protected 230 next-hop LSR. The PLR MUST push the label stack on behalf of the 231 next-hop delegation LSR. Hence, the number of labels that a 232 delegation hop chooses to push also depends on the number of labels 233 that the upstream hop (acting as PLR) along the primary LSP can push. 234 This section extends the Effective Transport Label-Stack Depth (ETLD) 235 signaling procedure specified in [I-D.ietf-mpls-rsvp-shared-labels] 236 for LSPs requesting node protection. 238 Considering Figure 2, assume LER A and LSR B can push a maximum of 3 239 labels on an MPLS packet while the remaining nodes can push a maximum 240 of 5 labels. LER A originates a Path message with an ETLD of 2 after 241 reserving space for the bypass tunnel label that should be pushed for 242 backup forwarding action. In addition to setting the ETLD, LER A 243 also sets the Delegation Helper Label Depth (DHLD) to 2 in the Path 244 message. The DHLD is computed as the maximum number of labels that 245 the node can push after reserving space for the NNHOP bypass tunnel 246 label that should be pushed for backup forwarding action. The ETLD 247 procedures dictate that each LSR add its own ETLD value before 248 sending the Path message downstream. LSRs C, E and I are 249 automatically selected as delegation hops by the time the Path 250 message reaches the egress LER L. LSR C uses the DHLD signaled by 251 the upstream LSR B as input when calculating the outgoing ETLD in the 252 Path message. 254 ETLD:2 ETLD:1 ETLD:2 ETLD:1 ETLD:4 255 DHLD:2 DHLD:2 DHLD:4 DHLD:4 DHLD:4 256 -----> -----> -----> -----> -----> 257 1300d 1500d 258 +---+ +---+ +---+ +---+ +---+ +---+ 259 | A |-----| B |-----| C |-----| D |-----| E |-----| F | ETLD:3 260 +---+ +---+ +---+ +---+ +---+ +---+ DHLD:4 261 | | | | 262 | | | | 263 | | 1900d | | 264 +---+ +---+ +---+ +---+ +---+ +---+ v 265 | L |-----| K |-----| J |-----| I |-----| H |-----+ G + 266 +---+ +---+ +---+ +---+ +---+ +---+ 268 DHLD:4 DHLD:4 DHLD:4 DHLD:4 DHLD:4 269 ETLD:2 ETLD:3 ETLD:4 ETLD:1 ETLD:2 270 <----- <----- <----- <----- <----- 272 Notation :