idnits 2.17.1 draft-ietf-rtgwg-multihomed-prefix-lfa-05.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 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 396 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 (February 6, 2018) is 2271 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 26, but not defined Summary: 1 error (**), 0 flaws (~~), 3 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 Arrcus, Inc. 4 Updates: 5286 (if approved) S. Hegde 5 Intended status: Standards Track Juniper Networks, Inc. 6 Expires: August 10, 2018 U. Chunduri, Ed. 7 Huawei USA 8 J. Tantsura 9 Individual 10 H. Gredler 11 RtBrick, Inc. 12 February 6, 2018 14 LFA selection for Multi-Homed Prefixes 15 draft-ietf-rtgwg-multihomed-prefix-lfa-05 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 [RFC 5286]. 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 August 10, 2018. 50 Copyright Notice 52 Copyright (c) 2018 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 90 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 94 10.2. Informative References . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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. 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 LSP - IS-IS Link State PDU 137 OSPF - Open Shortest Path First 139 MHP - Multi-homed Prefix 141 MT - Multi Topology 143 SPF - Shortest Path First PDU 145 2. LFA inequalities for MHPs 147 This document proposes the following set of LFA inequalities for 148 selecting the most appropriate LFAs for multi-homed prefixes (MHPs). 149 They can be derived from the inequalities in [RFC5286] combined with 150 the observation that D_opt(N,P) = Min (D_opt(N,PO_i) + cost(PO_i,P)) 151 over all PO_i 153 Link-Protection: 154 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 155 D_opt(S,PO_best) + cost(PO_best,P) 157 Link-Protection + Downstream-paths-only: 158 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 160 Node-Protection: 161 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 162 D_opt(E,PO_best) + cost(PO_best,P) 164 Where, 165 P - The multi-homed prefix being evaluated for 166 computing alternates 167 S - The computing router 168 N - The alternate router being evaluated 169 E - The primary next-hop on shortest path from S to 170 prefix P. 171 PO_i - The specific prefix-originating router being 172 evaluated. 173 PO_best - The prefix-originating router on the shortest path 174 from the computing router S to prefix P. 175 Cost (X,P) - Cost of reaching the prefix P from prefix 176 originating node X. 177 D_opt(X,Y) - Distance on the shortest path from node X to node 178 Y. 180 Figure 1: LFA inequalities for MHPs 182 3. LFA selection for the multi-homed prefixes 184 To compute a valid LFA for a given multi-homed prefix P, a computing 185 router S MUST follow one of the appropriate procedures below, for 186 each alternate neighbor N. 188 Link-Protection : 189 ================= 190 1. If alternate neighbor N is also prefix-originator of P, 191 1.a. Select N as a LFA for prefix P (irrespective of 192 the metric advertised by N for the prefix P). 193 2. Else, evaluate the link-protecting LFA inequality for P with 194 the N as the alternate neighbor. 195 2.a. If LFA inequality condition is met, 196 select N as a LFA for prefix P. 197 2.b. Else, N is not a LFA for prefix P. 199 Link-Protection + Downstream-paths-only : 200 ========================================= 201 1. Evaluate the link-protecting + downstream-only LFA inequality 202 for P with the N as the alternate neighbor. 203 1.a. If LFA inequality condition is met, 204 select N as a LFA for prefix P. 205 1.b. Else, N is not a LFA for prefix P. 207 Node-Protection : 208 ================= 209 1. If alternate neighbor N is also prefix-originator of P, 210 1.a. Select N as a LFA for prefix P (irrespective of 211 the metric advertised by N for the prefix P). 212 2. Else, evaluate the appropriate node-protecting LFA inequality 213 for P with the N as the alternate neighbor. 214 2.a. If LFA inequality condition is met, 215 select N as a LFA for prefix P. 216 2.b. Else, N is not a LFA for prefix P. 218 Figure 2: Rules for selecting LFA for MHPs 220 In case an alternate neighbor N is also one of the prefix-originators 221 of prefix P, N MAY be selected as a valid LFA for P since being a 222 prefix-originator it is guaranteed that N will not loop back packets 223 destined for prefix P to computing router S. 225 However, if N is not a prefix-originator of P, the computing router 226 SHOULD evaluate one of the corresponding LFA inequalities, as 227 mentioned in Figure 1, once for each remote node that originated the 228 prefix. In case the inequality is satisfied by the neighbor N router 229 S MUST choose neighbor N, as one of the valid LFAs for the prefix P. 231 When computing a downstream-only LFA, in addition to being a prefix- 232 originator of P, router N MUST also satisfy the downstream-only LFA 233 inequality specified in Figure 1. 235 For more specific rules please refer to the later sections of this 236 document. 238 3.1. Improved coverage with simplified approach to MHPs 240 LFA base specification [RFC5286] Section 6.1 recommends that a router 241 compute the alternate next-hop for an IGP multi-homed prefix by 242 considering alternate paths via all routers that have announced that 243 prefix and the same has been elaborated with appropriate inequalities 244 in the above section. However, [RFC5286] Section 6.1 also allows for 245 the router to simplify the multi-homed prefix calculation by assuming 246 that the MHP is solely attached to the router that was its pre- 247 failure optimal point of attachment, at the expense of potentially 248 lower coverage. If an implementation chooses to simplify the multi- 249 homed prefix calculation by assuming that the MHP is solely attached 250 to the router that was its pre-failure optimal point of attachment, 251 the procedure described in this memo can potentially improve coverage 252 for equal cost multi path (ECMP) MHPs without incurring extra 253 computational cost. 255 The approach specified in [RFC5286] Section 6.1 last paragraph, is to 256 simplify the MHP as solely attached to the router that was its pre- 257 failure optimal point of attachment; though it is a scalable approach 258 and simplifies computation, [RFC5286] notes this MAY result in little 259 less coverage. 261 This document improves the above approach to provide loop-free 262 alternatives without any additional cost for ECMP MHPs as described 263 through the below example network. The approach specified here MAY 264 also be applicable for handling default routes as explained in 265 Section 3.2. 267 5 +---+ 8 +---+ 5 +---+ 268 +-----| S |------| A |-----| B | 269 | +---+ +---+ +---+ 270 | | | 271 | 5 | 5 | 272 | | | 273 +---+ 5 +---+ 4 +---+ 1 +---+ 274 | C |---| E |-----| M |-------| F | 275 +---+ +---+ +---+ +---+ 276 | 10 5 | 277 +-----------p---------+ 279 Figure 3: MHP with same ECMP Next-hop 281 In the above network a prefix p, is advertised from both Node E and 282 Node F. With simplified approach taken as specified in [RFC5286] 283 Section 6.1, prefix p will get only link protection LFA through the 284 neighbor C while a node protection path is available through neighbor 285 A. In this scenario, E and F both are pre-failure optimal points of 286 attachment and share the same primary next-hop. Hence, an 287 implementation MAY compare the kind of protection A provides to F 288 (link-and-node protection) with the kind of protection C provides to 289 E (link protection) and inherit the better alternative to prefix p 290 and here it is A. 292 However, in the below network prefix p has an ECMP through both node 293 E and node F with cost 20. Though it has 2 pre-failure optimal 294 points of attachment, the primary next-hop to each pre-failure 295 optimal point of attachment is different. In this case, prefix p 296 MUST inherit corresponding LFAs of each primary next-hop calculated 297 for the router advertising the same respectively. In the below 298 diagram that would be node E's and node F's LFA i.e., node N1 and 299 node N2 respectively. 301 4 +----+ 302 +------------------| N2 | 303 | +----+ 304 | | 4 305 10 +---+ 3 +---+ 306 +------| S |----------------| B | 307 | +---+ +---+ 308 | | | 309 | 10 | 1 | 310 | | | 311 +----+ 5 +---+ 16 +---+ 312 | N1 |----| E |-----------------| F | 313 +----+ +---+ +---+ 314 | 10 16 | 315 +-----------p---------+ 317 Figure 4: MHP with different ECMP Next-hops 319 In summary, if there are multiple pre-failure points of attachment 320 for a MHP and primary next-hop of a MHP is same as that of the 321 primary next-hop of the router that was pre-failure optimal point of 322 attachment, an implementation MAY provide the better protection to 323 MHP without incurring any additional computation cost. 325 3.2. IS-IS ATT Bit considerations 327 Per [RFC1195] a default route needs to be added in Level1 (L1) router 328 to the closest reachable Level1/Level2 (L1/L2) router in the network 329 advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers 330 in the area would do this during the decision process with the next- 331 hop of the default route set to the adjacent router through which the 332 closest L1/L2 router is reachable. The base LFA specification 333 [RFC5286] does not specify any procedure for computing LFA for a 334 default route in IS-IS L1 area. This document specifies, potentially 335 a node MAY consider a default route is being advertised from the 336 border L1/L2 router where ATT bit is set and can do LFA computation 337 for the default route. But, when multiple ECMP L1/L2 routers are 338 reachable in an L1 area corresponding best LFAs SHOULD be given for 339 each primary next-hop associated with default route. Considerations 340 as specified in Section 3 and Section 3.1 are applicable for default 341 routes, if the default route is considered as ECMP MHP. Note that, 342 this document doesn't alter any ECMP handling rules or computation of 343 LFAs for ECMP in general as laid out in [RFC5286]. 345 4. LFA selection for the multi-homed external prefixes 347 Redistribution of external routes into IGP is required in case of two 348 different networks getting merged into one or during protocol 349 migrations. External routes could be distributed into an IGP domain 350 via multiple nodes to avoid a single point of failure. 352 During LFA calculation, alternate LFA next-hops to reach the best 353 ASBR could be used as LFA for the routes redistributed via that ASBR. 354 When there is no LFA available to the best ASBR, it may be desirable 355 to consider the other ASBRs (referred to as alternate ASBR hereafter) 356 redistributing the external routes for LFA selection as defined in 357 [RFC5286] and leverage the advantage of having multiple re- 358 distributing nodes in the network. 360 4.1. IS-IS 362 LFA evaluation for multi-homed external prefixes in IS-IS is similar 363 to the multi-homed internal prefixes. Inequalities described in sec 364 2 would also apply to multi-homed external prefixes as well. 366 4.2. OSPF 368 Loop free Alternates [RFC5286] describes mechanisms to apply 369 inequalities to find the loop free alternate neighbor. For the 370 selection of alternate ASBR for LFA consideration, additional rules 371 have to be applied in selecting the alternate ASBR due to the 372 external route calculation rules imposed by [RFC2328]. 374 This document also defines the inequalities defined in [RFC5286] 375 specifically for the alternate loop-free ASBR evaluation. 377 4.2.1. Rules to select alternate ASBR 379 The process to select an alternate ASBR is best explained using the 380 rules below. The below process is applied when primary ASBR for the 381 concerned prefix is chosen and there is an alternate ASBR originating 382 same prefix. 384 1. If RFC1583Compatibility is disabled 386 1a. if primary ASBR and alternate ASBR are intra area 387 non-backbone path go to step 2. 388 1b. If primary ASBR and alternate ASBR belong to 389 intra-area backbone and/or inter-area path go 390 to step 2. 391 1c. for other paths, skip this alternate ASBR and 392 consider next ASBR. 394 2. If cost type (type1/type2) advertised by alternate 395 ASBR same as primary 396 2a. If not, same skip alternate ASBR and consider 397 next ASBR. 398 2b. If same proceed to step 3. 400 3. If cost type is type1 401 3a. If cost is same, program ECMP and return. 402 3b. else go to step 5. 404 4 If cost type is type 2 405 4a. If cost is different, skip alternate ASBR and 406 consider next ASBR. 407 4b. If type2 cost is same, proceed to step 4c to compare 408 compare type 1 cost. 409 4c. If type1 cost is also same program ECMP and return. 410 4d. If type 1 cost is different go to step 5. 412 5. If route type (type 5/type 7) 413 5a. If route type is same, check route p-bit, 414 forwarding address field for routes from both 415 ASBRs match. If p-bit matches proceed to step 6. 416 If not, skip this alternate ASBR and consider 417 next ASBR. 418 5b. If route type is not same, skip this alternate ASBR 419 and consider next alternate ASBR. 421 6. Apply inequality on the alternate ASBR. 423 Figure 5: Rules for selecting alternate ASBR in OSPF 425 4.2.2. Multiple ASBRs belonging different area 427 When "RFC1583compatibility" is set to disabled, OSPF [RFC2328] 428 defines certain rules of preference to choose the ASBRs. While 429 selecting alternate ASBR for loop evaluation for LFA, these rules 430 should be applied and ensured that the alternate neighbor does not 431 loop the traffic back. 433 When there are multiple ASBRs belonging to different area advertising 434 the same prefix, pruning rules as defined in [RFC2328] section 16.4.1 435 are applied. The alternate ASBRs pruned using above rules are not 436 considered for LFA evaluation. 438 4.2.3. Type 1 and Type 2 costs 440 If there are multiple ASBRs not pruned via rules defined in 441 Section 4.2.2, the cost type advertised by the ASBRs is compared. 442 ASBRs advertising Type1 costs are preferred and the type2 costs are 443 pruned. If two ASBRs advertise same type2 cost, the alternate ASBRs 444 are considered along with their type1 cost for evaluation. If the 445 two ASBRs with same type2 as well as type1 cost, ECMP FRR is 446 programmed. If there are two ASBRs with different type2 cost, the 447 higher cost ASBR is pruned. The inequalities for evaluating 448 alternate ASBR for type 1 and type 2 costs are same, as the alternate 449 ASBRs with different type2 costs are pruned and the evaluation is 450 based on equal type 2 cost ASBRS. 452 4.2.4. RFC1583compatibility is set to enabled 454 When RFC1583Compatibility is set to enabled, multiple ASBRs belonging 455 to different area advertising same prefix are chosen based on cost 456 and hence are valid alternate ASBRs for the LFA evaluation. 458 4.2.5. Type 7 routes 460 Type 5 routes always get preference over Type 7 and the alternate 461 ASBRs chosen for LFA calculation should belong to same type. Among 462 Type 7 routes, routes with p-bit and forwarding address set have 463 higher preference than routes without these attributes. Alternate 464 ASBRs selected for LFA comparison should have same p-bit and 465 forwarding address attributes. 467 4.2.6. Inequalities to be applied for alternate ASBR selection 469 The alternate ASBRs selected using above mechanism described in 470 Section 4.2.1, are evaluated for Loop free criteria using below 471 inequalities. 473 4.2.6.1. Forwarding address set to non-zero value 474 Link-Protection: 475 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 476 F_opt(S,PO_best) + cost(PO_best,P) 478 Link-Protection + Downstream-paths-only: 479 F_opt(N,PO_i)+ cost(PO_i,P) < F_opt(S,PO_best) + cost(PO_best,P) 481 Node-Protection: 482 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 483 F_opt(E,PO_best) + cost(PO_best,P) 485 Where, 486 S - The computing router 487 N - The alternate router being evaluated 488 E - The primary next-hop on shortest path from S to 489 prefix P. 490 PO_i - The specific prefix-originating router being 491 evaluated. 492 PO_best - The prefix-originating router on the shortest path 493 from the computing router S to prefix P. 494 cost(X,Y) - External cost for Y as advertised by X 495 F_opt(X,Y) - Distance on the shortest path from node X to Forwarding 496 address specified by ASBR Y. 497 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 499 Figure 6: LFA inequality definition when forwarding address is non- 500 zero 502 4.2.6.2. ASBRs advertising type1 and type2 cost 503 Link-Protection: 504 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 505 D_opt(S,PO_best) + cost(PO_best,P) 507 Link-Protection + Downstream-paths-only: 508 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 510 Node-Protection: 511 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 512 D_opt(E,PO_best) + cost(PO_best,P) 514 Where, 515 S - The computing router 516 N - The alternate router being evaluated 517 E - The primary next-hop on shortest path from S to 518 prefix P. 519 PO_i - The specific prefix-originating router being 520 evaluated. 521 PO_best - The prefix-originating router on the shortest path 522 from the computing router S to prefix P. 523 cost(X,Y) - External cost for Y as advertised by X. 524 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 526 Figure 7: LFA inequality definition for type1 and type 2 cost 528 5. LFA Extended Procedures 530 This section explains the additional considerations in various 531 aspects as listed below to the base LFA specification [RFC5286]. 533 5.1. Links with IGP MAX_METRIC 535 Section 3.5 and 3.6 of [RFC5286] describes procedures for excluding 536 nodes and links from use in alternate paths based on the maximum link 537 metric (as defined in for IS-IS in [RFC5305] or as defined in 538 [RFC6987] for OSPF). If these procedures are strictly followed, 539 there are situations, as described below, where the only potential 540 alternate available which satisfies the basic loop-free condition 541 will not be considered as alternative. 543 +---+ 10 +---+ 10 +---+ 544 | S |------|N1 |-----|D1 | 545 +---+ +---+ +---+ 546 | | 547 10 | 10 | 548 |MAX_MET(N2 to S) | 549 | | 550 | +---+ | 551 +-------|N2 |--------+ 552 +---+ 553 10 | 554 +---+ 555 |D2 | 556 +---+ 558 Figure 8: Link with IGP MAX_METRIC 560 In the simple example network, all the link costs have a cost of 10 561 in both directions, except for the link between S and N2. The S-N2 562 link has a cost of 10 in the forward direction i.e., from S to N2, 563 and a cost of MAX_METRIC (0xffffff /2^24 - 1 for IS-IS and 0xffff for 564 OSPF) in the reverse direction i.e., from N2 to S for a specific end- 565 to-end Traffic Engineering (TE) requirement of the operator. At node 566 S, D1 is reachable through N1 with cost 20, and D2 is reachable 567 through N2 with cost 20. Even though neighbor N2 satisfies basic 568 loop-free condition (inequality 1 of [RFC5286]) for D1, S's neighbor 569 N2 could be excluded as a potential alternative because of the 570 current exclusions as specified in section 3.5 and 3.6 procedure of 571 [RFC5286]. But, as the primary traffic destined to D2 continue to 572 use the link and hence irrespective of the reverse metric in this 573 case, same link MAY be used as a potential LFA for D1. 575 Alternatively, reverse metric of the link MAY be configured with 576 MAX_METRIC-1, so that the link can be used as an alternative while 577 meeting the operator's TE requirements and without having to update 578 the router to fix this particular issue. 580 5.2. Multi Topology Considerations 582 Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and 583 ISIS are out of scope for that specification. This memo clarifies 584 and describes the applicability. 586 In Multi Topology (MT) IGP deployments, for each MT ID, a separate 587 shortest path tree (SPT) is built with topology specific adjacencies, 588 the LFA principles laid out in [RFC5286] are actually applicable for 589 MT IS-IS [RFC5120] LFA SPF. The primary difference in this case is, 590 identifying the eligible-set of neighbors for each LFA computation 591 which is done per MT ID. The eligible-set for each MT ID is 592 determined by the presence of IGP adjacency from Source to the 593 neighboring node on that MT-ID apart from the administrative 594 restrictions and other checks laid out in [RFC5286]. The same is 595 also applicable for MT-OSPF [RFC4915] or different AFs in multi 596 instance OSPFv3 [RFC5838]. 598 However for MT IS-IS, if a "standard topology" is used with MT-ID #0 599 [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are 600 present, then the condition of network congruency is applicable for 601 LFA computation as well. Network congruency here refers to, having 602 same address families provisioned on all the links and all the nodes 603 of the network with MT-ID #0. Here with single decision process both 604 IPv4 and IPv6 next-hops are computed for all the prefixes in the 605 network and similarly with one LFA computation from all eligible 606 neighbors per [RFC5286], all potential alternatives can be computed. 608 6. IANA Considerations 610 This document has no actions for IANA. 612 7. Acknowledgements 614 Thanks to Alia Atlas and Salih K A for their useful feedback and 615 inputs. Thanks to Stewart Bryant for being document shepherd and 616 providing detailed review comments. 618 8. Contributing Authors 620 The following people contributed substantially to the content of this 621 document and should be considered co-authors. 623 Chris Bowers 624 Juniper Networks, Inc. 625 1194 N. Mathilda Ave, 626 Sunnyvale, CA 94089, USA 628 Email: cbowers@juniper.ne 630 Bruno Decraene 631 Orange, 632 France 634 Email: bruno.decraene@orange.com 636 9. Security Considerations 638 This document does not introduce any change in any of the protocol 639 [RFC1195] [RFC5120] [RFC2328] [RFC5838] specifications discussed here 640 and also this does not introduce any new security issues other than 641 as noted in the LFA base specification [RFC5286]. 643 10. References 645 10.1. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, 650 . 652 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 653 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 654 DOI 10.17487/RFC5286, September 2008, 655 . 657 10.2. Informative References 659 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 660 dual environments", RFC 1195, DOI 10.17487/RFC1195, 661 December 1990, . 663 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 664 DOI 10.17487/RFC2328, April 1998, 665 . 667 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 668 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 669 RFC 4915, DOI 10.17487/RFC4915, June 2007, 670 . 672 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 673 Topology (MT) Routing in Intermediate System to 674 Intermediate Systems (IS-ISs)", RFC 5120, 675 DOI 10.17487/RFC5120, February 2008, 676 . 678 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 679 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 680 2008, . 682 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 683 DOI 10.17487/RFC5308, October 2008, 684 . 686 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 687 R. Aggarwal, "Support of Address Families in OSPFv3", 688 RFC 5838, DOI 10.17487/RFC5838, April 2010, 689 . 691 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 692 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 693 DOI 10.17487/RFC6987, September 2013, 694 . 696 Authors' Addresses 698 Pushpasis Sarkar (editor) 699 Arrcus, Inc. 701 Email: pushpasis.ietf@gmail.com 703 Shraddha Hegde 704 Juniper Networks, Inc. 705 Electra, Exora Business Park 706 Bangalore, KA 560103 707 India 709 Email: shraddha@juniper.net 711 Uma Chunduri (editor) 712 Huawei USA 713 2330 Central Expressway 714 Santa Clara, CA 95050 715 USA 717 Email: uma.chunduri@huawei.com 719 Jeff Tantsura 720 Individual 722 Email: jefftant.ietf@gmail.com 723 Hannes Gredler 724 RtBrick, Inc. 726 Email: hannes@rtbrick.com