idnits 2.17.1 draft-ietf-rtgwg-multihomed-prefix-lfa-08.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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 16, 2018) is 2017 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 (~~), 2 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) U. Chunduri, Ed. 5 Intended status: Standards Track Huawei USA 6 Expires: April 19, 2019 S. Hegde 7 Juniper Networks, Inc. 8 J. Tantsura 9 Apstra, Inc. 10 H. Gredler 11 RtBrick, Inc. 12 October 16, 2018 14 LFA selection for Multi-Homed Prefixes 15 draft-ietf-rtgwg-multihomed-prefix-lfa-08 17 Abstract 19 This document shares experience gained from implementing algorithms 20 to determine Loop-Free Alternates (LFAs) for multi-homed prefixes. 21 In particular, this document provides explicit inequalities that can 22 be used to evaluate neighbors as a potential alternates for multi- 23 homed 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", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 RFC8174 [RFC2119] RFC8174 [RFC8174] when, and only when, they 34 appear in all capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 19, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. LFA inequalities for MHPs . . . . . . . . . . . . . . . . . . 4 73 3. LFA selection for the multi-homed prefixes . . . . . . . . . 5 74 3.1. Improved coverage with simplified approach to MHPs . . . 6 75 3.2. IS-IS ATT Bit considerations . . . . . . . . . . . . . . 8 76 4. LFA selection for the multi-homed external prefixes . . . . . 8 77 4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.2.1. Rules to select alternate ASBR . . . . . . . . . . . 9 80 4.2.1.1. Multiple ASBRs belonging different area . . . . . 11 81 4.2.1.2. Type 1 and Type 2 costs . . . . . . . . . . . . . 11 82 4.2.1.3. RFC1583compatibility is set to enabled . . . . . 11 83 4.2.1.4. Type 7 routes . . . . . . . . . . . . . . . . . . 11 84 4.2.2. Inequalities to be applied for alternate ASBR 85 selection . . . . . . . . . . . . . . . . . . . . . . 12 86 4.2.2.1. Forwarding address set to non-zero value . . . . 12 87 4.2.2.2. ASBRs advertising type1 and type2 cost . . . . . 12 88 5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 13 89 5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 13 90 5.2. Multi Topology Considerations . . . . . . . . . . . . . . 14 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 93 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 97 10.2. Informative References . . . . . . . . . . . . . . . . . 16 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction 102 A framework for the development of IP fast-reroute mechanisms is 103 detailed in [RFC5714]. The use of LFAs for IP Fast Reroute is 104 specified in [RFC5286]. Section 6.1 of [RFC5286] describes a method 105 to determine LFAs for multi-homed prefixes (MHPs). This document 106 describes a procedure using explicit inequalities that can be used by 107 a computing router to evaluate a neighbor as a potential alternate 108 for a multi-homed prefix. The results obtained are equivalent to 109 those obtained using the method described in Section 6.1 of 110 [RFC5286]. However, some may find this formulation 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 provides 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 This specification uses the same terminology introduced in [RFC5714] 127 to represent LFA and builds on the inequalities notation used in 128 [RFC5286] to compute LFAs for MHPs. 130 1.1. Acronyms 132 AF - Address Family 134 ATT - IS-IS Attach Bit 136 ECMP - Equal Cost Multi Path 138 IGP - Interior Gateway Protocol 140 IS-IS - Intermediate System to Intermediate System 142 LFA - Loop-Free Alternate 143 LSP - IS-IS Link State PDU 145 OSPF - Open Shortest Path First 147 MHP - Multi-homed Prefix 149 MT - Multi Topology 151 SPF - Shortest Path First PDU 153 2. LFA inequalities for MHPs 155 This document proposes the following set of LFA inequalities for 156 selecting the most appropriate LFAs for multi-homed prefixes (MHPs). 157 They can be derived from the inequalities in [RFC5286] combined with 158 the observation that D_opt(N,P) = Min (D_opt(N,PO_i) + Cost(PO_i,P)) 159 over all PO_i 161 Link-Protection: 162 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + 163 D_opt(S,PO_best) + Cost(PO_best,P) 165 Link-Protection + Downstream-paths-only: 166 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P) 168 Node-Protection: 169 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + 170 D_opt(E,PO_best) + Cost(PO_best,P) 172 Where, 173 P - The multi-homed prefix being evaluated for 174 computing alternates 175 S - The computing router 176 N - The alternate router being evaluated 177 E - The primary next-hop on shortest path from S to 178 prefix P. 179 PO_i - The specific prefix-originating router being 180 evaluated. 181 PO_best - The prefix-originating router on the shortest path 182 from the computing router S to prefix P. 183 Cost(X,P) - Cost of reaching the prefix P from prefix 184 originating node X. 185 D_opt(X,Y) - Distance on the shortest path from node X to node 186 Y. 188 Figure 1: LFA inequalities for MHPs 190 3. LFA selection for the multi-homed prefixes 192 To compute a valid LFA for a given multi-homed prefix P, a computing 193 router S MUST follow one of the appropriate procedures below, for 194 each alternate neighbor N. 196 Link-Protection : 197 ================= 198 1. If alternate neighbor N is also prefix-originator of P, 199 1.a. Select N as a LFA for prefix P (irrespective of 200 the metric advertised by N for the prefix P). 201 2. Else, evaluate the link-protecting LFA inequality for P with 202 the N as the alternate neighbor. 203 2.a. If LFA inequality condition is met, 204 select N as a LFA for prefix P. 205 2.b. Else, N is not a LFA for prefix P. 207 Link-Protection + Downstream-paths-only : 208 ========================================= 209 1. Evaluate the link-protecting + downstream-only LFA inequality 210 for P with the N as the alternate neighbor. 211 1.a. If LFA inequality condition is met, 212 select N as a LFA for prefix P. 213 1.b. Else, N is not a LFA for prefix P. 215 Node-Protection : 216 ================= 217 1. If alternate neighbor N is also prefix-originator of P, 218 1.a. Select N as a LFA for prefix P (irrespective of 219 the metric advertised by N for the prefix P). 220 2. Else, evaluate the appropriate node-protecting LFA inequality 221 for P with the N as the alternate neighbor. 222 2.a. If LFA inequality condition is met, 223 select N as a LFA for prefix P. 224 2.b. Else, N is not a LFA for prefix P. 226 Figure 2: Rules for selecting LFA for MHPs 228 In case an alternate neighbor N is also one of the prefix-originators 229 of prefix P, N being a prefix-originator it is guaranteed that N will 230 not loop back packets destined for prefix P to computing router S. 231 So N MUST be chosen as a valid LFA for prefix P, without evaluating 232 any of the inequalities in Figure 1 as long as downstream-paths-only 233 LFA is not desired. To ensure such a neighbor N also provides a 234 downstream-paths-only LFA, router S MUST also evaluate the 235 downstream-only LFA inequality specified in Figure 1 for neighbor N 236 and ensure router N satisfies the inequality. 238 However, if N is not a prefix-originator of P, the computing router 239 SHOULD evaluate one of the corresponding LFA inequalities, as 240 mentioned in Figure 1, once for each remote node that originated the 241 prefix. In case the inequality is satisfied by the neighbor N router 242 S MUST choose neighbor N, as one of the valid LFAs for the prefix P. 244 For more specific rules please refer to the later sections of this 245 document. 247 3.1. Improved coverage with simplified approach to MHPs 249 LFA base specification [RFC5286] Section 6.1 recommends that a router 250 computes the alternate next-hop for an IGP multi-homed prefix by 251 considering alternate paths via all routers that have announced that 252 prefix and the same has been elaborated with appropriate inequalities 253 in the above section. However, [RFC5286] Section 6.1 also allows for 254 the router to simplify the multi-homed prefix calculation by assuming 255 that the MHP is solely attached to the router that was its pre- 256 failure optimal point of attachment, at the expense of potentially 257 lower coverage. If an implementation chooses to simplify the multi- 258 homed prefix calculation by assuming that the MHP is solely attached 259 to the router that was its pre-failure optimal point of attachment, 260 the procedure described in this memo can potentially improve coverage 261 for equal cost multi path (ECMP) MHPs without incurring extra 262 computational cost. 264 This document improves the above approach to provide loop-free 265 alternatives without any additional cost for ECMP MHPs as described 266 through the below example network presented in Figure 3. The 267 approach specified here MAY also be applicable for handling default 268 routes as explained in Section 3.2. 270 5 +---+ 8 +---+ 5 +---+ 271 +-----| S |------| A |-----| B | 272 | +---+ +---+ +---+ 273 | | | 274 | 5 | 5 | 275 | | | 276 +---+ 5 +---+ 4 +---+ 1 +---+ 277 | C |---| E |-----| M |-------| F | 278 +---+ +---+ +---+ +---+ 279 | 10 5 | 280 +-----------P---------+ 282 Figure 3: MHP with same ECMP Next-hop 284 In the above network a prefix P, is advertised from both Node E and 285 Node F. With simplified approach taken as specified in [RFC5286] 286 Section 6.1, prefix P will get only link protection LFA through the 287 neighbor C while a node protection path is available through neighbor 288 A. In this scenario, E and F both are pre-failure optimal points of 289 attachment and share the same primary next-hop. Hence, an 290 implementation MAY compare the kind of protection A provides to F 291 (link-and-node protection) with the kind of protection C provides to 292 E (link protection) and inherit the better alternative to prefix P 293 and here it is A. 295 However, in the below example network presented in Figure 4, prefix P 296 has an ECMP through both node E and node F with cost 20. Though it 297 has 2 pre-failure optimal points of attachment, the primary next-hop 298 to each pre-failure optimal point of attachment is different. In 299 this case, prefix P MUST inherit corresponding LFAs of each primary 300 next-hop calculated for the router advertising the same respectively. 301 In the below diagram that would be node E's and node F's LFA i.e., 302 node N1 and node N2 respectively. 304 4 +----+ 305 +------------------| N2 | 306 | +----+ 307 | | 4 308 10 +---+ 3 +---+ 309 +------| S |----------------| B | 310 | +---+ +---+ 311 | | | 312 | 10 | 1 | 313 | | | 314 +----+ 5 +---+ 16 +---+ 315 | N1 |----| E |-----------------| F | 316 +----+ +---+ +---+ 317 | 10 16 | 318 +-----------P---------+ 320 Figure 4: MHP with different ECMP Next-hops 322 In summary, if there are multiple pre-failure points of attachment 323 for a MHP and primary next-hop of a MHP is same as that of the 324 primary next-hop of the router that was pre-failure optimal point of 325 attachment, an implementation MAY provide a better protection to MHP 326 without incurring any additional computation cost. 328 3.2. IS-IS ATT Bit considerations 330 Per [RFC1195] a default route needs to be added in Level1 (L1) router 331 to the closest reachable Level1/Level2 (L1/L2) router in the network 332 advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers 333 in the area would do this during the decision process with the next- 334 hop of the default route set to the adjacent router through which the 335 closest L1/L2 router is reachable. The base LFA specification 336 [RFC5286] does not specify any procedure for computing LFA for a 337 default route in IS-IS L1 area. This document specifies, a node can 338 consider a default route is being advertised from the border L1/L2 339 router where ATT bit is set, and can do LFA computation for that 340 default route. But, when multiple ECMP L1/L2 routers are reachable 341 in an L1 area corresponding best LFAs SHOULD be given for each 342 primary next-hop associated with default route. Considerations as 343 specified in Section 3 and Section 3.1 are applicable for default 344 routes, if the default route is considered as ECMP MHP. Note that, 345 this document doesn't alter any ECMP handling rules or computation of 346 LFAs for ECMP in general as laid out in [RFC5286]. 348 4. LFA selection for the multi-homed external prefixes 350 Redistribution of external routes into IGP is required in case of two 351 different networks getting merged into one or during protocol 352 migrations. External routes could be distributed into an IGP domain 353 via multiple nodes to avoid a single point of failure. 355 During LFA calculation, alternate LFA next-hops to reach the best 356 ASBR could be used as LFA for the routes redistributed via that ASBR. 357 When there is no LFA available to the best ASBR, it may be desirable 358 to consider the other ASBRs (referred to as alternate ASBR hereafter) 359 redistributing the external routes for LFA selection as defined in 360 [RFC5286] and leverage the advantage of having multiple re- 361 distributing nodes in the network. 363 4.1. IS-IS 365 LFA evaluation for multi-homed external prefixes in IS-IS is similar 366 to the multi-homed internal prefixes. Inequalities described in 367 Section 2 would also apply to multi-homed external prefixes. 369 4.2. OSPF 371 Loop Free Alternates [RFC5286] describes mechanisms to apply 372 inequalities to find the loop free alternate neighbor. For the 373 selection of alternate ASBR for LFA consideration, additional rules 374 have to be applied in selecting the alternate ASBR due to the 375 external route calculation rules imposed by [RFC2328]. 377 This document defines inequalities specifically for the alternate 378 loop-free ASBR evaluation, based on those in [RFC5286]. 380 4.2.1. Rules to select alternate ASBR 382 The process to select an alternate ASBR is best explained using the 383 rules below. The below process is applied when primary ASBR for the 384 concerned prefix is chosen and there is an alternate ASBR originating 385 same prefix. 387 1. If RFC1583Compatibility is disabled 389 1a. if primary ASBR and alternate ASBR belong to intra-area 390 non-backbone go to step 2. 391 1b. If primary ASBR and alternate ASBR belong to 392 intra-area backbone and/or inter-area path go 393 to step 2. 394 1c. for other paths, skip this alternate ASBR and 395 consider next ASBR. 397 2. Compare cost types (type 1/type 2) advertised by alternate ASBR and 398 by the primary ASBR 399 2a. If not the same type skip alternate ASBR and 400 consider next ASBR. 401 2b. If same proceed to step 3. 403 3.If cost types are type 1, compare costs advertised by alternate ASBR 404 and by the primary ASBR 405 3a. If costs are the same then program ECMP FRR and return. 406 3b. else go to step 5.. 408 4 If cost types are type 2, compare costs advertised by alternate ASBR 409 and by the primary ASBR 410 4a. If costs are different, skip alternate ASBR and 411 consider next ASBR. 412 4b. If cost are the same, proceed to step 4c to compare 413 cost to reach ASBR/forwarding address. 414 4c. If cost to reach ASBR/forwarding address are also same 415 program ECMP FRR and return. 416 4d. If cost to reach ASBR/forwarding address are different 417 go to step 5. 419 5. If route type (type 5/type 7) 420 5a. If route type is same, check route p-bit, 421 forwarding address field for routes from both 422 ASBRs match. If p-bit and forwarding address matches 423 proceed to step 6. 424 If not, skip this alternate ASBR and consider 425 next ASBR. 426 5b. If route type is not same, skip this alternate ASBR 427 and consider next alternate ASBR. 429 6. Apply inequality on the alternate ASBR. 431 Figure 5: Rules for selecting alternate ASBR in OSPF 433 4.2.1.1. Multiple ASBRs belonging different area 435 When "RFC1583compatibility" is set to disabled, OSPF [RFC2328] 436 defines certain rules of preference to choose the ASBRs. While 437 selecting alternate ASBR for loop evaluation for LFA, these rules 438 should be applied to ensure that the alternate neighbor does not 439 cause looping. 441 When there are multiple ASBRs belonging to different area advertising 442 the same prefix, pruning rules as defined in [RFC2328] section 16.4.1 443 are applied. The alternate ASBRs pruned using above rules are not 444 considered for LFA evaluation. 446 4.2.1.2. Type 1 and Type 2 costs 448 If there are multiple ASBRs not pruned via rules defined in 449 Section 4.2.1.1, the cost type advertised by the ASBRs is compared. 450 ASBRs advertising type 1 costs are preferred and the type 2 costs are 451 pruned. If two ASBRs advertise same type 2 cost, the alternate ASBRs 452 are considered along with their cost to reach ASBR/forwarding adress 453 for evaluation. If the two ASBRs have same type 2 cost as well as 454 same cost to reach ASBR, ECMP FRR is programmed. When there are 455 multiple ASBRs advertising same type 2 cost for the prefix, primary 456 AS external route calculation as described in [RFC2328] section 457 16.4.1 selects the route with lowest type 2 cost. ASBRs advertising 458 different type 2 cost (higher cost) are not considered for LFA 459 evaluation. Alternate ASBRs advertising type 2 cost for the prefix 460 but are not chosen as primary due to higher cost to reach ASBR are 461 considered for LFA evaluation.The inequalities for evaluating 462 alternate ASBR for type 1 and type 2 costs are same, as the alternate 463 ASBRs with different type 2 costs are pruned and the evaluation is 464 based on equal type 2 cost ASBRS. 466 4.2.1.3. RFC1583compatibility is set to enabled 468 When RFC1583Compatibility is set to enabled, multiple ASBRs belonging 469 to different area advertising same prefix are chosen based on cost 470 and hence are valid alternate ASBRs for the LFA evaluation. The 471 inequalities described in Section 4.2.2 are applicable based on 472 forwarding address and cost type advertised in External LSA. 474 4.2.1.4. Type 7 routes 476 Type 5 routes always get preference over Type 7 and the alternate 477 ASBRs chosen for LFA calculation should belong to same type. Among 478 Type 7 routes, routes with p-bit and forwarding address set have 479 higher preference than routes without these attributes. Alternate 480 ASBRs selected for LFA comparison should have same p-bit and 481 forwarding address attributes. 483 4.2.2. Inequalities to be applied for alternate ASBR selection 485 The alternate ASBRs selected using above mechanism described in 486 Section 4.2.1, are evaluated for Loop free criteria using below 487 inequalities. 489 4.2.2.1. Forwarding address set to non-zero value 491 Link-Protection: 492 F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + 493 F_opt(S,PO_best) + Cost(PO_best,P) 495 Link-Protection + Downstream-paths-only: 496 F_opt(N,PO_i)+ Cost(PO_i,P) < F_opt(S,PO_best) + Cost(PO_best,P) 498 Node-Protection: 499 F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + 500 F_opt(E,PO_best) + Cost(PO_best,P) 502 Where, 503 P - The multi-homed prefix being evaluated for 504 computing alternates 505 S - The computing router 506 N - The alternate router being evaluated 507 E - The primary next-hop on shortest path from S to 508 prefix P. 509 PO_i - The specific prefix-originating router being 510 evaluated. 511 PO_best - The prefix-originating router on the shortest path 512 from the computing router S to prefix P. 513 Cost(X,Y) - External cost for Y as advertised by X 514 F_opt(X,Y) - Distance on the shortest path from node X to Forwarding 515 address specified by ASBR Y. 516 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 518 Figure 6: LFA inequality definition when forwarding address is non- 519 zero 521 4.2.2.2. ASBRs advertising type1 and type2 cost 522 Link-Protection: 523 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + 524 D_opt(S,PO_best) + Cost(PO_best,P) 526 Link-Protection + Downstream-paths-only: 527 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P) 529 Node-Protection: 530 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + 531 D_opt(E,PO_best) + Cost(PO_best,P) 533 Where, 534 P - The multi-homed prefix being evaluated for 535 computing alternates 536 S - The computing router 537 N - The alternate router being evaluated 538 E - The primary next-hop on shortest path from S to 539 prefix P. 540 PO_i - The specific prefix-originating router being 541 evaluated. 542 PO_best - The prefix-originating router on the shortest path 543 from the computing router S to prefix P. 544 Cost(X,Y) - External cost for Y as advertised by X. 545 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 547 Figure 7: LFA inequality definition for type1 and type 2 cost 549 5. LFA Extended Procedures 551 This section explains the additional considerations in various 552 aspects as listed below to the base LFA specification [RFC5286]. 554 5.1. Links with IGP MAX_METRIC 556 Section 3.5 and 3.6 of [RFC5286] describe procedures for excluding 557 nodes and links from use in alternate paths based on the maximum link 558 metric (as defined for IS-IS in [RFC5305] or as defined in [RFC6987] 559 for OSPF). If these procedures are strictly followed, there are 560 situations, as described below, where the only potential alternate 561 available which satisfies the basic loop-free condition will not be 562 considered as alternative. 564 +---+ 10 +---+ 10 +---+ 565 | S |------|N1 |-----|D1 | 566 +---+ +---+ +---+ 567 | | 568 10 | 10 | 569 |MAX_MET(N2 to S) | 570 | | 571 | +---+ | 572 +-------|N2 |--------+ 573 +---+ 574 10 | 575 +---+ 576 |D2 | 577 +---+ 579 Figure 8: Link with IGP MAX_METRIC 581 In the simple example network, all the link costs have a cost of 10 582 in both directions, except for the link between S and N2. The S-N2 583 link has a cost of 10 in the forward direction i.e., from S to N2, 584 and a cost of MAX_METRIC (0xffffff /2^24 - 1 for IS-IS and 0xffff for 585 OSPF) in the reverse direction i.e., from N2 to S for a specific end- 586 to-end Traffic Engineering (TE) requirement of the operator. At node 587 S, D1 is reachable through N1 with cost 20, and D2 is reachable 588 through N2 with cost 20. Even though neighbor N2 satisfies basic 589 loop-free condition (inequality 1 of [RFC5286]) for D1, S's neighbor 590 N2 could be excluded as a potential alternative because of the 591 current exclusions as specified in section 3.5 and 3.6 procedure of 592 [RFC5286]. But, as the primary traffic destined to D2 continues to 593 use the link and hence irrespective of the reverse metric in this 594 case, same link MAY be used as a potential LFA for D1. 596 Alternatively, reverse metric of the link MAY be configured with 597 MAX_METRIC-1, so that the link can be used as an alternative while 598 meeting the operator's TE requirements and without having to update 599 the router to fix this particular issue. 601 5.2. Multi Topology Considerations 603 Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and 604 IS-IS are out of scope for that specification. This memo clarifies 605 and describes the applicability. 607 In Multi Topology (MT) IGP deployments, for each MT ID, a separate 608 shortest path tree (SPT) is built with topology specific adjacencies, 609 the LFA principles laid out in [RFC5286] are actually applicable for 610 MT IS-IS [RFC5120] LFA SPF. The primary difference in this case is, 611 identifying the eligible-set of neighbors for each LFA computation 612 which is done per MT ID. The eligible-set for each MT ID is 613 determined by the presence of IGP adjacency from Source to the 614 neighboring node on that MT-ID apart from the administrative 615 restrictions and other checks laid out in [RFC5286]. The same is 616 also applicable for MT-OSPF [RFC4915] or different AFs in multi 617 instance OSPFv3 [RFC5838]. 619 However for MT IS-IS, if a "standard topology" is used with MT-ID #0 620 [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are 621 present, then the condition of network congruency is applicable for 622 LFA computation as well. Network congruency here refers to, having 623 same address families provisioned on all the links and all the nodes 624 of the network with MT-ID #0. Here with single decision process both 625 IPv4 and IPv6 next-hops are computed for all the prefixes in the 626 network and similarly with one LFA computation from all eligible 627 neighbors per [RFC5286], all potential alternatives can be computed. 629 6. IANA Considerations 631 This document has no actions for IANA. 633 7. Acknowledgements 635 Thanks to Alia Atlas and Salih K A for their useful feedback and 636 inputs. Thanks to Stewart Bryant for being document shepherd and 637 providing detailed review comments. 639 8. Contributing Authors 641 The following people contributed substantially to the content of this 642 document and should be considered co-authors. 644 Chris Bowers 645 Juniper Networks, Inc. 646 1194 N. Mathilda Ave, 647 Sunnyvale, CA 94089, USA 649 Email: cbowers@juniper.net 651 Bruno Decraene 652 Orange, 653 France 655 Email: bruno.decraene@orange.com 657 9. Security Considerations 659 Existing OSPF security considerations and stronger authentication and 660 manual key management mechanisms are specified in [RFC7474] SHOULD be 661 considered for OSPF deployments. Security concerns for IS-IS are 662 addressed in [RFC5304] and [RFC5310]. Further security analysis for 663 IS-IS protocol is done in [RFC7645] SHOULD be considered for IS-IS 664 deployments. This document does not change any of the discussed 665 protocol specifications [RFC1195] [RFC5120] [RFC2328] [RFC5838], and 666 the security considerations of the LFA base specification [RFC5286] 667 therefore continue to apply. 669 10. References 671 10.1. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, 675 DOI 10.17487/RFC2119, March 1997, 676 . 678 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 679 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 680 DOI 10.17487/RFC5286, September 2008, 681 . 683 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 684 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 685 May 2017, . 687 10.2. Informative References 689 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 690 dual environments", RFC 1195, DOI 10.17487/RFC1195, 691 December 1990, . 693 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 694 DOI 10.17487/RFC2328, April 1998, 695 . 697 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 698 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 699 RFC 4915, DOI 10.17487/RFC4915, June 2007, 700 . 702 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 703 Topology (MT) Routing in Intermediate System to 704 Intermediate Systems (IS-ISs)", RFC 5120, 705 DOI 10.17487/RFC5120, February 2008, 706 . 708 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 709 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 710 2008, . 712 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 713 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 714 2008, . 716 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 717 DOI 10.17487/RFC5308, October 2008, 718 . 720 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 721 and M. Fanto, "IS-IS Generic Cryptographic 722 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 723 2009, . 725 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 726 RFC 5714, DOI 10.17487/RFC5714, January 2010, 727 . 729 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 730 R. Aggarwal, "Support of Address Families in OSPFv3", 731 RFC 5838, DOI 10.17487/RFC5838, April 2010, 732 . 734 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 735 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 736 DOI 10.17487/RFC6987, September 2013, 737 . 739 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 740 "Security Extension for OSPFv2 When Using Manual Key 741 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 742 . 744 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 745 Authentication for Routing Protocol (KARP) IS-IS Security 746 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 747 . 749 Authors' Addresses 751 Pushpasis Sarkar (editor) 752 Arrcus, Inc. 754 Email: pushpasis.ietf@gmail.com 756 Uma Chunduri (editor) 757 Huawei USA 758 2330 Central Expressway 759 Santa Clara, CA 95050 760 USA 762 Email: uma.chunduri@huawei.com 764 Shraddha Hegde 765 Juniper Networks, Inc. 766 Electra, Exora Business Park 767 Bangalore, KA 560103 768 India 770 Email: shraddha@juniper.net 772 Jeff Tantsura 773 Apstra, Inc. 775 Email: jefftant.ietf@gmail.com 777 Hannes Gredler 778 RtBrick, Inc. 780 Email: hannes@rtbrick.com