idnits 2.17.1 draft-mtaillon-mpls-summary-frr-rsvpte-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 13, 2016) is 2960 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: 1 error (**), 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 T. Saad 4 Intended status: Standards Track Cisco Systems Inc 5 Expires: September 14, 2016 N. Tan 6 Arista Networks 7 A. Deshmukh 8 M. Jork 9 V. Beeram 10 Juniper Networks 11 March 13, 2016 13 RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels 14 draft-mtaillon-mpls-summary-frr-rsvpte-03 16 Abstract 18 This document defines RSVP-TE signaling extensions that reduce the 19 amount of RSVP signaling required for Fast Reroute (FRR) procedures 20 and subsequently improve the scalability of the RSVP-TE signaling 21 when undergoing FRR convergence post a link or node failure. Such 22 extensions allow the RSVP message exchange between the Point of Local 23 Repair (PLR) and the Merge Point (MP) to be independent of the number 24 of protected LSPs traversing between them (eg. when bypass LSP FRR 25 protection is used). The new signaling extensions are fully 26 backwards compatible with nodes that do not support them. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 14, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Summary FRR Signaling Procedures . . . . . . . . . . . . . . 3 65 2.1. Signaling Procedures Prior to Failure . . . . . . . . . . 4 66 2.1.1. SUMMARY_FRR_BYPASS_ASSIGNMENT subobject . . . . . . . 4 67 2.1.2. PLR Summary FRR Signaling Procedure . . . . . . . . . 8 68 2.1.3. MP Summary FRR Signaling Procedure . . . . . . . . . 8 69 2.2. Signaling Procedures Post Failure . . . . . . . . . . . . 9 70 2.2.1. SUMMARY_FRR_BYPASS_ACTIVE object . . . . . . . . . . 9 71 2.2.2. PLR Summary FRR Signaling Procedure . . . . . . . . . 10 72 2.2.3. MP Summary FRR Signaling Procedure . . . . . . . . . 11 73 2.3. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 11 74 3. Compatibilty . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 6. Normative References . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 FRR procedures defined in [RFC4090] describe the mechanisms for the 83 PLR to reroute traffic and signaling of a protected RSVP-TE LSP onto 84 the bypass tunnel in the event of a TE link or node failure. Such 85 signaling procedures are performed individually for each affected 86 protected LSP. This may eventually lead to control plane scalability 87 and latency issues under limited (memory and processing) resources 88 after failure that affects a large number of protected LSPs 89 traversing the same PLR and MP. 91 In a large RSVP-TE LSPs scale deployment, a single P node acting as a 92 PLR may host tens of thousands of protected RSVP-TE LSPs egressing 93 the same link, and likewise, act as a Merge Point (MP) for similar 94 number of LSPs ingressing the same link. In the event of the failure 95 of the link or neighbor node, the RSVP-TE control plane of the node 96 acting as PLR becomes busy rerouting protected LSPs signaling over 97 the bypass tunnel(s) in one direction. In addition, its control 98 plane acting as MP becomes busy merging RSVP states signaling 99 received over bypass tunnels in the opposite direction. At the same 100 time, the head-end PE nodes that are notified of the local repair at 101 downstream P nodes, will attempt to (re)converge affected RSVP-TE 102 LSPs onto newly computed paths - possibly traversing the same 103 previously affected P node(s). As a result, the RSVP-TE control 104 plane at the PLR and MP becomes overwhelmed by the amount of FRR 105 RSVP-TE processing overhead following the link or node failure, and 106 the competing other control plane protocol(s) (e.g. the IGP) that 107 undergo their convergence at the same time. 109 The extensions defined in this document enable an MP to become aware 110 of the PLR's bypass assignment and allow FRR procedures between PLR 111 and MP to be signaled and processed on groups of LSPs. Further, 112 MESSAGE_ID objects for the rerouted PATH and RESV states are 113 exchanged a-priori to the fault such that Summary Refresh procedures 114 defined in [RFC2961] can continue to be used to refresh the rerouted 115 state(s) after FRR has occurred. 117 1.1. Terminology 119 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 121 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 122 [RFC2119]. 124 2. Summary FRR Signaling Procedures 126 This document defines two new subobjects (IPv4 and IPv6 127 SUMMARY_FRR_BYPASS_ASSIGNMENT subobjects) in RSVP RECORD_ROUTE object 128 to coordinate bypass tunnel assignment between the PLR and MP. These 129 new subobjects are backward compatible with LSRs that do not 130 recognize them (see section 4.4.5 in [RFC3209]). The document also 131 defines a new RSVP SUMMARY_FRR_BYPASS_ACTIVE object that is sent 132 within an RSVP Path message to inform the MP that one or more groups 133 of protected LSPs that are being protected by the bypass tunnel are 134 being rerouted. 136 The PLR creates and manages Summary FRR LSP groups 137 (Bypass_Group_Identifiers) and shares them with the MP via signaling. 138 Protected LSPs sharing the same egress link and bypass assignment are 139 grouped together and are assigned the same group. The MP maintains 140 the PLR group assignments learned via signaling, and acknowledges the 141 group assignments via signaling. Once the PLR receives the 142 acknowledgment, FRR signaling can proceed as group based. 144 The SUMMARY_FRR_BYPASS_ASSIGNMENT RRO subobject is used to inform the 145 MP of the bypass tunnel being used by the PLR, the assigned Summary 146 FRR Bypass_Group_Identifier for the protected LSP, and the MESSAGE_ID 147 object that the PLR will use to refresh the protected LSP PATH state 148 post FRR trigger. When used within a RSVP Resv message, the 149 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject is used by the MP to 150 acknowledge the PLR's bypass tunnel assignment, and provide the 151 MESSAGE_ID object that the MP will use to refresh the protected LSP 152 RESV state post FRR trigger (and also indicates support for this 153 extension). 155 2.1. Signaling Procedures Prior to Failure 157 Before Summary FRR procedures can be used, a handshake MUST be 158 completed between the PLR and MP. This handshake is performed using 159 RECORD_ROUTE SUMMARY_FRR_BYPASS_ASSIGNMENT subobject within both the 160 RSVP Path and Resv messages. 162 2.1.1. SUMMARY_FRR_BYPASS_ASSIGNMENT subobject 164 The IPv4 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject has the following 165 format: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type | Length | Bypass_Tunnel_ID | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Bypass_Source_IPv4_Address | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Bypass_Destination_IPv4_Address | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Bypass_Group_Identifier | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Summary_FRR_MESSAGE_ID | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Type: 8 bits 183 (TBD-1) IPv4 Summary FRR Bypass Assignment 185 Length: 8 bits 187 The Length contains the total length of the subobject in 188 bytes, including the Type and Length fields. 190 Bypass_Tunnel_ID: 16 bits 192 The bypass tunnel identifier. 194 Bypass_Source_IPv4_Address: 32 bits 196 The bypass tunnel source IPV4 address. 198 Bypass_Destination_IPv4_Address: 32 bits 200 The bypass tunnel destination IPV4 address. 202 Bypass_Group_Identifier: 32 bits 204 The bypass tunnel group identifier. 206 Summary_FRR_MESSAGE_ID 208 A MESSAGE_ID object as defined by {{RFC2961}}. 210 The IPv6 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject has the following 211 format: 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type | Length | Bypass_Tunnel_ID | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 219 + + 220 | | 221 + Bypass_Source_IPv6_Address + 222 | | 223 + + 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 + + 228 | | 229 + Bypass_Destination_IPv6_Address + 230 | | 231 + + 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Bypass_Group_Identifier | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Summary_FRR_MESSAGE_ID | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Type: 8 bits 241 (TBD-2) IPv6 Summary FRR Bypass Assignment 243 Length: 8 bits 245 The Length contains the total length of the subobject in 246 bytes, including the Type and Length fields. 248 Bypass_Tunnel_ID: 16 bits 250 The bypass tunnel identifier. 252 Bypass_Source_IPv6_Address: 128 bits 254 The bypass tunnel source IPV4 address. 256 Bypass_Destination_IPv6_Address: 128 bits 258 The bypass tunnel destination IPV4 address. 260 Bypass_Group_Identifier: 32 bits 262 The bypass tunnel group identifier. 264 Summary_FRR_MESSAGE_ID 266 A MESSAGE_ID object as defined by {{RFC2961}}. 268 The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each 269 protected LSP. The same Bypass_Group_Identifier is used for the set 270 of protected LSPs that share the same bypass tunnel and traverse the 271 same egress link and are not already rerouted. The PLR also 272 generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and 273 Message_Identifier MUST be set according to [RFC2961]) that is used 274 by the PLR to later match the last sent subobject and eliminate 275 timing issues. 277 The PLR MUST generate a new Message_Identifier each time the 278 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject contents change; for example, 279 when PLR changes the bypass tunnel assignment. 281 The PLR notifies the MP of the bypass tunnel assignment via adding a 282 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject to the RSVP Path message 283 RECORD_ROUTE object for the protected LSP using procedure described 284 in section 2.2.1. 286 The MP acknowledges the PLR's assignment by signalling a 287 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject within the RSVP Resv messsage 288 RECORD_ROUTE object. With exception of the MESSAGE_ID object, all 289 other fields of the received SUMMARY_FRR_BYPASS_ASSIGNMENT subobject 290 are copied into the SUMMARY_FRR_BYPASS_ASSIGNMENT of the Resv 291 message. The MESSAGE_ID object is set according to [RFC2961] with 292 the Flags being clear. A new Message_Identifier MUST be used to 293 acknowledge an updated PLR assignment. 295 The PLR considers the protected LSP as Summary FRR capable only if 296 the SUMMARY_FRR_BYPASS_ASSIGNMENT subobjects within the sent RSVP 297 Path message RECORD_ROUTE and the received RSVP Resv message 298 RECORD_ROUTE match (with exception of the MESSAGE_ID object). If a 299 matching subobject does not exist, or is later absent in a subsequent 300 refresh, the PLR MUST consider the protected LSP as not Summary FRR 301 capable. 303 2.1.2. PLR Summary FRR Signaling Procedure 305 The SUMMARY_FRR_BYPASS_ASSIGNMENT subobject is added to the 306 RECORD_ROUTE object by each PLR in the RSVP Path message of the 307 protected LSP to record the bypass tunnel assignment. This subobject 308 is updated every time the PLR updates the bypass tunnel assignment 309 (which triggers an RSVP Path change message). Upon updating the 310 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject, the PLR MUST consider the 311 protected LSP as not Summary FRR capable until a new handshake has 312 completed. 314 The SUMMARY_FRR_BYPASS_ASSIGNMENT subobject is added in the 315 RECORD_ROUTE object prior to adding the node's IP address. An 316 implementation may choose to also add the interface IPv4/IPv6 address 317 sub-object after the node's IP address. A node MUST NOT add a 318 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject without also adding the 319 node's IPv4 or IPv6 subobject. 321 Upon receiving an RSVP Resv message with RECORD_ROUTE object, the PLR 322 checks if the expected SUMMARY_FRR_BYPASS_ASSIGNMENT subobject is 323 present. If present, the PLR determines if the MP has acknowledged 324 the current PLR assignment. 326 To be a valid acknowledgement, the received 327 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject within the Resv message MUST 328 match the latest SUMMARY_FRR_BYPASS_ASSIGNMENT subobject sent with 329 the Path message (with exception of the MESSAGE_ID) and the received 330 Message_Identifier MUST be different (to prevent race condition 331 during bypass assignment flip-flop). If the MP has acknowledged the 332 bypass assignment then the LSP is now ready for Summary FRR. 334 When forwarding an RSVP Resv message upstream, the PLR MAY remove 335 any/all SUMMARY_FRR_BYPASS_ASSIGNMENT subobjects with a matching 336 Bypass_Source_Address. 338 2.1.3. MP Summary FRR Signaling Procedure 340 Upon receiving an RSVP Path message with RECORD_ROUTE object, the MP 341 processes all (there may be multiple PLRs for a single MP) 342 SUMMARY_FRR_BYPASSS_ASSIGNMENT subobjects with a matching Bypass 343 Destination address. 345 The MP first ensures the existence of the bypass tunnel and that the 346 Bypass_Group_Identifier is not already active. That is, an LSP 347 cannot join a group that is already active. 349 The MP builds a mirrored Summary FRR Group database per PLR, which is 350 determined using the Bypass_Source_Address field. The MESSAGE_ID is 351 extracted and recorded for the protected LSP PATH state. To 352 acknowledge each PLR bypass assignment, a matching 353 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject is prepared as per 2.2. 354 Note, an MP may received more than a Path message with the 355 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject from different upstream PLRs. 356 In this case, the MP is expected to save all the received MESSAGE_IDs 357 from the different PLRs. Post failure, the MP determines and 358 activates the associated Sumamry Refresh ID to use once it receives 359 and processes the SUMMARY_FRR_BYPASS_ACTIVE from the PLR. 361 Each SUMMARY_FRR_BYPASS_ASSIGNMENT subobject is added in the 362 RECORD_ROUTE object prior to adding the node's IP address. An 363 implementation may choose to also add the interface IPv4/IPv6 address 364 sub-object after the node's IP address. A node MUST NOT add a 365 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject without also adding an IPv4 366 or IPv6 subobject. 368 When forwarding an RSVP Path message downstream, the MP MAY remove 369 any/all SUMMARY_FRR_BYPASS_ASSIGNMENT subobjects with a matching 370 Bypass_Destination_Address. 372 2.2. Signaling Procedures Post Failure 374 Upon detection of the fault (egress link or node failure) the PLR 375 first performs the object modification procedures described by 376 section 6.4.3 of [RFC4090] for all affected protected LSPs. For 377 Summary FRR LSPs assigned to the same bypass tunnel a common RSVP_HOP 378 and SENDER_TEMPLATE MUST be used. 380 The PLR MUST signal non-Summary FRR LSPs over the bypass tunnel 381 before signaling the Summary FRR LSPs. This is needed to allow for 382 the case when the PLR has recently changed a bypass assignment which 383 the MP may not have processed the change yet. 385 A new object SUMMARY_FRR_BYPASS_ACTIVE is defined and sent within the 386 RSVP Path message of the bypass tunnel for reroute signaling of 387 Summary FRR LSPs. 389 2.2.1. SUMMARY_FRR_BYPASS_ACTIVE object 391 The SUMMARY_FRR_BYPASS_ACTIVE object is sent within an RSVP Path 392 message to inform the MP (bypass tunnel destination) that one or more 393 groups of protected LSPs that are being protected by the bypass 394 tunnel are being rerouted. 396 The SUMMARY_FRR_BYPASS_ACTIVE object has the following format: 398 SUMMARY_FRR_BYPASS_ACTIVE Class = (TBD-3) (of the form 11bbbbbb) 400 Class = SUMMARY_FRR_BYPASS_ACTIVE Class, C_Type = (TBD-4) 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | RSVP_HOP_Object | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Bypass_Group_Identifier | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | : | 410 // : // 411 | : | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Bypass_Group_Identifier | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 RSVP_HOP_Object: Class 3, as defined by {{RFC2205}}] 418 Replacement HOP object to be applied to all LSPs associated 419 with each of the following Bypass_Group_Identifiers 421 Bypass_Group_Identifier: 32 bits 423 Bypass_Group_Identifier field from the RECORD_ROUTE object 424 SUMMARY_FRR_BYPASS_ASSIGNMENT subobject(s) corresponding to all 425 LSPs that the bypass headend (PLR) advertised this specific 426 Bypass_Group_Identifier for. One or more 427 Bypass_Group_Identifiers may be included. 429 2.2.2. PLR Summary FRR Signaling Procedure 431 Post a failure event, when using the Summary FRR path signalling 432 procedures, an individual RSVP Path message for each Summary FRR LSP 433 is not signaled. Instead, to reroute Summary FRR LSPs via the bypass 434 tunnel, the PLR adds the SUMMARY_FRR_BYPASS_ACTIVE object in the RSVP 435 Path message of the RSVP session of the bypass tunnel. 437 The RSVP_HOP_Object field of the SUMMARY_FRR_BYPASS_ACTIVE object is 438 set to the common RSVP_HOP that was used by the PLR in Section 2.2. 440 The previously received MESSAGE_ID from the MP is activated. As a 441 result, the MP may refresh the protected rerouted RESV state using 442 Summary Refresh procedures. 444 For each affected Summary FRR group, its group identifier is added to 445 the SUMMARY_FRR_BYPASS_ACTIVE object. 447 2.2.3. MP Summary FRR Signaling Procedure 449 Upon receiving an RSVP Path message with a SUMMARY_FRR_BYPASS_ACTIVE 450 object, the MP performs normal merging processing for each LSP 451 associated with each Bypass_Group_Identifier, as if it received 452 individual RSVP Path messages for each Summary FRR LSP. 454 For each Summary FRR LSP being merged, the MP first modifies the Path 455 state as follows: 457 1. The RSVP_HOP object is copied from the SUMMARY_FRR_BYPASS_ACTIVE 458 RSVP_HOP_Object field. 460 2. The SENDER_TEMPLATE object SrcAddress field is copied from the 461 bypass tunnel SENDER_TEMPLATE object. For the case where PLR is 462 also the headend, and SENDER_TEMPLATE SrcAddress of the protected 463 LSP and bypass tunnel are the same, the MP MUST use the modified 464 HOP Hop Address field instead. 466 3. The ERO object is modified as per section 6.4.4. of [RFC4090]. 467 Once the above modifications are completed, the MP then performs 468 the merge processing as per [RFC4090]. 470 4. The previously received MESSAGE_ID from the PLR is activated, 471 meaning that the PLR may now refresh the protected rerouted PATH 472 state using Summary Refresh procedures. 474 A failure during merge processing of any individual rerouted LSP MUST 475 result in an RSVP Path Error message and the LSP MUST NOT be removed 476 from the Bypass_Group - this is to cover the case where the RSVP Path 477 Error message doesn't reach the PLR and the RSVP Path Error message 478 may need to be resignaled. 480 An individual RSVP Resv message for each successfully merged Summary 481 FRR LSP is not signaled. The MP SHOULD immediately use Summary 482 Refresh to refresh the protected LSP RESV state. 484 2.3. Refreshing Summary FRR Active LSPs 486 Refreshing of Summary FRR active LSPs is performed using Summary 487 Refresh as defined by [RFC2961]. 489 3. Compatibilty 491 The new SUMMARY_FRR_BYPASS_ACTIVE object is to be defined with a 492 class number in the form 11bbbbbb, which ensures compatibility with 493 non- supporting nodes. Per [RFC2205], nodes not supporting this 494 extension will ignore the object but forward it, unexamined and 495 unmodified, in all messages. 497 The new SUMMARY_FRR_BYPASS_ASSIGNMENT RECORD_ROUTE subobject, as per 498 section 4.4.5. of [RFC3209], if not recognized SHOULD be ignored and 499 forwarded. 501 4. Security Considerations 503 This document introduces new RSVP subobjects, and one new RSVP 504 object. Thus in the event of the interception of a signaling 505 message, slightly more could be deduced about the state of the 506 network than was previously the case. 508 5. IANA Considerations 510 IANA is requested to administer assignment of new values for the 511 namespace defined in this document and summarized in this section. 512 IANA maintains and assigns the values for RSVP-TE protocol parameters 513 "Resource Reservation Protocol (RSVP) Parameters" (see 514 http://www.iana.org/assignments/rsvp-parameters). 516 From the registries in this namespace for "Route Record" types, IANA 517 is requested to allocate two new RECORD_ROUTE object sub-types (IPv4 518 and IPv6) for the new SUMMARY_FRR_BYPASS_ASSIGNMENT subobjects. 520 From the same registry, a new RSVP Class and C-type (of the form 521 11bbbbbb) is requested for the new SUMMARY_FRR_BYPASS_ACTIVE object 522 defined in this document. 524 6. Normative References 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 528 RFC2119, March 1997, 529 . 531 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 532 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 533 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 534 September 1997, . 536 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 537 and S. Molendini, "RSVP Refresh Overhead Reduction 538 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 539 . 541 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 542 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 543 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 544 . 546 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 547 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 548 DOI 10.17487/RFC4090, May 2005, 549 . 551 Authors' Addresses 553 Mike Taillon 554 Cisco Systems Inc 556 Email: mtaillon@cisco.com 558 Tarek Saad 559 Cisco Systems Inc 561 Email: tsaad@cisco.com 563 Nicholas Tan 564 Arista Networks 566 Email: ntan@arista.com 568 Abhishek Deshmukh 569 Juniper Networks 571 Email: adeshmukh@juniper.net 573 Markus Jork 574 Juniper Networks 576 Email: mjork@juniper.net 578 Vishnu Pavan Beeram 579 Juniper Networks 581 Email: vbeeram@juniper.net