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