idnits 2.17.1 draft-ietf-rtgwg-ipfrr-spec-base-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 728. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 734. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 273: '... specification MUST conform to at le...' RFC 2119 keyword, line 281: '...ternate next-hop MUST be loop-free wit...' RFC 2119 keyword, line 297: '...herefore, a router MUST assume that an...' RFC 2119 keyword, line 351: '...ernate, a router MUST not consider div...' RFC 2119 keyword, line 357: '...inity, then router S MUST NOT consider...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For computing an alternate, a router MUST not consider diverting from the SPF tree along a link whose cost or reverse cost is LSInfinity (for OSPF) or the maximum cost (for ISIS) or whose next-hop router has the overload bit set (for ISIS). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Multicast traffic is out of scope for this specification of IP Fast-Reroute. The alternate next-hops SHOULD not used for multi-cast RPF checks. -- 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 (January 21, 2005) is 7028 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) == Unused Reference: 'RFC3036' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 656, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-ipfrr-framework-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rtgwg-ipfrr-framework (ref. 'FRAMEWORK') ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 3137 (Obsoleted by RFC 6987) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Atlas, Ed. 3 Internet-Draft Avici Systems, Inc. 4 Expires: July 22, 2005 January 21, 2005 6 Basic Specification for IP Fast-Reroute: Loop-free Alternates 7 draft-ietf-rtgwg-ipfrr-spec-base-02 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 22, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes the use of loop-free alternates to provide 43 local protection for IP unicast and/or LDP traffic in the event of a 44 single failure, whether link, node or shared risk link group (SRLG). 45 The goal of this technology is to reduce the micro-looping that and 46 packet loss that happens while routers converge after a topology 47 change due to a failure. When a topology change occurs, a router S 48 determines for each prefix an alternate next-hop which can be used if 49 the primary next-hop fails. An acceptable alternate next-hop must be 50 a loop-free alternate, which goes to a neighbor whose shortest path 51 to the prefix does not go back through the router S. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Failure Scenarios . . . . . . . . . . . . . . . . . . . . 4 57 2. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 6 58 2.1 Basic Loop-free Condition . . . . . . . . . . . . . . . . 7 59 2.2 Node-Protecting Alternate Next-Hops . . . . . . . . . . . 7 60 2.3 Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 7 61 2.4 Interactions with ISIS Overload, RFC 3137 and Costed 62 Out Links . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.5 Selection Procedure . . . . . . . . . . . . . . . . . . . 9 64 3. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 10 65 3.1 Terminating Use of Alternate . . . . . . . . . . . . . . . 10 66 4. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 12 67 5. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.1 Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 12 69 5.2 OSPF External Routing . . . . . . . . . . . . . . . . . . 13 70 5.3 OSPF Virtual Links . . . . . . . . . . . . . . . . . . . . 14 71 5.4 BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 14 72 5.5 Multicast Considerations . . . . . . . . . . . . . . . . . 14 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 76 Intellectual Property and Copyright Statements . . . . . . . . 17 78 1. Introduction 80 Applications for interactive multimedia services such as VoIP and 81 pseudo-wires can be very sensitive to traffic loss, such as occurs 82 when a link or router in the network fails. A router's convergence 83 time is generally on the order of seconds; the application traffic 84 may be sensitive to losses greater than 10s of milliseconds. 86 As discussed in [FRAMEWORK], minimizing traffic loss requires a 87 mechanism for the router adjacent to a failure to rapidly invoke a 88 repair path, which is minimally affected by any subsequent 89 re-convergence. This specification describes such a mechanism which 90 allows a router whose local link has failed to forward traffic to a 91 pre-computed alternate until the router installs the new primary 92 next-hops based upon the changed network topology. The terminology 93 used in this specification is given in [FRAMEWORK]. 95 When a local link fails, a router currently must signal the event to 96 its neighbors via the IGP, recompute new primary next-hops for all 97 affected prefixes, and only then install those new primary next-hops 98 into the forwarding plane. Until the new primary next-hops are 99 installed, traffic directed towards the affected prefixes is 100 discarded. This process can take seconds. 102 <-- 103 +-----+ 104 /------| S |--\ 105 / +-----+ \ 106 / 5 8 \ 107 / \ 108 +-----+ +-----+ 109 | E | | N_1 | 110 +-----+ +-----+ 111 \ / 112 \ \ 4 3 / / 113 \| \ / |/ 114 -+ \ +-----+ / +- 115 \---| D |---/ 116 +-----+ 118 Figure 1: Basic Topology 120 The goal of IP Fast-Reroute is to reduce that traffic convergence 121 time to 10s of milliseconds by using a pre-computed alternate 122 next-hop, in the event that the currently selected primary next-hop 123 fails, so that the alternate can be rapidly used when the failure is 124 detected. A network with this feature experiences less traffic loss 125 and less micro-looping of packets than a network without IPFRR. 127 There are cases where micro-looping is still a possibility since 128 IPFRR coverage varies but in the worst possible situation a network 129 with IPFRR is equivalent with respect traffic convergence to a 130 network without IPFRR. 132 To clarify the behavior of IP Fast-Reroute, consider the simple 133 topology in Figure 1. When router S computes its shortest path to 134 router D, router S determines to use the link to router E as its 135 primary next-hop. Without IP Fast-Reroute, that link is the only 136 next-hop that router S computes to reach D. With IP Fast-Reroute, S 137 also looks for an alternate next-hop to use. In this example, S 138 would determine that it could send traffic destined to D by using the 139 link to router N_1 and therefore S would install the link to N_1 as 140 its alternate next-hop. At some later time, the link between router 141 S and router E could fail. When that link fails, S and E will be the 142 first to detect it. On detecting the failure, S will stop sending 143 traffic destined for D towards E via the failed link, and instead 144 send the traffic to S's pre-computed alternate next-hop, which is the 145 link to N_1, until a new SPF is run and its results are installed. 146 As with the primary next-hop, an alternate next-hop is computed for 147 each destination. The process of computing an alternate next-hop 148 does not alter the primary next-hop computed via a standard SPF. 150 If in the example of Figure 1, the link cost from N_1 to D increased 151 to 30 from 3, then N_1 would not be a loop-free alternate, because 152 the cost of the path from N_1 to D via S would be 17 while the cost 153 from N_1 directly to D would be 30. In real networks, we may often 154 face this situation. The existence of a suitable loop-free alternate 155 next-hop is topology dependent. 157 A neighbor N can provide a loop-free alternate if and only if 159 Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D) 161 Equation 1: Loop-Free Criterion 163 A sub-set of loop-free alternate are downstream paths which must meet 164 the more restrictive condition of 166 Distance_opt(N, D) < Distance_opt(S, D) 168 Equation 2: Downstream Path Criterion 170 1.1 Failure Scenarios 172 The alternate next-hop can protect against a single link failure, a 173 single node failure, one or more shared risk link group failure, or a 174 combination of these. Whenever a failure occurs that is more 175 extensive than what the alternate was intended to protect, there is 176 the possibility of looping traffic. The example where a node fails 177 when the alternate provided only link protection is illustrated 178 below. If unexpected simultaneous failures occur, then micro-looping 179 may occur since the alternates are not pre-computed to avoid the set 180 of failed links. 182 If only link protection is provided and the node fails, it is 183 possible for traffic using the alternates to experience 184 micro-looping. This issue is illustrated in Figure 2. If Link(S->E) 185 fails, then the link-protecting alternate via N will work correctly. 186 However, if router E fails, then both S and N will detect a failure 187 and switch to their alternates. In this example, that would cause S 188 to redirect the traffic to N and N to redirect the traffic to S and 189 thus causing a forwarding loop. Such a scenario can arise because 190 the key assumption, that all other routers in the network are 191 forwarding based upon the shortest path, is violated because of a 192 second simultaneous correlated failure - another link connected to 193 the same primary neighbor. If there are not other protection 194 mechanisms a node failure is still a concern when only using link 195 protection. 197 <@@@ 198 @@@> 199 +-----+ +-----+ 200 | S |-------| N | 201 +-+---+ 5 +-----+ 202 | | 203 | 5 4 | | 204 | | | \|/ 205 \|/ | | 206 | +-----+ | 207 +----| E |---+ 208 +--+--+ 209 | 210 | 211 | 10 212 | 213 +--+--+ 214 | D | 215 +-----+ 217 Figure 2: Link-Protecting Alternates Causing Loop on Node Failure 219 Micro-looping of traffic via the alternates caused when a more 220 extensive failure than planned for can be prevented via selection of 221 only downstream paths as alternates. In Figure 2, S would be able to 222 use N as an alternate, but N could not use S; therefore N would have 223 no alternate and would discard the traffic, thus avoiding the 224 micro-loop. A micro-loop due to the use of alternates can be avoided 225 by using downstream paths because each router in the path to the 226 destination must be closer to the destination (according to the 227 topology prior to the failures). Although use of downstream paths 228 ensures that the micro-looping via alternates does not occur, such a 229 restriction can severely limit the coverage of alternates. 231 It may be desirable to find an alternate that can protect against 232 other correlated failures (of which node failure is a specific 233 instance). In the general case, these are handled by shared risk 234 link groups (SRLGs) where any links in the network can belong to the 235 SRLG. General SRLGs may add unacceptably to the computational 236 complexity of finding a loop-free alternate. 238 However, a sub-category of SRLGs is of interest and can be applied 239 only during the selection of an acceptable alternate. This 240 sub-category is to express correlated failures of links that are 241 connected to the same router. For example, if there are multiple 242 logical sub-interfaces on the same physical interface, such as VLANs 243 on an Ethernet interface, if multiple interfaces use the same 244 physical port because of channelization, or if multiple interfaces 245 share a correlated failure because they are on the same line-card. 246 This sub-category of SRLGs will be referred to as local-SRLGs. A 247 local-SRLG has all of its member links with one end connected to the 248 same router. Thus, router S could select a loop-free alternate which 249 does not use a link in the same local-SRLG as the primary next-hop. 250 The local-SRLGs belonging to E can be protected against via 251 node-protection; i.e. picking a loop-free node-protecting alternate. 253 2. Alternate Next-Hop Calculation 255 To support IP Fast-Reroute, a router must be able to determine if a 256 next-hop will provide a loop-free alternate before the router 257 installs that next-hop as an alternate. That next-hop must go to a 258 loop-free neighbor. 260 To do this computation, a router could run an SPF from the 261 perspective of each of its neighbors as well as from its own 262 perspective. This provides the router with all the information 263 necessary to test the equations given is this specification. 265 To determine SRLG protection, the set of SRLGs that include at least 266 one link from the computing router could be determined. Then when 267 the SPF is run from the perspective of a router's neighbor, the SRLGs 268 traversed on each shortest path can be tracked. 270 2.1 Basic Loop-free Condition 272 Alternate next hops used by implementations following this 273 specification MUST conform to at least the loop-freeness condition 274 stated above in Equation 1. Further conditions may be applied when 275 determining link-protecting and/or node-protecting alternate 276 next-hops as described in Sections Section 2.2 and Section 2.3. 278 2.2 Node-Protecting Alternate Next-Hops 280 For an alternate next-hop to protect against node failure, the 281 alternate next-hop MUST be loop-free with respect to the primary 282 neighbor E and the destination. 284 An alternate will be node-protecting if it doesn't go through the 285 same primary neighbor as the primary next-hop. This is the case if 286 Equation 3 is true, where N is the neighbor providing a loop-free 287 alternate. 289 Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D) 291 Equation 3: Criteria for a Node-Protecting Loop-Free Alternate 293 If Distance_opt(N,D) = Distance_opt(N, E) + Distance_opt(E, D), it is 294 possible that the neighbor may have equal-cost paths and one of those 295 could provide a loop-free node-protecting alternate. However, the 296 decision as to which of equal-cost paths a router will use is a 297 router-local decision. Therefore, a router MUST assume that an 298 alternate next-hop does not offer node protection if Equation 3 is 299 not met. 301 2.3 Broadcast and NBMA Links 303 The computation for link-protection is a bit more complicated for 304 broadcast links. In an SPF computation, a broadcast links is 305 represented as a pseudo-node with links of 0 cost exiting the 306 pseudo-node. For an alternate to be considered link-protecting, it 307 must be loop-free with regard to the pseudo-node. Consider the 308 example in Figure 3. 310 +-----+ 15 311 | S |-------- 312 +-----+ | 313 | 5 | 314 | | 315 | 0 | 316 /----\ 0 5 +-----+ 317 | PN |-----| N | 318 \----/ +-----+ 319 | 0 | 320 | | 8 321 | 5 | 322 +-----+ 5 +-----+ 323 | E |----| D | 324 +-----+ +-----+ 326 Figure 3: Loop-Free Alternate that is Link-Protecting 328 In Figure 3, N offers a loop-free alternate which is link-protecting. 329 If the primary next-hop uses a broadcast link, then an alternate must 330 be loop-free with respect to that link's pseudo-node to provide link 331 protection. This requirement is described in Equation 4 below. 333 D_opt(N, D) < D_opt(N, pseudo) + D_opt(pseudo, D) 335 Equation 4: Loop-Free Link-Protecting Criterion for Broadcast Links 337 Because the shortest path from the pseudo-node goes through E, if a 338 loop-free alternate from a neighbor N is node-protecting, the 339 alternate will also be link-protecting unless the router S can only 340 reach the neighbor N via the same pseudo-node. This can occur 341 because S will direct traffic away from the shortest path to use an 342 alternate. Therefore link protection must be considered during the 343 alternate selection. 345 2.4 Interactions with ISIS Overload, RFC 3137 and Costed Out Links 347 As described in [RFC3137], there are cases where it is desirable not 348 to have a router used as a transit node. For those cases, it is also 349 desirable not to have the router used on an alternate path. 351 For computing an alternate, a router MUST not consider diverting from 352 the SPF tree along a link whose cost or reverse cost is LSInfinity 353 (for OSPF) or the maximum cost (for ISIS) or whose next-hop router 354 has the overload bit set (for ISIS). 356 In the case of OSPF, if all links from router S to a neighbor N_i 357 have a reverse cost of LSInfinity, then router S MUST NOT consider 358 using N_i as an alternate. 360 Similarly in the case of ISIS, if N_i has the overload bit set, then 361 S MUST NOT consider using N_i as an alternate. 363 This preserves the desired behavior of diverting traffic away from a 364 router which is following [RFC3137] and it also preserves the desired 365 behavior when an operator sets the cost of a link to LSInfinity for 366 maintenance which is not permitting traffic across that link unless 367 there is no other path. 369 If a link or router which is costed out was the only possible 370 alternate to protect traffic from a particular router S to a 371 particular destination, then there will be no alternate provided for 372 protection. 374 2.5 Selection Procedure 376 A router supporting this specification SHOULD select a loop-free 377 alternate next-hop for each primary next-hop used for a given prefix. 378 A router MAY decide to not use an available loop-free alternate 379 next-hop. A reason for such a decision might be that the loop-free 380 alternate next-hop does not provide protection for the failure 381 scenario of interest. 383 The alternate selection should maximize the coverage of the failure 384 cases. 386 S SHOULD select a loop-free node-protecting alternate next-hop, if 387 one is available. If S has a choice between a loop-free 388 link-protecting node-protecting alternate and a loop-free 389 node-protecting alternate which is not link-protecting, S SHOULD 390 select a loop-free node-protecting alternate which is also 391 link-protecting. This can occur as explained in Section 2.3. If S 392 has multiple primary next-hops, then S SHOULD select as a loop-free 393 alternate either one of the other primary next-hops or a loop-free 394 node-protecting alternate. If no loop-free node-protecting alternate 395 is available, then S MAY select a loop-free link-protecting 396 alternate. 398 Each next-hop can be categorized as to the type of alternate it can 399 provide to a particular destination D from router S for a particular 400 primary next-hop which goes to a neighbor E. A next-hop may provide 401 one of the following types of paths: 403 Primary Path - This is the primary next-hop. 405 Loop-Free Node-Protecting Alternate - This next-hop satisfies 406 Equation 1 and Equation 3. The path avoids S, S's primary 407 neighbor E, and the link from S to E. 409 Loop-Free Link-Protecting Alternate - This next-hop satisfies 410 Equation 1 but not Equation 3. If the primary next-hop uses a 411 broadcast link, then this next-hop satisfies Equation 4. 413 Unavailable - This may be because the path goes through S to reach 414 D, because the link is costed out, etc. 416 An alternate path may also provide none, some or complete SRLG 417 protection as well as node and link or link protection. For 418 instance, a link may belong to two SRLGs G1 and G2. The alternate 419 path might avoid other links in G1 but not G2, in which case the 420 alternate would only provide partial SRLG protection. 422 3. Using an Alternate 424 If an alternate next-hop is available, the router SHOULD redirect 425 traffic to the alternate next-hop when the primary next-hop has 426 failed. 428 When a local interface failure is detected, traffic that was destined 429 to go out the failed interface must be redirected to the appropriate 430 alternate next-hops. Other failure detection mechanisms which detect 431 the loss of a link or a node may also be used to trigger redirection 432 of traffic to the appropriate alternate next-hops. The mechanisms 433 available for failure detection are discussed in [FRAMEWORK] and are 434 outside the scope of this specification. 436 The alternate next-hop MUST be used only for traffic types which are 437 routed according to the shortest path. Multicast traffic is 438 specifically out of scope for this specification. 440 3.1 Terminating Use of Alternate 442 A router MUST limit the amount of time an alternate next-hop is used 443 after the primary next-hop has become unavailable. This ensures that 444 the router will start using the new primary next-hops. It ensures 445 that all possible transient conditions are removed and the network 446 converges according to the deployed routing protocol. 448 It is desirable to avoid micro-forwarding loops involving S. An 449 example illustrating the problem is given in Figure 4. If the link 450 from S to E fails, S will use N1 as an alternate and S will compute 451 N2 as the new primary next-hop to reach D. If S starts using N2 as 452 soon as S can compute and install its new primary, it is probable 453 that N2 will not have yet installed its new primary next-hop. This 454 would cause traffic to loop and be dropped until N2 has installed the 455 new topology. This can be avoided by S delaying its installation and 456 leaving traffic on the alternate next-hop. 458 +-----+ 459 | N2 |-------- | 460 +-----+ 1 | \|/ 461 | | 462 | +-----+ @@> +-----+ 463 | | S |---------| N1 | 464 10 | +-----+ 10 +-----+ 465 | | | 466 | 1 | | | 467 | | \|/ 10 | 468 | +-----+ | | 469 | | E | | \|/ 470 | +-----+ | 471 | | | 472 | 1 | | | 473 | | \|/ | 474 | +-----+ | 475 |----| D |-------------- 476 +-----+ 478 Figure 4: Example where Continued Use of Alternate is Desirable 480 This is an example of a case where the new primary is not a loop-free 481 alternate before the failure and therefore may have been forwarding 482 traffic through S. This will occur when the path via a previously 483 upstream node is shorter than the the path via a loop-free alternate 484 neighbor. In these cases, it is useful to give sufficient time to 485 ensure that the new primary neighbor and other nodes on the new 486 primary path have switched to the new route. 488 If the newly selected primary was loop-free before the failure, then 489 it is safe to switch to that new primary immediately; the new primary 490 wasn't dependent on the failure and therefore its path will not have 491 changed. 493 Given that there is an alternate providing appropriate protection and 494 while the assumption of a single failure holds, it is safe to delay 495 the installation of the new primaries; this will not create 496 forwarding loops because the alternate's path to the destination is 497 known to not go via S or the failed element and will therefore not be 498 affected by the failure. 500 An implementation SHOULD continue to use the alternate next-hops for 501 packet forwarding even after the new routing information is available 502 based on the new network topology. The use of the alternate 503 next-hops for packet forwarding SHOULD terminate: 505 a. if the new primary next-hop was loop-free prior to the topology 506 change, or 508 b. if a configured hold-down, which represents a worst-case bound on 509 the length of the network convergence transition, has expired, or 511 c. if notification of an unrelated topological change in the network 512 is received. 514 4. Requirements on LDP Mode 516 Since LDP traffic will follow the path specified by the IGP, it is 517 also possible for the LDP traffic to follow the loop-free alternates 518 indicated by the IGP. To do so, it is necessary for LDP to have the 519 appropriate labels available for the alternate so that the 520 appropriate out-segments can be installed in the forwarding plane 521 before the failure occurs. 523 This means that a Label Switched Router (LSR) running LDP must 524 distribute its labels for the FECs it can provide to all its 525 neighbors, regardless of whether or not they are upstream. 526 Additionally, LDP must be acting in liberal label retention mode so 527 that the labels which correspond to neighbors that aren't currently 528 the primary neighbor are stored. Similarly, LDP should be in 529 downstream unsolicited mode, so that the labels for the FEC are 530 distributed other than along the SPT. 532 If these requirements are met, then LDP can use the loop-free 533 alternates without requiring any targeted sessions or signaling 534 extensions for this purpose. 536 5. Routing Aspects 538 5.1 Multi-Homed Prefixes 540 An SPF-like computation is run for each topology, which corresponds 541 to a particular OSPF area or ISIS level. The IGP needs to determine 542 loop-free alternates to multi-homed routes. Multi-homed routes occur 543 for routes obtained from outside the routing domain by multiple 544 routers, for subnets on links where the subnet is announced from 545 multiple ends of the link, and for routes advertised by multiple 546 routers to provide resiliency. 548 Figure 5 demonstrates such a topology. In this example, the shortest 549 path to reach the prefix p is via E. The prefix p will have the link 550 to E as its primary next-hop. If the alternate next-hop for the 551 prefix p is simply inherited from the router advertising it on the 552 shortest path to p, then the prefix p's alternate next-hop would be 553 the link to C. This would provide link protection, but not the node 554 protection that is possible via A. 556 5 +---+ 4 +---+ 5 +---+ 557 ------| S |------| A |-----| B | 558 | +---+ +---+ +---+ 559 | | | 560 | 5 | 5 | 561 | | | 562 +---+ 5 +---+ 5 7 +---+ 563 | C |---| E |------ p -------| F | 564 +---+ +---+ +---+ 566 Figure 5: Multi-homed prefix 568 To determine the best protection possible, the prefix p can be 569 treated in the SPF computations as a node with uni-directional links 570 to it from those routers that have advertised the prefix. Such a 571 node need never have its links explored, as it has no out-going 572 links. 574 If there exist multiple multi-homed prefixes exist that share the 575 same connectivity and the difference in metrics to those routers, 576 then a single node can be used to represent the set. For instance, 577 if in Figure 5 there were another prefix X that was connected to E 578 with a metric of 1 and to F with a metric of 3, then that prefix X 579 could use the same alternate next-hop as was computed for prefix p. 581 A router SHOULD compute the alternate next-hop for an IGP multi-homed 582 prefix by considering alternate paths via all routers that have 583 announced that prefix. 585 5.2 OSPF External Routing 587 An additional complication comes from forwarding addresses, where an 588 ASBR uses a forwarding address to indicate to all routers in the 589 Autonomous System to use the specified address instead of going 590 through the ASBR. When a forwarding address has been indicated, all 591 routers in the topology calculate the shortest path to the link 592 specified in the external LSA. In this case, the alternate next-hop 593 should be computed by selecting among the alternate paths to the 594 forwarding link(s) instead of among alternate paths to the ASBR. 596 5.3 OSPF Virtual Links 598 OSPF virtual links are used to connect two disjoint backbone areas 599 using a transit area. A virtual link is configured at the border 600 routers of the disjoint area. If router S is itself an ABR or one of 601 the endpoints of the disjoint area, then router S must resolve its 602 paths to the destination on the other side of the disjoint area by 603 using the summary links in the transit area and using the closest ABR 604 summarizing them into the transit area. This means that the data 605 path may diverge from the virtual neighbor's control path. An ABR's 606 primary and alternate next-hops are calculated by S on the transit 607 area. 609 A virtual link MUST NOT be used as an alternate next-hop. 611 5.4 BGP Next-Hop Synchronization 613 Typically BGP prefixes are advertised with AS exit routers router-id, 614 and AS exit routers are reached by means of IGP routes. BGP resolves 615 its advertised next-hop to the immediate next-hop by potential 616 recursive lookups in the routing database. IP Fast-Reroute computes 617 the alternate next-hops to all IGP destinations, which include 618 alternate next-hops to the AS exit router's router-id. BGP simply 619 inherits the alternate next-hop from IGP. The BGP decision process 620 is unaltered; BGP continues to use the IGP optimal distance to find 621 the nearest exit router. MBGP routes do not need to copy the 622 alternate next hops. 624 It is possible to provide ASBR protection if BGP selected a set of 625 IGP next-hops and allowed the IGP to determine the primary and 626 alternate next-hops as if the BGP route were a multi-homed prefix. 627 This is for future study. 629 5.5 Multicast Considerations 631 Multicast traffic is out of scope for this specification of IP 632 Fast-Reroute. The alternate next-hops SHOULD not used for multi-cast 633 RPF checks. 635 6. Security Considerations 637 This document does not introduce any new security issues. The 638 mechanisms described in this document depend upon the network 639 topology distributed via an IGP, such as OSPF or ISIS. It is 640 dependent upon the security associated with those protocols. 642 7 References 644 [FRAMEWORK] 645 Shand, M., "IP Fast Reroute Framework", 646 draft-ietf-rtgwg-ipfrr-framework-02.txt (work in 647 progress), October 2004. 649 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 650 B. Thomas, "LDP Specification", RFC 3036, January 2001. 652 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A. and D. 653 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 654 June 2001. 656 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 657 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 658 Tunnels", RFC 3209, December 2001. 660 Authors' Addresses 662 Alia K. Atlas (editor) 663 Avici Systems, Inc. 664 101 Billerica Avenue 665 N. Billerica, MA 01862 666 USA 668 Phone: +1 978 964 2070 669 EMail: aatlas@avici.com 671 Raveendra Torvi 672 Avici Systems, Inc. 673 101 Billerica Avenue 674 N. Billerica, MA 01862 675 USA 677 Phone: +1 978 964 2026 678 EMail: rtorvi@avici.com 679 Gagan Choudhury 680 AT&T 681 200 Laurel Avenue, Room D5-3C21 682 Middletown, NJ 07748 683 USA 685 Phone: +1 732 420-3721 686 EMail: gchoudhury@att.com 688 Christian Martin 689 Verizon 690 1880 Campus Commons Drive 691 Reston, VA 20191 692 USA 694 Brent Imhoff 695 LightCore 696 14567 North Outer Forty Rd. 697 Chesterfield, MO 63017 698 USA 700 Phone: +1 314 880 1851 701 EMail: brent@lightcore.net 703 Don Fedyk 704 Nortel Networks 705 600 Technology Park 706 Billerica, MA 01821 707 USA 709 Phone: +1 978 288 3041 710 EMail: dwfedyk@nortelnetworks.com 712 Intellectual Property Statement 714 The IETF takes no position regarding the validity or scope of any 715 Intellectual Property Rights or other rights that might be claimed to 716 pertain to the implementation or use of the technology described in 717 this document or the extent to which any license under such rights 718 might or might not be available; nor does it represent that it has 719 made any independent effort to identify any such rights. Information 720 on the procedures with respect to rights in RFC documents can be 721 found in BCP 78 and BCP 79. 723 Copies of IPR disclosures made to the IETF Secretariat and any 724 assurances of licenses to be made available, or the result of an 725 attempt made to obtain a general license or permission for the use of 726 such proprietary rights by implementers or users of this 727 specification can be obtained from the IETF on-line IPR repository at 728 http://www.ietf.org/ipr. 730 The IETF invites any interested party to bring to its attention any 731 copyrights, patents or patent applications, or other proprietary 732 rights that may cover technology that may be required to implement 733 this standard. Please address the information to the IETF at 734 ietf-ipr@ietf.org. 736 Disclaimer of Validity 738 This document and the information contained herein are provided on an 739 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 740 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 741 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 742 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 743 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 744 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 746 Copyright Statement 748 Copyright (C) The Internet Society (2005). This document is subject 749 to the rights, licenses and restrictions contained in BCP 78, and 750 except as set forth therein, the authors retain all their rights. 752 Acknowledgment 754 Funding for the RFC Editor function is currently provided by the 755 Internet Society.