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