idnits 2.17.00 (12 Aug 2021) /tmp/idnits55800/draft-ietf-mpls-mldp-node-protection-07.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6388]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 16, 2015) is 2439 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) == Missing Reference: 'RFC5420' is mentioned on line 103, but not defined == Missing Reference: 'RFC5286' is mentioned on line 104, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AFI' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IJ. Wijnands, Ed. 3 Internet-Draft K. Raza 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: March 19, 2016 A. Atlas 6 Juniper Networks, Inc. 7 J. Tantsura 8 Ericsson 9 Q. Zhao 10 Huawei Technology 11 September 16, 2015 13 mLDP Node Protection 14 draft-ietf-mpls-mldp-node-protection-07 16 Abstract 18 This document describes procedures to support node protection for 19 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths 20 (MP LSPs) that have been built by the "Multipoint Label Distribution 21 Protocol"(mLDP) [RFC6388]. In order to protect a node N, the Point 22 of Local Repair (PLR) Label Switched Router (LSR) of N must learn the 23 Merge Point (MPT) LSR(s) of node N such that traffic can be 24 redirected to them in case node N fails. Redirecting the traffic 25 around the failed node N depends on existing Point-to-Point (P2P) 26 Label Switched Paths (LSPs). The pre-established LSPs originate from 27 the PLR LSR and terminate on the MPT LSRs while bypassing LSR N. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 19, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Conventions used in this document . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. PLR Determination . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Transit node procedure . . . . . . . . . . . . . . . . . . 4 68 2.2. MP2MP root node procedure . . . . . . . . . . . . . . . . 5 69 2.3. PLR information encoding . . . . . . . . . . . . . . . . . 6 70 3. Using the tLDP session . . . . . . . . . . . . . . . . . . . . 8 71 4. Link or node failure . . . . . . . . . . . . . . . . . . . . . 10 72 4.1. Re-convergence after node/link failure . . . . . . . . . . 11 73 4.1.1. Node failure . . . . . . . . . . . . . . . . . . . . . 11 74 4.1.2. Link failure . . . . . . . . . . . . . . . . . . . . . 12 75 4.1.3. Switching to new primary path . . . . . . . . . . . . 12 76 5. mLDP Capabilities for Node Protection . . . . . . . . . . . . 12 77 5.1. PLR capability . . . . . . . . . . . . . . . . . . . . . . 13 78 5.2. MPT capability . . . . . . . . . . . . . . . . . . . . . . 13 79 5.3. The Protected LSR . . . . . . . . . . . . . . . . . . . . 13 80 5.4. The Node Protection Capability . . . . . . . . . . . . . . 14 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 84 9. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 16 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 This document describes procedures to support node protection for 93 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths 94 (MP LSPs) that have been built by the "Multipoint Label Distribution 95 Protocol"(mLDP) [RFC6388]. In order to protect a node N, the Point 96 of Local Repair (PLR) LSR of N must learn the Merge Point (MPT) 97 LSR(s) of node N such that traffic can be redirected to them in case 98 node N fails. Redirecting the traffic around the failed node N 99 depends on existing P2P LSPs. The pre-established LSPs originate 100 from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N. 101 The procedures to setup these P2P LSPs are outside the scope of this 102 document, but one can imagine using Resource Reservation Protocol for 103 Traffic Engineering (RSVP-TE) [RFC5420] or Label Distribution 104 Protocol (LDP) Loop Free Alternative (LFA) [RFC5286] based techniques 105 to accomplish this. 107 The solution described in this document notifies the PLR(s) of the 108 MPT LST(s) via signalling using a Targeted LDP (tLDP) session 109 [RFC7060]. By having a tLDP session with the PLR, no additional 110 procedures need to be defined in order to support Make-Before-Break 111 (MBB), Graceful Restart (GR) and Typed Wildcard FEC support. All 112 this is achieved at the expense of having additional tLDP sessions 113 between each MPT and PLR LSR. 115 In order to allow a node to be protected against failure, the LSRs 116 providing the PLR and the MPT functionality as well as the protected 117 node MUST support the functionality described in this document. LDP 118 capability negotiation [RFC5561] is used to signal the availability 119 of the functionality between the participating nodes; these nodes 120 MUST support capability negotiation. 122 1.1. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 The terms "node" is used to refer to an LSR and used interchangeably. 129 The terms "PLR" and "MPT" are used as shorthand to refer to "PLR LSR" 130 and "MPT LSR" respectively. 132 1.2. Terminology 133 mLDP: Multipoint extensions to LDP. 135 PLR: Point of Local Repair (the LSR that redirects the traffic to 136 one or more Merge Point LSRs). 138 MPT: Merge Point (the LSR that merges the backup LSP with primary 139 LSP. Note, there can be multiple MPT LSRs for a single MP-LSP 140 node protection). 142 tLDP: Targeted LDP. 144 MP LSP: Multi-Point LSP (either a P2MP or MP2MP LSP). 146 root node: The root of either a P2MP or MP2MP LSP as defined in 147 [RFC6388]. 149 2. PLR Determination 151 In order for a MPT to establish a tLDP session with a PLR, it first 152 has to learn the PLR for a particular MP LSP. It is the 153 responsibility of the protected node N to advertise the address of 154 the PLR to the MPT. The PLR address for a MP LSP on node N is the 155 address of the upstream LDP peer, but only when node N is NOT the 156 root node of the MP2MP LSP. If the upstream LDP peer is unable to 157 function as PLR, the procedures in this document do not apply and are 158 out of the scope. If node N is the root node, the procedures are 159 slightly different as described in Section 2.2. The procedures that 160 follow assume that all the participating nodes (N, PLRs, MPTs) are 161 enabled (e.g., by a user configuration) to support and implement the 162 PLR determination feature. 164 The procedures as documented in this document requires the protected 165 node to be directly connected to the PLR and MPT nodes. This is 166 because mLDP depends on unicast routing to determine the upstream LSR 167 and unicast routing (by default) only has information about the next- 168 hop and not beyond that. Support for non-directly connected PLR and 169 MPT nodes is outside the scope of this document. 171 2.1. Transit node procedure 173 Find below the procedures for when the protected node is a transit 174 node along the path to the root. 176 root 177 ^ 178 | 179 (LSR1) 180 . | . 181 . | . 182 . (N) . 183 . / \ . 184 . / \. 185 (LSR2) (LSR3) 186 | | 187 Figure 1. 189 N: The node being protected, 190 ...: Backup LSPs from LSR1 to LSR2 and LSR3. 192 Node N uses the root address of the MP LSP to determine the upstream 193 LSR for a given MP LSP following the procedures as documented in 194 [RFC6388] section 2.4.1.1. The upstream LSR in figure 1 is LSR1 195 because it is the first hop along the shortest path to reach the root 196 address. After determining the upstream LSR, node N (which has the 197 node protection feature enabled) MUST advertise the address of LSR1 198 as the PLR address to the downstream members of the MP LSP (i.e., 199 LSR2 and LSR3) if the given downstream member has announced support 200 for node protection (see Section 5 during Capability negotiation). 201 For the format and encoding of PLR address information, see 202 Section 2.3. 204 Note, in order for the protected traffic to reach nodes LSR2 and 205 LSR3, LSR1 MUST have two unidirectinal LSPs to LSR2 and LSR3, 206 bypassing node N. The procedures for setting up these LSPs are 207 outside the scope of this documemnt. 209 2.2. MP2MP root node procedure 211 Find below the procedures for when the protected node is the root of 212 a MP2MP LSP. Consider figure 2 below; 213 | 214 (LSR1) 215 . | . 216 . | . 217 . (N) . root 218 . / \ . 219 . / \. 220 (LSR2)....(LSR3) 221 | | 222 Figure 2. 224 N: The MP2MP root node being protected. 225 ...: Backup LSPs between LSR1, LSR2 and LSR3. 227 Assume that LSR1, LSR2 and LSR3 are all members of a MP2MP LSP for 228 which N is the root node. Since N is the root of the MP2MP LSP, 229 there is no upstream LSR and no 'single' PLR LSR for protecting node 230 N. In order to protect node N, all the directly connected members of 231 the MP2MP must participate in protecting node N by acting both as PLR 232 and MPT LSR. An LSR will act as MPT for traffic coming from the 233 other LSR(s) and it will act as PLR for traffic it is sending to the 234 other LSR(s). Since node N knows the members of the MP2MP LSP, it 235 will advertise the member list to its directly connected members, 236 excluding the member it is sending to. For example, node N will 237 advertise {LSR3,LSR1} list to LSR2 excluding LSR2 from it. Instead 238 of advertising a single PLR when node N is not the root, a list of 239 PLRs is advertised using the procedures documented in Section 2.3. 241 It should be noted that the MP2MP root node protection mechanism 242 doesn't replace the Root Node Redundancy (RNR) procedures as 243 described in [RFC6388] section 7. The node protection procedures in 244 this document will help in restoring traffic for the existing MP2MP 245 LSPs after node failure, but a new root node has to be elected 246 eventually in order to allow new MP2MP LSPs to be created. 248 Note, in order for the protected traffic to be exchanged between 249 nodes LSR1, LSR2 and LSR3, bidirectional LSPs have to exist between 250 the LSRs, bypassing node N. The procedures for setting up these LSPs 251 are outside the scope of this documemnt. 253 2.3. PLR information encoding 255 The upstream LSR address is conveyed via an LDP Notification message 256 with an MP Status TLV, where the MP status TLV contains a new "PLR 257 Status Value Element" that specifies the address of the PLR. 259 The new "PLR Status Value Element" is encoded as follows; 260 PLR Status Element: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type = TBA-1 | Length | Addr Family | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Addr Fam cont | Num PLR entry | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 269 | | 270 | PLR entry (1 or more) ~ 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Where 276 Type: PLR Status Value Element (Type TBA-1 to be assigned by IANA) 278 Length: The Length field is an unsigned integer that encodes the 279 length of the Status Value following the Length field. The 280 encoded Length varies based on the Addr Family and the number of 281 PLR entries. 283 Addr Family: Two octet quantity containing a value from IANA's 284 [AFI] registry that encodes the address family for the PLR Address 285 encoded in the PLR entry. 287 Num PLR entry: Element as an unsigned, integer followed by that 288 number of "PLR entry" fields in the format specified below. 290 The format of a "PLR Entry" is as follows: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |A| Reserved | PLR address | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ~ PLR address (cont) ~ 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Where 302 A bit: 0 = Withdraw, 1 = Add. 304 Reserved: 15 bits, MUST be zero on transmit and ignored on receipt 305 PLR address: PLR Address encoded according to Address Family field 306 encoded in the PLR Status Value Element. Note, the length of the 307 PLR address field is specific to the Address Family that is 308 encoded. 310 The size of a "PLR Entry" is the 2 octets ("A bit + Reserved") + PLR 311 address length. The length of the PLR address is dependent on the 312 Address Family as encoded in the PLR Status Value Element. The size 313 of a "PLR entry" is 6 octets and 18 octets respectively for an IPv4 314 PLR address and an IPv6 PLR address. 316 If the PLR address on N changes for a given MP LSP, N needs to 317 trigger a new PLR Status to update the MPT(s). Node N can advertise 318 or withdraw a given PLR from its PLR set by setting the "A bit" to 1 319 or 0 respectively in the corresponding PLR entry. Removing a PLR 320 address is likely due to a link failure; see the procedures as 321 documented in Section 4.1. To remove all PLR addresses belonging to 322 the encoded Address Family, an LSR N MUST encode PLR Status Value 323 Element with no PLR entry and "Num PLR entry" field MUST be set to 324 zero. 326 Along with the PLR Status a MP FEC TLV [RFC5036] MUST be included in 327 the LDP Notification message so that a receiver is able to associate 328 the PLR Status with the MP LSP. 330 3. Using the tLDP session 332 The receipt of a PLR MP Status (with PLR addresses) for a MP LSP on a 333 receiving LSR makes it an MPT for node protection. If not already 334 established, the MPT LSR MUST establish a tLDP session with all of 335 the learned PLR addresses using the procedures as documented in 336 [RFC7060]. 338 Using Figure 1 as the reference topology, let us assume that both 339 LSR2 and LSR3 are MPTs and have established a tLDP session with the 340 PLR being LSR1. Assume that both LSR2 and LSR3 have a FEC with 341 a upstream LSR N and label Ln assigned to FEC towards N. The MPTs 342 will create a secondary upstream LSR (using the received PLR address) 343 and assigned a Label Lpx to FEC towards PLR for it. The MPTs 344 will do that for each PLR address that was learned for the MP LSP. 345 In this example, the MPTs will have a FEC with two local labels 346 associated with it. Label Ln that was assigned to N using the the 347 normal mLDP procedures, and Label Lpx that was assigned to PLR (LSR1) 348 for the purpose of node protection. Note, when the protected node is 349 a MP2MP root node, there will be an upstream LSR for each PLR address 350 that was advertised along with a unique Label Lpx. 352 The receipt of a FEC Label Mapping alone over the tLDP session from 353 MPT on a PLR conveys the label information but does not convey the 354 node being protected. The information about a protected node is 355 known to the MPT LSR and needs to be communicated to the PLR as well. 356 For this reason, the FEC Label Mapping (FEC : Lpx) sent by the 357 MPT over the tLDP session to the PLR MUST include a Status TLV with 358 MP Status and a new LDP MP status Value Element called the "Protected 359 Node Status Value Element". This new value element is used to 360 specify the address of the node being protected. The "Protected Node 361 Status Value Element" has the following format; 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type = TBA-2 | Length | Addr Family | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Addr Fam cont | Node address ~ 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Type : Protected Node Status Value Element (Type TBA-2 to be 372 assigned by IANA) 374 Length: The Length field is an unsigned integer that encodes the 375 length of the Status Value following the Length field. The 376 encoded Length varies based on the Address Family and is 6 octets 377 (for Address Family + IPv4 address and 18 octets for Address 378 Family + IPv6 address. 380 Addr Family: Two octet quantity containing a value from IANA's 381 [AFI] registry that encodes the address family for the Node 382 Address. 384 Node address: Protected node address encoded according to Address 385 Family field. 387 When a PLR receives a Label Mapping for FEC that includes a 388 Protected Node Status, it will only use that label binding once the 389 Node advertised in the Status value becomes unreachable. If the LSP 390 is a MP2MP LSP, the PLR would have assigned a Label Mapping for the 391 upstream MP2MP FEC Element to the MPT ([RFC6388] section 3) for FEC 392 . This label binding on the MPT MUST only be used once node N 393 becomes unreachable. 395 The procedures to determine if a node is unreachable is a local 396 decision and not spelled out in this document. Typically link 397 failure or Bidirectional Forwarding Detection (BFD) can be used to 398 determine and detect node unreachability. 400 4. Link or node failure 402 Consider the following topology; 404 root 405 ^ 406 | 407 . (LSR1) 408 . / | . 409 . (M) | . 410 . \ | . 411 . (N) . 412 . / \ . 413 . / \. 414 (LSR2) (LSR3) 415 | | 416 Figure 3. 418 N: The node being protected 419 M: The backup node to protect link LSR1 - N 420 ...; Backup LSPs from LSR1 to LSR2 and LSR3. 422 Assume that LSR1 is the PLR for protected node N, LSR2 and LSR3 are 423 MPTs for node N. When LSR1 discovers that node N is unreachable, it 424 cannot immediately determine whether it is the link from LSR1 to N or 425 the actual node N that has failed. In Figure 3, the link between 426 LSR1 and N is also protected using Fast ReRoute (FRR) [RFC4090] link 427 protection via node M. LSR1 MAY potentially invoke both protection 428 mechanisms at the same time, that is redirection of the traffic using 429 link protection via node M to N, and for node protection directly to 430 LSR1 and LSR2. If only the link failed, LSR2 and LSR3 will receive 431 the packets twice due to the two protection mechanisms. To prevent 432 duplicate packets being forwarded to the receivers on the tree, LSR2 433 and LSR3 need to determine from which upstream node they should 434 accept the packets. This can be either from the primary upstream LSR 435 N or from the secondary upstream LSR1, but never both at the same 436 time. The selection between the primary upstream LSR or (one or 437 more) secondary upstream LSRs (on LSR2 and LSR3) is based on the 438 reachability of the protected node N. As long as N is reachable from 439 an MPT, the MPT should accept and forward the MPLS packets from N. 440 Once N becomes unreachable, the LSPs from secondary upstream PLR LSRs 441 (LSR1 in our example) are activated. Note that detecting if N is 442 unreachable is a local decision and not spelled out in this document. 444 Typically link failure or Bidirectional Forwarding Detection (BFD) 445 can be used to determine and detect node unreachability. 447 4.1. Re-convergence after node/link failure 449 Consider the following topology; 451 root 452 ^ 453 _ | 454 /. (LSR1) 455 /. /. | .\ 456 /. (M). | .\ 457 (P). \. | .\ 458 \. ( N ) .(Q) 459 \. / \ ./ 460 \. / \ ./ 461 (LSR2) (LSR3) 462 | | 463 Figure 4. 465 N: The node being protected. 466 M: The backup node to protect link 'LSR1 - N'. 467 P and Q: The nodes on the new primary path after failure of node N. 468 ...: P2P backup LSPs. 470 Assume that LSR1 has detected that Node N is unreachable and invoked 471 both the Link Protection and Node Protection procedures as described 472 in this example. LSR1 is acting as PLR and sending traffic over both 473 the backup P2P LSP to node N (via M) and the P2P LSPs directly to 474 LSR2 and LSR3, acting as MPT LSRs. The sequence of events is 475 dependent on whether the link from LSR1 to N has failed or node N 476 itself. The nodes downstream from the protected node (and 477 participating in node protection) MUST have the capability to 478 determine that the protected node has become unreachable. Otherwise 479 the procedures below can not be applied. 481 4.1.1. Node failure 483 If node N failed, both LSR2 and LSR3 will have changed the primary 484 upstream LSR to the secondary upstream LSR (LSR1) due to node N being 485 unreachable. With that, the label bindings previously assigned to 486 LSR1 will be activated on the MPTs (LSR2 and LSR3) and the label 487 binding to N will be disabled. Traffic is now switched over to the 488 label bindings that were installed for node protection. 490 4.1.2. Link failure 492 If the link 'LSR1 - N' has failed, both LSR2 and LSR3 will not change 493 the primary upstream LSR because node N is still reachable. LSR2 and 494 LSR3 will receive traffic over two different bindings, the primary 495 label binding assigned to node N (due to link protection via node M) 496 as well as over the binding assigned to LSR1 for the node protection. 497 Since the secondary upstream LSRs have not been activated, the 498 traffic received due to node protection will be dropped. Node N will 499 re-converge and update LSR2 and LSR3 (Section 2.3) with the 500 information that the PLR address (LSR1) is no longer applicable and 501 must be removed. In response, LSR2 and LSR3 MUST send a Label 502 Withdraw to LSR1 to withdraw the label binding. This will stop the 503 traffic being forwarded over the backup P2P LSPs for node protection. 504 LSR1 will respond back with a Label Release as soon as the binding 505 has been removed. 507 4.1.3. Switching to new primary path 509 The network will eventually re-converge and a new best path to the 510 root will be found by LSR2 and LSR3. LSR2 will find that P is its 511 new primary upstream LSR to reach the Root and LSR3 will find Q. Note 512 that although the current active upstream LSR can either be node N or 513 LSR1 (depending on link or node failure), it does not matter for the 514 following procedures. Both LSR2 and LSR3 SHOULD use the Make-Before- 515 Break (MBB) procedures as described in [RFC6388] section 8 to switch 516 to the new primary upstream node. As soon as the new primary 517 upstream LSRs P and Q are activated, a Label Withdraw message MUST be 518 sent to the old upstream LSR. Note that an upstream LSR switchover 519 from a tLDP neighbor to a directly connected LDP neighbor is no 520 different compared to switching between two directly connected 521 neighbors. After the Label Withdraw message has been received by 522 LSR1 or node N, forwarding will stop and a Label Release will be 523 sent. 525 When it is determined that after re-convergence there is no more 526 interest in the tLDP session between the MPT and the PLR, the tLDP 527 session MAY be taken down. It is possible that having no more 528 interest in the tLDP session is temporarily due to link flapping. In 529 order to avoid the tLDP session from flapping, it is RECOMMENDED to 530 apply a delay before tearing down the session. Determining the delay 531 is a local implementation matter. 533 5. mLDP Capabilities for Node Protection 535 In order to describe the capabilities of the participating LSRs, this 536 document is organizing it per role in the network i.e., Point of 537 Local Repair (PLR), Merge Point (MPT), and Protected Node (as 538 depicted in Fig 1). 540 5.1. PLR capability 542 A PLR node should handle the following conditions; 544 1. Accept an incoming tLDP session from the MPT LSR. 546 2. Support the receipt of a "Protected Node Status Value Element" 547 status in a MP Status TLV over tLDP session. 549 3. Upon node failure detection, capable of switching traffic towards 550 one or more MPT(s) over P2P LSP (bypassing N) using the labels 551 previously advertised for MP LSPs over the tLDP session. 553 An LSR capable of performing these actions will advertise it self as 554 PLR capable in the Node Protection capability (see Section 5.4). 555 This is a unidirectional capability announced from PLR to the 556 protected LSR. 558 5.2. MPT capability 560 An MPT node should handle the following conditions; 562 1. Support the receipt of "PLR Status Value Element" in a MP Status 563 TLV from a protected node N. 565 2. Support to transmit "Protected Node Status Value Element" in a MP 566 Status TLV to a PLR. 568 A LSR capable of performing these actions will advertise itself as 569 MPT capable in the Node Protection capability (see Section 5.4). 570 This is a unidirectional capability from MPT to the protected LSR. 572 5.3. The Protected LSR 574 A protected node should handle the following conditions; 576 1. Determine the PLR and MPT capability for directly connected 577 upstream and downstream LSRs for a given MP FEC. 579 2. Support transmitting of "PLR Status Value Element" in a MP Status 580 TLV to one or more downstream MPT LSRs. 582 The protected LSR does not advertise any capability for mLDP Node 583 Protection because it does not need to receive any of the defined MP 584 Status values as described above. However, the protected node does 585 play an important role in the signaling and setup of the node 586 protection. For a given FEC, the protected node can only send PLR 587 information to a downstream LSR if the PLR has signaled the PLR 588 capability and the downstream LSR has signaled the MPT capability. 589 When the downstream LSR (acting as MPT) receives the PLR status, it 590 can implicitly infer that the advertised LSR(s) are PLR capable. The 591 MPT LSR can now proceed with setting up a tLDP session with the 592 PLR(s) and MP LSP node protection signaling. 594 5.4. The Node Protection Capability 596 We define a single capability "MP Node Protection Capability" to 597 announce the PLR and MPT capability. 599 The format of the capability parameter TLV is as follows: 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 |U|F| Type = TBA-3 | Length = 2 | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 |S| Reserved |P|M| Reserved | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Where 611 U/F bits: MUST be set to 1 and 0 respectively (as per [RFC5561]) 613 Type: MP Node Protection Capability (Type = TBA-3 to be assigned 614 by IANA) 616 Length: Unsigned integer, MUST be set to 2. 618 S bit: Set to 1 to announce and 0 to withdraw the capability (as 619 per [RFC5561]) 621 P bit: Set to 1 to indicate the PLR is capable of MP LSP node 622 protection 624 M bit: Set to 1 to indicate the MPT is capable of MP LSP node 625 protection 627 Reserved: MUST be zero on transmit and ignored on receipt 629 The above capability can be sent in an LDP Initialization message to 630 announce capability at the session establishment time, or it can be 631 sent in LDP Capability message to dynamically update (announce or 632 withdraw) its capability towards its peer using procedures specified 633 in [RFC5561]. 635 An LSR that supports the PLR functionality LSR MAY send this 636 capability to its downstream MP peers with "P" bit set; whereas, an 637 LSR that supports an the MPT functionality MAY send this capability 638 to its upstream peer with "M" bit set. Moreover, an LSR that 639 supports both the PLR and MPT functionality MAY sent this capability 640 to its peers with both "P" and "M" bit set. 642 6. Security Considerations 644 The procedures in this document add two new TLVs to existing LDP 645 messages. Those TLVs can be protected by the mechanisms that are 646 used to protect LDP messages as described in [RFC6388] and [RFC5920]. 647 If it were possible to attack the mechanisms described in this 648 document an LSR (a PLR or a MPT) could be induced to support a large 649 number of tLDP sessions and set up an even larger number of LSPs. 650 The security mechanisms in [RFC6388] and [RFC5920] are believed to be 651 adequate, but an implementation could provide additional protection 652 by counting such protection sessions and LSPs and producing a log 653 message to the operator if a threshold is crossed. 655 7. IANA considerations 657 IANA is requested to allocate two new code points from the "LDP MP 658 Status Value Element type" registry within the Label Distribution 659 Protocol (LDP) Parameters; 661 Value | Name | Reference 662 ------+----------------------------------------+----------- 663 TBA-1 | PLR Status Value Element | this doc 664 ------+----------------------------------------+----------- 665 TBA-2 | Protected Node Status Value Element | this doc 667 IANA is requested to assign a new code points for a new Capability 668 Parameter TLV. The code point should be assigned from the IETF 669 Consensus range of the "TLV Type Name Space" registry within the LDP 670 Parameters. The lowest available new code point after 0x0970 should 671 be used. 673 Value | Description | Reference | Notes/Reg Date 674 ------+-------------------------------+-----------+--------------- 675 TBA-3 | MP Node Protection Capability | This doc | 677 8. Acknowledgments 679 The authors like to thank Nagendra Kumar, Duan Hong, Martin 680 Vigoureux, Kenji Fujihira, Loa Andersson for their comments on this 681 document. Also, many thanks to Elwyn Davies and Adrian Farrel for 682 the detailed review and contribution to this document. 684 9. Contributor Addresses 686 Below is a list of other contributing authors in alphabetical order: 688 Eric Rosen 689 Juniper Networks, Inc. 690 10 Technology Park Drive 691 Westford 692 MA 01886 693 USA 694 erosen@juniper.net 696 10. References 698 10.1. Normative References 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997. 703 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 704 Specification", RFC 5036, October 2007. 706 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 707 "Label Distribution Protocol Extensions for Point-to- 708 Multipoint and Multipoint-to-Multipoint Label Switched 709 Paths", RFC 6388, November 2011. 711 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 712 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 714 [RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP 715 Multipoint Extensions on Targeted LDP Sessions", RFC 7060, 716 November 2013. 718 [AFI] "IANA, Address Family Identifier (AFIs), http:// 719 www.iana.org/assignments/address-family-numbers/address- 720 family-numbers.xhtml", July 2013. 722 10.2. Informative References 724 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 725 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 726 May 2005. 728 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 729 Networks", RFC 5920, July 2010. 731 Authors' Addresses 733 IJsbrand Wijnands (editor) 734 Cisco Systems, Inc. 735 De kleetlaan 6a 736 Diegem 1831 737 Belgium 739 Email: ice@cisco.com 741 Kamran Raza 742 Cisco Systems, Inc. 743 2000 Innovation Drive 744 Ottawa Ontario K2K-3E8 745 Canada 747 Email: skraza@cisco.com 749 Alia Atlas 750 Juniper Networks, Inc. 751 10 Technology Park Drive 752 Westford MA 01886 753 USA 755 Email: akatlas@juniper.net 757 Jeff Tantsura 758 Ericsson 759 300 Holger Way 760 San Jose CA 95134 761 USA 763 Email: jeff.tantsura@ericsson.com 764 Quintin Zhao 765 Huawei Technology 766 125 Nagog Technology Park 767 Acton MA 01719 768 USA 770 Email: quintin.zhao@huawei.com