idnits 2.17.1 draft-ietf-rtgwg-multihomed-prefix-lfa-09.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 19 characters in excess of 72. -- 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 (November 21, 2018) is 1982 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: 1 error (**), 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: May 25, 2019 S. Hegde 7 Juniper Networks, Inc. 8 J. Tantsura 9 Apstra, Inc. 10 H. Gredler 11 RtBrick, Inc. 12 November 21, 2018 14 Loop-Free Alternates selection for Multi-Homed Prefixes 15 draft-ietf-rtgwg-multihomed-prefix-lfa-09 17 Abstract 19 Deployment experience gained from implementing algorithms to 20 determine Loop-Free Alternates (LFAs) for multi-homed prefixes has 21 revealed some avenues for potential improvement. This document 22 provides explicit inequalities that can be used to evaluate neighbors 23 as a potential alternates for multi-homed prefixes. It also provides 24 detailed criteria for evaluating potential alternates for external 25 prefixes advertised by OSPF ASBRs. This documents updates and 26 expands some of the "Routing Aspects" as specified in Section 6 of 27 RFC 5286. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in BCP 34 14 RFC8174 [RFC2119] RFC8174 [RFC8174] when, and only when, they 35 appear in all capitals, as shown here. 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 25, 2019. 54 Copyright Notice 56 Copyright (c) 2018 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 . . . . . . . . . 5 75 3.1. Improved coverage with simplified approach to MHPs . . . 7 76 3.2. IS-IS ATT Bit considerations . . . . . . . . . . . . . . 8 77 4. LFA selection for the multi-homed external prefixes . . . . . 9 78 4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.2.1. Rules to select alternate ASBR . . . . . . . . . . . 9 81 4.2.1.1. Multiple ASBRs belonging different area . . . . . 11 82 4.2.1.2. Type 1 and Type 2 costs . . . . . . . . . . . . . 11 83 4.2.1.3. RFC1583compatibility is set to enabled . . . . . 11 84 4.2.1.4. Type 7 routes . . . . . . . . . . . . . . . . . . 11 85 4.2.2. Inequalities to be applied for alternate ASBR 86 selection . . . . . . . . . . . . . . . . . . . . . . 12 87 4.2.2.1. Forwarding address set to non-zero value . . . . 12 88 4.2.2.2. ASBRs advertising type1 and type2 cost . . . . . 13 89 5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 13 90 5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 13 91 5.2. Multi Topology Considerations . . . . . . . . . . . . . . 14 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 94 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 98 10.2. Informative References . . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 101 1. Introduction 103 A framework for the development of IP fast-reroute mechanisms is 104 detailed in [RFC5714]. The use of LFAs for IP Fast Reroute is 105 specified in [RFC5286]. If a prefix is advertised by more than one 106 router that prefix is called as multi-homed prefix (MHP). MHPs 107 generally occur for prefixes obtained from outside the routing domain 108 by multiple routers, for subnets on links where the subnet is 109 announced from multiple ends of the link, and for prefixes advertised 110 by multiple routers to provide resiliency. 112 Section 6.1 of [RFC5286] describes a method to determine LFAs for 113 MHPs. This document describes a procedure using explicit 114 inequalities that can be used by a computing router to evaluate a 115 neighbor as a potential alternate for a MHP. The results obtained 116 are equivalent to those obtained using the method described in 117 Section 6.1 of [RFC5286]. 119 Section 6.3 of [RFC5286] discusses complications associated with 120 computing LFAs for MHPs in OSPF. This document provides detailed 121 criteria for evaluating potential alternates for external prefixes 122 advertised by OSPF ASBRs, as well as explicit inequalities. 124 This document also provides clarifications, additional considerations 125 to [RFC5286], to address a few coverage and operational observations. 126 These observations are in the area of handling IS-IS attach (ATT) bit 127 in Level-1 (L1) area, links provisioned with MAX_METRIC (see 128 Section 5.1) for traffic engineering (TE) purposes and in the area of 129 Multi Topology (MT) IGP deployments. These are elaborated in detail 130 in Section 3.2 and Section 5. 132 This specification uses the same terminology introduced in [RFC5714] 133 to represent LFA and builds on the inequalities notation used in 134 [RFC5286] to compute LFAs for MHPs. 136 1.1. Acronyms 138 AF - Address Family 140 ATT - IS-IS Attach Bit 142 ECMP - Equal Cost Multi Path 144 IGP - Interior Gateway Protocol 145 IS-IS - Intermediate System to Intermediate System 147 LFA - Loop-Free Alternate 149 LSP - IS-IS Link State PDU 151 OSPF - Open Shortest Path First 153 MHP - Multi-homed Prefix 155 MT - Multi Topology 157 SPF - Shortest Path First 159 2. LFA inequalities for MHPs 161 This document proposes the following set of LFA inequalities for 162 selecting the most appropriate LFAs for MHPs. D_opt(X,Y) terminology 163 is defined in [RFC5714], which is nothing but the metric sum of the 164 shortest path from X to Y and Cost(X,Y) introduced in this document 165 is defined as the metric value of prefix Y from the prefix 166 advertising node X. These LFAs can be derived from the inequalities 167 in [RFC5286] combined with the observation that D_opt(N,P) = Min 168 (D_opt(N,PO_i) + Cost(PO_i,P)) over all PO_i 170 Link-Protection: 171 A neighbor N can provide a loop-free alternate (LFA) if and only if 173 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + 174 D_opt(S,PO_best) + Cost(PO_best,P) 176 Link-Protection + Downstream-paths-only: 177 A subset of loop-free alternates are downstream paths that must meet 178 a more restrictive condition that is applicable to more complex 179 failure scenarios 181 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P) 183 Node-Protection: 184 For an alternate next-hop N to protect against node failure of a 185 primary neighbor E for MHP P, N must be loop-free with 186 respect to both E and mhp P. In other words, N's path to MHP P must not go 187 through E (where N is the neighbor providing a loop-free alternate) 189 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + 190 D_opt(E,PO_best) + Cost(PO_best,P) 192 Where, 193 P - The multi-homed prefix being evaluated for 194 computing alternates 195 S - The computing router 196 N - The alternate router being evaluated 197 E - The primary next-hop on shortest path from S to 198 prefix P. 199 PO_i - The specific prefix-originating router being 200 evaluated. 201 PO_best - The prefix-originating router on the shortest path 202 from the computing router S to prefix P. 203 Cost(X,P) - Cost of reaching the prefix P from prefix 204 originating node X. 205 D_opt(X,Y) - Distance on the shortest path from node X to node 206 Y. 208 Figure 1: LFA inequalities for MHPs 210 3. LFA selection for the multi-homed prefixes 212 To compute a valid LFA for a given MHP P, a computing router S MUST 213 follow one of the appropriate procedures below, for each alternate 214 neighbor N and once for each remote node that originated the prefix 215 P. 217 Link-Protection : 218 ================= 219 1. if, in addition to being an alternate neighbor, N is also a prefix-originator of P, 220 1.a. Select N as a LFA for prefix P (irrespective of 221 the metric advertised by N for the prefix P). 222 2. Else, evaluate the link-protecting LFA inequality for P with 223 the N as the alternate neighbor. 224 2.a. If LFA inequality condition is met, 225 select N as a LFA for prefix P. 226 2.b. Else, N is not a LFA for prefix P. 228 Link-Protection + Downstream-paths-only : 229 ========================================= 230 1. Evaluate the link-protecting + downstream-only LFA inequality 231 for P with the N as the alternate neighbor. 232 1.a. If LFA inequality condition is met, 233 select N as a LFA for prefix P. 234 1.b. Else, N is not a LFA for prefix P. 236 Node-Protection : 237 ================= 238 1. if, in addition to being an alternate neighbor, N is also a prefix-originator of P, 239 1.a. Select N as a LFA for prefix P (irrespective of 240 the metric advertised by N for the prefix P). 241 2. Else, evaluate the appropriate node-protecting LFA inequality 242 for P with the N as the alternate neighbor. 243 2.a. If LFA inequality condition is met, 244 select N as a LFA for prefix P. 245 2.b. Else, N is not a LFA for prefix P. 247 Figure 2: Rules for selecting LFA for MHPs 249 In case an alternate neighbor N is also one of the prefix-originators 250 of prefix P, N being a prefix-originator it is guaranteed that N will 251 not loop back packets destined for prefix P to computing router S. 252 So N MUST be chosen as a valid LFA for prefix P, without evaluating 253 any of the inequalities in Figure 1 as long as downstream-paths-only 254 LFA is not desired. To ensure such a neighbor N also provides a 255 downstream-paths-only LFA, router S MUST also evaluate the 256 downstream-only LFA inequality specified in Figure 1 for neighbor N 257 and ensure router N satisfies the inequality. 259 However, if N is not a prefix-originator of P, the computing router 260 MUST evaluate one of the corresponding LFA inequalities, as mentioned 261 in Figure 1, once for each remote node that originated the prefix. 262 In case the inequality is satisfied by the neighbor N router S MUST 263 choose neighbor N, as one of the valid LFAs for the prefix P. 265 For more specific rules please refer to the later sections of this 266 document. 268 3.1. Improved coverage with simplified approach to MHPs 270 LFA base specification [RFC5286] Section 6.1 recommends that a router 271 computes the alternate next-hop for an IGP MHP by considering 272 alternate paths via all routers that have announced that prefix and 273 the same has been elaborated with appropriate inequalities in the 274 above section. However, [RFC5286] Section 6.1 also allows for the 275 router to simplify the MHP calculation by assuming that the MHP is 276 solely attached to the router that was its pre-failure optimal point 277 of attachment, at the expense of potentially lower coverage. If an 278 implementation chooses to simplify the MHP calculation by assuming 279 that the MHP is solely attached to the router that was its pre- 280 failure optimal point of attachment, the procedure described in this 281 memo can potentially improve coverage for equal cost multi path 282 (ECMP) MHPs without incurring extra computational cost. 284 This document improves the above approach to provide loop-free 285 alternatives without any additional cost for ECMP MHPs as described 286 through the below example network presented in Figure 3. The 287 approach specified here may also be applicable for handling default 288 routes as explained in Section 3.2. 290 5 +---+ 8 +---+ 5 +---+ 291 +-----| S |------| A |-----| B | 292 | +---+ +---+ +---+ 293 | | | 294 | 5 | 5 | 295 | | | 296 +---+ 5 +---+ 4 +---+ 1 +---+ 297 | C |---| E |-----| M |-------| F | 298 +---+ +---+ +---+ +---+ 299 | 10 5 | 300 +-----------P---------+ 302 Figure 3: MHP with same ECMP Next-hop 304 In the above network a prefix P, is advertised from both Node E and 305 Node F. With simplified approach taken as specified in [RFC5286] 306 Section 6.1, prefix P will get only link protection LFA through the 307 neighbor C while a node protection path is available through neighbor 308 A. In this scenario, E and F both are pre-failure optimal points of 309 attachment and share the same primary next-hop. Hence, an 310 implementation MAY compare the kind of protection A provides to F 311 (link-and-node protection) with the kind of protection C provides to 312 E (link protection) and inherit the better alternative to prefix P 313 and here it is A. 315 However, in the below example network presented in Figure 4, prefix P 316 has an ECMP through both node E and node F with cost 20. Though it 317 has 2 pre-failure optimal points of attachment, the primary next-hop 318 to each pre-failure optimal point of attachment is different. In 319 this case, prefix P MUST inherit corresponding LFAs of each primary 320 next-hop calculated for the router advertising the same respectively. 321 In the below diagram that would be node E's and node F's LFA i.e., 322 node N1 and node N2 respectively. 324 4 +----+ 325 +------------------| N2 | 326 | +----+ 327 | | 4 328 10 +---+ 3 +---+ 329 +------| S |----------------| B | 330 | +---+ +---+ 331 | | | 332 | 10 | 1 | 333 | | | 334 +----+ 5 +---+ 16 +---+ 335 | N1 |----| E |-----------------| F | 336 +----+ +---+ +---+ 337 | 10 16 | 338 +-----------P---------+ 340 Figure 4: MHP with different ECMP Next-hops 342 In summary, if there are multiple pre-failure points of attachment 343 for a MHP and primary next-hop of a MHP is same as that of the 344 primary next-hop of the router that was pre-failure optimal point of 345 attachment, an implementation MAY provide a better protection to MHP 346 without incurring any additional computation cost. 348 3.2. IS-IS ATT Bit considerations 350 Per [RFC1195] a default route needs to be added in Level1 (L1) router 351 to the closest reachable Level1/Level2 (L1/L2) router in the network 352 advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers 353 in the area would do this during the decision process with the next- 354 hop of the default route set to the adjacent router through which the 355 closest L1/L2 router is reachable. The base LFA specification 356 [RFC5286] does not specify any procedure for computing LFA for a 357 default route in IS-IS L1 area. This document specifies, a node can 358 consider a default route is being advertised from the border L1/L2 359 router where ATT bit is set, and can do LFA computation for that 360 default route. But, when multiple ECMP L1/L2 routers are reachable 361 in an L1 area corresponding best LFAs SHOULD be computed for each 362 primary next-hop associated with default route as this would be 363 similar to ECMP MHP example as described in Section 3.1. 364 Considerations as specified in Section 3 and Section 3.1 are 365 applicable for default routes, if the default route is considered as 366 ECMP MHP. Note that, this document doesn't alter any ECMP handling 367 rules or computation of LFAs for ECMP in general as laid out in 368 [RFC5286]. 370 4. LFA selection for the multi-homed external prefixes 372 Redistribution of external routes into IGP is required in case of two 373 different networks getting merged into one or during protocol 374 migrations. External routes could be distributed into an IGP domain 375 via multiple nodes to avoid a single point of failure. 377 During LFA calculation, alternate LFA next-hops to reach the best 378 ASBR could be used as LFA for the routes redistributed via that ASBR. 379 When there is no LFA available to the best ASBR, it may be desirable 380 to consider the other ASBRs (referred to as alternate ASBR hereafter) 381 redistributing the external routes for LFA selection as defined in 382 [RFC5286] and leverage the advantage of having multiple re- 383 distributing nodes in the network. 385 4.1. IS-IS 387 LFA evaluation for multi-homed external prefixes in IS-IS is same to 388 the multi-homed internal prefixes. Inequalities described in 389 Section 2 would also apply to multi-homed external prefixes. 391 4.2. OSPF 393 Loop Free Alternates [RFC5286] describes mechanisms to apply 394 inequalities to find the loop free alternate neighbor. For the 395 selection of alternate ASBR for LFA consideration, additional rules 396 have to be applied in selecting the alternate ASBR due to the 397 external route calculation rules imposed by [RFC2328]. 399 This document defines inequalities specifically for the alternate 400 loop-free ASBR evaluation, based on those in [RFC5286]. 402 4.2.1. Rules to select alternate ASBR 404 The process to select an alternate ASBR is best explained using the 405 rules below. The below process is applied when primary ASBR for the 406 concerned prefix is chosen and there is an alternate ASBR originating 407 same prefix. 409 1. If RFC1583Compatibility is disabled 411 1a. if primary ASBR and alternate ASBR belong to intra-area 412 non-backbone go to step 2. 413 1b. If primary ASBR and alternate ASBR belong to 414 intra-area backbone and/or inter-area path go 415 to step 2. 416 1c. for other paths, skip this alternate ASBR and 417 consider next ASBR. 419 2. Compare cost types (type 1/type 2) advertised by alternate ASBR and 420 by the primary ASBR 421 2a. If not the same type skip alternate ASBR and 422 consider next ASBR. 423 2b. If same proceed to step 3. 425 3.If cost types are type 1, compare costs advertised by alternate ASBR 426 and by the primary ASBR 427 3a. If costs are the same then program ECMP Fast ReRoute (FRR) and return. 428 3b. else go to step 5.. 430 4 If cost types are type 2, compare costs advertised by alternate ASBR 431 and by the primary ASBR 432 4a. If costs are different, skip alternate ASBR and 433 consider next ASBR. 434 4b. If cost are the same, proceed to step 4c to compare 435 cost to reach ASBR/forwarding address. 436 4c. If cost to reach ASBR/forwarding address are also same 437 program ECMP FRR and return. 438 4d. If cost to reach ASBR/forwarding address are different 439 go to step 5. 441 5. If route type (type 5/type 7) 442 5a. If route type is same, check if the route p-bit and the 443 forwarding address field for routes from both 444 ASBRs match. If p-bit and forwarding address matches 445 proceed to step 6. 446 If not, skip this alternate ASBR and consider 447 next ASBR. 448 5b. If route type is not same, skip this alternate ASBR 449 and consider next alternate ASBR. 451 6. Apply inequality on the alternate ASBR. 453 Figure 5: Rules for selecting alternate ASBR in OSPF 455 4.2.1.1. Multiple ASBRs belonging different area 457 When "RFC1583compatibility" is set to disabled, OSPF [RFC2328] 458 defines certain rules of preference to choose the ASBRs. While 459 selecting alternate ASBR for loop evaluation for LFA, these rules 460 should be applied to ensure that the alternate neighbor does not 461 cause looping. 463 When there are multiple ASBRs belonging to different area advertising 464 the same prefix, pruning rules as defined in [RFC2328] section 16.4 465 are applied. The alternate ASBRs pruned using above rules are not 466 considered for LFA evaluation. 468 4.2.1.2. Type 1 and Type 2 costs 470 If there are multiple ASBRs not pruned via rules described in 471 Section 4.2.1.1, the cost type advertised by the ASBRs is compared. 472 ASBRs advertising type 1 costs are preferred and the type 2 costs are 473 pruned. If two ASBRs advertise same type 2 cost, the alternate ASBRs 474 are considered along with their cost to reach ASBR/forwarding address 475 for evaluation. If the two ASBRs have same type 2 cost as well as 476 same cost to reach ASBR, ECMP FRR is programmed. When there are 477 multiple ASBRs advertising same type 2 cost for the prefix, primary 478 Autonomous System (AS) external route calculation as described in 479 [RFC2328] section 16.4.1 selects the route with lowest type 2 cost. 480 ASBRs advertising different type 2 cost (higher cost) are not 481 considered for LFA evaluation. Alternate ASBRs advertising type 2 482 cost for the prefix but are not chosen as primary due to higher cost 483 to reach ASBR are considered for LFA evaluation. The inequalities 484 for evaluating alternate ASBR for type 1 and type 2 costs are same, 485 as the alternate ASBRs with different type 2 costs are pruned and the 486 evaluation is based on equal type 2 cost ASBRS. 488 4.2.1.3. RFC1583compatibility is set to enabled 490 When RFC1583Compatibility is set to enabled, multiple ASBRs belonging 491 to different area advertising same prefix are chosen based on cost 492 and hence are valid alternate ASBRs for the LFA evaluation. The 493 inequalities described in Section 4.2.2 are applicable based on 494 forwarding address and cost type advertised in External Link State 495 Advertisement (LSA). 497 4.2.1.4. Type 7 routes 499 Type 5 routes always get preference over Type 7 and the alternate 500 ASBRs chosen for LFA calculation should belong to same type. Among 501 Type 7 routes, routes with p-bit and forwarding address set have 502 higher preference than routes without these attributes. Alternate 503 ASBRs selected for LFA comparison should have same p-bit and 504 forwarding address attributes. 506 4.2.2. Inequalities to be applied for alternate ASBR selection 508 The alternate ASBRs selected using above mechanism described in 509 Section 4.2.1, are evaluated for Loop free criteria using below 510 inequalities. 512 4.2.2.1. Forwarding address set to non-zero value 514 Similar to inequalities as defined in Figure 1, the following 515 inequalities are defined when forwarding address is a non-zero value. 517 Link-Protection: 518 F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + 519 F_opt(S,PO_best) + Cost(PO_best,P) 521 Link-Protection + Downstream-paths-only: 522 F_opt(N,PO_i)+ Cost(PO_i,P) < F_opt(S,PO_best) + Cost(PO_best,P) 524 Node-Protection: 525 F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + 526 F_opt(E,PO_best) + Cost(PO_best,P) 528 Where, 529 P - The multi-homed prefix being evaluated for 530 computing alternates 531 S - The computing router 532 N - The alternate router being evaluated 533 E - The primary next-hop on shortest path from S to 534 prefix P. 535 PO_i - The specific prefix-originating router being 536 evaluated. 537 PO_best - The prefix-originating router on the shortest path 538 from the computing router S to prefix P. 539 Cost(X,Y) - External cost for Y as advertised by X 540 F_opt(X,Y) - Distance on the shortest path from node X to Forwarding 541 address specified by ASBR Y. 542 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 544 Figure 6: LFA inequality definition when forwarding address is non- 545 zero 547 4.2.2.2. ASBRs advertising type1 and type2 cost 549 Similar to inequalities as defined in Figure 1, the following 550 inequlities are defined for type1 and type2 cost. 552 Link-Protection: 553 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + 554 D_opt(S,PO_best) + Cost(PO_best,P) 556 Link-Protection + Downstream-paths-only: 557 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P) 559 Node-Protection: 560 D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + 561 D_opt(E,PO_best) + Cost(PO_best,P) 563 Where, 564 P - The multi-homed prefix being evaluated for 565 computing alternates 566 S - The computing router 567 N - The alternate router being evaluated 568 E - The primary next-hop on shortest path from S to 569 prefix P. 570 PO_i - The specific prefix-originating router being 571 evaluated. 572 PO_best - The prefix-originating router on the shortest path 573 from the computing router S to prefix P. 574 Cost(X,Y) - External cost for Y as advertised by X. 575 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 577 Figure 7: LFA inequality definition for type1 and type2 cost 579 5. LFA Extended Procedures 581 This section explains the additional considerations in various 582 aspects as listed below to the base LFA specification [RFC5286]. 584 5.1. Links with IGP MAX_METRIC 586 Section 3.5 and 3.6 of [RFC5286] describe procedures for excluding 587 nodes and links from use in alternate paths based on the maximum link 588 metric. If these procedures are strictly followed, there are 589 situations, as described below, where the only potential alternate 590 available which satisfies the basic loop-free condition will not be 591 considered as alternative. This document refers the maximum link 592 metric in IGPs as the MAX_METRIC. MAX_METRIC is defined for IS-IS in 594 [RFC5305], where it is called as "maximum link metric" and defined 595 for OSPF in [RFC6987], where it is called as "MaxLinkMetric". 597 +---+ 10 +---+ 10 +---+ 598 | S |------|N1 |-----|D1 | 599 +---+ +---+ +---+ 600 | | 601 10 | 10 | 602 |MAX_METRIC(N2 to S) | 603 | | 604 | +---+ | 605 +-------|N2 |--------+ 606 +---+ 607 10 | 608 +---+ 609 |D2 | 610 +---+ 612 Figure 8: Link with IGP MAX_METRIC 614 In the simple example network, all the link costs have a cost of 10 615 in both directions, except for the link between S and N2. The S-N2 616 link has a cost of 10 in the forward direction i.e., from S to N2, 617 and a cost of MAX_METRIC (0xffffff /2^24 - 1 for IS-IS and 0xffff for 618 OSPF) in the reverse direction i.e., from N2 to S for a specific end- 619 to-end Traffic Engineering (TE) requirement of the operator. At node 620 S, D1 is reachable through N1 with cost 20, and D2 is reachable 621 through N2 with cost 20. Even though neighbor N2 satisfies basic 622 loop-free condition (inequality 1 of [RFC5286]) for D1, S's neighbor 623 N2 could be excluded as a potential alternative because of the 624 current exclusions as specified in section 3.5 and 3.6 procedure of 625 [RFC5286]. But, as the primary traffic destined to D2 continues to 626 use the link and hence irrespective of the reverse metric in this 627 case, same link MAY be used as a potential LFA for D1. 629 Alternatively, reverse metric of the link MAY be configured with 630 MAX_METRIC-1, so that the link can be used as an alternative while 631 meeting the operator's TE requirements and without having to update 632 the router to fix this particular issue. 634 5.2. Multi Topology Considerations 636 Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and 637 IS-IS are out of scope for that specification. This memo clarifies 638 and describes the applicability. 640 In Multi Topology (MT) IGP deployments, for each MT ID, a separate 641 shortest path tree (SPT) is built with topology specific adjacencies, 642 so the LFA principles laid out in [RFC5286] are actually applicable 643 for MT IS-IS [RFC5120] LFA SPF. The primary difference in this case 644 is, identifying the eligible-set of neighbors for each LFA 645 computation which is done per MT ID. The eligible-set for each MT ID 646 is determined by the presence of IGP adjacency from Source to the 647 neighboring node on that MT-ID apart from the administrative 648 restrictions and other checks laid out in [RFC5286]. The same is 649 also applicable for MT-OSPF [RFC4915] or different AFs in multi 650 instance OSPFv3 [RFC5838]. 652 However for MT IS-IS, if a "standard topology" is used with MT-ID #0 653 [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are 654 present, then the condition of network congruency is applicable for 655 LFA computation as well. Network congruency here refers to, having 656 same address families provisioned on all the links and all the nodes 657 of the network with MT-ID #0. Here with single decision process both 658 IPv4 and IPv6 next-hops are computed for all the prefixes in the 659 network and similarly with one LFA computation from all eligible 660 neighbors per [RFC5286], all potential alternatives can be computed. 662 6. IANA Considerations 664 This document has no actions for IANA. 666 7. Acknowledgements 668 Authors acknowledge Alia Atlas and Salih K A for their useful 669 feedback and inputs. Thanks to Stewart Bryant for being document 670 shepherd and providing detailed review comments. Thanks to Elwyn 671 Davies for reviewing and providing feedback as part of Gen-art 672 review. Thanks to Alvaro Retena, Adam Roach, Ben Campbell, Benjamin 673 Kaduk and sponsoring Routing Area Director Martin Vigoureux for 674 providing detailed feedback and suggestions. 676 8. Contributing Authors 678 The following people contributed substantially to the content of this 679 document and should be considered co-authors. 681 Chris Bowers 682 Juniper Networks, Inc. 683 1194 N. Mathilda Ave, 684 Sunnyvale, CA 94089, USA 686 Email: cbowers@juniper.net 688 Bruno Decraene 689 Orange, 690 France 692 Email: bruno.decraene@orange.com 694 9. Security Considerations 696 The existing OSPF security considerations continue to apply, as do 697 the recommended manual key management mechanisms specified in 698 [RFC7474]. The existing security considerations for IS-IS also 699 continue to apply, as specified in [RFC5304] and [RFC5310] and 700 extended by [RFC7645] for KARP. This document does not change any of 701 the discussed protocol specifications [RFC1195] [RFC5120] [RFC2328] 702 [RFC5838], and the security considerations of the LFA base 703 specification [RFC5286] therefore continue to apply. 705 10. References 707 10.1. Normative References 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, 711 DOI 10.17487/RFC2119, March 1997, 712 . 714 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 715 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 716 DOI 10.17487/RFC5286, September 2008, 717 . 719 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 720 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 721 May 2017, . 723 10.2. Informative References 725 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 726 dual environments", RFC 1195, DOI 10.17487/RFC1195, 727 December 1990, . 729 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 730 DOI 10.17487/RFC2328, April 1998, 731 . 733 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 734 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 735 RFC 4915, DOI 10.17487/RFC4915, June 2007, 736 . 738 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 739 Topology (MT) Routing in Intermediate System to 740 Intermediate Systems (IS-ISs)", RFC 5120, 741 DOI 10.17487/RFC5120, February 2008, 742 . 744 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 745 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 746 2008, . 748 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 749 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 750 2008, . 752 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 753 DOI 10.17487/RFC5308, October 2008, 754 . 756 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 757 and M. Fanto, "IS-IS Generic Cryptographic 758 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 759 2009, . 761 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 762 RFC 5714, DOI 10.17487/RFC5714, January 2010, 763 . 765 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 766 R. Aggarwal, "Support of Address Families in OSPFv3", 767 RFC 5838, DOI 10.17487/RFC5838, April 2010, 768 . 770 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 771 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 772 DOI 10.17487/RFC6987, September 2013, 773 . 775 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 776 "Security Extension for OSPFv2 When Using Manual Key 777 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 778 . 780 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 781 Authentication for Routing Protocol (KARP) IS-IS Security 782 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 783 . 785 Authors' Addresses 787 Pushpasis Sarkar (editor) 788 Arrcus, Inc. 790 Email: pushpasis.ietf@gmail.com 792 Uma Chunduri (editor) 793 Huawei USA 794 2330 Central Expressway 795 Santa Clara, CA 95050 796 USA 798 Email: uma.chunduri@huawei.com 800 Shraddha Hegde 801 Juniper Networks, Inc. 802 Electra, Exora Business Park 803 Bangalore, KA 560103 804 India 806 Email: shraddha@juniper.net 808 Jeff Tantsura 809 Apstra, Inc. 811 Email: jefftant.ietf@gmail.com 813 Hannes Gredler 814 RtBrick, Inc. 816 Email: hannes@rtbrick.com