idnits 2.17.1 draft-ietf-mpls-summary-frr-rsvpte-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 11, 2019) is 1597 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 (~~), 2 warnings (==), 1 comment (--). 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: RFC4090 (if approved) T. Saad, Ed. 5 Intended status: Standards Track Juniper Networks 6 Expires: June 13, 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 December 11, 2019 16 RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels 17 draft-ietf-mpls-summary-frr-rsvpte-07 19 Abstract 21 This document updates the Resource Reservation Protocol (RSVP) 22 Traffic-Engineering (TE) procedures that are defined in RFC 4090 for 23 facility backup protection. The updates include extensions that 24 reduce the amount of signaling and processing that occurs during Fast 25 Reroute (FRR), and subsequently, improves scalability when undergoing 26 FRR convergence after a link or node failure. These extensions allow 27 the RSVP message exchange between the Point of Local Repair (PLR) and 28 the Merge Point (MP) 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 June 13, 2020. 50 Copyright Notice 52 Copyright (c) 2019 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 . . . . . . . . . . . . 4 72 3.1. B-SFRR-Ready Extended ASSOCIATION Object . . . . . . . . 6 73 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID . . . 6 74 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID . . . 7 75 3.2. B-SFRR-Active Extended ASSOCIATION Object . . . . . . . . 10 76 3.2.1. IPv4 B-SFRR-Active Extended ASSOCIATION ID . . . . . 11 77 3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID . . . . . 12 78 3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 13 79 3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 14 80 3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 14 81 3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 15 82 3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 15 83 3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 16 84 3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 17 85 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 89 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 92 9.2. Informative References . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 The Fast Reroute (FRR) procedures defined in [RFC4090] describe the 98 mechanisms for the Point of Local Repair (PLR) to reroute traffic and 99 signaling of a protected RSVP-TE LSP onto the bypass tunnel in the 100 event of a TE link or node failure. Such signaling procedures are 101 performed individually for each affected protected LSP. This may 102 eventually lead to control plane scalability and latency issues on 103 the PLR and/or the MP due to limited memory and CPU processing 104 resources. This condition is exacerbated when the failure affects 105 large number of protected LSPs that traverse the same PLR and Merge 106 Point (MP) nodes. 108 For example, in a large scale RSVP-TE LSPs deployment, a single LSR 109 acting as a PLR node may host tens of thousands of protected RSVP-TE 110 LSPs egressing the same link, and also act as a MP node for similar 111 number of LSPs that ingress on the same link. In the event of the 112 failure of the link or neighbor node, the RSVP-TE control plane of 113 the node when acting as PLR becomes busy rerouting protected LSPs 114 signaling over the bypass tunnel(s) in one direction, and when acting 115 as an MP node becomes busy merging RSVP states from signaling 116 received over bypass tunnels for LSP(s) in the reverse direction. 117 Subsequently, the head-end LER(s) that are notified of the local 118 repair at downstream LSR will attempt to (re)converge the affected 119 RSVP-TE LSPs onto newly computed paths - possibly traversing the same 120 previously affected LSR(s). As a result, the RSVP-TE control plane 121 at the PLR and MP becomes overwhelmed by the amount of FRR RSVP-TE 122 processing overhead following the link or node failure, and due to 123 other control plane protocol(s) (e.g. the IGP) that undergo 124 convergence on the same node at the same time too. 126 The extensions defined in this document update the procedures defined 127 in [RFC4090] for facility backup protection to enable a MP node to 128 become aware of the PLR node's bypass tunnel assignment group and 129 allow the FRR procedures between PLR node and MP node to be signaled 130 and processed on groups of protected LSPs. 132 As defined in [RFC2961], Summary Refresh procedures use MESSAGE_ID to 133 refresh the RSVP Path and Resv states to help with the scale. The 134 extensions defined in this document allow the MESSAGE_ID information 135 for the rerouted Path and Resv states to be exchanged between PLR and 136 MP nodes a priori to the fault such that Summary Refresh procedures 137 can continue to be used to refresh the rerouted state(s) after FRR 138 has occurred. 140 2. Conventions Used in This Document 142 2.1. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 2.2. Acronyms and Abbreviations 152 The reader is assumed to be familiar with terms and abbreviations 153 used in [RFC3209] and [RFC4090]. 155 The following abbreviations are also used in this document: 157 LSR: Label Switching Router 159 LER: Label Edge Router 161 MPLS: Multiprotocol Label Switching 163 LSP: Label Switched Path 165 MP: Merge Point node as defined in [RFC4090] 167 PLR: Point of Local Repair node as defined in [RFC4090] 169 FRR: Fast Reroute as defined in [RFC4090] 171 B-SFRR-Ready: Bypass Summary FRR Ready Extended ASSOCIATION 172 object. Added by the PLR for each LSP protected by the bypass 173 tunnel. 175 B-SFRR-Active: Bypass Summary FRR Active Extended ASSOCIATION 176 object. Used to notify the MP node of one ore more groups of 177 protected LSP(s) that are being protected by the specified bypass 178 tunnel are being rerouted. 180 3. Extensions for Summary FRR Signaling 182 The RSVP ASSOCIATION object is defined in [RFC4872] as a means to 183 associate LSPs with each other. For example, in the context of 184 GMPLS-controlled LSP(s), the object is used to associate recovery 185 LSPs with the LSP they are protecting. The Extended ASSOCIATION 186 object is introduced in [RFC6780] to expand on the possible usage of 187 the ASSOCIATION object and generalize the definition of the Extended 188 Association ID field. 190 This document defines the use of the Extended ASSOCIATION object to 191 carry the Summary FRR information and associate the protected LSP(s) 192 with the bypass tunnel that protects them. Two new Association Types 193 for the Extended ASSOCIATION object, and new Extended Association IDs 194 are proposed in this draft to describe the Bypass Summary FRR Ready 195 (B-SFRR-Ready) and the Bypass Summary FRR Active (B-SFRR-Active) 196 associations. 198 The PLR creates and manages the Summary FRR LSP groups (identified by 199 Bypass_Group_Identifiers) and shares the group identifier(s) with the 200 MP via signaling. 202 The PLR SHOULD assign the same Bypass_Group_Identifier to all 203 protected LSPs that share the egress link, and bypass tunnel as long 204 as the protected LSP(s) have the common group attributes, including 205 the modified tunnel sender address used for backup path 206 identification as described in [RFC4090]. 208 The MP maintains the PLR group assignments learned via signaling, and 209 acknowledges the group assignments via signaling. Once the PLR 210 receives the acknowledgment, FRR signaling can proceed as group 211 based. 213 The PLR node that supports Summary FRR procedures adds the Extended 214 ASSOCIATION object with Type B-SFRR-Ready and respective Extended 215 Association ID in the RSVP Path message of the protected LSP to 216 inform the MP of the PLR's assigned bypass tunnel, Summary FRR 217 Bypass_Group_Identifier, and the MESSAGE_ID that the PLR will use to 218 refresh the protected LSP Path state after FRR occurs. 220 The MP node that supports Summary FRR procedures adds the B-SFRR- 221 Ready Extended ASSOCIATION object and respective Extended Association 222 ID in the RSVP Resv message of the protected LSP to acknowledge the 223 PLR's bypass tunnel assignment, and provide the MESSAGE_ID object 224 that the MP node will use to refresh the protected LSP Resv state 225 after FRR occurs. 227 This document also defines a new Association Type for the Extended 228 ASSOCIATION object and new Extended Association ID to describe the B- 229 SFRR-Active association. The B-SFRR-Active Extended ASSOCIATION 230 object and Extended Association ID are sent by PLR after activating 231 FRR procedures on the PLR. The B-SFRR-Active Extended ASSOCIATION 232 object and Extended Association ID are sent within the RSVP Path 233 message of the bypass tunnel to inform the MP node that one or more 234 groups of protected LSPs protected by the bypass tunnel are now being 235 rerouted over the bypass tunnel. 237 3.1. B-SFRR-Ready Extended ASSOCIATION Object 239 The Extended ASSOCIATION object is populated using the rules defined 240 below to associate a protected LSP with the bypass tunnel that is 241 protecting it when Summary FRR procedures are enabled. 243 The Association Type, Association ID, and Association Source MUST be 244 set as defined in [RFC4872] for the ASSOCIATION Object. More 245 specifically: 247 Association Source: 249 The Association Source is set to an address of the PLR node. 251 Association Type: 253 A new Association Type is defined for B-SFRR-Ready as follows: 255 Value Type 256 ------- ------ 257 (TBD-1) Bypass Summary FRR Ready Association (B-SFRR-Ready) 259 Extended ASSOCIATION ID for B-SFRR-Ready: 261 The B-SFRR-Ready Extended ASSOCIATION ID is 262 populated by the PLR for the Bypass Summary FRR Ready association. 263 The rules to populate the Extended ASSOCIATION ID in this case are 264 described below. 266 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID 268 The IPv4 Extended ASSOCIATION ID for the B-SFRR-Ready association 269 type has the following format: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Bypass_Tunnel_ID | Reserved | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Bypass_Source_IPv4_Address | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Bypass_Destination_IPv4_Address | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Bypass_Group_Identifier | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | MESSAGE_ID | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 1: The IPv4 Extended ASSOCIATION ID for B-SFRR-Ready 287 Bypass_Tunnel_ID: 16 bits 289 The bypass tunnel identifier. 291 Reserved: 16 bits 293 Reserved for future use. 295 Bypass_Source_IPv4_Address: 32 bits 297 The bypass tunnel source IPV4 address. 299 Bypass_Destination_IPv4_Address: 32 bits 301 The bypass tunnel destination IPV4 address. 303 Bypass_Group_Identifier: 32 bits 305 The bypass tunnel group identifier. 307 MESSAGE_ID 309 A MESSAGE_ID object as defined by [RFC2961]. 311 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID 313 The IPv6 Extended ASSOCIATION ID field for the B-SFRR-Ready 314 association type has the following format: 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Bypass_Tunnel_ID | Reserved | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 + + 323 | | 324 + Bypass_Source_IPv6_Address + 325 | | 326 + + 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 + + 331 | | 332 + Bypass_Destination_IPv6_Address + 333 | | 334 + + 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Bypass_Group_Identifier | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | MESSAGE_ID | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 2: The IPv6 Extended ASSOCIATION ID for B-SFRR-Ready 344 Bypass_Tunnel_ID: 16 bits 346 The bypass tunnel identifier. 348 Reserved: 16 bits 350 Reserved for future use. 352 Bypass_Source_IPv6_Address: 128 bits 354 The bypass tunnel source IPV6 address. 356 Bypass_Destination_IPv6_Address: 128 bits 358 The bypass tunnel destination IPV6 address. 360 Bypass_Group_Identifier: 32 bits 362 The bypass tunnel group identifier. 364 MESSAGE_ID 366 A MESSAGE_ID object as defined by [RFC2961]. 368 The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each 369 protected LSP. The same Bypass_Group_Identifier is used for the set 370 of protected LSPs that share the same bypass tunnel, traverse the 371 same egress link, and are not already rerouted. The PLR also 372 generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and 373 Message_Identifier MUST be set according to [RFC2961]). 375 The PLR MUST generate a new Message_Identifier each time the contents 376 of the B-SFRR-Ready Extended ASSOCIATION ID changes (e.g. when PLR 377 node changes the bypass tunnel assignment). 379 The PLR node notifies the MP node of the bypass tunnel assignment via 380 adding a B-SFRR-Ready Extended ASSOCIATION object and Extended 381 Association ID in the RSVP Path message for the protected LSP using 382 procedures described in Section 3.4. 384 The MP node acknowledges the assignment to the PLR node by signaling 385 the B-SFRR-Ready Extended ASSOCIATION object and Extended Association 386 ID within the RSVP Resv message of the protected LSP. With exception 387 of the MESSAGE_ID objects, all other fields of the received in the B- 388 SFRR-Ready Extended ASSOCIATION ID in the RSVP Path message are 389 copied into the B-SFRR-Ready Extended ASSOCIATION ID to be added in 390 the Resv message. The MESSAGE_ID object is set according to 392 [RFC2961] with the Flags being clear. A new Message_Identifier MUST 393 be used to acknowledge an updated PLR assignment. 395 The PLR considers the protected LSP as Summary FRR capable only if 396 all the fields in the B-SFRR-Ready Extended ASSOCIATION ID that are 397 sent in the RSVP Path message and the ones received in the RSVP Resv 398 message (with exception of the MESSAGE_ID) match. If it does not 399 match, or if B-SFRR-Ready Extended ASSOCIATION object is absent in a 400 subsequent refresh, the PLR node MUST consider the protected LSP as 401 not Summary FRR capable. 403 3.2. B-SFRR-Active Extended ASSOCIATION Object 405 The Extended ASSOCIATION object for B-SFRR-Active association type is 406 populated by a PLR node to indicate to the MP node (bypass tunnel 407 destination) that one or more groups of Summary FRR protected LSPs 408 that are being protected by the bypass tunnel are being rerouted over 409 the bypass tunnel. 411 The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP 412 Path message of the bypass tunnel and signaled downstream towards the 413 MP (bypass tunnel destination). 415 The Association Type, Association ID, and Association Source MUST be 416 set as defined in [RFC4872] for the ASSOCIATION Object. More 417 specifically: 419 Association Source: 421 The Association Source is set to an address of the PLR node. 423 Association Type: 425 A new Association Type is defined for B-SFRR-Active as follows: 427 Value Type 428 ------- ------ 429 (TBD-2) Bypass Summary FRR Active Association (B-SFRR-Active) 431 Extended ASSOCIATION ID for B-SFRR-Active: 433 The B-SFRR-Active Extended ASSOCIATION ID is 434 populated by the PLR for the Bypass Summary FRR Active association. 435 The rules to populate the Extended ASSOCIATION ID in this case are 436 described below. 438 3.2.1. IPv4 B-SFRR-Active Extended ASSOCIATION ID 440 The IPv4 Extended ASSOCIATION ID for the B-SFRR-Active association 441 type is carried inside the IPv4 Extended ASSOCIATION object and has 442 the following format: 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Num-BGIDs | Reserved | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Bypass_Group_Identifier | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | : | 452 // : // 453 | : | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Bypass_Group_Identifier | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 // RSVP_HOP_Object // 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 // TIME_VALUES // 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | IPv4 tunnel sender address | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 3: The IPv4 Extended ASSOCIATION ID for B-SFRR-Active 466 Num-BGIDs: 16 bits 468 Number of Bypass_Group_Identifier fields. 470 Reserved: 16 bits 472 Reserved for future use. 474 Bypass_Group_Identifier: 32 bits 476 The Bypass_Group_Identifier that is previously signaled by the PLR 477 using the Extended Association object. One or more 478 Bypass_Group_Identifiers may be included. 480 RSVP_HOP_Object: Class 3, as defined by [RFC2205] 482 Replacement RSVP HOP object to be applied to all LSPs associated 483 with each of the following Bypass_Group_Identifiers. This 484 corresponds to C-Type = 1 for IPv4 RSVP HOP. 486 TIME_VALUES object: Class 5, as defined by [RFC2205] 488 Replacement TIME_VALUES object to be applied to all LSPs 489 associated with each of the following Bypass_Group_Identifiers 490 after receiving the B-SFRR-Active Extended ASSOCIATION Object. 492 IPv4 tunnel sender address: 494 The IPv4 address that the PLR sets to identify backup path(s) as 495 described in Section 6.1.1 of [RFC4090]. This address is 496 applicable to all groups identified by Bypass_Group_Identifier(s) 497 carried in the B-SFRR-Active Extended ASSOCIATION ID. 499 3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID 501 The IPv6 Extended ASSOCIATION ID for the B-SFRR-Active association 502 type is carried inside the IPv6 Extended ASSOCIATION object and has 503 the following format: 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Num-BGIDs | Reserved | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Bypass_Group_Identifier | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | : | 513 // : // 514 | : | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Bypass_Group_Identifier | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 // RSVP_HOP_Object // 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 // TIME_VALUES // 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | | 523 + + 524 | | 525 + IPv6 tunnel sender address + 526 | | 527 + + 528 | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Figure 4: The IPv6 Extended ASSOCIATION ID for B-SFRR-Active 533 Num-BGIDs: 16 bits 535 Number of Bypass_Group_Identifier fields. 537 Reserved: 16 bits 539 Reserved for future use. 541 Bypass_Group_Identifier: 32 bits 543 The Bypass_Group_Identifier that is previously signaled by the PLR 544 using the Extended Association object. One or more 545 Bypass_Group_Identifiers may be included. 547 RSVP_HOP_Object: Class 3, as defined by [RFC2205] 549 Replacement RSVP HOP object to be applied to all LSPs associated 550 with each of the following Bypass_Group_Identifiers. This 551 corresponds to C-Type = 2 for IPv6 RSVP HOP. 553 TIME_VALUES object: Class 5, as defined by [RFC2205] 555 Replacement TIME_VALUES object to be applied to all LSPs 556 associated with each of the following Bypass_Group_Identifiers 557 after receiving the B-SFRR-Active Extended ASSOCIATION Object. 559 IPv6 tunnel sender address: 561 The IPv6 address that the PLR sets to identify backup path(s) as 562 described in Section 6.1.1 of [RFC4090]. This address is 563 applicable to all groups identified by Bypass_Group_Identifier(s) 564 carried in the B-SFRR-Active Extended ASSOCIATION ID. 566 3.3. Signaling Procedures Prior to Failure 568 Before Summary FRR procedures can be used, a handshake MUST be 569 completed between the PLR and MP. This handshake is performed using 570 the Extended ASSOCIATION object that carries the B-SFRR-Ready 571 Extended Association ID in both the RSVP Path and Resv messages of 572 the protected LSP. 574 When using procedures defined in this document, the PLR MUST ensure 575 bypass tunnel assignment can satisfy the protected LSP MTU 576 requirements post FRR. This avoids any packets from being dropped 577 due to exceeding the MTU size of the bypass tunnel after traffic is 578 rerouted on the bypass tunnel post failure. 580 3.3.1. PLR Signaling Procedure 582 The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR in 583 the RSVP Path message of the protected LSP to record the bypass 584 tunnel assignment. This object is updated every time the PLR updates 585 the bypass tunnel assignment and that triggers an RSVP Path change 586 message. 588 Upon receiving an RSVP Resv message with B-SFRR-Ready Extended 589 ASSOCIATION object, the PLR node checks if the expected sub-objects 590 from the B-SFRR-Ready Extended ASSOCIATION ID are present. If 591 present, the PLR determines if the MP has acknowledged the current 592 PLR assignment. 594 To be a valid acknowledgement, the received B-SFRR-Ready Extended 595 ASSOCIATION ID contents within the RSVP Resv message of the protected 596 LSP MUST match the latest B-SFRR-Ready Extended ASSOCIATION object 597 and Association ID contents that the PLR node had sent within the 598 RSVP Path message (with exception of the MESSAGE_ID). 600 Note, when forwarding an RSVP Resv message upstream, the PLR node 601 SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose 602 Association Source matches the PLR node address. 604 3.3.2. MP Signaling Procedure 606 Upon receiving an RSVP Path message with a B-SFRR-Ready Extended 607 ASSOCIATION object, the MP node processes all (there may be multiple 608 PLRs for a single MP) B-SFRR-Ready Extended ASSOCIATION objects that 609 have the MP node address as Bypass Destination address in the 610 Extended Association ID. 612 The MP node first ensures the existence of the bypass tunnel and that 613 the Bypass_Group_Identifier is not already FRR active. That is, an 614 LSP cannot join a group that is already FRR rerouted. 616 The MP node builds a mirrored Summary FRR Group database per PLR, 617 which is determined using the Bypass_Source_Address field. The 618 MESSAGE_ID is extracted and recorded for the protected LSP Path 619 state. The MP node signals a B-SFRR-Ready Extended Association 620 object and Extended Association ID in the RSVP Resv message of the 621 protected LSP. With exception of the MESSAGE_ID objects, all other 622 fields of the received B-SFRR-Ready Extended ASSOCIATION object in 623 the RSVP Path message are copied into the B-SFRR-Ready Extended 624 ASSOCIATION object to be added in the Resv message. The MESSAGE_ID 625 object is set according to [RFC2961] with the Flags being clear. 627 Note, an MP may receive more than one RSVP Path message with the B- 628 SFRR-Ready Extended ASSOCIATION object from different upstream PLR 629 node(s). In this case, the MP node is expected to save all the 630 received MESSAGE_IDs from the different upstream PLR node(s). After 631 a failure, the MP node determines and activates the associated 632 Summary Refresh ID to use once it receives and processes the RSVP 633 Path message containing B-SFRR-Active Extended ASSOCIATION object 634 that is signaled over the bypass tunnel from the PLR, as described 635 Section 3.4 637 When forwarding an RSVP Path message downstream, the MP SHOULD remove 638 any/all B-SFRR-Ready Extended ASSOCIATION object(s) whose Association 639 ID contains Bypass_Destination_Address matching the MP node address. 641 3.4. Signaling Procedures Post Failure 643 Upon detection of the fault (egress link or node failure) the PLR 644 first performs the object modification procedures described by 645 Section 6.4.3 of [RFC4090] for all affected protected LSPs. For the 646 Summary FRR capable LSPs that are assigned to the same bypass tunnel 647 a common RSVP_HOP and SENDER_TEMPLATE MUST be used. 649 The PLR MUST signal non-Summary FRR capable LSPs over the bypass 650 tunnel before signaling the Summary FRR capable LSPs. This is needed 651 to allow for the case when the PLR node has recently changed a bypass 652 assignment and the MP has not processed the change yet. 654 The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP 655 Path message of the bypass tunnel to reroute RSVP state of Summary 656 FRR capable LSPs. 658 3.4.1. PLR Signaling Procedure 660 After a failure event, when using the Summary FRR path signaling 661 procedures, an individual RSVP Path message is not signaled for each 662 Summary FRR LSP. Instead, to reroute Summary FRR LSPs via the bypass 663 tunnel, the PLR adds the B-SFRR-Active Extended Association object in 664 the RSVP Path message of the RSVP session of the bypass tunnel. 666 The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION 667 ID is set to the common RSVP_HOP that was used by the PLR in 668 Section 3.4 of this document. 670 The previously received MESSAGE_ID from the MP is activated. As a 671 result, the MP may refresh the protected rerouted Resv state using 672 Summary Refresh procedures. 674 The PLR adds the Bypass_Group_Identifier(s) of group(s) that have 675 common group attributes, including the tunnel sender address, to the 676 same B-SFRR-Active Extended ASSOCIATION ID. Note that multiple 677 ASSOCIATION objects, each carrying a B-SFRR-Active Extended 678 ASSOCIATION ID, can be carried within a single RSVP Path message of 679 the bypass tunnel and sent towards the MP as described in [RFC6780]. 681 3.4.2. MP Signaling Procedure 683 Upon receiving an RSVP Path message with a B-SFRR-Active Extended 684 Association object, the MP performs normal merge point processing for 685 each protected LSP associated with each Bypass_Group_Identifier, as 686 if it received an individual RSVP Path messages for that LSP. 688 For each Summary FRR capable LSP that is being merged, the MP first 689 modifies the Path state as follows: 691 1. The RSVP_HOP object is copied from the B-SFRR-Active Extended 692 ASSOCIATION ID. 694 2. The TIME_VALUES object is copied from the TIMES_VALUE field in 695 the B-SFRR-Active Extended ASSOCIATION ID. The TIME_VALUES 696 object contains the refresh time of the PLR to generate refreshes 697 and that would have exchanged in a Path message sent to the MP 698 after the failure when no Summary FRR procedures are in effect. 700 3. The tunnel sender address field in the SENDER_TEMPLATE object is 701 copied from the tunnel sender address of the B-SFRR-Active 702 Extended ASSOCIATION ID. 704 4. The ERO object is modified as per Section 6.4.4 of [RFC4090]. 705 Once the above modifications are completed, the MP node performs 706 the merge processing as per [RFC4090]. 708 5. The previously received MESSAGE_ID from the PLR is activated, 709 meaning that the PLR may now refresh the protected rerouted Path 710 state using Summary Refresh procedures. 712 A failure during merge processing of any individual rerouted LSP MUST 713 result in an RSVP Path Error message. 715 An individual RSVP Resv message for each successfully merged Summary 716 FRR LSP is not signaled. The MP node SHOULD immediately use Summary 717 Refresh procedures to refresh the protected LSP Resv state. 719 3.5. Refreshing Summary FRR Active LSPs 721 Refreshing of Summary FRR active LSPs is performed using Summary 722 Refresh as defined by [RFC2961]. 724 4. Backwards Compatibility 726 The (Extended) ASSOCIATION object is defined in [RFC4872] with a 727 class number in the form 11bbbbbb, which ensures compatibility with 728 non-supporting node(s). Such nodes will ignore the object and 729 forward it without modification. 731 5. Security Considerations 733 This document updates an existing RSVP object. Thus, in the event of 734 the interception of a signaling message, slightly more information 735 could be deduced about the state of the network than was previously 736 the case. Existing mechanisms for maintaining the integrity and 737 authenticity of RSVP protocol messages [RFC2747] can be applied. 738 Other considerations mentioned in [RFC4090] and [RFC5920] also apply. 740 6. IANA Considerations 742 IANA maintains the "Generalized Multi-Protocol Label Switching 743 (GMPLS) Signaling Parameters" registry. The "Association Type" sub- 744 registry is included in this registry. 746 This registry has been updated by new Association Type for Extended 747 ASSOCIATION Object defined in this document as follows: 749 Value Name Reference 750 ----- ---- --------- 751 TBD-1 B-SFRR-Ready Association Section 3.1 752 TBD-2 B-SFRR-Active Association Section 3.2 754 7. Acknowledgments 756 The authors would like to thank Alexander Okonnikov, Loa Andersson, 757 Lou Berger, Eric Osborne, Gregory Mirsky, Mach Chen for reviewing and 758 providing valuable comments to this document. 760 8. Contributors 762 Nicholas Tan 763 Arista Networks 765 Email: ntan@arista.com 767 9. References 769 9.1. Normative References 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, 773 DOI 10.17487/RFC2119, March 1997, 774 . 776 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 777 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 778 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 779 September 1997, . 781 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 782 Authentication", RFC 2747, DOI 10.17487/RFC2747, January 783 2000, . 785 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 786 and S. Molendini, "RSVP Refresh Overhead Reduction 787 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 788 . 790 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 791 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 792 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 793 . 795 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 796 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 797 DOI 10.17487/RFC4090, May 2005, 798 . 800 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 801 Ed., "RSVP-TE Extensions in Support of End-to-End 802 Generalized Multi-Protocol Label Switching (GMPLS) 803 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 804 . 806 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 807 ASSOCIATION Object Extensions", RFC 6780, 808 DOI 10.17487/RFC6780, October 2012, 809 . 811 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 812 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 813 May 2017, . 815 9.2. Informative References 817 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 818 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 819 . 821 Authors' Addresses 823 Mike Taillon 824 Cisco Systems, Inc. 826 Email: mtaillon@cisco.com 828 Tarek Saad (editor) 829 Juniper Networks 831 Email: tsaad@juniper.net 833 Rakesh Gandhi 834 Cisco Systems, Inc. 836 Email: rgandhi@cisco.com 838 Abhishek Deshmukh 839 Juniper Networks 841 Email: adeshmukh@juniper.net 843 Markus Jork 844 128 Technology 846 Email: mjork@128technology.com 848 Vishnu Pavan Beeram 849 Juniper Networks 851 Email: vbeeram@juniper.net