idnits 2.17.1 draft-psarkar-rtgwg-multihomed-prefix-lfa-03.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 383 has weird spacing: '... 2a. If not s...' -- The document date (January 19, 2016) is 3018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 5286' is mentioned on line 355, but not defined == Missing Reference: 'RFC 2328' is mentioned on line 359, but not defined -- Looks like a reference, but probably isn't: '5286' on line 361 == Missing Reference: 'RFC2328' is mentioned on line 411, but not defined == Missing Reference: 'MT-OSPF' is mentioned on line 576, but not defined == Unused Reference: 'I-D.ietf-rtgwg-lfa-manageability' is defined on line 619, 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 S. Hegde 4 Intended status: Informational C. Bowers 5 Expires: July 22, 2016 Juniper Networks, Inc. 6 U. Chunduri, Ed. 7 J. Tantsura 8 Ericsson Inc. 9 B. Decraene 10 Orange 11 H. Gredler 12 Unaffiliated 13 January 19, 2016 15 LFA selection for Multi-Homed Prefixes 16 draft-psarkar-rtgwg-multihomed-prefix-lfa-03 18 Abstract 20 This document shares experience gained from implementing algorithms 21 to determine Loop-Free Alternates for multi-homed prefixes. In 22 particular, this document provides explicit inequalities that can be 23 used to evaluate neighbors as a potential alternates for multi-homed 24 prefixes. It also provides detailed criteria for evaluating 25 potential alternates for external prefixes advertised by OSPF ASBRs. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 22, 2016. 50 Copyright Notice 52 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . 8 77 4.2.2. Multiple ASBRs belonging different area . . . . . . . 9 78 4.2.3. Type 1 and Type 2 costs . . . . . . . . . . . . . . . 10 79 4.2.4. RFC1583compatibility is set to enabled . . . . . . . 10 80 4.2.5. Type 7 routes . . . . . . . . . . . . . . . . . . . . 10 81 4.2.6. Inequalities to be applied for alternate ASBR 82 selection . . . . . . . . . . . . . . . . . . . . . . 10 83 4.2.6.1. Forwarding address set to non zero value . . . . 10 84 4.2.6.2. ASBRs advertising type1 and type2 cost . . . . . 11 85 5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 12 86 5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 12 87 5.2. Multi Topology Considerations . . . . . . . . . . . . . . 13 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 9.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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. All 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 OSPF - Open Shortest Path First 136 MHP - Multi-homed Prefix 138 MT - Multi Topology 140 SPF - Shortest Path First PDU 142 2. LFA inequalities for MHPs 144 This document proposes the following set of LFA inequalities for 145 selecting the most appropriate LFAs for multi-homed prefixes (MHPs). 146 They can be derived from the inequalities in [RFC5286] combined with 147 the observation that D_opt(N,P) = Min (D_opt(N,PO_i) + cost(PO_i,P)) 148 over all PO_i 150 Link-Protection: 151 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 152 D_opt(S,PO_best) + cost(PO_best,P) 154 Link-Protection + Downstream-paths-only: 155 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 157 Node-Protection: 158 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 159 D_opt(E,PO_best) + cost(PO_best,P) 161 Where, 162 S - The computing router 163 N - The alternate router being evaluated 164 E - The primary next-hop on shortest path from S to 165 prefix P. 166 PO_i - The specific prefix-originating router being 167 evaluated. 168 PO_best - The prefix-originating router on the shortest path 169 from the computing router S to prefix P. 170 Cost (X,P) - Cost of reaching the prefix P from prefix 171 originating node X. 172 D_opt(X,Y) - Distance on the shortest path from node X to node 173 Y. 175 Figure 1: LFA inequalities for MHPs 177 3. LFA selection for the multi-homed prefixes 179 To compute a valid LFA for a given multi-homed prefix P, through an 180 alternate neighbor N a computing router S MUST follow one of the 181 appropriate procedures below. 183 Link-Protection : 184 ================= 185 1. If alternate neighbor N is also prefix-originator of P, 186 1.a. Select N as a LFA for prefix P (irrespective of 187 the metric advertised by N for the prefix P). 188 2. Else, evaluate the link-protecting LFA inequality for P with 189 the N as the alternate neighbor. 190 2.a. If LFA inequality condition is met, 191 select N as a LFA for prefix P. 192 2.b. Else, N is not a LFA for prefix P. 194 Link-Protection + Downstream-paths-only : 195 ========================================= 196 1. Evaluate the link-protecting + downstream-only LFA inequality 197 for P with the N as the alternate neighbor. 198 1.a. If LFA inequality condition is met, 199 select N as a LFA for prefix P. 200 1.b. Else, N is not a LFA for prefix P. 202 Node-Protection : 203 ================= 204 1. If alternate neighbor N is also prefix-originator of P, 205 1.a. Select N as a LFA for prefix P (irrespective of 206 the metric advertised by N for the prefix P). 207 2. Else, evaluate the apporpriate node-protecting LFA inequality 208 for P with the N as the alternate neighbor. 209 2.a. If LFA inequality condition is met, 210 select N as a LFA for prefix P. 211 2.b. Else, N is not a LFA for prefix P. 213 Figure 2: Rules for selecting LFA for MHPs 215 In case an alternate neighbor N is also one of the prefix-originators 216 of prefix P, N MAY be selected as a valid LFA for P. 218 However if N is not a prefix-originator of P, the computing router 219 SHOULD evaluate one of the corresponding LFA inequalities, as 220 mentioned in Figure 1, once for each remote node that originated the 221 prefix. In case the inequality is satisfied by the neighbor N router 222 S MUST choose neighbor N, as one of the valid LFAs for the prefix P. 224 When computing a downstream-only LFA, in addition to being a prefix- 225 originator of P, router N MUST also satisfy the downstream-only LFA 226 inequality specified in Figure 1. 228 For more specific rules please refer to the later sections of this 229 document. 231 3.1. Improved coverage with simplified approach to MHPs 233 LFA base specification [RFC5286] Section 6.1 recommends that a router 234 compute the alternate next-hop for an IGP multi-homed prefix by 235 considering alternate paths via all routers that have announced that 236 prefix and the same has been elaborated with appropriate inequalities 237 in the above section. However, [RFC5286] Section 6.1 also allows for 238 the router to simplify the multi-homed prefix calculation by assuming 239 that the MHP is solely attached to the router that was its pre- 240 failure optimal point of attachment, at the expense of potentially 241 lower coverage. If an implementation chooses to simplify the multi- 242 homed prefix calculation by assuming that the MHP is solely attached 243 to the router that was its pre-failure optimal point of attachment, 244 the procedure described in this memo can potentially improve coverage 245 for equal cost multi path (ECMP) MHPs without incurring extra 246 computational cost. 248 While the approach as specified in [RFC5286] Section 6.1 last 249 paragraph, is to simplify the MHP as solely attached to the router 250 that was its pre-failure optimal point of attachment; though it is a 251 scalable approach and simplifies computation, [RFC5286] notes this 252 may result in little less coverage. 254 This memo improves the above approach to provide loop-free 255 alternatives without any additional cost for equal cost multi path 256 MHPs as described through the below example network. The approach 257 specified here MAY also be applicable for handling default routes as 258 explained in Section 3.2. 260 5 +---+ 8 +---+ 5 +---+ 261 +-----| S |------| A |-----| B | 262 | +---+ +---+ +---+ 263 | | | 264 | 5 | 5 | 265 | | | 266 +---+ 5 +---+ 4 +---+ 1 +---+ 267 | C |---| E |-----| M |-------| F | 268 +---+ +---+ +---+ +---+ 269 | 10 5 | 270 +-----------p---------+ 272 Figure 3: MHP with same ECMP Next-hop 274 In the above network a prefix p, is advertised from both Node E and 275 Node F. With simplified approach taken as specified in [RFC5286] 276 Section 6.1, prefix p will get only link protection LFA through the 277 neighbor C while a node protection path is available through neighbor 278 A. In this scenario, E and F both are pre-failure optimal points of 279 attachment and share the same primary next-hop. Hence, an 280 implementation MAY compare the kind of protection A provides to F 281 (link-and-node protection) with the kind of protection C provides to 282 E (link protection) and inherit the better alternative to prefix p 283 and here it is A. 285 However, in the below network prefix p has an ECMP through both node 286 E and node F with cost 20. Though it has 2 pre-failure optimal 287 points of attachment, the primary next-hop to each pre-failure 288 optimal point of attachment is different. In this case, prefix p 289 shall inherit corresponding LFA to each primary next-hop calculated 290 for the router advertising the same respectively (node E's and node 291 F's LFA). 293 +---+ 3 +---+ 294 | S |----------------| B | 295 +---+ +---+ 296 | | 297 10 | 1 | 298 | | 299 +---+ 6 +---+ 300 | E |-----------------| F | 301 +---+ +---+ 302 | 10 16 | 303 +-----------p---------+ 305 Figure 4: MHP with different ECMP Next-hops 307 In summary, if there are multiple pre-failure points of attachment 308 for a MHP and primary next-hop of a MHP is same as that of the 309 primary next-hop of the router that was pre-failure optimal point of 310 attachment, an implementation MAY provide the better protection to 311 MHP without incurring any additional computation cost. 313 3.2. IS-IS ATT Bit considerations 315 Per [RFC1195] a default route needs to be added in Level1 (L1) router 316 to the closest reachable Level1/Level2 (L1/L2) router in the network 317 advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers 318 in the area would do this during the decision process with the next- 319 hop of the default route set to the adjacent router through which the 320 closest L1/L2 router is reachable. The base LFA specification 321 [RFC5286] does not specify any procedure for computing LFA for a 322 default route in IS-IS L1 area. Potentially one MAY consider a 323 default route is being advertised from the border L1/L2 router where 324 ATT bit is set and can do LFA computation for the default route. 326 But, when multiple ECMP L1/L2 routers are reachable in an L1 area 327 corresponding best LFAs SHOULD be given for each primary next-hop 328 associated with default route. Considerations as specified in 329 Section 3 and Section 3.1 are applicable for default routes, if the 330 default route is considered as ECMP MHP. 332 4. LFA selection for the multi-homed external prefixes 334 Redistribution of external routes into IGP is required in case of two 335 different networks getting merged into one or during protocol 336 migrations. External routes could be distributed into an IGP domain 337 via multiple nodes to avoid a single point of failure. 339 During LFA calculation, alternate LFA next-hops to reach the best 340 ASBR could be used as LFA for the routes redistributed via that ASBR. 341 When there is no LFA available to the best ASBR, it may be desirable 342 to consider the other ASBRs (referred to as alternate ASBR hereafter) 343 redistributing the external routes for LFA selection as defined in 344 [RFC5286] and leverage the advantage of having multiple re- 345 distributing nodes in the network. 347 4.1. IS-IS 349 LFA evaluation for multi-homed external prefixes in IS-IS is similar 350 to the multi-homed internal prefixes. Inequalities described in sec 351 2 would also apply to multi-homed external prefixes as well. 353 4.2. OSPF 355 Loop free Alternates [RFC 5286] describes mechanisms to apply 356 inequalities to find the loop free alternate neighbor. For the 357 selection of alternate ASBR for LFA consideration, additional rules 358 have to be applied in selecting the alternate ASBR due to the 359 external route calculation rules imposed by [RFC 2328]. 361 This document also defines the inequalities defined in RFC [5286] 362 specifically for the alternate loop-free ASBR evaluation. 364 4.2.1. Rules to select alternate ASBR 366 The process to select an alternate ASBR is best explained using the 367 rules below. The below process is applied when primary ASBR for the 368 concerned prefix is chosen and there is an alternate ASBR originating 369 same prefix. 371 1. If RFC1583Compatibility is disabled 373 1a. if primary ASBR and alternate ASBR are intra area 374 non-backbone path go to step 2. 375 1b. If primary ASBR and alternate ASBR belong to 376 intra-area backbone and/or inter-area path go 377 to step 2. 378 1c. for other paths, skip the alternate ASBR and 379 consider next ASBR. 381 2. If cost type (type1/type2) advertised by alternate 382 ASBR same as primary 383 2a. If not same skip alternate ASBR and consider next ASBR. 385 3. If cost type is type1 386 3a. If cost is same, program ECMP 387 3b. else go to step 5. 389 4 If cost type is type 2 390 4a. If cost is different, skip alternate ASBR and 391 consider next ASBR 392 4b. If type2 cost is same, compare type 1 cost. 393 4c. If type1 cost is also same program ECMP. 394 4d. If type 1 cost is different go to step 5. 396 5. If route type (type 5/type 7) 397 5a. If route type is same, check route p-bit, 398 forwarding address field for routes from both 399 ASBRs 400 match. If not skip alternate ASBR and consider 401 next ASBR. 402 5b. If route type is not same, skip ASBR 403 and consider next ASBR. 405 6. Apply inequality on the alternate ASBR. 407 Figure 5: Rules for selecting alternate ASBR in OSPF 409 4.2.2. Multiple ASBRs belonging different area 411 When "RFC1583compatibility" is set to disabled, OSPF[RFC2328] defines 412 certain rules of preference to choose the ASBRs. While selecting 413 alternate ASBR for loop evaluation for LFA, these rules should be 414 applied and ensured that the alternate neighbor does not loop the 415 traffic back. 417 When there are multiple ASBRs belonging to different area advertising 418 the same prefix, pruning rules as defined in RFC 2328 section 16.4.1 419 are applied. The alternate ASBRs pruned using above rules are not 420 considered for LFA evaluation. 422 4.2.3. Type 1 and Type 2 costs 424 If there are multiple ASBRs not pruned via rules defined in 3.2.2, 425 the cost type advertised by the ASBRs is compared. ASBRs advertising 426 Type1 costs are preferred and the type2 costs are pruned. If two 427 ASBRs advertise same type2 cost, the alternate ASBRs are considered 428 along with their type1 cost for evaluation. If the two ASBRs with 429 same type2 as well as type1 cost, ECMP FRR is programmed. If there 430 are two ASBRs with different type2 cost, the higher cost ASBR is 431 pruned. The inequalities for evaluating alternate ASBR for type 1 432 and type 2 costs are same, as the alternate ASBRs with different 433 type2 costs are pruned and the evaluation is based on equal type 2 434 cost ASBRS. 436 4.2.4. RFC1583compatibility is set to enabled 438 When RFC1583Compatibility is set to enabled, multiple ASBRs belonging 439 to different area advertising same prefix are chosen based on cost 440 and hence are valid alternate ASBRs for the LFA evaluation. 442 4.2.5. Type 7 routes 444 Type 5 routes always get preference over Type 7 and the alternate 445 ASBRs chosen for LFA calculation should belong to same type.Among 446 Type 7 routes, routes with p-bit and forwarding address set have 447 higher preference than routes without these attributes. Alternate 448 ASBRs selected for LFA comparison should have same p-bit and 449 forwarding address attributes. 451 4.2.6. Inequalities to be applied for alternate ASBR selection 453 The alternate ASBRs selected using above mechanism described in 454 3.2.1, are evaluated for Loop free criteria using below inequalities. 456 4.2.6.1. Forwarding address set to non zero value 457 Link-Protection: 458 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 459 F_opt(S,PO_best) + cost(PO_best,P) 461 Link-Protection + Downstream-paths-only: 462 F_opt(N,PO_i)+ cost(PO_i,P) < F_opt(S,PO_best) + cost(PO_best,P) 464 Node-Protection: 465 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 466 F_opt(E,PO_best) + cost(PO_best,P) 468 Where, 469 S - The computing router 470 N - The alternate router being evaluated 471 E - The primary next-hop on shortest path from S to 472 prefix P. 473 PO_i - The specific prefix-originating router being 474 evaluated. 475 PO_best - The prefix-originating router on the shortest path 476 from the computing router S to prefix P. 477 cost(X,Y) - External cost for Y as advertised by X 478 F_opt(X,Y) - Distance on the shortest path from node X to Forwarding 479 address specified by ASBR Y. 480 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 482 Figure 6: LFA inequality definition when forwarding address in non- 483 zero 485 4.2.6.2. ASBRs advertising type1 and type2 cost 486 Link-Protection: 487 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 488 D_opt(S,PO_best) + cost(PO_best,P) 490 Link-Protection + Downstream-paths-only: 491 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 493 Node-Protection: 494 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 495 D_opt(E,PO_best) + cost(PO_best,P) 497 Where, 498 S - The computing router 499 N - The alternate router being evaluated 500 E - The primary next-hop on shortest path from S to 501 prefix P. 502 PO_i - The specific prefix-originating router being 503 evaluated. 504 PO_best - The prefix-originating router on the shortest path 505 from the computing router S to prefix P. 506 cost(X,Y) - External cost for Y as advertised by X. 507 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 509 Figure 7: LFA inequality definition for type1 and type 2 cost 511 5. LFA Extended Procedures 513 This section explains the additional considerations in various 514 aspects as listed below to the base LFA specification [RFC5286]. 516 5.1. Links with IGP MAX_METRIC 518 Section 3.5 and 3.6 of [RFC5286] describes procedures for excluding 519 nodes and links from use in alternate paths based on the maximum link 520 metric (as defined in for IS-IS in [RFC5305] or as defined in 521 [RFC3137] for OSPF). If these procedures are strictly followed, 522 there are situations, as described below, where the only potential 523 alternate available which satisfies the basic loop-free condition 524 will not be considered as alternative. 526 +---+ 10 +---+ 10 +---+ 527 | S |------|N1 |-----|D1 | 528 +---+ +---+ +---+ 529 | | 530 10 | 10 | 531 |MAX_MET(N2 to S) | 532 | | 533 | +---+ | 534 +-------|N2 |--------+ 535 +---+ 536 10 | 537 +---+ 538 |D2 | 539 +---+ 541 Figure 8: Link with IGP MAX_METRIC 543 In the simple example network, all the link costs have a cost of 10 544 in both directions, except for the link between S and N2. The S-N2 545 link has a cost of 10 in the direction from S to N2, and a cost of 546 MAX_METRIC in the direction from N2 to S (0xffffff /2^24 - 1 for IS- 547 IS and 0xffff for OSPF) for a specific end to end Traffic Engineering 548 (TE) requirement of the operator. At node S, D1 is reachable through 549 N1 with cost 20, and D2 is reachable through N2 with cost 20. Even 550 though neighbor N2 satisfies basic loop-free condition (inequality 1 551 of [RFC5286]) for D1 this could be excluded as potential alternative 552 because of the current exclusions as specified in section 3.5 and 3.6 553 procedure of [RFC5286]. But, as the primary traffic destined to D2 554 continue to use the link and hence irrespective of the reverse metric 555 in this case, the same link MAY be used as a potential LFA for D1. 557 Alternatively, reverse metric of the link MAY be configured with 558 MAX_METRIC-1, so that the link can be used as an alternative while 559 meeting the TE requirements. 561 5.2. Multi Topology Considerations 563 Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and 564 ISIS are out of scope for that specification. This memo clarifies 565 and describes the applicability. 567 In Multi Topology (MT) IGP deployments, for each MT ID, a separate 568 shortest path tree (SPT) is built with topology specific adjacencies, 569 the LFA principles laid out in [RFC5286] are actually applicable for 570 MT IS-IS [RFC5120] LFA SPF. The primary difference in this case is, 571 identifying the eligible-set of neighbors for each LFA computation 572 which is done per MT ID. The eligible-set for each MT ID is 573 determined by the presence of IGP adjacency from Source to the 574 neighboring node on that MT-ID apart from the administrative 575 restrictions and other checks laid out in [RFC5286]. The same is 576 also applicable for OSPF [RFC4915] [MT-OSPF] or different AFs in 577 multi instance OSPFv3 [RFC5838]. 579 However for MT IS-IS, if a default topology is used with MT-ID 0 580 [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are 581 present, then the condition of network congruency is applicable for 582 LFA computation as well. Network congruency here refers to, having 583 same address families provisioned on all the links and all the nodes 584 of the network with MT-ID 0. Here with single decision process both 585 IPv4 and IPv6 next-hops are computed for all the prefixes in the 586 network and similarly with one LFA computation from all eligible 587 neighbors per [RFC5286], all potential alternatives can be computed. 589 6. Acknowledgements 591 Thanks to Alia Atlas and Salih K A for their useful feedback and 592 inputs. 594 7. IANA Considerations 596 N/A. - No protocol changes are proposed in this document. 598 8. Security Considerations 600 This document does not introduce any change in any of the protocol 601 specifications and also this does not introduce any new security 602 issues other than as noted in the LFA base specification [RFC5286]. 604 9. References 606 9.1. Normative References 608 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 609 dual environments", RFC 1195, DOI 10.17487/RFC1195, 610 December 1990, . 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, 614 DOI 10.17487/RFC2119, March 1997, 615 . 617 9.2. Informative References 619 [I-D.ietf-rtgwg-lfa-manageability] 620 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., 621 Horneffer, M., and P. Sarkar, "Operational management of 622 Loop Free Alternates", draft-ietf-rtgwg-lfa- 623 manageability-11 (work in progress), June 2015. 625 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 626 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 627 DOI 10.17487/RFC3137, June 2001, 628 . 630 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 631 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 632 RFC 4915, DOI 10.17487/RFC4915, June 2007, 633 . 635 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 636 Topology (MT) Routing in Intermediate System to 637 Intermediate Systems (IS-ISs)", RFC 5120, 638 DOI 10.17487/RFC5120, February 2008, 639 . 641 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 642 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 643 DOI 10.17487/RFC5286, September 2008, 644 . 646 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 647 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 648 2008, . 650 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 651 DOI 10.17487/RFC5308, October 2008, 652 . 654 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 655 R. Aggarwal, "Support of Address Families in OSPFv3", 656 RFC 5838, DOI 10.17487/RFC5838, April 2010, 657 . 659 Authors' Addresses 660 Pushpasis Sarkar (editor) 661 Juniper Networks, Inc. 662 Electra, Exora Business Park 663 Bangalore, KA 560103 664 India 666 Email: psarkar@juniper.net; pushpasis.ietf@gmail.com 668 Shraddha Hegde 669 Juniper Networks, Inc. 670 Electra, Exora Business Park 671 Bangalore, KA 560103 672 India 674 Email: shraddha@juniper.net 676 Chris Bowers 677 Juniper Networks, Inc. 678 1194 N. Mathilda Ave. 679 Sunnyvale, CA 94089 680 US 682 Email: cbowers@juniper.net 684 Uma Chunduri (editor) 685 Ericsson Inc. 686 300 Holger Way, 687 San Jose, California 95134 688 USA 690 Phone: 408 750-5678 691 Email: uma.chunduri@ericsson.com 693 Jeff Tantsura 694 Ericsson Inc. 695 300 Holger Way, 696 San Jose, California 95134 697 USA 699 Email: jeff.tantsura@ericsson.com 700 Bruno Decraene 701 Orange 703 Email: bruno.decraene@orange.com 705 Hannes Gredler 706 Unaffiliated 708 Email: hannes@gredler.at