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