idnits 2.17.1 draft-ietf-rtgwg-lfa-applicability-06.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 (January 18, 2012) is 4454 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Clarence Filsfils 3 Internet-Draft Cisco Systems 4 Intended status: Informational Pierre Francois 5 Expires: July 21, 2012 Institute IMDEA Networks 6 January 18, 2012 8 LFA applicability in SP networks 9 draft-ietf-rtgwg-lfa-applicability-06 11 Abstract 13 In this document, we analyze the applicability of the Loop-Free 14 Alternates method of providing IP fast re-route in both the core and 15 the access parts of Service Provider networks. We consider both the 16 link and node failure cases, and provide guidance on the 17 applicability of LFA to different network topologies, with special 18 emphasis on the access parts of the network. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 21, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Access Network . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. Triangle . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 3.1.1. E1C1 failure . . . . . . . . . . . . . . . . . . . . . 9 59 3.1.2. C1E1 failure . . . . . . . . . . . . . . . . . . . . . 9 60 3.1.3. uLoop . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.1.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . 10 62 3.2. Full-Mesh . . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.2.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 11 64 3.2.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 12 65 3.2.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 12 66 3.2.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 13 67 3.2.5. uLoop . . . . . . . . . . . . . . . . . . . . . . . . 13 68 3.2.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . 13 69 3.3. Square . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 3.3.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 14 71 3.3.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 15 72 3.3.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 15 73 3.3.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 16 74 3.3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 17 75 3.3.6. A square might become a full-mesh . . . . . . . . . . 18 76 3.3.7. A full-mesh might be more economical than a square . . 18 77 3.4. Extended U . . . . . . . . . . . . . . . . . . . . . . . . 18 78 3.4.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 20 79 3.4.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 20 80 3.4.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 21 81 3.4.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 21 82 3.4.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 22 83 3.5. Dual-plane Core and its impact on the Access LFA 84 analysis . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 3.6. Two-tiered IGP metric allocation . . . . . . . . . . . . . 22 86 3.7. uLoop analysis . . . . . . . . . . . . . . . . . . . . . . 22 87 3.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 4. Core Network . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 4.1. Simulation Framework . . . . . . . . . . . . . . . . . . . 25 90 4.2. Data Set . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 4.3. Simulation results . . . . . . . . . . . . . . . . . . . . 26 92 5. Core and Access protection schemes are independent . . . . . . 27 93 6. Simplicity and other LFA benefits . . . . . . . . . . . . . . 27 94 7. Capacity Planning with LFA in mind . . . . . . . . . . . . . . 28 95 7.1. Coverage Estimation - Default Topology . . . . . . . . . . 28 96 7.2. Coverage estimation in relation to traffic . . . . . . . . 29 97 7.3. Coverage verification for a given set of demands . . . . . 29 98 7.4. Modeling - What-if Scenarios - Coverage impact . . . . . . 29 99 7.5. Modeling - What-if Scenarios - Load impact . . . . . . . . 30 100 7.6. Discussion on metric recommendations . . . . . . . . . . . 30 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 102 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 103 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 106 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 107 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33 108 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 111 1. Introduction 113 In this document, we analyze the applicability of the Loop-Free 114 Alternates (LFA) [RFC5714] [RFC5286] method of providing IP fast re- 115 route (IPFRR) in both the core and the access parts of Service 116 Provider (SP) networks. We consider both the link and node failure 117 cases, and provide guidance on the applicability of LFA to different 118 network topologies, with special emphasis on the access parts of the 119 network. 121 We first introduce the terminology used in this document in 122 Section 2. In Section 3, we describe typical access network designs 123 and we analyze them for LFA applicability. In Section 4, we describe 124 a simulation framework for the study of LFA applicability in SP core 125 networks, and present results based on various SP networks. We then 126 emphasize the independence between protection schemes used in the 127 core and at the access level of the network. Finally we discuss the 128 key benefits of LFA which stem from its simplicity and we draw some 129 conclusions. 131 2. Terminology 133 We use IS-IS [RFC1195] as reference. It is assumed that normal 134 routing (i.e., when traffic not being fast re-routed around a 135 failure) occurs along the shortest path. The analysis is equally 136 applicable to OSPF [RFC2328] [RFC5340]. 138 A per-prefix LFA for a destination D at a node S is a precomputed 139 backup IGP nexthop for that destination. This backup IGP nexthop can 140 be link protecting or node protecting. In this document, we assume 141 that all links to be protected with LFAs are point-to-point. 143 Link-protecting: A neighbor N is a link-protecting per-prefix LFA for 144 S's route to D if equation eq1 is satisfied, with eq1 == ND < NS + SD 145 where XY refers to the IGP distance from X to Y. This is in line with 146 the definition of an LFA in [RFC5714]. 148 eq1 == ND < NS + SD 150 Equation eq1 152 Node-protecting: A Neighbor N is a node-protecting LFA for S's route 153 to D, with initial IGP nexthop F if N is a link-protecting LFA for D 154 and equation eq2 is satisfied, with eq2 == ND < NF + FD. This is in 155 line with the definition of a Node-Protecting Alternate Next-Hop in 157 [RFC5714]. 159 eq2 == ND < NF + FD 161 Equation eq2 163 De facto node-protecting LFA: this is a link-protecting LFA that 164 turns out to be node-protecting. This occurs in cases illustrated by 165 the following examples : 166 o The LFA candidate that is picked by S actually satisfies Equation 167 eq2 but S did not verify that property. The show command issued 168 by the operator would not indicate this LFA as "node protecting" 169 while in practice (de facto) it is. 170 o A cascading effect of multiple LFA's can also provide de facto 171 node protection. Equation eq2 is not satisfied, but the combined 172 activation of LFAs by some other neighbors of the failing node F 173 provides (de facto) node protection. In other words, it puts the 174 dataplane in a state such that packets forwarded by S ultimately 175 reach a neighbor of F that has a node-protecting LFA. Note that 176 in this case S cannot indicate the node-protecting behavior of the 177 repair without running additional computations. 179 Per-Link LFA: a per-link LFA for the link SF is one precomputed 180 backup IGP nexthop for all the destinations reached through SF. This 181 is a neighbor of the repairing node that is a per-Prefix LFA for all 182 the destinations that the repairing node reaches through SF. Note 183 that such a per-link LFA exists if S has a per-prefix LFA for 184 destination F. 186 D 187 / \ 188 10 / \ 10 189 / \ 190 G H----------. 191 | | | 192 1 | 1 | | 193 | | | 194 B C | 10 195 | |\ | 196 | | \ | 197 | | \ 6 | 198 | | \ | 199 7 | 10 | E F 200 | | / / 201 | | / 6 / 5 202 | | / / 203 | |/ / 204 A-------S-----/ 205 7 207 Figure 1: Example 1 209 In Figure 1, considering the protection of link SC, we can see that 210 A, E, and F are per-prefix LFAs for destination D, as none of them 211 use S to reach D. 213 For destination D, A and F are node-protecting LFA as they do not 214 reach D through node C, while E is not node-protecting for S as it 215 reaches D through C. 217 If S does not compute and select node-protecting LFAs, there is a 218 chance that S picks the non node-protecting LFA E, although A and F 219 were node-protecting LFAs. If S enforces the selection of node- 220 protecting LFAs, then in the case of the single failure of link SC, S 221 will first activate its LFA and deviate traffic addressed to D along 222 S-A-B-G-D and/or S-F-H-D, and then converge to its post-convergence 223 optimal path S-E-C-H-D. 225 A is not a per-link LFA for link SC because A reaches C via S. E is a 226 per-Link LFA for link SC as it reaches C through link EC. This per- 227 link LFA does not provide de facto node protection. Upon failure of 228 node C, S would fast-reroute D-destined packets to its per-link lfa 229 (= E). E would himself detect the failure of EC and hence activate 230 its own per-link LFA (=S). Traffic addressed to D would be trapped 231 in a loop and hence there is no de facto node protection behavior. 233 If there were a link between E and F, that E would pick as its LFA 234 for destination D, then E would provide de facto node protection for 235 S, as upon the activation of its LFA, S would deviate traffic 236 addressed to D towards E, which in turns deviates that traffic to F, 237 which does not reach D through C. 239 F is a per-Link LFA for link SC as F reaches C via H. This per-link 240 LFA is de facto node-protecting for destination D as F reaches D via 241 F-H-D. 243 MicroLoop (uLoop): the occurrence of a transient forwarding loop 244 during a routing transition (as defined in [RFC5714]). 246 In Figure 1, the loss of link SE cannot create any uLoop because: 247 1/The link is only used to reach destination E and 2/ S is the sole 248 node changing its path to E upon link SE failure. 3/ S's shortest 249 path to E after the failure goes via C. 4/C's best path to E (before 250 and after link SC failure) is via CE. 252 To the contrary, upon failure of link AB, a microloop may form for 253 traffic destined to B. Indeed, if A updates its FIB before S, A will 254 deviate B-destined traffic towards S, while S is still forwarding 255 this traffic to A. 257 3. Access Network 259 The access part of the network often represents the majority of the 260 nodes and links. It is organized in several tens or more of regions 261 interconnected by the core network. Very often the core acts as an 262 IS-IS level2 domain (OSPF area 0) while each access region is 263 confined in an IS-IS level1 domain (OSPF non 0 area). Very often, 264 the network topology within each access region is derived from a 265 unique template common across the whole access network. Within an 266 access region itself, the network is made of several aggregation 267 regions, each following the same interconnection topologies. 269 For these reasons, in the next sections, we base the analysis of the 270 LFA applicability in a single access region, with the following 271 assumptions: 272 o Two routers (C1 and C2) provide connectivity between the access 273 region and the rest of the network. If a link connects these two 274 routers in the region area, then it has a symmetric IGP metric c. 275 o We analyze a single aggregation region within the access region. 276 Two aggregation routers (A1 and A2) interconnect the aggregation 277 region to the two routers C1 and C2 for the analyzed access 278 region. If a link connects A1 to A2 then it has a symmetric IGP 279 metric a. If a link connects an A to a C router then, for sake of 280 generality, we will call d the metric for the directed link CA and 281 u the metric for the AC directed link. 282 o We analyze two edge routers E1 and E2 in the access region. Each 283 is either dual-homed directly into C1 and C2 (Section 3.1) or into 284 A1 and A2 (Section 3.2, Section 3.3, Section 3.4 ). The directed 285 link metric between Cx/Ax and Ey is d and u in the opposite 286 direction. 287 o We assume a multi-level IGP domain. The analyzed access region 288 forms a level-1 (L1) domain. The core is the level-2 (L2) domain. 289 We assume that the link between C1 and C2, if it exists, is 290 configured as L1L2. We assume that the loopbacks of the C routers 291 are part of the L2 topology. L1 routers learn about them as 292 propagated routes (L2=>L1 with Down bit set). We remind that if 293 an L1L2 router learns about X/x as an L1 path P1, an L2 path P2 294 and an L1L2 path P12, then it will prefer path P1. If P1 is lost, 295 then it will prefer path P2. 296 o We assume that all the C, A and E routers may be connected to 297 customers and hence we analyze LFA coverage for the loopbacks of 298 each type of node. 299 o We assume that no useful traffic is directed to router-to-router 300 subnets and hence we do not analyze LFA applicability for these. 301 o A prefix P models an important IGP destination that is not present 302 in the local access region. The igp metric from C1 to P is x and 303 the metric from C2 to P is x+e. 304 o We analyze LFA coverage against all link and node failures within 305 the access region. 306 o WxYz refers to the link from Wx to Yz. 307 o We assume that c < d + u and a < d + u (commonly agreed design 308 rule). 309 o In the square access design (Section 3.3), we assume that c < a 310 (commonly agreed design rule). 311 o We analyze the most frequent topologies found in an access region. 312 o We first analyze per-prefix LFA applicability and then per-link. 313 o The topologies are symmetric with respect to a vertical axe and 314 hence we only detail the logic for the link and node failures of 315 the left half of the topology. 317 3.1. Triangle 319 We describe the LFA applicability for the failures of each direction 320 of link C1E1, E1 and C1 (Figure 2), and for the failure of each node. 322 P 323 / \ 324 x/ \x+e 325 / \ 326 C1--c--C2 327 |\ /| 328 d/u| \/ |d/u 329 | / \ | 330 E1 E2 332 Figure 2: Triangle 334 3.1.1. E1C1 failure 336 3.1.1.1. Per-Prefix LFA 338 Three destinations are impacted by this link failure: C1, E2 and P. 340 The LFA for destination C1 is C2 because eq1 == c < d + u. Node 341 protection for route C1 is not applicable. (if C1 goes down, traffic 342 destined to C1 is lost anyway). 344 The LFA to E2 is via C2 because eq1 == d < d+u+d. It is node 345 protecting because eq2 == d < c + d. 347 The LFA to P is via C2 because eq1 == c < d + u. It is node 348 protecting if eq2 == x + e < x + c, i.e., if e < c. This 349 relationship between e and c is an important aspect of the analysis, 350 which is discussed in detail in Section 3.5 and Section 3.6 352 Conclusion: all important intra-PoP routes with primary interface 353 E1C1 benefit from LFA link and node protection. All important inter- 354 PoP routes with primary interface E1C1 benefit from LFA link 355 protection, and also from node protection if e < c. 357 3.1.1.2. Per-Link LFA 359 We have a per-prefix LFA to C1 and hence we have a per-link LFA for 360 link E1C1. All impacted destinations are protected for link failure. 361 In case of C1 node failure, the traffic to C1 is lost (by 362 definition), the traffic to E2 is de facto protected against node 363 failure and the traffic to P is de facto protected when e < c. 365 3.1.2. C1E1 failure 366 3.1.2.1. Per-Prefix LFA 368 C1 has one single primary route via C1E1: the route to E1 (because c 369 < d + u). 371 C1's LFA to E1 is via C2 because eq1 == d < c + d. 373 Node protection upon E1's failure is not applicable as the only 374 impacted traffic is sinked at E1 and hence is lost anyway. 376 Conclusion: all important routes with primary interface C1E1 benefit 377 from LFA link protection. Node protection is not applicable. 379 3.1.2.2. Per-Link LFA 381 We have a per-prefix LFA to E1 and hence we have a per-link LFA for 382 link C1E1. De facto node protection is not applicable. 384 3.1.3. uLoop 386 The IGP convergence cannot create any uLoop. See Section 3.7. 388 3.1.4. Conclusion 390 All important intra-PoP routes benefit from LFA link and node 391 protection or de facto node protection. All important inter-PoP 392 routes benefit from LFA link protection. De facto node protection is 393 ensured if e < c (this is particularly the case for dual-plane core 394 or two-tiered-igp-metric design, see later sections). 396 The IGP convergence does not cause any uLoop. 398 Per-link LFA and per-Prefix LFA provide the same protection benefits. 400 3.2. Full-Mesh 402 We describe the LFA applicability for the failures of C1A1, A1E1, E1, 403 A1 and C1 (Figure 3). 405 P 406 / \ 407 x/ \x+e 408 / \ 409 C1--c--C2 410 |\ /| 411 | \ / | 412 d/u | \ | d/u 413 | / \ | 414 |/ \| 415 A1--a--A2 416 |\ /| 417 d/u| \/ |d/u 418 | / \ | 419 E1 E2 421 Figure 3: Full-Mesh 423 3.2.1. E1A1 failure 425 3.2.1.1. Per-Prefix LFA 427 Four destinations are impacted by this link failure: A1, C1, E2 and 428 P. 430 The LFA for A1 is A2: eq1 == a < d + u. Node protection for route A1 431 is not applicable (if A1 goes down, traffic to A1 is lost anyway). 433 The LFA for C1 is A2: eq1 == u < d + u + u. Node protection for 434 route C1 is guaranteed: eq2 == u < a + u. 436 The LFA to E2 is via A2: eq1 == d < d+u+d. Node protection is 437 guaranteed: eq2 == d < a + d. 439 The LFA to P is via A2: eq1 == u + x < d + u + u + x. Node 440 protection is guaranteed: eq2 == u+ x < a + u + x. 442 Conclusion: all important intra-PoP and inter-PoP routes with primary 443 interface E1A1 benefit from LFA link and node protection. 445 3.2.1.2. Per-Link LFA 447 We have a per-prefix LFA to A1 and hence we have a per-link LFA for 448 link E1A1. All impacted destinations are protected for link failure. 449 De facto node protection is provided for all destinations (except to 450 A1 which is not applicable). 452 3.2.2. A1E1 failure 454 3.2.2.1. Per-Prefix LFA 456 A1 has one single primary route via A1E1: the route to E1 (because c 457 < d + u). 459 A1's LFA to E1 is via A2: eq1 == d < a + d. 461 Node protection upon E1's failure is not applicable as the only 462 impacted traffic is sinked at E1 and hence is lost anyway. 464 Conclusion: all important routes with primary interface A1E1 benefit 465 from LFA link protection. Node protection is not applicable. 467 3.2.2.2. Per-Link LFA 469 We have a per-prefix LFA to E1 and hence we have a per-link LFA for 470 link C1E1. De facto node protection is not applicable. 472 3.2.3. A1C1 failure 474 3.2.3.1. Per-Prefix LFA 476 Two destinations are impacted by this link failure: C1 and P. 478 The LFA for C1 is C2 because eq1 == c < d + u. Node protection for 479 route C1 is not applicable (if C1 goes down, traffic to C1 is lost 480 anyway). 482 The LFA for P is via C2 because eq1 == c < d + u. It is de facto 483 protected for node failure if eq2 == x + e < x + c. 485 Conclusion: all important intra-PoP routes with primary interface 486 A1C1 benefit from LFA link protection (node protection is not 487 applicable). All important inter-PoP routes with primary interface 488 E1C1 benefit from LFA link protection (and from de facto node 489 protection if e < c). 491 3.2.3.2. Per-Link LFA 493 We have a per-prefix LFA to C1 and hence we have a per-link LFA for 494 link A1C1. All impacted destinations are protected for link failure. 495 In case of C1 node failure, the traffic to C1 is lost (by definition) 496 and the traffic to P is de facto node protected if e < c. 498 3.2.4. C1A1 failure 500 3.2.4.1. Per-Prefix LFA 502 C1 has three routes via C1A1: A1, E1 and E2. E2 behaves like E1 and 503 hence is not analyzed further. 505 C1's LFA to A1 is via C2 because we assumed c < a and eq1 == d < c + 506 d. Node protection upon A1's failure is not applicable as the 507 traffic to A1 is lost anyway. 509 C1's LFA to E1 is via A2: eq1 == d < u+ d + d. Node protection upon 510 A1's failure is guaranteed because: eq2 == d < a + d. 512 Conclusion: all important routes with primary interface C1A1 benefit 513 from LFA link protection. Node protection is guaranteed where 514 applicable. 516 3.2.4.2. Per-Link LFA 518 We have a per-prefix LFA to A1 and hence we have a per-link LFA for 519 link C1E1. De facto node protection is available. 521 3.2.5. uLoop 523 The IGP convergence cannot create any uLoop. See Section 3.7. 525 3.2.6. Conclusion 527 All important intra-PoP routes benefit from LFA link and node 528 protection. 530 All important inter-PoP routes benefit from LFA link protection. 531 They benefit from node protection upon failure of A nodes. They 532 benefit from node protections upon failure of C nodes if e < c (this 533 is particularly the case for dual-plane core or two-tiered-igp-metric 534 design, see later sections). 536 The IGP convergence does not cause any uLoop. 538 Per-link LFA and per-Prefix LFA provide the same protection benefits. 540 3.3. Square 542 We describe the LFA applicability for the failures of C1A1, A1E1, E1, 543 A1 and C1 (Figure 4). 545 P 546 / \ 547 x/ \x+e 548 / \ 549 C1--c--C2 550 |\ | \ 551 | \ | +-------+ 552 d/u | \ | \ 553 | +-|-----+ \ 554 | | \ \ 555 A1--a--A2 A3--a--A4 556 |\ /| | / 557 d/u| \/ |d/u | / 558 | / \ | |/ 559 E1 E2 E3 561 Figure 4: Square 563 3.3.1. E1A1 failure 565 3.3.1.1. Per-Prefix LFA 567 E1 has six routes via E1A1: A1, C1, P, E2, A3, E3. 569 E1's LFA route to A1 is via A2 because eq1 == a < d + u. Node 570 protection for traffic to A1 upon A1 node failure is not applicable. 572 E1's LFA route to A3 is via A2 because eq1 == u + c + d < d + u + u + 573 d. This LFA is guaranteed to be node protecting because eq2 == u + c 574 + d < a + u + d. 576 E1's LFA route to C1 is via A2 because eq1 == u + c < d + u + u. 577 This LFA is guaranteed to be node protecting because eq2 == u + c < a 578 + u. 580 E1's primary route to E2 is via ECMP(E1A1, E1A2). The LFA for the 581 first ECMP path (via A1) is the second ECMP path (via A2). This LFA 582 is guaranteed to be node protecting because eq2 == d < a + d. 584 E1's primary route to E3 is via ECMP(E1A1, E1A2). The LFA for the 585 first ECMP path (via A1) is the second ECMP path (via A2). This LFA 586 is guaranteed to be node protecting because eq2 == u + d + d < a + u 587 d + d. 589 If e=0: E1's primary route to P is via ECMP(E1A1, E1A2). The LFA for 590 the first ECMP path (via A1) is the second ECMP path (via A2). This 591 LFA is guaranteed to be node protecting because eq2 == u + x + 0 < a 592 + u + x . 594 If e<>0: E1's primary route to P is via E1A1. Its LFA is via A2 595 because eq1 == u + c + x < d + u + u + x. This LFA is guaranteed to 596 be node protecting because eq2 == u + c + x < a + u + x. 598 Conclusion: all important intra-PoP and inter-PoP routes with primary 599 interface E1A1 benefit from LFA link protection and node protection. 601 3.3.1.2. Per-Link LFA 603 We have a per-prefix LFA for A1 and hence we have a per-link LFA for 604 link E1A1. All important intra-PoP and inter-PoP routes with primary 605 interface E1A1 benefit from LFA per-link protection and de facto node 606 protection. 608 3.3.2. A1E1 failure 610 3.3.2.1. Per-Prefix LFA 612 A1 has one single primary route via A1E1: the route to E1. 614 A1's LFA for route E1 is the path via A2 because eq1 == d < a + d. 615 Node protection is not applicable. 617 Conclusion: all important routes with primary interface A1E1 benefit 618 from LFA link protection. Node protection is not applicable. 620 3.3.2.2. Per-Link LFA 622 All important routes with primary interface A1E1 benefit from LFA 623 link protection. De facto node protection is not applicable. 625 3.3.3. A1C1 failure 627 3.3.3.1. Per-Prefix LFA 629 Four destinations are impacted when A1C1 fails: C1, A3, E3, and P. 631 A1's LFA to C1 is via A2 because eq1 == u + c < a + u. Node 632 protection property is not applicable for traffic to C1 when C1 633 fails. 635 A1's LFA to A3 is via A2 because eq1 == u + c + d < a + u + d. It is 636 de facto node protecting as a < u + c + d (as we assumed a < u + d). 637 Indeed A2 forwards traffic destined to A3 to C2, and C2 has a node 638 protecting LFA for A3, for the failure of C2C1, being A4, as a < u + 639 c + d. Hence the cascading application of LFAs by A1 and C2 during 640 the failure of C1 provides de facto node protection. 642 A1's LFA to E3 is via A2 because eq1 == u + d + d < a + u + d + d. 643 It is node protecting because eq2 == u + d + d < u + c + d + d. 645 A1's primary route to P is via C1 (even if e=0, u+x < u + c + x). 646 The LFA is via A2 because eq1 == [u + c + x < a + u + x]. This LFA 647 is node protecting (from the viewpoint of A1 computing eq2) if eq2 == 648 u + x + e < u + c + x hence if e < c. 650 Conclusion: all important intra-PoP routes with primary interface 651 A1C1 benefit from LFA link protection and node protection. Note that 652 A3 benefits from a de facto node protection. All important inter-PoP 653 routes with primary interface A1C1 benefit from LFA link protection. 654 They also benefit from node protection if e < c. 656 3.3.3.2. Per-Link LFA 658 All important intra-PoP routes with primary interface A1C1 benefit 659 from LFA link protection and de facto node protection. All important 660 inter-PoP routes with primary interface A1C1 benefit from LFA link 661 protection. They also benefit from de facto node protection if e < 662 c. 664 3.3.4. C1A1 failure 666 3.3.4.1. Per-Prefix LFA 668 Three destinations are impacted by C1A1 link failure: A1, E1 and E2. 669 E2's analysis is the same as E1 and hence is omitted. 671 C1's has no LFA for A1. Indeed, all its neighbors (C2 and A3) have a 672 shortest path to A1 via C1. This is due to the assumption (c < a). 674 C1's LFA for E1 is via C2 because eq1 == d + d < c + d + d. It 675 provides node protection because eq2 == d + d < d + a + d. 677 Conclusion: all important intra-PoP routes with primary interface 678 A1C1 except A1 benefit from LFA link protection and node protection. 680 3.3.4.2. Per-Link LFA 682 C1 does not have a per-prefix LFA for destination A1 and hence there 683 is no per-link LFA for the link C1A1. 685 3.3.4.3. Assumptions on the values of c and a 687 The commonly agreed design rule (c < a) is especially beneficial for 688 a deployment using per-link LFA: it provides a per-link LFA for the 689 most important direction (A1C1). Indeed, there are many more 690 destinations reachable over A1C1 than over C1A1. As the IGP 691 convergence duration is proportional to the number of routes to 692 update, there is a better benefit in leveraging LFA FRR for the link 693 A1C1 than the link C1A1. 695 Note as well that the consequence of this assumption is much more 696 important for per-link LFA than for per-prefix LFA. 698 For per-prefix LFA, in case of link C1A1 failure, we do have a per- 699 prefix LFA for E1, E2 and any node subtended below A1 and A2. 700 Typically most of the traffic traversing the link C1A1 is directed to 701 these E nodes and hence the lack of per-prefix LFA for the 702 destination A1 might be insignificant. This is a good example of the 703 coverage benefit of per-prefix LFA over per-link LFA. 705 In the remainder of this section we analyze the consequence of not 706 having c < a. 708 It definitely has a negative impact upon per-link LFA. 710 With c >= a, C1A1 has a per-link LFA while A1C1 has no per-link LFA. 711 The number of destinations impacted by A1C1 failure is much larger 712 than the direction C1A1 and hence the protection is provided for the 713 wrong direction. 715 For per-prefix LFA, the availability of an LFA depends on the 716 topology and needs to be assessed individually for each per-prefix. 717 Some backbone topologies will lead to very good protection coverage, 718 some others might provide very poor coverage. 720 More specifically, the coverage upon A1C1 failure of a remote 721 destination P depends on whether e < a. In such case, A2 is a de- 722 facto node-protecting per-prefix LFA for P. 724 Such a study likely requires a planning tool as each remote 725 destination P would have a different e value (exception: all the edge 726 devices of other aggregation pairs within the same region as for 727 these e=0 by definition, e.g. E3). 729 Finally note that c = a is the worst choice as in this case C1 has no 730 per-prefix LFA for A1 (and vice versa) and hence there is no per-link 731 LFA for C1A1 and A1C1. 733 3.3.5. Conclusion 735 All important intra-PoP routes benefit from LFA link and node 736 protection with one exception: C1 has no per-prefix LFA to A1. 738 All important inter-PoP routes benefit from LFA link protection. 739 They benefit from node protection if e < c. 741 Per-link LFA provides the same protection coverage as per-prefix LFA 742 with two exceptions. First, C1A1 has no per-link LFA at all. 743 Second, when per-prefix LFA provides node protection (eq2 is 744 satisfied), per-link LFA provides effective de facto node protection. 746 3.3.6. A square might become a full-mesh 748 If the vertical links of the square are made of parallel links (at L3 749 or at L2), then one should consider splitting these "vertical links" 750 into "vertical and crossed links". The topology becomes "full-mesh". 751 One should also ensure that the two resulting set of links (vertical 752 and crossed) do not share any SRLG. 754 A typical reason preventing this is that the A1C1 bandwidth may be 755 within a building while the A1C2 is between buildings. Hence while 756 from a router port viewpoint the operation is cost-neutral, it is not 757 from a cost of bandwidth viewpoint. 759 3.3.7. A full-mesh might be more economical than a square 761 In a full-mesh, the vertical and cross-links play the dominant role 762 as they support most of the primary and backup paths. The capacity 763 of the horizontal links can be dimensioned on the basis of traffic 764 destined to a single C or a single A and a single E node. 766 3.4. Extended U 768 For the Extended U topology, we define the following terminology: 770 C1L1: the node "C1" as seen in topology L1. 772 C1L2: the node "C1" as seen in topology L2. 774 C1LO: the loopback of C1. This loopback is in L2. 776 C2LO: the loopback of C2. This loopback is in L2. 778 Let us also remind that C1 and C2 are L1L2 routers and that their 779 loopbacks are in L2 only. 781 P 782 / \ 783 x/ \x+e 784 / \ 785 C1<...>C2 786 |\ | \ 787 | \ | +-------+ 788 d/u | \ | \ 789 | +-|-----+ \ 790 | | \ \ 791 A1--a--A2 A3--a--A4 792 |\ /| | / 793 d/u| \/ |d/u | / 794 | / \ | |/ 795 E1 E2 E3 797 Figure 5: Extended U 799 There is no L1 link between C1 and C2. There might be an L2 link 800 between C1 and C2. This is not relevant as this is not seen from the 801 viewpoint of the L1 topology which is the focus of our analysis. 803 It is guaranteed that there is a path from C1LO to C2LO within the L2 804 topology (except if the L2 topology partitions which is very unlikely 805 and hence not analyzed here). We call "c" its path cost. Once 806 again, we assume that c < a. 808 We exploit this property to create a tunnel T between C1LO and C2LO. 809 Once again, as the source and destination addresses are the loopbacks 810 of C1 and C2 and these loopbacks are in L2 only, it is guaranteed 811 that the tunnel does not transit via the L1 domain. 813 IS-IS does not run over the tunnel and hence the tunnel is not used 814 for any primary paths within the L1 or L2 topology. 816 Within Level1, we configure C1 (C2) with a Level1 LFA extended 817 neighbor "C2 via tunnel T" ("C1 via tunnel T"). 819 A router supporting such extension learns that it has one additional 820 potential neighbor in topology Level1 when checking for LFA's. 822 The L1 topology learns about C1LO as an L2=>L1 route with Down bit 823 set propagated by C1L1 and C2L1. The metric advertised by C2L1 is 824 bigger than the metric advertised by C1L1 by "c". 826 The L1 topology learns about P as an L2=>L1 routes with Down bit set 827 propagated by C1L1 and C2L1. The metric advertised by C2L1 is bigger 828 than the metric advertised by C1L1 by "e". This implies that e <= c. 830 3.4.1. E1A1 failure 832 3.4.1.1. Per-Prefix LFA 834 Five destinations are impacted by E1A1 link failure: A1, C1LO, E2, E3 835 and P. 837 The LFA for A1 is via A2 because eq1 == a < d + u. Node protection 838 for traffic to A1 upon A1 node failure is not applicable. 840 The LFA for E2 is via A2 because eq1 == d < d + u + d. Node 841 protection is guaranteed because eq2 == d < a + d. 843 The LFA for E3 is via A2 because eq1 == u + d + d < d + u + d + d. 844 Node protection is guaranteed because eq2 == u + d + d < a + u + d + 845 d. 847 The LFA for C1LO is via A2 because eq1 == u + c < d + u + u. Node 848 protection is guaranteed because eq2 == u + c < a + u. 850 If e=0: E1's primary route to P is via ECMP(E1A1, E1A2). The LFA for 851 the first ECMP path (via A1) is the second ECMP path (via A2). Node 852 protection is possible because eq2 == u + x < a + u + x. 854 If e<>0: E1's primary route to P is via E1A1. Its LFA is via A2 855 because eq1 == a + c + x < d + u + u + x. Node protection is 856 guaranteed because eq2 == u + x + e < a + u + x <=> e < a. This is 857 true because e <= c and c < a. 859 Conclusion: same as the square topology. 861 3.4.1.2. Per-Link LFA 863 Same as the square topology. 865 3.4.2. A1E1 failure 867 3.4.2.1. Per-Prefix LFA 869 Same as the square topology. 871 3.4.2.2. Per-Link LFA 873 Same as the square topology. 875 3.4.3. A1C1 failure 877 3.4.3.1. Per-Prefix LFA 879 Three destinations are impacted when A1C1 fails: C1, E3 and P. 881 A1's LFA to C1LO is via A2 because eq1 == u + c < a + u. Node 882 protection property is not applicable for traffic to C1 when C1 883 fails. 885 A1's LFA to E3 is via A2 because eq1 == u + d + d < d + u + u + d + 886 d. Node protection is guaranteed because eq2 == u + d + d < a + u + 887 d + d. 889 A1's primary route to P is via C1 (even if e=0, u + x < a + u + x). 890 The LFA is via A2 because eq1 == u + x + e < a + u + x <=> e < a 891 (which is true see above). Node protection is guaranteed because eq2 892 == u + x + e < a + u + x. 894 Conclusion: same as the square topology 896 3.4.3.2. Per-Link LFA 898 Same as the square topology. 900 3.4.4. C1A1 failure 902 3.4.4.1. Per-Prefix LFA 904 Three destinations are impacted by C1A1 link failure: A1, E1 and E2. 905 E2's analysis is the same as E1 and hence is omitted. 907 C1L1 has an LFA for A1 via the extended neighbor C2L1 reachable via 908 tunnel T. Indeed, eq1 is true: d + a < d + a + u + d. From the 909 viewpoint of C1L1, C2L1's path to C1L1 is C2L1-A2-A1-C1L1. Remember 910 the tunnel is not seen by IS-IS for computing primary paths! Node 911 protection is not applicable for traffic to A1 when A1 fails. 913 C1L1's LFA for E1 is via extended neighbor C2L1 (over tunnel T) 914 because eq1 == d + d < d + a + u + d + d. Node protection is 915 guaranteed because eq2 == d + d < d + a + d. 917 3.4.4.2. Per-Link LFA 919 C1 has a per-prefix LFA for destination A1 and hence there is a per- 920 link LFA for the link C1A1. Node resistance is applicable for 921 traffic to E1 (and E2). 923 3.4.5. Conclusion 925 The extended U topology is as good as the square topology. 927 It does not require any cross links between the A and C nodes within 928 an aggregation region. It does not need an L1 link between the C 929 routers in an access region. Note that a link between the C routers 930 might exist in the L2 topology. 932 3.5. Dual-plane Core and its impact on the Access LFA analysis 934 A Dual-plane core is defined as follows 935 o Each access region k is connected to the core by two C routers 936 (C(1,k) and C(2,k)). 937 o C(1,k) is part of Plane1 of the dual-plane core. 938 o C(2,k) is part of Plane2 of the dual-plane core. 939 o C(1,k) has a link to C(2, l) iff k = l 940 o {C(1,k) has a link to C(1, l)} iff {C(2,k) has a link to C(2, l)} 942 In a dual-plane core design, e = 0 and hence the LFA node-protection 943 coverage is improved in all the analyzed topologies. 945 3.6. Two-tiered IGP metric allocation 947 A Two-tiered IGP metric allocation scheme is defined as follows 948 o all the link metrics used in the L2 domain are part of range R1 949 o all the link metrics used in an L1 domain are part of range R2 950 o range R1 << range R2 such that the difference e = C2P - C1P is 951 smaller than any link metric within an access region. 953 Assuming such an IGP metric allocation, the following properties are 954 guaranteed : c < a, e < c, and e < a. 956 3.7. uLoop analysis 958 In this section, we analyze a case where the routing transition 959 following the failure of a link may have some uLoop potential for one 960 destination. Then we show that all the other cases do not have uLoop 961 potential. 963 In the square design, upon the failure of link C1A1, traffic 964 addressed to A1 can undergo a transient forwarding loop as C1 965 reroutes traffic to C2, which initially reaches A1 through C1, as c < 966 a. This loop will actually occur when C1 updates its FIB for 967 destination A1 before C2. 969 It can be shown that all the other routing transitions following a 970 link failure in the analyzed topologies do not have uLoop potential. 972 Indeed, in each case, for all destinations affected by the failure, 973 the rerouting nodes deviate their traffic directly to adjacent nodes 974 whose paths towards these destinations do not change. As a 975 consequence, all these routing transitions cannot undergo transient 976 forwarding loops. 978 For example, in the square topology, the failure of directed link 979 A1C1 does not lead to any uLoop. The destinations reached over that 980 directed link are C1 and P. A1 and E1's shortest paths to these 981 destinations after the convergence go via A2. A2's path to C1 and P 982 is not using A1C1 before the failure, hence no uLoop may occur. 984 3.8. Summary 986 In this section, we summarize the applicability of LFAs detailed in 987 the previous sections. For link protection, we use "Full" to refer 988 to the applicability of LFAs for each destination, reached via any 989 link of the topology. For node protection, we use "yes" to refer to 990 the fact that node protection is achieved for a given node. 991 1. Intra Area Destinations 992 Link Protection 993 + Triangle: Full 994 + Full-Mesh: Full 995 + Square: Full, except C1 has no LFA for dest A1 996 + Extended U: Full 997 Node Protection 998 + Triangle: yes. 999 + Full-Mesh: yes. 1000 + Square: yes. 1001 + Extended U: yes. 1002 2. Inter Area Destinations 1003 Link Protection 1004 + Triangle: Full 1005 + Full-Mesh: Full 1006 + Square: Full 1007 + Extended U: Full 1008 Node Protection 1009 + Triangle: yes if e e 1019 4. Per-Link LFA vs Per-Prefix LFA 1020 * Triangle: Same 1021 * Full-Mesh: Same 1022 * Square: Same except C1A1 has no per-Link LFA. In practice, 1023 this means that per-prefix LFAs will be used (hence C1 has no 1024 LFA for dest=E1 and dest=A1) 1025 * Extended U : Same 1027 4. Core Network 1029 In the backbone, the optimization of the network design to achieve 1030 the maximum LFA protection is less straightforward than in the case 1031 of the access/aggregation network. 1033 The main optimization objectives for backbone topology design are 1034 cost, latency, and bandwidth, constrained by the availability of 1035 fiber. Optimizing the design for Local IP restoration is more likely 1036 to be considered as a non-primary objective. For example, the way 1037 the fiber is laid out and the resulting cost to change it leads to 1038 ring topologies in some backbone networks. 1040 Also, the capacity planning process is already complex in the 1041 backbone. It needs to make sure that the traffic matrix (demand) is 1042 supported by the underlying network (capacity) under all possible 1043 variation of the underlying network (what-if scenario related to one- 1044 srlg failure). Classically, "supported" means that no congestion be 1045 experienced and that the demands be routed along the appropriate 1046 latency paths. Selecting LFA as a deterministic FRR solution for the 1047 backbone would require to enhance the capacity planning process to 1048 add a third constraint: each variation of the underlying network 1049 should lead to a sufficient LFA coverage (we detail this aspect in a 1050 following section). 1052 To the contrary, the access network is based on many replications of 1053 a small number of well-known (well-engineered) topologies. The LFA 1054 coverage is deterministic and is independent of additions/insertions 1055 of a new edge device, a new aggregation sub-region or a new access 1056 region. 1058 In practice, we believe that there are three profiles for the 1059 backbone applicability of LFA. 1061 In the first profile, the designer plans all the network resilience 1062 on IGP convergence. In such case, LFA is a free bonus. If an LFA is 1063 available, then the loss of connectivity is likely reduced by a 1064 factor 10 (50msec vs 500msec), else the loss of connectivity depends 1065 on IGP convergence which is anyway the initial target. LFA should be 1066 very successful here as it provides a significant improvement without 1067 any additional cost. 1069 In the second profile, the designer seeks a very high and 1070 deterministic FRR coverage and he either does not want or cannot 1071 engineer the topology. LFA should not be considered in this case. 1072 MPLS TE FRR would perform much better in this environment. Explicit 1073 routing ensures that a backup path exists what-ever the underlying 1074 topology. 1076 In the third profile, the designer seeks a very high and 1077 deterministic FRR coverage and he does engineer the topology. LFA is 1078 appealing in this scenario as it can provide a very simple way to 1079 obtain protection. Furthermore, in practice, the requirement for FRR 1080 coverage might be limited to a certain part of the network, given by 1081 a sub-topology and/or is likely limited to a subset of the demands 1082 within the traffic matrix. In such case, if the relevant part of the 1083 network natively provides a high degree of LFA protection for the 1084 demands of interest, it might actually be straightforward to improve 1085 the topology and achieve the level of protection required for the 1086 sub-topology and demands which matter. Once again, the practical 1087 problem needs to be considered (which sub-topology, which real 1088 demands need 50msec) as it is often simpler than the theoretical 1089 generic one. 1091 For the reasons explained previously, the backbone applicability 1092 should be analyzed on a case by case basis and it is difficult to 1093 derive generic rules. 1095 In order to help the reader to assess the LFA applicability in its 1096 own case, we provide in the next section some simulation results 1097 based on 11 real backbone topologies. 1099 4.1. Simulation Framework 1101 In order to perform an analysis of LFA applicability in the core, we 1102 usually receive the complete IS-IS/OSPF linkstate database taken on a 1103 core router. We parse it to obtain the topology. During this 1104 process, we eliminate all nodes connected to the topology with a 1105 single link and all prefixes except a single "node address" per 1106 router. We compute the availability of per-prefix LFA's to all these 1107 node addresses which we call "destinations" hereafter. We treat each 1108 link in each direction. 1110 For each (directed) link, we compute whether we have a per-prefix LFA 1111 to the next-hop. If so, we have a per-link LFA for the link. 1113 The Per-link-LFA coverage for a topology T is the fraction of the 1114 number of links with a per-link LFA divided by the total number of 1115 links. 1117 For each link, we compute the number of destinations whose primary 1118 path involves the analyzed link. For each such destination, we 1119 compute whether a per-prefix LFA exists. 1121 The Per-Prefix-LFA coverage for a topology T is the fraction: 1123 (the sum across all links of the number of destinations with a 1124 primary path over the link and a per-prefix LFA) 1126 divided by 1128 (the sum across all links of the number of destinations with a 1129 primary path over the link) 1131 4.2. Data Set 1133 Our data set is based on 11 SP core topologies with different 1134 geographical scopes: worldwide, national and regional. The number of 1135 nodes range from 600 to 16. The average link-to-node ratio is 2.3 1136 with a minimum of 1.2 and maximum of 6. 1138 4.3. Simulation results 1140 +----------+--------------+----------------+ 1141 | Topology | Per-link LFA | Per-prefix LFA | 1142 +----------+--------------+----------------+ 1143 | T1 | 45% | 76% | 1144 | T2 | 49% | 98% | 1145 | T3 | 88% | 99% | 1146 | T4 | 68% | 84% | 1147 | T5 | 75% | 94% | 1148 | T6 | 87% | 98% | 1149 | T7 | 16% | 67% | 1150 | T8 | 87% | 99% | 1151 | T9 | 67% | 79% | 1152 | T10 | 98% | 99% | 1153 | T11 | 59% | 77% | 1154 | Average | 67% | 89% | 1155 | Median | 68% | 94% | 1156 +----------+--------------+----------------+ 1158 Table 1: Core LFA Coverages 1160 In Table 1, we observe a wide variation in terms of LFA coverage 1161 across topologies; From 67% to 100% for the per-prefix LFA coverage, 1162 and from 16% to 98% for the per-link LFA coverage. Several 1163 topologies have been optimized for LFAs (T3, 6, 8 and 10). This 1164 illustrates the need for case by case analysis when considering LFA 1165 for core networks. 1167 It should be noted that, to the contrary of the access/aggregation 1168 topologies, per-prefix LFA outperforms per-link LFA in the backbone. 1170 5. Core and Access protection schemes are independent 1172 Specifically, a design might use LFA FRR in the access and MPLS TE 1173 FRR in the core. 1175 LFA provides great benefits for the access network due to its 1176 excellent access coverage and its simplicity. 1178 MPLS TE FRR's topology independence might prove beneficial in the 1179 core when either the LFA FRR coverage is judged too small and/or the 1180 designer feels unable to optimize the topology to improve the LFA 1181 coverage. 1183 6. Simplicity and other LFA benefits 1185 The LFA solution provides significant benefits which mainly stem from 1186 its simplicity. 1188 The LFA behavior is an automated process that makes fast restoration 1189 an intrinsic part of the IGP, with no additional configuration burden 1190 in the IGP or any other protocol. 1192 Thanks to this integration, the use of multiple areas in the IGP does 1193 not make Fast Restoration more complex to achieve than in a single 1194 area IGP design. 1196 There is no requirement for network-wide upgrade as LFAs do not 1197 require any protocol change and hence can be deployed router by 1198 router. 1200 With LFAs, the backup paths are pre-computed and installed in the 1201 dataplane in advance of the failure. Assuming a fast enough FIB 1202 update time compared to the total number of (important) destinations, 1203 a "<50msec repair" requirement becomes achievable. With a prefix- 1204 independent implementation, LFAs have a fixed repair time, as it only 1205 depends on the failure detection time and the time to activate the 1206 LFA behavior, which does not scale with the number of destinations to 1207 be fast rerouted. 1209 Link and node protection are provided together and without 1210 operational difference (as a comparison, MPLS TE FRR link and node 1211 protections require different types of backup tunnels and different 1212 grades of operational complexity). 1214 Also, compared to MPLS TE FRR, an important simplicity aspect of LFA 1215 is that is does not require the introduction of yet another virtual 1216 layer of topology. Maintaining a virtual topology of explicit MPLS 1217 TE tunnels clearly increases the complexity of the network. MPLS TE 1218 tunnels would have to be represented in a network management system 1219 in order to be monitored and managed. In large networks this may 1220 significantly contribute to the number of network entities polled by 1221 the network management system and monitored by operational staff. 1222 LFA on the other hand only has to be monitored for its operational 1223 status once per router and it needs to be considered in the network 1224 planning process. If the latter is done based on offline simulations 1225 for failure cases anyways, the incremental cost of supporting LFA for 1226 a defined set of demands may be relatively low. 1228 The per-prefix mode of LFAs allows for a simpler and more efficient 1229 capacity planning. As the backup path of each destination is 1230 optimized individually, the load to be fast rerouted can be spread on 1231 a set of shortest-repair-paths (as opposed to one single backup 1232 tunnel). This leads for a simpler and more efficient capacity 1233 planning process that takes congestion during protection into 1234 account. 1236 7. Capacity Planning with LFA in mind 1238 We briefly describe the functionality a designer should expect from a 1239 capacity planning tool supporting LFA and the related capacity 1240 planning process. 1242 7.1. Coverage Estimation - Default Topology 1244 Per-Link LFA Coverage Estimation: the tool would color each 1245 unidirectional link in depending on whether per-link LFA is available 1246 or not. Per-Prefix LFA Coverage Estimation: the tool would color 1247 each unidirectional link with a colored gradient based on the % of 1248 destinations which have a per-prefix LFA. 1250 On top of the visual GUI reporting, the tool should provide detailed 1251 tables listing, on a per interface basis: percentage of LFA, number 1252 of prefixes with LFA, number without LFA, list of prefixes without 1253 LFA. 1255 Furthermore, the tool should provide the percentage and list the 1256 traffic matrix demands with less than 100% source-to-destination LFA 1257 coverage, and, average coverage (#links this demand has an LFA on/# 1258 links this demands traverses) for every demands (using a threshold). 1260 The user should be able to alter the color scheme to show whether 1261 these LFAs are guaranteed-node-protecting or de-facto node protecting 1262 or only link protecting. 1264 This functionality provides the same level of information as we 1265 described in sections 4.1 to 4.3. 1267 7.2. Coverage estimation in relation to traffic 1269 Instead of reporting the coverage as a ratio of the number of 1270 destinations with a backup, one might prefer a ratio of the amount of 1271 traffic on a link that benefits from protection. 1273 This is likely much more relevant as not all destinations are equal 1274 and it is much more important to have an LFA for a destination 1275 attracting lots of traffic rather than an unpopular destination. 1277 7.3. Coverage verification for a given set of demands 1279 Depending on the requirements on the network it might be more 1280 relevant to verify the complete LFA coverage of a given sub-topology, 1281 or a given set of demands, rather than calculating the relative 1282 coverage of the overall traffic. This is most likely true for the 1283 third engineering profile described in Section 4. 1285 In that case, the tool should be able to separately report the LFA 1286 coverage on a given set of demands and highlight each part of the 1287 network that does not support 100% coverage for any of those demands. 1289 7.4. Modeling - What-if Scenarios - Coverage impact 1291 The tool should be able to compute the coverage for all the possible 1292 topologies that result from a set of expected failures (ie. one-srlg 1293 failure). 1295 Filtering the key information from the huge amount of generated data 1296 should be a key property of the tool. 1298 For example, the user could set a threshold (at least 80% per-prefix 1299 LFA coverage in all one-srlg what-if scenarios) and the tool would 1300 report only the cases where this condition is not met, hopefully with 1301 some assistance on how to remedy the problem (IGP metric 1302 optimization). 1304 As an application example, a designer who is not able to ensure c < a 1305 could leverage such a tool to assess the per-prefix LFA coverage for 1306 square aggregation topologies grafted to its core backbone topology. 1307 The tool would analyze the per-prefix LFA availability for each 1308 remote destination and would help optimize the backbone topology to 1309 increase the LFA protection coverage for failures within the square 1310 aggregation topologies. 1312 7.5. Modeling - What-if Scenarios - Load impact 1314 The tool should be able to compute the link load for all routing 1315 states that result from a set of expected failures (i.e. one-srlg 1316 failure). 1318 The routing states that should be supported are: 1/ network-wide 1319 converged state before the failure, 2/ all the LFA's protecting the 1320 failure are active and 3/ network-wide converged state after the 1321 failure. 1323 Filtering the key information from the huge amount of generated data 1324 should be a key property of the tool. 1326 For example, the user could set a threshold (at most 100% link load 1327 in all one-srlg what-if scenarios) and the tool would report only the 1328 cases where this condition is violated, hopefully with some 1329 assistance on how to remedy the problem (IGP metric optimization). 1331 The tool should be able to do this for the aggregate load and as well 1332 on a per class of service basis. 1334 Note: in case the traffic matrix is unknown, an intermediate solution 1335 consists in identifying the destinations that would attract traffic 1336 (i.e. PE routers), and those that would not (i.e. P routers). You 1337 could achieve this by creating a traffic matrix with equal demands 1338 between the sources/destinations that would attract traffic (Pe to 1339 PE). This will be more relevant than considering all demands between 1340 all prefixes (e.g. when there is no customer traffic from P to P). 1342 7.6. Discussion on metric recommendations 1344 While LFA FRR has many benefits (section 6), LFA FRR's applicability 1345 depends on topology. 1347 The purpose of this document is to show how to introduce a level of 1348 control on this topology parameter. 1350 On the one hand, we wanted to show that by adopting a small set of 1351 igp metric constraints and a repetition of well-behaved patterns, the 1352 designer could deterministically guarantee maximum link and node 1353 protection for the vast majority of the network (the access/ 1354 aggregation). Doing so, he would obtain an extremely simple 1355 resiliency solution. 1357 One another side, we also wanted to show that it might not be so bad 1358 to not apply (all) these constraints. 1360 Indeed, we showed in section 3.3.4.3 that the per-prefix LFA coverage 1361 in a square where c > a might still be very good. 1363 We showed in section 4.3 that the median per-prefix LFA coverage for 1364 11 SP backbone topologies still provides for 94% coverage (most of 1365 these topologies were built without any idea of LFA)! 1367 Furthermore, we showed that any topology may be analyzed with an LFA- 1368 aware capacity planning tool. This would readily assess the coverage 1369 of per-prefix LFA and would assist the designer in fine-tuning it to 1370 obtain the level of protection he seeks. 1372 While this document highlighted LFA applicability and benefits for SP 1373 network, it also noted that LFA is not meant to replace MPLS TE FRR. 1375 With a very-LFA-unfriendly topology, a designer seeking a guaranteed 1376 < 50msec protection might be better off leveraging the explicit- 1377 routed backup capability of MPLS TE FRR to provide 100% protection 1378 while ensuring no congestion along the backup paths during 1379 protection. 1381 But when LFA provides 100% link and node protection without any 1382 uLoop, then clearly LFA seems a technology to consider to drastically 1383 simplify the operation of a large-scale network. 1385 8. Security Considerations 1387 The security considerations applicable to LFAs are described in 1388 [RFC5286]. This document does not introduce any new security 1389 considerations. 1391 9. IANA considerations 1393 This draft does not require any IANA considerations. 1395 10. Conclusions 1397 LFA is an important protection alternative for IP/MPLS networks. 1399 Its simplicity benefit is significant, in terms of automation and 1400 integration with the default IGP behavior and the absence of any 1401 requirement for network-wide upgrade. The technology does not 1402 require any protocol change and hence can be deployed router by 1403 router. 1405 At first sight, these significant simplicity benefits are negated by 1406 the topological dependency of its applicability. 1408 The purpose of this document was to highlight that very frequent 1409 access and aggregation topologies benefit from excellent link and 1410 node LFA coverage. 1412 A second objective consisted in describing the three different 1413 profiles of LFA applicability for the IP/MPLS core networks and 1414 illustrating them with simulation results based on real SP core 1415 topologies. 1417 11. Contributors 1419 This work has been realized in tight collaboration with the following 1420 people. 1422 Mike Shand 1423 imc.shand@googlemail.com 1425 Bruno Decraene 1426 France Telecom 1427 38-40 rue du General Leclerc 1428 92794 Issy Moulineaux cedex 9 1429 FR 1430 bruno.decraene@orange.com 1432 James Uttaro 1433 ATT 1434 200 S. Laurel Avenue 1435 07748, Middletown, NJ 1436 US 1437 uttaro@att.com 1439 Nicolai Leymann 1440 Deutsche Telekom 1441 Winterfeldtstrasse 21 1442 10781, Berlin 1443 DE 1444 N.Leymann@telekom.de 1446 Martin Horneffer 1447 Deutsche Telekom 1448 Hammer Str. 216-226 1449 48153, Muenster 1450 DE 1451 Martin.Horneffer@telekom.de 1453 12. Acknowledgments 1455 We would like to thank Alvaro Retana and Stewart Bryant (in bold) for 1456 their precious comments on this work. 1458 13. References 1460 13.1. Normative References 1462 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1463 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1465 13.2. Informative References 1467 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1468 RFC 5714, January 2010. 1470 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1471 dual environments", RFC 1195, December 1990. 1473 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1475 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1476 for IPv6", RFC 5340, July 2008. 1478 Authors' Addresses 1480 Clarence Filsfils 1481 Cisco Systems 1482 Brussels 1000 1483 BE 1485 Email: cf@cisco.com 1487 Pierre Francois 1488 Institute IMDEA Networks 1489 Avda. del Mar Mediterraneo, 22 1490 Leganese 28918 1491 ES 1493 Email: pierre.francois@imdea.org