idnits 2.17.1 draft-psarkar-rtgwg-multihomed-prefix-lfa-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 195 has weird spacing: '... 2a. If not s...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 27, 2014) is 3466 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 5286' is mentioned on line 168, but not defined == Missing Reference: 'RFC 2328' is mentioned on line 172, but not defined -- Looks like a reference, but probably isn't: '5286' on line 173 == Missing Reference: 'RFC2328' is mentioned on line 223, but not defined Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 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 H. Gredler 4 Intended status: Informational S. Hegde 5 Expires: April 30, 2015 C. Bowers 6 Juniper Networks, Inc. 7 October 27, 2014 9 LFA selection for Multi-Homed Prefixes 10 draft-psarkar-rtgwg-multihomed-prefix-lfa-00 12 Abstract 14 This document shares experience gained from implementing algorithms 15 to determine Loop-Free Alternates for multi-homed prefixes. In 16 particular, this document provides explicit inequalities that can be 17 used to evaluate neighbours as a potential alternates for multi-homed 18 prefixes. It also provides detailed criteria for evaluating 19 potential alternates for external prefixes advertised by OSPF ASBRs. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 30, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. LFA inequalities for MHPs . . . . . . . . . . . . . . . . . . 3 63 3. LFA selection for the multi-homed external routes . . . . . . 4 64 3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2.1. Rules to select alternate ASBR . . . . . . . . . . . 4 67 3.2.2. Multiple ASBRs belonging different area . . . . . . . 5 68 3.2.3. Type 1 and Type 2 costs . . . . . . . . . . . . . . . 6 69 3.2.4. RFC1583compatibility is set to enabled . . . . . . . 6 70 3.2.5. Type 7 routes . . . . . . . . . . . . . . . . . . . . 6 71 3.2.6. Inequalities to be applied for alternate ASBR 72 selection . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2.6.1. Forwarding address set to non zero value . . . . 6 74 3.2.6.2. ASBRs advertising type1 and type2 cost . . . . . 7 75 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 7.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The use of Loop-Free Alternates (LFA) for IP Fast Reroute is 86 specified in [RFC5286]. Section 6.1 of [RFC5286] describes a method 87 to determine loop-free alternates for a multi-homed prefixes (MHPs). 88 This document describes a procedure using explicit inequalities that 89 can be used by a computing router to evaluate a neighbour as a 90 potential alternate for a multi-homed prefix. The results obtained 91 are equivalent to those obtained using the method described in 92 Section 6.1 of [RFC5286]. However, some may find this formulation 93 useful. 95 Section 6.3 of [RFC5286] discusses complications associated with 96 computing LFAs for multi-homed prefixes in OSPF. This document 97 provides detailed criteria for evaluating potential alternates for 98 external prefixes advertised by OSPF ASBRs, as well as explicit 99 inequalities. 101 2. LFA inequalities for MHPs 103 The following set of inequalities can be used to evaluate LFAs for 104 multi-homed prefixes. 106 This document proposes the following set of LFA inequalities for 107 selecting the most appropriate LFAs for multi-homed prefixes (MHPs). 108 They can be derived from the inequalities in [RFC5286] combined with 109 the observation that D_opt(N,P) = Min (D_opt(N,PO_i) + cost(PO_i,P)) 110 over all PO_i 112 Link-Protection: 113 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 114 D_opt(S,PO_best) + cost (PO_best,P) 116 Link-Protection + Downstream-paths-only: 117 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost (PO_best,P) 119 Node-Protection: 120 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 121 D_opt(E,PO_best) + cost (PO_best,P) 123 Where, 124 S - The computing router 125 N - The alternate router being evaluated 126 E - The primary next-hop on shortest path from S to 127 prefix P. 128 PO_i - The specific prefix-originating router being 129 evaluated. 130 PO_best - The prefix-originating router on the shortest path 131 from the computing router S to prefix P. 132 Cost (X,P) - Cost of reaching the prefix P from prefix 133 originating node X. 134 D_opt(X,Y) - Distance on the shortest path from node X to node 135 Y. 137 Figure 1: LFA inequalities for MHPs 139 To compute a valid LFA for a given multi-homed prefix P, a computing 140 router S shall evaluate for each alternate neighbor N, one of the 141 above set of inequalities, once for each remote node that originated 142 the prefix. If the inequality is satisfied by any neighbour N for 143 any remote prefix-originating node, router S shall choose neighbour 144 N, as one of the valid LFAs for the prefix P. 146 3. LFA selection for the multi-homed external routes 148 Redistribution of external routes into IGP is required in case of two 149 different networks getting merged into one or during protocol 150 migrations. External routes could be distributed into an IGP domain 151 via multiple nodes to avoid a single point of failure. During LFA 152 calculation, alternate LFA next-hops to reach the best ASBR could be 153 used as LFA for the routes redistributed via that ASBR. When there 154 is no LFA available to the best ASBR, it may be desirable to consider 155 the other ASBRs (referred to as alternate ASBR hereafter) 156 redistributing the external routes for LFA selection as defined in 157 [RFC5286] and leverage the advantage of having multiple re- 158 distributing nodes in the network. 160 3.1. IS-IS 162 LFA evaluation for multi-homed external prefixes in IS-IS is similar 163 to the multi-homed internal prefixes. Inequalities described in sec 164 2 would also apply to multi-homed external prefixes as well. 166 3.2. OSPF 168 Loop free Alternates [RFC 5286] describes mechanisms to apply 169 inequalities to find the the loop free alternate neighbour. For the 170 selection of alternate ASBR for LFA consideration, additional rules 171 have to be applied in selecting the alternate ASBR due to the 172 external route calculation rules imposed by [RFC 2328]. This 173 document also defines the inequalities defined in RFC [5286] 174 specifically for the alternate loop-free ASBR evaluation. 176 3.2.1. Rules to select alternate ASBR 178 The process to select an alternate ASBR is best explained using the 179 rules below. The below process is applied when primary ASBR for the 180 concerned prefix is chosen and there is an alternate ASBR originating 181 same prefix. 183 1. If RFC1583Compatibility is disabled 185 1a. if primary ASBR and alternate ASBR are intra area 186 non-backbone path go to step 2. 187 1b. If primary ASBR and alternate ASBR belong to 188 intra-area backbone and/or inter-area path go 189 to step 2. 190 1c. for other paths, skip the alternate ASBR and 191 consider next ASBR. 193 2. If cost type (type1/type2) advertised by alternate 194 ASBR same as primary 195 2a. If not same skip alternate ASBR and consider next ASBR. 197 3. If cost type is type1 198 3a. If cost is same, program ECMP 199 3b. else go to step 5. 201 4 If cost type is type 2 202 4a. If cost is different, skip alternate ASBR and 203 consider next ASBR 204 4b. If type2 cost is same, compare type 1 cost. 205 4c. If type1 cost is also same program ECMP. 206 4d. If type 1 cost is different go to step 5. 208 5. If route type (type 5/type 7) 209 5a. If route type is same, check route p-bit, 210 forwarding address field for routes from both 211 ASBRs 212 match. If not skip alternate ASBR and consider 213 next ASBR. 214 5b. If route type is not same, skip ASBR 215 and consider next ASBR. 217 6. Apply inequality on the alternate ASBR. 219 Figure 2: Rules for selecting alternate ASBR in OSPF 221 3.2.2. Multiple ASBRs belonging different area 223 When "RFC1583compatibility" is set to disabled, OSPF[RFC2328] defines 224 certain rules of preference to choose the ASBRs. While selecting 225 alternate ASBR for loop evaluation for LFA, these rules should be 226 applied and ensured that the alternate neighbour does not loop the 227 traffic back. 229 When there are multiple ASBRs belonging to different area advertising 230 the same prefix, pruning rules as defined in RFC 2328 section 16.4.1 231 are applied. The alternate ASBRs pruned using above rules are not 232 considered for LFA evaluation. 234 3.2.3. Type 1 and Type 2 costs 236 If there are multiple ASBRs not pruned via rules defined in 3.2.2, 237 the cost type advertised by the ASBRs is compared. ASBRs advertising 238 Type1 costs are preferred and the type2 costs are pruned.If two ASBRs 239 advertise same type2 cost, the alternate ASBRs are considered along 240 with their type1 cost for evaluation.If the two ASBRs with same type2 241 as well as type1 cost, ECMP FRR is programmed.If there are two ASBRs 242 with different type2 cost, the higher cost ASBR is pruned.The 243 inequalities for evaluating alternate ASBR for type 1 and type 2 244 costs are same, as the alternate ASBRs with different type2 costs are 245 pruned and the evaluation is based on equal type 2 cost ASBRS. 247 3.2.4. RFC1583compatibility is set to enabled 249 When RFC1583Compatibility is set to enabled, multiple ASBRs belonging 250 to different area advertising same prefix are chosen based on cost 251 and hence are valid alternate ASBRs for the LFA evaluation. 253 3.2.5. Type 7 routes 255 Type 5 routes always get preference over Type 7 and the alternate 256 ASBRs chosen for LFA calculation should belong to same type.Among 257 Type 7 routes, routes with p-bit and forwarding address set have 258 higher preference than routes without these attributes. Alternate 259 ASBRs selected for LFA comparison should have same p-bit and 260 forwarding address attributes. 262 3.2.6. Inequalities to be applied for alternate ASBR selection 264 The alternate ASBRs selected using above mechanism described in 265 3.2.1, are evaluated for Loop free criteria using below inequalities. 267 3.2.6.1. Forwarding address set to non zero value 268 Link-Protection: 269 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 270 F_opt(S,PO_best) + cost (PO_best,P) 272 Link-Protection + Downstream-paths-only: 273 F_opt(N,PO_i)+ cost(PO_i,P) < F_opt(S,PO_best) + 274 cost (PO_best,P) 276 Node-Protection: 277 F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 278 F_opt(E,PO_best) + cost (PO_best,P) 280 Where, 281 S - The computing router 282 N - The alternate router being evaluated 283 E - The primary next-hop on shortest path from S to 284 prefix P. 285 PO_i - The specific prefix-originating router being 286 evaluated. 287 PO_best - The prefix-originating router on the shortest path 288 from the computing router S to prefix P. 289 cost(X,Y) - External cost for Y as advertised by X 290 F_opt(X,Y) - Distance on the shortest path from node X to Forwarding 291 address specified by ASBR Y. 292 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 294 Figure 3: LFA inequality definition when forwarding address in non- 295 zero 297 3.2.6.2. ASBRs advertising type1 and type2 cost 298 Link-Protection: 299 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) + 300 D_opt(S,PO_best) + cost (PO_best,P) 302 Link-Protection + Downstream-paths-only: 303 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost (PO_best,P) 305 Node-Protection: 306 D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) + 307 D_opt(E,PO_best) + cost (PO_best,P) 309 Where, 310 S - The computing router 311 N - The alternate router being evaluated 312 E - The primary next-hop on shortest path from S to 313 prefix P. 314 PO_i - The specific prefix-originating router being 315 evaluated. 316 PO_best - The prefix-originating router on the shortest path 317 from the computing router S to prefix P. 318 cost(X,Y) - External cost for Y as advertised by X. 319 D_opt(X,Y) - Distance on the shortest path from node X to node Y. 321 Figure 4: LFA inequality definition for type1 and type 2 cost 323 4. Acknowledgements 325 Thanks to Alia Atlas and Salih K A for their useful feedback and 326 inputs. 328 5. IANA Considerations 330 N/A. - No protocol changes are proposed in this document. 332 6. Security Considerations 334 This document does not introduce any change in any of the protocol 335 specifications. It simply proposes additional inequalities for 336 selecting LFAs for multi-homed prefixes. 338 7. References 339 7.1. Normative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997. 344 7.2. Informative References 346 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 347 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 349 Authors' Addresses 351 Pushpasis Sarkar (editor) 352 Juniper Networks, Inc. 353 Electra, Exora Business Park 354 Bangalore, KA 560103 355 India 357 Email: psarkar@juniper.net 359 Hannes Gredler 360 Juniper Networks, Inc. 361 1194 N. Mathilda Ave. 362 Sunnyvale, CA 94089 363 US 365 Email: hannes@juniper.net 367 Shraddha Hegde 368 Juniper Networks, Inc. 369 Electra, Exora Business Park 370 Bangalore, KA 560103 371 India 373 Email: shraddha@juniper.net 375 Chris Bowers 376 Juniper Networks, Inc. 377 1194 N. Mathilda Ave. 378 Sunnyvale, CA 94089 379 US 381 Email: cbowers@juniper.net