idnits 2.17.1 draft-ietf-rtgwg-multihomed-prefix-lfa-02.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 387 has weird spacing: '... 2a. If not s...' (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 (July 25, 2017) is 2467 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) == Missing Reference: 'RFC 5286' is mentioned on line 359, but not defined == Missing Reference: 'RFC 2328' is mentioned on line 363, but not defined -- Looks like a reference, but probably isn't: '5286' on line 365 == Missing Reference: 'RFC2328' is mentioned on line 415, but not defined == Missing Reference: 'MT-OSPF' is mentioned on line 580, but not defined == Unused Reference: 'RFC7916' is defined on line 653, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 5 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 Updates: 5286 (if approved) S. Hegde 5 Intended status: Standards Track C. Bowers 6 Expires: January 26, 2018 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 July 25, 2017 17 LFA selection for Multi-Homed Prefixes 18 draft-ietf-rtgwg-multihomed-prefix-lfa-02 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. 28 This documents updates and expands some of the "Routing Aspects" as 29 specified in Section 6 of [RFC5286]. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 26, 2018. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. LFA inequalities for MHPs . . . . . . . . . . . . . . . . . . 4 74 3. LFA selection for the multi-homed prefixes . . . . . . . . . 4 75 3.1. Improved coverage with simplified approach to MHPs . . . 6 76 3.2. IS-IS ATT Bit considerations . . . . . . . . . . . . . . 7 77 4. LFA selection for the multi-homed external prefixes . . . . . 8 78 4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.2.1. Rules to select alternate ASBR . . . . . . . . . . . 8 81 4.2.2. Multiple ASBRs belonging different area . . . . . . . 9 82 4.2.3. Type 1 and Type 2 costs . . . . . . . . . . . . . . . 10 83 4.2.4. RFC1583compatibility is set to enabled . . . . . . . 10 84 4.2.5. Type 7 routes . . . . . . . . . . . . . . . . . . . . 10 85 4.2.6. Inequalities to be applied for alternate ASBR 86 selection . . . . . . . . . . . . . . . . . . . . . . 10 87 4.2.6.1. Forwarding address set to non-zero value . . . . 10 88 4.2.6.2. ASBRs advertising type1 and type2 cost . . . . . 11 89 5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 12 90 5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 12 91 5.2. Multi Topology Considerations . . . . . . . . . . . . . . 13 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 96 8.2. Informative References . . . . . . . . . . . . . . . . . 14 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 100 1. Introduction 102 The use of Loop-Free Alternates (LFA) for IP Fast Reroute is 103 specified in [RFC5286]. Section 6.1 of [RFC5286] describes a method 104 to determine loop-free alternates for a multi-homed prefixes (MHPs). 105 This document describes a procedure using explicit inequalities that 106 can be used by a computing router to evaluate a neighbor as a 107 potential alternate for a multi-homed prefix. The results obtained 108 are equivalent to those obtained using the method described in 109 Section 6.1 of [RFC5286]. However, some may find this formulation 110 useful. 112 Section 6.3 of [RFC5286] discusses complications associated with 113 computing LFAs for multi-homed prefixes in OSPF. This document 114 provides detailed criteria for evaluating potential alternates for 115 external prefixes advertised by OSPF ASBRs, as well as explicit 116 inequalities. 118 This document also provide clarifications, additional considerations 119 to [RFC5286], to address a few coverage and operational observations. 120 These observations are in the area of handling IS-IS attach (ATT) bit 121 in Level-1 (L1) area, links provisioned with MAX_METRIC for traffic 122 engineering (TE) purposes and in the area of Multi Topology (MT) IGP 123 deployments. These are elaborated in detail in Section 3.2 and 124 Section 5. 126 1.1. Acronyms 128 AF - Address Family 130 ATT - IS-IS Attach Bit 132 ECMP - Equal Cost Multi Path 134 IGP - Interior Gateway Protocol 136 IS-IS - Intermediate System to Intermediate System 138 OSPF - Open Shortest Path First 140 MHP - Multi-homed Prefix 142 MT - Multi Topology 144 SPF - Shortest Path First PDU 146 2. LFA inequalities for MHPs 148 This document proposes the following set of LFA inequalities for 149 selecting the most appropriate LFAs for multi-homed prefixes (MHPs). 150 They can be derived from the inequalities in [RFC5286] combined with 151 the observation that D_opt(N,P) = Min (D_opt(N,PO_i) + cost(PO_i,P)) 152 over all PO_i 154 Link-Protection: 155 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 156 D_opt(S,PO_best) + cost(PO_best,P) 158 Link-Protection + Downstream-paths-only: 159 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 161 Node-Protection: 162 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 163 D_opt(E,PO_best) + cost(PO_best,P) 165 Where, 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, through an 184 alternate neighbor N a computing router S MUST follow one of the 185 appropriate procedures below. 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. 222 However, if N is not a prefix-originator of P, the computing router 223 SHOULD evaluate one of the corresponding LFA inequalities, as 224 mentioned in Figure 1, once for each remote node that originated the 225 prefix. In case the inequality is satisfied by the neighbor N router 226 S MUST choose neighbor N, as one of the valid LFAs for the prefix P. 228 When computing a downstream-only LFA, in addition to being a prefix- 229 originator of P, router N MUST also satisfy the downstream-only LFA 230 inequality specified in Figure 1. 232 For more specific rules please refer to the later sections of this 233 document. 235 3.1. Improved coverage with simplified approach to MHPs 237 LFA base specification [RFC5286] Section 6.1 recommends that a router 238 compute the alternate next-hop for an IGP multi-homed prefix by 239 considering alternate paths via all routers that have announced that 240 prefix and the same has been elaborated with appropriate inequalities 241 in the above section. However, [RFC5286] Section 6.1 also allows for 242 the router to simplify the multi-homed prefix calculation by assuming 243 that the MHP is solely attached to the router that was its pre- 244 failure optimal point of attachment, at the expense of potentially 245 lower coverage. If an implementation chooses to simplify the multi- 246 homed prefix calculation by assuming that the MHP is solely attached 247 to the router that was its pre-failure optimal point of attachment, 248 the procedure described in this memo can potentially improve coverage 249 for equal cost multi path (ECMP) MHPs without incurring extra 250 computational cost. 252 The approach specified in [RFC5286] Section 6.1 last paragraph, is to 253 simplify the MHP as solely attached to the router that was its pre- 254 failure optimal point of attachment; though it is a scalable approach 255 and simplifies computation, [RFC5286] notes this may result in little 256 less coverage. 258 This document improves the above approach to provide loop-free 259 alternatives without any additional cost for equal cost multi path 260 MHPs as described through the below example network. The approach 261 specified here MAY also be applicable for handling default routes as 262 explained in Section 3.2. 264 5 +---+ 8 +---+ 5 +---+ 265 +-----| S |------| A |-----| B | 266 | +---+ +---+ +---+ 267 | | | 268 | 5 | 5 | 269 | | | 270 +---+ 5 +---+ 4 +---+ 1 +---+ 271 | C |---| E |-----| M |-------| F | 272 +---+ +---+ +---+ +---+ 273 | 10 5 | 274 +-----------p---------+ 276 Figure 3: MHP with same ECMP Next-hop 278 In the above network a prefix p, is advertised from both Node E and 279 Node F. With simplified approach taken as specified in [RFC5286] 280 Section 6.1, prefix p will get only link protection LFA through the 281 neighbor C while a node protection path is available through neighbor 282 A. In this scenario, E and F both are pre-failure optimal points of 283 attachment and share the same primary next-hop. Hence, an 284 implementation MAY compare the kind of protection A provides to F 285 (link-and-node protection) with the kind of protection C provides to 286 E (link protection) and inherit the better alternative to prefix p 287 and here it is A. 289 However, in the below network prefix p has an ECMP through both node 290 E and node F with cost 20. Though it has 2 pre-failure optimal 291 points of attachment, the primary next-hop to each pre-failure 292 optimal point of attachment is different. In this case, prefix p 293 shall inherit corresponding LFA to each primary next-hop calculated 294 for the router advertising the same respectively (node E's and node 295 F's LFA). 297 +---+ 3 +---+ 298 | S |----------------| B | 299 +---+ +---+ 300 | | 301 10 | 1 | 302 | | 303 +---+ 6 +---+ 304 | E |-----------------| F | 305 +---+ +---+ 306 | 10 16 | 307 +-----------p---------+ 309 Figure 4: MHP with different ECMP Next-hops 311 In summary, if there are multiple pre-failure points of attachment 312 for a MHP and primary next-hop of a MHP is same as that of the 313 primary next-hop of the router that was pre-failure optimal point of 314 attachment, an implementation MAY provide the better protection to 315 MHP without incurring any additional computation cost. 317 3.2. IS-IS ATT Bit considerations 319 Per [RFC1195] a default route needs to be added in Level1 (L1) router 320 to the closest reachable Level1/Level2 (L1/L2) router in the network 321 advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers 322 in the area would do this during the decision process with the next- 323 hop of the default route set to the adjacent router through which the 324 closest L1/L2 router is reachable. The base LFA specification 325 [RFC5286] does not specify any procedure for computing LFA for a 326 default route in IS-IS L1 area. Potentially one MAY consider a 327 default route is being advertised from the border L1/L2 router where 328 ATT bit is set and can do LFA computation for the default route. 330 But, when multiple ECMP L1/L2 routers are reachable in an L1 area 331 corresponding best LFAs SHOULD be given for each primary next-hop 332 associated with default route. Considerations as specified in 333 Section 3 and Section 3.1 are applicable for default routes, if the 334 default route is considered as ECMP MHP. 336 4. LFA selection for the multi-homed external prefixes 338 Redistribution of external routes into IGP is required in case of two 339 different networks getting merged into one or during protocol 340 migrations. External routes could be distributed into an IGP domain 341 via multiple nodes to avoid a single point of failure. 343 During LFA calculation, alternate LFA next-hops to reach the best 344 ASBR could be used as LFA for the routes redistributed via that ASBR. 345 When there is no LFA available to the best ASBR, it may be desirable 346 to consider the other ASBRs (referred to as alternate ASBR hereafter) 347 redistributing the external routes for LFA selection as defined in 348 [RFC5286] and leverage the advantage of having multiple re- 349 distributing nodes in the network. 351 4.1. IS-IS 353 LFA evaluation for multi-homed external prefixes in IS-IS is similar 354 to the multi-homed internal prefixes. Inequalities described in sec 355 2 would also apply to multi-homed external prefixes as well. 357 4.2. OSPF 359 Loop free Alternates [RFC 5286] describes mechanisms to apply 360 inequalities to find the loop free alternate neighbor. For the 361 selection of alternate ASBR for LFA consideration, additional rules 362 have to be applied in selecting the alternate ASBR due to the 363 external route calculation rules imposed by [RFC 2328]. 365 This document also defines the inequalities defined in RFC [5286] 366 specifically for the alternate loop-free ASBR evaluation. 368 4.2.1. Rules to select alternate ASBR 370 The process to select an alternate ASBR is best explained using the 371 rules below. The below process is applied when primary ASBR for the 372 concerned prefix is chosen and there is an alternate ASBR originating 373 same prefix. 375 1. If RFC1583Compatibility is disabled 377 1a. if primary ASBR and alternate ASBR are intra area 378 non-backbone path go to step 2. 379 1b. If primary ASBR and alternate ASBR belong to 380 intra-area backbone and/or inter-area path go 381 to step 2. 382 1c. for other paths, skip the alternate ASBR and 383 consider next ASBR. 385 2. If cost type (type1/type2) advertised by alternate 386 ASBR same as primary 387 2a. If not same skip alternate ASBR and consider next ASBR. 389 3. If cost type is type1 390 3a. If cost is same, program ECMP 391 3b. else go to step 5. 393 4 If cost type is type 2 394 4a. If cost is different, skip alternate ASBR and 395 consider next ASBR 396 4b. If type2 cost is same, compare type 1 cost. 397 4c. If type1 cost is also same program ECMP. 398 4d. If type 1 cost is different go to step 5. 400 5. If route type (type 5/type 7) 401 5a. If route type is same, check route p-bit, 402 forwarding address field for routes from both 403 ASBRs 404 match. If not skip alternate ASBR and consider 405 next ASBR. 406 5b. If route type is not same, skip ASBR 407 and consider next ASBR. 409 6. Apply inequality on the alternate ASBR. 411 Figure 5: Rules for selecting alternate ASBR in OSPF 413 4.2.2. Multiple ASBRs belonging different area 415 When "RFC1583compatibility" is set to disabled, OSPF[RFC2328] defines 416 certain rules of preference to choose the ASBRs. While selecting 417 alternate ASBR for loop evaluation for LFA, these rules should be 418 applied and ensured that the alternate neighbor does not loop the 419 traffic back. 421 When there are multiple ASBRs belonging to different area advertising 422 the same prefix, pruning rules as defined in RFC 2328 section 16.4.1 423 are applied. The alternate ASBRs pruned using above rules are not 424 considered for LFA evaluation. 426 4.2.3. Type 1 and Type 2 costs 428 If there are multiple ASBRs not pruned via rules defined in 3.2.2, 429 the cost type advertised by the ASBRs is compared. ASBRs advertising 430 Type1 costs are preferred and the type2 costs are pruned. If two 431 ASBRs advertise same type2 cost, the alternate ASBRs are considered 432 along with their type1 cost for evaluation. If the two ASBRs with 433 same type2 as well as type1 cost, ECMP FRR is programmed. If there 434 are two ASBRs with different type2 cost, the higher cost ASBR is 435 pruned. The inequalities for evaluating alternate ASBR for type 1 436 and type 2 costs are same, as the alternate ASBRs with different 437 type2 costs are pruned and the evaluation is based on equal type 2 438 cost ASBRS. 440 4.2.4. RFC1583compatibility is set to enabled 442 When RFC1583Compatibility is set to enabled, multiple ASBRs belonging 443 to different area advertising same prefix are chosen based on cost 444 and hence are valid alternate ASBRs for the LFA evaluation. 446 4.2.5. Type 7 routes 448 Type 5 routes always get preference over Type 7 and the alternate 449 ASBRs chosen for LFA calculation should belong to same type. Among 450 Type 7 routes, routes with p-bit and forwarding address set have 451 higher preference than routes without these attributes. Alternate 452 ASBRs selected for LFA comparison should have same p-bit and 453 forwarding address attributes. 455 4.2.6. Inequalities to be applied for alternate ASBR selection 457 The alternate ASBRs selected using above mechanism described in 458 3.2.1, are evaluated for Loop free criteria using below inequalities. 460 4.2.6.1. Forwarding address set to non-zero value 461 Link-Protection: 462 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 463 F_opt(S,PO_best) + cost(PO_best,P) 465 Link-Protection + Downstream-paths-only: 466 F_opt(N,PO_i)+ cost(PO_i,P) < F_opt(S,PO_best) + cost(PO_best,P) 468 Node-Protection: 469 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 470 F_opt(E,PO_best) + cost(PO_best,P) 472 Where, 473 S - The computing router 474 N - The alternate router being evaluated 475 E - The primary next-hop on shortest path from S to 476 prefix P. 477 PO_i - The specific prefix-originating router being 478 evaluated. 479 PO_best - The prefix-originating router on the shortest path 480 from the computing router S to prefix P. 481 cost(X,Y) - External cost for Y as advertised by X 482 F_opt(X,Y) - Distance on the shortest path from node X to Forwarding 483 address specified by ASBR Y. 484 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 486 Figure 6: LFA inequality definition when forwarding address in non- 487 zero 489 4.2.6.2. ASBRs advertising type1 and type2 cost 490 Link-Protection: 491 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 492 D_opt(S,PO_best) + cost(PO_best,P) 494 Link-Protection + Downstream-paths-only: 495 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 497 Node-Protection: 498 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 499 D_opt(E,PO_best) + cost(PO_best,P) 501 Where, 502 S - The computing router 503 N - The alternate router being evaluated 504 E - The primary next-hop on shortest path from S to 505 prefix P. 506 PO_i - The specific prefix-originating router being 507 evaluated. 508 PO_best - The prefix-originating router on the shortest path 509 from the computing router S to prefix P. 510 cost(X,Y) - External cost for Y as advertised by X. 511 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 513 Figure 7: LFA inequality definition for type1 and type 2 cost 515 5. LFA Extended Procedures 517 This section explains the additional considerations in various 518 aspects as listed below to the base LFA specification [RFC5286]. 520 5.1. Links with IGP MAX_METRIC 522 Section 3.5 and 3.6 of [RFC5286] describes procedures for excluding 523 nodes and links from use in alternate paths based on the maximum link 524 metric (as defined in for IS-IS in [RFC5305] or as defined in 525 [RFC3137] for OSPF). If these procedures are strictly followed, 526 there are situations, as described below, where the only potential 527 alternate available which satisfies the basic loop-free condition 528 will not be considered as alternative. 530 +---+ 10 +---+ 10 +---+ 531 | S |------|N1 |-----|D1 | 532 +---+ +---+ +---+ 533 | | 534 10 | 10 | 535 |MAX_MET(N2 to S) | 536 | | 537 | +---+ | 538 +-------|N2 |--------+ 539 +---+ 540 10 | 541 +---+ 542 |D2 | 543 +---+ 545 Figure 8: Link with IGP MAX_METRIC 547 In the simple example network, all the link costs have a cost of 10 548 in both directions, except for the link between S and N2. The S-N2 549 link has a cost of 10 in the direction from S to N2, and a cost of 550 MAX_METRIC in the direction from N2 to S (0xffffff /2^24 - 1 for IS- 551 IS and 0xffff for OSPF) for a specific end to end Traffic Engineering 552 (TE) requirement of the operator. At node S, D1 is reachable through 553 N1 with cost 20, and D2 is reachable through N2 with cost 20. Even 554 though neighbor N2 satisfies basic loop-free condition (inequality 1 555 of [RFC5286]) for D1 this could be excluded as potential alternative 556 because of the current exclusions as specified in section 3.5 and 3.6 557 procedure of [RFC5286]. But, as the primary traffic destined to D2 558 continue to use the link and hence irrespective of the reverse metric 559 in this case, the same link MAY be used as a potential LFA for D1. 561 Alternatively, reverse metric of the link MAY be configured with 562 MAX_METRIC-1, so that the link can be used as an alternative while 563 meeting the TE requirements. 565 5.2. Multi Topology Considerations 567 Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and 568 ISIS are out of scope for that specification. This memo clarifies 569 and describes the applicability. 571 In Multi Topology (MT) IGP deployments, for each MT ID, a separate 572 shortest path tree (SPT) is built with topology specific adjacencies, 573 the LFA principles laid out in [RFC5286] are actually applicable for 574 MT IS-IS [RFC5120] LFA SPF. The primary difference in this case is, 575 identifying the eligible-set of neighbors for each LFA computation 576 which is done per MT ID. The eligible-set for each MT ID is 577 determined by the presence of IGP adjacency from Source to the 578 neighboring node on that MT-ID apart from the administrative 579 restrictions and other checks laid out in [RFC5286]. The same is 580 also applicable for OSPF [RFC4915] [MT-OSPF] or different AFs in 581 multi instance OSPFv3 [RFC5838]. 583 However for MT IS-IS, if a default topology is used with MT-ID 0 584 [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are 585 present, then the condition of network congruency is applicable for 586 LFA computation as well. Network congruency here refers to, having 587 same address families provisioned on all the links and all the nodes 588 of the network with MT-ID 0. Here with single decision process both 589 IPv4 and IPv6 next-hops are computed for all the prefixes in the 590 network and similarly with one LFA computation from all eligible 591 neighbors per [RFC5286], all potential alternatives can be computed. 593 6. Acknowledgements 595 Thanks to Alia Atlas and Salih K A for their useful feedback and 596 inputs. 598 7. 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 8. References 606 8.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 8.2. Informative References 619 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 620 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 621 DOI 10.17487/RFC3137, June 2001, 622 . 624 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 625 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 626 RFC 4915, DOI 10.17487/RFC4915, June 2007, 627 . 629 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 630 Topology (MT) Routing in Intermediate System to 631 Intermediate Systems (IS-ISs)", RFC 5120, 632 DOI 10.17487/RFC5120, February 2008, 633 . 635 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 636 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 637 DOI 10.17487/RFC5286, September 2008, 638 . 640 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 641 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 642 2008, . 644 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 645 DOI 10.17487/RFC5308, October 2008, 646 . 648 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 649 R. Aggarwal, "Support of Address Families in OSPFv3", 650 RFC 5838, DOI 10.17487/RFC5838, April 2010, 651 . 653 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 654 Horneffer, M., and P. Sarkar, "Operational Management of 655 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 656 July 2016, . 658 Authors' Addresses 660 Pushpasis Sarkar (editor) 661 Individual 663 Email: pushpasis.ietf@gmail.com 664 Shraddha Hegde 665 Juniper Networks, Inc. 666 Electra, Exora Business Park 667 Bangalore, KA 560103 668 India 670 Email: shraddha@juniper.net 672 Chris Bowers 673 Juniper Networks, Inc. 674 1194 N. Mathilda Ave. 675 Sunnyvale, CA 94089 676 US 678 Email: cbowers@juniper.net 680 Uma Chunduri (editor) 681 Huawei Technologies 682 2330 Central Expressway 683 Santa Clara, CA 95050 684 USA 686 Email: uma.chunduri@huawei.com 688 Jeff Tantsura 689 Individual 691 Email: jefftant.ietf@gmail.com 693 Bruno Decraene 694 Orange 696 Email: bruno.decraene@orange.com 698 Hannes Gredler 699 RtBrick, Inc. 701 Email: hannes@rtbrick.com