idnits 2.17.1 draft-ietf-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 (April 6, 2017) is 2575 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 992, but no explicit reference was found in the text == Unused Reference: 'RFC6571' is defined on line 997, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 1009, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5715 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-backoff-algo-04 Summary: 1 error (**), 0 flaws (~~), 5 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: October 8, 2017 C. Filsfils 6 P. Francois 7 Cisco Systems 8 April 6, 2017 10 Micro-loop prevention by introducing a local convergence delay 11 draft-ietf-rtgwg-uloop-delay-04 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 time and the IGP convergence. 25 The proposed mechanism will be limited to the link down event in 26 order to keep simplicity. 28 Simulations using real network topologies have been performed and 29 show that local loops are a significant portion (>50%) of the total 30 forwarding loops. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on October 8, 2017. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Transient forwarding loops side effects . . . . . . . . . . . 3 74 2.1. Fast reroute inefficiency . . . . . . . . . . . . . . . . 4 75 2.2. Network congestion . . . . . . . . . . . . . . . . . . . 6 76 3. Overview of the solution . . . . . . . . . . . . . . . . . . 7 77 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 79 4.2. Current IGP reactions . . . . . . . . . . . . . . . . . . 8 80 4.3. Local events . . . . . . . . . . . . . . . . . . . . . . 8 81 4.4. Local delay for link down . . . . . . . . . . . . . . . . 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. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 8.1. Local link down . . . . . . . . . . . . . . . . . . . . . 12 89 8.2. Local and remote event . . . . . . . . . . . . . . . . . 15 90 8.3. Aborting local delay . . . . . . . . . . . . . . . . . . 17 91 9. Comparison with other solutions . . . . . . . . . . . . . . . 19 92 9.1. PLSN . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 9.2. OFIB . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 10. Existing implementations . . . . . . . . . . . . . . . . . . 20 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 96 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 97 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 100 14.2. Informative References . . . . . . . . . . . . . . . . . 21 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 Micro-forwarding loops and some potential solutions are well 106 described in [RFC5715]. This document describes a simple targeted 107 mechanism that solves micro-loops that are local to the failure; 108 based on network analysis, these are a significant portion of the 109 micro-forwarding loops. A simple and easily deployable solution for 110 these local micro-loops is critical because these local loops cause 111 some traffic loss after a fast-reroute alternate has been used (see 112 Section 2.1). 114 Consider the case in Figure 1 where S does not have an LFA to protect 115 its traffic to D. That means that all non-D neighbors of S on the 116 topology will send to S any traffic destined to D if a neighbor did 117 not, then that neighbor would be loop-free. Regardless of the 118 advanced fast-reroute (FRR) technique used, when S converges to the 119 new topology, it will send its traffic to a neighbor that was not 120 loop-free and thus cause a local micro-loop. The deployment of 121 advanced fast-reroute techniques motivates this simple router-local 122 mechanism to solve this targeted problem. This solution can be work 123 with the various techniques described in [RFC5715]. 125 1 126 D ------ C 127 | | 128 1 | | 5 129 | | 130 S ------ B 131 1 132 Figure 1 134 When S-D fails, a transient forwarding loop may appear between S and 135 B if S updates its forwarding entry to D before B. 137 2. Transient forwarding loops side effects 139 Even if they are very limited in duration, transient forwarding loops 140 may cause high damages for a network. 142 2.1. Fast reroute inefficiency 144 D 145 1 | 146 | 1 147 A ------ B 148 | | ^ 149 10 | | 5 | T 150 | | | 151 E--------C 152 | 1 153 1 | 154 S 156 Figure 2 - RSVP-TE FRR case 158 In the Figure 2, an RSVP-TE tunnel T, provisioned on C and 159 terminating on B, is used to protect against C-B link failure (IGP 160 shortcut is activated on C). The primary path of T is C->B and FRR 161 is activated on T providing an FRR bypass or detour using path 162 C->E->A->B. On the router C, the nexthop to D is the tunnel T thanks 163 to the IGP shortcut. When C-B link fails: 165 1. C detects the failure, and updates the tunnel path using 166 preprogrammed FRR path, the traffic path from S to D becomes: 167 S->E->C->E->A->B->A->D. 169 2. In parallel, on router C, both the IGP convergence and the TE 170 tunnel convergence (tunnel path recomputation) are occurring: 172 * The Tunnel T path is recomputed and now uses C->E->A->B. 174 * The IGP path to D is recomputed and now uses C->E->A->D. 176 3. On C, the tail-end of the TE tunnel (router B) is no more on the 177 shortest-path tree (SPT) to D, so C does not encapsulate anymore 178 the traffic to D using the tunnel T and updates its forwarding 179 entry to D using the nexthop E. 181 If C updates its forwarding entry to D before router E, there would 182 be a transient forwarding loop between C and E until E has converged. 184 +-----------+------------+------------------+-----------------------+ 185 | Network | Time | Router C events | Router E events | 186 | condition | | | | 187 +-----------+------------+------------------+-----------------------+ 188 | S->D | | | | 189 | Traffic | | | | 190 | OK | | | | 191 | | | | | 192 | S->D | t0 | Link B-C fails | Link B-C fails | 193 | Traffic | | | | 194 | lost | | | | 195 | | | | | 196 | | t0+20msec | C detects the | | 197 | | | failure | | 198 | | | | | 199 | S->D | t0+40msec | C activates FRR | | 200 | Traffic | | | | 201 | OK | | | | 202 | | | | | 203 | | t0+50msec | C updates its | | 204 | | | local LSP/LSA | | 205 | | | | | 206 | | t0+60msec | C schedules SPF | | 207 | | | (100ms) | | 208 | | | | | 209 | | t0+70msec | C floods its | | 210 | | | local updated | | 211 | | | LSP/LSA | | 212 | | | | | 213 | | t0+87msec | | E receives LSP/LSA | 214 | | | | from C and schedules | 215 | | | | SPF (100ms) | 216 | | | | | 217 | | t0+117msec | | E floods LSP/LSA from | 218 | | | | C | 219 | | | | | 220 | | t0+160msec | C computes SPF | | 221 | | | | | 222 | | t0+165msec | C starts | | 223 | | | updating its | | 224 | | | RIB/FIB | | 225 | | | | | 226 | | t0+193msec | | E computes SPF | 227 | | | | | 228 | | t0+199msec | | E starts updating its | 229 | | | | RIB/FIB | 230 | | | | | 231 | S->D | t0+255msec | C updates its | | 232 | Traffic | | RIB/FIB for D | | 233 | lost | | | | 234 | | | | | 235 | | t0+340msec | C convergence | | 236 | | | ends | | 237 | | | | | 238 | S->D | t0+443msec | | E updates its RIB/FIB | 239 | Traffic | | | for D | 240 | OK | | | | 241 | | | | | 242 | | t0+470msec | | E convergence ends | 243 +-----------+------------+------------------+-----------------------+ 245 Route computation event time scale 247 The issue described here is completely independent of the fast- 248 reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...). The 249 protection enabled by fast-reroute is working perfectly, but ensures 250 a protection, by definition, only until the PLR has converged. When 251 implementing FRR, a service provider wants to guarantee a very 252 limited loss of connectivity time. The previous example shows that 253 the benefit of FRR may be completely lost due to a transient 254 forwarding loop appearing when PLR has converged. Delaying FIB 255 updates after the IGP convergence may allow to keep the fast-reroute 256 path until the neighbors have converged and preserves the customer 257 traffic. 259 2.2. Network congestion 261 1 262 D ------ C 263 | | 264 1 | | 5 265 | | 266 A -- S ------ B 267 / | 1 268 F E 270 In the figure above, as presented in Section 1, when the link S-D 271 fails, a transient forwarding loop may appear between S and B for 272 destination D. The traffic on the S-B link will constantly increase 273 due to the looping traffic to D. Depending on the TTL of the 274 packets, the traffic rate destinated to D and the bandwidth of the 275 link, the S-B link may be congested in few hundreds of milliseconds 276 and will stay overloaded until the loop is solved. 278 The congestion introduced by transient forwarding loops is 279 problematic as it is impacting traffic that is not directly concerned 280 by the failing network component. In our example, the congestion of 281 the S-B link will impact some customer traffic that is not directly 282 concerned by the failure: e.g. A to B, F to B, E to B. Some class 283 of services may be implemented to mitigate the congestion, but some 284 traffic not directly concerned by the failure would still be dropped 285 as a router is not able to identify the looping traffic from the 286 normally forwarded traffic. 288 3. Overview of the solution 290 This document defines a two-step convergence initiated by the router 291 detecting the failure and advertising the topological changes in the 292 IGP. This introduces a delay between the convergence of the local 293 router and the network wide convergence. 295 The proposed solution is kept limited to local link down events for 296 simplicity reason. 298 This ordered convergence, is similar to the ordered FIB proposed 299 defined in [RFC6976], but limited to only a "one hop" distance. As a 300 consequence, it is simpler and becomes a local only feature not 301 requiring interoperability; at the cost of only covering the 302 transient forwarding loops involving this local router. The proposed 303 mechanism also reuses some concept described in 304 [I-D.ietf-rtgwg-microloop-analysis] with some limitations. 306 4. Specification 308 4.1. Definitions 310 This document will refer to the following existing IGP timers: 312 o LSP_GEN_TIMER: The delay used to batch multiple local events in 313 one single local LSP/LSA update. It is often associated with a 314 damping mechanism to slow down reactions by incrementing the timer 315 when multiple consecutive events are detected. 317 o SPF_DELAY: The delay between the first IGP event triggering a new 318 routing table computation and the start of that routing table 319 computation. It is often associated with a damping mechanism to 320 slow down reactions by incrementing the timer when the IGP becomes 321 unstable. As an example, [I-D.ietf-rtgwg-backoff-algo] defines a 322 standard SPF delay algorithm. 324 This document introduces the following new timer: 326 o ULOOP_DELAY_DOWN_TIMER: used to slow down the local node 327 convergence in case of link down events. 329 4.2. Current IGP reactions 331 Upon a change of the status of an adjacency/link, the existing 332 behavior of the router advertising the event is the following: 334 1. The Up/Down event is notified to the IGP. 336 2. The IGP processes the notification and postpones the reaction in 337 LSP_GEN_TIMER msec. 339 3. Upon LSP_GEN_TIMER expiration, the IGP updates its LSP/LSA and 340 floods it. 342 4. The SPF computation is scheduled in SPF_DELAY msec. 344 5. Upon SPF_DELAY expiration, the SPF is computed, then the RIB and 345 FIB are updated. 347 4.3. Local events 349 The mechanism described in this document assumes that there has been 350 a single link failure as seen by the IGP area/level. If this 351 assumption is violated (e.g. multiple links or nodes failed), then 352 standard IP convergence MUST be applied (as described in 353 Section 4.2). 355 To determine if the mechanism can be applicable or not, an 356 implementation SHOULD implement a logic to correlate the protocol 357 messages (LSP/LSA) received during the SPF scheduling period in order 358 to determine the topology changes that occured. This is necessary as 359 multiple protocol messages may describe the same topology change and 360 a single protocol message may describe multiple topology changes. As 361 a consequence, determining a particular topology change MUST be 362 independent of the order of reception of those protocol messages. 363 How the logic works is let to implementation details. 365 Using this logic, if an implementation determines that the associated 366 topology change is a single local link failure, then the router MAY 367 use the mechanism described in this document, otherwise the standard 368 IP convergence MUST be used. 370 Example: 372 +--- E ----+--------+ 373 | | | 374 A ---- B -------- C ------ D 375 Let router B be the computing router when the link B-C fails. B 376 updates its local LSP/LSA describing the link B->C as down, C does 377 the same, and both start flooding their updated LSP/LSAs. During the 378 SPF_DELAY period, B and C learn all the LSPs/LSAs to consider. B 379 sees that C is flooding as down a link where B is the other end and 380 that B and C are describing the same single event. Since B receives 381 no other changes, B can determine that this is a local link failure 382 and may decide to activate the mechanism described in this document. 384 4.4. Local delay for link down 386 Upon an adjacency/link down event, this document introduces a change 387 in step 5 (Section 4.2) in order to delay the local convergence 388 compared to the network wide convergence: the node SHOULD delay the 389 forwarding entry updates by ULOOP_DELAY_DOWN_TIMER. Such delay 390 SHOULD only be introduced if all the LSDB modifications processed are 391 only reporting a single local link down event (Section 4.3). If a 392 subsequent LSP/LSA is received/updated and a new SPF computation is 393 triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the 394 same evaluation SHOULD be performed. 396 As a result of this addition, routers local to the failure will 397 converge slower than remote routers. Hence it SHOULD only be done 398 for a non-urgent convergence, such as for administrative de- 399 activation (maintenance) or when the traffic is protected by fast- 400 reroute. 402 5. Applicability 404 As previously stated, the mechanism only avoids the forwarding loops 405 on the links between the node local to the failure and its neighbor. 406 Forwarding loops may still occur on other links. 408 5.1. Applicable case: local loops 410 A ------ B ----- E 411 | / | 412 | / | 413 G---D------------C F All the links have a metric of 1 415 Figure 2 417 Let us consider the traffic from G to F. The primary path is 418 G->D->C->E->F. When link C-E fails, if C updates its forwarding 419 entry for F before D, a transient loop occurs. This is sub-optimal 420 as C has FRR enabled and it breaks the FRR forwarding while all 421 upstream routers are still forwarding the traffic to itself. 423 By implementing the mechanism defined in this document on C, when the 424 C-E link fails, C delays the update of its forwarding entry to F, in 425 order to let some time for D to converge. FRR keeps protecting the 426 traffic during this period. When the timer expires on C, its 427 forwarding entry to F is updated. There is no transient forwarding 428 loop on the link C-D. 430 5.2. Non applicable case: remote loops 432 A ------ B ----- E --- H 433 | | 434 | | 435 G---D--------C ------F --- J ---- K 437 All the links have a metric of 1 except BE=15 439 Figure 3 441 Let us consider the traffic from G to K. The primary path is 442 G->D->C->F->J->K. When the C-F link fails, if C updates its 443 forwarding entry to K before D, a transient loop occurs between C and 444 D. 446 By implementing the mechanism defined in this document on C, when the 447 link C-F fails, C delays the update of its forwarding entry to K, 448 letting time for D to converge. When the timer expires on C, its 449 forwarding entry to F is updated. There is no transient forwarding 450 loop between C and D. However, a transient forwarding loop may still 451 occur between D and A. In this scenario, this mechanism is not 452 enough to address all the possible forwarding loops. However, it 453 does not create additional traffic loss. Besides, in some cases 454 -such as when the nodes update their FIB in the following order C, A, 455 D, for example because the router A is quicker than D to converge- 456 the mechanism may still avoid the forwarding loop that was occurring. 458 6. Simulations 460 Simulations have been run on multiple service provider topologies. 462 +----------+------+ 463 | Topology | Gain | 464 +----------+------+ 465 | T1 | 71% | 466 | T2 | 81% | 467 | T3 | 62% | 468 | T4 | 50% | 469 | T5 | 70% | 470 | T6 | 70% | 471 | T7 | 59% | 472 | T8 | 77% | 473 +----------+------+ 475 Table 1: Number of Repair/Dst that may loop 477 We evaluated the efficiency of the mechanism on eight different 478 service provider topologies (different network size, design). The 479 benefit is displayed in the table above. The benefit is evaluated as 480 follows: 482 o We consider a tuple (link A-B, destination D, PLR S, backup 483 nexthop N) as a loop if upon link A-B failure, the flow from a 484 router S upstream from A (A could be considered as PLR also) to D 485 may loop due to convergence time difference between S and one of 486 his neighbor N. 488 o We evaluate the number of potential loop tuples in normal 489 conditions. 491 o We evaluate the number of potential loop tuples using the same 492 topological input but taking into account that S converges after 493 N. 495 o The gain is how much loops (remote and local) we succeed to 496 suppress. 498 On topology 1, 71% of the transient forwarding loops created by the 499 failure of any link are prevented by implementing the local delay. 500 The analysis shows that all local loops are obviously solved and only 501 remote loops are remaining. 503 7. Deployment considerations 505 Transient forwarding loops have the following drawbacks: 507 o They limit FRR efficiency: even if FRR is activated in 50msec, as 508 soon as PLR has converged, the traffic may be affected by a 509 transient loop. 511 o They may impact traffic not directly concerned by the failure (due 512 to link congestion). 514 This local delay proposal is a transient forwarding loop avoidance 515 mechanism (like OFIB). Even if it only addresses local transient 516 loops, the efficiency versus complexity comparison of the mechanism 517 makes it a good solution. It is also incrementally deployable with 518 incremental benefits, which makes it an attractive option for both 519 vendors to implement and Service Providers to deploy. Delaying the 520 convergence time is not an issue if we consider that the traffic is 521 protected during the convergence. 523 8. Examples 525 We will consider the following figure for the associated examples : 527 D 528 1 | F----X 529 | 1 | 530 A ------ B 531 | | ^ 532 10 | | 5 | T 533 | | | 534 E--------C 535 | 1 536 1 | 537 S 539 The network above is considered to have a convergence time about 1 540 second, so ULOOP_DELAY_DOWN_TIMER will be adjusted to this value. We 541 also consider that FRR is running on each node. 543 8.1. Local link down 545 The table below describes the events and associating timing that 546 happens on router C and E when link B-C goes down. As C detects a 547 single local event corresponding to a link down (its LSP + LSP from B 548 received), it decides to apply the local delay down behavior and no 549 microloop is formed. 551 +-----------+-------------+------------------+----------------------+ 552 | Network | Time | Router C events | Router E events | 553 | condition | | | | 554 +-----------+-------------+------------------+----------------------+ 555 | S->D | | | | 556 | Traffic | | | | 557 | OK | | | | 558 | | | | | 559 | S->D | t0 | Link B-C fails | Link B-C fails | 560 | Traffic | | | | 561 | lost | | | | 562 | | | | | 563 | | t0+20msec | C detects the | | 564 | | | failure | | 565 | | | | | 566 | S->D | t0+40msec | C activates FRR | | 567 | Traffic | | | | 568 | OK | | | | 569 | | | | | 570 | | t0+50msec | C updates its | | 571 | | | local LSP/LSA | | 572 | | | | | 573 | | t0+60msec | C schedules SPF | | 574 | | | (100ms) | | 575 | | | | | 576 | | t0+67msec | C receives | | 577 | | | LSP/LSA from B | | 578 | | | | | 579 | | t0+70msec | C floods its | | 580 | | | local updated | | 581 | | | LSP/LSA | | 582 | | | | | 583 | | t0+87msec | | E receives LSP/LSA | 584 | | | | from C and schedules | 585 | | | | SPF (100ms) | 586 | | | | | 587 | | t0+117msec | | E floods LSP/LSA | 588 | | | | from C | 589 | | | | | 590 | | t0+160msec | C computes SPF | | 591 | | | | | 592 | | t0+165msec | C delays its | | 593 | | | RIB/FIB update | | 594 | | | (1 sec) | | 595 | | | | | 596 | | t0+193msec | | E computes SPF | 597 | | | | | 598 | | t0+199msec | | E starts updating | 599 | | | | its RIB/FIB | 600 | | | | | 601 | | t0+443msec | | E updates its | 602 | | | | RIB/FIB for D | 603 | | | | | 604 | | t0+470msec | | E convergence ends | 605 | | | | | 606 | | t0+1165msec | C starts | | 607 | | | updating its | | 608 | | | RIB/FIB | | 609 | | | | | 610 | | t0+1255msec | C updates its | | 611 | | | RIB/FIB for D | | 612 | | | | | 613 | | t0+1340msec | C convergence | | 614 | | | ends | | 615 +-----------+-------------+------------------+----------------------+ 617 Route computation event time scale 619 Similarly, upon B-C link down event, if LSP/LSA from B is received 620 before C detects the link failure, C will apply the route update 621 delay if the local detection is part of the same SPF run. 623 +-----------+-------------+------------------+----------------------+ 624 | Network | Time | Router C events | Router E events | 625 | condition | | | | 626 +-----------+-------------+------------------+----------------------+ 627 | S->D | | | | 628 | Traffic | | | | 629 | OK | | | | 630 | | | | | 631 | S->D | t0 | Link B-C fails | Link B-C fails | 632 | Traffic | | | | 633 | lost | | | | 634 | | | | | 635 | | t0+32msec | C receives | | 636 | | | LSP/LSA from B | | 637 | | | | | 638 | | t0+33msec | C schedules SPF | | 639 | | | (100ms) | | 640 | | | | | 641 | | t0+50msec | C detects the | | 642 | | | failure | | 643 | | | | | 644 | S->D | t0+55msec | C activates FRR | | 645 | Traffic | | | | 646 | OK | | | | 647 | | | | | 648 | | t0+55msec | C updates its | | 649 | | | local LSP/LSA | | 650 | | | | | 651 | | t0+70msec | C floods its | | 652 | | | local updated | | 653 | | | LSP/LSA | | 654 | | | | | 655 | | t0+87msec | | E receives LSP/LSA | 656 | | | | from C and schedules | 657 | | | | SPF (100ms) | 658 | | | | | 659 | | t0+117msec | | E floods LSP/LSA | 660 | | | | from C | 661 | | | | | 662 | | t0+160msec | C computes SPF | | 663 | | | | | 664 | | t0+165msec | C delays its | | 665 | | | RIB/FIB update | | 666 | | | (1 sec) | | 667 | | | | | 668 | | t0+193msec | | E computes SPF | 669 | | | | | 670 | | t0+199msec | | E starts updating | 671 | | | | its RIB/FIB | 672 | | | | | 673 | | t0+443msec | | E updates its | 674 | | | | RIB/FIB for D | 675 | | | | | 676 | | t0+470msec | | E convergence ends | 677 | | | | | 678 | | t0+1165msec | C starts | | 679 | | | updating its | | 680 | | | RIB/FIB | | 681 | | | | | 682 | | t0+1255msec | C updates its | | 683 | | | RIB/FIB for D | | 684 | | | | | 685 | | t0+1340msec | C convergence | | 686 | | | ends | | 687 +-----------+-------------+------------------+----------------------+ 689 Route computation event time scale 691 8.2. Local and remote event 693 The table below describes the events and associating timing that 694 happens on router C and E when link B-C goes down, in addition F-X 695 link will fail in the same time window. C will not apply the local 696 delay because a non local topology change is also received. 698 +-----------+------------+-----------------+------------------------+ 699 | Network | Time | Router C events | Router E events | 700 | condition | | | | 701 +-----------+------------+-----------------+------------------------+ 702 | S->D | | | | 703 | Traffic | | | | 704 | OK | | | | 705 | | | | | 706 | S->D | t0 | Link B-C fails | Link B-C fails | 707 | Traffic | | | | 708 | lost | | | | 709 | | | | | 710 | | t0+20msec | C detects the | | 711 | | | failure | | 712 | | | | | 713 | | t0+36msec | Link F-X fails | Link F-X fails | 714 | | | | | 715 | S->D | t0+40msec | C activates FRR | | 716 | Traffic | | | | 717 | OK | | | | 718 | | | | | 719 | | t0+50msec | C updates its | | 720 | | | local LSP/LSA | | 721 | | | | | 722 | | t0+54msec | C receives | | 723 | | | LSP/LSA from F | | 724 | | | and floods it | | 725 | | | | | 726 | | t0+60msec | C schedules SPF | | 727 | | | (100ms) | | 728 | | | | | 729 | | t0+67msec | C receives | | 730 | | | LSP/LSA from B | | 731 | | | | | 732 | | t0+69msec | | E receives LSP/LSA | 733 | | | | from F, floods it and | 734 | | | | schedules SPF (100ms) | 735 | | | | | 736 | | t0+70msec | C floods its | | 737 | | | local updated | | 738 | | | LSP/LSA | | 739 | | | | | 740 | | t0+87msec | | E receives LSP/LSA | 741 | | | | from C | 742 | | | | | 743 | | t0+117msec | | E floods LSP/LSA from | 744 | | | | C | 745 | | | | | 746 | | t0+160msec | C computes SPF | | 747 | | | | | 748 | | t0+165msec | C starts | | 749 | | | updating its | | 750 | | | RIB/FIB (NO | | 751 | | | DELAY) | | 752 | | | | | 753 | | t0+170msec | | E computes SPF | 754 | | | | | 755 | | t0+173msec | | E starts updating its | 756 | | | | RIB/FIB | 757 | | | | | 758 | S->D | t0+365msec | C updates its | | 759 | Traffic | | RIB/FIB for D | | 760 | lost | | | | 761 | | | | | 762 | S->D | t0+443msec | | E updates its RIB/FIB | 763 | Traffic | | | for D | 764 | OK | | | | 765 | | | | | 766 | | t0+450msec | C convergence | | 767 | | | ends | | 768 | | | | | 769 | | t0+470msec | | E convergence ends | 770 | | | | | 771 +-----------+------------+-----------------+------------------------+ 773 Route computation event time scale 775 8.3. Aborting local delay 777 The table below describes the events and associating timing that 778 happens on router C and E when link B-C goes down, in addition F-X 779 link will fail during local delay run. C will first apply local 780 delay, but when the new event happens, it will fall back to the 781 standard convergence mechanism without delaying route insertion 782 anymore. In this example, we consider a ULOOP_DELAY_DOWN_TIMER 783 configured to 2 seconds. 785 +-----------+------------+-------------------+----------------------+ 786 | Network | Time | Router C events | Router E events | 787 | condition | | | | 788 +-----------+------------+-------------------+----------------------+ 789 | S->D | | | | 790 | Traffic | | | | 791 | OK | | | | 792 | | | | | 793 | S->D | t0 | Link B-C fails | Link B-C fails | 794 | Traffic | | | | 795 | lost | | | | 796 | | | | | 797 | | t0+20msec | C detects the | | 798 | | | failure | | 799 | | | | | 800 | S->D | t0+40msec | C activates FRR | | 801 | Traffic | | | | 802 | OK | | | | 803 | | | | | 804 | | t0+50msec | C updates its | | 805 | | | local LSP/LSA | | 806 | | | | | 807 | | t0+60msec | C schedules SPF | | 808 | | | (100ms) | | 809 | | | | | 810 | | t0+67msec | C receives | | 811 | | | LSP/LSA from B | | 812 | | | | | 813 | | t0+70msec | C floods its | | 814 | | | local updated | | 815 | | | LSP/LSA | | 816 | | | | | 817 | | t0+87msec | | E receives LSP/LSA | 818 | | | | from C and schedules | 819 | | | | SPF (100ms) | 820 | | | | | 821 | | t0+117msec | | E floods LSP/LSA | 822 | | | | from C | 823 | | | | | 824 | | t0+160msec | C computes SPF | | 825 | | | | | 826 | | t0+165msec | C delays its | | 827 | | | RIB/FIB update (2 | | 828 | | | sec) | | 829 | | | | | 830 | | t0+193msec | | E computes SPF | 831 | | | | | 832 | | t0+199msec | | E starts updating | 833 | | | | its RIB/FIB | 834 | | | | | 835 | | t0+254msec | Link F-X fails | Link F-X fails | 836 | | | | | 837 | | t0+300msec | C receives | | 838 | | | LSP/LSA from F | | 839 | | | and floods it | | 840 | | | | | 841 | | t0+303msec | C schedules SPF | | 842 | | | (200ms) | | 843 | | | | | 844 | | t0+312msec | E receives | | 845 | | | LSP/LSA from F | | 846 | | | and floods it | | 847 | | | | | 848 | | t0+313msec | E schedules SPF | | 849 | | | (200ms) | | 850 | | | | | 851 | | t0+502msec | C computes SPF | | 852 | | | | | 853 | | t0+505msec | C starts updating | | 854 | | | its RIB/FIB (NO | | 855 | | | DELAY) | | 856 | | | | | 857 | | t0+514msec | | E computes SPF | 858 | | | | | 859 | | t0+519msec | | E starts updating | 860 | | | | its RIB/FIB | 861 | | | | | 862 | S->D | t0+659msec | C updates its | | 863 | Traffic | | RIB/FIB for D | | 864 | lost | | | | 865 | | | | | 866 | S->D | t0+778msec | | E updates its | 867 | Traffic | | | RIB/FIB for D | 868 | OK | | | | 869 | | | | | 870 | | t0+781msec | C convergence | | 871 | | | ends | | 872 | | | | | 873 | | t0+810msec | | E convergence ends | 874 +-----------+------------+-------------------+----------------------+ 876 Route computation event time scale 878 9. Comparison with other solutions 880 As stated in Section 3, our solution reuses some concepts already 881 introduced by other IETF proposals but tries to find a tradeoff 882 between efficiency and simplicity. This section tries to compare 883 behaviors of the solutions. 885 9.1. PLSN 887 PLSN ([I-D.ietf-rtgwg-microloop-analysis]) describes a mechanism 888 where each node in the network tries to avoid transient forwarding 889 loops upon a topology change by always keeping traffic on a loop-free 890 path for a defined duration (locked path to a safe neighbor). The 891 locked path may be the new primary nexthop, another neighbor, or the 892 old primary nexthop depending how the safety condition is satisfied. 894 PLSN does not solve all transient forwarding loops (see 895 [I-D.ietf-rtgwg-microloop-analysis] Section 4 for more details). 897 Our solution reuses some concept of PLSN but in a more simple 898 fashion: 900 o PLSN has three different behaviors: keep using old nexthop, use 901 new primary nexthop if it is safe, or use another safe nexthop, 902 while our solution only have one: keep using the current nexthop 903 (old primary, or already activated FRR path). 905 o PLSN may cause some damage while using a safe nexthop which is not 906 the new primary nexthop in case the new safe nexthop does not 907 enough provide enough bandwidth (see [RFC7916]). Our solution may 908 not experience this issue as the service provider may have control 909 on the FRR path being used preventing network congestion. 911 o PLSN applies to all nodes in a network (remote or local changes), 912 while our mechanism applies only on the nodes connected to the 913 topology change. 915 9.2. OFIB 917 OFIB ([RFC6976]) describes a mechanism where the convergence of the 918 network upon a topology change is made ordered to prevent transient 919 forwarding loops. Each router in the network must deduce the failure 920 type from the LSA/LSP received and computes/applies a specific FIB 921 update timer based on the failure type and its rank in the network 922 considering the failure point as root. 924 This mechanism allows to solve all the transient forwarding loop in a 925 network at the price of introducing complexity in the convergence 926 process that may require a strong monitoring by the service provider. 928 Our solution reuses the OFIB concept but limits it to the first hop 929 that experiences the topology change. As demonstrated, our proposal 930 allows to solve all the local transient forwarding loops that 931 represents an high percentage of all the loops. Moreover limiting 932 the mechanism to one hop allows to keep the network-wide convergence 933 behavior. 935 10. Existing implementations 937 At this time, there are three different implementations of this 938 mechanism: CISCO IOS-XR, CISCO IOS-XE and Juniper JUNOS. The three 939 implementations have been tested in labs and demonstrated a good 940 behavior in term of local micro-loop avoidance. The feature has also 941 been deployed in some live networks. No side effects have been 942 found. 944 11. Security Considerations 946 This document does not introduce any change in term of IGP security. 947 The operation is internal to the router. The local delay does not 948 increase the attack vector as an attacker could only trigger this 949 mechanism if he already has be ability to disable or enable an IGP 950 link. The local delay does not increase the negative consequences as 951 if an attacker has the ability to disable or enable an IGP link, it 952 can already harm the network by creating instability and harm the 953 traffic by creating forwarding packet loss and forwarding loss for 954 the traffic crossing that link. 956 12. Acknowledgements 958 We would like to thanks the authors of [RFC6976] for introducing the 959 concept of ordered convergence: Mike Shand, Stewart Bryant, Stefano 960 Previdi, and Olivier Bonaventure. 962 13. IANA Considerations 964 This document has no actions for IANA. 966 14. References 968 14.1. Normative References 970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 971 Requirement Levels", BCP 14, RFC 2119, 972 DOI 10.17487/RFC2119, March 1997, 973 . 975 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 976 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 977 2010, . 979 14.2. Informative References 981 [I-D.ietf-rtgwg-backoff-algo] 982 Decraene, B., Litkowski, S., Gredler, H., Lindem, A., 983 Francois, P., and C. Bowers, "SPF Back-off algorithm for 984 link state IGPs", draft-ietf-rtgwg-backoff-algo-04 (work 985 in progress), January 2017. 987 [I-D.ietf-rtgwg-microloop-analysis] 988 Zinin, A., "Analysis and Minimization of Microloops in 989 Link-state Routing Protocols", draft-ietf-rtgwg-microloop- 990 analysis-01 (work in progress), October 2005. 992 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 993 (TE) Extensions to OSPF Version 2", RFC 3630, 994 DOI 10.17487/RFC3630, September 2003, 995 . 997 [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, 998 B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 999 Alternate (LFA) Applicability in Service Provider (SP) 1000 Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, 1001 . 1003 [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., 1004 Francois, P., and O. Bonaventure, "Framework for Loop-Free 1005 Convergence Using the Ordered Forwarding Information Base 1006 (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 1007 2013, . 1009 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1010 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 1011 RFC 7490, DOI 10.17487/RFC7490, April 2015, 1012 . 1014 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 1015 Horneffer, M., and P. Sarkar, "Operational Management of 1016 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 1017 July 2016, . 1019 Authors' Addresses 1021 Stephane Litkowski 1022 Orange 1024 Email: stephane.litkowski@orange.com 1026 Bruno Decraene 1027 Orange 1029 Email: bruno.decraene@orange.com 1030 Clarence Filsfils 1031 Cisco Systems 1033 Email: cfilsfil@cisco.com 1035 Pierre Francois 1036 Cisco Systems 1038 Email: pifranco@cisco.com