idnits 2.17.1 draft-ietf-mpls-ri-rsvp-frr-04.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 draft header indicates that this document updates RFC4090, but the abstract doesn't seem to directly say this. It does mention RFC4090 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4090, updated by this document, for RFC5378 checks: 2002-02-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 9, 2018) is 2086 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) == Unused Reference: 'RFC8174' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'RFC5439' is defined on line 1111, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-summary-frr-rsvpte-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group C. Ramachandran 3 Internet-Draft Juniper Networks 4 Updates: 4090 (if approved) I. Minei 5 Intended status: Standards Track Google, Inc 6 Expires: February 10, 2019 D. Pacella 7 Verizon 8 T. Saad 9 Cisco Systems Inc. 10 August 9, 2018 12 Refresh Interval Independent FRR Facility Protection 13 draft-ietf-mpls-ri-rsvp-frr-04 15 Abstract 17 RSVP-TE relies on periodic refresh of RSVP messages to synchronize 18 and maintain the LSP related states along the reserved path. In the 19 absence of refresh messages, the LSP related states are automatically 20 deleted. Reliance on periodic refreshes and refresh timeouts are 21 problematic from the scalability point of view. The number of RSVP- 22 TE LSPs that a router needs to maintain has been growing in service 23 provider networks and the implementations should be capable of 24 handling increase in LSP scale. 26 RFC 2961 specifies mechanisms to eliminate the reliance on periodic 27 refresh and refresh timeout of RSVP messages, and enables a router to 28 increase the message refresh interval to values much longer than the 29 default 30 seconds defined in RFC 2205. However, the protocol 30 extensions defined in RFC 4090 for supporting fast reroute (FRR) 31 using bypass tunnels implicitly rely on short refresh timeouts to 32 cleanup stale states. 34 In order to eliminate the reliance on refresh timeouts, the routers 35 should unambiguously determine when a particular LSP state should be 36 deleted. Coupling LSP state with the corresponding RSVP-TE signaling 37 adjacencies as recommended in RFC 8370 will apply in scenarios other 38 than RFC 4090 FRR using bypass tunnels. In scenarios involving RFC 39 4090 FRR using bypass tunnels, additional explicit tear down messages 40 are necessary. Refresh-interval Independent RSVP FRR (RI-RSVP-FRR) 41 extensions specified in this document consists of procedures to 42 enable LSP state cleanup that are essential in scenarios not covered 43 by procedures defined in RSVP-TE Scaling Recommendations. Hence, 44 this document updates the procedures defined in RFC 4090 to support 45 Refresh-Interval Independent RSVP (RI-RSVP) capability specified in 46 RFC 8370. 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC-2119 [RFC2119]. 54 Status of This Memo 56 This Internet-Draft is submitted in full conformance with the 57 provisions of BCP 78 and BCP 79. 59 Internet-Drafts are working documents of the Internet Engineering 60 Task Force (IETF). Note that other groups may also distribute 61 working documents as Internet-Drafts. The list of current Internet- 62 Drafts is at https://datatracker.ietf.org/drafts/current/. 64 Internet-Drafts are draft documents valid for a maximum of six months 65 and may be updated, replaced, or obsoleted by other documents at any 66 time. It is inappropriate to use Internet-Drafts as reference 67 material or to cite them other than as "work in progress." 69 This Internet-Draft will expire on February 10, 2019. 71 Copyright Notice 73 Copyright (c) 2018 IETF Trust and the persons identified as the 74 document authors. All rights reserved. 76 This document is subject to BCP 78 and the IETF Trust's Legal 77 Provisions Relating to IETF Documents 78 (https://trustee.ietf.org/license-info) in effect on the date of 79 publication of this document. Please review these documents 80 carefully, as they describe your rights and restrictions with respect 81 to this document. Code Components extracted from this document must 82 include Simplified BSD License text as described in Section 4.e of 83 the Trust Legal Provisions and are provided without warranty as 84 described in the Simplified BSD License. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 89 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 90 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 91 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5 92 4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7 93 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP 94 Capability . . . . . . . . . . . . . . . . . . . . . . . 8 95 4.2. Signaling Handshake between PLR and MP . . . . . . . . . 8 96 4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 8 97 4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 9 98 4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10 99 4.2.4. "Remote" state on MP . . . . . . . . . . . . . . . . 11 100 4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12 101 4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12 102 4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 12 103 4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 12 104 4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 14 105 4.4. Conditional Path Tear . . . . . . . . . . . . . . . . . . 14 106 4.4.1. Sending Conditional Path Tear . . . . . . . . . . . . 14 107 4.4.2. Processing Conditional Path Tear . . . . . . . . . . 15 108 4.4.3. CONDITIONS object . . . . . . . . . . . . . . . . . . 15 109 4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 16 110 4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 17 111 4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 17 112 4.5.3. LSP Preemption during Local Repair . . . . . . . . . 17 113 4.5.3.1. Preemption on LP-MP after Phop Link failure . . . 17 114 4.5.3.2. Preemption on NP-MP after Phop Link failure . . . 18 115 4.6. Backward Compatibility Procedures . . . . . . . . . . . . 18 116 4.6.1. Detecting Support for Refresh interval Independent 117 FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19 118 4.6.2. Procedures for backward compatibility . . . . . . . . 19 119 4.6.2.1. Lack of support on Downstream Node . . . . . . . 19 120 4.6.2.2. Lack of support on Upstream Node . . . . . . . . 20 121 4.6.2.3. Incremental Deployment . . . . . . . . . . . . . 20 122 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 123 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 124 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 22 125 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 126 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 127 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 128 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 129 9.2. Informative References . . . . . . . . . . . . . . . . . 24 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 132 1. Introduction 134 RSVP-TE Fast Reroute [RFC4090] defines two local repair techniques to 135 reroute label switched path (LSP) traffic over pre-established backup 136 tunnel. Facility backup method allows one or more LSPs traversing a 137 connected link or node to be protected using a bypass tunnel. The 138 many-to-one nature of local repair technique is attractive from 139 scalability point of view. This document enumerates facility backup 140 procedures in RFC 4090 that rely on refresh timeout and hence make 141 facility backup method refresh-interval dependent. The RSVP-TE 142 extensions defined in this document will enhance the facility backup 143 protection mechanism by making the corresponding procedures refresh- 144 interval independent. 146 1.1. Motivation 148 Standard RSVP [RFC2205] maintains state via the generation of RSVP 149 Path/Resv refresh messages. Refresh messages are used to both 150 synchronize state between RSVP neighbors and to recover from lost 151 RSVP messages. The use of Refresh messages to cover many possible 152 failures has resulted in a number of operational problems. 154 - One problem relates to RSVP control plane scaling due to periodic 155 refreshes of Path and Resv messages, another relates to the 156 reliability and latency of RSVP signaling. 158 - An additional problem is the time to clean up the stale state 159 after a tear message is lost. For more on these problems see 160 Section 1 of RSVP Refresh Overhead Reduction Extensions [RFC2961]. 162 The problems listed above adversely affect RSVP control plane 163 scalability and RSVP-TE [RFC3209] inherited these problems from 164 standard RSVP. Procedures specified in [RFC2961] address the above 165 mentioned problems by eliminating dependency on refreshes for state 166 synchronization and for recovering from lost RSVP messages, and by 167 eliminating dependency on refresh timeout for stale state cleanup. 168 Implementing these procedures allows implementations to improve RSVP- 169 TE control plane scalability. For more details on eliminating 170 dependency on refresh timeout for stale state cleanup, refer to 171 "Refresh Interval Independent RSVP" section 3 of RSVP-TE Scaling 172 Techniques [RFC8370]. 174 However, the procedures specified in RSVP-TE Scaling Techniques 175 [RFC8370] do not fully address stale state cleanup for facility 176 backup protection [RFC4090], as facility backup protection still 177 depends on refresh timeouts for stale state cleanup. 179 The procedures specified in this document, in combination with RSVP- 180 TE Scaling Techniques [RFC8370], eliminate facility backup protection 181 dependency on refresh timeouts for stale state cleanup including the 182 cleanup for facility backup protection. The document hence updates 183 the semantics of Refresh-Interval Independent RSVP (RI-RSVP) 184 capability specified in Section 3 of RSVP-TE Scaling Techniques 185 [RFC8370]. 187 The procedures specified in this document assume reliable delivery of 188 RSVP messages, as specified in [RFC2961]. Therefore this document 189 makes support for [RFC2961] a pre-requisite. 191 2. Terminology 193 The reader is expected to be familiar with the terminology in 194 [RFC2205], [RFC3209], [RFC4090] and [RFC4558]. 196 Phop node: Previous-hop router along the label switched path 198 PPhop node: Previous-Previous-hop router along the LSP 200 LP-MP node: Merge Point router at the tail of Link-protecting bypass 201 tunnel 203 NP-MP node: Merge Point router at the tail of Node-protecting bypass 204 tunnel 206 TED: Traffic Engineering Database 208 LSP state: The combination of "path state" maintained as Path State 209 Block (PSB) and "reservation state" maintained as Reservation State 210 Block (RSB) forms an individual LSP state on an RSVP-TE speaker 212 Conditional PathTear: PathTear message containing a suggestion to a 213 receiving downstream router to retain Path state if the receiving 214 router is NP-MP 216 Remote PathTear: PathTear message sent from Point of Local Repair 217 (PLR) to MP to delete LSP state on MP if PLR had not reliably sent 218 backup Path state before 220 3. Problem Description 222 E 223 / \ 224 / \ 225 / \ 226 / \ 227 / \ 228 / \ 229 A ----- B ----- C ----- D 230 \ / 231 \ / 232 \ / 233 \ / 234 \ / 235 \ / 236 F 238 Figure 1: Example Topology 240 In the topology in Figure 1, consider a large number of LSPs from A 241 to D transiting B and C. Assume that refresh interval has been 242 configured to be long of the order of minutes and refresh reduction 243 extensions are enabled on all routers. 245 Also assume that node protection has been configured for the LSPs and 246 the LSPs are protected by each router in the following way 248 - A has made node protection available using bypass LSP A -> E -> C; 249 A is the Point of Local Repair (PLR) and C is Node Protecting 250 Merge Point (NP-MP) 252 - B has made node protection available using bypass LSP B -> F -> D; 253 B is the PLR and D is the NP-MP 255 - C has made link protection available using bypass LSP C -> B -> F 256 -> D; C is the PLR and D is the Link Protecting Merge Point (LP- 257 MP) 259 In the above condition, assume that B-C link fails. The following is 260 the sequence of events that is expected to occur for all protected 261 LSPs under normal conditions. 263 1. B performs local repair and re-directs LSP traffic over the bypass 264 LSP B -> F -> D. 266 2. B also creates backup state for the LSP and triggers sending of 267 backup LSP state to D over the bypass LSP B -> F -> D. 269 3. D receives backup LSP states and merges the backups with the 270 protected LSPs. 272 4. As the link on C, over which the LSP states are refreshed has 273 failed, C will no longer receive state refreshes. Consequently 274 the protected LSP states on C will time out and C will send tear 275 down message for all LSPs. As each router should consider itself 276 as a Merge Point, C will time out the state only after waiting for 277 an additional duration equal to refresh timeout. 279 While the above sequence of events has been described in [RFC4090], 280 there are a few problems for which no mechanism has been specified 281 explicitly. 283 - If the protected LSP on C times out before D receives signaling 284 for the backup LSP, then D would receive PathTear from C prior to 285 receiving signaling for the backup LSP, thus resulting in deleting 286 the LSP state. This would be possible at scale even with default 287 refresh time. 289 - If upon the link failure C is to keep state until its timeout, 290 then with long refresh interval this may result in a large amount 291 of stale state on C. Alternatively, if upon the link failure C is 292 to delete the state and send PathTear to D, this would result in 293 deleting the state on D, thus deleting the LSP. D needs a 294 reliable mechanism to determine whether it is MP or not to 295 overcome this problem. 297 - If head-end A attempts to tear down LSP after step 1 but before 298 step 2 of the above sequence, then B may receive the tear down 299 message before step 2 and delete the LSP state from its state 300 database. If B deletes its state without informing D, with long 301 refresh interval this could cause (large) buildup of stale state 302 on D. 304 - If B fails to perform local repair in step 1, then B will delete 305 the LSP state from its state database without informing D. As B 306 deletes its state without informing D, with long refresh interval 307 this could cause (large) buildup of stale state on D. 309 The purpose of this document is to provide solutions to the above 310 problems which will then make it practical to scale up to a large 311 number of protected LSPs in the network. 313 4. Solution Aspects 315 The solution consists of five parts. 317 - Utilize MP determination mechanism specified in RSVP-TE Summary 318 FRR [I-D.ietf-mpls-summary-frr-rsvpte] that enables the PLR to 319 signal the availability of local protection to the MP. In 320 addition, introduce PLR and MP procedures to establish Node-ID 321 based hello session between the PLR and the MP to detect router 322 failures and to determine capability. See section 4.2 for more 323 details. This part of the solution re-uses some of the extensions 324 defined in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte] 325 and RSVP-TE Scaling Techniques [RFC8370], and the subsequent sub- 326 sections will list the extensions in these drafts that are 327 utilized in this document. 329 - Handle upstream link or node failures by cleaning up LSP states if 330 the node has not found itself as MP through the MP determination 331 mechanism. See section 4.3 for more details. 333 - Introduce extensions to enable a router to send tear down message 334 to the downstream router that enables the receiving router to 335 conditionally delete its local LSP state. See section 4.4 for 336 more details. 338 - Enhance facility protection by allowing a PLR to directly send 339 tear down message to MP without requiring the PLR to either have a 340 working bypass LSP or have already signaled backup LSP state. See 341 section 4.5 for more details. 343 - Introduce extensions to enable the above procedures to be backward 344 compatible with routers along the LSP path running implementation 345 that do not support these procedures. See section 4.6 for more 346 details. 348 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP 349 Capability 351 A node supporting RFC 4090 facility protection FRR MAY set the RI- 352 RSVP capability (I bit) defined in Section 3 of RSVP-TE Scaling 353 Techniques [RFC8370] only if it supports all the extensions specified 354 in the rest of this document. A node supporting RFC 4090 facility 355 bypass FRR but not supporting the extensions specified in this 356 document MUST reset RI-RSVP capability (I bit) in the outgoing Node- 357 ID based Hello messages. Hence, this document updates RFC 4090 by 358 defining extensions and additional procedures over facility 359 protection FRR defined in RFC 4090 in order to advertise RI-RSVP 360 capability [RFC8370]. 362 4.2. Signaling Handshake between PLR and MP 364 4.2.1. PLR Behavior 366 As per the procedures specified in RFC 4090, when a protected LSP 367 comes up and if the "local protection desired" flag is set in the 368 SESSION_ATTRIBUTE object, each node along the LSP path attempts to 369 make local protection available for the LSP. 371 - If the "node protection desired" flag is set, then the node tries 372 to become a PLR by attempting to create a NP-bypass LSP to the 373 NNhop node avoiding the Nhop node on protected LSP path. In case 374 node protection could not be made available, the node attempts to 375 create a LP-bypass LSP to Nhop node avoiding only the link that 376 protected LSP takes to reach Nhop 378 - If the "node protection desired" flag is not set, then the PLR 379 attempts to create a LP-bypass LSP to Nhop node avoiding the link 380 that the protected LSP takes to reach Nhop 382 With regard to the PLR procedures described above and that are 383 specified in RFC 4090, this document specifies the following 384 additional procedures to support RI-RSVP defined in RFC 8370. 386 - While selecting the destination address of the bypass LSP, the PLR 387 SHOULD select the router ID of the NNhop or Nhop node from the 388 Node-ID sub-object included RRO object carried in RESV message. 389 If the MP has not included Node-ID sub-object in RESV RRO and if 390 the PLR and the MP are in the same area, then the PLR may utilize 391 the TED to determine the router ID corresponding to the interface 392 address included by the MP in the RRO object. If the NP-MP in a 393 different IGP area has not included Node-ID sub-object in RRO 394 object, then the PLR SHOULD execute backward compatibility 395 procedures as if the downstream nodes along the LSP do not support 396 the extensions defined in the document (see Section 4.6.2.1). 398 - The PLR SHOULD also include its router ID in a Node-ID sub-object 399 in RRO object carried in PATH message. While including its router 400 ID in the Node-ID sub-object carried in the outgoing PATH message, 401 the PLR MUST include the Node-ID sub-object after including its 402 IPv4/IPv6 address or unnumbered interface ID sub-object. 404 - In parallel to the attempt made to create NP-bypass or LP-bypass, 405 the PLR SHOULD initiate a Node-ID based Hello session to the NNhop 406 or Nhop node respectively to establish the RSVP-TE signaling 407 adjacency. This Hello session is used to detect MP node failure 408 as well as determine the capability of the MP node. If the MP has 409 set the I-bit in CAPABILITY object [RFC8370] carried in Hello 410 message corresponding to Node-ID based Hello session, then the PLR 411 SHOULD conclude that the MP supports refresh-interval independent 412 FRR procedures defined in this document. If the MP has not sent 413 Node-ID based Hello messages or has not set the I-bit in 414 CAPABILITY object [RFC8370], then the PLR SHOULD execute backward 415 compatibility procedures defined in Section 4.6.2.1 of this 416 document. 418 - If the bypass LSP comes up and the PLR has made local protection 419 available for one or more LSPs, then the PLR SHOULD include B- 420 SFRR-Ready Extended Association object and triggers PATH message 421 to be sent for those LSPs. If a B-SFRR-Ready Extended Association 422 object is included in the PATH message, then the encoding and 423 ordering rules object specified in RSVP-TE Summary FRR 424 [I-D.ietf-mpls-summary-frr-rsvpte] MUST be followed. 426 4.2.2. Remote Signaling Adjacency 428 A Node-ID based RSVP-TE Hello session is one in which Node-ID is used 429 in the source and the destination address fields of RSVP Hello 430 messages [RFC4558]. This document extends Node-ID based RSVP Hello 431 session to track the state of any RSVP-TE neighbor that is not 432 directly connected by at least one interface. In order to apply 433 Node-ID based RSVP-TE Hello session between any two routers that are 434 not immediate neighbors, the router that supports the extensions 435 defined in the document SHOULD set TTL to 255 in all outgoing Node-ID 436 based Hello messages exchanged between PLR and MP. The default hello 437 interval for this Node-ID hello session SHOULD be set to the default 438 specified in RSVP-TE Scaling Techniques [RFC8370]. 440 In the rest of the document the term "signaling adjacency", or 441 "remote signaling adjacency" refers specifically to the RSVP-TE 442 signaling adjacency. 444 4.2.3. MP Behavior 446 With regard to the MP procedures that are defined in RFC 4090, this 447 document specifies the following additional procedures to support RI- 448 RSVP defined in RFC 8370. 450 Each node along an LSP path supporting the extensions defined in this 451 document SHOULD also include its router ID in the Node-ID sub-object 452 in the RRO object carried in the RESV message of the LSPs. If the 453 PLR has not included Node-ID sub-object in the RRO object carried in 454 PATH message and if the PLR is in a different IGP area, then the 455 router SHOULD NOT execute the MP procedures specified in this 456 document for those LSPs. Instead, the node SHOULD execute backward 457 compatibility procedures defined in Section 4.6.2.2 as if the 458 upstream nodes along the LSP do not support the extensions defined in 459 this document. 461 The node should determine whether the incoming PATH messages contains 462 B-SFRR-Ready Extended Association object with the Node-ID address of 463 the PLR as the source and its own Node-ID as the destination. In 464 addition the node should determine whether it has an operational 465 remote Node-ID signaling adjacency with the PLR. If either the PLR 466 has not included B-SFRR-Ready Extended Association object or if there 467 is no operational Node-ID signaling adjacency with the PLR or if the 468 PLR has not advertised RI-RSVP capability in its Node-ID based Hello 469 messages, then the node SHOULD execute backward compatibility 470 procedures defined in Section 4.6.2.2. 472 If a matching B-SFRR-Ready Extended Association object is found in 473 the PATH message and if there is an operational remote signaling 474 adjacency with the PLR that has advertised RI-RSVP capability (I-bit) 475 [RFC8370] in its Node-ID based Hello messages, then the node SHOULD 476 consider itself as the MP for the corresponding PLR. The matching 477 and ordering rules for Bypass Summary FRR Extended Association 478 specified in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte] 479 MUST be followed by implementations supporting this document. 481 - If a matching Bypass Summary FRR Extended Association object is 482 included by the PPhop node of an LSP and if a corresponding Node- 483 ID signaling adjacency exists with the PPhop node, then the router 484 SHOULD conclude it is NP-MP. 486 - If a matching Bypass Summary FRR Extended Association object is 487 included by the Phop node of an LSP and if a corresponding Node-ID 488 signaling adjacency exists with the Phop node, then the router 489 SHOULD conclude it is LP-MP. 491 4.2.4. "Remote" state on MP 493 Once a router concludes it is the MP for a PLR running refresh- 494 interval independent FRR procedures, it SHOULD create a remote path 495 state for the LSP. The "remote" state is identical to the protected 496 LSP path state except for the difference in RSVP_HOP object. The 497 RSVP_HOP object in "remote" Path state contains the address that the 498 PLR uses to send Node-ID hello messages to MP. 500 The MP SHOULD consider the "remote" path state automatically deleted 501 if: 503 - MP later receives a PATH with no matching B-SFRR-Ready Extended 504 Association object corresponding to the PLR's IP address contained 505 in PATH RRO, or 507 - Node signaling adjacency with PLR goes down, or 509 - MP receives backup LSP signaling from PLR or 511 - MP receives PathTear, or 513 - MP deletes the LSP state on local policy or exception event 515 Unlike the normal path state that is either locally generated on the 516 Ingress or created from a PATH message from the Phop node, the 517 "remote" path state is not signaled explicitly from PLR. The purpose 518 of "remote" path state is to enable the PLR to explicitly tear down 519 path and reservation states corresponding to the LSP by sending tear 520 message for the "remote" path state. Such message tearing down 521 "remote" path state is called "Remote PathTear". 523 The scenarios in which "Remote" PathTear is applied are described in 524 Section 4.5. 526 4.3. Impact of Failures on LSP State 528 This section describes the procedures for routers on the LSP path for 529 different kinds of failures. The procedures described on detecting 530 RSVP control plane adjacency failures do not impact the RSVP-TE 531 graceful restart mechanisms ([RFC3473], [RFC5063]). If the router 532 executing these procedures act as helper for neighboring router, then 533 the control plane adjacency will be declared as having failed after 534 taking into account the grace period extended for neighbor by the 535 helper. 537 Immediate node failures are detected from the state of Node-ID hello 538 sessions established with immediate neighbors. RSVP-TE Scaling 539 Techniques [RFC8370] recommends each router to establish Node-ID 540 hello sessions with all its immediate neighbors. PLR or MP node 541 failure is detected from the state of remote signaling adjacency 542 established according to Section 4.2.2 of this document. 544 4.3.1. Non-MP Behavior 546 When a router detects Phop link or Phop node failure and the router 547 is not an MP for the LSP, then it SHOULD send Conditional PathTear 548 (refer to Section 4.4 "Conditional PathTear" below) and delete PSB 549 and RSB states corresponding to the LSP. 551 4.3.2. LP-MP Behavior 553 When the Phop link for an LSP fails on a router that is LP-MP for the 554 LSP, the LP-MP SHOULD retain PSB and RSB states corresponding to the 555 LSP till the occurrence of any of the following events. 557 - Node-ID signaling adjacency with Phop PLR goes down, or 559 - MP receives normal or "Remote" PathTear for PSB, or 561 - MP receives ResvTear RSB. 563 When a router that is LP-MP for an LSP detects Phop node failure from 564 Node-ID signaling adjacency state, the LP-MP SHOULD send normal 565 PathTear and delete PSB and RSB states corresponding to the LSP. 567 4.3.3. NP-MP Behavior 569 When a router that is NP-MP for an LSP detects Phop link failure, or 570 Phop node failure from Node-ID signaling adjacency, the router SHOULD 571 retain PSB and RSB states corresponding to the LSP till the 572 occurrence of any of the following events. 574 - Remote Node-ID signaling adjacency with PPhop PLR goes down, or 576 - MP receives normal or "Remote" PathTear for PSB, or 578 - MP receives ResvTear for RSB. 580 When a router that is NP-MP does not detect Phop link or node 581 failure, but receives Conditional PathTear from the Phop node, then 582 the router SHOULD retain PSB and RSB states corresponding to the LSP 583 till the occurrence of any of the following events. 585 - Remote Node-ID signaling adjacency with PPhop PLR goes down, or 587 - MP receives normal or "Remote" PathTear for PSB, or 589 - MP receives ResvTear for RSB. 591 Receiving Conditional PathTear from the Phop node will not impact the 592 "remote" state from the PPhop PLR. Note that Phop node would send 593 Conditional PathTear if it was not an MP. 595 In the example topology in Figure 1, assume C & D are NP-MP for PLRs 596 A & B respectively. Now when A-B link fails, as B is not MP and its 597 Phop link has failed, B will delete LSP state (this behavior is 598 required for unprotected LSPs - Section 4.3.1). In the data plane, 599 that would require B to delete the label forwarding entry 600 corresponding to the LSP. So if B's downstream nodes C and D 601 continue to retain state, it would not be correct for D to continue 602 to assume itself as NP-MP for PLR B. 604 The mechanism that enables D to stop considering itself as the NP-MP 605 for B and delete the corresponding "remote" path state is given 606 below. 608 1. When C receives Conditional PathTear from B, it decides to retain 609 LSP state as it is NP-MP of PLR A. C also SHOULD check whether 610 Phop B had previously signaled availability of node protection. 611 As B had previously signaled NP availability by including B-SFRR- 612 Ready Extended Association object, C SHOULD remove the B-SFRR- 613 Ready Extended Association object containing Association Source 614 set to B from the PATH message and trigger PATH to D. 616 2. When D receives triggered PATH, it realizes that it is no longer 617 the NP-MP for B and so it deletes the corresponding "remote" path 618 state. D does not propagate PATH further down because the only 619 change is that the B-SFRR-Ready Extended Association object 620 corresponding to Association Source B is no longer present in the 621 PATH message. 623 4.3.4. Behavior of a Router that is both LP-MP and NP-MP 625 A router may be both LP-MP as well as NP-MP at the same time for Phop 626 and PPhop nodes respectively of an LSP. If Phop link fails on such 627 node, the node SHOULD retain PSB and RSB states corresponding to the 628 LSP till the occurrence of any of the following events. 630 - Both Node-ID signaling adjacencies with Phop and PPhop nodes go 631 down, or 633 - MP receives normal or "Remote" PathTear for PSB, or 635 - MP receives ResvTear for RSB. 637 If a router that is both LP-MP and NP-MP detects Phop node failure, 638 then the node SHOULD retain PSB and RSB states corresponding to the 639 LSP till the occurrence of any of the following events. 641 - Remote Node-ID signaling adjacency with PPhop PLR goes down, or 643 - MP receives normal or "Remote" PathTear for PSB, or 645 - MP receives ResvTear for RSB. 647 4.4. Conditional Path Tear 649 In the example provided in the Section 4.3.3, B deletes PSB and RSB 650 states corresponding to the LSP once B detects its link to Phop went 651 down as B is not MP. If B were to send PathTear normally, then C 652 would delete LSP state immediately. In order to avoid this, there 653 should be some mechanism by which B can indicate to C that B does not 654 require the receiving node to unconditionally delete the LSP state 655 immediately. For this, B SHOULD add a new optional object called 656 CONDITIONS object in PathTear. The new optional object is defined in 657 Section 4.4.3. If node C also understands the new object, then C 658 SHOULD delete LSP state only if it is not an NP-MP - in other words C 659 SHOULD delete LSP state if there is no "remote" PLR path state on C. 661 4.4.1. Sending Conditional Path Tear 663 A router that is not an MP for an LSP SHOULD delete PSB and RSB 664 states corresponding to the LSP if Phop link or Phop Node-ID 665 signaling adjacency goes down (Section 4.3.1). The router SHOULD 666 send Conditional PathTear if the following are also true. 668 - Ingress has requested node protection for the LSP, and 670 - PathTear is not received from the upstream node 672 4.4.2. Processing Conditional Path Tear 674 When a router that is not an NP-MP receives Conditional PathTear, the 675 node SHOULD delete PSB and RSB states corresponding to the LSP, and 676 process Conditional PathTear by considering it as normal PathTear. 677 Specifically, the node SHOULD NOT propagate Conditional PathTear 678 downstream but remove the optional object and send normal PathTear 679 downstream. 681 When a node that is an NP-MP receives Conditional PathTear, it SHOULD 682 NOT delete LSP state. The node SHOULD check whether the Phop node 683 had previously included B-SFRR-Ready Extended Association object in 684 PATH. If the object had been included previously by the Phop, then 685 the node processing Conditional PathTear from the Phop SHOULD remove 686 the corresponding object and trigger PATH downstream. 688 If Conditional PathTear is received from a neighbor that has not 689 advertised support (refer to Section 4.6) for the new procedures 690 defined in this document, then the node SHOULD consider the message 691 as normal PathTear. The node SHOULD propagate normal PathTear 692 downstream and delete the LSP state. 694 4.4.3. CONDITIONS object 696 As any implementation that does not support Conditional PathTear 697 SHOULD ignore the new object but process the message as normal 698 PathTear without generating any error, the Class-Num of the new 699 object SHOULD be 10bbbbbb where 'b' represents a bit (from 700 Section 3.10 of [RFC2205]). 702 The new object is called as "CONDITIONS" object that will specify the 703 conditions under which default processing rules of the RSVP-TE 704 message SHOULD be invoked. 706 The object has the following format: 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Length | Class | C-type | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Reserved |M| 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Figure 2: CONDITIONS Object 716 Length 717 This contains the size of the object in bytes and should be set to 718 eight. 720 Class 721 To be assigned 723 C-type 724 1 726 M bit 727 If M-bit is set to 1, then the PathTear message SHOULD be 728 processed based on the condition if the receiver router is a Merge 729 Point or not. 730 If M-bit is set to 0, then the PathTear message SHOULD be 731 processed as normal PathTear message. 733 4.5. Remote State Teardown 735 If the Ingress wants to tear down the LSP because of a management 736 event while the LSP is being locally repaired at a transit PLR, it 737 would not be desirable to wait till the completion of backup LSP 738 signaling to perform state cleanup. To enable LSP state cleanup when 739 the LSP is being locally repaired, the PLR SHOULD send "remote" 740 PathTear message instructing the MP to delete PSB and RSB states 741 corresponding to the LSP. The TTL in "remote" PathTear message 742 SHOULD be set to 255. 744 Consider node C in example topology (Figure 1) has gone down and B 745 locally repairs the LSP. 747 1. Ingress A receives a management event to tear down the LSP. 749 2. A sends normal PathTear to B. 751 3. Assume B has not initiated backup signaling for the LSR. To 752 enable LSP state cleanup, B SHOULD send "remote" PathTear with 753 destination IP address set to that of D used in Node-ID signaling 754 adjacency with D, and RSVP_HOP object containing local address 755 used in Node-ID signaling adjacency. 757 4. B then deletes PSB and RSB states corresponding to the LSP. 759 5. On D there would be a remote signaling adjacency with B and so D 760 SHOULD accept the remote PathTear and delete PSB and RSB states 761 corresponding to the LSP. 763 4.5.1. PLR Behavior on Local Repair Failure 765 If local repair fails on the PLR after a failure, then this should be 766 considered as a case for cleaning up LSP state from PLR to the 767 Egress. PLR would achieve this using "remote" PathTear to clean up 768 state from MP. If MP has retained state, then it would propagate 769 PathTear downstream thereby achieving state cleanup. Note that in 770 the case of link protection, the PathTear would be directed to LP-MP 771 node IP address rather than the Nhop interface address. 773 4.5.2. PLR Behavior on Resv RRO Change 775 When a router that has already made NP available detects a change in 776 the RRO carried in RESV message, and if the RRO change indicates that 777 the router's former NP-MP is no longer present in the LSP path, then 778 the router SHOULD send "Remote" PathTear directly to its former NP- 779 MP. 781 In the example topology in Figure 1, assume A has made node 782 protection available and C has concluded it is the NP-MP for A. When 783 the B-C link fails then C, implementing the procedure specified in 784 Section 4.3.4 of this document, will retain state till: remote Node- 785 ID signaling adjacency with A goes down, or PathTear or ResvTear is 786 received for PSB or RSB respectively. If B also has made node 787 protection available, B will eventually complete backup LSP signaling 788 with its NP-MP D and trigger RESV to A with RRO changed. The new RRO 789 of the LSP carried in RESV will not contain C. When A processes the 790 RESV with a new RRO not containing C - its former NP-MP, A SHOULD 791 send "Remote" PathTear to C. When C receives a "Remote" PathTear for 792 its PSB state, C will send normal PathTear downstream to D and delete 793 both PSB and RSB states corresponding to the LSP. As D has already 794 received backup LSP signaling from B, D will retain control plane and 795 forwarding states corresponding to the LSP. 797 4.5.3. LSP Preemption during Local Repair 799 4.5.3.1. Preemption on LP-MP after Phop Link failure 801 If an LSP is preempted on LP-MP after its Phop or incoming link has 802 already failed but the backup LSP has not been signaled yet, then the 803 node SHOULD send normal PathTear and delete both PSB and RSB states 804 corresponding to the LSP. As the LP-MP has retained LSP state 805 expecting the PLR to perform backup LSP signaling, preemption would 806 bring down the LSP and the node would not be LP-MP any more requiring 807 the node to clean up LSP state. 809 4.5.3.2. Preemption on NP-MP after Phop Link failure 811 If an LSP is preempted on NP-MP after its Phop link has already 812 failed but the backup LSP has not been signaled yet, then the node 813 SHOULD send normal PathTear and delete PSB and RSB states 814 corresponding to the LSP. As the NP-MP has retained LSP state 815 expecting the PLR to perform backup LSP signaling, preemption would 816 bring down the LSP and the node would not be NP-MP any more requiring 817 the node to clean up LSP state. 819 Consider B-C link goes down on the same example topology (Figure 1). 820 As C is NP-MP for PLR A, C will retain LSP state. 822 1. The LSP is preempted on C. 824 2. C will delete RSB state corresponding to the LSP. But C cannot 825 send PathErr or ResvTear to PLR A because backup LSP has not been 826 signaled yet. 828 3. As the only reason for C having retained state after Phop node 829 failure was that it was NP-MP, C SHOULD send normal PathTear to D 830 and delete PSB state also. D would also delete PSB and RSB states 831 on receiving PathTear from C. 833 4. B starts backup LSP signaling to D. But as D does not have the 834 LSP state, it will reject backup LSP PATH and send PathErr to B. 836 5. B will delete its reservation and send ResvTear to A. 838 4.6. Backward Compatibility Procedures 840 The "Refresh interval Independent FRR" or RI-RSVP-FRR referred below 841 in this section refers to the changes that have been proposed in 842 previous sections. Any implementation that does not support them has 843 been termed as "non-RI-RSVP-FRR implementation". The extensions 844 proposed in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte] 845 are applicable to implementations that do not support RI-RSVP-FRR. 846 On the other hand, changes proposed relating to LSP state cleanup 847 namely Conditional and remote PathTear require support from one-hop 848 and two-hop neighboring nodes along the LSP path. So procedures that 849 fall under LSP state cleanup category SHOULD be turned on only if all 850 nodes involved in the node protection FRR i.e. PLR, MP and 851 intermediate node in the case of NP, support the extensions. Note 852 that for LSPs requesting only link protection, the PLR and the LP-MP 853 should support the extensions. 855 4.6.1. Detecting Support for Refresh interval Independent FRR 857 An implementation supporting the extensions specified in previous 858 sections (called RI-RSVP-FRR here after) SHOULD set the flag "Refresh 859 interval Independent RSVP" or RI-RSVP in CAPABILITY object carried in 860 Hello messages. The RI-RSVP flag is specified in RSVP-TE Scaling 861 Techniques [RFC8370]. 863 - As nodes supporting the extensions SHOULD initiate Node Hellos 864 with adjacent nodes, a node on the path of protected LSP can 865 determine whether its Phop or Nhop neighbor supports RI-RSVP-FRR 866 enhancements from the Hello messages sent by the neighbor. 868 - If a node attempts to make node protection available, then the PLR 869 SHOULD initiate remote Node-ID signaling adjacency with NNhop. If 870 the NNhop (a) does not reply to remote node Hello message or (b) 871 does not set RI-RSVP flag in CAPABILITY object carried in its 872 Node-ID Hello messages, then the PLR can conclude that NNhop does 873 not support RI-RSVP-FRR extensions. 875 - If node protection is requested for an LSP and if (a) PPhop node 876 has not included a matching B-SFRR-Ready Extended Association 877 object in PATH or (b) PPhop node has not initiated remote node 878 Hello messages or (c) PPhop node does not set RI-RSVP flag in 879 CAPABILITY object carried in its Node-ID Hello messages, then the 880 node SHOULD conclude that the PLR does not support RI-RSVP-FRR 881 extensions. The details are described in the "Procedures for 882 backward compatibility" section below. 884 4.6.2. Procedures for backward compatibility 886 The procedures defined hereafter are performed on a subset of LSPs 887 that traverse a node, rather than on all LSPs that traverse a node. 888 This behavior is required to support backward compatibility for a 889 subset of LSPs traversing nodes running non-RI-RSVP-FRR 890 implementations. 892 4.6.2.1. Lack of support on Downstream Node 894 The procedures on the downstream direction are as follows. 896 - If the Nhop does not support the RI-RSVP-FRR extensions, then the 897 node SHOULD reduce the "refresh period" in TIME_VALUES object 898 carried in PATH to default short refresh default value. 900 - If node protection is requested and the NNhop node does not 901 support the enhancements, then the node SHOULD reduce the "refresh 902 period" in TIME_VALUES object carried in PATH to a short refresh 903 default value. 905 If the node reduces the refresh time from the above procedures, it 906 SHOULD also not send remote PathTear or Conditional PathTear 907 messages. 909 Consider the example topology in Figure 1. If C does not support the 910 RI-RSVP-FRR extensions, then: 912 - A and B SHOULD reduce the refresh time to default value of 30 913 seconds and trigger PATH 915 - If B is not an MP and if Phop link of B fails, B cannot send 916 Conditional PathTear to C but SHOULD time out PSB state from A 917 normally. This would be accomplished if A would also reduce the 918 refresh time to default value. So if C does not support the RI- 919 RSVP-FRR extensions, then Phop B and PPhop A SHOULD reduce refresh 920 time to a small default value. 922 4.6.2.2. Lack of support on Upstream Node 924 The procedures on the upstream direction are as follows. 926 - If Phop node does not support the RI-RSVP-FRR extensions, then the 927 node SHOULD reduce the "refresh period" in TIME_VALUES object 928 carried in RESV to default short refresh time value. 930 - If node protection is requested and the Phop node does not support 931 the RI-RSVP-FRR extensions, then the node SHOULD reduce the 932 "refresh period" in TIME_VALUES object carried in PATH to default 933 value. 935 - If node protection is requested and PPhop node does not support 936 the RI-RSVP-FRR extensions, then the node SHOULD reduce the 937 "refresh period" in TIME_VALUES object carried in RESV to default 938 value. 940 - If the node reduces the refresh time from the above procedures, it 941 SHOULD also not execute MP procedures specified in Section 4.3 of 942 this document. 944 4.6.2.3. Incremental Deployment 946 The backward compatibility procedures described in the previous sub- 947 sections imply that a router supporting the RI-RSVP-FRR extensions 948 specified in this document can apply the procedures specified in the 949 document either in the downstream or upstream direction of an LSP, 950 depending on the capability of the routers downstream or upstream in 951 the LSP path. 953 - RI-RSVP-FRR extensions and procedures are enabled for downstream 954 Path, PathTear and ResvErr messages corresponding to an LSP if 955 link protection is requested for the LSP and the Nhop node 956 supports the extensions 958 - RI-RSVP-FRR extensions and procedures are enabled for downstream 959 Path, PathTear and ResvErr messages corresponding to an LSP if 960 node protection is requested for the LSP and both Nhop & NNhop 961 nodes support the extensions 963 - RI-RSVP-FRR extensions and procedures are enabled for upstream 964 PathErr, Resv and ResvTear messages corresponding to an LSP if 965 link protection is requested for the LSP and the Phop node 966 supports the extensions 968 - RI-RSVP-FRR extensions and procedures are enabled for upstream 969 PathErr, Resv and ResvTear messages corresponding to an LSP if 970 node protection is requested for the LSP and both Phop and PPhop 971 nodes support the extensions 973 For example, if an implementation supporting the RI-RSVP-FRR 974 extensions specified in this document is deployed on all routers in 975 particular region of the network and if all the LSPs in the network 976 request node protection, then the FRR extensions will only be applied 977 for the LSP segments that traverse the particular region. This will 978 aid incremental deployment of these extensions and also allow reaping 979 the benefits of the extensions in portions of the network where it is 980 supported. 982 5. Security Considerations 984 The security considerations pertaining to the original RSVP protocol 985 [RFC2205], [RFC3209] and [RFC5920] remain relevant. 987 This document extends the applicability of Node-ID based Hello 988 session between immediate neighbors. The Node-ID based Hello session 989 between PLR and NP-MP may require the two routers to exchange Hello 990 messages with non-immediate neighbor. So, the implementations SHOULD 991 provide the option to configure Node-ID neighbor specific or global 992 authentication key to authentication messages received from Node-ID 993 neighbors. The network administrator MAY utilize this option to 994 enable RSVP-TE routers to authenticate Node-ID Hello messages 995 received with TTL greater than 1. Implementations SHOULD also 996 provide the option to specify a limit on the number of Node-ID based 997 Hello sessions that can be established on a router supporting the 998 extensions defined in this document. 1000 6. IANA Considerations 1002 6.1. New Object - CONDITIONS 1004 RSVP Change Guidelines [RFC3936] defines the Class-Number name space 1005 for RSVP objects. The name space is managed by IANA. 1007 IANA registry: RSVP Parameters 1008 Subsection: Class Names, Class Numbers, and Class Types 1010 A new RSVP object using a Class-Number from 128-183 range called the 1011 "CONDITIONS" object is defined in Section 4.4 of this document. The 1012 Class-Number from 128-183 range will be allocated by IANA. 1014 7. Acknowledgements 1016 We are very grateful to Yakov Rekhter for his contributions to the 1017 development of the idea and thorough review of content of the draft. 1018 Thanks to Raveendra Torvi and Yimin Shen for their comments and 1019 inputs. 1021 8. Contributors 1023 Markus Jork 1024 Juniper Networks 1025 Email: mjork@juniper.net 1027 Harish Sitaraman 1028 Juniper Networks 1029 Email: hsitaraman@juniper.net 1031 Vishnu Pavan Beeram 1032 Juniper Networks 1033 Email: vbeeram@juniper.net 1035 Ebben Aries 1036 Juniper Networks 1037 Email: exa@juniper.net 1039 Mike Taillon 1040 Cisco Systems Inc. 1041 Email: mtaillon@cisco.com 1043 9. References 1045 9.1. Normative References 1047 [I-D.ietf-mpls-summary-frr-rsvpte] 1048 Taillon, M., Saad, T., Gandhi, R., Deshmukh, A., Jork, M., 1049 and V. Beeram, "RSVP-TE Summary Fast Reroute Extensions 1050 for LSP Tunnels", draft-ietf-mpls-summary-frr-rsvpte-01 1051 (work in progress), April 2018. 1053 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1054 Requirement Levels", BCP 14, RFC 2119, 1055 DOI 10.17487/RFC2119, March 1997, 1056 . 1058 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1059 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1060 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1061 September 1997, . 1063 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1064 and S. Molendini, "RSVP Refresh Overhead Reduction 1065 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 1066 . 1068 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1069 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1070 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1071 . 1073 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1074 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1075 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1076 DOI 10.17487/RFC3473, January 2003, 1077 . 1079 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 1080 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 1081 DOI 10.17487/RFC3936, October 2004, 1082 . 1084 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1085 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1086 DOI 10.17487/RFC4090, May 2005, 1087 . 1089 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 1090 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 1091 A Clarification Statement", RFC 4558, 1092 DOI 10.17487/RFC4558, June 2006, 1093 . 1095 [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to 1096 GMPLS Resource Reservation Protocol (RSVP) Graceful 1097 Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, 1098 . 1100 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1101 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1102 May 2017, . 1104 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 1105 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 1106 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 1107 . 1109 9.2. Informative References 1111 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 1112 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 1113 DOI 10.17487/RFC5439, February 2009, 1114 . 1116 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1117 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1118 . 1120 Authors' Addresses 1122 Chandra Ramachandran 1123 Juniper Networks 1125 Email: csekar@juniper.net 1127 Ina Minei 1128 Google, Inc 1130 Email: inaminei@google.com 1131 Dante Pacella 1132 Verizon 1134 Email: dante.j.pacella@verizon.com 1136 Tarek Saad 1137 Cisco Systems Inc. 1139 Email: tsaad@cisco.com