idnits 2.17.1 draft-ietf-mpls-ri-rsvp-frr-12.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 (19 December 2021) is 858 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group C R. Ramachandran 3 Internet-Draft T S. Saad 4 Updates: 4090 (if approved) Juniper Networks, Inc. 5 Intended status: Standards Track I M. Minei 6 Expires: 22 June 2022 Google, Inc. 7 D P. Pacella 8 Verizon, Inc. 9 19 December 2021 11 Refresh-interval Independent FRR Facility Protection 12 draft-ietf-mpls-ri-rsvp-frr-12 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 22 June 2022. 54 Copyright Notice 56 Copyright (c) 2021 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 (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Revised BSD License text as 65 described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Revised BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5 74 4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP 76 Capability . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.2. Signaling Handshake between PLR and MP . . . . . . . . . 9 78 4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9 79 4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10 80 4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10 81 4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 12 82 4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12 83 4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 13 84 4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 85 4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 86 4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 15 87 4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15 88 4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15 89 4.4.2. Processing Conditional PathTear . . . . . . . . . . . 16 90 4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16 91 4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 17 92 4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 18 93 4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 18 94 4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18 95 4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 18 96 4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 19 97 4.6. Backward Compatibility Procedures . . . . . . . . . . . . 19 98 4.6.1. Detecting Support for Refresh interval Independent 99 FRR . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 4.6.2. Procedures for Backward Compatibility . . . . . . . . 20 101 4.6.2.1. Lack of support on Downstream Node . . . . . . . 20 102 4.6.2.2. Lack of support on Upstream Node . . . . . . . . 21 103 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR . . . . . 22 104 4.6.2.4. Incremental Deployment . . . . . . . . . . . . . 22 105 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 107 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 24 108 6.2. CONDITIONS Flags . . . . . . . . . . . . . . . . . . . . 24 109 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 110 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 111 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 112 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 113 9.2. Informative References . . . . . . . . . . . . . . . . . 26 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 116 1. Introduction 118 RSVP-TE relies on periodic refresh of RSVP messages to synchronize 119 and maintain the Label Switched Path (LSP) related states along the 120 reserved path. In the absence of refresh messages, the LSP-related 121 states are automatically deleted. Reliance on periodic refreshes and 122 refresh timeouts are problematic from the scalability point of view. 123 The number of RSVP-TE LSPs that a router needs to maintain has been 124 growing in service provider networks and the implementations should 125 be capable of handling increase in LSP scale. 127 RFC 2961 specifies mechanisms to eliminate the reliance on periodic 128 refresh and refresh timeout of RSVP messages, and enables a router to 129 increase the message refresh interval to values much longer than the 130 default 30 seconds defined in RFC 2205. However, the protocol 131 extensions defined in RFC 4090 for supporting Fast ReRoute (FRR) 132 using bypass tunnels implicitly rely on short refresh timeouts to 133 cleanup stale states. 135 In order to eliminate the reliance on refresh timeouts, the routers 136 should unambiguously determine when a particular LSP state should be 137 deleted. In scenarios involving RFC 4090 FRR using bypass tunnels, 138 additional explicit tear down messages are necessary. Refresh- 139 interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in 140 this document consists of procedures to enable LSP state cleanup that 141 are essential in supporting RI-RSVP capability for RFC 4090 FRR using 142 bypass tunnels. 144 1.1. Motivation 146 Base RSVP [RFC2205] maintains state via the generation of RSVP Path/ 147 Resv refresh messages. Refresh messages are used to both synchronize 148 state between RSVP neighbors and to recover from lost RSVP messages. 149 The use of Refresh messages to cover many possible failures has 150 resulted in a number of operational problems. 152 - One problem relates to RSVP control plane scaling due to periodic 153 refreshes of Path and Resv messages, another relates to the 154 reliability and latency of RSVP signaling. 156 - An additional problem is the time to clean up the stale state 157 after a tear message is lost. For more on these problems see 158 Section 1 of RSVP Refresh Overhead Reduction Extensions [RFC2961]. 160 The problems listed above adversely affect RSVP control plane 161 scalability and RSVP-TE [RFC3209] inherited these problems from 162 standard RSVP. Procedures specified in [RFC2961] address the above 163 mentioned problems by eliminating dependency on refreshes for state 164 synchronization and for recovering from lost RSVP messages, and by 165 eliminating dependency on refresh timeout for stale state cleanup. 166 Implementing these procedures allows implementations to improve RSVP- 167 TE control plane scalability. For more details on eliminating 168 dependency on refresh timeout for stale state cleanup, refer to 169 "Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling 170 Techniques [RFC8370]. 172 However, the facility backup protection procedures specified in 173 [RFC4090] do not fully address stale state cleanup as the procedures 174 depend on refresh timeouts for stale state cleanup. The updated 175 facility backup protection procedures specified in this document, in 176 combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this 177 dependency on refresh timeouts for stale state cleanup. 179 The procedures specified in this document assume reliable delivery of 180 RSVP messages, as specified in [RFC2961]. Therefore this document 181 makes support for [RFC2961] a pre-requisite. 183 2. Terminology 185 The reader is expected to be familiar with the terminology in 186 [RFC2205], [RFC3209], [RFC4090], [RFC4558], [RFC8370] and [RFC8796]. 188 Phop node: Previous-hop router along the label switched path 190 PPhop node: Previous-Previous-hop router along the label switched 191 path 192 Nhop node: Next-hop router along the label switched path 194 NNhop node: Next-Next-hop router along the label switched path 196 PLR: Point of Local Repair router as defined in [RFC4090] 198 MP: Merge Point router as defined in [RFC4090] 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 RI-RSVP: The set of procedures defined in Section 3 of RSVP-TE 213 Scaling Techniques [RFC8370] to eliminate RSVP's reliance on periodic 214 message refreshes 216 B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object 217 defined in Summary FRR extensions [RFC8796] and is added by the PLR 218 for each protected LSP. 220 RI-RSVP-FRR: The set of procedures defined in this document to 221 elimiate RSVP's reliance of periodic message refreshes when 222 supporting facility backup protection [RFC4090] 224 Conditional PathTear: A PathTear message containing a suggestion to a 225 receiving downstream router to retain the path state if the receiving 226 router is an NP-MP 228 Remote PathTear: A PathTear message sent from a Point of Local Repair 229 (PLR) to the MP to delete the LSP state on the MP if PLR had not 230 previously sent the backup Path state reliably 232 3. Problem Description 233 E 234 / \ 235 / \ 236 / \ 237 / \ 238 / \ 239 / \ 240 A ----- B ----- C ----- D 241 \ / 242 \ / 243 \ / 244 \ / 245 \ / 246 \ / 247 F 249 Figure 1: Example Topology 251 In the topology in Figure 1, let us consider a large number of LSPs 252 from A to D transiting B and C. Assume that refresh interval has 253 been configured to be long of the order of minutes and refresh 254 reduction extensions are enabled on all routers. 256 Also let us assume that node protection has been configured for the 257 LSPs and the LSPs are protected by each router in the following way 259 - A has made node protection available using bypass LSP A -> E -> C; 260 A is the PLR and C is the NP-MP 262 - B has made node protection available using bypass LSP B -> F -> D; 263 B is the PLR and D is the NP-MP 265 - C has made link protection available using bypass LSP C -> B -> F 266 -> D; C is the PLR and D is the LP-MP 268 In the above condition, assume that B-C link fails. The following is 269 the sequence of events that is expected to occur for all protected 270 LSPs under normal conditions. 272 1. B performs local repair and re-directs LSP traffic over the 273 bypass LSP B -> F -> D. 275 2. B also creates backup state for the LSP and triggers sending of 276 backup LSP state to D over the bypass LSP B -> F -> D. 278 3. D receives backup LSP states and merges the backups with the 279 protected LSPs. 281 4. As the link on C, over which the LSP states are refreshed, has 282 failed, C will no longer receive state refreshes. Consequently 283 the protected LSP states on C will time out and C will send the 284 tear down messages for all LSPs. As each router should consider 285 itself as an MP, C will time out the state only after waiting for 286 an additional duration equal to refresh timeout. 288 While the above sequence of events has been described in [RFC4090], 289 there are a few problems for which no mechanism has been specified 290 explicitly. 292 - If the protected LSP on C times out before D receives signaling 293 for the backup LSP, then D would receive a PathTear from C prior 294 to receiving signaling for the backup LSP, thus resulting in 295 deleting the LSP state. This would be possible at scale even with 296 default refresh time. 298 - If upon the link failure C is to keep state until its timeout, 299 then with long refresh interval this may result in a large amount 300 of stale state on C. Alternatively, if upon the link failure C is 301 to delete the state and send a PathTear to D, this would result in 302 deleting the state on D, thus deleting the LSP. D needs a 303 reliable mechanism to determine whether it is an MP or not to 304 overcome this problem. 306 - If head-end A attempts to tear down LSP after step 1 but before 307 step 2 of the above sequence, then B may receive the tear down 308 message before step 2 and delete the LSP state from its state 309 database. If B deletes its state without informing D, with long 310 refresh interval this could cause (large) buildup of stale state 311 on D. 313 - If B fails to perform local repair in step 1, then B will delete 314 the LSP state from its state database without informing D. As B 315 deletes its state without informing D, with long refresh interval 316 this could cause (large) buildup of stale state on D. 318 The purpose of this document is to provide solutions to the above 319 problems which will then make it practical to scale up to a large 320 number of protected LSPs in the network. 322 4. Solution Aspects 324 The solution consists of five parts. 326 - Utilize MP determination mechanism specified in RSVP-TE Summary 327 FRR [RFC8796] that enables the PLR to signal the availability of 328 local protection to the MP. In addition, introduce PLR and MP 329 procedures to to establish Node-ID based hello session between the 330 PLR and the MP to detect router failures and to determine 331 capability. See section 4.2 for more details. This part of the 332 solution re-uses some of the extensions defined in RSVP-TE Summary 333 FRR [RFC8796] and RSVP-TE Scaling Techniques [RFC8370], and the 334 subsequent sub-sections will list the extensions in these drafts 335 that are utilized in this document. 337 - Handle upstream link or node failures by cleaning up LSP states if 338 the node has not found itself as an MP through the MP 339 determination mechanism. See section 4.3 for more details. 341 - Introduce extensions to enable a router to send a tear down 342 message to the downstream router that enables the receiving router 343 to conditionally delete its local LSP state. See section 4.4 for 344 more details. 346 - Enhance facility backup protection by allowing a PLR to directly 347 send a tear down message to the MP without requiring the PLR to 348 either have a working bypass LSP or have already signaled backup 349 LSP state. See section 4.5 for more details. 351 - Introduce extensions to enable the above procedures to be backward 352 compatible with routers along the LSP path running implementation 353 that do not support these procedures. See section 4.6 for more 354 details. 356 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP 357 Capability 359 A node supporting facility backup protection [RFC4090] MUST set the 360 RI-RSVP capability (I bit) defined in Section 3.1 of RSVP-TE Scaling 361 Techniques [RFC8370] only if it supports all the extensions specified 362 in the rest of this document. Hence, this document updates RFC 4090 363 by defining extensions and additional procedures over facility backup 364 protection [RFC4090] in order to advertise RI-RSVP capability 365 [RFC8370]. However, if a node supporting facility backup protection 366 [RFC4090] does set the RI-RSVP capability (I bit) but does not 367 support all the extensions specified in the rest of this document, 368 then it leaves room for stale state to linger around for an 369 inordinate period of time given the long refresh intervals 370 recommended by RFC 8370 or disruption of normal FRR operation. 371 Procedures for backward compatibility Section 4.6.2.3 delves on this 372 in detail. 374 4.2. Signaling Handshake between PLR and MP 376 4.2.1. PLR Behavior 378 As per the facility backup procedures [RFC4090], when an LSP becomes 379 operational on a node and the "local protection desired" flag has 380 been set in the SESSION_ATTRIBUTE object carried in the Path message 381 corresponding to the LSP, then the node attempts to make local 382 protection available for the LSP. 384 - If the "node protection desired" flag is set, then the node tries 385 to become a PLR by attempting to create a NP-bypass LSP to the 386 NNhop node avoiding the Nhop node on protected LSP path. In case 387 node protection could not be made available, the node attempts to 388 create an LP-bypass LSP to the Nhop node avoiding only the link 389 that the protected LSP takes to reach the Nhop 391 - If the "node protection desired" flag is not set, then the PLR 392 attempts to create an LP-bypass LSP to the Nhop node avoiding the 393 link that the protected LSP takes to reach the Nhop 395 With regard to the PLR procedures described above and that are 396 specified in RFC 4090, this document specifies the following 397 additional procedures to support RI-RSVP [RFC8370]. 399 - While selecting the destination address of the bypass LSP, the PLR 400 MUST select the router ID of the NNhop or Nhop node from the Node- 401 ID sub-object included in the RRO object carried in the most 402 recent Resv message corresponding to the LSP. If the MP has not 403 included a Node-ID sub-object in the Resv RRO and if the PLR and 404 the MP are in the same area, then the PLR may utilize the TED to 405 determine the router ID corresponding to the interface address 406 included by the MP in the RRO object. If the NP-MP in a different 407 IGP area has not included a Node-ID sub-object in RRO object, then 408 the PLR MUST execute backward compatibility procedures as if the 409 downstream nodes along the LSP do not support the extensions 410 defined in the document (see Section 4.6.2.1). 412 - The PLR MUST also include its router ID in a Node-ID sub-object in 413 RRO object carried in any subsequent Path message corresponding to 414 the LSP. While including its router ID in the Node-ID sub-object 415 carried in the outgoing Path message, the PLR MUST include the 416 Node-ID sub-object after including its IPv4/IPv6 address or 417 unnumbered interface ID sub-object. 419 - In parallel to the attempt made to create NP-bypass or LP-bypass, 420 the PLR MUST initiate a Node-ID based Hello session to the NNhop 421 or Nhop node respectively along the LSP to establish the RSVP-TE 422 signaling adjacency. This Hello session is used to detect MP node 423 failure as well as determine the capability of the MP node. If 424 the MP has set the I-bit in the CAPABILITY object [RFC8370] 425 carried in Hello message corresponding to the Node-ID based Hello 426 session, then the PLR MUST conclude that the MP supports refresh- 427 interval independent FRR procedures defined in this document. If 428 the MP has not sent Node-ID based Hello messages or has not set 429 the I-bit in CAPABILITY object [RFC8370], then the PLR MUST 430 execute backward compatibility procedures defined in 431 Section 4.6.2.1 of this document. 433 - When the PLR associates a bypass to a protected LSP, it MUST 434 include a B-SFRR-Ready Extended Association object [RFC8796] and 435 trigger a Path message to be sent for the LSP. If a B-SFRR-Ready 436 Extended Association object is included in the Path message 437 corresponding to the LSP, the encoding and object ordering rules 438 specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. In 439 addition to those rules, the PLR MUST set the Association Source 440 in the object to its Node-ID address. 442 4.2.2. Remote Signaling Adjacency 444 A Node-ID based RSVP-TE Hello session is one in which Node-ID is used 445 in the source and the destination address fields of RSVP Hello 446 messages [RFC4558]. This document extends Node-ID based RSVP Hello 447 session to track the state of any RSVP-TE neighbor that is not 448 directly connected by at least one interface. In order to apply 449 Node-ID based RSVP-TE Hello session between any two routers that are 450 not immediate neighbors, the router that supports the extensions 451 defined in the document MUST set TTL to 255 in all outgoing Node-ID 452 based Hello messages exchanged between the PLR and the MP. The 453 default hello interval for this Node-ID hello session MUST be set to 454 the default specified in RSVP-TE Scaling Techniques [RFC8370]. 456 In the rest of the document the term "signaling adjacency", or 457 "remote signaling adjacency" refers specifically to the RSVP-TE 458 signaling adjacency. 460 4.2.3. MP Behavior 462 With regard to the MP procedures that are defined in [RFC4090] this 463 document specifies the following additional procedures to support RI- 464 RSVP defined in [RFC8370]. 466 Each node along an LSP path supporting the extensions defined in this 467 document MUST also include its router ID in the Node-ID sub-object of 468 the RRO object carried in the Resv message of the corresponding LSP. 469 If the PLR has not included a Node-ID sub-object in the RRO object 470 carried in the Path message and if the PLR is in a different IGP 471 area, then the router MUST NOT execute the MP procedures specified in 472 this document for those LSPs. Instead, the node MUST execute 473 backward compatibility procedures defined in Section 4.6.2.2 as if 474 the upstream nodes along the LSP do not support the extensions 475 defined in this document. 477 A node receiving a Path message should determine whether the message 478 contains a B-SFRR-Ready Extended Association object with its own 479 address as the bypass destination address and whether it has an 480 operational Node-ID signaling adjacency with the Association source. 481 If the PLR has not included the B-SFRR-Ready Extended Association 482 object or if there is no operational Node-ID signaling adjacency with 483 the PLR identified by the Association source address or if the PLR 484 has not advertised RI-RSVP capability in its Node-ID based Hello 485 messages, then the node MUST execute the backward compatibility 486 procedures defined in Section 4.6.2.2. 488 If a matching B-SFRR-Ready Extended Association object is found in in 489 the Path message and if there is an operational remote Node-ID 490 signaling adjacency with the PLR (identified by the Association 491 source) that has advertised RI-RSVP capability (I-bit) [RFC8370], 492 then the node MUST consider itself as the MP for the PLR. The 493 matching and ordering rules for Bypass Summary FRR Extended 494 Association specified in RSVP-TE Summary FRR [RFC8796] MUST be 495 followed by the implementations supporting this document. 497 - If a matching Bypass Summary FRR Extended Association object is 498 included by the PPhop node of an LSP and if a corresponding Node- 499 ID signaling adjacency exists with the PPhop node, then the router 500 MUST conclude it is the NP-MP. 502 - If a matching Bypass Summary FRR Extended Association object is 503 included by the Phop node of an LSP and if a corresponding Node-ID 504 signaling adjacency exists with the Phop node, then the router 505 MUST conclude it is the LP-MP. 507 4.2.4. "Remote" State on MP 509 Once a router concludes it is the MP for a PLR running refresh- 510 interval independent FRR procedures as described in the preceding 511 section, it MUST create a remote path state for the LSP. The only 512 difference between the "remote" path state and the LSP state is the 513 RSVP_HOP object. The RSVP_HOP object in a "remote" path state 514 contains the address that the PLR uses to send Node-ID hello messages 515 to the MP. 517 The MP MUST consider the "remote" path state corresponding to the LSP 518 automatically deleted if: 520 - The MP later receives a Path message for the LSP with no matching 521 B-SFRR-Ready Extended Association object corresponding to the 522 PLR's IP address contained in the Path RRO, or 524 - The Node-ID signaling adjacency with the PLR goes down, or 526 - The MP receives backup LSP signaling for the LSP from the PLR or 528 - The MP receives a PathTear for the LSP, or 530 - The MP deletes the LSP state on a local policy or an exception 531 event 533 The purpose of "remote" path state is to enable the PLR to explicitly 534 tear down the path and reservation states corresponding to the LSP by 535 sending a tear message for the "remote" path state. Such a message 536 tearing down "remote" path state is called "Remote" PathTear. 538 The scenarios in which a "Remote" PathTear is applied are described 539 in Section 4.5. 541 4.3. Impact of Failures on LSP State 543 This section describes the procedures that must be executed upon 544 different kinds of failures by nodes along the path of the LSP. The 545 procedures that must be executed upon detecting RSVP signaling 546 adjacency failures do not impact the RSVP-TE graceful restart 547 mechanisms ([RFC3473], [RFC5063]). If a node executing these 548 procedures acts as a helper for a neighboring router, then the 549 signaling adjacency with the neighbor will be declared as having 550 failed only after taking into account the grace period extended for 551 the neighbor by this node acting as a helper. 553 Node failures are detected from the state of Node-ID hello sessions 554 established with immediate neighbors. RSVP-TE Scaling Techniques 555 [RFC8370] recommends that each node establish Node-ID hello sessions 556 with all its immediate neighbors. Non-immediate PLR or MP failure is 557 detected from the state of remote signaling adjacency established 558 according to Section 4.2.2 of this document. 560 4.3.1. Non-MP Behavior 562 When a router detects the Phop link or the Phop node failure for an 563 LSP and the router is not an MP for the LSP, then it MUST send a 564 Conditional PathTear (refer to Section 4.4 "Conditional PathTear" 565 below) and delete the PSB and RSB states corresponding to the LSP. 567 4.3.2. LP-MP Behavior 569 When the Phop link for an LSP fails on a router that is an LP-MP for 570 the LSP, the LP-MP MUST retain the PSB and RSB states corresponding 571 to the LSP till the occurrence of any of the following events. 573 - The Node-ID signaling adjacency with the Phop PLR goes down, or 575 - The MP receives a normal or "Remote" PathTear for its PSB, or 577 - The MP receives a ResvTear for its RSB. 579 When a router that is an LP-MP for an LSP detects Phop node failure 580 from the Node-ID signaling adjacency state, the LP-MP MUST send a 581 normal PathTear and delete the PSB and RSB states corresponding to 582 the LSP. 584 4.3.3. NP-MP Behavior 586 When a router that is an NP-MP for an LSP detects Phop link failure, 587 or Phop node failure from the Node-ID signaling adjacency, the router 588 MUST retain the PSB and RSB states corresponding to the LSP till the 589 occurrence of any of the following events. 591 - The remote Node-ID signaling adjacency with the PPhop PLR goes 592 down, or 594 - The MP receives a normal or "Remote" PathTear for its PSB, or 596 - The MP receives a ResvTear for its RSB. 598 When a router that is an NP-MP for an LSP did not detect the Phop 599 link or the Phop node failure, but receives a Conditional PathTear 600 from the Phop node, then the router MUST retain the PSB and RSB 601 states corresponding to the LSP till the occurrence of any of the 602 following events. 604 - The remote Node-ID signaling adjacency with the PPhop PLR goes 605 down, or 607 - The MP receives a normal or "Remote" PathTear for its PSB, or 609 - The MP receives a ResvTear for its RSB. 611 Receiving a Conditional PathTear from the Phop node will not impact 612 the "remote" state from the PPhop PLR. Note that the Phop node must 613 have sent the Conditional PathTear as it was not an MP for the LSP 614 Section 4.3.1. 616 In the example topology Figure 1, we assume C & D are the NP-MPs for 617 the PLRs A & B respectively. Now when A-B link fails, as B is not an 618 MP and its Phop link has failed, B will delete the LSP state (this 619 behavior is required for unprotected LSPs - Section 4.3.1). In the 620 data plane, that would require B to delete the label forwarding entry 621 corresponding to the LSP. So if B's downstream nodes C and D 622 continue to retain state, it would not be correct for D to continue 623 to assume itself as the NP-MP for the PLR B. 625 The mechanism that enables D to stop considering itself as the NP-MP 626 for B and delete the corresponding "remote" path state is given 627 below. 629 1. When C receives a Conditional PathTear from B, it decides to 630 retain LSP state as it is the NP-MP of the PLR A. C also MUST 631 check whether Phop B had previously signaled availability of node 632 protection. As B had previously signaled NP availability by 633 including B-SFRR-Ready Extended Association object, C MUST remove 634 the B-SFRR-Ready Extended Association object containing 635 Association Source set to B from the Path message and trigger a 636 Path to D. 638 2. When D receives the Path message, it realizes that it is no 639 longer the NP-MP for B and so it deletes the corresponding 640 "remote" path state. D does not propagate the Path further down 641 because the only change is that the B-SFRR-Ready Extended 642 Association object corresponding to Association Source B is no 643 longer present in the Path message. 645 4.3.4. Behavior of a Router that is both LP-MP and NP-MP 647 A router may simultaneously be the LP-MP as well as the NP-MP for the 648 Phop and the PPhop nodes respectively of an LSP. If the Phop link 649 fails on such a node, the node MUST retain the PSB and RSB states 650 corresponding to the LSP till the occurrence of any of the following 651 events. 653 - Both Node-ID signaling adjacencies with Phop and PPhop nodes go 654 down, or 656 - The MP receives a normal or "Remote" PathTear for its PSB, or 658 - The MP receives a ResvTear for its RSB. 660 If a router that is both an LP-MP and an NP-MP detects Phop node 661 failure, then the node MUST retain the PSB and RSB states 662 corresponding to the LSP till the occurrence of any of the following 663 events. 665 - The remote Node-ID signaling adjacency with the PPhop PLR goes 666 down, or 668 - The MP receives a normal or "Remote" PathTear for its PSB, or 670 - The MP receives a ResvTear for its RSB. 672 4.4. Conditional PathTear 674 In the example provided in the Section 4.3.3, B deletes the PSB and 675 RSB states corresponding to the LSP once B detects its Phop link went 676 down as B is not an MP. If B were to send a PathTear normally, then 677 C would delete LSP state immediately. In order to avoid this, there 678 should be some mechanism by which B can indicate to C that B does not 679 require the receiving node to unconditionally delete the LSP state 680 immediately. For this, B MUST add a new optional CONDITIONS object 681 in the PathTear. The CONDITIONS object is defined in Section 4.4.3. 682 If node C also understands the new object, then C MUST NOT delete the 683 LSP state if it is an NP-MP. 685 4.4.1. Sending Conditional PathTear 687 A router that is not an MP for an LSP MUST delete the PSB and RSB 688 states corresponding to the LSP if the Phop link or the Phop Node-ID 689 signaling adjacency goes down (Section 4.3.1). The router MUST send 690 a Conditional PathTear if the following are also true. 692 - The ingress has requested node protection for the LSP, and 693 - No PathTear is received from the upstream node 695 4.4.2. Processing Conditional PathTear 697 When a router that is not an NP-MP receives a Conditional PathTear, 698 the node MUST delete the PSB and RSB states corresponding to the LSP, 699 and process the Conditional PathTear by considering it as a normal 700 PathTear. Specifically, the node MUST NOT propagate the Conditional 701 PathTear downstream but remove the optional object and send a normal 702 PathTear downstream. 704 When a node that is an NP-MP receives a Conditional PathTear, it MUST 705 NOT delete LSP state. The node MUST check whether the Phop node had 706 previously included the B-SFRR-Ready Extended Association object in 707 the Path. If the object had been included previously by the Phop, 708 then the node processing the Conditional PathTear from the Phop MUST 709 remove the corresponding object and trigger a Path downstream. 711 If a Conditional PathTear is received from a neighbor that has not 712 advertised support (refer to Section 4.6) for the new procedures 713 defined in this document, then the node MUST consider the message as 714 a normal PathTear. The node MUST propagate the normal PathTear 715 downstream and delete the LSP state. 717 4.4.3. CONDITIONS Object 719 As any implementation that does not support Conditional PathTear MUST 720 ignore the new object but process the message as a normal PathTear 721 without generating any error, the Class-Num of the new object MUST be 722 10bbbbbb where 'b' represents a bit (from Section 3.10 of [RFC2205]). 724 The new object is called as "CONDITIONS" object that will specify the 725 conditions under which default processing rules of the RSVP-TE 726 message MUST be invoked. 728 The object has the following format: 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Length | Class | C-type | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Reserved |M| 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 Figure 2: CONDITIONS Object 738 * Length: This contains the size of the object in bytes and should 739 be set to eight. 740 Class: To be assigned 741 C-type: 1 742 Merge-point condition (M) bit: If the M bit is set to 1, then the 743 PathTear message MUST be processed according to the receiver 744 router role, i.e. if the receiving router is an MP or not for the 745 LSP. 746 If the M-bit is set to 0, then the PathTear message MUST be 747 processed processed as a normal PathTear message for the LSP. 749 4.5. Remote State Teardown 751 If the ingress wants to tear down the LSP because of a management 752 event while the LSP is being locally repaired at a transit PLR, it 753 would not be desirable to wait till the completion of backup LSP 754 signaling to perform state cleanup. To enable LSP state cleanup when 755 the LSP is being locally repaired, the PLR MUST send a "Remote" 756 PathTear message instructing the MP to delete the PSB and RSB states 757 corresponding to the LSP. The TTL in the "Remote" PathTear message 758 MUST be set to 255. 760 Let us consider that node C in the example topology (Figure 1) has 761 gone down and node B locally repairs the LSP. 763 1. Ingress A receives a management event to tear down the LSP. 765 2. A sends a normal PathTear for the LSP to B. 767 3. Assume B has not initiated the backup signaling for the LSP 768 during local repair. To enable LSP state cleanup, B MUST send a 769 "Remote" PathTear with destination IP address set to that of the 770 node D used in the Node-ID signaling adjacency with D, and the 771 RSVP_HOP object containing local address used in the Node-ID 772 signaling adjacency. 774 4. B then deletes the PSB and RSB states corresponding to the LSP. 776 5. On D there would be a remote signaling adjacency with B and so D 777 MUST accept the "Remote" PathTear and delete the PSB and RSB 778 states corresponding to the LSP. 780 4.5.1. PLR Behavior on Local Repair Failure 782 If local repair fails on the PLR after a failure, then this MUST be 783 considered as a case for cleaning up LSP state from the PLR to the 784 Egress. The PLR achieves state cleanup by sending "Remote" PathTear 785 to the MP. The MP MUST delete the states corresponding to the LSP 786 also also propagate the PathTear downstream thereby achieving state 787 cleanup from all downstream nodes up to the LSP egress. Note that in 788 the case of link protection, the PathTear MUST be directed to the LP- 789 MP's Node-ID IP address rather than the Nhop interface address. 791 4.5.2. PLR Behavior on Resv RRO Change 793 When a PLR router that has already made NP available for an LSP 794 detects a change in the RRO carried in the Resv message that 795 indicates that the router's former NP-MP is no longer present on the 796 path of the LSP, then the router MUST send a "Remote" PathTear 797 directly to its former NP-MP. 799 In the example topology Figure 1, let us assume A has made node 800 protection available for an LSP and C has concluded it is the NP-MP 801 for PLR A. When the B-C link fails then C, implementing the 802 procedure specified in Section 4.3.4 of this document, will retain 803 the states corresponding to the LSP until: the remote Node-ID 804 signaling adjacency with A goes down, or a PathTear or a ResvTear is 805 received for its PSB or RSB respectively. If B also has made node 806 protection available, B will eventually complete backup LSP signaling 807 with its NP-MP D and trigger a Resv to A with RRO changed. The new 808 RRO of the LSP carried in the Resv will not contain C. When A 809 processes the Resv message with a new RRO not containing C - its 810 former NP-MP, A MUST send a "Remote" PathTear to C. When C receives 811 the "Remote" PathTear for its PSB state, C will send a normal 812 PathTear downstream to D and delete both the PSB and RSB states 813 corresponding to the LSP. As D has already received backup LSP 814 signaling from B, D will retain control plane and forwarding states 815 corresponding to the LSP. 817 4.5.3. LSP Preemption during Local Repair 819 4.5.3.1. Preemption on LP-MP after Phop Link Failure 821 If an LSP is preempted on an LP-MP after its Phop or the incoming 822 link has already failed but the backup LSP has not been signaled yet 823 as part of local repair procedure, then the node MUST send a normal 824 PathTear and delete both the PSB and RSB states corresponding to the 825 LSP. As the LP-MP has retained the LSP state expecting the PLR to 826 initiate backup LSP signaling, preemption would bring down the LSP 827 and the node would not be LP-MP any more requiring the node to clean 828 up the LSP state. 830 4.5.3.2. Preemption on NP-MP after Phop Link Failure 832 If an LSP is preempted on an NP-MP after its Phop link has already 833 failed but the backup LSP has not been signaled yet, then the node 834 MUST send a normal PathTear and delete the PSB and RSB states 835 corresponding to the LSP. As the NP-MP has retained LSP state 836 expecting the PLR to initiate backup LSP signaling, preemption would 837 bring down the LSP and the node would not be NP-MP any more requiring 838 the node to clean up LSP state. 840 Let us consider that B-C link goes down on the same example topology 841 (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP 842 state. 844 1. The LSP is preempted on C. 846 2. C will delete the RSB state corresponding to the LSP. But C 847 cannot send a PathErr or a ResvTear to the PLR A because the 848 backup LSP has not been signaled yet. 850 3. As the only reason for C having retained state after Phop node 851 failure was that it was an NP-MP, C MUST send a normal PathTear to 852 D and delete its PSB state also. D would also delete the PSB and 853 RSB states on receiving a PathTear from C. 855 4. B starts backup LSP signaling to D. But as D does not have the 856 LSP state, it will reject the backup LSP Path and send a PathErr 857 to B. 859 5. B will delete its reservation and send a ResvTear to A. 861 4.6. Backward Compatibility Procedures 863 "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set 864 of procedures defined in this document to elimiate the reliance of 865 periodic refreshes. The extensions proposed in RSVP-TE Summary FRR 866 [RFC8796] may apply to implementations that do not support RI-RSVP- 867 FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state 868 cleanup namely Conditional and "Remote" PathTear require support from 869 one-hop and two-hop neighboring nodes along the LSP path. So 870 procedures that fall under LSP state cleanup category MUST NOT be 871 turned on if any of the nodes involved in the node protection FRR 872 i.e. the PLR, the MP and the intermediate node in the case of NP, 873 DOES NOT support RI-RSVP-FRR extensions. Note that for LSPs 874 requesting link protection, only the PLR and the LP-MP MUST support 875 the extensions. 877 4.6.1. Detecting Support for Refresh interval Independent FRR 879 An implementation supporting RI-RSVP-FRR extensions SHOULD set the 880 flag "Refresh interval Independent RSVP" or RI-RSVP flag in the 881 CAPABILITY object carried in Hello messages as specified in RSVP-TE 882 Scaling Techniques [RFC8370]. If an implementation does not set the 883 flag even if it supports RI-RSVP-FRR extensions, then its neighbors 884 will view the node as any node that does not support the extensions. 886 - As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID 887 based signaling adjacency with all immedate neighbors, such a node 888 on the path of a protected LSP can determine whether its Phop and 889 Nhop neighbors support RI-RSVP-FRR enhancements. 891 - As nodes supporting the RI-RSVP-FRR extensions also initiate Node- 892 ID based signaling adjacency with the NNhop along the path of the 893 LSP requested node protection Section 4.2.1, each node along the 894 LSP path can determine whether its NNhop node supports RI-RSVP-FRR 895 enhancements. If the NNhop (a) does not reply to remote Node-ID 896 Hello messages or (b) does not set the RI-RSVP flag in the 897 CAPABILITY object carried in its Node-ID Hello messages, then the 898 node acting as the PLR can conclude that NNhop does not support 899 RI-RSVP-FRR extensions. 901 - If node protection is requested for an LSP and if (a) the PPhop 902 node has not included a matching B-SFRR-Ready Extended Association 903 object in its Path messages or (b) the PPhop node has not 904 initiated remote Node-ID Hello messages or (c) the PPhop node does 905 not set the RI-RSVP flag in the CAPABILITY object carried in its 906 Node-ID Hello messages, then the node MUST conclude that the PLR 907 does not support RI-RSVP-FRR extensions. 909 4.6.2. Procedures for Backward Compatibility 911 Every node that supports RI-RSVP-FRR MUST support the procedures 912 defined in this section in order to support backward compatibility 913 for those subset of LSPs that also traverse nodes that do not support 914 RI-RSVP-FRR. 916 4.6.2.1. Lack of support on Downstream Node 918 The procedures on the downstream direction are as follows. 920 - If a node finds that the Nhop node along the LSP does not support 921 the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh 922 period" in the TIME_VALUES object carried in the Path messages to 923 the default short refresh interval. 925 - If node protection is requested for the LSP and the NNhop node 926 along the LSP path does not support the RI-RSVP-FRR extensions, 927 then the node MUST reduce the "refresh period" in the TIME_VALUES 928 object carried in the Path messages to the default short refresh 929 interval. 931 If a node reduces the refresh time using the above procedures, it 932 MUST NOT send any "Remote" PathTear or Conditional PathTear message 933 to the downstream node. 935 Consider the example topology in Figure 1. If C does not support the 936 RI-RSVP-FRR extensions, then: 938 - A and B MUST reduce the refresh time to the default short refresh 939 interval of 30 seconds and trigger a Path message 941 - If B is not an MP and if Phop link of B fails, B cannot send 942 Conditional PathTear to C but MUST time out the PSB state from A 943 normally. Note that B can time out the PSB state A normally only 944 if A did not set long refresh in the TIME_VALUES object carried in 945 the Path messages sent earlier. 947 4.6.2.2. Lack of support on Upstream Node 949 The procedures are as follows. 951 - If a node finds that the Phop node along the LSP path does not 952 support the RI-RSVP-FRR extensions, then the node MUST reduce the 953 "refresh period" in the TIME_VALUES object carried in the Resv 954 messages to the default short refresh interval. 956 - If node protection is requested for the LSP and the Phop node 957 along the LSP path does not support the RI-RSVP-FRR extensions, 958 then the the node MUST reduce the "refresh period" in the 959 TIME_VALUES object carried in the Path messages to the default 960 short refresh interval (thus, the Nhop can use compatible values 961 when sending a Resv). 963 - If node protection is requested for the LSP and the PPhop node 964 does not support the RI-RSVP-FRR extensions, then the node MUST 965 reduce the "refresh period" in the TIME_VALUES object carried in 966 the Resv messages to the default short refresh interval. 968 - If the node reduces the refresh time using the above procedures, 969 it MUST NOT execute MP procedures specified in Section 4.3 of this 970 document. 972 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR 974 If a node supporting facility backup protection [RFC4090] sets the 975 RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR 976 extensions, then it leaves room for stale state to linger around for 977 an inordinate period of time or disruption of normal FRR operation 978 (Section 3). Consider the example topology Figure 1 provided in this 979 document. 981 - Assume node B does set RI-RSVP capability in its Node-ID based 982 Hello messages even though it does not support RI-RSVP-FRR 983 extensions. When B detects the failure of its Phop link along an 984 LSP, it will not send Conditional PathTear to C as required by the 985 RI-RSVP-FRR procedures. If B simply leaves the LSP state without 986 deleting, then B may end up holding on to the stale state until 987 the (long) refresh timeout. 989 - Intead of node B, assume node C does set RI-RSVP capability in its 990 Node-id based Hello messages even though it does not support RI- 991 RSVP-FRR extensions. When B details the failure of its Phop link 992 along an LSP, it will send Conditional PathTear to C as required 993 by the RI-RSVP-FRR procedures. But, C would not recognize the 994 condition encoded in the PathTear and end up tearing down the LSP. 996 - Assume node B does set RI-RSVP capability in its Node-ID based 997 Hello messages even though it does not support RI-RSVP-FRR 998 extensions. Also assume local repair is about to commence on node 999 B for an LSP that has only requested link protection. That is, B 1000 has not initiated the backup LSP signaling for the LSP. If node B 1001 receives a normal PathTear at this time from ingress A because of 1002 a management event initiated on A, then B simply deletes the LSP 1003 state without sending a Remote PathTear to the LP-MP C. So, C may 1004 end up holding on to the stale state until the (long) refresh 1005 timeout. 1007 4.6.2.4. Incremental Deployment 1009 The backward compatibility procedures described in the previous sub- 1010 sections imply that a router supporting the RI-RSVP-FRR extensions 1011 specified in this document can apply the procedures specified in the 1012 document either in the downstream or upstream direction of an LSP, 1013 depending on the capability of the routers downstream or upstream in 1014 the LSP path. 1016 - RI-RSVP-FRR extensions and procedures are enabled for downstream 1017 Path, PathTear and ResvErr messages corresponding to an LSP if 1018 link protection is requested for the LSP and the Nhop node 1019 supports the extensions 1021 - RI-RSVP-FRR extensions and procedures are enabled for downstream 1022 Path, PathTear and ResvErr messages corresponding to an LSP if 1023 node protection is requested for the LSP and both Nhop & NNhop 1024 nodes support the extensions 1026 - RI-RSVP-FRR extensions and procedures are enabled for upstream 1027 PathErr, Resv and ResvTear messages corresponding to an LSP if 1028 link protection is requested for the LSP and the Phop node 1029 supports the extensions 1031 - RI-RSVP-FRR extensions and procedures are enabled for upstream 1032 PathErr, Resv and ResvTear messages corresponding to an LSP if 1033 node protection is requested for the LSP and both Phop and the 1034 PPhop support the extensions 1036 For example, if an implementation supporting the RI-RSVP-FRR 1037 extensions specified in this document is deployed on all routers in 1038 particular region of the network and if all the LSPs in the network 1039 request node protection, then the FRR extensions will only be applied 1040 for the LSP segments that traverse the particular region. This will 1041 aid incremental deployment of these extensions and also allow reaping 1042 the benefits of the extensions in portions of the network where it is 1043 supported. 1045 5. Security Considerations 1047 The security considerations pertaining to [RFC2961], [RFC4090], 1048 [RFC8370], [RFC8796] and [RFC5920] remain relevant. When using RSVP 1049 Cryptographic Authentication [RFC2747], more robust algorithms 1050 [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed 1051 message digest where possible. 1053 This document extends the applicability of Node-ID based Hello 1054 session between immediate neighbors. The Node-ID based Hello session 1055 between the PLR and the NP-MP may require the two routers to exchange 1056 Hello messages with non-immediate neighbor. So, the implementations 1057 SHOULD provide the option to configure Node-ID neighbor specific or 1058 global authentication key to authentication messages received from 1059 Node-ID neighbors. The network administrator SHOULD utilize this 1060 option to enable RSVP-TE routers to authenticate Node-ID Hello 1061 messages received with TTL greater than 1. Implementations SHOULD 1062 also provide the option to specify a limit on the number of Node-ID 1063 based Hello sessions that can be established on a router supporting 1064 the extensions defined in this document. 1066 6. IANA Considerations 1068 6.1. New Object - CONDITIONS 1070 RSVP Change Guidelines [RFC3936] defines the Class-Number name space 1071 for RSVP objects. The name space is managed by IANA. 1073 IANA registry: RSVP Parameters Subsection: Class Names, Class 1074 Numbers, and Class Types 1076 A new RSVP object using a Class-Number from 128-183 range called the 1077 "CONDITIONS" object is defined in Section 4.4 of this document. The 1078 Class-Number from 128-183 range will be allocated by IANA. 1080 6.2. CONDITIONS Flags 1082 Apart from allocating Class-Number for the CONDITIONS object, the 1083 allocation of the Merge-point condition bit or M-bit Section 4.4 will 1084 also be done by IANA. 1086 Flag: 0x1 Name: Merge-point condition bit or M-bit 1088 7. Acknowledgements 1090 We are very grateful to Yakov Rekhter for his contributions to the 1091 development of the idea and thorough review of content of the draft. 1092 We are thankful to Raveendra Torvi and Yimin Shen for their comments 1093 and inputs on early versions of the draft. We also thank Alexander 1094 Okonnikov for his review and comments on the draft. 1096 8. Contributors 1098 Markus Jork Juniper Networks, Inc. Email: mjork@juniper.net Harish 1099 Sitaraman Individual Contributor Email: harish.ietf@gmail.com Vishnu 1100 Pavan Beeram Juniper Networks, Inc. Email: vbeeram@juniper.net Ebben 1101 Aries Arrcus, Inc. Email: exa@arrcus.com Mike Taillon Cisco Systems, 1102 Inc. Email: mtaillon@cisco.com 1104 9. References 1106 9.1. Normative References 1108 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1109 Requirement Levels", BCP 14, RFC 2119, 1110 DOI 10.17487/RFC2119, March 1997, 1111 . 1113 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1114 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1115 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1116 September 1997, . 1118 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1119 Authentication", RFC 2747, DOI 10.17487/RFC2747, January 1120 2000, . 1122 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1123 and S. Molendini, "RSVP Refresh Overhead Reduction 1124 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 1125 . 1127 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1128 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1129 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1130 . 1132 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1133 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1134 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1135 DOI 10.17487/RFC3473, January 2003, 1136 . 1138 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 1139 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 1140 DOI 10.17487/RFC3936, October 2004, 1141 . 1143 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1144 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1145 DOI 10.17487/RFC4090, May 2005, 1146 . 1148 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 1149 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 1150 A Clarification Statement", RFC 4558, 1151 DOI 10.17487/RFC4558, June 2006, 1152 . 1154 [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to 1155 GMPLS Resource Reservation Protocol (RSVP) Graceful 1156 Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, 1157 . 1159 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 1160 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 1161 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 1162 . 1164 [RFC8796] Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A., 1165 Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute 1166 Extensions for Label Switched Path (LSP) Tunnels", 1167 RFC 8796, DOI 10.17487/RFC8796, July 2020, 1168 . 1170 9.2. Informative References 1172 [FIPS-180-3] 1173 National Institute of Standards and Technology, "Secure 1174 Hash Standard", FIPS 180-3, October 2008. 1176 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1177 Hashing for Message Authentication", RFC 2104, 1178 DOI 10.17487/RFC2104, February 1997, 1179 . 1181 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1182 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1183 . 1185 Authors' Addresses 1187 Chandra Ramachandran 1188 Juniper Networks, Inc. 1190 Email: csekar@juniper.net 1192 Tarek Saad 1193 Juniper Networks, Inc. 1195 Email: tsaad@juniper.net 1197 Ina Minei 1198 Google, Inc. 1200 Email: inaminei@google.com 1201 Dante Pacella 1202 Verizon, Inc. 1204 Email: dante.j.pacella@verizon.com