idnits 2.17.00 (12 Aug 2021) /tmp/idnits36286/draft-ietf-rtgwg-multihomed-prefix-lfa-07.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 28 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 (September 19, 2018) is 1340 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) ** Downref: Normative reference to an Informational RFC: RFC 5714 Summary: 2 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: March 23, 2019 S. Hegde 7 Juniper Networks, Inc. 8 J. Tantsura 9 Nuage Networks 10 H. Gredler 11 RtBrick, Inc. 12 September 19, 2018 14 LFA selection for Multi-Homed Prefixes 15 draft-ietf-rtgwg-multihomed-prefix-lfa-07 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 RFC8174 [RFC8174]. 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 March 23, 2019. 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 . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . 8 77 4.2.1.1. Multiple ASBRs belonging different area . . . . . 9 78 4.2.1.2. Type 1 and Type 2 costs . . . . . . . . . . . . . 10 79 4.2.1.3. RFC1583compatibility is set to enabled . . . . . 10 80 4.2.1.4. Type 7 routes . . . . . . . . . . . . . . . . . . 10 81 4.2.2. Inequalities to be applied for alternate ASBR 82 selection . . . . . . . . . . . . . . . . . . . . . . 11 83 4.2.2.1. Forwarding address set to non-zero value . . . . 11 84 4.2.2.2. ASBRs advertising type1 and type2 cost . . . . . 11 85 5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 12 86 5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 12 87 5.2. Multi Topology Considerations . . . . . . . . . . . . . . 13 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 90 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 94 10.2. Informative References . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 A framework for the development of IP fast- reroute mechanisms is 100 detailed in [RFC5714]. The use of Loop-Free Alternates (LFA) for IP 101 Fast Reroute is specified in [RFC5286]. Section 6.1 of [RFC5286] 102 describes a method to determine loop-free alternates for multi-homed 103 prefixes (MHPs). This document describes a procedure using explicit 104 inequalities that can be used by a computing router to evaluate a 105 neighbor as a potential alternate for a multi-homed prefix. The 106 results obtained are equivalent to those obtained using the method 107 described in Section 6.1 of [RFC5286]. However, some may find this 108 formulation useful. 110 Section 6.3 of [RFC5286] discusses complications associated with 111 computing LFAs for multi-homed prefixes in OSPF. This document 112 provides detailed criteria for evaluating potential alternates for 113 external prefixes advertised by OSPF ASBRs, as well as explicit 114 inequalities. 116 This document also provides clarifications, additional considerations 117 to [RFC5286], to address a few coverage and operational observations. 118 These observations are in the area of handling IS-IS attach (ATT) bit 119 in Level-1 (L1) area, links provisioned with MAX_METRIC for traffic 120 engineering (TE) purposes and in the area of Multi Topology (MT) IGP 121 deployments. These are elaborated in detail in Section 3.2 and 122 Section 5. 124 1.1. Acronyms 126 AF - Address Family 128 ATT - IS-IS Attach Bit 130 ECMP - Equal Cost Multi Path 132 IGP - Interior Gateway Protocol 134 IS-IS - Intermediate System to Intermediate System 136 LSP - IS-IS Link State PDU 138 OSPF - Open Shortest Path First 140 MHP - Multi-homed Prefix 142 MT - Multi Topology 144 SPF - Shortest Path First PDU 146 2. LFA inequalities for MHPs 148 This document proposes the following set of LFA inequalities for 149 selecting the most appropriate LFAs for multi-homed prefixes (MHPs). 150 They can be derived from the inequalities in [RFC5286] combined with 151 the observation that D_opt(N,P) = Min (D_opt(N,PO_i) + cost(PO_i,P)) 152 over all PO_i 154 Link-Protection: 155 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 156 D_opt(S,PO_best) + cost(PO_best,P) 158 Link-Protection + Downstream-paths-only: 159 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 161 Node-Protection: 162 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 163 D_opt(E,PO_best) + cost(PO_best,P) 165 Where, 166 P - The multi-homed prefix being evaluated for 167 computing alternates 168 S - The computing router 169 N - The alternate router being evaluated 170 E - The primary next-hop on shortest path from S to 171 prefix P. 172 PO_i - The specific prefix-originating router being 173 evaluated. 174 PO_best - The prefix-originating router on the shortest path 175 from the computing router S to prefix P. 176 Cost (X,P) - Cost of reaching the prefix P from prefix 177 originating node X. 178 D_opt(X,Y) - Distance on the shortest path from node X to node 179 Y. 181 Figure 1: LFA inequalities for MHPs 183 3. LFA selection for the multi-homed prefixes 185 To compute a valid LFA for a given multi-homed prefix P, a computing 186 router S MUST follow one of the appropriate procedures below, for 187 each alternate neighbor N. 189 Link-Protection : 190 ================= 191 1. If alternate neighbor N is also prefix-originator of P, 192 1.a. Select N as a LFA for prefix P (irrespective of 193 the metric advertised by N for the prefix P). 194 2. Else, evaluate the link-protecting LFA inequality for P with 195 the N as the alternate neighbor. 196 2.a. If LFA inequality condition is met, 197 select N as a LFA for prefix P. 198 2.b. Else, N is not a LFA for prefix P. 200 Link-Protection + Downstream-paths-only : 201 ========================================= 202 1. Evaluate the link-protecting + downstream-only LFA inequality 203 for P with the N as the alternate neighbor. 204 1.a. If LFA inequality condition is met, 205 select N as a LFA for prefix P. 206 1.b. Else, N is not a LFA for prefix P. 208 Node-Protection : 209 ================= 210 1. If alternate neighbor N is also prefix-originator of P, 211 1.a. Select N as a LFA for prefix P (irrespective of 212 the metric advertised by N for the prefix P). 213 2. Else, evaluate the appropriate node-protecting LFA inequality 214 for P with the N as the alternate neighbor. 215 2.a. If LFA inequality condition is met, 216 select N as a LFA for prefix P. 217 2.b. Else, N is not a LFA for prefix P. 219 Figure 2: Rules for selecting LFA for MHPs 221 In case an alternate neighbor N is also one of the prefix-originators 222 of prefix P, N being a prefix-originator it is guaranteed that N will 223 not loop back packets destined for prefix P to computing router S. 224 So N MUST be chosen as a valid LFA for prefix P, without evaluating 225 any of the inequalities in Figure 1 as long as downstream-paths-only 226 LFA is not desired. To ensure such a neighbor N also provides a 227 downstream-paths-only LFA, router S MUST also evaluate the 228 downstream-only LFA inequality specified in Figure 1 for neighbor N 229 and ensure router N satisfies the inequality. 231 However, if N is not a prefix-originator of P, the computing router 232 SHOULD evaluate one of the corresponding LFA inequalities, as 233 mentioned in Figure 1, once for each remote node that originated the 234 prefix. In case the inequality is satisfied by the neighbor N router 235 S MUST choose neighbor N, as one of the valid LFAs for the prefix P. 237 For more specific rules please refer to the later sections of this 238 document. 240 3.1. Improved coverage with simplified approach to MHPs 242 LFA base specification [RFC5286] Section 6.1 recommends that a router 243 computes the alternate next-hop for an IGP multi-homed prefix by 244 considering alternate paths via all routers that have announced that 245 prefix and the same has been elaborated with appropriate inequalities 246 in the above section. However, [RFC5286] Section 6.1 also allows for 247 the router to simplify the multi-homed prefix calculation by assuming 248 that the MHP is solely attached to the router that was its pre- 249 failure optimal point of attachment, at the expense of potentially 250 lower coverage. If an implementation chooses to simplify the multi- 251 homed prefix calculation by assuming that the MHP is solely attached 252 to the router that was its pre-failure optimal point of attachment, 253 the procedure described in this memo can potentially improve coverage 254 for equal cost multi path (ECMP) MHPs without incurring extra 255 computational cost. 257 This document improves the above approach to provide loop-free 258 alternatives without any additional cost for ECMP MHPs as described 259 through the below example network. The approach specified here MAY 260 also be applicable for handling default routes as explained in 261 Section 3.2. 263 5 +---+ 8 +---+ 5 +---+ 264 +-----| S |------| A |-----| B | 265 | +---+ +---+ +---+ 266 | | | 267 | 5 | 5 | 268 | | | 269 +---+ 5 +---+ 4 +---+ 1 +---+ 270 | C |---| E |-----| M |-------| F | 271 +---+ +---+ +---+ +---+ 272 | 10 5 | 273 +-----------P---------+ 275 Figure 3: MHP with same ECMP Next-hop 277 In the above network a prefix p, is advertised from both Node E and 278 Node F. With simplified approach taken as specified in [RFC5286] 279 Section 6.1, prefix P will get only link protection LFA through the 280 neighbor C while a node protection path is available through neighbor 281 A. In this scenario, E and F both are pre-failure optimal points of 282 attachment and share the same primary next-hop. Hence, an 283 implementation MAY compare the kind of protection A provides to F 284 (link-and-node protection) with the kind of protection C provides to 285 E (link protection) and inherit the better alternative to prefix P 286 and here it is A. 288 However, in the below network prefix P has an ECMP through both node 289 E and node F with cost 20. Though it has 2 pre-failure optimal 290 points of attachment, the primary next-hop to each pre-failure 291 optimal point of attachment is different. In this case, prefix P 292 MUST inherit corresponding LFAs of each primary next-hop calculated 293 for the router advertising the same respectively. In the below 294 diagram that would be node E's and node F's LFA i.e., node N1 and 295 node N2 respectively. 297 4 +----+ 298 +------------------| N2 | 299 | +----+ 300 | | 4 301 10 +---+ 3 +---+ 302 +------| S |----------------| B | 303 | +---+ +---+ 304 | | | 305 | 10 | 1 | 306 | | | 307 +----+ 5 +---+ 16 +---+ 308 | N1 |----| E |-----------------| F | 309 +----+ +---+ +---+ 310 | 10 16 | 311 +-----------P---------+ 313 Figure 4: MHP with different ECMP Next-hops 315 In summary, if there are multiple pre-failure points of attachment 316 for a MHP and primary next-hop of a MHP is same as that of the 317 primary next-hop of the router that was pre-failure optimal point of 318 attachment, an implementation MAY provide a better protection to MHP 319 without incurring any additional computation cost. 321 3.2. IS-IS ATT Bit considerations 323 Per [RFC1195] a default route needs to be added in Level1 (L1) router 324 to the closest reachable Level1/Level2 (L1/L2) router in the network 325 advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers 326 in the area would do this during the decision process with the next- 327 hop of the default route set to the adjacent router through which the 328 closest L1/L2 router is reachable. The base LFA specification 329 [RFC5286] does not specify any procedure for computing LFA for a 330 default route in IS-IS L1 area. This document specifies, a node can 331 consider a default route is being advertised from the border L1/L2 332 router where ATT bit is set, and can do LFA computation for that 333 default route. But, when multiple ECMP L1/L2 routers are reachable 334 in an L1 area corresponding best LFAs SHOULD be given for each 335 primary next-hop associated with default route. Considerations as 336 specified in Section 3 and Section 3.1 are applicable for default 337 routes, if the default route is considered as ECMP MHP. Note that, 338 this document doesn't alter any ECMP handling rules or computation of 339 LFAs for ECMP in general as laid out in [RFC5286]. 341 4. LFA selection for the multi-homed external prefixes 343 Redistribution of external routes into IGP is required in case of two 344 different networks getting merged into one or during protocol 345 migrations. External routes could be distributed into an IGP domain 346 via multiple nodes to avoid a single point of failure. 348 During LFA calculation, alternate LFA next-hops to reach the best 349 ASBR could be used as LFA for the routes redistributed via that ASBR. 350 When there is no LFA available to the best ASBR, it may be desirable 351 to consider the other ASBRs (referred to as alternate ASBR hereafter) 352 redistributing the external routes for LFA selection as defined in 353 [RFC5286] and leverage the advantage of having multiple re- 354 distributing nodes in the network. 356 4.1. IS-IS 358 LFA evaluation for multi-homed external prefixes in IS-IS is similar 359 to the multi-homed internal prefixes. Inequalities described in 360 Section 2 would also apply to multi-homed external prefixes. 362 4.2. OSPF 364 Loop Free Alternates [RFC5286] describes mechanisms to apply 365 inequalities to find the loop free alternate neighbor. For the 366 selection of alternate ASBR for LFA consideration, additional rules 367 have to be applied in selecting the alternate ASBR due to the 368 external route calculation rules imposed by [RFC2328]. 370 This document defines inequalities specifically for the alternate 371 loop-free ASBR evaluation, based on those in [RFC5286]. 373 4.2.1. Rules to select alternate ASBR 375 The process to select an alternate ASBR is best explained using the 376 rules below. The below process is applied when primary ASBR for the 377 concerned prefix is chosen and there is an alternate ASBR originating 378 same prefix. 380 1. If RFC1583Compatibility is disabled 382 1a. if primary ASBR and alternate ASBR belong to intra area 383 non-backbone go to step 2. 384 1b. If primary ASBR and alternate ASBR belong to 385 intra-area backbone and/or inter-area path go 386 to step 2. 387 1c. for other paths, skip this alternate ASBR and 388 consider next ASBR. 390 2. Compare cost types (type 1/type 2) advertised by alternate ASBR and 391 by the primary ASBR 392 2a. If not the same type skip alternate ASBR and consider next ASBR. 393 2b. If same proceed to step 3. 395 3.If cost types are type 1, compare costs advertised by alternate ASBR 396 and by the primary ASBR 397 3a. If costs are the same then program ECMP FRR and return. 398 3b. else go to step 5.. 400 4 If cost types are type 2, compare costs advertised by alternate ASBR 401 and by the primary ASBR 402 4a. If costs are different, skip alternate ASBR and 403 consider next ASBR. 404 4b. If cost are the same, proceed to step 4c to compare 405 cost to reach ASBR/forwarding address. 406 4c. If cost to reach ASBR/forwarding address are also same program ECMP FRR and return. 407 4d. If cost to reach ASBR/forwarding address are different go to step 5. 409 5. If route type (type 5/type 7) 410 5a. If route type is same, check route p-bit, 411 forwarding address field for routes from both 412 ASBRs match. If p-bit and forwarding address matches proceed to step 6. 413 If not, skip this alternate ASBR and consider 414 next ASBR. 415 5b. If route type is not same, skip this alternate ASBR 416 and consider next alternate ASBR. 418 6. Apply inequality on the alternate ASBR. 420 Figure 5: Rules for selecting alternate ASBR in OSPF 422 4.2.1.1. Multiple ASBRs belonging different area 424 When "RFC1583compatibility" is set to disabled, OSPF [RFC2328] 425 defines certain rules of preference to choose the ASBRs. While 426 selecting alternate ASBR for loop evaluation for LFA, these rules 427 should be applied to ensure that the alternate neighbor does not 428 cause loop. 430 When there are multiple ASBRs belonging to different area advertising 431 the same prefix, pruning rules as defined in [RFC2328] section 16.4.1 432 are applied. The alternate ASBRs pruned using above rules are not 433 considered for LFA evaluation. 435 4.2.1.2. Type 1 and Type 2 costs 437 If there are multiple ASBRs not pruned via rules defined in 438 Section 4.2.1.1, the cost type advertised by the ASBRs is compared. 439 ASBRs advertising type 1 costs are preferred and the type 2 costs are 440 pruned. If two ASBRs advertise same type 2 cost, the alternate ASBRs 441 are considered along with their cost to reach ASBR/forwarding adress 442 for evaluation. If the two ASBRs have same type 2 cost as well as 443 same cost to reach ASBR, ECMP FRR is programmed. When there are 444 multiple ASBRs advertising same type 2 cost for the prefix, primary 445 AS external route calculation as described in [RFC2328] section 446 16.4.1 selects the route with lowest type 2 cost. ASBRs advertising 447 different type 2 cost (higher cost) are not considered for LFA 448 evaluation. Alternate ASBRs advertising type 2 cost for the prefix 449 but are not chosen as primary due to higher cost to reach ASBR are 450 considered for LFA evaluation.The inequalities for evaluating 451 alternate ASBR for type 1 and type 2 costs are same, as the alternate 452 ASBRs with different type 2 costs are pruned and the evaluation is 453 based on equal type 2 cost ASBRS. 455 4.2.1.3. RFC1583compatibility is set to enabled 457 When RFC1583Compatibility is set to enabled, multiple ASBRs belonging 458 to different area advertising same prefix are chosen based on cost 459 and hence are valid alternate ASBRs for the LFA evaluation. The 460 inequalities described in Section 4.2.2 are applicable based on 461 forwarding address and cost type advertised in External LSA. 463 4.2.1.4. Type 7 routes 465 Type 5 routes always get preference over Type 7 and the alternate 466 ASBRs chosen for LFA calculation should belong to same type. Among 467 Type 7 routes, routes with p-bit and forwarding address set have 468 higher preference than routes without these attributes. Alternate 469 ASBRs selected for LFA comparison should have same p-bit and 470 forwarding address attributes. 472 4.2.2. Inequalities to be applied for alternate ASBR selection 474 The alternate ASBRs selected using above mechanism described in 475 Section 4.2.1, are evaluated for Loop free criteria using below 476 inequalities. 478 4.2.2.1. Forwarding address set to non-zero value 480 Link-Protection: 481 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 482 F_opt(S,PO_best) + cost(PO_best,P) 484 Link-Protection + Downstream-paths-only: 485 F_opt(N,PO_i)+ cost(PO_i,P) < F_opt(S,PO_best) + cost(PO_best,P) 487 Node-Protection: 488 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 489 F_opt(E,PO_best) + cost(PO_best,P) 491 Where, 492 P - The multi-homed prefix being evaluated for 493 computing alternates 494 S - The computing router 495 N - The alternate router being evaluated 496 E - The primary next-hop on shortest path from S to 497 prefix P. 498 PO_i - The specific prefix-originating router being 499 evaluated. 500 PO_best - The prefix-originating router on the shortest path 501 from the computing router S to prefix P. 502 cost(X,Y) - External cost for Y as advertised by X 503 F_opt(X,Y) - Distance on the shortest path from node X to Forwarding 504 address specified by ASBR Y. 505 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 507 Figure 6: LFA inequality definition when forwarding address is non- 508 zero 510 4.2.2.2. ASBRs advertising type1 and type2 cost 511 Link-Protection: 512 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 513 D_opt(S,PO_best) + cost(PO_best,P) 515 Link-Protection + Downstream-paths-only: 516 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P) 518 Node-Protection: 519 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 520 D_opt(E,PO_best) + cost(PO_best,P) 522 Where, 523 P - The multi-homed prefix being evaluated for 524 computing alternates 525 S - The computing router 526 N - The alternate router being evaluated 527 E - The primary next-hop on shortest path from S to 528 prefix P. 529 PO_i - The specific prefix-originating router being 530 evaluated. 531 PO_best - The prefix-originating router on the shortest path 532 from the computing router S to prefix P. 533 cost(X,Y) - External cost for Y as advertised by X. 534 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 536 Figure 7: LFA inequality definition for type1 and type 2 cost 538 5. LFA Extended Procedures 540 This section explains the additional considerations in various 541 aspects as listed below to the base LFA specification [RFC5286]. 543 5.1. Links with IGP MAX_METRIC 545 Section 3.5 and 3.6 of [RFC5286] describe procedures for excluding 546 nodes and links from use in alternate paths based on the maximum link 547 metric (as defined for IS-IS in [RFC5305] or as defined in [RFC6987] 548 for OSPF). If these procedures are strictly followed, there are 549 situations, as described below, where the only potential alternate 550 available which satisfies the basic loop-free condition will not be 551 considered as alternative. 553 +---+ 10 +---+ 10 +---+ 554 | S |------|N1 |-----|D1 | 555 +---+ +---+ +---+ 556 | | 557 10 | 10 | 558 |MAX_MET(N2 to S) | 559 | | 560 | +---+ | 561 +-------|N2 |--------+ 562 +---+ 563 10 | 564 +---+ 565 |D2 | 566 +---+ 568 Figure 8: Link with IGP MAX_METRIC 570 In the simple example network, all the link costs have a cost of 10 571 in both directions, except for the link between S and N2. The S-N2 572 link has a cost of 10 in the forward direction i.e., from S to N2, 573 and a cost of MAX_METRIC (0xffffff /2^24 - 1 for IS-IS and 0xffff for 574 OSPF) in the reverse direction i.e., from N2 to S for a specific end- 575 to-end Traffic Engineering (TE) requirement of the operator. At node 576 S, D1 is reachable through N1 with cost 20, and D2 is reachable 577 through N2 with cost 20. Even though neighbor N2 satisfies basic 578 loop-free condition (inequality 1 of [RFC5286]) for D1, S's neighbor 579 N2 could be excluded as a potential alternative because of the 580 current exclusions as specified in section 3.5 and 3.6 procedure of 581 [RFC5286]. But, as the primary traffic destined to D2 continues to 582 use the link and hence irrespective of the reverse metric in this 583 case, same link MAY be used as a potential LFA for D1. 585 Alternatively, reverse metric of the link MAY be configured with 586 MAX_METRIC-1, so that the link can be used as an alternative while 587 meeting the operator's TE requirements and without having to update 588 the router to fix this particular issue. 590 5.2. Multi Topology Considerations 592 Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and 593 IS-IS are out of scope for that specification. This memo clarifies 594 and describes the applicability. 596 In Multi Topology (MT) IGP deployments, for each MT ID, a separate 597 shortest path tree (SPT) is built with topology specific adjacencies, 598 the LFA principles laid out in [RFC5286] are actually applicable for 599 MT IS-IS [RFC5120] LFA SPF. The primary difference in this case is, 600 identifying the eligible-set of neighbors for each LFA computation 601 which is done per MT ID. The eligible-set for each MT ID is 602 determined by the presence of IGP adjacency from Source to the 603 neighboring node on that MT-ID apart from the administrative 604 restrictions and other checks laid out in [RFC5286]. The same is 605 also applicable for MT-OSPF [RFC4915] or different AFs in multi 606 instance OSPFv3 [RFC5838]. 608 However for MT IS-IS, if a "standard topology" is used with MT-ID #0 609 [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are 610 present, then the condition of network congruency is applicable for 611 LFA computation as well. Network congruency here refers to, having 612 same address families provisioned on all the links and all the nodes 613 of the network with MT-ID #0. Here with single decision process both 614 IPv4 and IPv6 next-hops are computed for all the prefixes in the 615 network and similarly with one LFA computation from all eligible 616 neighbors per [RFC5286], all potential alternatives can be computed. 618 6. IANA Considerations 620 This document has no actions for IANA. 622 7. Acknowledgements 624 Thanks to Alia Atlas and Salih K A for their useful feedback and 625 inputs. Thanks to Stewart Bryant for being document shepherd and 626 providing detailed review comments. 628 8. Contributing Authors 630 The following people contributed substantially to the content of this 631 document and should be considered co-authors. 633 Chris Bowers 634 Juniper Networks, Inc. 635 1194 N. Mathilda Ave, 636 Sunnyvale, CA 94089, USA 638 Email: cbowers@juniper.ne 640 Bruno Decraene 641 Orange, 642 France 644 Email: bruno.decraene@orange.com 646 9. Security Considerations 648 Existing OSPF security considerations and stronger authentication and 649 manual key management mechanisms are specified in [RFC7474] SHOULD be 650 considered for OSPF deployments. Security concerns for IS-IS are 651 addressed in [RFC5304] and [RFC5310]. Further security analysis for 652 IS-IS protocol is done in [RFC7645] SHOULD be considered for IS-IS 653 deployments. This document does not introduce any change in any of 654 the protocol [RFC1195] [RFC5120] [RFC2328] [RFC5838] specifications 655 discussed here and also this does not introduce any new security 656 issues other than as noted in the LFA base specification [RFC5286]. 658 10. References 660 10.1. Normative References 662 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 663 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 664 DOI 10.17487/RFC5286, September 2008, 665 . 667 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 668 RFC 5714, DOI 10.17487/RFC5714, January 2010, 669 . 671 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 672 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 673 May 2017, . 675 10.2. Informative References 677 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 678 dual environments", RFC 1195, DOI 10.17487/RFC1195, 679 December 1990, . 681 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 682 DOI 10.17487/RFC2328, April 1998, 683 . 685 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 686 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 687 RFC 4915, DOI 10.17487/RFC4915, June 2007, 688 . 690 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 691 Topology (MT) Routing in Intermediate System to 692 Intermediate Systems (IS-ISs)", RFC 5120, 693 DOI 10.17487/RFC5120, February 2008, 694 . 696 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 697 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 698 2008, . 700 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 701 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 702 2008, . 704 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 705 DOI 10.17487/RFC5308, October 2008, 706 . 708 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 709 and M. Fanto, "IS-IS Generic Cryptographic 710 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 711 2009, . 713 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 714 R. Aggarwal, "Support of Address Families in OSPFv3", 715 RFC 5838, DOI 10.17487/RFC5838, April 2010, 716 . 718 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 719 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 720 DOI 10.17487/RFC6987, September 2013, 721 . 723 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 724 "Security Extension for OSPFv2 When Using Manual Key 725 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 726 . 728 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 729 Authentication for Routing Protocol (KARP) IS-IS Security 730 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 731 . 733 Authors' Addresses 734 Pushpasis Sarkar (editor) 735 Arrcus, Inc. 737 Email: pushpasis.ietf@gmail.com 739 Uma Chunduri (editor) 740 Huawei USA 741 2330 Central Expressway 742 Santa Clara, CA 95050 743 USA 745 Email: uma.chunduri@huawei.com 747 Shraddha Hegde 748 Juniper Networks, Inc. 749 Electra, Exora Business Park 750 Bangalore, KA 560103 751 India 753 Email: shraddha@juniper.net 755 Jeff Tantsura 756 Nuage Networks 757 755 Ravendale Drive 758 Mountain View, CA 94043 759 USA 761 Email: jefftant.ietf@gmail.com 763 Hannes Gredler 764 RtBrick, Inc. 766 Email: hannes@rtbrick.com