idnits 2.17.1 draft-litkowski-rtgwg-uloop-delay-04.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 (October 14, 2015) is 3089 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3630' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'RFC6571' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 640, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5443 ** Downref: Normative reference to an Informational RFC: RFC 5715 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group S. Litkowski 3 Internet-Draft B. Decraene 4 Intended status: Standards Track Orange 5 Expires: April 16, 2016 C. Filsfils 6 Cisco Systems 7 P. Francois 8 IMDEA Networks 9 October 14, 2015 11 Microloop prevention by introducing a local convergence delay 12 draft-litkowski-rtgwg-uloop-delay-04 14 Abstract 16 This document describes a mechanism for link-state routing protocols 17 to prevent local transient forwarding loops in case of link failure. 18 This mechanism Proposes a two-steps convergence by introducing a 19 delay between the convergence of the node adjacent to the topology 20 change and the network wide convergence. 22 As this mechanism delays the IGP convergence it may only be used for 23 planned maintenance or when fast reroute protects the traffic between 24 the link failure and the IGP convergence. 26 Simulations using real network topologies have been performed and 27 show that local loops are a significant portion (>50%) of the total 28 forwarding loops. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 16, 2016. 53 Copyright Notice 55 Copyright (c) 2015 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Transient forwarding loops side effects . . . . . . . . . . . 3 72 2.1. Fast reroute unefficiency . . . . . . . . . . . . . . . . 3 73 2.2. Network congestion . . . . . . . . . . . . . . . . . . . 5 74 3. Overview of the solution . . . . . . . . . . . . . . . . . . 6 75 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.2. Current IGP reactions . . . . . . . . . . . . . . . . . . 7 78 4.3. Local events . . . . . . . . . . . . . . . . . . . . . . 7 79 4.4. Local delay . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.4.1. Link down event . . . . . . . . . . . . . . . . . . . 8 81 4.4.2. Link up event . . . . . . . . . . . . . . . . . . . . 9 82 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 83 5.1. Applicable case : local loops . . . . . . . . . . . . . . 9 84 5.2. Non applicable case : remote loops . . . . . . . . . . . 10 85 6. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 7. Deployment considerations . . . . . . . . . . . . . . . . . . 11 87 8. Comparison with other solutions . . . . . . . . . . . . . . . 12 88 8.1. PLSN . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 8.2. OFIB . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 95 12.2. Informative References . . . . . . . . . . . . . . . . . 14 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 99 1. Introduction 101 Micro-forwarding loops and some potential solutions are well 102 described in [RFC5715]. This document describes a simple targeted 103 mechanism that solves micro-loops local to the failure; based on 104 network analysis, these are a significant portion of the micro- 105 forwarding loops. A simple and easily deployable solution to these 106 local micro-loops is critical because these local loops cause traffic 107 loss after an advanced fast-reroute alternate has been used (see 108 Section 2.1). 110 Consider the case in Figure 1 where S does not have an LFA to protect 111 its traffic to D. That means that all non-D neighbors of S on the 112 topology will send to S any traffic destined to D if a neighbor did 113 not, then that neighbor would be loop-free. Regardless of the 114 advanced fast-reroute technique used, when S converges to the new 115 topology, it will send its traffic to a neighbor that was not loop- 116 free and thus cause a local micro-loop. The deployment of advanced 117 fast-reroute techniques motivates this simple router-local mechanism 118 to solve this targeted problem. This solution can be work with the 119 various techniques described in [RFC5715]. 121 1 122 D ------ C 123 | | 124 1 | | 5 125 | | 126 S ------ B 127 1 128 Figure 1 130 When S-D fails, a transient forwarding loop may appear between S and 131 B if S updates its forwarding entry to D before B. 133 2. Transient forwarding loops side effects 135 Even if they are very limited in duration, transient forwarding loops 136 may cause high damage for the network. 138 2.1. Fast reroute unefficiency 139 D 140 1 | 141 | 1 142 A ------ B 143 | | ^ 144 10 | | 5 | T 145 | | | 146 E--------C 147 | 1 148 1 | 149 S 151 Figure 2 - RSVPTE FRR case 153 In figure 2, a RSVP-TE tunnel T, provisionned on C and terminating on 154 B, is used to protect against C-B link failure (IGP shortcut 155 activated on C). Primary path of T is C->B and FRR is activated on T 156 providing a FRR bypass or detour using path C->E->A->B. On C, 157 nexthop to D is tunnel T thanks to IGP shortcut. When C-B link fails 158 : 160 1. C detects the failure, and updates the tunnel path using 161 preprogrammed FRR path, traffic path from S to D is : 162 S->E->C->E->A->B->A->D . 164 2. In parallel, on router C, both IGP convergence and TE tunnel 165 convergence (tunnel path recomputation) are occuring : 167 * T path is recomputed : C->E->A->B 169 * IGP path to D is recomputed : C->E->A->D 171 3. On C, tail-end of the TE tunnel (router B) is no more on SPT to 172 D, so C does not encapsulate anymore the traffic to D using the 173 tunnel T and update forwarding entry to D using nexthop E. 175 If C updates its forwarding entry to D before router E, there would 176 be a transient forwarding loop between C and E until E has converged. 178 Router C timeline Router E timeline 180 --- + ---- t0 C-B link fails 181 LoC | ---- t1 C detects failure 182 --- + ---- t2 C activates FRR 183 | 184 T | ---- t3 C updates local LSA/LSP 185 R | 186 A | ---- t4 C floods local LSA/LSP 187 F | 188 F | ---- t5 C computes SPF --- t0 E receives LSA/LSP 189 I | 190 C | ---- t6 C updates RIB/FIB --- t1 E floods LSA/LSP 191 | 192 O | --- t2 E computes SPF 193 K | 194 --- + * (t6' C updates FIB for D) --- t3 E updates RIB/FIB 195 | 196 LoC | ---- t7 Convergence ended on C 197 | 198 | 199 | 200 | 201 | 202 --- + * (Traffic restored to D) * (t3' E updates FIB for D) 203 | 204 | --- t4 Convergence ended on E 205 | 207 The issue described here is completely independent of the fast- 208 reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...). Fast-reroute 209 is working perfectly but ensures protection, by definition, only 210 until the PLR has converged. When implementing FRR, a service 211 provider wants to guarantee a very limited loss of connectivity time. 212 The previous example shows that the benefit of FRR may be completely 213 lost due to a transient forwarding loop appearing when PLR has 214 converged. Delaying FIB updates after IGP convergence may permit to 215 keep fast-reroute path until neighbor has converged and preserve 216 customer traffic. 218 2.2. Network congestion 219 1 220 D ------ C 221 | | 222 1 | | 5 223 | | 224 A -- S ------ B 225 / | 1 226 F E 228 In the figure above, as presented in Section 1, when link S-D fails, 229 a transient forwarding loop may appear between S and B for 230 destination D. The traffic on S-B link will constantly increase due 231 to the looping traffic to D. Depending on TTL of packets, traffic 232 rate destinated to D and bandwidth of link, the S-B link may be 233 congestioned in few hundreds of milliseconds and will stay overloaded 234 until the loop is solved. 236 Congestion introduced by transient forwarding loops are problematic 237 as they are impacting traffic that is not directly concerned by the 238 failing network component. In our example, the congestion of S-B 239 link will impact customer traffic that is not directly concerned by 240 the failure : e.g. A to B, F to B, E to B. Class of services may be 241 implemented to mitigate the congestion but some traffic not directly 242 concerned by the failure would still be dropped as a router is not 243 able to identify looped traffic from normal traffic. 245 3. Overview of the solution 247 This document defines a two-step convergence initiated by the router 248 detecting the failure and advertising the topological changes in the 249 IGP. This introduces a delay between the convergence of the local 250 router and the network wide convergence. This delay is positive in 251 case of "down" events and negative in case of "up" events. 253 This ordered convergence, is similar to the ordered FIB proposed 254 defined in [RFC6976], but limited to only one hop distance. As a 255 consequence, it is simpler and becomes a local only feature not 256 requiring interoperability; at the cost of only covering the 257 transient forwarding loops involving this local router. The proposed 258 mechanism also reuses some concept described in 259 [I-D.ietf-rtgwg-microloop-analysis] with some limitation. 261 4. Specification 262 4.1. Definitions 264 This document will refer to the following existing IGP timers: 266 o LSP_GEN_TIMER: to batch multiple local events in one single local 267 LSP update. It is often associated with damping mechanism to 268 slowdown reactions by incrementing the timer when multiple 269 consecutive events are detected. 271 o SPF_TIMER: to batch multiple events in one single computation. It 272 is often associated with damping mechanism to slowdown reactions 273 by incrementing the timer when the IGP is instable. 275 o IGP_LDP_SYNC_TIMER: defined in [RFC5443] to give LDP some time to 276 establish the session and learn the MPLS labels before the link is 277 used. 279 This document introduces the following two new timers : 281 o ULOOP_DELAY_DOWN_TIMER: slowdown the local node convergence in 282 case of link down events. 284 o ULOOP_DELAY_UP_TIMER: slowdown the network wide IGP convergence in 285 case of link up events. 287 4.2. Current IGP reactions 289 Upon a change of status on an adjacency/link, the existing behavior 290 of the router advertising the event is the following: 292 1. UP/Down event is notified to IGP. 294 2. IGP processes the notification and postpones the reaction in 295 LSP_GEN_TIMER msec. 297 3. Upon LSP_GEN_TIMER expiration, IGP updates its LSP/LSA and floods 298 it. 300 4. SPF is scheduled in SPF_TIMER msec. 302 5. Upon SPF_TIMER expiration, SPF is computed and RIB/FIB are 303 updated. 305 4.3. Local events 307 The mechanisms described in this document assume that there has been 308 a single failure as seen by the IGP area/level. If this assumption 309 is violated (e.g. multiple links or nodes failed), then standard IP 310 convergence MUST be applied. There are three types of single 311 failures: local link, local node, and remote failure. 313 Example : 315 +--- E ----+--------+ 316 | | | 317 A ---- B -------- C ------ D 319 Let B be the computing router when the link B-C fails. B updates its 320 local LSP/LSA describing the link B->C as down, C does the same, and 321 both start flooding their updated LSP/LSAs. During the SPF_TIMER 322 period, B and C learn all the LSPs/LSAs to consider. B sees that C 323 is flooding as down a link where B is the other end and that B and C 324 are describing the same single event. Since B receives no other 325 changes, B can determine that this is a local link failure. 327 [Editor s Note: Detection of a failed broadcast link involves 328 additional complexity and will be described in a future version.] 330 If a router determines that the event is local link failure, then the 331 router may use the mechanism described in this document. 333 Distinguishing local node failure from remote or multiple link 334 failure requires additional logic which is future work to fully 335 describe. To give a sense of the work necessary, if node C is 336 failing, routers B,E and D are updating and flooding updated LSPs/ 337 LSAs. B would need to determine the changes in the LSPs/LSAs from E 338 and D and see that they all relate to node C which is also the far- 339 end of the locally failed link. Once this detection is accurately 340 done, the same mechanism of delaying local convergence can be 341 applied. 343 4.4. Local delay 345 4.4.1. Link down event 347 Upon an adjacency/link down event, this document introduces a change 348 in step 5 in order to delay the local convergence compared to the 349 network wide convergence: the node SHOULD delay the forwarding entry 350 updates by ULOOP_DELAY_DOWN_TIMER. Such delay SHOULD only be 351 introduced if all the LSDB modifications processed are only reporting 352 down local events . Note that determining that all topological 353 change are only local down events requires analyzing all modified 354 LSP/LSA as a local link or node failure will typically be notified by 355 multiple nodes. If a subsequent LSP/LSA is received/updated and a 356 new SPF computation is triggered before the expiration of 357 ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. 359 As a result of this addition, routers local to the failure will 360 converge slower than remote routers. Hence it SHOULD only be done 361 for non urgent convergence, such as for administrative de-activation 362 (maintenance) or when the traffic is Fast ReRouted. 364 4.4.2. Link up event 366 Upon an adjacency/link up event, this document introduces the 367 following change in step 3 where the node SHOULD: 369 o Firstly build a LSP/LSA with the new adjacency but setting the 370 metric to MAX_METRIC . It SHOULD flood it but not compute the SPF 371 at this time. This step is required to ensure the two way 372 connectivity check on all nodes when computing SPF. 374 o Then build the LSP/LSA with the target metric but SHOULD delay the 375 flooding of this LSP/LSA by SPF_TIMER + ULOOP_DELAY_UP_TIMER. 376 MAX_METRIC is equal to MaxLinkMetric (0xFFFF) for OSPF and 2^24-2 377 (0xFFFFFE) for IS-IS. 379 o Then continue with next steps (SPF computation) without waiting 380 for the expiration of the above timer. In other word, only the 381 flooding of the LSA/LSP is delayed, not the local SPF computation. 383 As as result of this addition, routers local to the failure will 384 converge faster than remote routers. 386 If this mechanism is used in cooperation with "LDP IGP 387 Synchronization" as defined in [RFC5443] then the mechanism defined 388 in RFC 5443 is applied first, followed by the mechanism defined in 389 this document. More precisely, the procedure defined in this 390 document is applied once the LDP session is considered "fully 391 operational" as per [RFC5443]. 393 5. Applicability 395 As previously stated, the mechanism only avoids the forwarding loops 396 on the links between the node local to the failure and its neighbor. 397 Forwarding loops may still occur on other links. 399 5.1. Applicable case : local loops 401 A ------ B ----- E 402 | / | 403 | / | 404 G---D------------C F All the links have a metric of 1 406 Figure 2 408 Let us consider the traffic from G to F. The primary path is 409 G->D->C->E->F. When link CE fails, if C updates its forwarding entry 410 for F before D, a transient loop occurs. This is sub-optimal as C 411 has FRR enabled and it breaks the FRR forwarding while all upstream 412 routers are still forwarding the traffic to itself. 414 By implementing the mechanism defined in this document on C, when the 415 CE link fails, C delays the update of his forwarding entry to F, in 416 order to let some time for D to converge. FRR keeps protecting the 417 traffic during this period. When the timer expires on C, forwarding 418 entry to F is updated. There is no transient forwarding loop on the 419 link CD. 421 5.2. Non applicable case : remote loops 423 A ------ B ----- E --- H 424 | | 425 | | 426 G---D--------C ------F --- J ---- K 428 All the links have a metric of 1 except BE=15 430 Figure 3 432 Let us consider the traffic from G to K. The primary path is 433 G->D->C->F->J->K. When the CF link fails, if C updates its 434 forwarding entry to K before D, a transient loop occurs between C and 435 D. 437 By implementing the mechanism defined in this document on C, when the 438 link CF fails, C delays the update of his forwarding entry to K, 439 letting time for D to converge. When the timer expires on C, 440 forwarding entry to F is updated. There is no transient forwarding 441 loop between C and D. However, a transient forwarding loop may still 442 occur between D and A. In this scenario, this mechanism is not 443 enough to address all the possible forwarding loops. However, it 444 does not create additional traffic loss. Besides, in some cases 445 -such as when the nodes update their FIB in the following order C, A, 446 D, for example because the router A is quicker than D to converge- 447 the mechanism may still avoid the forwarding loop that was occuring. 449 6. Simulations 451 Simulations have been run on multiple service provider topologies. 452 So far, only link down event have been tested. 454 +----------+------+ 455 | Topology | Gain | 456 +----------+------+ 457 | T1 | 71% | 458 | T2 | 81% | 459 | T3 | 62% | 460 | T4 | 50% | 461 | T5 | 70% | 462 | T6 | 70% | 463 | T7 | 59% | 464 | T8 | 77% | 465 +----------+------+ 467 Table 1: Number of Repair/Dst that may loop 469 We evaluated the efficiency of the mechanism on eight different 470 service provider topologies (different network size, design). The 471 benefit is displayed in the table above. The benefit is evaluated as 472 follows: 474 o We consider a tuple (link A-B, destination D, PLR S, backup 475 nexthop N) as a loop if upon link A-B failure, the flow from a 476 router S upstream from A (A could be considered as PLR also) to D 477 may loop due to convergence time difference between S and one of 478 his neighbor N. 480 o We evaluate the number of potential loop tuples in normal 481 conditions. 483 o We evaluate the number of potential loop tuples using the same 484 topological input but taking into account that S converges after 485 N. 487 o Gain is how much loops (remote and local) we succeed to suppress. 489 On topology 1, 71% of the transient forwarding loops created by the 490 failure of any link are prevented by implementing the local delay. 491 The analysis shows that all local loops are obviously solved and only 492 remote loops are remaining. 494 7. Deployment considerations 496 Transient forwarding loops have the following drawbacks : 498 o Limit FRR efficiency : even if FRR is activated in 50msec, as soon 499 as PLR has converged, traffic may be affected by a transient loop. 501 o It may impact traffic not directly concerned by the failure (due 502 to link congestion). 504 This local delay proposal is a transient forwarding loop avoidance 505 mechanism (like OFIB). Even if it only address local transient 506 loops, , the efficiency versus complexity comparison of the mechanism 507 makes it a good solution. It is also incrementally deployable with 508 incremental benefits, which makes it an attractive option for both 509 vendors to implement and Service Providers to deploy. Delaying 510 convergence time is not an issue if we consider that the traffic is 511 protected during the convergence. 513 8. Comparison with other solutions 515 As stated in Section 3, our solution reuses some concepts already 516 introduced by other IETF proposals but tries to find a tradeoff 517 between efficiency and simplicity. This section tries to compare 518 behaviors of the solutions. 520 8.1. PLSN 522 PLSN ([I-D.ietf-rtgwg-microloop-analysis]) describes a mechanism 523 where each node in the network tries a avoid transient forwarding 524 loops upon a topology change by always keeping traffic on a loop-free 525 path for a defined duration (locked path to a safe neighbor). The 526 locked path may be the new primary nexthop, another neighbor, or the 527 old primary nexthop depending how the safety condition is satisified. 529 PLSN does not solve all transient forwarding loops (see 530 [I-D.ietf-rtgwg-microloop-analysis] Section 4 for more details). 532 Our solution reuse some concept of PLSN but in a more simple fashion 533 : 535 o PLSN has 3 different behavior : keep using old nexthop, use new 536 primary nexthop if safe, or use another safe nexthop, while our 537 solution only have one : keep using the current nexthop (old 538 primary, or already activated FRR path). 540 o PLSN may cause some damage while using a safe nexthop which is not 541 the new primary nexthop in case the new safe nexthop does not 542 enough provide enough bandwidth (see 543 [I-D.ietf-rtgwg-lfa-manageability]). Our solution may not 544 experience this issue as the service provider may have control on 545 the FRR path being used preventing network congestion. 547 o PLSN applies to all nodes in a network (remote or local changes), 548 while our mechanism applies only on the nodes connected to the 549 topology change. 551 8.2. OFIB 553 OFIB ([RFC6976]) describes a mechanism where convergence of the 554 network upon a topology change is made ordered to prevent transient 555 forwarding loops. Each router in the network must deduce the failure 556 type from the LSA/LSP received and compute/apply a specific FIB 557 update timer based on the failure type and its rank in the network 558 considering the failure point as root. 560 This mechanism permit to solve all the transient forwarding loop in a 561 network at the price of introducing complexity in the convergence 562 process that may require strong monitoring by the service provider. 564 Our solution reuses the OFIB concept but limits it to the first hop 565 that experience the topology change. As demonstrated, our proposal 566 permits to solve all the local transient forwarding loops that 567 represents a high percentage of all the loops. Moreover limiting the 568 mechanism to one hop permit to keep the network-wide convergence 569 behavior. 571 9. Security Considerations 573 This document does not introduce change in term of IGP security. The 574 operation is internal to the router. The local delay does not 575 increase the attack vector as an attacker could only trigger this 576 mechanism if he already has be ability to disable or enable an IGP 577 link. The local delay does not increase the negative consequences as 578 if an attacker has the ability to disable or enable an IGP link, it 579 can already harm the network by creating instability and harm the 580 traffic by creating forwarding packet loss and forwarding loss for 581 the traffic crossing that link. 583 10. Acknowledgements 585 We wish to thanks the authors of [RFC6976] for introducing the 586 concept of ordered convergence: Mike Shand, Stewart Bryant, Stefano 587 Previdi, and Olivier Bonaventure. 589 11. IANA Considerations 591 This document has no actions for IANA. 593 12. References 595 12.1. Normative References 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, 599 DOI 10.17487/RFC2119, March 1997, 600 . 602 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 603 Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 604 2009, . 606 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 607 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 608 2010, . 610 12.2. Informative References 612 [I-D.ietf-rtgwg-lfa-manageability] 613 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., 614 Horneffer, M., and P. Sarkar, "Operational management of 615 Loop Free Alternates", draft-ietf-rtgwg-lfa- 616 manageability-11 (work in progress), June 2015. 618 [I-D.ietf-rtgwg-microloop-analysis] 619 Zinin, A., "Analysis and Minimization of Microloops in 620 Link-state Routing Protocols", draft-ietf-rtgwg-microloop- 621 analysis-01 (work in progress), October 2005. 623 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 624 (TE) Extensions to OSPF Version 2", RFC 3630, 625 DOI 10.17487/RFC3630, September 2003, 626 . 628 [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, 629 B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 630 Alternate (LFA) Applicability in Service Provider (SP) 631 Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, 632 . 634 [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., 635 Francois, P., and O. Bonaventure, "Framework for Loop-Free 636 Convergence Using the Ordered Forwarding Information Base 637 (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 638 2013, . 640 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 641 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 642 RFC 7490, DOI 10.17487/RFC7490, April 2015, 643 . 645 Authors' Addresses 647 Stephane Litkowski 648 Orange 650 Email: stephane.litkowski@orange.com 652 Bruno Decraene 653 Orange 655 Email: bruno.decraene@orange.com 657 Clarence Filsfils 658 Cisco Systems 660 Email: cfilsfil@cisco.com 662 Pierre Francois 663 IMDEA Networks 665 Email: pierre.francois@imdea.org