idnits 2.17.00 (12 Aug 2021) /tmp/idnits57292/draft-ietf-mpls-summary-frr-rsvpte-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 (February 26, 2020) is 808 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 M. Taillon 3 Internet-Draft Cisco Systems, Inc. 4 Updates: 4090 (if approved) T. Saad, Ed. 5 Intended status: Standards Track Juniper Networks 6 Expires: August 29, 2020 R. Gandhi 7 Cisco Systems, Inc. 8 A. Deshmukh 9 Juniper Networks 10 M. Jork 11 128 Technology 12 V. Beeram 13 Juniper Networks 14 February 26, 2020 16 RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels 17 draft-ietf-mpls-summary-frr-rsvpte-09 19 Abstract 21 This document updates RFC 4090 for the Resource Reservation Protocol 22 (RSVP) Traffic-Engineering (TE) procedures defined for facility 23 backup protection. The updates include extensions that reduce the 24 amount of signaling and processing that occurs during Fast Reroute 25 (FRR), and subsequently, improves scalability when undergoing FRR 26 convergence after a link or node failure. These extensions allow the 27 RSVP message exchange between the Point of Local Repair (PLR) and the 28 Merge Point (MP) nodes to be independent of the number of protected 29 Label Switched Paths (LSPs) traversing between them when facility 30 bypass FRR protection is used. The signaling extensions are fully 31 backwards compatible with nodes that do not support them. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 29, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 69 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 71 3. Extensions for Summary FRR Signaling . . . . . . . . . . . . 5 72 3.1. B-SFRR-Ready Extended ASSOCIATION Object . . . . . . . . 6 73 3.1.1. IPv4 B-SFRR-Ready Extended ASSOCIATION ID . . . . . . 7 74 3.1.2. IPv6 B-SFRR-Ready Extended ASSOCIATION ID . . . . . . 8 75 3.1.3. Processing Rules for B-SFRR-Ready Extended 76 ASSOCIATION Object . . . . . . . . . . . . . . . . . 9 77 3.2. B-SFRR-Active Extended ASSOCIATION Object . . . . . . . . 10 78 3.2.1. IPv4 B-SFRR-Active Extended ASSOCIATION ID . . . . . 11 79 3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID . . . . . 12 80 3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 14 81 3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 15 82 3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 15 83 3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 16 84 3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 16 85 3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 17 86 3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 18 87 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 91 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 94 9.2. Informative References . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 97 1. Introduction 99 The Fast Reroute (FRR) procedures defined in [RFC4090] describe the 100 mechanisms for the Point of Local Repair (PLR) to reroute traffic and 101 signaling of a protected RSVP-TE Label Switched Path (LSP) onto the 102 bypass tunnel in the event of a TE link or node failure. Such 103 signaling procedures are performed individually for each affected 104 protected LSP. This may eventually lead to control plane scalability 105 and latency issues on the PLR and/or the Merge Point (MP) nodes due 106 to limited memory and CPU processing resources. This condition is 107 exacerbated when the failure affects a large number of protected LSPs 108 that traverse the same PLR and MP nodes. 110 For example, in a large-scale RSVP-TE LSPs deployment, a single Label 111 Switched Router (LSR) acting as a PLR node may host tens of thousands 112 of protected RSVP-TE LSPs egressing the same protected link, and also 113 act as an MP node for a similar number of LSPs that ingress on the 114 same link. In the event of the failure of the link or neighbor node, 115 the RSVP-TE control plane of the node (when acting as a PLR node) 116 becomes busy rerouting protected LSPs over the bypass tunnel(s) in 117 one direction, and (when acting as an MP node) becomes busy merging 118 RSVP states from signaling received over bypass tunnels for LSP(s) in 119 the reverse direction. Subsequently, the head-end Label Edge Routers 120 (LERs) that are notified of the local repair at downstream LSR will 121 attempt to (re)converge the affected RSVP-TE LSPs onto newly computed 122 paths - possibly traversing the same previously affected LSR(s). As 123 a result, the RSVP-TE control plane becomes overwhelmed by the amount 124 of FRR RSVP-TE processing overhead following the link or node 125 failure, and due to other control plane protocol(s) (e.g. the IGP) 126 that undergo convergence on the same node at the same time too. 128 Today, each protected RSVP-TE LSP is signaled individually over the 129 bypass tunnel after FRR. The changes introduced in this document 130 allow the PLR node to assign multiple protected LSPs to a bypass 131 tunnel group and to communicate this assignment to the MP, such that 132 upon failure, the signaling over the bypass tunnel happens on bypass 133 tunnel group(s). New extensions are defined in this document to 134 update the procedures defined in [RFC4090] for facility backup 135 protection to enable the MP node to become aware of the PLR node's 136 bypass tunnel assignment group(s) and to allow FRR procedures between 137 the PLR and the MP nodes to be signaled and processed on per bypass 138 tunnel group(s). 140 As defined in [RFC2961], Summary Refresh procedures use MESSAGE_ID to 141 refresh the RSVP Path and Resv states to help with scaling. The 142 Summary FRR procedures introduced in this document build on those 143 concepts to allow the MESSAGE_ID(s) to be exchanged on per bypass 144 tunnel assignment group, and continue use Summary Refresh procedures 145 while reducing the amount of messaging that occurs after rerouting 146 signaling over the bypass tunnel post FRR. 148 2. Conventions Used in This Document 150 2.1. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 2.2. Acronyms and Abbreviations 160 The reader is assumed to be familiar with terms and abbreviations 161 used in [RFC3209] and [RFC4090]. 163 The following abbreviations are also used in this document: 165 LSR: Label Switching Router 167 LER: Label Edge Router 169 MPLS: Multiprotocol Label Switching 171 LSP: Label Switched Path 173 MP: Merge Point node as defined in [RFC4090] 175 PLR: Point of Local Repair node as defined in [RFC4090] 177 FRR: Fast Reroute as defined in [RFC4090] 179 B-SFRR-Ready: Bypass Summary FRR Ready Extended ASSOCIATION 180 object. Added by the PLR node for each LSP protected by the 181 bypass tunnel. 183 B-SFRR-Active: Bypass Summary FRR Active Extended ASSOCIATION 184 object. Used to notify the MP node that one or more groups of 185 protected LSP(s) have been rerouted over the associated bypass 186 tunnel. 188 MTU: Maximum transmission unit. 190 3. Extensions for Summary FRR Signaling 192 The RSVP ASSOCIATION object is defined in [RFC4872] as a means to 193 associate LSPs with each other. For example, in the context of 194 GMPLS-controlled LSP(s), the ASSOCIATION object is used to associate 195 a recovery LSP with the LSP(s) it is protecting. The Extended 196 ASSOCIATION object is introduced in [RFC6780] to expand on the 197 possible usage of the ASSOCIATION object and generalize the 198 definition of the Extended Association ID field. 200 This document defines the use of the Extended ASSOCIATION object to 201 carry the Summary FRR information and associate the protected LSP(s) 202 with the bypass tunnel that protects them. Two new Association Types 203 for the Extended ASSOCIATION object, and new Extended Association IDs 204 are proposed in this document to describe the Bypass Summary FRR 205 Ready (B-SFRR-Ready) and the Bypass Summary FRR Active (B-SFRR- 206 Active) associations. 208 The PLR node creates and manages the Summary FRR LSP groups 209 (identified by Bypass_Group_Identifiers) and shares the group 210 identifier(s) with the MP via signaling. 212 A PLR node SHOULD assign the same Bypass_Group_Identifier to all 213 protected LSPs provided that the protected LSPs: 215 o share the same outgoing protected interface, 217 o are protected by the same bypass tunnel, and 219 o are assigned the same tunnel sender address that is used for 220 backup path identification after FRR as described in [RFC4090]. 222 This minimizes the number of bypass tunnel SFRR groups, and optimizes 223 the amount of signaling that occurs between the PLR and the MP nodes 224 after FRR. 226 A PLR node that supports Summary FRR procedures adds an Extended 227 ASSOCIATION object with B-SFRR-Ready Extended Association ID in the 228 RSVP Path message of the protected LSP. The PLR node adds the 229 protected LSP Bypass_Group_Identifier, information from the assigned 230 bypass tunnel, and MESSAGE_ID object into the B-SFRR-Ready Extended 231 Association ID. The MP uses the information contained in the 232 received B-SFRR-Ready Extended Association ID to refresh and merge 233 the protected LSP Path state after FRR occurs. 235 An MP node that supports Summary FRR procedures adds the B-SFRR-Ready 236 Extended ASSOCIATION object and respective Extended Association ID in 237 the RSVP Resv message of the protected LSP to acknowledge the PLR's 238 bypass tunnel assignment, and provide the MESSAGE_ID object that the 239 MP node will use to refresh the protected LSP Resv state after FRR 240 occurs. 242 The MP maintains the PLR node group assignments learned from 243 signaling, and acknowledges the group assignments to the PLR node via 244 signaling. Once the PLR node receives the group assignment 245 acknowledgment from the MP, the FRR signaling can proceed based on 246 Summary FRR procedures as described in this document. 248 The B-SFRR-Active Extended ASSOCIATION object with Extended 249 Association ID is sent by the PLR node after activating the Summary 250 FRR procedures. The B-SFRR-Active Extended ASSOCIATION object with 251 Extended Association ID is sent within the RSVP Path message of the 252 bypass tunnel to inform the MP node that one or more groups of 253 protected LSPs protected by the bypass tunnel are now being rerouted 254 over the bypass tunnel. 256 3.1. B-SFRR-Ready Extended ASSOCIATION Object 258 The Extended ASSOCIATION object is populated using the rules defined 259 below to associate a protected LSP with the bypass tunnel that is 260 protecting it when Summary FRR procedures are enabled. 262 The Association Type, Association ID, and Association Source MUST be 263 set as defined in [RFC4872] for the ASSOCIATION Object. More 264 specifically: 266 Association Source: 268 The Association Source is set to an address of the PLR node. 270 Association Type: 272 A new Association Type is defined for B-SFRR-Ready as follows: 274 Value Type 275 ------- ------ 276 (TBD-1) Bypass Summary FRR Ready Association (B-SFRR-Ready) 278 The Extended ASSOCIATION object's Global Association Source MUST be 279 set according to the rules defined in [RFC6780]. 281 The B-SFRR-Ready Extended ASSOCIATION ID is populated by the PLR node 282 when performing Bypass Summary FRR Ready association for a protected 283 LSP. The rules governing its population are described in the 284 subsequent sections. 286 3.1.1. IPv4 B-SFRR-Ready Extended ASSOCIATION ID 288 The IPv4 Extended ASSOCIATION ID for the B-SFRR-Ready association 289 type is carried inside the IPv4 Extended ASSOCIATION object and has 290 the following format: 292 0 1 2 3 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Bypass_Tunnel_ID | Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Bypass_Source_IPv4_Address | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Bypass_Destination_IPv4_Address | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Bypass_Group_Identifier | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | MESSAGE_ID | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 1: The IPv4 Extended ASSOCIATION ID for B-SFRR-Ready 308 Bypass_Tunnel_ID: 16 bits 310 The bypass tunnel identifier. 312 Reserved: 16 bits 314 Reserved for future use. MUST be set to zero when sending 315 and ignored on receipt. 317 Bypass_Source_IPv4_Address: 32 bits 319 The bypass tunnel source IPV4 address. 321 Bypass_Destination_IPv4_Address: 32 bits 323 The bypass tunnel destination IPV4 address. 325 Bypass_Group_Identifier: 32 bits 327 The bypass tunnel group identifier that is assigned to the 328 LSP. 330 MESSAGE_ID 332 A MESSAGE_ID object as defined by [RFC2961]. 334 3.1.2. IPv6 B-SFRR-Ready Extended ASSOCIATION ID 336 The IPv6 Extended ASSOCIATION ID for the B-SFRR-Ready association 337 type is carried inside the IPv6 Extended ASSOCIATION object and has 338 the following format: 340 0 1 2 3 341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Bypass_Tunnel_ID | Reserved | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 + + 347 | | 348 + Bypass_Source_IPv6_Address + 349 | | 350 + + 351 | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 + + 355 | | 356 + Bypass_Destination_IPv6_Address + 357 | | 358 + + 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Bypass_Group_Identifier | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | MESSAGE_ID | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 2: The IPv6 Extended ASSOCIATION ID for B-SFRR-Ready 368 Bypass_Tunnel_ID: 16 bits 370 The bypass tunnel identifier. 372 Reserved: 16 bits 374 Reserved for future use. MUST be set to zero when sending 375 and ignored on receipt. 377 Bypass_Source_IPv6_Address: 128 bits 379 The bypass tunnel source IPV6 address. 381 Bypass_Destination_IPv6_Address: 128 bits 383 The bypass tunnel destination IPV6 address. 385 Bypass_Group_Identifier: 32 bits 387 The bypass tunnel group identifier that is assigned to the 388 LSP. 390 MESSAGE_ID 392 A MESSAGE_ID object as defined by [RFC2961]. 394 3.1.3. Processing Rules for B-SFRR-Ready Extended ASSOCIATION Object 396 A PLR node assigns a bypass tunnel and Bypass_Group_Identifier for 397 each protected LSP. The same Bypass_Group_Identifier is used for the 398 set of protected LSPs that share the same bypass tunnel, traverse the 399 same egress link and are not already rerouted. The PLR node MUST 400 generate a MESSAGE_ID object with Epoch and Message_Identifier set 401 according to [RFC2961]. The MESSAGE_ID object flags MUST be cleared 402 when transmitted by the PLR node and ignored when received at the MP 403 node. 405 A PLR node MUST generate a new Message_Identifier each time the 406 contents of the B-SFRR-Ready Extended ASSOCIATION ID changes (e.g. 407 when the PLR node changes the bypass tunnel assignment). 409 A PLR node notifies the MP node of the bypass tunnel assignment via 410 adding a B-SFRR-Ready Extended ASSOCIATION object and Extended 411 Association ID in the RSVP Path message for the protected LSP using 412 procedures described in Section 3.3. 414 An MP node acknowledges the assignment to the PLR node by signaling 415 the B-SFRR-Ready Extended ASSOCIATION object and Extended Association 416 ID within the RSVP Resv message of the protected LSP. With the 417 exception of the MESSAGE_ID objects, all other fields of the received 418 in the B-SFRR-Ready Extended ASSOCIATION ID in the RSVP Path message 419 are copied into the B-SFRR-Ready Extended ASSOCIATION ID to be added 420 in the Resv message. The MESSAGE_ID object is set according to 421 [RFC2961]. The MESSAGE_ID object flags MUST be cleared when 422 transmitted by the MP node and ignored when received at the PLR node. 423 A new Message_Identifier MUST be used to acknowledge an updated PLR 424 node's assignment. 426 A PLR node considers the protected LSP as Summary FRR capable only if 427 all the fields in the B-SFRR-Ready Extended ASSOCIATION ID that are 428 sent in the RSVP Path message match the fields received in the RSVP 429 Resv message (with exception of the MESSAGE_ID). If the fields do 430 not match, or if B-SFRR-Ready Extended ASSOCIATION object is absent 431 in a subsequent refresh, the PLR node MUST consider the protected LSP 432 as not Summary FRR capable. 434 A race condition may arise for a previously Summary FRR capable 435 protected LSP when the MP node triggers a refresh that does not 436 contain the B-SFRR-Ready Extended ASSOCIATION object, while at the 437 same time, the PLR triggers Summary FRR procedures due to a fault 438 occurring concurrently. In this case, it is possible that the PLR 439 triggers Summary FRR procedurees on the protected LSP before it can 440 receive and process the refresh from the MP node. As a result, the 441 MP will receive a Srefresh with a Message_Identifier that is not 442 associated with any state. As per [RFC2961], this results in the MP 443 generating an Srefresh NACK for this Message_Identifier and sending 444 it back to the PLR. The PLR processes the Srefresh NACK and replays 445 the full Path state associated with the Message_Identifier, and 446 subsequently recovering from this condition. 448 3.2. B-SFRR-Active Extended ASSOCIATION Object 450 The Extended ASSOCIATION object for B-SFRR-Active association type is 451 populated by a PLR node to indicate to the MP node (bypass tunnel 452 destination) that one or more groups of Summary FRR protected LSPs 453 that are being protected by the bypass tunnel are being rerouted over 454 the bypass tunnel. 456 The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP 457 Path message of the bypass tunnel and signaled downstream towards the 458 MP (bypass tunnel destination). 460 The Association Type, Association ID, and Association Source MUST be 461 set as defined in [RFC4872] for the ASSOCIATION Object. More 462 specifically: 464 Association Source: 466 The Association Source is set to an address of the PLR node. 468 Association Type: 470 A new Association Type is defined for B-SFRR-Active as follows: 472 Value Type 473 ------- ------ 474 (TBD-2) Bypass Summary FRR Active Association (B-SFRR-Active) 476 Extended ASSOCIATION ID for B-SFRR-Active: 478 The B-SFRR-Active Extended ASSOCIATION ID is 479 populated by the PLR node for the Bypass Summary FRR Active 480 association. The rules to populate the Extended ASSOCIATION ID 481 in this case are described below. 483 3.2.1. IPv4 B-SFRR-Active Extended ASSOCIATION ID 485 The IPv4 Extended ASSOCIATION ID for the B-SFRR-Active association 486 type is carried inside the IPv4 Extended ASSOCIATION object and has 487 the following format: 489 0 1 2 3 490 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Num-BGIDs | Reserved | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Bypass_Group_Identifier | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | : | 497 // : // 498 | : | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Bypass_Group_Identifier | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 // RSVP_HOP_Object // 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 // TIME_VALUES // 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | IPv4 tunnel sender address | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Figure 3: The IPv4 Extended ASSOCIATION ID for B-SFRR-Active 511 Num-BGIDs: 16 bits 513 Number of Bypass_Group_Identifier fields. 515 Reserved: 16 bits 517 Reserved for future use. 519 Bypass_Group_Identifier: 32 bits each 521 A Bypass_Group_Identifier that was previously signaled by the PLR 522 using the Extended ASSOCIATION object in the B-SFRR-Ready Extended 523 Association ID. One or more Bypass_Group_Identifiers MAY be 524 included. 526 RSVP_HOP_Object: Class 3, as defined by [RFC2205] 528 Replacement RSVP HOP object to be applied to all LSPs associated 529 with each of the following Bypass_Group_Identifiers. This 530 corresponds to C-Type = 1 for IPv4 RSVP HOP. 532 TIME_VALUES object: Class 5, as defined by [RFC2205] 534 Replacement TIME_VALUES object to be applied to all LSPs 535 associated with each of the preceding Bypass_Group_Identifiers 536 after receiving the B-SFRR-Active Extended ASSOCIATION Object. 538 IPv4 tunnel sender address: 540 The IPv4 address that the PLR node sets to identify backup path(s) 541 as described in Section 6.1.1 of [RFC4090]. This address is 542 applicable to all groups identified by Bypass_Group_Identifier(s) 543 carried in the B-SFRR-Active Extended ASSOCIATION ID. 545 3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID 547 The IPv6 Extended ASSOCIATION ID for the B-SFRR-Active association 548 type is carried inside the IPv6 Extended ASSOCIATION object and has 549 the following format: 551 0 1 2 3 552 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Num-BGIDs | Reserved | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Bypass_Group_Identifier | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | : | 559 // : // 560 | : | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Bypass_Group_Identifier | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 // RSVP_HOP_Object // 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 // TIME_VALUES // 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | | 569 + + 570 | | 571 + IPv6 tunnel sender address + 572 | | 573 + + 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Figure 4: The IPv6 Extended ASSOCIATION ID for B-SFRR-Active 579 Num-BGIDs: 16 bits 581 Number of Bypass_Group_Identifier fields. 583 Reserved: 16 bits 585 Reserved for future use. 587 Bypass_Group_Identifier: 32 bits each 589 A Bypass_Group_Identifier that was previously signaled by the PLR 590 using the Extended ASSOCIATION object in the B-SFRR-Ready Extended 591 Association ID. One or more Bypass_Group_Identifiers MAY be 592 included. 594 RSVP_HOP_Object: Class 3, as defined by [RFC2205] 595 Replacement RSVP HOP object to be applied to all LSPs associated 596 with each of the following Bypass_Group_Identifiers. This 597 corresponds to C-Type = 2 for IPv6 RSVP HOP. 599 TIME_VALUES object: Class 5, as defined by [RFC2205] 601 Replacement TIME_VALUES object to be applied to all LSPs 602 associated with each of the following Bypass_Group_Identifiers 603 after receiving the B-SFRR-Active Extended ASSOCIATION Object. 605 IPv6 tunnel sender address: 607 The IPv6 address that the PLR node sets to identify backup path(s) 608 as described in Section 6.1.1 of [RFC4090]. This address is 609 applicable to all groups identified by Bypass_Group_Identifier(s) 610 carried in the B-SFRR-Active Extended ASSOCIATION ID. 612 3.3. Signaling Procedures Prior to Failure 614 Before Summary FRR procedures can be used, a handshake MUST be 615 completed between the PLR and MP nodes. This handshake is performed 616 using the Extended ASSOCIATION object that carries the B-SFRR-Ready 617 Extended Association ID in both the RSVP Path and Resv messages of 618 the protected LSP. 620 The facility backup method introduced in [RFC4090] takes advantage of 621 MPLS label stacking (PLR node imposing additional MPLS label post 622 FRR) to allow rerouting of protected traffic over the backup path. 623 The backup path may have stricter MTU requirement and due to label 624 stacking at PLR node, the protected traffic may exceed the backup 625 path MTU. The operator is assumed to engineer their network to allow 626 rerouting of protected traffic and the additional label stacking at 627 PLR node to not exceed the backup path MTU. 629 When using procedures defined in this document, the PLR node MUST 630 ensure the bypass tunnel assignment can satisfy the protected LSP MTU 631 requirements post FRR. This avoids any packets from being dropped 632 due to exceeding the MTU size of the backup path after traffic is 633 rerouted on to the bypass tunnel post the failure. Section 2.6 in 634 [RFC3209] describes a mechanism to determine whether a node needs to 635 fragment or drop a packet when it exceeds the Path MTU discovered 636 using RSVP signaling on primary LSP path. A PLR can leverage the 637 RSVP discovered Path MTU on the backup and primary LSP paths to 638 ensure MTU is not exceeded before or after rerouting the protected 639 traffic on to the bypass tunnel. 641 3.3.1. PLR Signaling Procedure 643 The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR 644 node in the RSVP Path message of the protected LSP to record the 645 bypass tunnel assignment. This object is updated every time the PLR 646 node updates the bypass tunnel assignment and that triggers an RSVP 647 Path change message. 649 Upon receiving an RSVP Resv message with B-SFRR-Ready Extended 650 ASSOCIATION object, the PLR node checks if the expected sub-objects 651 from the B-SFRR-Ready Extended ASSOCIATION ID are present. If 652 present, the PLR node determines if the MP has acknowledged the 653 current PLR node's assignment. 655 To be a valid acknowledgement, the received B-SFRR-Ready Extended 656 ASSOCIATION ID contents within the RSVP Resv message of the protected 657 LSP MUST match the latest B-SFRR-Ready Extended ASSOCIATION object 658 and Association ID contents that the PLR node had sent within the 659 RSVP Path message (with exception of the MESSAGE_ID). 661 Note, when forwarding an RSVP Resv message upstream, the PLR node 662 SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose 663 Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address field 664 matches any of the PLR node addresses. 666 3.3.2. MP Signaling Procedure 668 Upon receiving an RSVP Path message with a B-SFRR-Ready Extended 669 ASSOCIATION object, an MP node processes all (there may be multiple 670 PLR nodes for a single MP node) B-SFRR-Ready Extended ASSOCIATION 671 objects that have the MP node address as Bypass Destination address 672 in the Extended Association ID. 674 The MP node first ensures the existence of the bypass tunnel and that 675 the Bypass_Group_Identifier is not already FRR active. That is, an 676 LSP cannot join a group that is already FRR rerouted. 678 The MP node builds a mirrored Summary FRR Group database per PLR node 679 by associating the Bypass_Source_IPv4_Address or 680 Bypass_Source_IPv6_Address that is carried in the IPv4 or IPv6 B- 681 SFRR-Ready Extended ASSOCIATION IDs respectively. 683 The MESSAGE_ID is extracted and recorded for the protected LSP Path 684 state. The MP node signals a B-SFRR-Ready Extended Association 685 object and Extended Association ID in the RSVP Resv message of the 686 protected LSP. With the exception of the MESSAGE_ID objects, all 687 other fields of the received B-SFRR-Ready Extended ASSOCIATION object 688 in the RSVP Path message are copied into the B-SFRR-Ready Extended 689 ASSOCIATION object to be added in the Resv message. The MESSAGE_ID 690 object is set according to [RFC2961] with the Flags being clear. 692 Note, an MP may receive more than one RSVP Path message with the B- 693 SFRR-Ready Extended ASSOCIATION object from different upstream PLR 694 node(s). In this case, the MP node is expected to save all the 695 received MESSAGE_IDs received from the different upstream PLR 696 node(s). After a failure, the MP node determines and activates the 697 state(s) associated with the Bypass_Group_Identifier(s) received in 698 the RSVP Path message containing B-SFRR-Active Extended ASSOCIATION 699 object that is signaled over the bypass tunnel from the PLR node, as 700 described Section 3.4 702 When forwarding an RSVP Path message downstream, the MP node SHOULD 703 remove any/all B-SFRR-Ready Extended ASSOCIATION object(s) whose 704 Bypass_Destination_IPv4_Address or Bypass_Destination_IPv6_Address 705 field matches any of the MP node addresses. 707 3.4. Signaling Procedures Post Failure 709 Upon detection of a fault (egress link or node failure) the PLR node 710 will first perform the object modification procedures described by 711 Section 6.4.3 of [RFC4090] for all affected protected LSPs. For the 712 Summary FRR capable LSPs that are assigned to the same bypass tunnel 713 a common RSVP_HOP and SENDER_TEMPLATE MUST be used. 715 The PLR node MUST signal non-Summary FRR capable LSPs over the bypass 716 tunnel before signaling the Summary FRR capable LSPs. This is needed 717 to allow for the case where the PLR node recently changed a bypass 718 assignment and the MP has not processed the change yet. 720 The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP 721 Path message of the bypass tunnel to reroute RSVP state of Summary 722 FRR capable LSPs. 724 3.4.1. PLR Signaling Procedure 726 After a failure event, when using the Summary FRR path signaling 727 procedures, an individual RSVP Path message is not signaled for each 728 Summary FRR LSP. Instead, to reroute Summary FRR LSPs via the bypass 729 tunnel, the PLR node adds the B-SFRR-Active Extended Association 730 object in the RSVP Path message of the RSVP session of the bypass 731 tunnel. 733 The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION 734 ID is set to a common object that will be applied to all LSPs 735 associated with the Bypass_Group_Identifiers that are carried in the 736 B-SFRR-Active Extended ASSOCIATION ID. 738 The PLR node adds the Bypass_Group_Identifier(s) of group(s) that 739 have common group attributes, including the tunnel sender address, to 740 the same B-SFRR-Active Extended ASSOCIATION ID. Note that multiple 741 ASSOCIATION objects, each carrying a B-SFRR-Active Extended 742 ASSOCIATION ID, can be carried within a single RSVP Path message of 743 the bypass tunnel and sent towards the MP as described in [RFC6780]. 745 The previously received MESSAGE_ID(s) from the MP are activated on 746 the PLR. As a result, the PLR starts sending Srefresh messages 747 containing the specific Message_identifier(s) for the states to be 748 refreshed. 750 3.4.2. MP Signaling Procedure 752 Upon receiving an RSVP Path message with a B-SFRR-Active Extended 753 Association object, the MP performs normal merge point processing for 754 each protected LSP associated with each Bypass_Group_Identifier, as 755 if it had received an individual RSVP Path message for that LSP. 757 For each Summary FRR capable LSP that is being merged, the MP first 758 modifies the Path state as follows: 760 1. The RSVP_HOP object is copied from the RSVP_HOP_Object field in 761 the B-SFRR-Active Extended ASSOCIATION ID. 763 2. The TIME_VALUES object is copied from the TIME_VALUES field in 764 the B-SFRR-Active Extended ASSOCIATION ID. The TIME_VALUES 765 object contains the refresh time of the PLR node to generate 766 refreshes and that would have exchanged in a Path message sent to 767 the MP after the failure when no Summary FRR procedures are in 768 effect. 770 3. The tunnel sender address field in the SENDER_TEMPLATE object is 771 copied from the tunnel sender address field of the B-SFRR-Active 772 Extended ASSOCIATION ID. 774 4. The ERO object is modified as per Section 6.4.4 of [RFC4090]. 775 Once the above modifications are completed, the MP node performs 776 the merge processing as per [RFC4090]. 778 5. The previously received MESSAGE_ID(s) from the PLR node are 779 activated. The MP is allowed to send Srefresh messages 780 containing the specific Message_identifier(s) for the states to 781 be refreshed. 783 A failure during merge processing of any individual rerouted LSP MUST 784 result in an RSVP Path Error message. 786 An individual RSVP Resv message for each successfully merged Summary 787 FRR LSP is not signaled. The MP node SHOULD immediately use Summary 788 Refresh procedures to refresh the protected LSP Resv state. 790 3.5. Refreshing Summary FRR Active LSPs 792 Refreshing of Summary FRR active LSPs is performed using Summary 793 Refresh as defined by [RFC2961]. 795 4. Backwards Compatibility 797 The (Extended) ASSOCIATION object is defined in [RFC4872] with a 798 class number in the form 11bbbbbb, where b=0 or 1. This ensures 799 compatibility with non-supporting node(s) in accordance with the 800 procedures specified in [RFC2205], Section 3.10 for unknown-class 801 objects, Such nodes will ignore the object and forward it without any 802 modification. 804 5. Security Considerations 806 This document updates an existing RSVP object. Thus, in the event of 807 the interception of a signaling message, slightly more information 808 could be deduced about the state of the network than was previously 809 the case. 811 When using procedures defined in this document, FRR signaling for 812 rerouting of protected LSP(s) states on to the bypass tunnel can be 813 performed on a group of protected LSP(s) with a single RSVP message. 814 This allows an intruder to potentially impact and manipulate a set of 815 protected LSP that are assigned to the same bypass tunnel group. 816 Note that such attack is even possible without the mechanisms 817 proposed in this document; albeit, at an extra cost resulting from 818 the excessive per LSP signaling that will occur. 820 Existing mechanisms for maintaining the integrity and authenticity of 821 RSVP protocol messages [RFC2747] can be applied. Other 822 considerations mentioned in [RFC4090] and [RFC5920] also apply. 824 6. IANA Considerations 826 IANA maintains the "Generalized Multi-Protocol Label Switching 827 (GMPLS) Signaling Parameters" registry. The "Association Type" sub- 828 registry is included in this registry. 830 This registry has been updated by new Association Type for Extended 831 ASSOCIATION Object defined in this document as follows: 833 Value Name Reference 834 ----- ---- --------- 835 TBD-1 B-SFRR-Ready Association Section 3.1 836 TBD-2 B-SFRR-Active Association Section 3.2 838 7. Acknowledgments 840 The authors would like to thank Alexander Okonnikov, Loa Andersson, 841 Lou Berger, Eric Osborne, Gregory Mirsky, Mach Chen for reviewing and 842 providing valuable comments to this document. 844 8. Contributors 846 Nicholas Tan 847 Arista Networks 849 Email: ntan@arista.com 851 9. References 853 9.1. Normative References 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, 857 DOI 10.17487/RFC2119, March 1997, 858 . 860 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 861 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 862 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 863 September 1997, . 865 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 866 Authentication", RFC 2747, DOI 10.17487/RFC2747, January 867 2000, . 869 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 870 and S. Molendini, "RSVP Refresh Overhead Reduction 871 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 872 . 874 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 875 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 876 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 877 . 879 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 880 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 881 DOI 10.17487/RFC4090, May 2005, 882 . 884 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 885 Ed., "RSVP-TE Extensions in Support of End-to-End 886 Generalized Multi-Protocol Label Switching (GMPLS) 887 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 888 . 890 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 891 ASSOCIATION Object Extensions", RFC 6780, 892 DOI 10.17487/RFC6780, October 2012, 893 . 895 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 896 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 897 May 2017, . 899 9.2. Informative References 901 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 902 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 903 . 905 Authors' Addresses 907 Mike Taillon 908 Cisco Systems, Inc. 910 Email: mtaillon@cisco.com 912 Tarek Saad (editor) 913 Juniper Networks 915 Email: tsaad@juniper.net 917 Rakesh Gandhi 918 Cisco Systems, Inc. 920 Email: rgandhi@cisco.com 921 Abhishek Deshmukh 922 Juniper Networks 924 Email: adeshmukh@juniper.net 926 Markus Jork 927 128 Technology 929 Email: mjork@128technology.com 931 Vishnu Pavan Beeram 932 Juniper Networks 934 Email: vbeeram@juniper.net