idnits 2.17.1 draft-ietf-mpls-ri-rsvp-frr-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 : ---------------------------------------------------------------------------- No issues found here. 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 (September 3, 2019) is 1697 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-summary-frr-rsvpte-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group C. Ramachandran 3 Internet-Draft T. Saad 4 Updates: 4090 (if approved) Juniper Networks, Inc. 5 Intended status: Standards Track I. Minei 6 Expires: March 6, 2020 Google, Inc. 7 D. Pacella 8 Verizon, Inc. 9 September 3, 2019 11 Refresh-interval Independent FRR Facility Protection 12 draft-ietf-mpls-ri-rsvp-frr-07 14 Abstract 16 RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two 17 local repair techniques to reroute Label Switched Path (LSP) traffic 18 over pre-established backup tunnel. Facility backup method allows 19 one or more LSPs traversing a connected link or node to be protected 20 using a bypass tunnel. The many-to-one nature of local repair 21 technique is attractive from scalability point of view. This 22 document enumerates facility backup procedures in RFC 4090 that rely 23 on refresh timeout and hence make facility backup method refresh- 24 interval dependent. The RSVP-TE extensions defined in this document 25 will enhance the facility backup protection mechanism by making the 26 corresponding procedures refresh-interval independent and hence 27 compatible with Refresh-interval Independent RSVP (RI-RSVP) specified 28 in RFC 8370. Hence, this document updates RFC 4090 in order to 29 support RI-RSVP capability specified in RFC 8370. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC-2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 6, 2020. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5 75 4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP 77 Capability . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.2. Signaling Handshake between PLR and MP . . . . . . . . . 8 79 4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9 80 4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10 81 4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10 82 4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 11 83 4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12 84 4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12 85 4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 86 4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 87 4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 14 88 4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15 89 4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15 90 4.4.2. Processing Conditional PathTear . . . . . . . . . . . 15 91 4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16 92 4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 16 93 4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 17 94 4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 17 95 4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18 96 4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 18 97 4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 18 98 4.6. Backward Compatibility Procedures . . . . . . . . . . . . 19 99 4.6.1. Detecting Support for Refresh interval Independent 100 FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 4.6.2. Procedures for Backward Compatibility . . . . . . . . 20 102 4.6.2.1. Lack of support on Downstream Node . . . . . . . 20 103 4.6.2.2. Lack of support on Upstream Node . . . . . . . . 20 104 4.6.2.3. Incremental Deployment . . . . . . . . . . . . . 21 105 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 107 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 22 108 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 109 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 110 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 111 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 112 9.2. Informative References . . . . . . . . . . . . . . . . . 24 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 115 1. Introduction 117 RSVP-TE relies on periodic refresh of RSVP messages to synchronize 118 and maintain the Label Switched Path (LSP) related states along the 119 reserved path. In the absence of refresh messages, the LSP-related 120 states are automatically deleted. Reliance on periodic refreshes and 121 refresh timeouts are problematic from the scalability point of view. 122 The number of RSVP-TE LSPs that a router needs to maintain has been 123 growing in service provider networks and the implementations should 124 be capable of handling increase in LSP scale. 126 RFC 2961 specifies mechanisms to eliminate the reliance on periodic 127 refresh and refresh timeout of RSVP messages, and enables a router to 128 increase the message refresh interval to values much longer than the 129 default 30 seconds defined in RFC 2205. However, the protocol 130 extensions defined in RFC 4090 for supporting Fast ReRoute (FRR) 131 using bypass tunnels implicitly rely on short refresh timeouts to 132 cleanup stale states. 134 In order to eliminate the reliance on refresh timeouts, the routers 135 should unambiguously determine when a particular LSP state should be 136 deleted. In scenarios involving RFC 4090 FRR using bypass tunnels, 137 additional explicit tear down messages are necessary. Refresh- 138 interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in 139 this document consists of procedures to enable LSP state cleanup that 140 are essential in supporting RI-RSVP capability for RFC 4090 FRR using 141 bypass tunnels. 143 1.1. Motivation 145 Base RSVP [RFC2205] maintains state via the generation of RSVP Path/ 146 Resv refresh messages. Refresh messages are used to both synchronize 147 state between RSVP neighbors and to recover from lost RSVP messages. 148 The use of Refresh messages to cover many possible failures has 149 resulted in a number of operational problems. 151 - One problem relates to RSVP control plane scaling due to periodic 152 refreshes of Path and Resv messages, another relates to the 153 reliability and latency of RSVP signaling. 155 - An additional problem is the time to clean up the stale state 156 after a tear message is lost. For more on these problems see 157 Section 1 of RSVP Refresh Overhead Reduction Extensions [RFC2961]. 159 The problems listed above adversely affect RSVP control plane 160 scalability and RSVP-TE [RFC3209] inherited these problems from 161 standard RSVP. Procedures specified in [RFC2961] address the above 162 mentioned problems by eliminating dependency on refreshes for state 163 synchronization and for recovering from lost RSVP messages, and by 164 eliminating dependency on refresh timeout for stale state cleanup. 165 Implementing these procedures allows implementations to improve RSVP- 166 TE control plane scalability. For more details on eliminating 167 dependency on refresh timeout for stale state cleanup, refer to 168 "Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling 169 Techniques [RFC8370]. 171 However, the facility backup protection procedures specified in 172 [RFC4090] do not fully address stale state cleanup as the procedures 173 depend on refresh timeouts for stale state cleanup. The updated 174 facility backup protection procedures specified in this document, in 175 combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this 176 dependency on refresh timeouts for stale state cleanup. 178 The procedures specified in this document assume reliable delivery of 179 RSVP messages, as specified in [RFC2961]. Therefore this document 180 makes support for [RFC2961] a pre-requisite. 182 2. Terminology 184 The reader is expected to be familiar with the terminology in 185 [RFC2205], [RFC3209], [RFC4090] and [RFC4558]. 187 Phop node: Previous-hop router along the label switched path 189 PPhop node: Previous-Previous-hop router along the label switched 190 path 191 Nhop node: Next-hop router along the label switched path 193 NNhop node: Next-Next-hop router along the label switched path 195 PLR: Point of Local Repair router as defined in [RFC4090] 197 MP: Merge Point router as defined in [RFC4090] 199 LP-MP node: Merge Point router at the tail of Link-Protecting bypass 200 tunnel 202 NP-MP node: Merge Point router at the tail of Node-Protecting bypass 203 tunnel 205 TED: Traffic Engineering Database 207 LSP state: The combination of "path state" maintained as Path State 208 Block (PSB) and "reservation state" maintained as Reservation State 209 Block (RSB) forms an individual LSP state on an RSVP-TE speaker 211 B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object 212 defined in Summary FRR extensions [I-D.ietf-mpls-summary-frr-rsvpte] 213 and is added by the PLR for each protected LSP. 215 Conditional PathTear: A PathTear message containing a suggestion to a 216 receiving downstream router to retain the path state if the receiving 217 router is an NP-MP 219 Remote PathTear: A PathTear message sent from a Point of Local Repair 220 (PLR) to the MP to delete LSP state on the MP if PLR had not reliably 221 sent the backup Path state before 223 3. Problem Description 224 E 225 / \ 226 / \ 227 / \ 228 / \ 229 / \ 230 / \ 231 A ----- B ----- C ----- D 232 \ / 233 \ / 234 \ / 235 \ / 236 \ / 237 \ / 238 F 240 Figure 1: Example Topology 242 In the topology in Figure 1, let us consider a large number of LSPs 243 from A to D transiting B and C. Assume that refresh interval has 244 been configured to be long of the order of minutes and refresh 245 reduction extensions are enabled on all routers. 247 Also let us assume that node protection has been configured for the 248 LSPs and the LSPs are protected by each router in the following way 250 - A has made node protection available using bypass LSP A -> E -> C; 251 A is the PLR and C is the NP-MP 253 - B has made node protection available using bypass LSP B -> F -> D; 254 B is the PLR and D is the NP-MP 256 - C has made link protection available using bypass LSP C -> B -> F 257 -> D; C is the PLR and D is the LP-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 the 275 tear down messages for all LSPs. As each router should consider 276 itself as an MP, 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 a PathTear from C prior 285 to receiving signaling for the backup LSP, thus resulting in 286 deleting the LSP state. This would be possible at scale even with 287 default 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 a 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 an 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 an MP through the MP 331 determination mechanism. See section 4.3 for more details. 333 - Introduce extensions to enable a router to send a tear down 334 message to the downstream router that enables the receiving router 335 to 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 a 339 tear down message to the MP without requiring the PLR to either 340 have a working bypass LSP or have already signaled backup LSP 341 state. See 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 [RFC4090] 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 [RFC4090] facility 355 bypass FRR but not supporting the extensions specified in this 356 document MUST reset the RI-RSVP capability (I bit) in the outgoing 357 Node-ID based Hello messages. Hence, this document updates [RFC4090] 358 by defining extensions and additional procedures over facility 359 protection FRR defined in [RFC4090] in order to advertise RI-RSVP 360 capability [RFC8370]. 362 4.2. Signaling Handshake between PLR and MP 363 4.2.1. PLR Behavior 365 As per the procedures specified in [RFC4090], when a protected LSP 366 comes up and if the "local protection desired" flag is set in the 367 SESSION_ATTRIBUTE object, each node along the LSP path attempts to 368 make local protection available for the LSP. 370 - If the "node protection desired" flag is set, then the node tries 371 to become a PLR by attempting to create a NP-bypass LSP to the 372 NNhop node avoiding the Nhop node on protected LSP path. In case 373 node protection could not be made available, the node attempts to 374 create an LP-bypass LSP to the Nhop node avoiding only the link 375 that the protected LSP takes to reach Nhop 377 - If the "node protection desired" flag is not set, then the PLR 378 attempts to create an LP-bypass LSP to the Nhop node avoiding the 379 link that the protected LSP takes to reach the Nhop 381 With regard to the PLR procedures described above and that are 382 specified in [RFC4090], this document specifies the following 383 additional procedures to support RI-RSVP defined in [RFC8370]. 385 - While selecting the destination address of the bypass LSP, the PLR 386 SHOULD select the router ID of the NNhop or Nhop node from the 387 Node-ID sub-object included in the RRO object carried in the Resv 388 message. If the MP has not included a Node-ID sub-object in the 389 Resv RRO and if the PLR and the MP are in the same area, then the 390 PLR may utilize the TED to determine the router ID corresponding 391 to the interface address included by the MP in the RRO object. If 392 the NP-MP in a different IGP area has not included a Node-ID sub- 393 object in RRO object, then the PLR MUST execute backward 394 compatibility procedures as if the downstream nodes along the LSP 395 do not support the extensions defined in the document (see 396 Section 4.6.2.1). 398 - The PLR MUST also include its router ID in a Node-ID sub-object in 399 RRO object carried in a 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 MUST 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 the CAPABILITY object [RFC8370] carried in Hello 410 message corresponding to the Node-ID based Hello session, then the 411 PLR SHOULD conclude that the MP supports refresh-interval 412 independent FRR procedures defined in this document. If the MP 413 has not sent Node-ID based Hello messages or has not set the I-bit 414 in CAPABILITY object [RFC8370], then the PLR MUST 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 [I-D.ietf-mpls-summary-frr- 420 rsvpte] applies: the PLR MUST include B-SFRR-Ready Extended 421 Association object and trigger a Path message to be sent for those 422 LSPs. If a B-SFRR-Ready Extended Association object is included 423 in the Path message, then the encoding and object ordering rules 424 specified in RSVP-TE Summary FRR 425 [I-D.ietf-mpls-summary-frr-rsvpte] MUST be followed. 427 4.2.2. Remote Signaling Adjacency 429 A Node-ID based RSVP-TE Hello session is one in which Node-ID is used 430 in the source and the destination address fields of RSVP Hello 431 messages [RFC4558]. This document extends Node-ID based RSVP Hello 432 session to track the state of any RSVP-TE neighbor that is not 433 directly connected by at least one interface. In order to apply 434 Node-ID based RSVP-TE Hello session between any two routers that are 435 not immediate neighbors, the router that supports the extensions 436 defined in the document MUST set TTL to 255 in all outgoing Node-ID 437 based Hello messages exchanged between the PLR and the MP. The 438 default hello interval for this Node-ID hello session SHOULD be set 439 to the default specified in RSVP-TE Scaling Techniques [RFC8370]. 441 In the rest of the document the term "signaling adjacency", or 442 "remote signaling adjacency" refers specifically to the RSVP-TE 443 signaling adjacency. 445 4.2.3. MP Behavior 447 With regard to the MP procedures that are defined in [RFC4090], this 448 document specifies the following additional procedures to support RI- 449 RSVP defined in [RFC8370]. 451 Each node along an LSP path supporting the extensions defined in this 452 document MUST also include its router ID in the Node-ID sub-object of 453 the RRO object carried in the Resv message of the LSPs. If the PLR 454 has not included a Node-ID sub-object in the RRO object carried in 455 the Path message and if the PLR is in a different IGP area, then the 456 router MUST NOT execute the MP procedures specified in this document 457 for those LSPs. Instead, the node MUST execute backward 458 compatibility procedures defined in Section 4.6.2.2 as if the 459 upstream nodes along the LSP do not support the extensions defined in 460 this document. 462 A node receiving Path messages should determine whether they contain 463 a B-SFRR-Ready Extended Association object with the Node-ID address 464 of the PLR as the source and its own Node-ID as the destination. In 465 addition the node should determine whether it has an operational 466 remote Node-ID signaling adjacency with the PLR. If either the PLR 467 has not included the B-SFRR-Ready Extended Association object or if 468 there is no operational Node-ID signaling adjacency with the PLR or 469 if the PLR has not advertised RI-RSVP capability in its Node-ID based 470 Hello messages, then the node MUST execute backward compatibility 471 procedures defined in Section 4.6.2.2. 473 If a matching B-SFRR-Ready Extended Association object is found in 474 the Path message and if there is an operational remote signaling 475 adjacency with the PLR that has advertised RI-RSVP capability (I-bit) 476 [RFC8370] in its Node-ID based Hello messages, then the node SHOULD 477 consider itself as the MP for the corresponding PLR. The matching 478 and ordering rules for Bypass Summary FRR Extended Association 479 specified in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte] 480 MUST be followed by the implementations supporting this document. 482 - If a matching Bypass Summary FRR Extended Association object is 483 included by the PPhop node of an LSP and if a corresponding Node- 484 ID signaling adjacency exists with the PPhop node, then the router 485 SHOULD conclude it is the NP-MP. 487 - If a matching Bypass Summary FRR Extended Association object is 488 included by the Phop node of an LSP and if a corresponding Node-ID 489 signaling adjacency exists with the Phop node, then the router 490 SHOULD conclude it is the LP-MP. 492 4.2.4. "Remote" State on MP 494 Once a router concludes it is the MP for a PLR running refresh- 495 interval independent FRR procedures, it SHOULD create a remote path 496 state for the LSP. The only difference between the "remote" path 497 state and the LSP state is the RSVP_HOP object. The RSVP_HOP object 498 in a "remote" path state contains the address that the PLR uses to 499 send Node-ID hello messages to the MP. 501 The MP SHOULD consider the "remote" path state automatically deleted 502 if: 504 - The MP later receives a Path with no matching B-SFRR-Ready 505 Extended Association object corresponding to the PLR's IP address 506 contained in the Path RRO, or 508 - The Node-ID signaling adjacency with the PLR goes down, or 510 - The MP receives backup LSP signaling from the PLR or 512 - The MP receives a PathTear, or 514 - The MP deletes the LSP state on local policy or exception event 516 Unlike the normal path state that is either locally generated on the 517 ingress or created by a Path message from the Phop node, the "remote" 518 path state is not signaled explicitly from the PLR. The purpose of 519 "remote" path state is to enable the PLR to explicitly tear down the 520 path and reservation states corresponding to the LSP by sending a 521 tear message for the "remote" path state. Such a message tearing 522 down "remote" path state is called "Remote" PathTear. 524 The scenarios in which a "Remote" PathTear is applied are described 525 in Section 4.5. 527 4.3. Impact of Failures on LSP State 529 This section describes the procedures for routers on the LSP path for 530 different kinds of failures. The procedures described on detecting 531 RSVP control plane adjacency failures do not impact the RSVP-TE 532 graceful restart mechanisms ([RFC3473], [RFC5063]). If the router 533 executing these procedures act as helper for neighboring router, then 534 the control plane adjacency will be declared as having failed after 535 taking into account the grace period extended for neighbor by the 536 helper. 538 Node failures are detected from the state of Node-ID hello sessions 539 established with immediate neighbors. RSVP-TE Scaling Techniques 540 [RFC8370] recommends each router to establish Node-ID hello sessions 541 with all its immediate neighbors. PLR or MP node failure is detected 542 from the state of remote signaling adjacency established according to 543 Section 4.2.2 of this document. 545 4.3.1. Non-MP Behavior 547 When a router detects Phop link or Phop node failure and the router 548 is not an MP for the LSP, then it SHOULD send a Conditional PathTear 549 (refer to Section 4.4 "Conditional PathTear" below) and delete the 550 PSB and RSB states corresponding to the LSP. 552 4.3.2. LP-MP Behavior 554 When the Phop link for an LSP fails on a router that is an LP-MP for 555 the LSP, the LP-MP MUST retain the PSB and RSB states corresponding 556 to the LSP till the occurrence of any of the following events. 558 - The Node-ID signaling adjacency with the Phop PLR goes down, or 560 - The MP receives a normal or "Remote" PathTear for its PSB, or 562 - The MP receives a ResvTear for its RSB. 564 When a router that is an LP-MP for an LSP detects Phop node failure 565 from the Node-ID signaling adjacency state, the LP-MP SHOULD send a 566 normal PathTear and delete the PSB and RSB states corresponding to 567 the LSP. 569 4.3.3. NP-MP Behavior 571 When a router that is an NP-MP for an LSP detects Phop link failure, 572 or Phop node failure from the Node-ID signaling adjacency, the router 573 MUST retain the PSB and RSB states corresponding to the LSP till the 574 occurrence of any of the following events. 576 - The remote Node-ID signaling adjacency with the PPhop PLR goes 577 down, or 579 - The MP receives a normal or "Remote" PathTear for its PSB, or 581 - The MP receives a ResvTear for its RSB. 583 When a router that is an NP-MP does not detect Phop link or node 584 failure, but receives a Conditional PathTear from the Phop node, then 585 the router MUST retain the PSB and RSB states corresponding to the 586 LSP till the occurrence of any of the following events. 588 - The remote Node-ID signaling adjacency with the PPhop PLR goes 589 down, or 591 - The MP receives a normal or "Remote" PathTear for its PSB, or 593 - The MP receives a ResvTear for its RSB. 595 Receiving a Conditional PathTear from the Phop node will not impact 596 the "remote" state from the PPhop PLR. Note that Phop node would 597 send a Conditional PathTear if it was not an MP. 599 In the example topology in Figure 1, we assume C & D are the NP-MPs 600 for the PLRs A & B respectively. Now when A-B link fails, as B is 601 not an MP and its Phop link has failed, B will delete LSP state (this 602 behavior is required for unprotected LSPs - Section 4.3.1). In the 603 data plane, that would require B to delete the label forwarding entry 604 corresponding to the LSP. So if B's downstream nodes C and D 605 continue to retain state, it would not be correct for D to continue 606 to assume itself as the NP-MP for the PLR B. 608 The mechanism that enables D to stop considering itself as the NP-MP 609 for B and delete the corresponding "remote" path state is given 610 below. 612 1. When C receives a Conditional PathTear from B, it decides to 613 retain LSP state as it is the NP-MP of the PLR A. C also SHOULD 614 check whether Phop B had previously signaled availability of node 615 protection. As B had previously signaled NP availability by 616 including B-SFRR-Ready Extended Association object, C SHOULD 617 remove the B-SFRR-Ready Extended Association object containing 618 Association Source set to B from the Path message and trigger a 619 Path to D. 621 2. When D receives a triggered Path, it realizes that it is no longer 622 the NP-MP for B and so it deletes the corresponding "remote" path 623 state. D does not propagate the Path further down because the 624 only change is that the B-SFRR-Ready Extended Association object 625 corresponding to Association Source B is no longer present in the 626 Path message. 628 4.3.4. Behavior of a Router that is both LP-MP and NP-MP 630 A router may be simultaneously the LP-MP as well as the NP-MP for the 631 Phop and the PPhop nodes respectively of an LSP. If Phop link fails 632 on such node, the node MUST retain the PSB and RSB states 633 corresponding to the LSP till the occurrence of any of the following 634 events. 636 - Both Node-ID signaling adjacencies with Phop and PPhop nodes go 637 down, or 639 - The MP receives a normal or "Remote" PathTear for its PSB, or 641 - The MP receives a ResvTear for its RSB. 643 If a router that is both LP-MP and NP-MP detects Phop node failure, 644 then the node MUST retain the PSB and RSB states corresponding to the 645 LSP till the occurrence of any of the following events. 647 - The remote Node-ID signaling adjacency with the PPhop PLR goes 648 down, or 650 - The MP receives a normal or "Remote" PathTear for its PSB, or 652 - The MP receives a ResvTear for its RSB. 654 4.4. Conditional PathTear 656 In the example provided in the Section 4.3.3, B deletes the PSB and 657 RSB states corresponding to the LSP once B detects its link to Phop 658 went down as B is not an MP. If B were to send a PathTear normally, 659 then C would delete LSP state immediately. In order to avoid this, 660 there should be some mechanism by which B can indicate to C that B 661 does not require the receiving node to unconditionally delete the LSP 662 state immediately. For this, B SHOULD add a new optional CONDITIONS 663 object in the PathTear. The CONDITIONS object is defined in 664 Section 4.4.3. If node C also understands the new object, then C 665 SHOULD delete LSP state only if it is not an NP-MP - in other words C 666 SHOULD delete LSP state if there is no "remote" PLR path state on C. 668 4.4.1. Sending Conditional PathTear 670 A router that is not an MP for an LSP SHOULD delete the PSB and RSB 671 states corresponding to the LSP if the Phop link or the Phop Node-ID 672 signaling adjacency goes down (Section 4.3.1). The router SHOULD 673 send a Conditional PathTear if the following are also true. 675 - The ingress has requested node protection for the LSP, and 677 - No PathTear is received from the upstream node 679 4.4.2. Processing Conditional PathTear 681 When a router that is not an NP-MP receives a Conditional PathTear, 682 the node SHOULD delete the PSB and RSB states corresponding to the 683 LSP, and process the Conditional PathTear by considering it as a 684 normal PathTear. Specifically, the node MUST NOT propagate the 685 Conditional PathTear downstream but remove the optional object and 686 send a normal PathTear downstream. 688 When a node that is an NP-MP receives a Conditional PathTear, it MUST 689 NOT delete LSP state. The node SHOULD check whether the Phop node 690 had previously included the B-SFRR-Ready Extended Association object 691 in the Path. If the object had been included previously by the Phop, 692 then the node processing the Conditional PathTear from the Phop 693 SHOULD remove the corresponding object and trigger a Path downstream. 695 If a Conditional PathTear is received from a neighbor that has not 696 advertised support (refer to Section 4.6) for the new procedures 697 defined in this document, then the node SHOULD consider the message 698 as a normal PathTear. The node SHOULD propagate the normal PathTear 699 downstream and delete the LSP state. 701 4.4.3. CONDITIONS Object 703 As any implementation that does not support Conditional PathTear 704 SHOULD ignore the new object but process the message as a normal 705 PathTear without generating any error, the Class-Num of the new 706 object MUST be 10bbbbbb where 'b' represents a bit (from Section 3.10 707 of [RFC2205]). 709 The new object is called as "CONDITIONS" object that will specify the 710 conditions under which default processing rules of the RSVP-TE 711 message MUST be invoked. 713 The object has the following format: 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Length | Class | C-type | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Reserved |M| 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Figure 2: CONDITIONS Object 723 Length: This contains the size of the object in bytes and should 724 be set to eight. 726 Class: To be assigned 728 C-type: 1 730 M bit: If the M bit is set to 1, then the PathTear message SHOULD 731 be processed according to the receiver router role, i.e. if it is 732 an MP or not. 733 If M-bit is set to 0, then the PathTear message SHOULD be 734 processed as a normal PathTear message. 736 4.5. Remote State Teardown 738 If the ingress wants to tear down the LSP because of a management 739 event while the LSP is being locally repaired at a transit PLR, it 740 would not be desirable to wait till the completion of backup LSP 741 signaling to perform state cleanup. To enable LSP state cleanup when 742 the LSP is being locally repaired, the PLR SHOULD send a "Remote" 743 PathTear message instructing the MP to delete the PSB and RSB states 744 corresponding to the LSP. The TTL in the "Remote" PathTear message 745 SHOULD be set to 255. 747 Let us consider that node C, in example topology (Figure 1), has gone 748 down and B locally repairs the LSP. 750 1. Ingress A receives a management event to tear down the LSP. 752 2. A sends a normal PathTear to B. 754 3. Assume B has not initiated backup signaling for the LSR. To 755 enable LSP state cleanup, B SHOULD send a "Remote" PathTear with 756 destination IP address set to that of D used in the Node-ID 757 signaling adjacency with D, and RSVP_HOP object containing local 758 address used in the Node-ID signaling adjacency. 760 4. B then deletes the PSB and RSB states corresponding to the LSP. 762 5. On D there would be a remote signaling adjacency with B and so D 763 SHOULD accept the "Remote" PathTear and delete the PSB and RSB 764 states corresponding to the LSP. 766 4.5.1. PLR Behavior on Local Repair Failure 768 If local repair fails on the PLR after a failure, then this should be 769 considered as a case for cleaning up LSP state from the PLR to the 770 Egress. The PLR would achieve this using "Remote" PathTear to clean 771 up the state from the MP. If the MP has retained the LSP state, then 772 it would propagate the PathTear downstream thereby achieving state 773 cleanup. Note that in the case of link protection, the PathTear 774 would be directed to the LP-MP node's IP address rather than the Nhop 775 interface address. 777 4.5.2. PLR Behavior on Resv RRO Change 779 When a PLR router that has already made NP available detects a change 780 in the RRO carried in the Resv message indicating that the router's 781 former NP-MP is no longer present in the LSP path, then the router 782 SHOULD send a "Remote" PathTear directly to its former NP-MP. 784 In the example topology in Figure 1, let us assume A has made node 785 protection available and C has concluded it is the NP-MP for PLR A. 786 When the B-C link fails then C, implementing the procedure specified 787 in Section 4.3.4 of this document, will retain state till: the remote 788 Node-ID signaling adjacency with A goes down, or a PathTear or a 789 ResvTear is received for its PSB or RSB respectively. If B also has 790 made node protection available, B will eventually complete backup LSP 791 signaling with its NP-MP D and trigger a Resv to A with RRO changed. 792 The new RRO of the LSP carried in the Resv will not contain C. When 793 A processes the Resv with a new RRO not containing C - its former NP- 794 MP, A SHOULD send a "Remote" PathTear to C. When C receives the 795 "Remote" PathTear for its PSB state, C will send a normal PathTear 796 downstream to D and delete both the PSB and RSB states corresponding 797 to the LSP. As D has already received backup LSP signaling from B, D 798 will retain control plane and forwarding states corresponding to the 799 LSP. 801 4.5.3. LSP Preemption during Local Repair 803 4.5.3.1. Preemption on LP-MP after Phop Link Failure 805 If an LSP is preempted on an LP-MP after its Phop or incoming link 806 has already failed but the backup LSP has not been signaled yet, then 807 the node SHOULD send a normal PathTear and delete both the PSB and 808 RSB states corresponding to the LSP. As the LP-MP has retained LSP 809 state expecting the PLR to perform backup LSP signaling, preemption 810 would bring down the LSP and the node would not be LP-MP any more 811 requiring the node to clean up LSP state. 813 4.5.3.2. Preemption on NP-MP after Phop Link Failure 815 If an LSP is preempted on an NP-MP after its Phop link has already 816 failed but the backup LSP has not been signaled yet, then the node 817 SHOULD send a normal PathTear and delete the PSB and RSB states 818 corresponding to the LSP. As the NP-MP has retained LSP state 819 expecting the PLR to perform backup LSP signaling, preemption would 820 bring down the LSP and the node would not be NP-MP any more requiring 821 the node to clean up LSP state. 823 Let us consider that B-C link goes down on the same example topology 824 (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP 825 state. 827 1. The LSP is preempted on C. 829 2. C will delete the RSB state corresponding to the LSP. But C 830 cannot send a PathErr or a ResvTear to the PLR A because the 831 backup LSP has not been signaled yet. 833 3. As the only reason for C having retained state after Phop node 834 failure was that it was an NP-MP, C SHOULD send a normal PathTear 835 to D and delete its PSB state also. D would also delete the PSB 836 and RSB states on receiving a PathTear from C. 838 4. B starts backup LSP signaling to D. But as D does not have the 839 LSP state, it will reject the backup LSP Path and send a PathErr 840 to B. 842 5. B will delete its reservation and send a ResvTear to A. 844 4.6. Backward Compatibility Procedures 846 The "Refresh interval Independent FRR" or RI-RSVP-FRR referred below 847 in this section refers to the changes that have been defined in 848 previous sections. Any implementation that does not support them has 849 been termed as "non-RI-RSVP-FRR implementation". The extensions 850 proposed in RSVP-TE Summary FRR [I-D.ietf-mpls-summary-frr-rsvpte] 851 are applicable to implementations that do not support RI-RSVP-FRR. 852 On the other hand, changes proposed relating to LSP state cleanup 853 namely Conditional and "Remote" PathTear require support from one-hop 854 and two-hop neighboring nodes along the LSP path. So procedures that 855 fall under LSP state cleanup category SHOULD be turned on only if all 856 nodes involved in the node protection FRR i.e. the PLR, the MP and 857 the intermediate node in the case of NP, support the extensions. 858 Note that for LSPs requesting only link protection, the PLR and the 859 LP-MP need to support the extensions. 861 4.6.1. Detecting Support for Refresh interval Independent FRR 863 An implementation supporting the extensions specified in previous 864 sections (called RI-RSVP-FRR here after) SHOULD set the flag "Refresh 865 interval Independent RSVP" or RI-RSVP flag in the CAPABILITY object 866 carried in Hello messages. The RI-RSVP flag is specified in RSVP-TE 867 Scaling Techniques [RFC8370]. 869 - As nodes supporting the extensions SHOULD initiate Node Hellos 870 with adjacent nodes, a node on the path of protected LSP can 871 determine whether its Phop or Nhop neighbor supports RI-RSVP-FRR 872 enhancements from the Hello messages sent by the neighbor. 874 - If a node attempts to make node protection available, then the PLR 875 SHOULD initiate a remote Node-ID signaling adjacency with its 876 NNhop. If the NNhop (a) does not reply to remote node Hello 877 message or (b) does not set the RI-RSVP flag in the CAPABILITY 878 object carried in its Node-ID Hello messages, then the PLR can 879 conclude that NNhop does not support RI-RSVP-FRR extensions. 881 - If node protection is requested for an LSP and if (a) the PPhop 882 node has not included a matching B-SFRR-Ready Extended Association 883 object in its Path messages or (b) the PPhop node has not 884 initiated remote node Hello messages or (c) the PPhop node does 885 not set the RI-RSVP flag in the CAPABILITY object carried in its 886 Node-ID Hello messages, then the node MUST conclude that the PLR 887 does not support RI-RSVP-FRR extensions. The details are 888 described in the "Procedures for Backward Compatibility" section 889 below. 891 4.6.2. Procedures for Backward Compatibility 893 The procedures defined hereafter are performed on a subset of LSPs 894 that traverse a node, rather than on all LSPs that traverse a node. 895 This behavior is required to support backward compatibility for a 896 subset of LSPs traversing nodes running non-RI-RSVP-FRR 897 implementations. 899 4.6.2.1. Lack of support on Downstream Node 901 The procedures on the downstream direction are as follows. 903 - If the Nhop does not support the RI-RSVP-FRR extensions, then the 904 node SHOULD reduce the "refresh period" in the TIME_VALUES object 905 carried in the Path to the default short refresh interval. 907 - If node protection is requested and the NNhop node does not 908 support the enhancements, then the node SHOULD reduce the "refresh 909 period" in the TIME_VALUES object carried in the Path to the 910 default short refresh interval. 912 If the node reduces the refresh time from the above procedures, it 913 MUST NOT send any "Remote" PathTear or Conditional PathTear messages. 915 Consider the example topology in Figure 1. If C does not support the 916 RI-RSVP-FRR extensions, then: 918 - A and B SHOULD reduce the refresh time to default short refresh 919 interval of 30 seconds and trigger a Path 921 - If B is not an MP and if Phop link of B fails, B cannot send 922 Conditional PathTear to C but MUST time out the PSB state from A 923 normally. This would be accomplished if A would also reduce the 924 refresh time to default value. So if C does not support the RI- 925 RSVP-FRR extensions, then Phop B and the PPhop A SHOULD reduce the 926 refresh period to the default short refresh interval. 928 4.6.2.2. Lack of support on Upstream Node 930 The procedures are as follows. 932 - If Phop node does not support the RI-RSVP-FRR extensions, then the 933 node SHOULD reduce the "refresh period" in the TIME_VALUES object 934 carried in the Resv to the default short refresh interval. 936 - If node protection is requested and the Phop node does not support 937 the RI-RSVP-FRR extensions, then the node SHOULD reduce the 938 "refresh period" in the TIME_VALUES object carried in the Path to 939 the default short refresh interval (thus, the Nhop can use 940 compatible values when sending a Resv). 942 - If node protection is requested and the PPhop node does not 943 support the RI-RSVP-FRR extensions, then the node SHOULD reduce 944 the "refresh period" in the TIME_VALUES object carried in the Resv 945 to the default short refresh interval. 947 - If the node reduces the refresh time from the above procedures, it 948 SHOULD also not execute MP procedures specified in Section 4.3 of 949 this document. 951 4.6.2.3. Incremental Deployment 953 The backward compatibility procedures described in the previous sub- 954 sections imply that a router supporting the RI-RSVP-FRR extensions 955 specified in this document can apply the procedures specified in the 956 document either in the downstream or upstream direction of an LSP, 957 depending on the capability of the routers downstream or upstream in 958 the LSP path. 960 - RI-RSVP-FRR extensions and procedures are enabled for downstream 961 Path, PathTear and ResvErr messages corresponding to an LSP if 962 link protection is requested for the LSP and the Nhop node 963 supports the extensions 965 - RI-RSVP-FRR extensions and procedures are enabled for downstream 966 Path, PathTear and ResvErr messages corresponding to an LSP if 967 node protection is requested for the LSP and both Nhop & NNhop 968 nodes support the extensions 970 - RI-RSVP-FRR extensions and procedures are enabled for upstream 971 PathErr, Resv and ResvTear messages corresponding to an LSP if 972 link protection is requested for the LSP and the Phop node 973 supports the extensions 975 - RI-RSVP-FRR extensions and procedures are enabled for upstream 976 PathErr, Resv and ResvTear messages corresponding to an LSP if 977 node protection is requested for the LSP and both Phop and the 978 PPhop support the extensions 980 For example, if an implementation supporting the RI-RSVP-FRR 981 extensions specified in this document is deployed on all routers in 982 particular region of the network and if all the LSPs in the network 983 request node protection, then the FRR extensions will only be applied 984 for the LSP segments that traverse the particular region. This will 985 aid incremental deployment of these extensions and also allow reaping 986 the benefits of the extensions in portions of the network where it is 987 supported. 989 5. Security Considerations 991 The security considerations pertaining to the original RSVP protocol 992 [RFC2205], [RFC3209] and [RFC5920] remain relevant. 994 This document extends the applicability of Node-ID based Hello 995 session between immediate neighbors. The Node-ID based Hello session 996 between the PLR and the NP-MP may require the two routers to exchange 997 Hello messages with non-immediate neighbor. So, the implementations 998 SHOULD provide the option to configure Node-ID neighbor specific or 999 global authentication key to authentication messages received from 1000 Node-ID neighbors. The network administrator MAY utilize this option 1001 to enable RSVP-TE routers to authenticate Node-ID Hello messages 1002 received with TTL greater than 1. Implementations SHOULD also 1003 provide the option to specify a limit on the number of Node-ID based 1004 Hello sessions that can be established on a router supporting the 1005 extensions defined in this document. 1007 6. IANA Considerations 1009 6.1. New Object - CONDITIONS 1011 RSVP Change Guidelines [RFC3936] defines the Class-Number name space 1012 for RSVP objects. The name space is managed by IANA. 1014 IANA registry: RSVP Parameters 1015 Subsection: Class Names, Class Numbers, and Class Types 1017 A new RSVP object using a Class-Number from 128-183 range called the 1018 "CONDITIONS" object is defined in Section 4.4 of this document. The 1019 Class-Number from 128-183 range will be allocated by IANA. 1021 7. Acknowledgements 1023 We are very grateful to Yakov Rekhter for his contributions to the 1024 development of the idea and thorough review of content of the draft. 1025 Thanks to Raveendra Torvi and Yimin Shen for their comments and 1026 inputs. 1028 8. Contributors 1030 Markus Jork 1031 128 Technology 1032 Email: mjork@128technology.net 1034 Harish Sitaraman 1035 Individual Contributor 1036 Email: harish.ietf@gmail.com 1038 Vishnu Pavan Beeram 1039 Juniper Networks, Inc. 1040 Email: vbeeram@juniper.net 1042 Ebben Aries 1043 Arrcus, Inc. 1044 Email: exa@arrcus.com 1046 Mike Taillon 1047 Cisco Systems, Inc. 1048 Email: mtaillon@cisco.com 1050 9. References 1052 9.1. Normative References 1054 [I-D.ietf-mpls-summary-frr-rsvpte] 1055 Taillon, M., Saad, T., Gandhi, R., Deshmukh, A., Jork, M., 1056 and V. Beeram, "RSVP-TE Summary Fast Reroute Extensions 1057 for LSP Tunnels", draft-ietf-mpls-summary-frr-rsvpte-05 1058 (work in progress), July 2019. 1060 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1061 Requirement Levels", BCP 14, RFC 2119, 1062 DOI 10.17487/RFC2119, March 1997, 1063 . 1065 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1066 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1067 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1068 September 1997, . 1070 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1071 and S. Molendini, "RSVP Refresh Overhead Reduction 1072 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 1073 . 1075 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1076 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1077 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1078 . 1080 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1081 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1082 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1083 DOI 10.17487/RFC3473, January 2003, 1084 . 1086 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 1087 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 1088 DOI 10.17487/RFC3936, October 2004, 1089 . 1091 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1092 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1093 DOI 10.17487/RFC4090, May 2005, 1094 . 1096 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 1097 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 1098 A Clarification Statement", RFC 4558, 1099 DOI 10.17487/RFC4558, June 2006, 1100 . 1102 [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to 1103 GMPLS Resource Reservation Protocol (RSVP) Graceful 1104 Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, 1105 . 1107 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 1108 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 1109 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 1110 . 1112 9.2. Informative References 1114 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1115 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1116 . 1118 Authors' Addresses 1119 Chandra Ramachandran 1120 Juniper Networks, Inc. 1122 Email: csekar@juniper.net 1124 Tarek Saad 1125 Juniper Networks, Inc. 1127 Email: tsaad@juniper.net 1129 Ina Minei 1130 Google, Inc. 1132 Email: inaminei@google.com 1134 Dante Pacella 1135 Verizon, Inc. 1137 Email: dante.j.pacella@verizon.com