idnits 2.17.1 draft-chunduri-rtgwg-lfa-extended-procedures-03.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 -- The document date (September 9, 2015) is 3123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MT-OSPF' is mentioned on line 270, but not defined -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Working Group U. Chunduri 2 Internet-Draft J. Tantsura 3 Intended status: Informational Ericsson Inc. 4 Expires: March 12, 2016 C. Bowers 5 Juniper Networks 6 September 9, 2015 8 Extended procedures and considerations for evaluating Loop-Free 9 Alternates 10 draft-chunduri-rtgwg-lfa-extended-procedures-03 12 Abstract 14 This document provide few clarifications and extended procedures to 15 IP Fast Reroute using Loop-Free Alternates as defined in RFC 5286. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 12, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 3 55 2.1. Multi Homed Prefixes . . . . . . . . . . . . . . . . . . 3 56 2.1.1. IS-IS ATT Bit considerations . . . . . . . . . . . . 5 57 2.2. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 5 58 2.3. Multi Topology Considerations . . . . . . . . . . . . . . 6 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 6.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 Loop Free Alternatives (LFAs) as defined in [RFC5286] have been 70 widely deployed, and the operational and manageability considerations 71 are described in great detail in [I-D.ietf-rtgwg-lfa-manageability]. 73 This document intends to provide clarifications, additional 74 considerations to [RFC5286], to address a few coverage and 75 operational observations. These observations are in the area of 76 handling Muti-homed prefixes (MHPs), IS-IS attach (ATT) bit in L1 77 area, links provisioned with MAX_METRIC for traffic engineering (TE) 78 purposes and in the area of Multi Topology (MT) IGP deployments. All 79 these are elaborated in detail in Section 2. 81 1.1. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 1.2. Acronyms 89 AF - Address Family 91 ATT - IS-IS Attach Bit 93 ECMP - Equal Cost Multi Path 95 IGP - Interior Gateway Protocol 96 IS-IS - Intermediate System to Intermediate System 98 OSPF - Open Shortest Path First 100 MHP - Multi-homed Prefix 102 MT - Multi Topology 104 SPF - Shortest Path First PDU 106 2. LFA Extended Procedures 108 This section explains the additional considerations in various 109 aspects as listed below to the base LFA specification [RFC5286]. 111 2.1. Multi Homed Prefixes 113 LFA base specification [RFC5286] Section 6.1 recommends that a router 114 compute the alternate next-hop for an IGP multi-homed prefix by 115 considering alternate paths via all routers that have announced that 116 prefix. However, it also allows for the router to simplify the 117 multi-homed prefix calculation by assuming that the MHP is solely 118 attached to the router that was its pre-failure optimal point of 119 attachment, at the expense of potentially lower coverage. If an 120 implementation chooses to simplify the multi-homed prefix calculation 121 by assuming that the MHP is solely attached to the router that was 122 its pre-failure optimal point of attachment, the procedure described 123 in this memo can potentially improve coverage for equal cost multi 124 path (ECMP) MHPs without incurring extra computational cost. 126 The approach as specified in [RFC5286] Section 6.1 last paragraph, is 127 to simplify the MHP is solely attached to the router that was its 128 pre-failure optimal point of attachment. While this is very scalable 129 approach and simplifies computation, as [RFC5286] notes this may 130 result in little less coverage. 132 This memo improves the above approach to provide loop-free 133 alternatives without any additional cost for equal cost multi path 134 MHPs as described through the below example network. The approach 135 specified here MAY also applicable for handling default routes as 136 explained in Section 2.1.1. 138 5 +---+ 8 +---+ 5 +---+ 139 +-----| S |------| A |-----| B | 140 | +---+ +---+ +---+ 141 | | | 142 | 5 | 5 | 143 | | | 144 +---+ 5 +---+ 4 +---+ 1 +---+ 145 | C |---| E |-----| M |-------| F | 146 +---+ +---+ +---+ +---+ 147 | 10 5 | 148 +-----------p---------+ 150 Figure 1: MHP with same ECMP Next-hop 152 In the above network a prefix p, is advertised from both Node E and 153 Node F. With simplified approach taken as specified in [RFC5286] 154 Section 6.1, prefix p will get only link protection LFA through the 155 neighbor C while a node protection path is available through neighbor 156 A. In this scenario, E and F both are pre-failure optimal points of 157 attachment and share the same primary next-hop. Hence, an 158 implementation MAY compare the kind of protection A provides to F 159 (link-and-node protection) with the kind of protection C provides to 160 E (link protection) and inherit the better alternative to prefix p 161 and here it is A. 163 However, in the below network prefix p has an ECMP through both node 164 E and node F with cost 20. Though it has 2 pre-failure optimal 165 points of attachment, the primary next-hop to each pre-failure 166 optimal point of attachment is different. In this case, prefix p 167 shall inherit corresponding LFA to each primary next-hop calculated 168 for the router advertising the same respectively (node E's and node 169 F's LFA). 171 +---+ 3 +---+ 172 | S |----------------| B | 173 +---+ +---+ 174 | | 175 10 | 1 | 176 | | 177 +---+ 6 +---+ 178 | E |-----------------| F | 179 +---+ +---+ 180 | 10 16 | 181 +-----------p---------+ 183 Figure 2: MHP with different ECMP Next-hops 185 In summary, if there are multiple pre-failure points of attachment 186 for a MHP and primary next-hop of a MHP is same as that of the 187 primary next-hop of the router that was pre-failure optimal point of 188 attachment, an implementation MAY provide the better protection to 189 MHP without incurring any additional computation cost. 191 2.1.1. IS-IS ATT Bit considerations 193 Per [RFC1195] a default route needs to be added in Level1 (L1) router 194 to the closest reachable Level1/Level2 (L1/L2) router in the network 195 advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers 196 in the area would do this during the decision process with the next- 197 hop of the default route set to the adjacent router through which the 198 closest L1/L2 router is reachable. The base LFA specification 199 [RFC5286] does not specify any procedure for computing LFA for a 200 default route in IS-IS L1 area. Potentially one MAY consider a 201 default route is being advertised from the boarder L1/L2 router where 202 ATT bit is set and can do LFA computation for the default route. 203 But, when multiple ECMP L1/L2 routers are reachable in an L1 area 204 corresponding best LFAs SHOULD be given for each primary next-hop 205 associated with default route. Considerations as specified in 206 Section 2.1 are applicable for default routes, if the default route 207 is considered as ECMP MHP. 209 2.2. Links with IGP MAX_METRIC 211 Section 3.5 and 3.6 of [RFC5286] describes procedures for excluding 212 nodes and links from use in alternate paths based on the maximum link 213 metric (as defined in for IS-IS in [RFC5305] or as defined in 214 [RFC3137] for OSPF). If these procedures are strictly followed, 215 there are situations, as described below, where the only potential 216 alternate available which satisfies the basic loop-free condition 217 will not be considered as alternative. 219 +---+ 10 +---+ 10 +---+ 220 | S |------|N1 |-----|D1 | 221 +---+ +---+ +---+ 222 | | 223 10 | 10 | 224 |MAX_MET(N2 to S) | 225 | | 226 | +---+ | 227 +-------|N2 |--------+ 228 +---+ 229 10 | 230 +---+ 231 |D2 | 232 +---+ 234 Figure 3: Link with IGP MAX_METRIC 236 In the simple example network, all the link costs have a cost of 10 237 in both directions, except for the link between S and N2. The S-N2 238 link has a cost of 10 in the direction from S to N2, and a cost of 239 MAX_METRIC in the direction from N2 to S (0xffffff /2^24 - 1 for IS- 240 IS and 0xffff for OSPF) for a specific end to end Traffic Engineering 241 (TE) requirement of the operator. At node S, D1 is reachable through 242 N1 with cost 20, and D2 is reachable through N2 with cost 20. Even 243 though neighbor N2 satisfies basic loop-free condition (inequality 1 244 of [RFC5286]) for D1 this could be excluded as potential alternative 245 because of the current exclusions as specified in section 3.5 and 3.6 246 procedure of [RFC5286]. But, as the primary traffic destined to D2 247 is continue to use the link and hence irrespective of the reverse 248 metric in this case, the same link MAY be used as a potential LFA for 249 D1. 251 Alternatively, reverse metric of the link MAY be configured with 252 MAX_METRIC-1, so that the link can be used as an alternative while 253 meeting the TE requirements. 255 2.3. Multi Topology Considerations 257 Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and 258 ISIS are out of scope for that specification. This memo clarifies 259 and describes the applicability. 261 In Multi Topology (MT) IGP deployments, for each MT ID, a separate 262 shortest path tree (SPT) is built with topology specific adjacencies, 263 the LFA principles laid out in [RFC5286] are actually applicable for 264 MT IS-IS [RFC5120] LFA SPF. The primary difference in this case is, 265 identifying the eligible-set of neighbors for each LFA computation 266 which is done per MT ID. The eligible-set for each MT ID is 267 determined by the presence of IGP adjacency from Source to the 268 neighboring node on that MT-ID apart from the administrative 269 restrictions and other checks laid out in [RFC5286]. The same is 270 also applicable for OSPF [RFC4915] [MT-OSPF] or different AFs in 271 multi instance OSPFv3 [RFC5838]. 273 However for MT IS-IS, if a default topology is used with MT-ID 0 274 [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are 275 present, then the condition of network congruency is applicable for 276 LFA computation as well. Network congruency here refers to, having 277 same address families provisioned on all the links and all the nodes 278 of the network with MT-ID 0. Here with single decision process both 279 IPv4 and IPv6 next-hops are computed for all the prefixes in the 280 network and similarly with one LFA computation from all eligible 281 neighbors per [RFC5286], all potential alternatives can be computed. 283 3. IANA Considerations 285 This document defines no new namespaces and no actions for IANA. 287 4. Security Considerations 289 This document does not introduce any new security issues or any 290 change in security considerations as noted in the LFA base 291 specification [RFC5286]. 293 5. Acknowledgements 295 Authors would like to thank Alia Atlas for detailed review of initial 296 document and providing valuable suggestions. We also thank Bruno 297 Decreane, Stephane Litkowski for their initial review and feedback on 298 the document. 300 6. References 302 6.1. Normative References 304 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 305 dual environments", RFC 1195, DOI 10.17487/RFC1195, 306 December 1990, . 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, 310 DOI 10.17487/RFC2119, March 1997, 311 . 313 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 314 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 315 DOI 10.17487/RFC5286, September 2008, 316 . 318 6.2. Informative References 320 [I-D.ietf-rtgwg-lfa-manageability] 321 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., 322 Horneffer, M., and P. Sarkar, "Operational management of 323 Loop Free Alternates", draft-ietf-rtgwg-lfa- 324 manageability-11 (work in progress), June 2015. 326 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 327 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 328 DOI 10.17487/RFC3137, June 2001, 329 . 331 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 332 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 333 RFC 4915, DOI 10.17487/RFC4915, June 2007, 334 . 336 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 337 Topology (MT) Routing in Intermediate System to 338 Intermediate Systems (IS-ISs)", RFC 5120, 339 DOI 10.17487/RFC5120, February 2008, 340 . 342 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 343 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 344 2008, . 346 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 347 DOI 10.17487/RFC5308, October 2008, 348 . 350 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 351 R. Aggarwal, "Support of Address Families in OSPFv3", 352 RFC 5838, DOI 10.17487/RFC5838, April 2010, 353 . 355 Authors' Addresses 356 Uma Chunduri 357 Ericsson Inc. 358 300 Holger Way, 359 San Jose, California 95134 360 USA 362 Phone: 408 750-5678 363 Email: uma.chunduri@ericsson.com 365 Jeff Tantsura 366 Ericsson Inc. 367 300 Holger Way, 368 San Jose, California 95134 369 USA 371 Email: jeff.tantsura@ericsson.com 373 Chris Bowers 374 Juniper Networks 375 1194 N. Mathilda Ave. 376 Sunnyvale, California 94089 377 USA 379 Email: cbowers@juniper.net