idnits 2.17.1 draft-ietf-mpls-ri-rsvp-frr-11.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 (June 20, 2021) is 1012 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. Ramachandran 3 Internet-Draft T. Saad 4 Updates: 4090 (if approved) Juniper Networks, Inc. 5 Intended status: Standards Track I. Minei 6 Expires: December 22, 2021 Google, Inc. 7 D. Pacella 8 Verizon, Inc. 9 June 20, 2021 11 Refresh-interval Independent FRR Facility Protection 12 draft-ietf-mpls-ri-rsvp-frr-11 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 December 22, 2021. 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 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 . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . 21 104 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR . . . . . 21 105 4.6.2.4. Incremental Deployment . . . . . . . . . . . . . 22 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 108 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 23 109 6.2. CONDITIONS Flags . . . . . . . . . . . . . . . . . . . . 24 110 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 111 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 112 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 113 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 114 9.2. Informative References . . . . . . . . . . . . . . . . . 26 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 117 1. Introduction 119 RSVP-TE relies on periodic refresh of RSVP messages to synchronize 120 and maintain the Label Switched Path (LSP) related states along the 121 reserved path. In the absence of refresh messages, the LSP-related 122 states are automatically deleted. Reliance on periodic refreshes and 123 refresh timeouts are problematic from the scalability point of view. 124 The number of RSVP-TE LSPs that a router needs to maintain has been 125 growing in service provider networks and the implementations should 126 be capable of handling increase in LSP scale. 128 RFC 2961 specifies mechanisms to eliminate the reliance on periodic 129 refresh and refresh timeout of RSVP messages, and enables a router to 130 increase the message refresh interval to values much longer than the 131 default 30 seconds defined in RFC 2205. However, the protocol 132 extensions defined in RFC 4090 for supporting Fast ReRoute (FRR) 133 using bypass tunnels implicitly rely on short refresh timeouts to 134 cleanup stale states. 136 In order to eliminate the reliance on refresh timeouts, the routers 137 should unambiguously determine when a particular LSP state should be 138 deleted. In scenarios involving RFC 4090 FRR using bypass tunnels, 139 additional explicit tear down messages are necessary. Refresh- 140 interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in 141 this document consists of procedures to enable LSP state cleanup that 142 are essential in supporting RI-RSVP capability for RFC 4090 FRR using 143 bypass tunnels. 145 1.1. Motivation 147 Base RSVP [RFC2205] maintains state via the generation of RSVP Path/ 148 Resv refresh messages. Refresh messages are used to both synchronize 149 state between RSVP neighbors and to recover from lost RSVP messages. 150 The use of Refresh messages to cover many possible failures has 151 resulted in a number of operational problems. 153 - One problem relates to RSVP control plane scaling due to periodic 154 refreshes of Path and Resv messages, another relates to the 155 reliability and latency of RSVP signaling. 157 - An additional problem is the time to clean up the stale state 158 after a tear message is lost. For more on these problems see 159 Section 1 of RSVP Refresh Overhead Reduction Extensions [RFC2961]. 161 The problems listed above adversely affect RSVP control plane 162 scalability and RSVP-TE [RFC3209] inherited these problems from 163 standard RSVP. Procedures specified in [RFC2961] address the above 164 mentioned problems by eliminating dependency on refreshes for state 165 synchronization and for recovering from lost RSVP messages, and by 166 eliminating dependency on refresh timeout for stale state cleanup. 167 Implementing these procedures allows implementations to improve RSVP- 168 TE control plane scalability. For more details on eliminating 169 dependency on refresh timeout for stale state cleanup, refer to 170 "Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling 171 Techniques [RFC8370]. 173 However, the facility backup protection procedures specified in 174 [RFC4090] do not fully address stale state cleanup as the procedures 175 depend on refresh timeouts for stale state cleanup. The updated 176 facility backup protection procedures specified in this document, in 177 combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this 178 dependency on refresh timeouts for stale state cleanup. 180 The procedures specified in this document assume reliable delivery of 181 RSVP messages, as specified in [RFC2961]. Therefore this document 182 makes support for [RFC2961] a pre-requisite. 184 2. Terminology 186 The reader is expected to be familiar with the terminology in 187 [RFC2205], [RFC3209], [RFC4090], [RFC4558], [RFC8370] and [RFC8796]. 189 Phop node: Previous-hop router along the label switched path 191 PPhop node: Previous-Previous-hop router along the label switched 192 path 193 Nhop node: Next-hop router along the label switched path 195 NNhop node: Next-Next-hop router along the label switched path 197 PLR: Point of Local Repair router as defined in [RFC4090] 199 MP: Merge Point router as defined in [RFC4090] 201 LP-MP node: Merge Point router at the tail of Link-Protecting bypass 202 tunnel 204 NP-MP node: Merge Point router at the tail of Node-Protecting bypass 205 tunnel 207 TED: Traffic Engineering Database 209 LSP state: The combination of "path state" maintained as Path State 210 Block (PSB) and "reservation state" maintained as Reservation State 211 Block (RSB) forms an individual LSP state on an RSVP-TE speaker 213 RI-RSVP: The set of procedures defined in Section 3 of RSVP-TE 214 Scaling Techniques [RFC8370] to eliminate RSVP's reliance on periodic 215 message refreshes 217 B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object 218 defined in Summary FRR extensions [RFC8796] and is added by the PLR 219 for each protected LSP. 221 RI-RSVP-FRR: The set of procedures defined in this document to 222 elimiate RSVP's reliance of periodic message refreshes when 223 supporting facility backup protection [RFC4090] 225 Conditional PathTear: A PathTear message containing a suggestion to a 226 receiving downstream router to retain the path state if the receiving 227 router is an NP-MP 229 Remote PathTear: A PathTear message sent from a Point of Local Repair 230 (PLR) to the MP to delete the LSP state on the MP if PLR had not 231 previously sent the backup Path state reliably 233 3. Problem Description 234 E 235 / \ 236 / \ 237 / \ 238 / \ 239 / \ 240 / \ 241 A ----- B ----- C ----- D 242 \ / 243 \ / 244 \ / 245 \ / 246 \ / 247 \ / 248 F 250 Figure 1: Example Topology 252 In the topology in Figure 1, let us consider a large number of LSPs 253 from A to D transiting B and C. Assume that refresh interval has 254 been configured to be long of the order of minutes and refresh 255 reduction extensions are enabled on all routers. 257 Also let us assume that node protection has been configured for the 258 LSPs and the LSPs are protected by each router in the following way 260 - A has made node protection available using bypass LSP A -> E -> C; 261 A is the PLR and C is the NP-MP 263 - B has made node protection available using bypass LSP B -> F -> D; 264 B is the PLR and D is the NP-MP 266 - C has made link protection available using bypass LSP C -> B -> F 267 -> D; C is the PLR and D is the LP-MP 269 In the above condition, assume that B-C link fails. The following is 270 the sequence of events that is expected to occur for all protected 271 LSPs under normal conditions. 273 1. B performs local repair and re-directs LSP traffic over the bypass 274 LSP B -> F -> D. 276 2. B also creates backup state for the LSP and triggers sending of 277 backup LSP state to D over the bypass LSP B -> F -> D. 279 3. D receives backup LSP states and merges the backups with the 280 protected LSPs. 282 4. As the link on C, over which the LSP states are refreshed, has 283 failed, C will no longer receive state refreshes. Consequently 284 the protected LSP states on C will time out and C will send the 285 tear down messages for all LSPs. As each router should consider 286 itself as an MP, C will time out the state only after waiting for 287 an additional duration equal to refresh timeout. 289 While the above sequence of events has been described in [RFC4090], 290 there are a few problems for which no mechanism has been specified 291 explicitly. 293 - If the protected LSP on C times out before D receives signaling 294 for the backup LSP, then D would receive a PathTear from C prior 295 to receiving signaling for the backup LSP, thus resulting in 296 deleting the LSP state. This would be possible at scale even with 297 default refresh time. 299 - If upon the link failure C is to keep state until its timeout, 300 then with long refresh interval this may result in a large amount 301 of stale state on C. Alternatively, if upon the link failure C is 302 to delete the state and send a PathTear to D, this would result in 303 deleting the state on D, thus deleting the LSP. D needs a 304 reliable mechanism to determine whether it is an MP or not to 305 overcome this problem. 307 - If head-end A attempts to tear down LSP after step 1 but before 308 step 2 of the above sequence, then B may receive the tear down 309 message before step 2 and delete the LSP state from its state 310 database. If B deletes its state without informing D, with long 311 refresh interval this could cause (large) buildup of stale state 312 on D. 314 - If B fails to perform local repair in step 1, then B will delete 315 the LSP state from its state database without informing D. As B 316 deletes its state without informing D, with long refresh interval 317 this could cause (large) buildup of stale state on D. 319 The purpose of this document is to provide solutions to the above 320 problems which will then make it practical to scale up to a large 321 number of protected LSPs in the network. 323 4. Solution Aspects 325 The solution consists of five parts. 327 - Utilize MP determination mechanism specified in RSVP-TE Summary 328 FRR [RFC8796] that enables the PLR to signal the availability of 329 local protection to the MP. In addition, introduce PLR and MP 330 procedures to to establish Node-ID based hello session between the 331 PLR and the MP to detect router failures and to determine 332 capability. See section 4.2 for more details. This part of the 333 solution re-uses some of the extensions defined in RSVP-TE Summary 334 FRR [RFC8796] and RSVP-TE Scaling Techniques [RFC8370], and the 335 subsequent sub-sections will list the extensions in these drafts 336 that are utilized in this document. 338 - Handle upstream link or node failures by cleaning up LSP states if 339 the node has not found itself as an MP through the MP 340 determination mechanism. See section 4.3 for more details. 342 - Introduce extensions to enable a router to send a tear down 343 message to the downstream router that enables the receiving router 344 to conditionally delete its local LSP state. See section 4.4 for 345 more details. 347 - Enhance facility backup protection by allowing a PLR to directly 348 send a tear down message to the MP without requiring the PLR to 349 either have a working bypass LSP or have already signaled backup 350 LSP state. See section 4.5 for more details. 352 - Introduce extensions to enable the above procedures to be backward 353 compatible with routers along the LSP path running implementation 354 that do not support these procedures. See section 4.6 for more 355 details. 357 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP 358 Capability 360 A node supporting facility backup protection [RFC4090] MUST set the 361 RI-RSVP capability (I bit) defined in Section 3.1 of RSVP-TE Scaling 362 Techniques [RFC8370] only if it supports all the extensions specified 363 in the rest of this document. Hence, this document updates RFC 4090 364 by defining extensions and additional procedures over facility backup 365 protection [RFC4090] in order to advertise RI-RSVP capability 366 [RFC8370]. However, if a node supporting facility backup protection 367 [RFC4090] does set the RI-RSVP capability (I bit) but does not 368 support all the extensions specified in the rest of this document, 369 then it leaves room for stale state to linger around for an 370 inordinate period of time given the long refresh intervals 371 recommended by RFC 8370 or disruption of normal FRR operation. 372 Procedures for backward compatibility Section 4.6.2.3 delves on this 373 in detail. 375 4.2. Signaling Handshake between PLR and MP 377 4.2.1. PLR Behavior 379 As per the facility backup procedures [RFC4090], when an LSP becomes 380 operational on a node and the "local protection desired" flag has 381 been set in the SESSION_ATTRIBUTE object carried in the Path message 382 corresponding to the LSP, then the node attempts to make local 383 protection available for the LSP. 385 - If the "node protection desired" flag is set, then the node tries 386 to become a PLR by attempting to create a NP-bypass LSP to the 387 NNhop node avoiding the Nhop node on protected LSP path. In case 388 node protection could not be made available, the node attempts to 389 create an LP-bypass LSP to the Nhop node avoiding only the link 390 that the protected LSP takes to reach the Nhop 392 - If the "node protection desired" flag is not set, then the PLR 393 attempts to create an LP-bypass LSP to the Nhop node avoiding the 394 link that the protected LSP takes to reach the Nhop 396 With regard to the PLR procedures described above and that are 397 specified in RFC 4090, this document specifies the following 398 additional procedures to support RI-RSVP [RFC8370]. 400 - While selecting the destination address of the bypass LSP, the PLR 401 MUST select the router ID of the NNhop or Nhop node from the Node- 402 ID sub-object included in the RRO object carried in the most 403 recent Resv message corresponding to the LSP. If the MP has not 404 included a Node-ID sub-object in the Resv RRO and if the PLR and 405 the MP are in the same area, then the PLR may utilize the TED to 406 determine the router ID corresponding to the interface address 407 included by the MP in the RRO object. If the NP-MP in a different 408 IGP area has not included a Node-ID sub-object in RRO object, then 409 the PLR MUST execute backward compatibility procedures as if the 410 downstream nodes along the LSP do not support the extensions 411 defined in the document (see Section 4.6.2.1). 413 - The PLR MUST also include its router ID in a Node-ID sub-object in 414 RRO object carried in any subsequent Path message corresponding to 415 the LSP. While including its router ID in the Node-ID sub-object 416 carried in the outgoing Path message, the PLR MUST include the 417 Node-ID sub-object after including its IPv4/IPv6 address or 418 unnumbered interface ID sub-object. 420 - In parallel to the attempt made to create NP-bypass or LP-bypass, 421 the PLR MUST initiate a Node-ID based Hello session to the NNhop 422 or Nhop node respectively along the LSP to establish the RSVP-TE 423 signaling adjacency. This Hello session is used to detect MP node 424 failure as well as determine the capability of the MP node. If 425 the MP has set the I-bit in the CAPABILITY object [RFC8370] 426 carried in Hello message corresponding to the Node-ID based Hello 427 session, then the PLR MUST conclude that the MP supports refresh- 428 interval independent FRR procedures defined in this document. If 429 the MP has not sent Node-ID based Hello messages or has not set 430 the I-bit in CAPABILITY object [RFC8370], then the PLR MUST 431 execute backward compatibility procedures defined in 432 Section 4.6.2.1 of this document. 434 - When the PLR associates a bypass to a protected LSP, it MUST 435 include a B-SFRR-Ready Extended Association object [RFC8796] and 436 trigger a Path message to be sent for the LSP. If a B-SFRR-Ready 437 Extended Association object is included in the Path message 438 corresponding to the LSP, the encoding and object ordering rules 439 specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. In 440 addition to those rules, the PLR MUST set the Association Source 441 in the object to its Node-ID address. 443 4.2.2. Remote Signaling Adjacency 445 A Node-ID based RSVP-TE Hello session is one in which Node-ID is used 446 in the source and the destination address fields of RSVP Hello 447 messages [RFC4558]. This document extends Node-ID based RSVP Hello 448 session to track the state of any RSVP-TE neighbor that is not 449 directly connected by at least one interface. In order to apply 450 Node-ID based RSVP-TE Hello session between any two routers that are 451 not immediate neighbors, the router that supports the extensions 452 defined in the document MUST set TTL to 255 in all outgoing Node-ID 453 based Hello messages exchanged between the PLR and the MP. The 454 default hello interval for this Node-ID hello session MUST be set to 455 the default specified in RSVP-TE Scaling Techniques [RFC8370]. 457 In the rest of the document the term "signaling adjacency", or 458 "remote signaling adjacency" refers specifically to the RSVP-TE 459 signaling adjacency. 461 4.2.3. MP Behavior 463 With regard to the MP procedures that are defined in [RFC4090] this 464 document specifies the following additional procedures to support RI- 465 RSVP defined in [RFC8370]. 467 Each node along an LSP path supporting the extensions defined in this 468 document MUST also include its router ID in the Node-ID sub-object of 469 the RRO object carried in the Resv message of the corresponding LSP. 470 If the PLR has not included a Node-ID sub-object in the RRO object 471 carried in the Path message and if the PLR is in a different IGP 472 area, then the router MUST NOT execute the MP procedures specified in 473 this document for those LSPs. Instead, the node MUST execute 474 backward compatibility procedures defined in Section 4.6.2.2 as if 475 the upstream nodes along the LSP do not support the extensions 476 defined in this document. 478 A node receiving a Path message should determine whether the message 479 contains a B-SFRR-Ready Extended Association object with its own 480 address as the bypass destination address and whether it has an 481 operational Node-ID signaling adjacency with the Association source. 482 If the PLR has not included the B-SFRR-Ready Extended Association 483 object or if there is no operational Node-ID signaling adjacency with 484 the PLR identified by the Association source address or if the PLR 485 has not advertised RI-RSVP capability in its Node-ID based Hello 486 messages, then the node MUST execute the backward compatibility 487 procedures defined in Section 4.6.2.2. 489 If a matching B-SFRR-Ready Extended Association object is found in in 490 the Path message and if there is an operational remote Node-ID 491 signaling adjacency with the PLR (identified by the Association 492 source) that has advertised RI-RSVP capability (I-bit) [RFC8370], 493 then the node MUST consider itself as the MP for the PLR. The 494 matching and ordering rules for Bypass Summary FRR Extended 495 Association specified in RSVP-TE Summary FRR [RFC8796] MUST be 496 followed by the implementations supporting this document. 498 - If a matching Bypass Summary FRR Extended Association object is 499 included by the PPhop node of an LSP and if a corresponding Node- 500 ID signaling adjacency exists with the PPhop node, then the router 501 MUST conclude it is the NP-MP. 503 - If a matching Bypass Summary FRR Extended Association object is 504 included by the Phop node of an LSP and if a corresponding Node-ID 505 signaling adjacency exists with the Phop node, then the router 506 MUST conclude it is the LP-MP. 508 4.2.4. "Remote" State on MP 510 Once a router concludes it is the MP for a PLR running refresh- 511 interval independent FRR procedures as described in the preceding 512 section, it MUST create a remote path state for the LSP. The only 513 difference between the "remote" path state and the LSP state is the 514 RSVP_HOP object. The RSVP_HOP object in a "remote" path state 515 contains the address that the PLR uses to send Node-ID hello messages 516 to the MP. 518 The MP MUST consider the "remote" path state corresponding to the LSP 519 automatically deleted if: 521 - The MP later receives a Path message for the LSP with no matching 522 B-SFRR-Ready Extended Association object corresponding to the 523 PLR's IP address contained in the Path RRO, or 525 - The Node-ID signaling adjacency with the PLR goes down, or 527 - The MP receives backup LSP signaling for the LSP from the PLR or 529 - The MP receives a PathTear for the LSP, or 531 - The MP deletes the LSP state on a local policy or an exception 532 event 534 The purpose of "remote" path state is to enable the PLR to explicitly 535 tear down the path and reservation states corresponding to the LSP by 536 sending a tear message for the "remote" path state. Such a message 537 tearing down "remote" path state is called "Remote" PathTear. 539 The scenarios in which a "Remote" PathTear is applied are described 540 in Section 4.5. 542 4.3. Impact of Failures on LSP State 544 This section describes the procedures that must be executed upon 545 different kinds of failures by nodes along the path of the LSP. The 546 procedures that must be executed upon detecting RSVP signaling 547 adjacency failures do not impact the RSVP-TE graceful restart 548 mechanisms ([RFC3473], [RFC5063]). If a node executing these 549 procedures acts as a helper for a neighboring router, then the 550 signaling adjacency with the neighbor will be declared as having 551 failed only after taking into account the grace period extended for 552 the neighbor by this node acting as a helper. 554 Node failures are detected from the state of Node-ID hello sessions 555 established with immediate neighbors. RSVP-TE Scaling Techniques 556 [RFC8370] recommends that each node establish Node-ID hello sessions 557 with all its immediate neighbors. Non-immediate PLR or MP failure is 558 detected from the state of remote signaling adjacency established 559 according to Section 4.2.2 of this document. 561 4.3.1. Non-MP Behavior 563 When a router detects the Phop link or the Phop node failure for an 564 LSP and the router is not an MP for the LSP, then it MUST send a 565 Conditional PathTear (refer to Section 4.4 "Conditional PathTear" 566 below) and delete the PSB and RSB states corresponding to the LSP. 568 4.3.2. LP-MP Behavior 570 When the Phop link for an LSP fails on a router that is an LP-MP for 571 the LSP, the LP-MP MUST retain the PSB and RSB states corresponding 572 to the LSP till the occurrence of any of the following events. 574 - The Node-ID signaling adjacency with the Phop PLR goes down, or 576 - The MP receives a normal or "Remote" PathTear for its PSB, or 578 - The MP receives a ResvTear for its RSB. 580 When a router that is an LP-MP for an LSP detects Phop node failure 581 from the Node-ID signaling adjacency state, the LP-MP MUST send a 582 normal PathTear and delete the PSB and RSB states corresponding to 583 the LSP. 585 4.3.3. NP-MP Behavior 587 When a router that is an NP-MP for an LSP detects Phop link failure, 588 or Phop node failure from the Node-ID signaling adjacency, the router 589 MUST retain the PSB and RSB states corresponding to the LSP till the 590 occurrence of any of the following events. 592 - The remote Node-ID signaling adjacency with the PPhop PLR goes 593 down, or 595 - The MP receives a normal or "Remote" PathTear for its PSB, or 597 - The MP receives a ResvTear for its RSB. 599 When a router that is an NP-MP for an LSP did not detect the Phop 600 link or the Phop node failure, but receives a Conditional PathTear 601 from the Phop node, then the router MUST retain the PSB and RSB 602 states corresponding to the LSP till the occurrence of any of the 603 following events. 605 - The remote Node-ID signaling adjacency with the PPhop PLR goes 606 down, or 608 - The MP receives a normal or "Remote" PathTear for its PSB, or 610 - The MP receives a ResvTear for its RSB. 612 Receiving a Conditional PathTear from the Phop node will not impact 613 the "remote" state from the PPhop PLR. Note that the Phop node must 614 have sent the Conditional PathTear as it was not an MP for the LSP 615 Section 4.3.1. 617 In the example topology Figure 1, we assume C & D are the NP-MPs for 618 the PLRs A & B respectively. Now when A-B link fails, as B is not an 619 MP and its Phop link has failed, B will delete the LSP state (this 620 behavior is required for unprotected LSPs - Section 4.3.1). In the 621 data plane, that would require B to delete the label forwarding entry 622 corresponding to the LSP. So if B's downstream nodes C and D 623 continue to retain state, it would not be correct for D to continue 624 to assume itself as the NP-MP for the PLR B. 626 The mechanism that enables D to stop considering itself as the NP-MP 627 for B and delete the corresponding "remote" path state is given 628 below. 630 1. When C receives a Conditional PathTear from B, it decides to 631 retain LSP state as it is the NP-MP of the PLR A. C also MUST 632 check whether Phop B had previously signaled availability of node 633 protection. As B had previously signaled NP availability by 634 including B-SFRR-Ready Extended Association object, C MUST remove 635 the B-SFRR-Ready Extended Association object containing 636 Association Source set to B from the Path message and trigger a 637 Path to D. 639 2. When D receives the Path message, it realizes that it is no longer 640 the NP-MP for B and so it deletes the corresponding "remote" path 641 state. D does not propagate the Path further down because the 642 only change is that the B-SFRR-Ready Extended Association object 643 corresponding to Association Source B is no longer present in the 644 Path message. 646 4.3.4. Behavior of a Router that is both LP-MP and NP-MP 648 A router may simultaneously be the LP-MP as well as the NP-MP for the 649 Phop and the PPhop nodes respectively of an LSP. If the Phop link 650 fails on such a node, the node MUST retain the PSB and RSB states 651 corresponding to the LSP till the occurrence of any of the following 652 events. 654 - Both Node-ID signaling adjacencies with Phop and PPhop nodes go 655 down, or 657 - The MP receives a normal or "Remote" PathTear for its PSB, or 659 - The MP receives a ResvTear for its RSB. 661 If a router that is both an LP-MP and an NP-MP detects Phop node 662 failure, then the node MUST retain the PSB and RSB states 663 corresponding to the LSP till the occurrence of any of the following 664 events. 666 - The remote Node-ID signaling adjacency with the PPhop PLR goes 667 down, or 669 - The MP receives a normal or "Remote" PathTear for its PSB, or 671 - The MP receives a ResvTear for its RSB. 673 4.4. Conditional PathTear 675 In the example provided in the Section 4.3.3, B deletes the PSB and 676 RSB states corresponding to the LSP once B detects its Phop link went 677 down as B is not an MP. If B were to send a PathTear normally, then 678 C would delete LSP state immediately. In order to avoid this, there 679 should be some mechanism by which B can indicate to C that B does not 680 require the receiving node to unconditionally delete the LSP state 681 immediately. For this, B MUST add a new optional CONDITIONS object 682 in the PathTear. The CONDITIONS object is defined in Section 4.4.3. 683 If node C also understands the new object, then C MUST NOT delete the 684 LSP state if it is an NP-MP. 686 4.4.1. Sending Conditional PathTear 688 A router that is not an MP for an LSP MUST delete the PSB and RSB 689 states corresponding to the LSP if the Phop link or the Phop Node-ID 690 signaling adjacency goes down (Section 4.3.1). The router MUST send 691 a Conditional PathTear if the following are also true. 693 - The ingress has requested node protection for the LSP, and 695 - No PathTear is received from the upstream node 697 4.4.2. Processing Conditional PathTear 699 When a router that is not an NP-MP receives a Conditional PathTear, 700 the node MUST delete the PSB and RSB states corresponding to the LSP, 701 and process the Conditional PathTear by considering it as a normal 702 PathTear. Specifically, the node MUST NOT propagate the Conditional 703 PathTear downstream but remove the optional object and send a normal 704 PathTear downstream. 706 When a node that is an NP-MP receives a Conditional PathTear, it MUST 707 NOT delete LSP state. The node MUST check whether the Phop node had 708 previously included the B-SFRR-Ready Extended Association object in 709 the Path. If the object had been included previously by the Phop, 710 then the node processing the Conditional PathTear from the Phop MUST 711 remove the corresponding object and trigger a Path downstream. 713 If a Conditional PathTear is received from a neighbor that has not 714 advertised support (refer to Section 4.6) for the new procedures 715 defined in this document, then the node MUST consider the message as 716 a normal PathTear. The node MUST propagate the normal PathTear 717 downstream and delete the LSP state. 719 4.4.3. CONDITIONS Object 721 As any implementation that does not support Conditional PathTear MUST 722 ignore the new object but process the message as a normal PathTear 723 without generating any error, the Class-Num of the new object MUST be 724 10bbbbbb where 'b' represents a bit (from Section 3.10 of [RFC2205]). 726 The new object is called as "CONDITIONS" object that will specify the 727 conditions under which default processing rules of the RSVP-TE 728 message MUST be invoked. 730 The object has the following format: 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Length | Class | C-type | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Reserved |M| 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Figure 2: CONDITIONS Object 740 Length: This contains the size of the object in bytes and should 741 be set to eight. 743 Class: To be assigned 745 C-type: 1 747 Merge-point condition (M) bit: If the M bit is set to 1, then the 748 PathTear message MUST be processed according to the receiver 749 router role, i.e. if the receiving router is an MP or not for the 750 LSP. 751 If the M-bit is set to 0, then the PathTear message MUST be 752 processed processed as a normal PathTear message for the LSP. 754 4.5. Remote State Teardown 756 If the ingress wants to tear down the LSP because of a management 757 event while the LSP is being locally repaired at a transit PLR, it 758 would not be desirable to wait till the completion of backup LSP 759 signaling to perform state cleanup. To enable LSP state cleanup when 760 the LSP is being locally repaired, the PLR MUST send a "Remote" 761 PathTear message instructing the MP to delete the PSB and RSB states 762 corresponding to the LSP. The TTL in the "Remote" PathTear message 763 MUST be set to 255. 765 Let us consider that node C in the example topology (Figure 1) has 766 gone down and node B locally repairs the LSP. 768 1. Ingress A receives a management event to tear down the LSP. 770 2. A sends a normal PathTear for the LSP to B. 772 3. Assume B has not initiated the backup signaling for the LSP during 773 local repair. To enable LSP state cleanup, B MUST send a "Remote" 774 PathTear with destination IP address set to that of the node D 775 used in the Node-ID signaling adjacency with D, and the RSVP_HOP 776 object containing local address used in the Node-ID signaling 777 adjacency. 779 4. B then deletes the PSB and RSB states corresponding to the LSP. 781 5. On D there would be a remote signaling adjacency with B and so D 782 MUST accept the "Remote" PathTear and delete the PSB and RSB 783 states corresponding to the LSP. 785 4.5.1. PLR Behavior on Local Repair Failure 787 If local repair fails on the PLR after a failure, then this MUST be 788 considered as a case for cleaning up LSP state from the PLR to the 789 Egress. The PLR achieves state cleanup by sending "Remote" PathTear 790 to the MP. The MP MUST delete the states corresponding to the LSP 791 also also propagate the PathTear downstream thereby achieving state 792 cleanup from all downstream nodes up to the LSP egress. Note that in 793 the case of link protection, the PathTear MUST be directed to the LP- 794 MP's Node-ID IP address rather than the Nhop interface address. 796 4.5.2. PLR Behavior on Resv RRO Change 798 When a PLR router that has already made NP available for an LSP 799 detects a change in the RRO carried in the Resv message that 800 indicates that the router's former NP-MP is no longer present on the 801 path of the LSP, then the router MUST send a "Remote" PathTear 802 directly to its former NP-MP. 804 In the example topology Figure 1, let us assume A has made node 805 protection available for an LSP and C has concluded it is the NP-MP 806 for PLR A. When the B-C link fails then C, implementing the 807 procedure specified in Section 4.3.4 of this document, will retain 808 the states corresponding to the LSP until: the remote Node-ID 809 signaling adjacency with A goes down, or a PathTear or a ResvTear is 810 received for its PSB or RSB respectively. If B also has made node 811 protection available, B will eventually complete backup LSP signaling 812 with its NP-MP D and trigger a Resv to A with RRO changed. The new 813 RRO of the LSP carried in the Resv will not contain C. When A 814 processes the Resv message with a new RRO not containing C - its 815 former NP-MP, A MUST send a "Remote" PathTear to C. When C receives 816 the "Remote" PathTear for its PSB state, C will send a normal 817 PathTear downstream to D and delete both the PSB and RSB states 818 corresponding to the LSP. As D has already received backup LSP 819 signaling from B, D will retain control plane and forwarding states 820 corresponding to the LSP. 822 4.5.3. LSP Preemption during Local Repair 824 4.5.3.1. Preemption on LP-MP after Phop Link Failure 826 If an LSP is preempted on an LP-MP after its Phop or the incoming 827 link has already failed but the backup LSP has not been signaled yet 828 as part of local repair procedure, then the node MUST send a normal 829 PathTear and delete both the PSB and RSB states corresponding to the 830 LSP. As the LP-MP has retained the LSP state expecting the PLR to 831 initiate backup LSP signaling, preemption would bring down the LSP 832 and the node would not be LP-MP any more requiring the node to clean 833 up the LSP state. 835 4.5.3.2. Preemption on NP-MP after Phop Link Failure 837 If an LSP is preempted on an NP-MP after its Phop link has already 838 failed but the backup LSP has not been signaled yet, then the node 839 MUST send a normal PathTear and delete the PSB and RSB states 840 corresponding to the LSP. As the NP-MP has retained LSP state 841 expecting the PLR to initiate backup LSP signaling, preemption would 842 bring down the LSP and the node would not be NP-MP any more requiring 843 the node to clean up LSP state. 845 Let us consider that B-C link goes down on the same example topology 846 (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP 847 state. 849 1. The LSP is preempted on C. 851 2. C will delete the RSB state corresponding to the LSP. But C 852 cannot send a PathErr or a ResvTear to the PLR A because the 853 backup LSP has not been signaled yet. 855 3. As the only reason for C having retained state after Phop node 856 failure was that it was an NP-MP, C MUST send a normal PathTear to 857 D and delete its PSB state also. D would also delete the PSB and 858 RSB states on receiving a PathTear from C. 860 4. B starts backup LSP signaling to D. But as D does not have the 861 LSP state, it will reject the backup LSP Path and send a PathErr 862 to B. 864 5. B will delete its reservation and send a ResvTear to A. 866 4.6. Backward Compatibility Procedures 868 "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set 869 of procedures defined in this document to elimiate the reliance of 870 periodic refreshes. The extensions proposed in RSVP-TE Summary FRR 871 [RFC8796] may apply to implementations that do not support RI-RSVP- 872 FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state 873 cleanup namely Conditional and "Remote" PathTear require support from 874 one-hop and two-hop neighboring nodes along the LSP path. So 875 procedures that fall under LSP state cleanup category MUST NOT be 876 turned on if any of the nodes involved in the node protection FRR 877 i.e. the PLR, the MP and the intermediate node in the case of NP, 878 DOES NOT support RI-RSVP-FRR extensions. Note that for LSPs 879 requesting link protection, only the PLR and the LP-MP MUST support 880 the extensions. 882 4.6.1. Detecting Support for Refresh interval Independent FRR 884 An implementation supporting RI-RSVP-FRR extensions SHOULD set the 885 flag "Refresh interval Independent RSVP" or RI-RSVP flag in the 886 CAPABILITY object carried in Hello messages as specified in RSVP-TE 887 Scaling Techniques [RFC8370]. If an implementation does not set the 888 flag even if it supports RI-RSVP-FRR extensions, then its neighbors 889 will view the node as any node that does not support the extensions. 891 - As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID 892 based signaling adjacency with all immedate neighbors, such a node 893 on the path of a protected LSP can determine whether its Phop and 894 Nhop neighbors support RI-RSVP-FRR enhancements. 896 - As nodes supporting the RI-RSVP-FRR extensions also initiate Node- 897 ID based signaling adjacency with the NNhop along the path of the 898 LSP requested node protection Section 4.2.1, each node along the 899 LSP path can determine whether its NNhop node supports RI-RSVP-FRR 900 enhancements. If the NNhop (a) does not reply to remote Node-ID 901 Hello messages or (b) does not set the RI-RSVP flag in the 902 CAPABILITY object carried in its Node-ID Hello messages, then the 903 node acting as the PLR can conclude that NNhop does not support 904 RI-RSVP-FRR extensions. 906 - If node protection is requested for an LSP and if (a) the PPhop 907 node has not included a matching B-SFRR-Ready Extended Association 908 object in its Path messages or (b) the PPhop node has not 909 initiated remote Node-ID Hello messages or (c) the PPhop node does 910 not set the RI-RSVP flag in the CAPABILITY object carried in its 911 Node-ID Hello messages, then the node MUST conclude that the PLR 912 does not support RI-RSVP-FRR extensions. 914 4.6.2. Procedures for Backward Compatibility 916 Every node that supports RI-RSVP-FRR MUST support the procedures 917 defined in this section in order to support backward compatibility 918 for those subset of LSPs that also traverse nodes that do not support 919 RI-RSVP-FRR. 921 4.6.2.1. Lack of support on Downstream Node 923 The procedures on the downstream direction are as follows. 925 - If a node finds that the Nhop node along the LSP does not support 926 the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh 927 period" in the TIME_VALUES object carried in the Path messages to 928 the default short refresh interval. 930 - If node protection is requested for the LSP and the NNhop node 931 along the LSP path does not support the RI-RSVP-FRR extensions, 932 then the node MUST reduce the "refresh period" in the TIME_VALUES 933 object carried in the Path messages to the default short refresh 934 interval. 936 If a node reduces the refresh time using the above procedures, it 937 MUST NOT send any "Remote" PathTear or Conditional PathTear message 938 to the downstream node. 940 Consider the example topology in Figure 1. If C does not support the 941 RI-RSVP-FRR extensions, then: 943 - A and B MUST reduce the refresh time to the default short refresh 944 interval of 30 seconds and trigger a Path message 946 - If B is not an MP and if Phop link of B fails, B cannot send 947 Conditional PathTear to C but MUST time out the PSB state from A 948 normally. Note that B can time out the PSB state A normally only 949 if A did not set long refresh in the TIME_VALUES object carried in 950 the Path messages sent earlier. 952 4.6.2.2. Lack of support on Upstream Node 954 The procedures are as follows. 956 - If a node finds that the Phop node along the LSP path does not 957 support the RI-RSVP-FRR extensions, then the node MUST reduce the 958 "refresh period" in the TIME_VALUES object carried in the Resv 959 messages to the default short refresh interval. 961 - If node protection is requested for the LSP and the Phop node 962 along the LSP path does not support the RI-RSVP-FRR extensions, 963 then the the node MUST reduce the "refresh period" in the 964 TIME_VALUES object carried in the Path messages to the default 965 short refresh interval (thus, the Nhop can use compatible values 966 when sending a Resv). 968 - If node protection is requested for the LSP and the PPhop node 969 does not support the RI-RSVP-FRR extensions, then the node MUST 970 reduce the "refresh period" in the TIME_VALUES object carried in 971 the Resv messages to the default short refresh interval. 973 - If the node reduces the refresh time using the above procedures, 974 it MUST NOT execute MP procedures specified in Section 4.3 of this 975 document. 977 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR 979 If a node supporting facility backup protection [RFC4090] sets the 980 RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR 981 extensions, then it leaves room for stale state to linger around for 982 an inordinate period of time or disruption of normal FRR operation 983 (Section 3). Consider the example topology Figure 1 provided in this 984 document. 986 - Assume node B does set RI-RSVP capability in its Node-ID based 987 Hello messages even though it does not support RI-RSVP-FRR 988 extensions. When B detects the failure of its Phop link along an 989 LSP, it will not send Conditional PathTear to C as required by the 990 RI-RSVP-FRR procedures. If B simply leaves the LSP state without 991 deleting, then B may end up holding on to the stale state until 992 the (long) refresh timeout. 994 - Intead of node B, assume node C does set RI-RSVP capability in its 995 Node-id based Hello messages even though it does not support RI- 996 RSVP-FRR extensions. When B details the failure of its Phop link 997 along an LSP, it will send Conditional PathTear to C as required 998 by the RI-RSVP-FRR procedures. But, C would not recognize the 999 condition encoded in the PathTear and end up tearing down the LSP. 1001 - Assume node B does set RI-RSVP capability in its Node-ID based 1002 Hello messages even though it does not support RI-RSVP-FRR 1003 extensions. Also assume local repair is about to commence on node 1004 B for an LSP that has only requested link protection. That is, B 1005 has not initiated the backup LSP signaling for the LSP. If node B 1006 receives a normal PathTear at this time from ingress A because of 1007 a management event initiated on A, then B simply deletes the LSP 1008 state without sending a Remote PathTear to the LP-MP C. So, C may 1009 end up holding on to the stale state until the (long) refresh 1010 timeout. 1012 4.6.2.4. Incremental Deployment 1014 The backward compatibility procedures described in the previous sub- 1015 sections imply that a router supporting the RI-RSVP-FRR extensions 1016 specified in this document can apply the procedures specified in the 1017 document either in the downstream or upstream direction of an LSP, 1018 depending on the capability of the routers downstream or upstream in 1019 the LSP path. 1021 - RI-RSVP-FRR extensions and procedures are enabled for downstream 1022 Path, PathTear and ResvErr messages corresponding to an LSP if 1023 link protection is requested for the LSP and the Nhop node 1024 supports the extensions 1026 - RI-RSVP-FRR extensions and procedures are enabled for downstream 1027 Path, PathTear and ResvErr messages corresponding to an LSP if 1028 node protection is requested for the LSP and both Nhop & NNhop 1029 nodes support 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 link protection is requested for the LSP and the Phop node 1034 supports the extensions 1036 - RI-RSVP-FRR extensions and procedures are enabled for upstream 1037 PathErr, Resv and ResvTear messages corresponding to an LSP if 1038 node protection is requested for the LSP and both Phop and the 1039 PPhop support the extensions 1041 For example, if an implementation supporting the RI-RSVP-FRR 1042 extensions specified in this document is deployed on all routers in 1043 particular region of the network and if all the LSPs in the network 1044 request node protection, then the FRR extensions will only be applied 1045 for the LSP segments that traverse the particular region. This will 1046 aid incremental deployment of these extensions and also allow reaping 1047 the benefits of the extensions in portions of the network where it is 1048 supported. 1050 5. Security Considerations 1052 The security considerations pertaining to [RFC2961], [RFC4090], 1053 [RFC8370], [RFC8796] and [RFC5920] remain relevant. When using RSVP 1054 Cryptographic Authentication [RFC2747], more robust algorithms 1055 [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed 1056 message digest where possible. 1058 This document extends the applicability of Node-ID based Hello 1059 session between immediate neighbors. The Node-ID based Hello session 1060 between the PLR and the NP-MP may require the two routers to exchange 1061 Hello messages with non-immediate neighbor. So, the implementations 1062 SHOULD provide the option to configure Node-ID neighbor specific or 1063 global authentication key to authentication messages received from 1064 Node-ID neighbors. The network administrator SHOULD utilize this 1065 option to enable RSVP-TE routers to authenticate Node-ID Hello 1066 messages received with TTL greater than 1. Implementations SHOULD 1067 also provide the option to specify a limit on the number of Node-ID 1068 based Hello sessions that can be established on a router supporting 1069 the extensions defined in this document. 1071 6. IANA Considerations 1073 6.1. New Object - CONDITIONS 1075 RSVP Change Guidelines [RFC3936] defines the Class-Number name space 1076 for RSVP objects. The name space is managed by IANA. 1078 IANA registry: RSVP Parameters 1079 Subsection: Class Names, Class Numbers, and Class Types 1081 A new RSVP object using a Class-Number from 128-183 range called the 1082 "CONDITIONS" object is defined in Section 4.4 of this document. The 1083 Class-Number from 128-183 range will be allocated by IANA. 1085 6.2. CONDITIONS Flags 1087 Apart from allocating Class-Number for the CONDITIONS object, the 1088 allocation of the Merge-point condition bit or M-bit Section 4.4 will 1089 also be done by IANA. 1091 Flag: 0x1 Name: Merge-point condition bit or M-bit 1093 7. Acknowledgements 1095 We are very grateful to Yakov Rekhter for his contributions to the 1096 development of the idea and thorough review of content of the draft. 1097 We are thankful to Raveendra Torvi and Yimin Shen for their comments 1098 and inputs on early versions of the draft. We also thank Alexander 1099 Okonnikov for his review and comments on the draft. 1101 8. Contributors 1103 Markus Jork 1104 Juniper Networks, Inc. 1105 Email: mjork@juniper.net 1107 Harish Sitaraman 1108 Individual Contributor 1109 Email: harish.ietf@gmail.com 1111 Vishnu Pavan Beeram 1112 Juniper Networks, Inc. 1113 Email: vbeeram@juniper.net 1115 Ebben Aries 1116 Arrcus, Inc. 1117 Email: exa@arrcus.com 1119 Mike Taillon 1120 Cisco Systems, Inc. 1121 Email: mtaillon@cisco.com 1123 9. References 1125 9.1. Normative References 1127 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1128 Requirement Levels", BCP 14, RFC 2119, 1129 DOI 10.17487/RFC2119, March 1997, 1130 . 1132 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1133 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1134 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1135 September 1997, . 1137 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1138 Authentication", RFC 2747, DOI 10.17487/RFC2747, January 1139 2000, . 1141 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1142 and S. Molendini, "RSVP Refresh Overhead Reduction 1143 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 1144 . 1146 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1147 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1148 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1149 . 1151 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1152 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1153 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1154 DOI 10.17487/RFC3473, January 2003, 1155 . 1157 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 1158 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 1159 DOI 10.17487/RFC3936, October 2004, 1160 . 1162 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1163 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1164 DOI 10.17487/RFC4090, May 2005, 1165 . 1167 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 1168 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 1169 A Clarification Statement", RFC 4558, 1170 DOI 10.17487/RFC4558, June 2006, 1171 . 1173 [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to 1174 GMPLS Resource Reservation Protocol (RSVP) Graceful 1175 Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, 1176 . 1178 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 1179 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 1180 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 1181 . 1183 [RFC8796] Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A., 1184 Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute 1185 Extensions for Label Switched Path (LSP) Tunnels", 1186 RFC 8796, DOI 10.17487/RFC8796, July 2020, 1187 . 1189 9.2. Informative References 1191 [FIPS-180-3] 1192 National Institute of Standards and Technology, "Secure 1193 Hash Standard", FIPS 180-3, October 2008. 1195 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1196 Hashing for Message Authentication", RFC 2104, 1197 DOI 10.17487/RFC2104, February 1997, 1198 . 1200 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1201 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1202 . 1204 Authors' Addresses 1206 Chandra Ramachandran 1207 Juniper Networks, Inc. 1209 Email: csekar@juniper.net 1211 Tarek Saad 1212 Juniper Networks, Inc. 1214 Email: tsaad@juniper.net 1216 Ina Minei 1217 Google, Inc. 1219 Email: inaminei@google.com 1220 Dante Pacella 1221 Verizon, Inc. 1223 Email: dante.j.pacella@verizon.com