idnits 2.17.1 draft-atlas-rsvp-local-protect-interop-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8191 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) == Missing Reference: 'R7' is mentioned on line 156, but not defined == Missing Reference: 'R8' is mentioned on line 156, but not defined == Unused Reference: 'RFC2119' is defined on line 448, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'FAST-REROUTE' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-recovery-frmwrk-03 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-recovery-frmwrk (ref. 'MPLS-RECOVERY') == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Alia Atlas (Avici Systems) 3 Expires: May 20002 Markus Jork (Avici Systems) 5 November 2001 7 MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute 9 draft-atlas-rsvp-local-protect-interop-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. Internet-Drafts are working documents of 15 the Internet Engineering Task Force (IETF), its areas, and its 16 working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 Our combined draft on fast-reroute, draft-ping-rsvp-fastreroute- 33 00.txt, leaves several areas with future work required. One of those 34 areas is the merging rules for detour LSPs. This draft describes 35 some of the issues with the merging rules presented in draft-ping- 36 rsvp-fastreroute-02.txt and proposes a solution which also enhances 37 interoperability. 39 The implementation of detour LSPs described in draft-ping-rsvp- 40 fastreroute-00.txt results in intermittent backup availability. A 41 detour LSP will become temporarily unavailable when other detours 42 with different EROs are merged into it; local protection will become 43 temporarily unavailable if re-optimization of a backup path is 44 implemented. 46 This draft describes examples of the above problems and proposes a 47 solution. The solution also resolves issues with merged backups 48 which do not provide adequate protection, due to the use of SRLGs. 49 The solution also finds backup paths in some topologies where a 50 detour LSP could not be found, in the merging rules in draft-ping- 51 rsvp-fastreroute-00.txt were followed. 53 Recommended behavior for supporting a revertive mode for local 54 protection is specified. 56 Contents 58 1. Introduction ............................................... 3 59 2. Backup Availability ........................................ 3 60 3. Backup Does Not Provide Protection ......................... 4 61 3.1 Selected ERO Merges at PLR ................................ 4 62 3.2 Selected ERO Uses SRLG .................................... 5 63 3.3 No Backup Path For Detour LSP ............................. 5 64 4. Solution to Problems with Merging Rules .................... 6 65 4.1 Detour Object Need Not be Understood ...................... 7 66 5. Make-Before-Break .......................................... 7 67 6. Revertive Behavior: Recovery from Failure .................. 9 68 6.1 Local Failure ............................................. 10 69 6.2 Remote Failure ............................................ 10 70 7. Security Considerations .................................... 10 71 8. Reference .................................................. 10 72 9. Authors' Addresses ......................................... 11 74 1. Introduction 76 Our combined draft on fast-reroute, draft-ping-rsvp-fastreroute- 77 00.txt, leaves several areas with future work required. One of those 78 areas is the merging rules for detour LSPs. This draft describes 79 some of the issues with the merging rules presented in draft-ping- 80 rsvp-fastreroute-02.txt and proposes a solution which also enhances 81 interoperability. 83 The implementation of detour LSPs described in [FAST-REROUTE] results 84 in intermittent backup availability. A detour LSP will become 85 temporarily unavailable when other detours with different EROs are 86 merged into it; local protection will become temporarily unavailable 87 if re-optimization of a backup path is implemented. 89 This draft describes examples of the above problems and proposes a 90 solution. The solution also resolves issues with merged backups 91 which do not provide adequate protection, due to the use of SRLGs. 92 The solution also finds backup paths in some topologies where a 93 detour LSP could not be found, in the merging rules in [FAST-REROUTE] 94 were followed. Finally, the solution allows make-before-break to work 95 on detour LSPs without causing the protection to become temporarily 96 unavailable. 98 Recommended behavior for supporting a revertive mode for local 99 protection is specified. 101 2. Backup Availability 103 In order for local protection to be useful in mission-critical 104 networks, it is important that local protection, once created at a 105 PLR for a given primary LSP, remains available at all times until a 106 single fault has occurred. That fault could be physical or due to 107 resource preemption and could occur on either the primary LSP or the 108 backup LSP. 110 The fault against which the backup protects could occur at any time, 111 including when the backup is temporarily unavailable. Similarly, at 112 any time, traffic could be running across a backup - if it becomes 113 temporarily unavailable then, traffic loss will result. 115 The following example demonstrates a case when following the merging 116 rules given in [FAST-REROUTE] result in the backup becoming 117 temporarily unavailable. In this example, the PLR of the backup 118 which is temporarily unavailable is not aware that the backup is not 119 functional during that period. 121 [R1]----[R2]----[R3]----[R4]--R5] 122 | \ / | / 123 [R6]-------[R8]----------[R9] 125 Primary: R1-R2-R3-R4-R5 126 R2 backup: R2-R8-R9-R4 127 R3 backup: R3-R8-R9-R5 129 Figure 1: New Detour Causes Existing Detour to Fail 131 Assume that due to setup timing, R2's backup is created first. Then 132 when the detour from R3 tries to be created, R8 must merge the two 133 detours together. According to the merging rules in [FAST-REROUTE], 134 R8 must select the ERO to R3's backup. When R8 does so, there is a 135 period when the backup from R2 was "up" but isn't actually available 136 unless R8 and R9 deal with changing the ERO in a make-before-break 137 fashion. 139 The same problem will occur when and if the backup from R3 is torn 140 down. Tearing down R3's backup will make R2's backup temporarily 141 unavailable. 143 3. Backup Does Not Provide Protection 145 There are three examples of where the merging rules given in [FAST- 146 REROUTE] result in either a final detour LSP which does not provide 147 protection against failure or in no detour LSP being created. 149 3.1 Selected ERO Merges at PLR 151 In the following example, the merging rules in [FAST-REROUTE] require 152 that the shorter ERO be selected. 154 [R1]--[R2]----[R3]----[R4]---------------[R5]--[R6]-- 155 \ | | 156 \ [R7] [R8] 157 \ | \ | 158 \ | \ | 159 ------[R9]--[R10]--[R11]--[R12]---[R13] 161 Primary LSP: R1-R2-R3-R4-R5-R6-.... 162 R1's Backup: R1-R9-R10-R7-R3-R4-R5-R6-.... 163 R3's Backup: R3-R7-R9-R10-R11-R12-R13-R8-R5-R6-... 165 Figure 2: No Protection for PLR Because Merged Detour Ends at PLR 167 In this example, R9 must merge R1's backup and R3's backup. Because 168 the shorter ERO must be chosen, R9 would select R1's backup's ERO; 169 clearly R3 would not have an effective backup in this case. 171 This problem could be resolved by adding a merge rule which removes 172 any ERO from consideration which merges with the primary LSP at a 173 node which is the PLR for any detour LSP being merged. 175 3.2 Selected ERO Uses SRLG 177 In the following example, the selected ERO uses a link which belongs 178 to an SRLG which one of the merged detour LSPs was avoiding. 180 [R1]-----[R2]-----[R3]-------[R4] 181 \ | / | 182 -----[R5]------[R6]----[R7] | 183 | | 184 [R8]---[R9]--| 186 Primary LSP: R1-R2-R3-R4 187 R1's Backup: R1-R5-R6-R7-R4 188 R2's Backup: R2-R5-R6-R8-R9-R4 189 SRLG contains: R2-R3 and R6-R7 191 Figure 3: Merged Detour LSP Uses a Link Avoided Due to SRLG 193 In the above figure, the merging rules in [FAST-REROUTE] mean that R5 194 will select the ERO associated with R1's backup. Unfortunately, that 195 means that the merged detour LSP will not protect against the failure 196 of R2-R3 because the link R6-R7 is used in the final merged detour 197 LSP and R6-R7 and R2-R3 are in a common SRLG. 199 3.3 No Backup Path For Detour LSP 201 The CSPF rules given in [FAST-REROUTE] require that the backup path 202 selected does not cross a link in the same direction as the primary 203 LSP does. This is to avoid merging problems when a detour LSP 204 intersects its primary LSP and yet should not be merged. However, 205 this can result in the lack of protection, due to a lack of paths, as 206 described in the following example. 208 [R1]--[R2]--[R3]--[R4] 209 | / | | 210 | / | | 211 [R5]--[R6]--[R7]---------| 212 Primary: R5-R6-R7-R2-R3-R4 213 R2 Backup: R2-R6-R7-R4 214 [R2]-[R7] has insufficient bandwidth to support R2's backup 216 Figure 4: Detour LSP uses same link as primary LSP upstream from PLR 218 In the above example, there are two possible ways for R2 to have a 219 backup. Either, it can use R2-R6-R7 or it can use R2-R7. In this 220 scenario, the link R2-R7 does not have sufficient free bandwidth to 221 admit the backup LSP. 223 4. Solution to Problems with Merging Rules 225 The problems with the merging rules can be solved by using a 226 different SENDER_TEMPLATE for each backup LSP, instead of using the 227 primary's SENDER_TEMPLATE, and by not merging Path messages with 228 different EROs. 230 First, consider the solution of not merging Path messages with 231 different EROs. This alone appears to resolve all three of the 232 issues described in Section 3. However, simply not merging Path 233 messages with different EROs introduces other problems when all 234 detour LSPs for the same primary LSP have the same SENDER_TEMPLATE. 236 Consider the third issue described where the backup path must cross 237 and use the same link as the primary LSP. Not merging the detour LSP 238 and the primary LSP leads to the inability to determine whether a 239 PathErr belongs to the Primary LSP or to a Backup LSP through the LSR 240 with the same next hop. Figure 4 demonstrates the problem with this 241 partial solution. 243 In Figure 4, if the link from R7-R4 breaks, R7 will send a PathErr to 244 R6. If the SENDER_TEMPLATE for the Primary LSP and for R2's Backup 245 LSP were the same, then R6 would be unable to determine whether the 246 PathErr was for the Primary LSP or for R2's Backup LSP. This is the 247 problem with not merging Path messages with different EROs when 248 detour LSPs share the same SENDER_TEMPLATE. 250 To further elaborate, consider Figure 5 below, when one tries to NOT 251 merge Path messages for detour LSPs with different EROs but with the 252 same next link/hop. 254 [R1]--[R2]--[R3]--[R4] 255 \ | | / 256 \ | | / 257 [R5]---[R6] 259 Primary : R1-R5-R6-R4 260 R1's Backup: R1-R2-R3-R6 261 R5's Backup: R5-R2-R3-R4 263 Figure 5: OverMerging Backup LSPs 265 If the SENDER_TEMPLATES for R1's backup and R5's backup are the same, 266 then a RESV received for one would have a FILTER_SPEC which would 267 match both R1's backup and R5's backup. Because the SENDER_TEMPLATEs 268 are the same and the Detour object is not included in the RESV, there 269 is no way at R2 to distinguish a RESV for R1's backup from a RESV for 270 R5's backup. 272 From the preceeding, there are two alternatives if merging of Path 273 messages with different EROs is not desired (as demonstrated via 274 Figure 1). Either, the Detour object must be included in every Path, 275 Resv, PathErr, ResvErr, PathTear, ResvTear, and ResvConf message 276 which is for the detour LSP or the SENDER_TEMPLATEs for detour LSPs 277 must be different. The former alternative is essentially expanding 278 the SENDER_TEMPLATE to include the Detour object. 280 The recommendation is to simply use a different SENDER_TEMPLATE. The 281 "IPv4 tunnel sender address" in the SENDER_TEMPLATE MUST contain an 282 IP address of the PLR. 284 A backup LSP MUST be identified as follows. The SESSION object and 285 the LSP_ID are copied from the primary LSP being protected. The IPv4 286 tunnel sender address MUST be set to an address of the PLR node. If 287 the head-end of a tunnel is also acting as the PLR, it MUST choose an 288 IP address different from the one used in the SENDER_TEMPLATE of the 289 original LSP tunnel. 291 4.1 Detour Object Need Not be Understood 293 An additional benefit of having different SENDER_TEMPLATEs for detour 294 LSPs is that the Detour object need not be rejected by LSRs which do 295 not understand it. Instead, the Detour object can be silently passed 296 along; its use is for managability. 298 This simplifies the interoperability scenarios between an LSR which 299 implements only the facility backup method given in [FAST-REROUTE] 300 and not the one-to-one detour LSP backup method given in [FAST- 301 REROUTE]. 303 5. Make-Before-Break 305 Supporting make-before-break for detour LSPs is important if 306 re-optimization of the backup paths is desired. It guarantees that 307 the local protection, once created, will remain continuously 308 available until a failure occurs. At a PLR, consider a single 309 detour LSP for a given primary LSP. When network adaptivity, 310 configuration, etc. dictate that a different path is preferred for 311 the detour, a new detour LSP must be created. Once that new detour 312 LSP is created, the fast-reroute protection should be moved to the 313 new detour LSP; then the old detour LSP can finally be torn down. 315 The requirement is for local-protection to ALWAYS be available at a 316 given PLR for a given primary LSP until a single failure occurs. 317 That failure may occur on the backup or on the primary. 319 When signalling either detour LSP, the LSP ID used (sent in the 320 SENDER_TEMPLATE and the FILTER_SPEC objects) is that of the primary 321 LSP which the backup LSP is protecting. The SESSION object used 322 when signalling the backup LSP is the same as the SESSION object of 323 the primary LSP. 325 Therefore, the option of using a different LSP-ID, as described in 326 [RSVP-TE] for a regular tunnel, is not available for 327 make-before-break on a backup. As described in [RSVP-TE], when 328 doing a make-before-break on a regular tunnel, the ingress will 329 allocate a new LSP ID to be used when creating a new LSP. 331 To support make-before-break on a backup, it is necessary to have a 332 way of distinguishing the current backup LSP from the new backup 333 LSP. The content in the SENDER_TEMPLATE (and FILTER_SPEC) are the 334 LSP ID and the "IPv4 (IPv6) tunnel sender address". The former 335 cannot be modified; therefore it is necessary to change the 336 address. 338 For detour LSPs, the "IPv4 (IPv6) tunnel sender address" will be 339 filled with one of the PLR's address, which is different from that 340 used when the LSR acts as an ingress, rather than a PLR. 341 Additionally, for Detour Backup LSPs, the PLR will put that same 342 address in the DETOUR Object's "Source ID". 344 An LSR distinguishes a backup LSP from a primary LSP based upon the 345 "IPv4 (IPv6) tunnel sender address" in the SENDER_TEMPLATE (and 346 FILTER_SPEC). Therefore, to signal two different backup LSPs from 347 the same PLR for the same primary LSP, the PLR must use different 348 IP addresses, which are put into the SENDER_TEMPLATE. 350 To effect a reroute or a bandwidth change on a backup, the PLR 351 picks one of its IP addresses which is different from that used for 352 the current backup LSP and which is different from that used for 353 primary LSP. Then the PLR signals the new backup LSP and proceeds 354 with a make-before-break as described in [RSVP-TE]. 356 To support make-before-break on backups in this manner, the PLR 357 must have ownership of two distinct IP addresses. If the PLR is 358 also ingress, then it requires a third distinct IP address, which 359 it uses when signalling primary LSPs. Only the router ID needs to 360 be routable. All three addresses MUST be unique within the MPLS 361 domain. 363 Support of make-before-break on backups MAY be supported. 365 6. Revertive Behavior: Recovery from Failure 367 [MPLS-RECOVERY] describes some motivations for supporting revertive 368 behavior. It is necessary to have a method for recovering back to 369 the primary LSP after a failure has recovered. Ideally, as soon as 370 the Ingress learned about the failure, a new primary LSP would have 371 been created and the traffic moved onto it. Practically, it is not 372 required to occur. A recomputation of the primary tunnel's path 373 for a new primary LSP can guarantee the use of a newly available 374 resource. 376 Revertive behavior MAY be supported. The determination of when a 377 failure is over is as follows: 379 1) The locally detected failure, if any, has cleared 380 (e.g. interface has come back up), 382 2) and a RESV message for the primary LSP has been received 383 since the failure occured. 385 Practically, when a RESV for the primary LSP is received at a PLR 386 and that PLR has local protection in use for that primary LSP, if 387 no local failure is detectable, the PLR may revert to using the 388 primary LSP. 390 When the RESV for the primary LSP is received, it is highly likely 391 that a different label will be specified in the LABEL Object. This 392 occurs if the downstream neighbor of the PLR has lost all knowledge 393 of the primary LSP. When the PLR receives a different label, it 394 MUST change the primary LSP to using that label without propogating 395 a different label upstream. 397 Essentially, to revert to the primary LSP, the PLR should: 399 1) Update the primary LSP's out-segment to use the new label 400 specified, 402 2) Move the traffic from the backup LSP's out-segment to the 403 primary LSP's out-segment, 405 3) And clear the "local protection in use" flag from its IPv4 406 (IPv6) address subobject in the primary LSP's RRO. This 407 change should be propogated back to the ingress as soon as 408 feasible. 410 6.1 Local Failure 412 If the failure being recovered from is local, no PATH messages can 413 be sent for the primary LSP until the affected link, etc, has 414 recovered. 416 If the failure was resource preemption, revertive behavior may not 417 be reasonable. If desired, then if a PATH message for the primary 418 LSP succeeds in getting resources on the primary LSP's out-going 419 interface, then and only then can the PLR forward a PATH message 420 for the primary LSP downstream. 422 6.2 Remote Failure 424 If the failure being recovered from is remote, then the PLR may 425 send PATH messages for the primary LSP immediately. However, in 426 response to such a PATH message while the failure is occuring, the 427 PATH message will be met with a PathErr. All such PathErrs must be 428 ignored and not propogated upstream. The PLR is already aware that 429 a failure exists and is repairing around that failure. The PLR 430 should send a PATH message for the primary LSP no more frequently 431 than the normal refresh interval. 433 7. Security Considerations 435 These procedures do not change the trust model of RSVP [RFC2205] 436 and [RSVP-TE]. As such no additional security risks are posed. 438 8. References 440 [FAST-REROUTE] Pan, P. et al., "Fast Reroute Techniques in 441 RSVP-TE", Internet Draft, draft-ping-rsvp-fastreroute-00.txt, 442 November 2001 444 [MPLS-RECOVERY] Sharma, V. et al., "Framework for MPLS-based 445 Recovery", Internet Draft, draft-ietf-mpls-recovery-frmwrk-03.txt, 446 July 2001 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", RFC 2119, March 1997. 451 [RFC2205] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) 452 -- Version 1, Functional Specification", RFC 2205, September 453 1997. 455 [RSVP-TE] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP 456 Tunnels", Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, 457 February 2001. 459 9. Authors' Addresses 461 Alia Atlas 462 Avici Systems 463 101 Billerica Avenue 464 N. Billerica, MA 01862 465 Voice: +1 (978) 964-2070 466 Email: aatlas@avici.com 468 Markus Jork 469 Avici Systems 470 101 Billerica Avenue 471 N. Billerica, MA 01862 472 Voice: +1 (978) 964-2142 473 Email: mjork@avici.com