idnits 2.17.1 draft-litkowski-rtgwg-uloop-delay-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3723 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: 'I-D.ietf-rtgwg-remote-lfa' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC6571' is defined on line 626, 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 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-lfa-manageability-03 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-04 Summary: 2 errors (**), 0 flaws (~~), 6 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: August 18, 2014 C. Filsfils 6 Cisco Systems 7 P. Francois 8 IMDEA Networks 9 February 14, 2014 11 Microloop prevention by introducing a local convergence delay 12 draft-litkowski-rtgwg-uloop-delay-03 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 August 18, 2014. 53 Copyright Notice 55 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Transient forwarding loops side effects . . . . . . . . . . . 4 72 2.1. Fast reroute unefficiency . . . . . . . . . . . . . . . . 4 73 2.2. Network congestion . . . . . . . . . . . . . . . . . . . . 6 74 3. Overview of the solution . . . . . . . . . . . . . . . . . . . 7 75 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.2. Current IGP reactions . . . . . . . . . . . . . . . . . . 8 78 4.3. Local events . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.4. Local delay . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.4.1. Link down event . . . . . . . . . . . . . . . . . . . 9 81 4.4.2. Link up event . . . . . . . . . . . . . . . . . . . . 10 82 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 83 5.1. Applicable case : local loops . . . . . . . . . . . . . . 10 84 5.2. Non applicable case : remote loops . . . . . . . . . . . . 11 85 6. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7. Deployment considerations . . . . . . . . . . . . . . . . . . 13 87 8. Comparison with other solutions . . . . . . . . . . . . . . . 13 88 8.1. PLSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 8.2. OFIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 95 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 98 1. Introduction 100 Micro-forwarding loops and some potential solutions are well 101 described in [RFC5715]. This document describes a simple targeted 102 mechanism that solves micro-loops local to the failure; based on 103 network analysis, these are a significant portion of the micro- 104 forwarding loops. A simple and easily deployable solution to these 105 local micro-loops is critical because these local loops cause traffic 106 loss after an advanced fast-reroute alternate has been used (see 107 Section 2.1). 109 Consider the case in Figure 1 where S does not have an LFA to protect 110 its traffic to D. That means that all non-D neighbors of S on the 111 topology will send to S any traffic destined to D if a neighbor did 112 not, then that neighbor would be loop-free. Regardless of the 113 advanced fast-reroute technique used, when S converges to the new 114 topology, it will send its traffic to a neighbor that was not loop- 115 free and thus cause a local micro-loop. The deployment of advanced 116 fast-reroute techniques motivates this simple router-local mechanism 117 to solve this targeted problem. This solution can be work with the 118 various techniques described in [RFC5715]. 120 1 121 D ------ C 122 | | 123 1 | | 5 124 | | 125 S ------ B 126 1 127 Figure 1 129 When S-D fails, a transient forwarding loop may appear between S and 130 B if S updates its forwarding entry to D before B. 132 2. Transient forwarding loops side effects 134 Even if they are very limited in duration, transient forwarding loops 135 may cause high damage for the network. 137 2.1. Fast reroute unefficiency 138 D 139 1 | 140 | 1 141 A ------ B 142 | | ^ 143 10 | | 5 | T 144 | | | 145 E--------C 146 | 1 147 1 | 148 S 150 Figure 2 - RSVPTE FRR case 152 In figure 2, a RSVP-TE tunnel T, provisionned on C and terminating on 153 B, is used to protect against C-B link failure (IGP shortcut 154 activated on C). Primary path of T is C->B and FRR is activated on T 155 providing a FRR bypass or detour using path C->E->A->B. On C, nexthop 156 to D is tunnel T thanks to IGP shortcut. When C-B link fails : 158 1. C detects the failure, and updates the tunnel path using 159 preprogrammed FRR path, traffic path from S to D is : 160 S->E->C->E->A->B->A->D . 162 2. In parallel, on router C, both IGP convergence and TE tunnel 163 convergence (tunnel path recomputation) are occuring : 165 * T path is recomputed : C->E->A->B 167 * IGP path to D is recomputed : C->E->A->D 169 3. On C, tail-end of the TE tunnel (router B) is no more on SPT to 170 D, so C does not encapsulate anymore the traffic to D using the 171 tunnel T and update forwarding entry to D using nexthop E. 173 If C updates its forwarding entry to D before router E, there would 174 be a transient forwarding loop between C and E until E has converged. 176 Router C timeline Router E timeline 178 --- + ---- t0 C-B link fails 179 LoC | ---- t1 C detects failure 180 --- + ---- t2 C activates FRR 181 | 182 T | ---- t3 C updates local LSA/LSP 183 R | 184 A | ---- t4 C floods local LSA/LSP 185 F | 186 F | ---- t5 C computes SPF --- t0 E receives LSA/LSP 187 I | 188 C | ---- t6 C updates RIB/FIB --- t1 E floods LSA/LSP 189 | 190 O | --- t2 E computes SPF 191 K | 192 --- + * (t6' C updates FIB for D) --- t3 E updates RIB/FIB 193 | 194 LoC | ---- t7 Convergence ended on C 195 | 196 | 197 | 198 | 199 | 200 --- + * (Traffic restored to D) * (t3' E updates FIB for D) 201 | 202 | --- t4 Convergence ended on E 203 | 205 The issue described here is completely independent of the fast- 206 reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...). Fast-reroute 207 is working perfectly but ensures protection, by definition, only 208 until the PLR has converged. When implementing FRR, a service 209 provider wants to guarantee a very limited loss of connectivity time. 210 The previous example shows that the benefit of FRR may be completely 211 lost due to a transient forwarding loop appearing when PLR has 212 converged. Delaying FIB updates after IGP convergence may permit to 213 keep fast-reroute path until neighbor has converged and preserve 214 customer traffic. 216 2.2. Network congestion 217 1 218 D ------ C 219 | | 220 1 | | 5 221 | | 222 A -- S ------ B 223 / | 1 224 F E 226 In the figure above, as presented in Section 1, when link S-D fails, 227 a transient forwarding loop may appear between S and B for 228 destination D. The traffic on S-B link will constantly increase due 229 to the looping traffic to D. Depending on TTL of packets, traffic 230 rate destinated to D and bandwidth of link, the S-B link may be 231 congestioned in few hundreds of milliseconds and will stay overloaded 232 until the loop is solved. 234 Congestion introduced by transient forwarding loops are problematic 235 as they are impacting traffic that is not directly concerned by the 236 failing network component. In our example, the congestion of S-B 237 link will impact customer traffic that is not directly concerned by 238 the failure : e.g. A to B, F to B, E to B. Class of services may be 239 implemented to mitigate the congestion but some traffic not directly 240 concerned by the failure would still be dropped as a router is not 241 able to identify looped traffic from normal traffic. 243 3. Overview of the solution 245 This document defines a two-step convergence initiated by the router 246 detecting the failure and advertising the topological changes in the 247 IGP. This introduces a delay between the convergence of the local 248 router and the network wide convergence. This delay is positive in 249 case of "down" events and negative in case of "up" events. 251 This ordered convergence, is similar to the ordered FIB proposed 252 defined in [RFC6976], but limited to only one hop distance. As a 253 consequence, it is simpler and becomes a local only feature not 254 requiring interoperability; at the cost of only covering the 255 transient forwarding loops involving this local router. The proposed 256 mechanism also reuses some concept described in 257 [I-D.ietf-rtgwg-microloop-analysis] with some limitation. 259 4. Specification 260 4.1. Definitions 262 This document will refer to the following existing IGP timers: 264 o LSP_GEN_TIMER: to batch multiple local events in one single local 265 LSP update. It is often associated with damping mechanism to 266 slowdown reactions by incrementing the timer when multiple 267 consecutive events are detected. 269 o SPF_TIMER: to batch multiple events in one single computation. It 270 is often associated with damping mechanism to slowdown reactions 271 by incrementing the timer when the IGP is instable. 273 o IGP_LDP_SYNC_TIMER: defined in [RFC5443] to give LDP some time to 274 establish the session and learn the MPLS labels before the link is 275 used. 277 This document introduces the following two new timers : 279 o ULOOP_DELAY_DOWN_TIMER: slowdown the local node convergence in 280 case of link down events. 282 o ULOOP_DELAY_UP_TIMER: slowdown the network wide IGP convergence in 283 case of link up events. 285 4.2. Current IGP reactions 287 Upon a change of status on an adjacency/link, the existing behavior 288 of the router advertising the event is the following: 290 1. UP/Down event is notified to IGP. 292 2. IGP processes the notification and postpones the reaction in 293 LSP_GEN_TIMER msec. 295 3. Upon LSP_GEN_TIMER expiration, IGP updates its LSP/LSA and floods 296 it. 298 4. SPF is scheduled in SPF_TIMER msec. 300 5. Upon SPF_TIMER expiration, SPF is computed and RIB/FIB are 301 updated. 303 4.3. Local events 305 The mechanisms described in this document assume that there has been 306 a single failure as seen by the IGP area/level. If this assumption 307 is violated (e.g. multiple links or nodes failed), then standard IP 308 convergence MUST be applied. There are three types of single 309 failures: local link, local node, and remote failure. 311 Example : 313 +--- E ----+--------+ 314 | | | 315 A ---- B -------- C ------ D 317 Let B be the computing router when the link B-C fails. B updates its 318 local LSP/LSA describing the link B->C as down, C does the same, and 319 both start flooding their updated LSP/LSAs. During the SPF_TIMER 320 period, B and C learn all the LSPs/LSAs to consider. B sees that C 321 is flooding as down a link where B is the other end and that B and C 322 are describing the same single event. Since B receives no other 323 changes, B can determine that this is a local link failure. 325 [Editor s Note: Detection of a failed broadcast link involves 326 additional complexity and will be described in a future version.] 328 If a router determines that the event is local link failure, then the 329 router may use the mechanism described in this document. 331 Distinguishing local node failure from remote or multiple link 332 failure requires additional logic which is future work to fully 333 describe. To give a sense of the work necessary, if node C is 334 failing, routers B,E and D are updating and flooding updated LSPs/ 335 LSAs. B would need to determine the changes in the LSPs/LSAs from E 336 and D and see that they all relate to node C which is also the far- 337 end of the locally failed link. Once this detection is accurately 338 done, the same mechanism of delaying local convergence can be 339 applied. 341 4.4. Local delay 343 4.4.1. Link down event 345 Upon an adjacency/link down event, this document introduces a change 346 in step 5 in order to delay the local convergence compared to the 347 network wide convergence: the node SHOULD delay the forwarding entry 348 updates by ULOOP_DELAY_DOWN_TIMER. Such delay SHOULD only be 349 introduced if all the LSDB modifications processed are only reporting 350 down local events . Note that determining that all topological 351 change are only local down events requires analyzing all modified 352 LSP/LSA as a local link or node failure will typically be notified by 353 multiple nodes. If a subsequent LSP/LSA is received/updated and a 354 new SPF computation is triggered before the expiration of 355 ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. 357 As a result of this addition, routers local to the failure will 358 converge slower than remote routers. Hence it SHOULD only be done 359 for non urgent convergence, such as for administrative de-activation 360 (maintenance) or when the traffic is Fast ReRouted. 362 4.4.2. Link up event 364 Upon an adjacency/link up event, this document introduces the 365 following change in step 3 where the node SHOULD: 367 o Firstly build a LSP/LSA with the new adjacency but setting the 368 metric to MAX_METRIC . It SHOULD flood it but not compute the SPF 369 at this time. This step is required to ensure the two way 370 connectivity check on all nodes when computing SPF. 372 o Then build the LSP/LSA with the target metric but SHOULD delay the 373 flooding of this LSP/LSA by SPF_TIMER + ULOOP_DELAY_UP_TIMER. 374 MAX_METRIC is equal to MaxLinkMetric (0xFFFF) for OSPF and 2^24-2 375 (0xFFFFFE) for IS-IS. 377 o Then continue with next steps (SPF computation) without waiting 378 for the expiration of the above timer. In other word, only the 379 flooding of the LSA/LSP is delayed, not the local SPF computation. 381 As as result of this addition, routers local to the failure will 382 converge faster than remote routers. 384 If this mechanism is used in cooperation with "LDP IGP 385 Synchronization" as defined in [RFC5443] then the mechanism defined 386 in RFC 5443 is applied first, followed by the mechanism defined in 387 this document. More precisely, the procedure defined in this 388 document is applied once the LDP session is considered "fully 389 operational" as per [RFC5443]. 391 5. Applicability 393 As previously stated, the mechanism only avoids the forwarding loops 394 on the links between the node local to the failure and its neighbor. 395 Forwarding loops may still occur on other links. 397 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 forwarding 431 entry to K before D, a transient loop occurs between C and D. 433 By implementing the mechanism defined in this document on C, when the 434 link CF fails, C delays the update of his forwarding entry to K, 435 letting time for D to converge. When the timer expires on C, 436 forwarding entry to F is updated. There is no transient forwarding 437 loop between C and D. However, a transient forwarding loop may still 438 occur between D and A. In this scenario, this mechanism is not enough 439 to address all the possible forwarding loops. However, it does not 440 create additional traffic loss. Besides, in some cases -such as when 441 the nodes update their FIB in the following order C, A, D, for 442 example because the router A is quicker than D to converge- the 443 mechanism may still avoid the forwarding loop that was occuring. 445 6. Simulations 447 Simulations have been run on multiple service provider topologies. 448 So far, only link down event have been tested. 450 +----------+------+ 451 | Topology | Gain | 452 +----------+------+ 453 | T1 | 71% | 454 | T2 | 81% | 455 | T3 | 62% | 456 | T4 | 50% | 457 | T5 | 70% | 458 | T6 | 70% | 459 | T7 | 59% | 460 | T8 | 77% | 461 +----------+------+ 463 Table 1: Number of Repair/Dst that may loop 465 We evaluated the efficiency of the mechanism on eight different 466 service provider topologies (different network size, design). The 467 benefit is displayed in the table above. The benefit is evaluated as 468 follows: 470 o We consider a tuple (link A-B, destination D, PLR S, backup 471 nexthop N) as a loop if upon link A-B failure, the flow from a 472 router S upstream from A (A could be considered as PLR also) to D 473 may loop due to convergence time difference between S and one of 474 his neighbor N. 476 o We evaluate the number of potential loop tuples in normal 477 conditions. 479 o We evaluate the number of potential loop tuples using the same 480 topological input but taking into account that S converges after 481 N. 483 o Gain is how much loops (remote and local) we succeed to suppress. 485 On topology 1, 71% of the transient forwarding loops created by the 486 failure of any link are prevented by implementing the local delay. 487 The analysis shows that all local loops are obviously solved and only 488 remote loops are remaining. 490 7. Deployment considerations 492 Transient forwarding loops have the following drawbacks : 494 o Limit FRR efficiency : even if FRR is activated in 50msec, as soon 495 as PLR has converged, traffic may be affected by a transient loop. 497 o It may impact traffic not directly concerned by the failure (due 498 to link congestion). 500 This local delay proposal is a transient forwarding loop avoidance 501 mechanism (like OFIB). Even if it only address local transient 502 loops, , the efficiency versus complexity comparison of the mechanism 503 makes it a good solution. It is also incrementally deployable with 504 incremental benefits, which makes it an attractive option for both 505 vendors to implement and Service Providers to deploy. Delaying 506 convergence time is not an issue if we consider that the traffic is 507 protected during the convergence. 509 8. Comparison with other solutions 511 As stated in Section 3, our solution reuses some concepts already 512 introduced by other IETF proposals but tries to find a tradeoff 513 between efficiency and simplicity. This section tries to compare 514 behaviors of the solutions. 516 8.1. PLSN 518 PLSN ([I-D.ietf-rtgwg-microloop-analysis]) describes a mechanism 519 where each node in the network tries a avoid transient forwarding 520 loops upon a topology change by always keeping traffic on a loop-free 521 path for a defined duration (locked path to a safe neighbor). The 522 locked path may be the new primary nexthop, another neighbor, or the 523 old primary nexthop depending how the safety condition is satisified. 525 PLSN does not solve all transient forwarding loops (see 526 [I-D.ietf-rtgwg-microloop-analysis] Section 4 for more details). 528 Our solution reuse some concept of PLSN but in a more simple fashion 529 : 531 o PLSN has 3 different behavior : keep using old nexthop, use new 532 primary nexthop if safe, or use another safe nexthop, while our 533 solution only have one : keep using the current nexthop (old 534 primary, or already activated FRR path). 536 o PLSN may cause some damage while using a safe nexthop which is not 537 the new primary nexthop in case the new safe nexthop does not 538 enough provide enough bandwidth (see 539 [I-D.ietf-rtgwg-lfa-manageability]). Our solution may not 540 experience this issue as the service provider may have control on 541 the FRR path being used preventing network congestion. 543 o PLSN applies to all nodes in a network (remote or local changes), 544 while our mechanism applies only on the nodes connected to the 545 topology change. 547 8.2. OFIB 549 OFIB ([RFC6976]) describes a mechanism where convergence of the 550 network upon a topology change is made ordered to prevent transient 551 forwarding loops. Each router in the network must deduce the failure 552 type from the LSA/LSP received and compute/apply a specific FIB 553 update timer based on the failure type and its rank in the network 554 considering the failure point as root. 556 This mechanism permit to solve all the transient forwarding loop in a 557 network at the price of introducing complexity in the convergence 558 process that may require strong monitoring by the service provider. 560 Our solution reuses the OFIB concept but limits it to the first hop 561 that experience the topology change. As demonstrated, our proposal 562 permits to solve all the local transient forwarding loops that 563 represents a high percentage of all the loops. Moreover limiting the 564 mechanism to one hop permit to keep the network-wide convergence 565 behavior. 567 9. Security Considerations 569 This document does not introduce change in term of IGP security. The 570 operation is internal to the router. The local delay does not 571 increase the attack vector as an attacker could only trigger this 572 mechanism if he already has be ability to disable or enable an IGP 573 link. The local delay does not increase the negative consequences as 574 if an attacker has the ability to disable or enable an IGP link, it 575 can already harm the network by creating instability and harm the 576 traffic by creating forwarding packet loss and forwarding loss for 577 the traffic crossing that link. 579 10. Acknowledgements 581 We wish to thanks the authors of [RFC6976] for introducing the 582 concept of ordered convergence: Mike Shand, Stewart Bryant, Stefano 583 Previdi, and Olivier Bonaventure. 585 11. IANA Considerations 587 This document has no actions for IANA. 589 12. References 591 12.1. Normative References 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 597 Synchronization", RFC 5443, March 2009. 599 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 600 Convergence", RFC 5715, January 2010. 602 12.2. Informative References 604 [I-D.ietf-rtgwg-lfa-manageability] 605 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., 606 Horneffer, M., and p. psarkar@juniper.net, "Operational 607 management of Loop Free Alternates", 608 draft-ietf-rtgwg-lfa-manageability-03 (work in progress), 609 February 2014. 611 [I-D.ietf-rtgwg-microloop-analysis] 612 Zinin, A., "Analysis and Minimization of Microloops in 613 Link-state Routing Protocols", 614 draft-ietf-rtgwg-microloop-analysis-01 (work in progress), 615 October 2005. 617 [I-D.ietf-rtgwg-remote-lfa] 618 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 619 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-04 620 (work in progress), November 2013. 622 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 623 (TE) Extensions to OSPF Version 2", RFC 3630, 624 September 2003. 626 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 627 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 628 Alternate (LFA) Applicability in Service Provider (SP) 629 Networks", RFC 6571, June 2012. 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, July 2013. 636 Authors' Addresses 638 Stephane Litkowski 639 Orange 641 Email: stephane.litkowski@orange.com 643 Bruno Decraene 644 Orange 646 Email: bruno.decraene@orange.com 648 Clarence Filsfils 649 Cisco Systems 651 Email: cfilsfil@cisco.com 653 Pierre Francois 654 IMDEA Networks 656 Email: pierre.francois@imdea.org