idnits 2.17.1 draft-ietf-rtgwg-multihomed-prefix-lfa-06.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 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 (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 8, 2018) is 2263 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 12, 2018 U. Chunduri, Ed. 7 Huawei USA 8 J. Tantsura 9 Nuage Networks 10 H. Gredler 11 RtBrick, Inc. 12 February 8, 2018 14 LFA selection for Multi-Homed Prefixes 15 draft-ietf-rtgwg-multihomed-prefix-lfa-06 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 12, 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 next ASBR. 397 2b. If same proceed to step 3. 399 3. If cost type is type1 400 3a. If cost is same, program ECMP and return. 401 3b. else go to step 5. 403 4 If cost type is type 2 404 4a. If cost is different, skip alternate ASBR and 405 consider next ASBR. 406 4b. If type2 cost is same, proceed to step 4c to compare 407 compare type 1 cost. 408 4c. If type1 cost is also same program ECMP and return. 409 4d. If type 1 cost is different go to step 5. 411 5. If route type (type 5/type 7) 412 5a. If route type is same, check route p-bit, 413 forwarding address field for routes from both 414 ASBRs match. If p-bit matches proceed to step 6. 415 If not, skip this alternate ASBR and consider 416 next ASBR. 417 5b. If route type is not same, skip this alternate ASBR 418 and consider next alternate ASBR. 420 6. Apply inequality on the alternate ASBR. 422 Figure 5: Rules for selecting alternate ASBR in OSPF 424 4.2.2. Multiple ASBRs belonging different area 426 When "RFC1583compatibility" is set to disabled, OSPF [RFC2328] 427 defines certain rules of preference to choose the ASBRs. While 428 selecting alternate ASBR for loop evaluation for LFA, these rules 429 should be applied and ensured that the alternate neighbor does not 430 loop the traffic back. 432 When there are multiple ASBRs belonging to different area advertising 433 the same prefix, pruning rules as defined in [RFC2328] section 16.4.1 434 are applied. The alternate ASBRs pruned using above rules are not 435 considered for LFA evaluation. 437 4.2.3. Type 1 and Type 2 costs 439 If there are multiple ASBRs not pruned via rules defined in 440 Section 4.2.2, the cost type advertised by the ASBRs is compared. 441 ASBRs advertising Type1 costs are preferred and the type2 costs are 442 pruned. If two ASBRs advertise same type2 cost, the alternate ASBRs 443 are considered along with their type1 cost for evaluation. If the 444 two ASBRs with same type2 as well as type1 cost, ECMP FRR is 445 programmed. If there are two ASBRs with different type2 cost, the 446 higher cost ASBR is pruned. The inequalities for evaluating 447 alternate ASBR for type 1 and type 2 costs are same, as the alternate 448 ASBRs with different type2 costs are pruned and the evaluation is 449 based on equal type 2 cost ASBRS. 451 4.2.4. RFC1583compatibility is set to enabled 453 When RFC1583Compatibility is set to enabled, multiple ASBRs belonging 454 to different area advertising same prefix are chosen based on cost 455 and hence are valid alternate ASBRs for the LFA evaluation. 457 4.2.5. Type 7 routes 459 Type 5 routes always get preference over Type 7 and the alternate 460 ASBRs chosen for LFA calculation should belong to same type. Among 461 Type 7 routes, routes with p-bit and forwarding address set have 462 higher preference than routes without these attributes. Alternate 463 ASBRs selected for LFA comparison should have same p-bit and 464 forwarding address attributes. 466 4.2.6. Inequalities to be applied for alternate ASBR selection 468 The alternate ASBRs selected using above mechanism described in 469 Section 4.2.1, are evaluated for Loop free criteria using below 470 inequalities. 472 4.2.6.1. Forwarding address set to non-zero value 473 Link-Protection: 474 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 475 F_opt(S,PO_best) + cost(PO_best,P) 477 Link-Protection + Downstream-paths-only: 478 F_opt(N,PO_i)+ cost(PO_i,P) < F_opt(S,PO_best) + cost(PO_best,P) 480 Node-Protection: 481 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 482 F_opt(E,PO_best) + cost(PO_best,P) 484 Where, 485 S - The computing router 486 N - The alternate router being evaluated 487 E - The primary next-hop on shortest path from S to 488 prefix P. 489 PO_i - The specific prefix-originating router being 490 evaluated. 491 PO_best - The prefix-originating router on the shortest path 492 from the computing router S to prefix P. 493 cost(X,Y) - External cost for Y as advertised by X 494 F_opt(X,Y) - Distance on the shortest path from node X to Forwarding 495 address specified by ASBR Y. 496 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 498 Figure 6: LFA inequality definition when forwarding address is non- 499 zero 501 4.2.6.2. ASBRs advertising type1 and type2 cost 502 Link-Protection: 503 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 504 D_opt(S,PO_best) + cost(PO_best,P) 506 Link-Protection + Downstream-paths-only: 507 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 509 Node-Protection: 510 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 511 D_opt(E,PO_best) + cost(PO_best,P) 513 Where, 514 S - The computing router 515 N - The alternate router being evaluated 516 E - The primary next-hop on shortest path from S to 517 prefix P. 518 PO_i - The specific prefix-originating router being 519 evaluated. 520 PO_best - The prefix-originating router on the shortest path 521 from the computing router S to prefix P. 522 cost(X,Y) - External cost for Y as advertised by X. 523 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 525 Figure 7: LFA inequality definition for type1 and type 2 cost 527 5. LFA Extended Procedures 529 This section explains the additional considerations in various 530 aspects as listed below to the base LFA specification [RFC5286]. 532 5.1. Links with IGP MAX_METRIC 534 Section 3.5 and 3.6 of [RFC5286] describes procedures for excluding 535 nodes and links from use in alternate paths based on the maximum link 536 metric (as defined in for IS-IS in [RFC5305] or as defined in 537 [RFC6987] for OSPF). If these procedures are strictly followed, 538 there are situations, as described below, where the only potential 539 alternate available which satisfies the basic loop-free condition 540 will not be considered as alternative. 542 +---+ 10 +---+ 10 +---+ 543 | S |------|N1 |-----|D1 | 544 +---+ +---+ +---+ 545 | | 546 10 | 10 | 547 |MAX_MET(N2 to S) | 548 | | 549 | +---+ | 550 +-------|N2 |--------+ 551 +---+ 552 10 | 553 +---+ 554 |D2 | 555 +---+ 557 Figure 8: Link with IGP MAX_METRIC 559 In the simple example network, all the link costs have a cost of 10 560 in both directions, except for the link between S and N2. The S-N2 561 link has a cost of 10 in the forward direction i.e., from S to N2, 562 and a cost of MAX_METRIC (0xffffff /2^24 - 1 for IS-IS and 0xffff for 563 OSPF) in the reverse direction i.e., from N2 to S for a specific end- 564 to-end Traffic Engineering (TE) requirement of the operator. At node 565 S, D1 is reachable through N1 with cost 20, and D2 is reachable 566 through N2 with cost 20. Even though neighbor N2 satisfies basic 567 loop-free condition (inequality 1 of [RFC5286]) for D1, S's neighbor 568 N2 could be excluded as a potential alternative because of the 569 current exclusions as specified in section 3.5 and 3.6 procedure of 570 [RFC5286]. But, as the primary traffic destined to D2 continue to 571 use the link and hence irrespective of the reverse metric in this 572 case, same link MAY be used as a potential LFA for D1. 574 Alternatively, reverse metric of the link MAY be configured with 575 MAX_METRIC-1, so that the link can be used as an alternative while 576 meeting the operator's TE requirements and without having to update 577 the router to fix this particular issue. 579 5.2. Multi Topology Considerations 581 Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and 582 ISIS are out of scope for that specification. This memo clarifies 583 and describes the applicability. 585 In Multi Topology (MT) IGP deployments, for each MT ID, a separate 586 shortest path tree (SPT) is built with topology specific adjacencies, 587 the LFA principles laid out in [RFC5286] are actually applicable for 588 MT IS-IS [RFC5120] LFA SPF. The primary difference in this case is, 589 identifying the eligible-set of neighbors for each LFA computation 590 which is done per MT ID. The eligible-set for each MT ID is 591 determined by the presence of IGP adjacency from Source to the 592 neighboring node on that MT-ID apart from the administrative 593 restrictions and other checks laid out in [RFC5286]. The same is 594 also applicable for MT-OSPF [RFC4915] or different AFs in multi 595 instance OSPFv3 [RFC5838]. 597 However for MT IS-IS, if a "standard topology" is used with MT-ID #0 598 [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are 599 present, then the condition of network congruency is applicable for 600 LFA computation as well. Network congruency here refers to, having 601 same address families provisioned on all the links and all the nodes 602 of the network with MT-ID #0. Here with single decision process both 603 IPv4 and IPv6 next-hops are computed for all the prefixes in the 604 network and similarly with one LFA computation from all eligible 605 neighbors per [RFC5286], all potential alternatives can be computed. 607 6. IANA Considerations 609 This document has no actions for IANA. 611 7. Acknowledgements 613 Thanks to Alia Atlas and Salih K A for their useful feedback and 614 inputs. Thanks to Stewart Bryant for being document shepherd and 615 providing detailed review comments. 617 8. Contributing Authors 619 The following people contributed substantially to the content of this 620 document and should be considered co-authors. 622 Chris Bowers 623 Juniper Networks, Inc. 624 1194 N. Mathilda Ave, 625 Sunnyvale, CA 94089, USA 627 Email: cbowers@juniper.ne 629 Bruno Decraene 630 Orange, 631 France 633 Email: bruno.decraene@orange.com 635 9. Security Considerations 637 This document does not introduce any change in any of the protocol 638 [RFC1195] [RFC5120] [RFC2328] [RFC5838] specifications discussed here 639 and also this does not introduce any new security issues other than 640 as noted in the LFA base specification [RFC5286]. 642 10. References 644 10.1. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, 648 DOI 10.17487/RFC2119, March 1997, 649 . 651 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 652 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 653 DOI 10.17487/RFC5286, September 2008, 654 . 656 10.2. Informative References 658 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 659 dual environments", RFC 1195, DOI 10.17487/RFC1195, 660 December 1990, . 662 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 663 DOI 10.17487/RFC2328, April 1998, 664 . 666 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 667 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 668 RFC 4915, DOI 10.17487/RFC4915, June 2007, 669 . 671 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 672 Topology (MT) Routing in Intermediate System to 673 Intermediate Systems (IS-ISs)", RFC 5120, 674 DOI 10.17487/RFC5120, February 2008, 675 . 677 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 678 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 679 2008, . 681 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 682 DOI 10.17487/RFC5308, October 2008, 683 . 685 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 686 R. Aggarwal, "Support of Address Families in OSPFv3", 687 RFC 5838, DOI 10.17487/RFC5838, April 2010, 688 . 690 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 691 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 692 DOI 10.17487/RFC6987, September 2013, 693 . 695 Authors' Addresses 697 Pushpasis Sarkar (editor) 698 Arrcus, Inc. 700 Email: pushpasis.ietf@gmail.com 702 Shraddha Hegde 703 Juniper Networks, Inc. 704 Electra, Exora Business Park 705 Bangalore, KA 560103 706 India 708 Email: shraddha@juniper.net 710 Uma Chunduri (editor) 711 Huawei USA 712 2330 Central Expressway 713 Santa Clara, CA 95050 714 USA 716 Email: uma.chunduri@huawei.com 718 Jeff Tantsura 719 Nuage Networks 720 755 Ravendale Drive 721 Mountain View, CA 94043 722 USA 724 Email: jefftant.ietf@gmail.com 725 Hannes Gredler 726 RtBrick, Inc. 728 Email: hannes@rtbrick.com