idnits 2.17.1 draft-ietf-mpls-ri-rsvp-frr-09.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 (November 22, 2020) is 1249 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: May 26, 2021 Google, Inc. 7 D. Pacella 8 Verizon, Inc. 9 November 22, 2020 11 Refresh-interval Independent FRR Facility Protection 12 draft-ietf-mpls-ri-rsvp-frr-09 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 May 26, 2021. 54 Copyright Notice 56 Copyright (c) 2020 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] MAY 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. A node supporting facility backup 364 protection [RFC4090] but not supporting the extensions specified in 365 this document MUST NOT set the RI-RSVP capability (I bit) in the 366 outgoing Node-ID based Hello messages. Hence, this document updates 367 RFC 4090 by defining extensions and additional procedures over 368 facility backup protection [RFC4090] in order to advertise RI-RSVP 369 capability [RFC8370]. However, if a node supporting facility backup 370 protection [RFC4090] does set the RI-RSVP capability (I bit) but does 371 not support all the extensions specified in the rest of this 372 document, then it leaves room for stale state to linger around for an 373 inordinate period of time given the long refresh intervals 374 recommended by RFC 8370 or disruption of normal FRR operation. 375 Procedures for backward compatibility Section 4.6.2.3 delves on this 376 in detail. 378 4.2. Signaling Handshake between PLR and MP 380 4.2.1. PLR Behavior 382 As per the facility backup procedures [RFC4090], when an LSP becomes 383 operational on a node and the "local protection desired" flag has 384 been set in the SESSION_ATTRIBUTE object carried in the Path message 385 corresponding to the LSP, then the node attempts to make local 386 protection available for the LSP. 388 - If the "node protection desired" flag is set, then the node tries 389 to become a PLR by attempting to create a NP-bypass LSP to the 390 NNhop node avoiding the Nhop node on protected LSP path. In case 391 node protection could not be made available, the node attempts to 392 create an LP-bypass LSP to the Nhop node avoiding only the link 393 that the protected LSP takes to reach the Nhop 395 - If the "node protection desired" flag is not set, then the PLR 396 attempts to create an LP-bypass LSP to the Nhop node avoiding the 397 link that the protected LSP takes to reach the Nhop 399 With regard to the PLR procedures described above and that are 400 specified in RFC 4090, this document specifies the following 401 additional procedures to support RI-RSVP [RFC8370]. 403 - While selecting the destination address of the bypass LSP, the PLR 404 MUST select the router ID of the NNhop or Nhop node from the Node- 405 ID sub-object included in the RRO object carried in the most 406 recent Resv message corresponding to the LSP. If the MP has not 407 included a Node-ID sub-object in the Resv RRO and if the PLR and 408 the MP are in the same area, then the PLR may utilize the TED to 409 determine the router ID corresponding to the interface address 410 included by the MP in the RRO object. If the NP-MP in a different 411 IGP area has not included a Node-ID sub-object in RRO object, then 412 the PLR MUST execute backward compatibility procedures as if the 413 downstream nodes along the LSP do not support the extensions 414 defined in the document (see Section 4.6.2.1). 416 - The PLR MUST also include its router ID in a Node-ID sub-object in 417 RRO object carried in any subsequent Path message corresponding to 418 the LSP. While including its router ID in the Node-ID sub-object 419 carried in the outgoing Path message, the PLR MUST include the 420 Node-ID sub-object after including its IPv4/IPv6 address or 421 unnumbered interface ID sub-object. 423 - In parallel to the attempt made to create NP-bypass or LP-bypass, 424 the PLR MUST initiate a Node-ID based Hello session to the NNhop 425 or Nhop node respectively along the LSP to establish the RSVP-TE 426 signaling adjacency. This Hello session is used to detect MP node 427 failure as well as determine the capability of the MP node. If 428 the MP has set the I-bit in the CAPABILITY object [RFC8370] 429 carried in Hello message corresponding to the Node-ID based Hello 430 session, then the PLR MUST conclude that the MP supports refresh- 431 interval independent FRR procedures defined in this document. If 432 the MP has not sent Node-ID based Hello messages or has not set 433 the I-bit in CAPABILITY object [RFC8370], then the PLR MUST 434 execute backward compatibility procedures defined in 435 Section 4.6.2.1 of this document. 437 - When the PLR associates a bypass to a protected LSP, it MUST 438 include a B-SFRR-Ready Extended Association object [RFC8796] and 439 trigger a Path message to be sent for the LSP. If a B-SFRR-Ready 440 Extended Association object is included in the Path message 441 corresponding to the LSP, the encoding and object ordering rules 442 specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. In 443 addition to those rules, the PLR MUST set the Association Source 444 in the object to its Node-ID address. 446 4.2.2. Remote Signaling Adjacency 448 A Node-ID based RSVP-TE Hello session is one in which Node-ID is used 449 in the source and the destination address fields of RSVP Hello 450 messages [RFC4558]. This document extends Node-ID based RSVP Hello 451 session to track the state of any RSVP-TE neighbor that is not 452 directly connected by at least one interface. In order to apply 453 Node-ID based RSVP-TE Hello session between any two routers that are 454 not immediate neighbors, the router that supports the extensions 455 defined in the document MUST set TTL to 255 in all outgoing Node-ID 456 based Hello messages exchanged between the PLR and the MP. The 457 default hello interval for this Node-ID hello session MUST be set to 458 the default specified in RSVP-TE Scaling Techniques [RFC8370]. 460 In the rest of the document the term "signaling adjacency", or 461 "remote signaling adjacency" refers specifically to the RSVP-TE 462 signaling adjacency. 464 4.2.3. MP Behavior 466 With regard to the MP procedures that are defined in [RFC4090] this 467 document specifies the following additional procedures to support RI- 468 RSVP defined in [RFC8370]. 470 Each node along an LSP path supporting the extensions defined in this 471 document MUST also include its router ID in the Node-ID sub-object of 472 the RRO object carried in the Resv message of the corresponding LSP. 473 If the PLR has not included a Node-ID sub-object in the RRO object 474 carried in the Path message and if the PLR is in a different IGP 475 area, then the router MUST NOT execute the MP procedures specified in 476 this document for those LSPs. Instead, the node MUST execute 477 backward compatibility procedures defined in Section 4.6.2.2 as if 478 the upstream nodes along the LSP do not support the extensions 479 defined in this document. 481 A node receiving a Path message should determine whether the message 482 contains a B-SFRR-Ready Extended Association object with its own 483 address as the bypass destination address and whether it has an 484 operational Node-ID signaling adjacency with the Association source. 485 If the PLR has not included the B-SFRR-Ready Extended Association 486 object or if there is no operational Node-ID signaling adjacency with 487 the PLR identified by the Association source address or if the PLR 488 has not advertised RI-RSVP capability in its Node-ID based Hello 489 messages, then the node MUST execute the backward compatibility 490 procedures defined in Section 4.6.2.2. 492 If a matching B-SFRR-Ready Extended Association object is found in in 493 the Path message and if there is an operational remote Node-ID 494 signaling adjacency with the PLR (identified by the Association 495 source) that has advertised RI-RSVP capability (I-bit) [RFC8370], 496 then the node MUST consider itself as the MP for the PLR. The 497 matching and ordering rules for Bypass Summary FRR Extended 498 Association specified in RSVP-TE Summary FRR [RFC8796] MUST be 499 followed by the implementations supporting this document. 501 - If a matching Bypass Summary FRR Extended Association object is 502 included by the PPhop node of an LSP and if a corresponding Node- 503 ID signaling adjacency exists with the PPhop node, then the router 504 MUST conclude it is the NP-MP. 506 - If a matching Bypass Summary FRR Extended Association object is 507 included by the Phop node of an LSP and if a corresponding Node-ID 508 signaling adjacency exists with the Phop node, then the router 509 MUST conclude it is the LP-MP. 511 4.2.4. "Remote" State on MP 513 Once a router concludes it is the MP for a PLR running refresh- 514 interval independent FRR procedures as described in the preceding 515 section, it MUST create a remote path state for the LSP. The only 516 difference between the "remote" path state and the LSP state is the 517 RSVP_HOP object. The RSVP_HOP object in a "remote" path state 518 contains the address that the PLR uses to send Node-ID hello messages 519 to the MP. 521 The MP MUST consider the "remote" path state corresponding to the LSP 522 automatically deleted if: 524 - The MP later receives a Path message for the LSP with no matching 525 B-SFRR-Ready Extended Association object corresponding to the 526 PLR's IP address contained in the Path RRO, or 528 - The Node-ID signaling adjacency with the PLR goes down, or 530 - The MP receives backup LSP signaling for the LSP from the PLR or 532 - The MP receives a PathTear for the LSP, or 534 - The MP deletes the LSP state on a local policy or an exception 535 event 537 The purpose of "remote" path state is to enable the PLR to explicitly 538 tear down the path and reservation states corresponding to the LSP by 539 sending a tear message for the "remote" path state. Such a message 540 tearing down "remote" path state is called "Remote" PathTear. 542 The scenarios in which a "Remote" PathTear is applied are described 543 in Section 4.5. 545 4.3. Impact of Failures on LSP State 547 This section describes the procedures that must be executed upon 548 different kinds of failures by nodes along the path of the LSP. The 549 procedures that must be executed upon detecting RSVP signaling 550 adjacency failures do not impact the RSVP-TE graceful restart 551 mechanisms ([RFC3473], [RFC5063]). If a node executing these 552 procedures acts as a helper for a neighboring router, then the 553 signaling adjacency with the neighbor will be declared as having 554 failed only after taking into account the grace period extended for 555 the neighbor by this node acting as a helper. 557 Node failures are detected from the state of Node-ID hello sessions 558 established with immediate neighbors. RSVP-TE Scaling Techniques 559 [RFC8370] recommends that each node establish Node-ID hello sessions 560 with all its immediate neighbors. Non-immediate PLR or MP failure is 561 detected from the state of remote signaling adjacency established 562 according to Section 4.2.2 of this document. 564 4.3.1. Non-MP Behavior 566 When a router detects the Phop link or the Phop node failure for an 567 LSP and the router is not an MP for the LSP, then it MUST send a 568 Conditional PathTear (refer to Section 4.4 "Conditional PathTear" 569 below) and delete the PSB and RSB states corresponding to the LSP. 571 4.3.2. LP-MP Behavior 573 When the Phop link for an LSP fails on a router that is an LP-MP for 574 the LSP, the LP-MP MUST retain the PSB and RSB states corresponding 575 to the LSP till the occurrence of any of the following events. 577 - The Node-ID signaling adjacency with the Phop PLR goes down, or 579 - The MP receives a normal or "Remote" PathTear for its PSB, or 581 - The MP receives a ResvTear for its RSB. 583 When a router that is an LP-MP for an LSP detects Phop node failure 584 from the Node-ID signaling adjacency state, the LP-MP MUST send a 585 normal PathTear and delete the PSB and RSB states corresponding to 586 the LSP. 588 4.3.3. NP-MP Behavior 590 When a router that is an NP-MP for an LSP detects Phop link failure, 591 or Phop node failure from the Node-ID signaling adjacency, the router 592 MUST retain the PSB and RSB states corresponding to the LSP till the 593 occurrence of any of the following events. 595 - The remote Node-ID signaling adjacency with the PPhop PLR goes 596 down, or 598 - The MP receives a normal or "Remote" PathTear for its PSB, or 600 - The MP receives a ResvTear for its RSB. 602 When a router that is an NP-MP for an LSP did not detect the Phop 603 link or the Phop node failure, but receives a Conditional PathTear 604 from the Phop node, then the router MUST retain the PSB and RSB 605 states corresponding to the LSP till the occurrence of any of the 606 following events. 608 - The remote Node-ID signaling adjacency with the PPhop PLR goes 609 down, or 611 - The MP receives a normal or "Remote" PathTear for its PSB, or 613 - The MP receives a ResvTear for its RSB. 615 Receiving a Conditional PathTear from the Phop node will not impact 616 the "remote" state from the PPhop PLR. Note that the Phop node must 617 have sent the Conditional PathTear as it was not an MP for the LSP 618 Section 4.3.1. 620 In the example topology Figure 1, we assume C & D are the NP-MPs for 621 the PLRs A & B respectively. Now when A-B link fails, as B is not an 622 MP and its Phop link has failed, B will delete the LSP state (this 623 behavior is required for unprotected LSPs - Section 4.3.1). In the 624 data plane, that would require B to delete the label forwarding entry 625 corresponding to the LSP. So if B's downstream nodes C and D 626 continue to retain state, it would not be correct for D to continue 627 to assume itself as the NP-MP for the PLR B. 629 The mechanism that enables D to stop considering itself as the NP-MP 630 for B and delete the corresponding "remote" path state is given 631 below. 633 1. When C receives a Conditional PathTear from B, it decides to 634 retain LSP state as it is the NP-MP of the PLR A. C also MUST 635 check whether Phop B had previously signaled availability of node 636 protection. As B had previously signaled NP availability by 637 including B-SFRR-Ready Extended Association object, C MUST remove 638 the B-SFRR-Ready Extended Association object containing 639 Association Source set to B from the Path message and trigger a 640 Path to D. 642 2. When D receives the Path message, it realizes that it is no longer 643 the NP-MP for B and so it deletes the corresponding "remote" path 644 state. D does not propagate the Path further down because the 645 only change is that the B-SFRR-Ready Extended Association object 646 corresponding to Association Source B is no longer present in the 647 Path message. 649 4.3.4. Behavior of a Router that is both LP-MP and NP-MP 651 A router may simultaneously be the LP-MP as well as the NP-MP for the 652 Phop and the PPhop nodes respectively of an LSP. If the Phop link 653 fails on such a node, the node MUST retain the PSB and RSB states 654 corresponding to the LSP till the occurrence of any of the following 655 events. 657 - Both Node-ID signaling adjacencies with Phop and PPhop nodes go 658 down, or 660 - The MP receives a normal or "Remote" PathTear for its PSB, or 662 - The MP receives a ResvTear for its RSB. 664 If a router that is both an LP-MP and an NP-MP detects Phop node 665 failure, then the node MUST retain the PSB and RSB states 666 corresponding to the LSP till the occurrence of any of the following 667 events. 669 - The remote Node-ID signaling adjacency with the PPhop PLR goes 670 down, or 672 - The MP receives a normal or "Remote" PathTear for its PSB, or 674 - The MP receives a ResvTear for its RSB. 676 4.4. Conditional PathTear 678 In the example provided in the Section 4.3.3, B deletes the PSB and 679 RSB states corresponding to the LSP once B detects its Phop link went 680 down as B is not an MP. If B were to send a PathTear normally, then 681 C would delete LSP state immediately. In order to avoid this, there 682 should be some mechanism by which B can indicate to C that B does not 683 require the receiving node to unconditionally delete the LSP state 684 immediately. For this, B MUST add a new optional CONDITIONS object 685 in the PathTear. The CONDITIONS object is defined in Section 4.4.3. 686 If node C also understands the new object, then C MUST NOT delete the 687 LSP state if it is an NP-MP. 689 4.4.1. Sending Conditional PathTear 691 A router that is not an MP for an LSP MUST delete the PSB and RSB 692 states corresponding to the LSP if the Phop link or the Phop Node-ID 693 signaling adjacency goes down (Section 4.3.1). The router MUST send 694 a Conditional PathTear if the following are also true. 696 - The ingress has requested node protection for the LSP, and 698 - No PathTear is received from the upstream node 700 4.4.2. Processing Conditional PathTear 702 When a router that is not an NP-MP receives a Conditional PathTear, 703 the node MUST delete the PSB and RSB states corresponding to the LSP, 704 and process the Conditional PathTear by considering it as a normal 705 PathTear. Specifically, the node MUST NOT propagate the Conditional 706 PathTear downstream but remove the optional object and send a normal 707 PathTear downstream. 709 When a node that is an NP-MP receives a Conditional PathTear, it MUST 710 NOT delete LSP state. The node MUST check whether the Phop node had 711 previously included the B-SFRR-Ready Extended Association object in 712 the Path. If the object had been included previously by the Phop, 713 then the node processing the Conditional PathTear from the Phop MUST 714 remove the corresponding object and trigger a Path downstream. 716 If a Conditional PathTear is received from a neighbor that has not 717 advertised support (refer to Section 4.6) for the new procedures 718 defined in this document, then the node MUST consider the message as 719 a normal PathTear. The node MUST propagate the normal PathTear 720 downstream and delete the LSP state. 722 4.4.3. CONDITIONS Object 724 As any implementation that does not support Conditional PathTear MUST 725 ignore the new object but process the message as a normal PathTear 726 without generating any error, the Class-Num of the new object MUST be 727 10bbbbbb where 'b' represents a bit (from Section 3.10 of [RFC2205]). 729 The new object is called as "CONDITIONS" object that will specify the 730 conditions under which default processing rules of the RSVP-TE 731 message MUST be invoked. 733 The object has the following format: 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Length | Class | C-type | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Reserved |M| 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Figure 2: CONDITIONS Object 743 Length: This contains the size of the object in bytes and should 744 be set to eight. 746 Class: To be assigned 748 C-type: 1 750 Merge-point condition (M) bit: If the M bit is set to 1, then the 751 PathTear message MUST be processed according to the receiver 752 router role, i.e. if the receiving router is an MP or not for the 753 LSP. 754 If the M-bit is set to 0, then the PathTear message MUST be 755 processed processed as a normal PathTear message for the LSP. 757 4.5. Remote State Teardown 759 If the ingress wants to tear down the LSP because of a management 760 event while the LSP is being locally repaired at a transit PLR, it 761 would not be desirable to wait till the completion of backup LSP 762 signaling to perform state cleanup. To enable LSP state cleanup when 763 the LSP is being locally repaired, the PLR MUST send a "Remote" 764 PathTear message instructing the MP to delete the PSB and RSB states 765 corresponding to the LSP. The TTL in the "Remote" PathTear message 766 MUST be set to 255. 768 Let us consider that node C in the example topology (Figure 1) has 769 gone down and node B locally repairs the LSP. 771 1. Ingress A receives a management event to tear down the LSP. 773 2. A sends a normal PathTear for the LSP to B. 775 3. Assume B has not initiated the backup signaling for the LSP during 776 local repair. To enable LSP state cleanup, B MUST send a "Remote" 777 PathTear with destination IP address set to that of the node D 778 used in the Node-ID signaling adjacency with D, and the RSVP_HOP 779 object containing local address used in the Node-ID signaling 780 adjacency. 782 4. B then deletes the PSB and RSB states corresponding to the LSP. 784 5. On D there would be a remote signaling adjacency with B and so D 785 MUST accept the "Remote" PathTear and delete the PSB and RSB 786 states corresponding to the LSP. 788 4.5.1. PLR Behavior on Local Repair Failure 790 If local repair fails on the PLR after a failure, then this MUST be 791 considered as a case for cleaning up LSP state from the PLR to the 792 Egress. The PLR achieves state cleanup by sending "Remote" PathTear 793 to the MP. The MP MUST delete the states corresponding to the LSP 794 also also propagate the PathTear downstream thereby achieving state 795 cleanup from all downstream nodes up to the LSP egress. Note that in 796 the case of link protection, the PathTear MUST be directed to the LP- 797 MP's Node-ID IP address rather than the Nhop interface address. 799 4.5.2. PLR Behavior on Resv RRO Change 801 When a PLR router that has already made NP available for an LSP 802 detects a change in the RRO carried in the Resv message that 803 indicates that the router's former NP-MP is no longer present on the 804 path of the LSP, then the router MUST send a "Remote" PathTear 805 directly to its former NP-MP. 807 In the example topology Figure 1, let us assume A has made node 808 protection available for an LSP and C has concluded it is the NP-MP 809 for PLR A. When the B-C link fails then C, implementing the 810 procedure specified in Section 4.3.4 of this document, will retain 811 the states corresponding to the LSP until: the remote Node-ID 812 signaling adjacency with A goes down, or a PathTear or a ResvTear is 813 received for its PSB or RSB respectively. If B also has made node 814 protection available, B will eventually complete backup LSP signaling 815 with its NP-MP D and trigger a Resv to A with RRO changed. The new 816 RRO of the LSP carried in the Resv will not contain C. When A 817 processes the Resv message with a new RRO not containing C - its 818 former NP-MP, A MUST send a "Remote" PathTear to C. When C receives 819 the "Remote" PathTear for its PSB state, C will send a normal 820 PathTear downstream to D and delete both the PSB and RSB states 821 corresponding to the LSP. As D has already received backup LSP 822 signaling from B, D will retain control plane and forwarding states 823 corresponding to the LSP. 825 4.5.3. LSP Preemption during Local Repair 827 4.5.3.1. Preemption on LP-MP after Phop Link Failure 829 If an LSP is preempted on an LP-MP after its Phop or the incoming 830 link has already failed but the backup LSP has not been signaled yet 831 as part of local repair procedure, then the node MUST send a normal 832 PathTear and delete both the PSB and RSB states corresponding to the 833 LSP. As the LP-MP has retained the LSP state expecting the PLR to 834 initiate backup LSP signaling, preemption would bring down the LSP 835 and the node would not be LP-MP any more requiring the node to clean 836 up the LSP state. 838 4.5.3.2. Preemption on NP-MP after Phop Link Failure 840 If an LSP is preempted on an NP-MP after its Phop link has already 841 failed but the backup LSP has not been signaled yet, then the node 842 MUST send a normal PathTear and delete the PSB and RSB states 843 corresponding to the LSP. As the NP-MP has retained LSP state 844 expecting the PLR to initiate backup LSP signaling, preemption would 845 bring down the LSP and the node would not be NP-MP any more requiring 846 the node to clean up LSP state. 848 Let us consider that B-C link goes down on the same example topology 849 (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP 850 state. 852 1. The LSP is preempted on C. 854 2. C will delete the RSB state corresponding to the LSP. But C 855 cannot send a PathErr or a ResvTear to the PLR A because the 856 backup LSP has not been signaled yet. 858 3. As the only reason for C having retained state after Phop node 859 failure was that it was an NP-MP, C MUST send a normal PathTear to 860 D and delete its PSB state also. D would also delete the PSB and 861 RSB states on receiving a PathTear from C. 863 4. B starts backup LSP signaling to D. But as D does not have the 864 LSP state, it will reject the backup LSP Path and send a PathErr 865 to B. 867 5. B will delete its reservation and send a ResvTear to A. 869 4.6. Backward Compatibility Procedures 871 "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set 872 of procedures defined in this document to elimiate the reliance of 873 periodic refreshes. The extensions proposed in RSVP-TE Summary FRR 874 [RFC8796] may apply to implementations that do not support RI-RSVP- 875 FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state 876 cleanup namely Conditional and "Remote" PathTear require support from 877 one-hop and two-hop neighboring nodes along the LSP path. So 878 procedures that fall under LSP state cleanup category MUST NOT be 879 turned on if any of the nodes involved in the node protection FRR 880 i.e. the PLR, the MP and the intermediate node in the case of NP, 881 DOES NOT support RI-RSVP-FRR extensions. Note that for LSPs 882 requesting link protection, only the PLR and the LP-MP MUST support 883 the extensions. 885 4.6.1. Detecting Support for Refresh interval Independent FRR 887 An implementation supporting RI-RSVP-FRR extensions SHOULD set the 888 flag "Refresh interval Independent RSVP" or RI-RSVP flag in the 889 CAPABILITY object carried in Hello messages as specified in RSVP-TE 890 Scaling Techniques [RFC8370]. If an implementation does not set the 891 flag even if it supports RI-RSVP-FRR extensions, then its neighbors 892 will view the node as any node that does not support the extensions. 894 - As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID 895 based signaling adjacency with all immedate neighbors, such a node 896 on the path of a protected LSP can determine whether its Phop and 897 Nhop neighbors support RI-RSVP-FRR enhancements. 899 - As nodes supporting the RI-RSVP-FRR extensions also initiate Node- 900 ID based signaling adjacency with the NNhop along the path of the 901 LSP requested node protection Section 4.2.1, each node along the 902 LSP path can determine whether its NNhop node supports RI-RSVP-FRR 903 enhancements. If the NNhop (a) does not reply to remote Node-ID 904 Hello messages or (b) does not set the RI-RSVP flag in the 905 CAPABILITY object carried in its Node-ID Hello messages, then the 906 node acting as the PLR can conclude that NNhop does not support 907 RI-RSVP-FRR extensions. 909 - If node protection is requested for an LSP and if (a) the PPhop 910 node has not included a matching B-SFRR-Ready Extended Association 911 object in its Path messages or (b) the PPhop node has not 912 initiated remote Node-ID Hello messages or (c) the PPhop node does 913 not set the RI-RSVP flag in the CAPABILITY object carried in its 914 Node-ID Hello messages, then the node MUST conclude that the PLR 915 does not support RI-RSVP-FRR extensions. 917 4.6.2. Procedures for Backward Compatibility 919 Every node that supports RI-RSVP-FRR MUST support the procedures 920 defined in this section in order to support backward compatibility 921 for those subset of LSPs that also traverse nodes that do not support 922 RI-RSVP-FRR. 924 4.6.2.1. Lack of support on Downstream Node 926 The procedures on the downstream direction are as follows. 928 - If a node finds that the Nhop node along the LSP does not support 929 the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh 930 period" in the TIME_VALUES object carried in the Path messages to 931 the default short refresh interval. 933 - If node protection is requested for the LSP and the NNhop node 934 along the LSP path does not support the RI-RSVP-FRR extensions, 935 then the node MUST reduce the "refresh period" in the TIME_VALUES 936 object carried in the Path messages to the default short refresh 937 interval. 939 If a node reduces the refresh time using the above procedures, it 940 MUST NOT send any "Remote" PathTear or Conditional PathTear message 941 to the downstream node. 943 Consider the example topology in Figure 1. If C does not support the 944 RI-RSVP-FRR extensions, then: 946 - A and B MUST reduce the refresh time to the default short refresh 947 interval of 30 seconds and trigger a Path message 949 - If B is not an MP and if Phop link of B fails, B cannot send 950 Conditional PathTear to C but MUST time out the PSB state from A 951 normally. Note that B can time out the PSB state A normally only 952 if A did not set long refresh in the TIME_VALUES object carried in 953 the Path messages sent earlier. 955 4.6.2.2. Lack of support on Upstream Node 957 The procedures are as follows. 959 - If a node finds that the Phop node along the LSP path does not 960 support the RI-RSVP-FRR extensions, then the node MUST reduce the 961 "refresh period" in the TIME_VALUES object carried in the Resv 962 messages to the default short refresh interval. 964 - If node protection is requested for the LSP and the Phop node 965 along the LSP path does not support the RI-RSVP-FRR extensions, 966 then the the node MUST reduce the "refresh period" in the 967 TIME_VALUES object carried in the Path messages to the default 968 short refresh interval (thus, the Nhop can use compatible values 969 when sending a Resv). 971 - If node protection is requested for the LSP and the PPhop node 972 does not support the RI-RSVP-FRR extensions, then the node MUST 973 reduce the "refresh period" in the TIME_VALUES object carried in 974 the Resv messages to the default short refresh interval. 976 - If the node reduces the refresh time using the above procedures, 977 it MUST NOT execute MP procedures specified in Section 4.3 of this 978 document. 980 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR 982 If a node supporting facility backup protection [RFC4090] sets the 983 RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR 984 extensions, then it leaves room for stale state to linger around for 985 an inordinate period of time or disruption of normal FRR operation. 986 Consider the example topology Figure 1 provided in this document. 988 - Assume node B does set RI-RSVP capability in its Node-ID based 989 Hello messages even though it does not support RI-RSVP-FRR 990 extensions. When B detects the failure of its Phop link along an 991 LSP, it will not send Conditional PathTear to C as required by the 992 RI-RSVP-FRR procedures. If B simply leaves the LSP state without 993 deleting, then B may end up holding on to the stale state until 994 the (long) refresh timeout. 996 - Intead of node B, assume node C does set RI-RSVP capability in its 997 Node-id based Hello messages even though it does not support RI- 998 RSVP-FRR extensions. When B details the failure of its Phop link 999 along an LSP, it will send Conditional PathTear to C as required 1000 by the RI-RSVP-FRR procedures. But, C would not recognize the 1001 condition encoded in the PathTear and end up tearing down the LSP. 1003 - Assume node B does set RI-RSVP capability in its Node-ID based 1004 Hello messages even though it does not support RI-RSVP-FRR 1005 extensions. Also assume local repair is about to commence on node 1006 B for an LSP that has only requested link protection. That is, B 1007 has not initiated the backup LSP signaling for the LSP. If node B 1008 receives a normal PathTear at this time from ingress A because of 1009 a management event initiated on A, then B simply deletes the LSP 1010 state without sending a Remote PathTear to the LP-MP C. So, C may 1011 end up holding on to the stale state until the (long) refresh 1012 timeout. 1014 4.6.2.4. Incremental Deployment 1016 The backward compatibility procedures described in the previous sub- 1017 sections imply that a router supporting the RI-RSVP-FRR extensions 1018 specified in this document can apply the procedures specified in the 1019 document either in the downstream or upstream direction of an LSP, 1020 depending on the capability of the routers downstream or upstream in 1021 the LSP path. 1023 - RI-RSVP-FRR extensions and procedures are enabled for downstream 1024 Path, PathTear and ResvErr messages corresponding to an LSP if 1025 link protection is requested for the LSP and the Nhop node 1026 supports the extensions 1028 - RI-RSVP-FRR extensions and procedures are enabled for downstream 1029 Path, PathTear and ResvErr messages corresponding to an LSP if 1030 node protection is requested for the LSP and both Nhop & NNhop 1031 nodes support the extensions 1033 - RI-RSVP-FRR extensions and procedures are enabled for upstream 1034 PathErr, Resv and ResvTear messages corresponding to an LSP if 1035 link protection is requested for the LSP and the Phop node 1036 supports the extensions 1038 - RI-RSVP-FRR extensions and procedures are enabled for upstream 1039 PathErr, Resv and ResvTear messages corresponding to an LSP if 1040 node protection is requested for the LSP and both Phop and the 1041 PPhop support the extensions 1043 For example, if an implementation supporting the RI-RSVP-FRR 1044 extensions specified in this document is deployed on all routers in 1045 particular region of the network and if all the LSPs in the network 1046 request node protection, then the FRR extensions will only be applied 1047 for the LSP segments that traverse the particular region. This will 1048 aid incremental deployment of these extensions and also allow reaping 1049 the benefits of the extensions in portions of the network where it is 1050 supported. 1052 5. Security Considerations 1054 The security considerations pertaining to [RFC2961], [RFC4090], 1055 [RFC8370], [RFC8796] and [RFC5920] remain relevant. When using RSVP 1056 Cryptographic Authentication [RFC2747], more robust algorithms 1057 [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed 1058 message digest where possible. 1060 This document extends the applicability of Node-ID based Hello 1061 session between immediate neighbors. The Node-ID based Hello session 1062 between the PLR and the NP-MP may require the two routers to exchange 1063 Hello messages with non-immediate neighbor. So, the implementations 1064 SHOULD provide the option to configure Node-ID neighbor specific or 1065 global authentication key to authentication messages received from 1066 Node-ID neighbors. The network administrator SHOULD utilize this 1067 option to enable RSVP-TE routers to authenticate Node-ID Hello 1068 messages received with TTL greater than 1. Implementations SHOULD 1069 also provide the option to specify a limit on the number of Node-ID 1070 based Hello sessions that can be established on a router supporting 1071 the extensions defined in this document. 1073 6. IANA Considerations 1075 6.1. New Object - CONDITIONS 1077 RSVP Change Guidelines [RFC3936] defines the Class-Number name space 1078 for RSVP objects. The name space is managed by IANA. 1080 IANA registry: RSVP Parameters 1081 Subsection: Class Names, Class Numbers, and Class Types 1083 A new RSVP object using a Class-Number from 128-183 range called the 1084 "CONDITIONS" object is defined in Section 4.4 of this document. The 1085 Class-Number from 128-183 range will be allocated by IANA. 1087 6.2. CONDITIONS Flags 1089 Apart from allocating Class-Number for the CONDITIONS object, the 1090 allocation of the Merge-point condition bit or M-bit Section 4.4 will 1091 also be done by IANA. 1093 Flag: 0x1 Name: Merge-point condition bit or M-bit 1095 7. Acknowledgements 1097 We are very grateful to Yakov Rekhter for his contributions to the 1098 development of the idea and thorough review of content of the draft. 1099 We are thankful to Raveendra Torvi and Yimin Shen for their comments 1100 and inputs on early versions of the draft. We also thank Alexander 1101 Okonnikov for his review and comments on the draft. 1103 8. Contributors 1105 Markus Jork 1106 Juniper Networks, Inc. 1107 Email: mjork@juniper.net 1109 Harish Sitaraman 1110 Individual Contributor 1111 Email: harish.ietf@gmail.com 1113 Vishnu Pavan Beeram 1114 Juniper Networks, Inc. 1115 Email: vbeeram@juniper.net 1117 Ebben Aries 1118 Arrcus, Inc. 1119 Email: exa@arrcus.com 1121 Mike Taillon 1122 Cisco Systems, Inc. 1123 Email: mtaillon@cisco.com 1125 9. References 1127 9.1. Normative References 1129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1130 Requirement Levels", BCP 14, RFC 2119, 1131 DOI 10.17487/RFC2119, March 1997, 1132 . 1134 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1135 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1136 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1137 September 1997, . 1139 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1140 Authentication", RFC 2747, DOI 10.17487/RFC2747, January 1141 2000, . 1143 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1144 and S. Molendini, "RSVP Refresh Overhead Reduction 1145 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 1146 . 1148 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1149 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1150 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1151 . 1153 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1154 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1155 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1156 DOI 10.17487/RFC3473, January 2003, 1157 . 1159 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 1160 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 1161 DOI 10.17487/RFC3936, October 2004, 1162 . 1164 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1165 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1166 DOI 10.17487/RFC4090, May 2005, 1167 . 1169 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 1170 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 1171 A Clarification Statement", RFC 4558, 1172 DOI 10.17487/RFC4558, June 2006, 1173 . 1175 [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to 1176 GMPLS Resource Reservation Protocol (RSVP) Graceful 1177 Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, 1178 . 1180 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 1181 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 1182 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 1183 . 1185 [RFC8796] Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A., 1186 Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute 1187 Extensions for Label Switched Path (LSP) Tunnels", 1188 RFC 8796, DOI 10.17487/RFC8796, July 2020, 1189 . 1191 9.2. Informative References 1193 [FIPS-180-3] 1194 National Institute of Standards and Technology, "Secure 1195 Hash Standard", FIPS 180-3, October 2008. 1197 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1198 Hashing for Message Authentication", RFC 2104, 1199 DOI 10.17487/RFC2104, February 1997, 1200 . 1202 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1203 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1204 . 1206 Authors' Addresses 1208 Chandra Ramachandran 1209 Juniper Networks, Inc. 1211 Email: csekar@juniper.net 1213 Tarek Saad 1214 Juniper Networks, Inc. 1216 Email: tsaad@juniper.net 1218 Ina Minei 1219 Google, Inc. 1221 Email: inaminei@google.com 1222 Dante Pacella 1223 Verizon, Inc. 1225 Email: dante.j.pacella@verizon.com