idnits 2.17.1 draft-ietf-rtgwg-multihomed-prefix-lfa-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 384 has weird spacing: '... 2a. If not s...' -- The document date (January 16, 2017) is 2651 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 5286' is mentioned on line 356, but not defined == Missing Reference: 'RFC 2328' is mentioned on line 360, but not defined -- Looks like a reference, but probably isn't: '5286' on line 362 == Missing Reference: 'RFC2328' is mentioned on line 412, but not defined == Missing Reference: 'MT-OSPF' is mentioned on line 577, but not defined == Unused Reference: 'RFC7916' is defined on line 654, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 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 Individual 4 Intended status: Informational S. Hegde 5 Expires: July 20, 2017 C. Bowers 6 Juniper Networks, Inc. 7 U. Chunduri, Ed. 8 Huawei Technologies 9 J. Tantsura 10 Individual 11 B. Decraene 12 Orange 13 H. Gredler 14 RtBrick, Inc. 15 January 16, 2017 17 LFA selection for Multi-Homed Prefixes 18 draft-ietf-rtgwg-multihomed-prefix-lfa-01 20 Abstract 22 This document shares experience gained from implementing algorithms 23 to determine Loop-Free Alternates for multi-homed prefixes. In 24 particular, this document provides explicit inequalities that can be 25 used to evaluate neighbors as a potential alternates for multi-homed 26 prefixes. It also provides detailed criteria for evaluating 27 potential alternates for external prefixes advertised by OSPF ASBRs. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on July 20, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. LFA inequalities for MHPs . . . . . . . . . . . . . . . . . . 4 71 3. LFA selection for the multi-homed prefixes . . . . . . . . . 4 72 3.1. Improved coverage with simplified approach to MHPs . . . 6 73 3.2. IS-IS ATT Bit considerations . . . . . . . . . . . . . . 7 74 4. LFA selection for the multi-homed external prefixes . . . . . 8 75 4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.2.1. Rules to select alternate ASBR . . . . . . . . . . . 8 78 4.2.2. Multiple ASBRs belonging different area . . . . . . . 9 79 4.2.3. Type 1 and Type 2 costs . . . . . . . . . . . . . . . 10 80 4.2.4. RFC1583compatibility is set to enabled . . . . . . . 10 81 4.2.5. Type 7 routes . . . . . . . . . . . . . . . . . . . . 10 82 4.2.6. Inequalities to be applied for alternate ASBR 83 selection . . . . . . . . . . . . . . . . . . . . . . 10 84 4.2.6.1. Forwarding address set to non-zero value . . . . 10 85 4.2.6.2. ASBRs advertising type1 and type2 cost . . . . . 11 86 5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 12 87 5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 12 88 5.2. Multi Topology Considerations . . . . . . . . . . . . . . 13 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 9.2. Informative References . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 The use of Loop-Free Alternates (LFA) for IP Fast Reroute is 100 specified in [RFC5286]. Section 6.1 of [RFC5286] describes a method 101 to determine loop-free alternates for a multi-homed prefixes (MHPs). 102 This document describes a procedure using explicit inequalities that 103 can be used by a computing router to evaluate a neighbor as a 104 potential alternate for a multi-homed prefix. The results obtained 105 are equivalent to those obtained using the method described in 106 Section 6.1 of [RFC5286]. However, some may find this formulation 107 useful. 109 Section 6.3 of [RFC5286] discusses complications associated with 110 computing LFAs for multi-homed prefixes in OSPF. This document 111 provides detailed criteria for evaluating potential alternates for 112 external prefixes advertised by OSPF ASBRs, as well as explicit 113 inequalities. 115 This document also provide clarifications, additional considerations 116 to [RFC5286], to address a few coverage and operational observations. 117 These observations are in the area of handling IS-IS attach (ATT) bit 118 in Level-1 (L1) area, links provisioned with MAX_METRIC for traffic 119 engineering (TE) purposes and in the area of Multi Topology (MT) IGP 120 deployments. All these are elaborated in detail in Section 3.2 and 121 Section 5. 123 1.1. Acronyms 125 AF - Address Family 127 ATT - IS-IS Attach Bit 129 ECMP - Equal Cost Multi Path 131 IGP - Interior Gateway Protocol 133 IS-IS - Intermediate System to Intermediate System 135 OSPF - Open Shortest Path First 137 MHP - Multi-homed Prefix 139 MT - Multi Topology 141 SPF - Shortest Path First PDU 143 2. LFA inequalities for MHPs 145 This document proposes the following set of LFA inequalities for 146 selecting the most appropriate LFAs for multi-homed prefixes (MHPs). 147 They can be derived from the inequalities in [RFC5286] combined with 148 the observation that D_opt(N,P) = Min (D_opt(N,PO_i) + cost(PO_i,P)) 149 over all PO_i 151 Link-Protection: 152 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 153 D_opt(S,PO_best) + cost(PO_best,P) 155 Link-Protection + Downstream-paths-only: 156 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 158 Node-Protection: 159 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 160 D_opt(E,PO_best) + cost(PO_best,P) 162 Where, 163 S - The computing router 164 N - The alternate router being evaluated 165 E - The primary next-hop on shortest path from S to 166 prefix P. 167 PO_i - The specific prefix-originating router being 168 evaluated. 169 PO_best - The prefix-originating router on the shortest path 170 from the computing router S to prefix P. 171 Cost (X,P) - Cost of reaching the prefix P from prefix 172 originating node X. 173 D_opt(X,Y) - Distance on the shortest path from node X to node 174 Y. 176 Figure 1: LFA inequalities for MHPs 178 3. LFA selection for the multi-homed prefixes 180 To compute a valid LFA for a given multi-homed prefix P, through an 181 alternate neighbor N a computing router S MUST follow one of the 182 appropriate procedures below. 184 Link-Protection : 185 ================= 186 1. If alternate neighbor N is also prefix-originator of P, 187 1.a. Select N as a LFA for prefix P (irrespective of 188 the metric advertised by N for the prefix P). 189 2. Else, evaluate the link-protecting LFA inequality for P with 190 the N as the alternate neighbor. 191 2.a. If LFA inequality condition is met, 192 select N as a LFA for prefix P. 193 2.b. Else, N is not a LFA for prefix P. 195 Link-Protection + Downstream-paths-only : 196 ========================================= 197 1. Evaluate the link-protecting + downstream-only LFA inequality 198 for P with the N as the alternate neighbor. 199 1.a. If LFA inequality condition is met, 200 select N as a LFA for prefix P. 201 1.b. Else, N is not a LFA for prefix P. 203 Node-Protection : 204 ================= 205 1. If alternate neighbor N is also prefix-originator of P, 206 1.a. Select N as a LFA for prefix P (irrespective of 207 the metric advertised by N for the prefix P). 208 2. Else, evaluate the appropriate node-protecting LFA inequality 209 for P with the N as the alternate neighbor. 210 2.a. If LFA inequality condition is met, 211 select N as a LFA for prefix P. 212 2.b. Else, N is not a LFA for prefix P. 214 Figure 2: Rules for selecting LFA for MHPs 216 In case an alternate neighbor N is also one of the prefix-originators 217 of prefix P, N MAY be selected as a valid LFA for P. 219 However if N is not a prefix-originator of P, the computing router 220 SHOULD evaluate one of the corresponding LFA inequalities, as 221 mentioned in Figure 1, once for each remote node that originated the 222 prefix. In case the inequality is satisfied by the neighbor N router 223 S MUST choose neighbor N, as one of the valid LFAs for the prefix P. 225 When computing a downstream-only LFA, in addition to being a prefix- 226 originator of P, router N MUST also satisfy the downstream-only LFA 227 inequality specified in Figure 1. 229 For more specific rules please refer to the later sections of this 230 document. 232 3.1. Improved coverage with simplified approach to MHPs 234 LFA base specification [RFC5286] Section 6.1 recommends that a router 235 compute the alternate next-hop for an IGP multi-homed prefix by 236 considering alternate paths via all routers that have announced that 237 prefix and the same has been elaborated with appropriate inequalities 238 in the above section. However, [RFC5286] Section 6.1 also allows for 239 the router to simplify the multi-homed prefix calculation by assuming 240 that the MHP is solely attached to the router that was its pre- 241 failure optimal point of attachment, at the expense of potentially 242 lower coverage. If an implementation chooses to simplify the multi- 243 homed prefix calculation by assuming that the MHP is solely attached 244 to the router that was its pre-failure optimal point of attachment, 245 the procedure described in this memo can potentially improve coverage 246 for equal cost multi path (ECMP) MHPs without incurring extra 247 computational cost. 249 While the approach as specified in [RFC5286] Section 6.1 last 250 paragraph, is to simplify the MHP as solely attached to the router 251 that was its pre-failure optimal point of attachment; though it is a 252 scalable approach and simplifies computation, [RFC5286] notes this 253 may result in little less coverage. 255 This memo improves the above approach to provide loop-free 256 alternatives without any additional cost for equal cost multi path 257 MHPs as described through the below example network. The approach 258 specified here MAY also be applicable for handling default routes as 259 explained in Section 3.2. 261 5 +---+ 8 +---+ 5 +---+ 262 +-----| S |------| A |-----| B | 263 | +---+ +---+ +---+ 264 | | | 265 | 5 | 5 | 266 | | | 267 +---+ 5 +---+ 4 +---+ 1 +---+ 268 | C |---| E |-----| M |-------| F | 269 +---+ +---+ +---+ +---+ 270 | 10 5 | 271 +-----------p---------+ 273 Figure 3: MHP with same ECMP Next-hop 275 In the above network a prefix p, is advertised from both Node E and 276 Node F. With simplified approach taken as specified in [RFC5286] 277 Section 6.1, prefix p will get only link protection LFA through the 278 neighbor C while a node protection path is available through neighbor 279 A. In this scenario, E and F both are pre-failure optimal points of 280 attachment and share the same primary next-hop. Hence, an 281 implementation MAY compare the kind of protection A provides to F 282 (link-and-node protection) with the kind of protection C provides to 283 E (link protection) and inherit the better alternative to prefix p 284 and here it is A. 286 However, in the below network prefix p has an ECMP through both node 287 E and node F with cost 20. Though it has 2 pre-failure optimal 288 points of attachment, the primary next-hop to each pre-failure 289 optimal point of attachment is different. In this case, prefix p 290 shall inherit corresponding LFA to each primary next-hop calculated 291 for the router advertising the same respectively (node E's and node 292 F's LFA). 294 +---+ 3 +---+ 295 | S |----------------| B | 296 +---+ +---+ 297 | | 298 10 | 1 | 299 | | 300 +---+ 6 +---+ 301 | E |-----------------| F | 302 +---+ +---+ 303 | 10 16 | 304 +-----------p---------+ 306 Figure 4: MHP with different ECMP Next-hops 308 In summary, if there are multiple pre-failure points of attachment 309 for a MHP and primary next-hop of a MHP is same as that of the 310 primary next-hop of the router that was pre-failure optimal point of 311 attachment, an implementation MAY provide the better protection to 312 MHP without incurring any additional computation cost. 314 3.2. IS-IS ATT Bit considerations 316 Per [RFC1195] a default route needs to be added in Level1 (L1) router 317 to the closest reachable Level1/Level2 (L1/L2) router in the network 318 advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers 319 in the area would do this during the decision process with the next- 320 hop of the default route set to the adjacent router through which the 321 closest L1/L2 router is reachable. The base LFA specification 322 [RFC5286] does not specify any procedure for computing LFA for a 323 default route in IS-IS L1 area. Potentially one MAY consider a 324 default route is being advertised from the border L1/L2 router where 325 ATT bit is set and can do LFA computation for the default route. 327 But, when multiple ECMP L1/L2 routers are reachable in an L1 area 328 corresponding best LFAs SHOULD be given for each primary next-hop 329 associated with default route. Considerations as specified in 330 Section 3 and Section 3.1 are applicable for default routes, if the 331 default route is considered as ECMP MHP. 333 4. LFA selection for the multi-homed external prefixes 335 Redistribution of external routes into IGP is required in case of two 336 different networks getting merged into one or during protocol 337 migrations. External routes could be distributed into an IGP domain 338 via multiple nodes to avoid a single point of failure. 340 During LFA calculation, alternate LFA next-hops to reach the best 341 ASBR could be used as LFA for the routes redistributed via that ASBR. 342 When there is no LFA available to the best ASBR, it may be desirable 343 to consider the other ASBRs (referred to as alternate ASBR hereafter) 344 redistributing the external routes for LFA selection as defined in 345 [RFC5286] and leverage the advantage of having multiple re- 346 distributing nodes in the network. 348 4.1. IS-IS 350 LFA evaluation for multi-homed external prefixes in IS-IS is similar 351 to the multi-homed internal prefixes. Inequalities described in sec 352 2 would also apply to multi-homed external prefixes as well. 354 4.2. OSPF 356 Loop free Alternates [RFC 5286] describes mechanisms to apply 357 inequalities to find the loop free alternate neighbor. For the 358 selection of alternate ASBR for LFA consideration, additional rules 359 have to be applied in selecting the alternate ASBR due to the 360 external route calculation rules imposed by [RFC 2328]. 362 This document also defines the inequalities defined in RFC [5286] 363 specifically for the alternate loop-free ASBR evaluation. 365 4.2.1. Rules to select alternate ASBR 367 The process to select an alternate ASBR is best explained using the 368 rules below. The below process is applied when primary ASBR for the 369 concerned prefix is chosen and there is an alternate ASBR originating 370 same prefix. 372 1. If RFC1583Compatibility is disabled 374 1a. if primary ASBR and alternate ASBR are intra area 375 non-backbone path go to step 2. 376 1b. If primary ASBR and alternate ASBR belong to 377 intra-area backbone and/or inter-area path go 378 to step 2. 379 1c. for other paths, skip the alternate ASBR and 380 consider next ASBR. 382 2. If cost type (type1/type2) advertised by alternate 383 ASBR same as primary 384 2a. If not same skip alternate ASBR and consider next ASBR. 386 3. If cost type is type1 387 3a. If cost is same, program ECMP 388 3b. else go to step 5. 390 4 If cost type is type 2 391 4a. If cost is different, skip alternate ASBR and 392 consider next ASBR 393 4b. If type2 cost is same, compare type 1 cost. 394 4c. If type1 cost is also same program ECMP. 395 4d. If type 1 cost is different go to step 5. 397 5. If route type (type 5/type 7) 398 5a. If route type is same, check route p-bit, 399 forwarding address field for routes from both 400 ASBRs 401 match. If not skip alternate ASBR and consider 402 next ASBR. 403 5b. If route type is not same, skip ASBR 404 and consider next ASBR. 406 6. Apply inequality on the alternate ASBR. 408 Figure 5: Rules for selecting alternate ASBR in OSPF 410 4.2.2. Multiple ASBRs belonging different area 412 When "RFC1583compatibility" is set to disabled, OSPF[RFC2328] defines 413 certain rules of preference to choose the ASBRs. While selecting 414 alternate ASBR for loop evaluation for LFA, these rules should be 415 applied and ensured that the alternate neighbor does not loop the 416 traffic back. 418 When there are multiple ASBRs belonging to different area advertising 419 the same prefix, pruning rules as defined in RFC 2328 section 16.4.1 420 are applied. The alternate ASBRs pruned using above rules are not 421 considered for LFA evaluation. 423 4.2.3. Type 1 and Type 2 costs 425 If there are multiple ASBRs not pruned via rules defined in 3.2.2, 426 the cost type advertised by the ASBRs is compared. ASBRs advertising 427 Type1 costs are preferred and the type2 costs are pruned. If two 428 ASBRs advertise same type2 cost, the alternate ASBRs are considered 429 along with their type1 cost for evaluation. If the two ASBRs with 430 same type2 as well as type1 cost, ECMP FRR is programmed. If there 431 are two ASBRs with different type2 cost, the higher cost ASBR is 432 pruned. The inequalities for evaluating alternate ASBR for type 1 433 and type 2 costs are same, as the alternate ASBRs with different 434 type2 costs are pruned and the evaluation is based on equal type 2 435 cost ASBRS. 437 4.2.4. RFC1583compatibility is set to enabled 439 When RFC1583Compatibility is set to enabled, multiple ASBRs belonging 440 to different area advertising same prefix are chosen based on cost 441 and hence are valid alternate ASBRs for the LFA evaluation. 443 4.2.5. Type 7 routes 445 Type 5 routes always get preference over Type 7 and the alternate 446 ASBRs chosen for LFA calculation should belong to same type. Among 447 Type 7 routes, routes with p-bit and forwarding address set have 448 higher preference than routes without these attributes. Alternate 449 ASBRs selected for LFA comparison should have same p-bit and 450 forwarding address attributes. 452 4.2.6. Inequalities to be applied for alternate ASBR selection 454 The alternate ASBRs selected using above mechanism described in 455 3.2.1, are evaluated for Loop free criteria using below inequalities. 457 4.2.6.1. Forwarding address set to non-zero value 458 Link-Protection: 459 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 460 F_opt(S,PO_best) + cost(PO_best,P) 462 Link-Protection + Downstream-paths-only: 463 F_opt(N,PO_i)+ cost(PO_i,P) < F_opt(S,PO_best) + cost(PO_best,P) 465 Node-Protection: 466 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 467 F_opt(E,PO_best) + cost(PO_best,P) 469 Where, 470 S - The computing router 471 N - The alternate router being evaluated 472 E - The primary next-hop on shortest path from S to 473 prefix P. 474 PO_i - The specific prefix-originating router being 475 evaluated. 476 PO_best - The prefix-originating router on the shortest path 477 from the computing router S to prefix P. 478 cost(X,Y) - External cost for Y as advertised by X 479 F_opt(X,Y) - Distance on the shortest path from node X to Forwarding 480 address specified by ASBR Y. 481 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 483 Figure 6: LFA inequality definition when forwarding address in non- 484 zero 486 4.2.6.2. ASBRs advertising type1 and type2 cost 487 Link-Protection: 488 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 489 D_opt(S,PO_best) + cost(PO_best,P) 491 Link-Protection + Downstream-paths-only: 492 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 494 Node-Protection: 495 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 496 D_opt(E,PO_best) + cost(PO_best,P) 498 Where, 499 S - The computing router 500 N - The alternate router being evaluated 501 E - The primary next-hop on shortest path from S to 502 prefix P. 503 PO_i - The specific prefix-originating router being 504 evaluated. 505 PO_best - The prefix-originating router on the shortest path 506 from the computing router S to prefix P. 507 cost(X,Y) - External cost for Y as advertised by X. 508 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 510 Figure 7: LFA inequality definition for type1 and type 2 cost 512 5. LFA Extended Procedures 514 This section explains the additional considerations in various 515 aspects as listed below to the base LFA specification [RFC5286]. 517 5.1. Links with IGP MAX_METRIC 519 Section 3.5 and 3.6 of [RFC5286] describes procedures for excluding 520 nodes and links from use in alternate paths based on the maximum link 521 metric (as defined in for IS-IS in [RFC5305] or as defined in 522 [RFC3137] for OSPF). If these procedures are strictly followed, 523 there are situations, as described below, where the only potential 524 alternate available which satisfies the basic loop-free condition 525 will not be considered as alternative. 527 +---+ 10 +---+ 10 +---+ 528 | S |------|N1 |-----|D1 | 529 +---+ +---+ +---+ 530 | | 531 10 | 10 | 532 |MAX_MET(N2 to S) | 533 | | 534 | +---+ | 535 +-------|N2 |--------+ 536 +---+ 537 10 | 538 +---+ 539 |D2 | 540 +---+ 542 Figure 8: Link with IGP MAX_METRIC 544 In the simple example network, all the link costs have a cost of 10 545 in both directions, except for the link between S and N2. The S-N2 546 link has a cost of 10 in the direction from S to N2, and a cost of 547 MAX_METRIC in the direction from N2 to S (0xffffff /2^24 - 1 for IS- 548 IS and 0xffff for OSPF) for a specific end to end Traffic Engineering 549 (TE) requirement of the operator. At node S, D1 is reachable through 550 N1 with cost 20, and D2 is reachable through N2 with cost 20. Even 551 though neighbor N2 satisfies basic loop-free condition (inequality 1 552 of [RFC5286]) for D1 this could be excluded as potential alternative 553 because of the current exclusions as specified in section 3.5 and 3.6 554 procedure of [RFC5286]. But, as the primary traffic destined to D2 555 continue to use the link and hence irrespective of the reverse metric 556 in this case, the same link MAY be used as a potential LFA for D1. 558 Alternatively, reverse metric of the link MAY be configured with 559 MAX_METRIC-1, so that the link can be used as an alternative while 560 meeting the TE requirements. 562 5.2. Multi Topology Considerations 564 Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and 565 ISIS are out of scope for that specification. This memo clarifies 566 and describes the applicability. 568 In Multi Topology (MT) IGP deployments, for each MT ID, a separate 569 shortest path tree (SPT) is built with topology specific adjacencies, 570 the LFA principles laid out in [RFC5286] are actually applicable for 571 MT IS-IS [RFC5120] LFA SPF. The primary difference in this case is, 572 identifying the eligible-set of neighbors for each LFA computation 573 which is done per MT ID. The eligible-set for each MT ID is 574 determined by the presence of IGP adjacency from Source to the 575 neighboring node on that MT-ID apart from the administrative 576 restrictions and other checks laid out in [RFC5286]. The same is 577 also applicable for OSPF [RFC4915] [MT-OSPF] or different AFs in 578 multi instance OSPFv3 [RFC5838]. 580 However for MT IS-IS, if a default topology is used with MT-ID 0 581 [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are 582 present, then the condition of network congruency is applicable for 583 LFA computation as well. Network congruency here refers to, having 584 same address families provisioned on all the links and all the nodes 585 of the network with MT-ID 0. Here with single decision process both 586 IPv4 and IPv6 next-hops are computed for all the prefixes in the 587 network and similarly with one LFA computation from all eligible 588 neighbors per [RFC5286], all potential alternatives can be computed. 590 6. Acknowledgements 592 Thanks to Alia Atlas and Salih K A for their useful feedback and 593 inputs. 595 7. IANA Considerations 597 N/A. - No protocol changes are proposed in this document. 599 8. Security Considerations 601 This document does not introduce any change in any of the protocol 602 specifications and also this does not introduce any new security 603 issues other than as noted in the LFA base specification [RFC5286]. 605 9. References 607 9.1. Normative References 609 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 610 dual environments", RFC 1195, DOI 10.17487/RFC1195, 611 December 1990, . 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 9.2. Informative References 620 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 621 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 622 DOI 10.17487/RFC3137, June 2001, 623 . 625 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 626 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 627 RFC 4915, DOI 10.17487/RFC4915, June 2007, 628 . 630 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 631 Topology (MT) Routing in Intermediate System to 632 Intermediate Systems (IS-ISs)", RFC 5120, 633 DOI 10.17487/RFC5120, February 2008, 634 . 636 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 637 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 638 DOI 10.17487/RFC5286, September 2008, 639 . 641 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 642 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 643 2008, . 645 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 646 DOI 10.17487/RFC5308, October 2008, 647 . 649 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 650 R. Aggarwal, "Support of Address Families in OSPFv3", 651 RFC 5838, DOI 10.17487/RFC5838, April 2010, 652 . 654 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 655 Horneffer, M., and P. Sarkar, "Operational Management of 656 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 657 July 2016, . 659 Authors' Addresses 661 Pushpasis Sarkar (editor) 662 Individual 664 Email: pushpasis.ietf@gmail.com 665 Shraddha Hegde 666 Juniper Networks, Inc. 667 Electra, Exora Business Park 668 Bangalore, KA 560103 669 India 671 Email: shraddha@juniper.net 673 Chris Bowers 674 Juniper Networks, Inc. 675 1194 N. Mathilda Ave. 676 Sunnyvale, CA 94089 677 US 679 Email: cbowers@juniper.net 681 Uma Chunduri (editor) 682 Huawei Technologies 683 2330 Central Expressway 684 Santa Clara, CA 95050 685 USA 687 Email: uma.chunduri@huawei.com 689 Jeff Tantsura 690 Individual 692 Email: jefftant.ietf@gmail.com 694 Bruno Decraene 695 Orange 697 Email: bruno.decraene@orange.com 699 Hannes Gredler 700 RtBrick, Inc. 702 Email: hannes@rtbrick.com