idnits 2.17.1 draft-ietf-rtgwg-ipfrr-spec-base-05.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1164. ** 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. 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 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 372: '... specification MUST conform to at le...' RFC 2119 keyword, line 397: '...on to use it. Therefore, it SHOULD be...' RFC 2119 keyword, line 434: '... SHOULD be loop-free with respect to...' RFC 2119 keyword, line 509: '...ernate, a router MUST NOT use an alter...' RFC 2119 keyword, line 520: '...ity, then router S MUST NOT use N_i as...' (21 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 'SHOULD not' in this paragraph: Multicast traffic is out of scope for this specification of IP Fast-Reroute. The alternate next-hops SHOULD not be 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 (February 2006) is 6616 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'E1' is mentioned on line 477, but not defined == Missing Reference: 'E2' is mentioned on line 477, but not defined == Missing Reference: 'A' is mentioned on line 480, but not defined == Missing Reference: 'B' is mentioned on line 480, but not defined == Missing Reference: 'FRAMEWORK' is mentioned on line 735, but not defined == Unused Reference: 'RFC3036' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1019, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-03) exists of draft-ietf-isis-link-attr-01 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-ipfrr-framework-05 -- Obsolete informational reference (is this intentional?): RFC 2966 (Obsoleted by RFC 5302) -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) -- Obsolete informational reference (is this intentional?): RFC 4205 (Obsoleted by RFC 5307) Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 11 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 Google, Inc. 4 Expires: August 5, 2006 A. Zinin, Ed. 5 Alcatel 6 February 2006 8 Basic Specification for IP Fast-Reroute: Loop-free Alternates 9 draft-ietf-rtgwg-ipfrr-spec-base-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 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 August 5, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes the use of loop-free alternates to provide 43 local protection for unicast traffic in pure IP and MPLS/LDP networks 44 in the event of a single failure, whether link, node or shared risk 45 link group (SRLG). The goal of this technology is to reduce the 46 micro-looping and packet loss that happens while routers converge 47 after a topology change due to a failure. Rapid failure repair is 48 achieved through use of precalculated backup next-hops that are loop- 49 free and safe to use until the distributed network convergence 50 process completes. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Failure Scenarios . . . . . . . . . . . . . . . . . . . . 5 56 2. Applicability of Described Mechanisms . . . . . . . . . . . . 6 57 3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 7 58 3.1 Basic Loop-free Condition . . . . . . . . . . . . . . . . 8 59 3.2 Node-Protecting Alternate Next-Hops . . . . . . . . . . . 9 60 3.3 Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 9 61 3.4 ECMP and Alternates . . . . . . . . . . . . . . . . . . . 11 62 3.5 Interactions with ISIS Overload, RFC 3137 and Costed 63 Out Links . . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.5.1 Interactions with ISIS Link Attributes . . . . . . . . 12 65 3.6 Selection Procedure . . . . . . . . . . . . . . . . . . . 12 66 4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 16 67 4.1 Terminating Use of Alternate . . . . . . . . . . . . . . . 17 68 5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 18 69 6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 19 70 6.1 Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 19 71 6.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 6.2.1 OSPF External Routing . . . . . . . . . . . . . . . . 20 73 6.3 BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 21 74 6.4 Multicast Considerations . . . . . . . . . . . . . . . . . 21 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 9.1 Normative References . . . . . . . . . . . . . . . . . . . 22 79 9.2 Informative References . . . . . . . . . . . . . . . . . . 22 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 81 A. OSPF Example Where LFA Based on Local Area Topology is 82 Insufficient . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 Intellectual Property and Copyright Statements . . . . . . . . 26 85 1. Introduction 87 Applications for interactive multimedia services such as VoIP and 88 pseudo-wires can be very sensitive to traffic loss, such as occurs 89 when a link or router in the network fails. A router's convergence 90 time is generally on the order of seconds; the application traffic 91 may be sensitive to losses greater than 10s of milliseconds. 93 As discussed in [I-D.ietf-rtgwg-ipfrr-framework], minimizing traffic 94 loss requires a mechanism for the router adjacent to a failure to 95 rapidly invoke a repair path, which is minimally affected by any 96 subsequent re-convergence. This specification describes such a 97 mechanism which allows a router whose local link has failed to 98 forward traffic to a pre-computed alternate until the router installs 99 the new primary next-hops based upon the changed network topology. 100 The terminology used in this specification is given in [I-D.ietf- 101 rtgwg-ipfrr-framework]. The described mechanism assumes that routing 102 in the network is performed using a link-state routing protocol-- 103 OSPF[RFC2328] or ISIS [RFC1195] [RFC2966]. 105 When a local link fails, a router currently must signal the event to 106 its neighbors via the IGP, recompute new primary next-hops for all 107 affected prefixes, and only then install those new primary next-hops 108 into the forwarding plane. Until the new primary next-hops are 109 installed, traffic directed towards the affected prefixes is 110 discarded. This process can take seconds. 112 <-- 113 +-----+ 114 /------| S |--\ 115 / +-----+ \ 116 / 5 8 \ 117 / \ 118 +-----+ +-----+ 119 | E | | N_1 | 120 +-----+ +-----+ 121 \ / 122 \ \ 4 3 / / 123 \| \ / |/ 124 -+ \ +-----+ / +- 125 \---| D |---/ 126 +-----+ 128 Figure 1: Basic Topology 130 The goal of IP Fast-Reroute is to reduce failure reaction time to 10s 131 of milliseconds by using a pre-computed alternate next-hop, in the 132 event that the currently selected primary next-hop fails, so that the 133 alternate can be rapidly used when the failure is detected. A 134 network with this feature experiences less traffic loss and less 135 micro-looping of packets than a network without IPFRR. There are 136 cases where micro-looping is still a possibility since IPFRR coverage 137 varies but in the worst possible situation a network with IPFRR is 138 equivalent with respect to traffic convergence to a network without 139 IPFRR. 141 To clarify the behavior of IP Fast-Reroute, consider the simple 142 topology in Figure 1. When router S computes its shortest path to 143 router D, router S determines to use the link to router E as its 144 primary next-hop. Without IP Fast-Reroute, that link is the only 145 next-hop that router S computes to reach D. With IP Fast-Reroute, S 146 also looks for an alternate next-hop to use. In this example, S 147 would determine that it could send traffic destined to D by using the 148 link to router N_1 and therefore S would install the link to N_1 as 149 its alternate next-hop. At some later time, the link between router 150 S and router E could fail. When that link fails, S and E will be the 151 first to detect it. On detecting the failure, S will stop sending 152 traffic destined for D towards E via the failed link, and instead 153 send the traffic to S's pre-computed alternate next-hop, which is the 154 link to N_1, until a new SPF is run and its results are installed. 155 As with the primary next-hop, an alternate next-hop is computed for 156 each destination. The process of computing an alternate next-hop 157 does not alter the primary next-hop computed via a standard SPF. 159 If in the example of Figure 1, the link cost from N_1 to D increased 160 to 30 from 3, then N_1 would not be a loop-free alternate, because 161 the cost of the path from N_1 to D via S would be 17 while the cost 162 from N_1 directly to D would be 30. In real networks, we may often 163 face this situation. The existence of a suitable loop-free alternate 164 next-hop is topology dependent and the nature of the failure the 165 alternate is calculated for. 167 A neighbor N can provide a loop-free alternate (LFA) if and only if 169 Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D) 171 Equation 1: Loop-Free Criterion 173 A sub-set of loop-free alternate are downstream paths which must meet 174 a more restrictive condition that is applicable to more complex 175 failure scenarios: 177 Distance_opt(N, D) < Distance_opt(S, D) 179 Equation 2: Downstream Path Criterion 181 1.1 Failure Scenarios 183 The alternate next-hop can protect against a single link failure, a 184 single node failure, one or more shared risk link group failure, or a 185 combination of these. Whenever a failure occurs that is more 186 extensive than what the alternate was intended to protect, there is 187 the possibility of temporarily looping traffic (note again, that such 188 a loop would only last until the next complete SPF calculation). The 189 example where a node fails when the alternate provided only link 190 protection is illustrated below. If unexpected simultaneous failures 191 occur, then micro-looping may occur since the alternates are not pre- 192 computed to avoid the set of failed links. 194 If only link protection is provided and the node fails, it is 195 possible for traffic using the alternates to experience micro- 196 looping. This issue is illustrated in Figure 2. If Link(S->E) 197 fails, then the link-protecting alternate via N will work correctly. 198 However, if router E fails, then both S and N will detect a failure 199 and switch to their alternates. In this example, that would cause S 200 to redirect the traffic to N and N to redirect the traffic to S and 201 thus causing a forwarding loop. Such a scenario can arise because 202 the key assumption, that all other routers in the network are 203 forwarding based upon the shortest path, is violated because of a 204 second simultaneous correlated failure - another link connected to 205 the same primary neighbor. If there are not other protection 206 mechanisms a node failure is still a concern when only using link 207 protection. 209 <@@@ 210 @@@> 211 +-----+ +-----+ 212 | S |-------| N | 213 +-+---+ 5 +-----+ 214 | | 215 | 5 4 | | 216 | | | \|/ 217 \|/ | | 218 | +-----+ | 219 +----| E |---+ 220 +--+--+ 221 | 222 | 223 | 10 224 | 225 +--+--+ 226 | D | 227 +-----+ 229 Figure 2: Link-Protecting Alternates Causing Loop on Node Failure 231 Micro-looping of traffic via the alternates caused when a more 232 extensive failure than planned for can be prevented via selection of 233 only downstream paths as alternates. In Figure 2, S would be able to 234 use N as an alternate, but N could not use S; therefore N would have 235 no alternate and would discard the traffic, thus avoiding the micro- 236 loop. A micro-loop due to the use of alternates can be avoided by 237 using downstream paths because each router in the path to the 238 destination must be closer to the destination (according to the 239 topology prior to the failures). Although use of downstream paths 240 ensures that the micro-looping via alternates does not occur, such a 241 restriction can severely limit the coverage of alternates. 243 It may be desirable to find an alternate that can protect against 244 other correlated failures (of which node failure is a specific 245 instance). In the general case, these are handled by shared risk 246 link groups (SRLGs) where any links in the network can belong to the 247 SRLG. General SRLGs may add unacceptably to the computational 248 complexity of finding a loop-free alternate. 250 However, a sub-category of SRLGs is of interest and can be applied 251 only during the selection of an acceptable alternate. This sub- 252 category is to express correlated failures of links that are 253 connected to the same router. For example, if there are multiple 254 logical sub-interfaces on the same physical interface, such as VLANs 255 on an Ethernet interface, if multiple interfaces use the same 256 physical port because of channelization, or if multiple interfaces 257 share a correlated failure because they are on the same line-card. 258 This sub-category of SRLGs will be referred to as local-SRLGs. A 259 local-SRLG has all of its member links with one end connected to the 260 same router. Thus, router S could select a loop-free alternate which 261 does not use a link in the same local-SRLG as the primary next-hop. 262 The local-SRLGs belonging to E can be protected against via node- 263 protection; i.e. picking a loop-free node-protecting alternate. 265 Where SRLG protection is provided, it is in the context of the 266 particular OSPF or ISIS area, whose topology is used the SPF 267 computations to compute the loop-free alternates. If an SRLG 268 contains links in multiple areas, then separate SRLG-protecting 269 alternates would be required in each area that is traversed by the 270 affected traffic. 272 2. Applicability of Described Mechanisms 274 IP Fast Reroute mechanisms described in this memo cover intra-domain 275 routing only, with OSPF[RFC2328] or ISIS [RFC1195] [RFC2966] as the 276 IGP. Specifically, Fast Reroute for BGP inter-domain routing is not 277 part of this specification. 279 Certain aspects of OSPF inter-area routing behavior explained in 280 Section 6.2 and Appendix A impact the ability of the router 281 calculating the backup next-hops to assess traffic trajectories. In 282 order to avoid micro-looping and ensure required coverage, certain 283 constrains are applied to multi-area OSPF networks: 285 a. Loop-free alternates should not be used in the backbone area if 286 there are any virtual links configured unless, for each transit 287 area, there is a full mesh of virtual links between all ABRs in 288 that area. Loop-free alternates may be used in non-backbone 289 areas regardless of whether there are virtual links configured. 291 b. Loop-free alternates should not be used for inter-area routes in 292 an area that contains more than one alternate ABR. [RFC3509] 294 c. Loop-free alternates should not be used for AS External routes or 295 ASBR routes in a non-backbone area of a network where there 296 exists an ABR that is announced as an ASBR in multiple non- 297 backbone areas and there exists another ABR that is in at least 298 two of the same non-backbone areas. 300 d. Loop-free alternates should not be used in a non-backbone area of 301 a network for AS External routes where an AS External prefix is 302 advertised with the same type of external metric by multiple 303 ASBRs, which are in different non-backbone areas, with a 304 forwarding address of 0.0.0.0 or by one or more ASBRs with 305 forwarding addresses in multiple non-backbone areas when an ABR 306 exists simultaneously in two or more of those non-backbone areas. 308 3. Alternate Next-Hop Calculation 310 In addition to the set of primary next-hops obtained through a 311 shortest path tree (SPT) computation that is part of standard link- 312 state routing functionality, routers supporting IP Fast Reroute also 313 calculate a set of backup next hops that are engaged when a local 314 failure occurs. These backup next hops are calculated to provide 315 required type of protection (i.e. link-protecting and/or node- 316 protecting) and to guarantee that when the expected failure occurs, 317 forwarding traffic through them will not result in a loop. Such next 318 hops are called loop-free alternates or LFAs throughout this 319 specification. 321 In general, to be able to calculate the set of LFAs for a specific 322 destination D, a router needs to know the following basic pieces of 323 information: 325 o Shortest-path distance from the calculating router to the 326 destination (Distance_opt(S, D)) 328 o Shortest-path distance from the router's IGP neighbors to the 329 destination (Distance_opt(N, D)) 331 o Shortest path distance from the router's IGP neighbors to itself 332 (Distance_opt(N, S)) 334 o Distance_opt(S, D) is normally available from the regular SPF 335 calculation performed by the link-state routing protocols. 336 Distance_opt(N, D) and Distance_opt(N, S) can be obtained by 337 performing additional SPF calculations from the perspective of 338 each IGP neighbor (i.e. considering the neighbor's vertex as the 339 root of the SPT--called SPT(N) hereafter--rather than the 340 calculating router's one, called SPT(S)). 342 This specification defines a form of SRLG protection limited to those 343 SRLGs that include a link that the calculating router is directly 344 connected to. Information about local link SRLG membership is 345 manually configured. Information about remote link SRLG membership 346 is dynamically obtained using [RFC4205] or [RFC4203]. In order to 347 choose among all available LFAs that provide required SRLG protection 348 for a given destination, the calculating router needs to track the 349 set of SRLGs that the path through a specific IGP neighbor involves. 350 To do so, each node D in the network topology is associated with 351 SRLG_set(N, D), which is the set of SRLGs that would be crossed if 352 traffic to D was forwarded through N. To calculate this set, the 353 router initializes SRLG_set(N, N) for each of its IGP neighbors to be 354 empty. During the SPT(N) calculation, when a new vertex V is added 355 to the SPT, its SRLG_set(N, V) is set to the union of SRLG sets 356 associated with its parents, and the SRLG sets associated with the 357 links from V's parents to V. The union of the set of SRLG associated 358 with a candidate alternate next-hop and the SRLG_set(N, D) for the 359 neighbor reached via that candidate next-hop is used to determine 360 SRLG protection. 362 The following sections provide information required for calculation 363 of LFAs. Sections Section 3.1 through Section 3.4 define different 364 types of LFA conditions. Section 3.5 describes constrains imposed by 365 the IS-IS overload and OSPF stub router functionality. Section 3.6 366 defines the summarized algorithm for LFA calculation using the 367 definitions in the previous sections. 369 3.1 Basic Loop-free Condition 371 Alternate next hops used by implementations following this 372 specification MUST conform to at least the loop-freeness condition 373 stated above in Equation 1. This condition guarantees that 374 forwarding traffic to an LFA will not result in a loop after a link 375 failure. 377 Further conditions may be applied when determining link-protecting 378 and/or node-protecting alternate next-hops as described in Sections 379 Section 3.2 and Section 3.3. 381 3.2 Node-Protecting Alternate Next-Hops 383 For an alternate next-hop N to protect against node failure of a 384 primary neighbor E for destination D, N must be loop-free with 385 respect to both E and D. In other words, N's path to D must not go 386 through E. This is the case if Equation 3 is true, where N is the 387 neighbor providing a loop-free alternate. 389 Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D) 391 Equation 3: Criteria for a Node-Protecting Loop-Free Alternate 393 If Distance_opt(N,D) = Distance_opt(N, E) + Distance_opt(E, D), it is 394 possible that N has equal-cost paths and one of those could provide 395 protection against E's node failure. However, it is equally possible 396 that one of N's paths goes through E, and the calculating router has 397 no way to influence N's decision to use it. Therefore, it SHOULD be 398 assumed that an alternate next-hop does not offer node protection if 399 Equation 3 is not met. 401 3.3 Broadcast and NBMA Links 403 Verification of the link-protection property of a next hop in the 404 case of a broadcast link is more elaborate than for a point-to-point 405 link. This is because a broadcast link is represented as a pseudo- 406 node with zero-cost links connecting it to other nodes. 408 Because failure of an interface attached to a broadcast segment may 409 mean loss of connectivity of the whole segment, the condition 410 described for broadcast link protection is pessimistic and requires 411 that the alternate is loop-free with regard to the pseudo-node. 412 Consider the example in Figure 3. 414 +-----+ 15 415 | S |-------- 416 +-----+ | 417 | 5 | 418 | | 419 | 0 | 420 /----\ 0 5 +-----+ 421 | PN |-----| N | 422 \----/ +-----+ 423 | 0 | 424 | | 8 425 | 5 | 426 +-----+ 5 +-----+ 427 | E |----| D | 428 +-----+ +-----+ 430 Figure 3: Loop-Free Alternate that is Link-Protecting 432 In Figure 3, N offers a loop-free alternate which is link-protecting. 433 If the primary next-hop uses a broadcast link, then an alternate 434 SHOULD be loop-free with respect to that link's pseudo-node to 435 provide link protection. This requirement is described in Equation 4 436 below. 438 D_opt(N, D) < D_opt(N, pseudo) + D_opt(pseudo, D) 440 Equation 4: Loop-Free Link-Protecting Criterion for Broadcast Links 442 Because the shortest path from the pseudo-node goes through E, if a 443 loop-free alternate from a neighbor N is node-protecting, the 444 alternate will also be link-protecting unless the router S can only 445 reach the alternate neighbor N via the same pseudo-node. This can 446 occur because S will direct traffic away from the shortest path to 447 use an alternate. 449 To obtain link protection, it is necessary both that the path from 450 the selected alternate next-hop does not traverse the link of 451 interest and that the link used from S to reach that alternate next- 452 hop is not the link of interest. The latter can only occur with non- 453 point-to-point links. Therefore, if the primary next-hop is across a 454 broadcast or NBMA interface, it is necessary to consider link 455 protection during the alternate selection. Similar consideration of 456 the link from S to the selected alternate next-hop as well as the 457 path from the selected alternate next-hop is also necessary for SRLG 458 protection. 460 3.4 ECMP and Alternates 462 With equal-cost multi-path, a prefix may have multiple primary next- 463 hops that are used to forward traffic. When a particular primary 464 next-hop fails, alternate next-hops should be used to preserve the 465 traffic. These alternate next-hops may themselves also be primary 466 next-hops, but need not be. Other primary next-hops are not 467 guaranteed to provide protection against the failure scenarios of 468 concern. 470 20 L1 L3 3 471 [N]-----[ S ]--------[E3] 472 | | | 473 | 5 | L2 | 474 20 | | | 475 | --------- | 2 476 | 5 | | 5 | 477 | [E1] [E2]------| 478 | | | 479 | 10 | 10 | 480 |---[A] [B] 481 | | 482 2 |--[D]--| 2 484 Figure 4: ECMP where Primary Next-Hops Provide Limited Protection 486 In Figure 4 S has three primary next-hops to reach D; these are L2 to 487 E1, L2 to E2 and L3 to E3. The primary next-hop L2 to E1 can obtain 488 link and node protection from L3 to E3, which is one of the other 489 primary next-hops; L2 to E1 cannot obtain link protection from the 490 other primary next-hop L2 to E2. Similarly, the primary next-hop L2 491 to E2 can only get node protection from L2 to E1 and can only get 492 link protection from L3 to E3. The third primary next-hop L3 to E3 493 can obtain link and node protection from L2 to E1 and from L2 to E2. 494 It is possible for both the primary next-hop L2 to E2 and the primary 495 next-hop L2 to E1 to obtain an alternate next-hop that provides both 496 link and node protection by using L1. 498 Alternate next-hops are determined for each primary next-hop 499 separately. As with alternate selection in the non-ECMP case, these 500 alternate next-hops should maximize the coverage of the failure 501 cases. 503 3.5 Interactions with ISIS Overload, RFC 3137 and Costed Out Links 505 As described in [RFC3137], there are cases where it is desirable not 506 to have a router used as a transit node. For those cases, it is also 507 desirable not to have the router used on an alternate path. 509 For computing an alternate, a router MUST NOT use an alternate next- 510 hop that is along a link whose cost or reverse cost is LSInfinity 511 (for OSPF) or the maximum cost (for ISIS) or which has the overload 512 bit set (for ISIS). For a broadcast link, the reverse cost 513 associated with a potential alternate next-hop is the cost towards 514 the pseudo-node advertised by the next-hop router. For point-to- 515 point links, if a specific link from the next-hop router cannot be 516 associated with a particular link, then the reverse cost considered 517 is that of the minimum cost link from the next-hop router back to S. 519 In the case of OSPF, if all links from router S to a neighbor N_i 520 have a reverse cost of LSInfinity, then router S MUST NOT use N_i as 521 an alternate. 523 Similarly in the case of ISIS, if N_i has the overload bit set, then 524 S MUST NOT consider using N_i as an alternate. 526 This preserves the desired behavior of diverting traffic away from a 527 router which is following [RFC3137] and it also preserves the desired 528 behavior when an operator sets the cost of a link to LSInfinity for 529 maintenance which is not permitting traffic across that link unless 530 there is no other path. 532 If a link or router which is costed out was the only possible 533 alternate to protect traffic from a particular router S to a 534 particular destination, then there should be no alternate provided 535 for protection. 537 3.5.1 Interactions with ISIS Link Attributes 539 [I-D.ietf-isis-link-attr] describes several flags whose interactions 540 with LFAs needs to be defined. A router SHOULD NOT specify the 541 "local protection available" flag as a result of having LFAs. A 542 router SHOULD NOT use an alternate next-hop that is along a link for 543 which the link has been advertised with the attribute "link excluded 544 from local protection path" or with the attribute "local mainenance 545 required". 547 3.6 Selection Procedure 549 A router supporting this specification SHOULD attempt to select at 550 least one loop-free alternate next-hop for each primary next-hop used 551 for a given prefix. A router MAY decide to not use an available 552 loop-free alternate next-hop. A reason for such a decision might be 553 that the loop-free alternate next-hop does not provide protection for 554 the failure scenario of interest. 556 The alternate selection should maximize the coverage of the failure 557 cases. 559 When calculating alternate next-hops, the calculating router S 560 applies the following rules. 562 1. S SHOULD select a loop-free node-protecting alternate next-hop, 563 if one is available. If no loop-free node-protecting alternate 564 is available, then S MAY select a loop-free link-protecting 565 alternate. 567 2. If S has a choice between a loop-free link-protecting node- 568 protecting alternate and a loop-free node-protecting alternate 569 which is not link-protecting, S SHOULD select a loop-free node- 570 protecting alternate which is also link-protecting. This can 571 occur as explained in Section 3.3. 573 3. If S has multiple primary next-hops, then S SHOULD select as a 574 loop-free alternate either one of the other primary next-hops or 575 a loop-free node-protecting alternate if available. If no loop- 576 free node-protecting alternate is available and no other primary 577 next-hop can provide link-protection, then S SHOULD select a 578 loop-free link-protecting alternate. 580 4. Implementations SHOULD support a mode where other primary next- 581 hops satisfying the basic loop-free condition and providing at 582 least a minimal level of protection are preferred over any non- 583 primary alternates. This mode is provided to allow the 584 administrator to preserve traffic patterns based on regular ECMP 585 behavior. 587 Following the above rules maximizes the level of protection and use 588 of primary (ECMP) next-hops. 590 Each next-hop is associated with a set of non-mutually-exclusive 591 characteristics based on whether it is used as a primary next-hop to 592 a particular destination D, and the type of protection it can provide 593 relative to a specific primary next-hop E: 595 Primary Path - The next-hop is used by S as primary. 597 Loop-Free Node-Protecting Alternate - This next-hop satisfies 598 Equation 1 and Equation 3. The path avoids S, S's primary 599 neighbor E, and the link from S to E. 601 Loop-Free Link-Protecting Alternate - This next-hop satisfies 602 Equation 1 but not Equation 3. If the primary next-hop uses a 603 broadcast link, then this next-hop satisfies Equation 4. 605 An alternate path may also provide none, some or complete SRLG 606 protection as well as node and link or link protection. For 607 instance, a link may belong to two SRLGs G1 and G2. The alternate 608 path might avoid other links in G1 but not G2, in which case the 609 alternate would only provide partial SRLG protection. 611 Below is an algorithm that can be used to calculate loop-free 612 alternate next-hops. The algorithm is given for informational 613 purposes and implementations are free to use any other algorithm as 614 long as it satisfies the rules described above. 616 The following procedure describes how to select an alternate next- 617 hop. The procedure is described to determine alternate next-hops to 618 use to reach each router in the topology. Prefixes that are 619 advertised by a single router can use the alternate next-hop computed 620 for the router to which they are attached. The same procedure can be 621 used to reach a prefix that is advertised by more than one router 622 when the logical topological transformation described in Section 6.1 623 is used. 625 S is the computing router and has candidate next-hops H_1 through 626 H_k. N_i and N_j are used to refer to neighbors of S. For a next-hop 627 to be a candidate, the next-hop must be associated with a bi- 628 directional link, as is determined by the IGP. For a particular 629 destination router D, let S have already computed D_opt(S, D), and 630 for each neighbor N_i, D_opt(N_i, D), D_opt(N_i, S), and D_opt(N_i, 631 N_j), the distance from N_i to each other neighbor N_j, and the set 632 of SRLGs traversed by the path D_opt(N_i, D). S SHOULD follow the 633 below procedure for every primary next-hop selected to reach D. This 634 set of primary next-hops is represented P_1 to P_p. This procedure 635 finds the alternate next-hop(s) for P_i. 637 First, initialize the alternate information for P_i as follows: 639 P_i.alt_next_hops = {} 640 P_i.alt_type = NONE P_i.alt_link-protect = FALSE 641 P_i.alt_node-protect = FALSE 642 P_i.alt_srlg-protect = {} 644 For each candidate next-hop H_h, 646 1. Initialize variables as follows: 648 cand_type = NONE 649 cand_link-protect = FALSE 650 cand_node-protect = FALSE 651 cand_srlg-protect = {} 653 2. If H_h is P_i, skip it and continue to the next candidate next- 654 hop. 656 3. If H_h.link is administratively allowed to be used as an 657 alternate, 659 and the cost of H_h.link less than the maximum, 660 and the reverse cost of H_h is less than the maximum, 661 and H_h.neighbor is not overloaded (for ISIS), 662 and H_h.link is bi-directional, 664 then H_h can be considered as an alternate. Otherwise, skip it 665 and continue to the next candidate next-hop. 667 4. If D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S, 668 D), then H_h is not loop-free. Skip it and continue to the next 669 candidate next-hop. 671 5. cand_type = LOOP-FREE. 673 6. If H_h is a primary next-hop, set cand_type to PRIMARY. 675 7. If H_h.link is not P_i.link, set can_link-protect to TRUE. 677 8. If D_opt(H_h.neighbor, D) < D_opt(H_h.neighbor, P_i.neighbor) + 678 D_opt(P_i.neighbor, D), set cand_node-protect to TRUE. 680 9. If the router considers SRLGs, then set the cand_srlg-protect to 681 the set of SRLGs traversed on the path from S via P_i to 682 P_i.neighbor. Remove the set of SRLGs to which H_h belongs from 683 cand_srlg-protect. Remove from cand_srlg-protect the set of 684 SRLGs traversed on the path from H_h.neighbor to D. Now 685 cand_srlg-protect holds the set of SRLGs to which P_i belongs 686 and that are not traversed on the path from S via H_h to D. 688 10. If cand_type is PRIMARY, the router prefers other primary next- 689 hops for use as the alternate, and the P_i.alt_type is not 690 PRIMARY, goto Step 18. 692 11. If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE, 693 goto Paragraph 18. 695 12. If cand_link-protect is TRUE and P_i.alt_link-protect is FALSE, 696 goto Step 18. 698 13. If cand_srlg-protect has a better set of SRLGs than 699 P_i.alt_srlg-protect, goto Step 18. 701 14. If cand_srlg-protect is different from P_i.alt_srlg-protect, 702 then select between H_h and P_i.alt_next_hops based upon 703 distance, IP addresses, or any router-local tie-breaker. If H_h 704 is preferred, then goto to Step 18. Otherwise, skip H_h and 705 continue to the next candidate next-hop. 707 15. Based upon the alternate types, the alternate distances, IP 708 addresses, or other tie-breakers, decide if H_h is preferred to 709 P_i.alt_next_hops. If so, goto Step 18. 711 16. Decide if P_i.alt_next_hops is preferred to H_h. If so, then 712 skip H_h and continue to the next candidate next-hop. 714 17. Add H_h into P_i.alt_next_hops. Set P_i.alt_type to the better 715 type of H_h.alt_type and P_i.alt_type. Continue to the next 716 candidate next-hop. 718 18. Replace the P_i alternate next-hop set with H_h as follows: 720 P_i.alt_next_hops = {H_h} 721 P_i.alt_type = cand_type 722 P_i.alt_link-protect = cand_link-protect 723 P_i.alt_node-protect = cand_node-protect 724 P_i.alt_srlg-protect = cand_srlg-protect 726 Continue to the next candidate next-hop. 728 4. Using an Alternate 730 If an alternate next-hop is available, the router redirects traffic 731 to the alternate next-hop in case of a primary next-hop failure as 732 follows. 734 When a next-hop failure is detected via a local interface failure or 735 other failure detection mechanisms (see [FRAMEWORK]), the router 736 SHOULD: 738 1. Remove the primary next-hop associated with the failure. 740 2. Install the loop-free alternate calculated for the failed next- 741 hop if it is not already installed (e.g. the alternate is also a 742 primary next-hop). 744 Note that the router MAY remove other next-hops if it believes (via 745 SRLG analysis) that they may have been affected by the same failure, 746 even if it is not visible at the time of failure detection. 748 The alternate next-hop MUST be used only for traffic types which are 749 routed according to the shortest path. Multicast traffic is 750 specifically out of scope for this specification. 752 4.1 Terminating Use of Alternate 754 A router MUST limit the amount of time an alternate next-hop is used 755 after the primary next-hop has become unavailable. This ensures that 756 the router will start using the new primary next-hops. It ensures 757 that all possible transient conditions are removed and the network 758 converges according to the deployed routing protocol. 760 A router that implements [I-D.ietf-rtgwg-microloop-analysis] SHOULD 761 follow the rules given there for terminating the use of an alternate. 763 It is desirable to avoid micro-forwarding loops involving S. An 764 example illustrating the problem is given in Figure 5. If the link 765 from S to E fails, S will use N1 as an alternate and S will compute 766 N2 as the new primary next-hop to reach D. If S starts using N2 as 767 soon as S can compute and install its new primary, it is probable 768 that N2 will not have yet installed its new primary next-hop. This 769 would cause traffic to loop and be dropped until N2 has installed the 770 new topology. This can be avoided by S delaying its installation and 771 leaving traffic on the alternate next-hop. 773 +-----+ 774 | N2 |-------- | 775 +-----+ 1 | \|/ 776 | | 777 | +-----+ @@> +-----+ 778 | | S |---------| N1 | 779 10 | +-----+ 10 +-----+ 780 | | | 781 | 1 | | | 782 | | \|/ 10 | 783 | +-----+ | | 784 | | E | | \|/ 785 | +-----+ | 786 | | | 787 | 1 | | | 788 | | \|/ | 789 | +-----+ | 790 |----| D |-------------- 791 +-----+ 793 Figure 5: Example where Continued Use of Alternate is Desirable 795 This is an example of a case where the new primary is not a loop-free 796 alternate before the failure and therefore may have been forwarding 797 traffic through S. This will occur when the path via a previously 798 upstream node is shorter than the the path via a loop-free alternate 799 neighbor. In these cases, it is useful to give sufficient time to 800 ensure that the new primary neighbor and other nodes on the new 801 primary path have switched to the new route. 803 If the newly selected primary was loop-free before the failure, then 804 it is safe to switch to that new primary immediately; the new primary 805 wasn't dependent on the failure and therefore its path will not have 806 changed. 808 Given that there is an alternate providing appropriate protection and 809 while the assumption of a single failure holds, it is safe to delay 810 the installation of the new primaries; this will not create 811 forwarding loops because the alternate's path to the destination is 812 known to not go via S or the failed element and will therefore not be 813 affected by the failure. 815 An implementation SHOULD continue to use the alternate next-hops for 816 packet forwarding even after the new routing information is available 817 based on the new network topology. The use of the alternate next- 818 hops for packet forwarding SHOULD terminate: 820 a. if the new primary next-hop was loop-free prior to the topology 821 change, or 823 b. if a configured hold-down, which represents a worst-case bound on 824 the length of the network convergence transition, has expired, or 826 c. if notification of an unrelated topological change in the network 827 is received. 829 5. Requirements on LDP Mode 831 Since LDP traffic will follow the path specified by the IGP, it is 832 also possible for the LDP traffic to follow the loop-free alternates 833 indicated by the IGP. To do so, it is necessary for LDP to have the 834 appropriate labels available for the alternate so that the 835 appropriate out-segments can be installed in the forwarding plane 836 before the failure occurs. 838 This means that a Label Switched Router (LSR) running LDP must 839 distribute its labels for the FECs it can provide to all its 840 neighbors, regardless of whether or not they are upstream. 841 Additionally, LDP must be acting in liberal label retention mode so 842 that the labels which correspond to neighbors that aren't currently 843 the primary neighbor are stored. Similarly, LDP should be in 844 downstream unsolicited mode, so that the labels for the FEC are 845 distributed other than along the SPT. 847 If these requirements are met, then LDP can use the loop-free 848 alternates without requiring any targeted sessions or signaling 849 extensions for this purpose. 851 6. Routing Aspects 853 6.1 Multi-Homed Prefixes 855 An SPF-like computation is run for each topology, which corresponds 856 to a particular OSPF area or ISIS level. The IGP needs to determine 857 loop-free alternates to multi-homed routes. Multi-homed routes occur 858 for routes obtained from outside the routing domain by multiple 859 routers, for subnets on links where the subnet is announced from 860 multiple ends of the link, and for routes advertised by multiple 861 routers to provide resiliency. 863 Figure 6 demonstrates such a topology. In this example, the shortest 864 path to reach the prefix p is via E. The prefix p will have the link 865 to E as its primary next-hop. If the alternate next-hop for the 866 prefix p is simply inherited from the router advertising it on the 867 shortest path to p, then the prefix p's alternate next-hop would be 868 the link to C. This would provide link protection, but not the node 869 protection that is possible via A. 871 5 +---+ 4 +---+ 5 +---+ 872 ------| S |------| A |-----| B | 873 | +---+ +---+ +---+ 874 | | | 875 | 5 | 5 | 876 | | | 877 +---+ 5 +---+ 5 7 +---+ 878 | C |---| E |------ p -------| F | 879 +---+ +---+ +---+ 881 Figure 6: Multi-homed prefix 883 To determine the best protection possible, the prefix p can be 884 treated in the SPF computations as a node with uni-directional links 885 to it from those routers that have advertised the prefix. Such a 886 node need never have its links explored, as it has no out-going 887 links. 889 If there exist multiple multi-homed prefixes that share the same 890 connectivity and the difference in metrics to those routers, then a 891 single node can be used to represent the set. For instance, if in 892 Figure 6 there were another prefix X that was connected to E with a 893 metric of 1 and to F with a metric of 3, then that prefix X could use 894 the same alternate next-hop as was computed for prefix p. 896 A router SHOULD compute the alternate next-hop for an IGP multi-homed 897 prefix by considering alternate paths via all routers that have 898 announced that prefix. 900 6.2 OSPF 902 OSPF introduces certain complications because it is possible for the 903 traffic path to exit an area and then re-enter that area. This can 904 occur whenever a router considers the same route from multiple areas. 905 There are several cases where issues such as this can occur. They 906 happen when another area permits a shorter path to connect two ABRs 907 than is available in the area where the LFA has been computed. To 908 clarify, an example topology is given in Appendix A. 910 a. Virtual Links: These allow paths to leave the backbone area and 911 traverse the transit area. The path provided via the transit 912 area can exit via any ABR. The path taken is not the shortest 913 path determined by doing an SPF in the backbone area. 915 b. Alternate ABR[RFC3509]: When an ABR is not connected to the 916 backbone, it considers the inter-area summaries from multiple 917 areas. The ABR A may determine to use area 2 but that path could 918 traverse another alternate ABR B that determines to use area 1. 919 This can lead to scenarios similar to that illustrated in 920 Figure 7. 922 c. ASBR Summaries: An ASBR may itself be an ABR and can be announced 923 into multiple areas. This presents other ABRs with a decision as 924 to which area to use. This is the example illustrated in 925 Figure 7. 927 d. AS External Prefixes: A prefix may be advertised by multiple 928 ASBRs in different areas and/or with multiple forwarding 929 addresses that are in different areas, which are connected via at 930 least one common ABR. This presents such ABRs with a decision as 931 to which area to use to reach the prefix. 933 6.2.1 OSPF External Routing 935 When a forwarding address is set in an OSPF AS-external LSA, all 936 routers in the network calculate their next-hops for the external 937 prefix by doing a lookup for the forwarding address in the routing 938 table, rather than using the next-hops calculated for the ASBR. In 939 this case, the alternate next-hops SHOULD be computed by selecting 940 among the alternate paths to the forwarding link(s) instead of among 941 alternate paths to the ASBR. 943 6.3 BGP Next-Hop Synchronization 945 Typically BGP prefixes are advertised with AS exit routers router-id, 946 and AS exit routers are reached by means of IGP routes. BGP resolves 947 its advertised next-hop to the immediate next-hop by potential 948 recursive lookups in the routing database. IP Fast-Reroute computes 949 the alternate next-hops to all IGP destinations, which include 950 alternate next-hops to the AS exit router's router-id. BGP simply 951 inherits the alternate next-hop from IGP. The BGP decision process 952 is unaltered; BGP continues to use the IGP optimal distance to find 953 the nearest exit router. MBGP routes do not need to copy the 954 alternate next hops. 956 It is possible to provide ASBR protection if BGP selected selected a 957 set of IGP next-hops and allowed the IGP to determine the primary and 958 alternate next-hops as if the BGP route were a multi-homed prefix. 959 This is for future study. 961 6.4 Multicast Considerations 963 Multicast traffic is out of scope for this specification of IP Fast- 964 Reroute. The alternate next-hops SHOULD not be used for multi-cast 965 RPF checks. 967 7. Security Considerations 969 The mechanism described in this document does not modify any routing 970 protocol messages, and hence no new threats related to packet 971 modifications or replay attacks are introduced. Traffic to certain 972 destinations can be temporarily routed via next-hop routers that 973 would not be used with the same topology change if this mechanism 974 wasn't employed. However, these next-hop routers can be used anyway 975 when a different topological change occurs, and hence this can't be 976 viewed as a new security threat. 978 8. IANA Considerations 980 This document requires no IANA considerations. 982 9. References 983 9.1 Normative References 985 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 986 dual environments", RFC 1195, December 1990. 988 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 990 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 991 B. Thomas, "LDP Specification", RFC 3036, January 2001. 993 9.2 Informative References 995 [I-D.ietf-isis-link-attr] 996 Vasseur, J. and S. Previdi, "Definition of an IS-IS Link 997 Attribute sub-TLV", draft-ietf-isis-link-attr-01 (work in 998 progress), May 2005. 1000 [I-D.ietf-rtgwg-ipfrr-framework] 1001 Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1002 draft-ietf-rtgwg-ipfrr-framework-05 (work in progress), 1003 March 2006. 1005 [I-D.ietf-rtgwg-microloop-analysis] 1006 Zinin, A., "Analysis and Minimization of Microloops in 1007 Link-state Routing Protocols", 1008 draft-ietf-rtgwg-microloop-analysis-01 (work in progress), 1009 October 2005. 1011 [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix 1012 Distribution with Two-Level IS-IS", RFC 2966, 1013 October 2000. 1015 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 1016 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 1017 June 2001. 1019 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1020 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1021 Tunnels", RFC 3209, December 2001. 1023 [RFC3509] Zinin, A., Lindem, A., and D. Yeung, "Alternative 1024 Implementations of OSPF Area Border Routers", RFC 3509, 1025 April 2003. 1027 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 1028 of Generalized Multi-Protocol Label Switching (GMPLS)", 1029 RFC 4203, October 2005. 1031 [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to 1032 Intermediate System (IS-IS) Extensions in Support of 1033 Generalized Multi-Protocol Label Switching (GMPLS)", 1034 RFC 4205, October 2005. 1036 Authors' Addresses 1038 Alia K. Atlas (editor) 1039 Google, Inc. 1040 1600 Amphitheatre Parkway 1041 Mountain View, CA 94043 1042 USA 1044 Email: akatlas@alum.mit.edu 1046 Alex Zinin (editor) 1047 Alcatel 1048 701 E Middlefield Rd. 1049 Mountain View, CA 94043 1050 USA 1052 Email: zinin@psg.com 1054 Raveendra Torvi 1055 Avici Systems, Inc. 1056 101 Billerica Avenue 1057 N. Billerica, MA 01862 1058 USA 1060 Phone: +1 978 964 2026 1061 Email: rtorvi@avici.com 1063 Gagan Choudhury 1064 AT&T 1065 200 Laurel Avenue, Room D5-3C21 1066 Middletown, NJ 07748 1067 USA 1069 Phone: +1 732 420-3721 1070 Email: gchoudhury@att.com 1071 Christian Martin 1072 iPath Technologies 1074 Email: chris@ipath.net 1076 Brent Imhoff 1077 Juniper Networks 1078 1194 North Mathilda 1079 Sunnyvale, CA 94089 1080 USA 1082 Phone: +1 314 378 2571 1083 Email: bimhoff@planetspork.com 1085 Don Fedyk 1086 Nortel Networks 1087 600 Technology Park 1088 Billerica, MA 01821 1089 USA 1091 Phone: +1 978 288 3041 1092 Email: dwfedyk@nortelnetworks.com 1094 Appendix A. OSPF Example Where LFA Based on Local Area Topology is 1095 Insufficient 1097 This appendix provides an example scenario where the local area 1098 topology does not suffice to determine that an LFA is available. As 1099 described in Section 6.2, one problem scenario is for ASBR summaries 1100 where the ASBR is available in two areas via intra-area routes and 1101 there is at least one ABR or alternate ABR that is in both areas. 1102 The following Figure 7 illustrates this case. 1104 5 1105 [ F ]-----------[ C ] 1106 | | 1107 | | 5 1108 20 | 5 | 1 1109 | [ N ]-----[ A ]*****[ F ] 1110 | | # * 1111 | 40 | # 50 * 2 1112 | | 5 # 2 * 1113 | [ S ]-----[ B ]*****[ G ] 1114 | | * 1115 | 5 | * 15 1116 | | * 1117 | [ E ] [ H ] 1118 | | * 1119 | 5 | * 10** 1120 | | * 1121 |---[ X ]-----[ASBR] 1122 5 1124 ---- Link in Area 1 1125 **** Link in Area 2 1126 #### Link in Backbone Area 0 1128 Figure 7: Topology with Multi-area ASBR Causing Area Transiting 1130 In Figure 7, the ASBR is also an ABR and is announced into both area 1131 1 and area 2. A and B are both ABRs that are also connected to the 1132 backbone area. S determines that N can provide a loop-free alternate 1133 to reach the ASBR. N's path goes via A. A also sees an intra-area 1134 route to ASBR via Area 2; the cost of the path in area 2 is 30, which 1135 is less than 35, the cost of the path in area 1. Therefore, A uses 1136 the path from area 2 and directs traffic to F. The path from F in 1137 area 2 goes to B. B is also an ABR and learns the ASBR from both 1138 areas 1 and area 2; B's path via area 1 is shorter (cost 20) than B's 1139 path via area 2 (cost 25). Therefore, B uses the path from area 1 1140 that connects to S. 1142 Intellectual Property Statement 1144 The IETF takes no position regarding the validity or scope of any 1145 Intellectual Property Rights or other rights that might be claimed to 1146 pertain to the implementation or use of the technology described in 1147 this document or the extent to which any license under such rights 1148 might or might not be available; nor does it represent that it has 1149 made any independent effort to identify any such rights. Information 1150 on the procedures with respect to rights in RFC documents can be 1151 found in BCP 78 and BCP 79. 1153 Copies of IPR disclosures made to the IETF Secretariat and any 1154 assurances of licenses to be made available, or the result of an 1155 attempt made to obtain a general license or permission for the use of 1156 such proprietary rights by implementers or users of this 1157 specification can be obtained from the IETF on-line IPR repository at 1158 http://www.ietf.org/ipr. 1160 The IETF invites any interested party to bring to its attention any 1161 copyrights, patents or patent applications, or other proprietary 1162 rights that may cover technology that may be required to implement 1163 this standard. Please address the information to the IETF at 1164 ietf-ipr@ietf.org. 1166 Disclaimer of Validity 1168 This document and the information contained herein are provided on an 1169 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1170 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1171 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1172 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1173 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1174 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1176 Copyright Statement 1178 Copyright (C) The Internet Society (2006). This document is subject 1179 to the rights, licenses and restrictions contained in BCP 78, and 1180 except as set forth therein, the authors retain all their rights. 1182 Acknowledgment 1184 Funding for the RFC Editor function is currently provided by the 1185 Internet Society.