idnits 2.17.00 (12 Aug 2021) /tmp/idnits37449/draft-ietf-rtgwg-multihomed-prefix-lfa-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The 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 abstract seems to contain references ([RFC5286]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5286, but the abstract doesn't seem to directly say this. It does mention RFC5286 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 395 has weird spacing: '... 2a. If not, ...' (Using the creation date from RFC5286, updated by this document, for RFC5378 checks: 2004-09-08) -- 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 (December 1, 2017) is 1632 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) -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group P. Sarkar, Ed. 3 Internet-Draft Arrcus, Inc. 4 Updates: 5286 (if approved) S. Hegde 5 Intended status: Standards Track Juniper Networks, Inc. 6 Expires: June 4, 2018 U. Chunduri, Ed. 7 Huawei Technologies 8 J. Tantsura 9 Individual 10 H. Gredler 11 RtBrick, Inc. 12 December 1, 2017 14 LFA selection for Multi-Homed Prefixes 15 draft-ietf-rtgwg-multihomed-prefix-lfa-04 17 Abstract 19 This document shares experience gained from implementing algorithms 20 to determine Loop-Free Alternates for multi-homed prefixes. In 21 particular, this document provides explicit inequalities that can be 22 used to evaluate neighbors as a potential alternates for multi-homed 23 prefixes. It also provides detailed criteria for evaluating 24 potential alternates for external prefixes advertised by OSPF ASBRs. 25 This documents updates and expands some of the "Routing Aspects" as 26 specified in Section 6 of [RFC5286]. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 4, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. LFA inequalities for MHPs . . . . . . . . . . . . . . . . . . 4 70 3. LFA selection for the multi-homed prefixes . . . . . . . . . 4 71 3.1. Improved coverage with simplified approach to MHPs . . . 6 72 3.2. IS-IS ATT Bit considerations . . . . . . . . . . . . . . 8 73 4. LFA selection for the multi-homed external prefixes . . . . . 8 74 4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.2.1. Rules to select alternate ASBR . . . . . . . . . . . 9 77 4.2.2. Multiple ASBRs belonging different area . . . . . . . 10 78 4.2.3. Type 1 and Type 2 costs . . . . . . . . . . . . . . . 11 79 4.2.4. RFC1583compatibility is set to enabled . . . . . . . 11 80 4.2.5. Type 7 routes . . . . . . . . . . . . . . . . . . . . 11 81 4.2.6. Inequalities to be applied for alternate ASBR 82 selection . . . . . . . . . . . . . . . . . . . . . . 11 83 4.2.6.1. Forwarding address set to non-zero value . . . . 11 84 4.2.6.2. ASBRs advertising type1 and type2 cost . . . . . 12 85 5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 13 86 5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 13 87 5.2. Multi Topology Considerations . . . . . . . . . . . . . . 14 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 89 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 93 9.2. Informative References . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 The use of Loop-Free Alternates (LFA) for IP Fast Reroute is 99 specified in [RFC5286]. Section 6.1 of [RFC5286] describes a method 100 to determine loop-free alternates for a multi-homed prefixes (MHPs). 101 This document describes a procedure using explicit inequalities that 102 can be used by a computing router to evaluate a neighbor as a 103 potential alternate for a multi-homed prefix. The results obtained 104 are equivalent to those obtained using the method described in 105 Section 6.1 of [RFC5286]. However, some may find this formulation 106 useful. 108 Section 6.3 of [RFC5286] discusses complications associated with 109 computing LFAs for multi-homed prefixes in OSPF. This document 110 provides detailed criteria for evaluating potential alternates for 111 external prefixes advertised by OSPF ASBRs, as well as explicit 112 inequalities. 114 This document also provide clarifications, additional considerations 115 to [RFC5286], to address a few coverage and operational observations. 116 These observations are in the area of handling IS-IS attach (ATT) bit 117 in Level-1 (L1) area, links provisioned with MAX_METRIC for traffic 118 engineering (TE) purposes and in the area of Multi Topology (MT) IGP 119 deployments. These are elaborated in detail in Section 3.2 and 120 Section 5. 122 1.1. Acronyms 124 AF - Address Family 126 ATT - IS-IS Attach Bit 128 ECMP - Equal Cost Multi Path 130 IGP - Interior Gateway Protocol 132 IS-IS - Intermediate System to Intermediate System 134 LSP - IS-IS Link State PDU 136 OSPF - Open Shortest Path First 138 MHP - Multi-homed Prefix 140 MT - Multi Topology 142 SPF - Shortest Path First PDU 144 2. LFA inequalities for MHPs 146 This document proposes the following set of LFA inequalities for 147 selecting the most appropriate LFAs for multi-homed prefixes (MHPs). 148 They can be derived from the inequalities in [RFC5286] combined with 149 the observation that D_opt(N,P) = Min (D_opt(N,PO_i) + cost(PO_i,P)) 150 over all PO_i 152 Link-Protection: 153 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 154 D_opt(S,PO_best) + cost(PO_best,P) 156 Link-Protection + Downstream-paths-only: 157 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 159 Node-Protection: 160 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 161 D_opt(E,PO_best) + cost(PO_best,P) 163 Where, 164 P - The multi-homed prefix being evaluated for 165 computing alternates 166 S - The computing router 167 N - The alternate router being evaluated 168 E - The primary next-hop on shortest path from S to 169 prefix P. 170 PO_i - The specific prefix-originating router being 171 evaluated. 172 PO_best - The prefix-originating router on the shortest path 173 from the computing router S to prefix P. 174 Cost (X,P) - Cost of reaching the prefix P from prefix 175 originating node X. 176 D_opt(X,Y) - Distance on the shortest path from node X to node 177 Y. 179 Figure 1: LFA inequalities for MHPs 181 3. LFA selection for the multi-homed prefixes 183 To compute a valid LFA for a given multi-homed prefix P, a computing 184 router S MUST follow one of the appropriate procedures below, for 185 each alternate neighbor N. 187 Link-Protection : 188 ================= 189 1. If alternate neighbor N is also prefix-originator of P, 190 1.a. Select N as a LFA for prefix P (irrespective of 191 the metric advertised by N for the prefix P). 192 2. Else, evaluate the link-protecting LFA inequality for P with 193 the N as the alternate neighbor. 194 2.a. If LFA inequality condition is met, 195 select N as a LFA for prefix P. 196 2.b. Else, N is not a LFA for prefix P. 198 Link-Protection + Downstream-paths-only : 199 ========================================= 200 1. Evaluate the link-protecting + downstream-only LFA inequality 201 for P with the N as the alternate neighbor. 202 1.a. If LFA inequality condition is met, 203 select N as a LFA for prefix P. 204 1.b. Else, N is not a LFA for prefix P. 206 Node-Protection : 207 ================= 208 1. If alternate neighbor N is also prefix-originator of P, 209 1.a. Select N as a LFA for prefix P (irrespective of 210 the metric advertised by N for the prefix P). 211 2. Else, evaluate the appropriate node-protecting LFA inequality 212 for P with the N as the alternate neighbor. 213 2.a. If LFA inequality condition is met, 214 select N as a LFA for prefix P. 215 2.b. Else, N is not a LFA for prefix P. 217 Figure 2: Rules for selecting LFA for MHPs 219 In case an alternate neighbor N is also one of the prefix-originators 220 of prefix P, N MAY be selected as a valid LFA for P since being a 221 prefix-originator it is guaranteed that N will not loop back packets 222 destined for prefix P to computing router S. 224 However, if N is not a prefix-originator of P, the computing router 225 SHOULD evaluate one of the corresponding LFA inequalities, as 226 mentioned in Figure 1, once for each remote node that originated the 227 prefix. In case the inequality is satisfied by the neighbor N router 228 S MUST choose neighbor N, as one of the valid LFAs for the prefix P. 230 When computing a downstream-only LFA, in addition to being a prefix- 231 originator of P, router N MUST also satisfy the downstream-only LFA 232 inequality specified in Figure 1. 234 For more specific rules please refer to the later sections of this 235 document. 237 3.1. Improved coverage with simplified approach to MHPs 239 LFA base specification [RFC5286] Section 6.1 recommends that a router 240 compute the alternate next-hop for an IGP multi-homed prefix by 241 considering alternate paths via all routers that have announced that 242 prefix and the same has been elaborated with appropriate inequalities 243 in the above section. However, [RFC5286] Section 6.1 also allows for 244 the router to simplify the multi-homed prefix calculation by assuming 245 that the MHP is solely attached to the router that was its pre- 246 failure optimal point of attachment, at the expense of potentially 247 lower coverage. If an implementation chooses to simplify the multi- 248 homed prefix calculation by assuming that the MHP is solely attached 249 to the router that was its pre-failure optimal point of attachment, 250 the procedure described in this memo can potentially improve coverage 251 for equal cost multi path (ECMP) MHPs without incurring extra 252 computational cost. 254 The approach specified in [RFC5286] Section 6.1 last paragraph, is to 255 simplify the MHP as solely attached to the router that was its pre- 256 failure optimal point of attachment; though it is a scalable approach 257 and simplifies computation, [RFC5286] notes this MAY result in little 258 less coverage. 260 This document improves the above approach to provide loop-free 261 alternatives without any additional cost for ECMP MHPs as described 262 through the below example network. The approach specified here MAY 263 also be applicable for handling default routes as explained in 264 Section 3.2. 266 5 +---+ 8 +---+ 5 +---+ 267 +-----| S |------| A |-----| B | 268 | +---+ +---+ +---+ 269 | | | 270 | 5 | 5 | 271 | | | 272 +---+ 5 +---+ 4 +---+ 1 +---+ 273 | C |---| E |-----| M |-------| F | 274 +---+ +---+ +---+ +---+ 275 | 10 5 | 276 +-----------p---------+ 278 Figure 3: MHP with same ECMP Next-hop 280 In the above network a prefix p, is advertised from both Node E and 281 Node F. With simplified approach taken as specified in [RFC5286] 282 Section 6.1, prefix p will get only link protection LFA through the 283 neighbor C while a node protection path is available through neighbor 284 A. In this scenario, E and F both are pre-failure optimal points of 285 attachment and share the same primary next-hop. Hence, an 286 implementation MAY compare the kind of protection A provides to F 287 (link-and-node protection) with the kind of protection C provides to 288 E (link protection) and inherit the better alternative to prefix p 289 and here it is A. 291 However, in the below network prefix p has an ECMP through both node 292 E and node F with cost 20. Though it has 2 pre-failure optimal 293 points of attachment, the primary next-hop to each pre-failure 294 optimal point of attachment is different. In this case, prefix p 295 MUST inherit corresponding LFAs of each primary next-hop calculated 296 for the router advertising the same respectively. In the below 297 diagram that would be node E's and node F's LFA i.e., node N1 and 298 node N2 respectively. 300 4 +----+ 301 +------------------| N2 | 302 | +----+ 303 | | 4 304 10 +---+ 3 +---+ 305 +------| S |----------------| B | 306 | +---+ +---+ 307 | | | 308 | 10 | 1 | 309 | | | 310 +----+ 5 +---+ 16 +---+ 311 | N1 |----| E |-----------------| F | 312 +----+ +---+ +---+ 313 | 10 16 | 314 +-----------p---------+ 316 Figure 4: MHP with different ECMP Next-hops 318 In summary, if there are multiple pre-failure points of attachment 319 for a MHP and primary next-hop of a MHP is same as that of the 320 primary next-hop of the router that was pre-failure optimal point of 321 attachment, an implementation MAY provide the better protection to 322 MHP without incurring any additional computation cost. 324 3.2. IS-IS ATT Bit considerations 326 Per [RFC1195] a default route needs to be added in Level1 (L1) router 327 to the closest reachable Level1/Level2 (L1/L2) router in the network 328 advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers 329 in the area would do this during the decision process with the next- 330 hop of the default route set to the adjacent router through which the 331 closest L1/L2 router is reachable. The base LFA specification 332 [RFC5286] does not specify any procedure for computing LFA for a 333 default route in IS-IS L1 area. This document specifies, potentially 334 a node MAY consider a default route is being advertised from the 335 border L1/L2 router where ATT bit is set and can do LFA computation 336 for the default route. But, when multiple ECMP L1/L2 routers are 337 reachable in an L1 area corresponding best LFAs SHOULD be given for 338 each primary next-hop associated with default route. Considerations 339 as specified in Section 3 and Section 3.1 are applicable for default 340 routes, if the default route is considered as ECMP MHP. Note that, 341 this document doesn't alter any ECMP handling rules or computation of 342 LFAs for ECMP in general as laid out in [RFC5286]. 344 4. LFA selection for the multi-homed external prefixes 346 Redistribution of external routes into IGP is required in case of two 347 different networks getting merged into one or during protocol 348 migrations. External routes could be distributed into an IGP domain 349 via multiple nodes to avoid a single point of failure. 351 During LFA calculation, alternate LFA next-hops to reach the best 352 ASBR could be used as LFA for the routes redistributed via that ASBR. 353 When there is no LFA available to the best ASBR, it may be desirable 354 to consider the other ASBRs (referred to as alternate ASBR hereafter) 355 redistributing the external routes for LFA selection as defined in 356 [RFC5286] and leverage the advantage of having multiple re- 357 distributing nodes in the network. 359 4.1. IS-IS 361 LFA evaluation for multi-homed external prefixes in IS-IS is similar 362 to the multi-homed internal prefixes. Inequalities described in sec 363 2 would also apply to multi-homed external prefixes as well. 365 4.2. OSPF 367 Loop free Alternates [RFC5286] describes mechanisms to apply 368 inequalities to find the loop free alternate neighbor. For the 369 selection of alternate ASBR for LFA consideration, additional rules 370 have to be applied in selecting the alternate ASBR due to the 371 external route calculation rules imposed by [RFC2328]. 373 This document also defines the inequalities defined in [RFC5286] 374 specifically for the alternate loop-free ASBR evaluation. 376 4.2.1. Rules to select alternate ASBR 378 The process to select an alternate ASBR is best explained using the 379 rules below. The below process is applied when primary ASBR for the 380 concerned prefix is chosen and there is an alternate ASBR originating 381 same prefix. 383 1. If RFC1583Compatibility is disabled 385 1a. if primary ASBR and alternate ASBR are intra area 386 non-backbone path go to step 2. 387 1b. If primary ASBR and alternate ASBR belong to 388 intra-area backbone and/or inter-area path go 389 to step 2. 390 1c. for other paths, skip this alternate ASBR and 391 consider next ASBR. 393 2. If cost type (type1/type2) advertised by alternate 394 ASBR same as primary 395 2a. If not, same skip alternate ASBR and consider 396 next ASBR. 397 2b. If same proceed to step 3. 399 3. If cost type is type1 400 3a. If cost is same, program ECMP and return. 401 3b. else go to step 5. 403 4 If cost type is type 2 404 4a. If cost is different, skip alternate ASBR and 405 consider next ASBR. 406 4b. If type2 cost is same, proceed to step 4c to compare 407 compare type 1 cost. 408 4c. If type1 cost is also same program ECMP and return. 409 4d. If type 1 cost is different go to step 5. 411 5. If route type (type 5/type 7) 412 5a. If route type is same, check route p-bit, 413 forwarding address field for routes from both 414 ASBRs match. If p-bit matches proceed to step 6. 415 If not, skip this alternate ASBR and consider 416 next ASBR. 417 5b. If route type is not same, skip this alternate ASBR 418 and consider next alternate ASBR. 420 6. Apply inequality on the alternate ASBR. 422 Figure 5: Rules for selecting alternate ASBR in OSPF 424 4.2.2. Multiple ASBRs belonging different area 426 When "RFC1583compatibility" is set to disabled, OSPF [RFC2328] 427 defines certain rules of preference to choose the ASBRs. While 428 selecting alternate ASBR for loop evaluation for LFA, these rules 429 should be applied and ensured that the alternate neighbor does not 430 loop the traffic back. 432 When there are multiple ASBRs belonging to different area advertising 433 the same prefix, pruning rules as defined in [RFC2328] section 16.4.1 434 are applied. The alternate ASBRs pruned using above rules are not 435 considered for LFA evaluation. 437 4.2.3. Type 1 and Type 2 costs 439 If there are multiple ASBRs not pruned via rules defined in 3.2.2, 440 the cost type advertised by the ASBRs is compared. ASBRs advertising 441 Type1 costs are preferred and the type2 costs are pruned. If two 442 ASBRs advertise same type2 cost, the alternate ASBRs are considered 443 along with their type1 cost for evaluation. If the two ASBRs with 444 same type2 as well as type1 cost, ECMP FRR is programmed. If there 445 are two ASBRs with different type2 cost, the higher cost ASBR is 446 pruned. The inequalities for evaluating alternate ASBR for type 1 447 and type 2 costs are same, as the alternate ASBRs with different 448 type2 costs are pruned and the evaluation is based on equal type 2 449 cost ASBRS. 451 4.2.4. RFC1583compatibility is set to enabled 453 When RFC1583Compatibility is set to enabled, multiple ASBRs belonging 454 to different area advertising same prefix are chosen based on cost 455 and hence are valid alternate ASBRs for the LFA evaluation. 457 4.2.5. Type 7 routes 459 Type 5 routes always get preference over Type 7 and the alternate 460 ASBRs chosen for LFA calculation should belong to same type. Among 461 Type 7 routes, routes with p-bit and forwarding address set have 462 higher preference than routes without these attributes. Alternate 463 ASBRs selected for LFA comparison should have same p-bit and 464 forwarding address attributes. 466 4.2.6. Inequalities to be applied for alternate ASBR selection 468 The alternate ASBRs selected using above mechanism described in 469 3.2.1, are evaluated for Loop free criteria using below inequalities. 471 4.2.6.1. Forwarding address set to non-zero value 472 Link-Protection: 473 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 474 F_opt(S,PO_best) + cost(PO_best,P) 476 Link-Protection + Downstream-paths-only: 477 F_opt(N,PO_i)+ cost(PO_i,P) < F_opt(S,PO_best) + cost(PO_best,P) 479 Node-Protection: 480 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 481 F_opt(E,PO_best) + cost(PO_best,P) 483 Where, 484 S - The computing router 485 N - The alternate router being evaluated 486 E - The primary next-hop on shortest path from S to 487 prefix P. 488 PO_i - The specific prefix-originating router being 489 evaluated. 490 PO_best - The prefix-originating router on the shortest path 491 from the computing router S to prefix P. 492 cost(X,Y) - External cost for Y as advertised by X 493 F_opt(X,Y) - Distance on the shortest path from node X to Forwarding 494 address specified by ASBR Y. 495 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 497 Figure 6: LFA inequality definition when forwarding address in non- 498 zero 500 4.2.6.2. ASBRs advertising type1 and type2 cost 501 Link-Protection: 502 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 503 D_opt(S,PO_best) + cost(PO_best,P) 505 Link-Protection + Downstream-paths-only: 506 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 508 Node-Protection: 509 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 510 D_opt(E,PO_best) + cost(PO_best,P) 512 Where, 513 S - The computing router 514 N - The alternate router being evaluated 515 E - The primary next-hop on shortest path from S to 516 prefix P. 517 PO_i - The specific prefix-originating router being 518 evaluated. 519 PO_best - The prefix-originating router on the shortest path 520 from the computing router S to prefix P. 521 cost(X,Y) - External cost for Y as advertised by X. 522 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 524 Figure 7: LFA inequality definition for type1 and type 2 cost 526 5. LFA Extended Procedures 528 This section explains the additional considerations in various 529 aspects as listed below to the base LFA specification [RFC5286]. 531 5.1. Links with IGP MAX_METRIC 533 Section 3.5 and 3.6 of [RFC5286] describes procedures for excluding 534 nodes and links from use in alternate paths based on the maximum link 535 metric (as defined in for IS-IS in [RFC5305] or as defined in 536 [RFC3137] for OSPF). If these procedures are strictly followed, 537 there are situations, as described below, where the only potential 538 alternate available which satisfies the basic loop-free condition 539 will not be considered as alternative. 541 +---+ 10 +---+ 10 +---+ 542 | S |------|N1 |-----|D1 | 543 +---+ +---+ +---+ 544 | | 545 10 | 10 | 546 |MAX_MET(N2 to S) | 547 | | 548 | +---+ | 549 +-------|N2 |--------+ 550 +---+ 551 10 | 552 +---+ 553 |D2 | 554 +---+ 556 Figure 8: Link with IGP MAX_METRIC 558 In the simple example network, all the link costs have a cost of 10 559 in both directions, except for the link between S and N2. The S-N2 560 link has a cost of 10 in the forward direction i.e., from S to N2, 561 and a cost of MAX_METRIC (0xffffff /2^24 - 1 for IS-IS and 0xffff for 562 OSPF) in the reverse direction i.e., from N2 to S for a specific end- 563 to-end Traffic Engineering (TE) requirement of the operator. At node 564 S, D1 is reachable through N1 with cost 20, and D2 is reachable 565 through N2 with cost 20. Even though neighbor N2 satisfies basic 566 loop-free condition (inequality 1 of [RFC5286]) for D1, S's neighbor 567 N2 could be excluded as a potential alternative because of the 568 current exclusions as specified in section 3.5 and 3.6 procedure of 569 [RFC5286]. But, as the primary traffic destined to D2 continue to 570 use the link and hence irrespective of the reverse metric in this 571 case, same link MAY be used as a potential LFA for D1. 573 Alternatively, reverse metric of the link MAY be configured with 574 MAX_METRIC-1, so that the link can be used as an alternative while 575 meeting the operator's TE requirements and without having to update 576 the router to fix this particular issue. 578 5.2. Multi Topology Considerations 580 Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and 581 ISIS are out of scope for that specification. This memo clarifies 582 and describes the applicability. 584 In Multi Topology (MT) IGP deployments, for each MT ID, a separate 585 shortest path tree (SPT) is built with topology specific adjacencies, 586 the LFA principles laid out in [RFC5286] are actually applicable for 587 MT IS-IS [RFC5120] LFA SPF. The primary difference in this case is, 588 identifying the eligible-set of neighbors for each LFA computation 589 which is done per MT ID. The eligible-set for each MT ID is 590 determined by the presence of IGP adjacency from Source to the 591 neighboring node on that MT-ID apart from the administrative 592 restrictions and other checks laid out in [RFC5286]. The same is 593 also applicable for MT-OSPF [RFC4915] or different AFs in multi 594 instance OSPFv3 [RFC5838]. 596 However for MT IS-IS, if a "standard topology" is used with MT-ID #0 597 [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are 598 present, then the condition of network congruency is applicable for 599 LFA computation as well. Network congruency here refers to, having 600 same address families provisioned on all the links and all the nodes 601 of the network with MT-ID #0. Here with single decision process both 602 IPv4 and IPv6 next-hops are computed for all the prefixes in the 603 network and similarly with one LFA computation from all eligible 604 neighbors per [RFC5286], all potential alternatives can be computed. 606 6. Acknowledgements 608 Thanks to Alia Atlas and Salih K A for their useful feedback and 609 inputs. Thanks to Stewart Bryant for being document shepherd and 610 providing detailed review comments. 612 7. Contributing Authors 614 The following people contributed substantially to the content of this 615 document and should be considered co-authors. 617 Chris Bowers 618 Juniper Networks, Inc. 619 1194 N. Mathilda Ave, 620 Sunnyvale, CA 94089, USA 622 Email: cbowers@juniper.ne 624 Bruno Decraene 625 Orange, 626 France 628 Email: bruno.decraene@orange.com 630 8. Security Considerations 632 This document does not introduce any change in any of the protocol 633 [RFC1195] [RFC5120] [RFC2328] [RFC5838] specifications discussed here 634 and also this does not introduce any new security issues other than 635 as noted in the LFA base specification [RFC5286]. 637 9. References 639 9.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 647 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 648 DOI 10.17487/RFC5286, September 2008, 649 . 651 9.2. Informative References 653 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 654 dual environments", RFC 1195, DOI 10.17487/RFC1195, 655 December 1990, . 657 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 658 DOI 10.17487/RFC2328, April 1998, 659 . 661 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 662 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 663 DOI 10.17487/RFC3137, June 2001, 664 . 666 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 667 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 668 RFC 4915, DOI 10.17487/RFC4915, June 2007, 669 . 671 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 672 Topology (MT) Routing in Intermediate System to 673 Intermediate Systems (IS-ISs)", RFC 5120, 674 DOI 10.17487/RFC5120, February 2008, 675 . 677 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 678 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 679 2008, . 681 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 682 DOI 10.17487/RFC5308, October 2008, 683 . 685 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 686 R. Aggarwal, "Support of Address Families in OSPFv3", 687 RFC 5838, DOI 10.17487/RFC5838, April 2010, 688 . 690 Authors' Addresses 692 Pushpasis Sarkar (editor) 693 Arrcus, Inc. 695 Email: pushpasis.ietf@gmail.com 697 Shraddha Hegde 698 Juniper Networks, Inc. 699 Electra, Exora Business Park 700 Bangalore, KA 560103 701 India 703 Email: shraddha@juniper.net 705 Uma Chunduri (editor) 706 Huawei Technologies 707 2330 Central Expressway 708 Santa Clara, CA 95050 709 USA 711 Email: uma.chunduri@huawei.com 713 Jeff Tantsura 714 Individual 716 Email: jefftant.ietf@gmail.com 718 Hannes Gredler 719 RtBrick, Inc. 721 Email: hannes@rtbrick.com