idnits 2.17.1 draft-litkowski-rtgwg-uloop-delay-02.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 3714 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: 'RFC5715' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-remote-lfa' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 421, but no explicit reference was found in the text == Unused Reference: 'RFC6571' is defined on line 425, 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-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 P. Francois 6 IMDEA Networks 7 C. Filsfils 8 Cisco Systems 9 February 14, 2014 11 Microloop prevention by introducing a local convergence delay 12 draft-litkowski-rtgwg-uloop-delay-02 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. Overview of the solution . . . . . . . . . . . . . . . . . . . 4 72 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 74 3.2. Current IGP reactions . . . . . . . . . . . . . . . . . . 5 75 3.3. Local events . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.4. Local delay . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.4.1. Link down event . . . . . . . . . . . . . . . . . . . 6 78 3.4.2. Link up event . . . . . . . . . . . . . . . . . . . . 6 79 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.1. Applicable case : local loops . . . . . . . . . . . . . . 7 81 4.2. Non applicable case : remote loops . . . . . . . . . . . . 7 82 5. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 6. Deployment considerations . . . . . . . . . . . . . . . . . . 9 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 In figure 1, upon link AD down event, for the destination A, if D 95 updates its forwarding entry before C, a transient forwarding loop 96 occurs between C and D. We have a similar loop for link up event, if 97 C updates its forwarding entry A before D. 99 A ------ B 100 | | 101 | | 102 D--------C All the links have a metric of 1 except BC=5 104 Figure 1 106 2. Overview of the solution 108 This document defines a two-step convergence initiated by the router 109 detecting the failure and advertising the topological changes in the 110 IGP. This introduces a delay between the convergence of the local 111 router and the network wide convergence. This delay is positive in 112 case of "down" events and negative in case of "up" events. 114 This ordered convergence, is similar to the ordered FIB proposed 115 defined in [I-D.ietf-rtgwg-ordered-fib], but limited to only one hop 116 distance. As a consequence, it is simpler and becomes a local only 117 feature not requiring interoperability; at the cost of only covering 118 the transient forwarding loops involving this local router. The 119 proposed mechanism also reuses some concept described in 120 [I-D.ietf-rtgwg-microloop-analysis] with some limitation and 121 improvements. 123 3. Specification 125 3.1. Definitions 127 This document will refer to the following existing IGP timers: 129 o LSP_GEN_TIMER: to batch multiple local events in one single local 130 LSP update. It is often associated with damping mechanism to 131 slowdown reactions by incrementing the timer when multiple 132 consecutive events are detected. 134 o SPF_TIMER: to batch multiple events in one single computation. It 135 is often associated with damping mechanism to slowdown reactions 136 by incrementing the timer when the IGP is instable. 138 o IGP_LDP_SYNC_TIMER: defined in [RFC5443] to give LDP some time to 139 establish the session and learn the MPLS labels before the link is 140 used. 142 This document introduces the following two new timers : 144 o ULOOP_DELAY_DOWN_TIMER: slowdown the network wide IGP convergence 145 in case of link down events. 147 o ULOOP_DELAY_UP_TIMER: slowdown the local node convergence in case 148 of link up events. 150 3.2. Current IGP reactions 152 Upon a change of status on an adjacency/link, the existing behavior 153 of the router advertising the event is the following: 155 1. UP/Down event is notified to IGP. 157 2. IGP processes the notification and postpones the reaction in 158 LSP_GEN_TIMER msec. 160 3. Upon LSP_GEN_TIMER expiration, IGP updates its LSP/LSA and floods 161 it. 163 4. SPF is scheduled in SPF_TIMER msec. 165 5. Upon SPF_TIMER expiration, SPF is computed and RIB/FIB are 166 updated. 168 3.3. Local events 170 In the next sections, we will use the concept of local events versus 171 remote events. The notion of event we are using in this document is 172 linked to IGP link state advertisements and not network events, as a 173 single network event would create multiple IGP link state 174 advertisement within the network. 176 A local event is a set of IGP link state advertisements describing 177 only a change of a local component of the computing router (e.g. a 178 link). As opposite to a remote event being a set of IGP link state 179 advertisements describing any other type of changes. 181 Example : 183 +--- E ----+--------+ 184 | | | 185 A ---- B -------- C ------ D 186 Considering computing router is B, when B-C fails. B updates its 187 local LSP describing the link B->C being down, C does exactly the 188 same and starts flooding. During SPF_TIMER, B and C LSPs would be 189 taken into account. B and C LSPs are describing exactly the same 190 event (B-C link down). For B point of view, both LSPs must be 191 considered as a local event as they are describing the change of a 192 local component of B (link B-C). If C node is failing, routers B,E 193 and D are updating and flooding their LSPs. LSPs from E and D are 194 considered as remote events for B as they are describing a change in 195 a component that does not belong to B. Hence the local delay 196 mechanism will be aborted. Hence this mechanism is not applicable to 197 node failure. 199 3.4. Local delay 201 3.4.1. Link down event 203 Upon an adjacency/link down event, this document introduces a change 204 in step 5 in order to delay the local convergence compared to the 205 network wide convergence: the node SHOULD delay the forwarding entry 206 updates by ULOOP_DELAY_DOWN_TIMER. Such delay SHOULD only be 207 introduced if all the LSDB modifications processed are only reporting 208 down local events . Note that determining that all topological 209 change are only local down events requires analyzing all modified 210 LSP/LSA as a local link or node failure will typically be notified by 211 multiple nodes. If a subsequent LSP/LSA is received/updated and a 212 new SPF computation is triggered before the expiration of 213 ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. 215 As a result of this addition, routers local to the failure will 216 converge slower than remote routers. Hence it SHOULD only be done 217 for non urgent convergence, such as for administrative de-activation 218 (maintenance) or when the traffic is Fast ReRouted. 220 3.4.2. Link up event 222 Upon an adjacency/link up event, this document introduces the 223 following change in step 3 where the node SHOULD: 225 o Firstly build a LSP/LSA with the new adjacency but setting the 226 metric to MAX_METRIC . It SHOULD flood it but not compute the SPF 227 at this time. This step is required to ensure the two way 228 connectivity check on all nodes when computing SPF. 230 o Then build the LSP/LSA with the target metric but SHOULD delay the 231 flooding of this LSP/LSA by SPF_TIMER + ULOOP_DELAY_UP_TIMER. 232 MAX_METRIC is equal to MaxLinkMetric (0xFFFF) for OSPF and 2^24-2 233 (0xFFFFFE) for IS-IS. 235 o Then continue with next steps (SPF computation) without waiting 236 for the expiration of the above timer. In other word, only the 237 flooding of the LSA/LSP is delayed, not the local SPF computation. 239 As as result of this addition, routers local to the failure will 240 converge faster than remote routers. 242 If this mechanism is used in cooperation with "LDP IGP 243 Synchronization" as defined in [RFC5443] then the mechanism defined 244 in RFC 5443 is applied first, followed by the mechanism defined in 245 this document. More precisely, the procedure defined in this 246 document is applied once the LDP session is considered "fully 247 operational" as per [RFC5443]. 249 4. Applicability 251 As previously stated, the mechanism only avoids the forwarding loops 252 on the links between the node local to the failure and its neighbor. 253 Forwarding loops may still occur on other links. 255 4.1. Applicable case : local loops 257 A ------ B ----- E 258 | / | 259 | / | 260 G---D------------C F All the links have a metric of 1 262 Figure 2 264 Let us consider the traffic from G to F. The primary path is 265 G->D->C->E->F. When link CE fails, if C updates its forwarding entry 266 for F before D, a transient loop occurs. This is sub-optimal as C 267 has FRR enabled and it breaks the FRR forwarding while all upstream 268 routers are still forwarding the traffic to itself. 270 By implementing the mechanism defined in this document on C, when the 271 CE link fails, C delays the update of his forwarding entry to F, in 272 order to let some time for D to converge. FRR keeps protecting the 273 traffic during this period. When the timer expires on C, forwarding 274 entry to F is updated. There is no transient forwarding loop on the 275 link CD. 277 4.2. Non applicable case : remote loops 278 A ------ B ----- E --- H 279 | | 280 | | 281 G---D--------C ------F --- J ---- K 283 All the links have a metric of 1 except BE=15 285 Figure 3 287 Let us consider the traffic from G to K. The primary path is 288 G->D->C->F->J->K. When the CF link fails, if C updates its forwarding 289 entry to K before D, a transient loop occurs between C and D. 291 By implementing the mechanism defined in this document on C, when the 292 link CF fails, C delays the update of his forwarding entry to K, 293 letting time for D to converge. When the timer expires on C, 294 forwarding entry to F is updated. There is no transient forwarding 295 loop between C and D. However, a transient forwarding loop may still 296 occur between D and A. In this scenario, this mechanism is not enough 297 to address all the possible forwarding loops. However, it does not 298 create additional traffic loss. Besides, in some cases -such as when 299 the nodes update their FIB in the following order C, A, D, for 300 example because the router A is quicker than D to converge- the 301 mechanism may still avoid the forwarding loop that was occuring. 303 5. Simulations 305 Simulations have been run on multiple service provider topologies. 306 So far, only link down event have been tested. 308 +----------+------+ 309 | Topology | Gain | 310 +----------+------+ 311 | T1 | 71% | 312 | T2 | 81% | 313 | T3 | 62% | 314 | T4 | 50% | 315 | T5 | 70% | 316 | T6 | 70% | 317 | T7 | 59% | 318 | T8 | 77% | 319 +----------+------+ 321 Table 1: Number of Repair/Dst that may loop 323 We evaluated the efficiency of the mechanism on eight different 324 service provider topologies (different network size, design). The 325 benefit is displayed in the table above. The benefit is evaluated as 326 follows: 328 o We consider a tuple (link A-B, destination D, PLR S, backup 329 nexthop N) as a loop if upon link A-B failure, the flow from a 330 router S upstream from A (A could be considered as PLR also) to D 331 may loop due to convergence time difference between S and one of 332 his neighbor N. 334 o We evaluate the number of potential loop tuples in normal 335 conditions. 337 o We evaluate the number of potential loop tuples using the same 338 topological input but taking into account that S converges after 339 N. 341 o Gain is how much loops (remote and local) we succeed to suppress. 343 On topology 1, 71% of the transient forwarding loops created by the 344 failure of any link are prevented by implementing the local delay. 345 The analysis shows that all local loops are obviously solved and only 346 remote loops are remaining. 348 6. Deployment considerations 350 Transient forwarding loops have the following drawbacks : 352 o Limit FRR efficiency : even if FRR is activated in 50msec, as soon 353 as PLR has converged, traffic may be affected by a transient loop. 355 o It may impact traffic not directly concerned by the failure (due 356 to link congestion). 358 This local delay proposal is a transient forwarding loop avoidance 359 mechanism (like OFIB). Even if it only address local transient 360 loops, , the efficiency versus complexity comparison of the mechanism 361 makes it a good solution. It is also incrementally deployable with 362 incremental benefits, which makes it an attractive option for both 363 vendors to implement and Service Providers to deploy. Delaying 364 convergence time is not an issue if we consider that the traffic is 365 protected during the convergence. 367 7. Security Considerations 369 This document does not introduce change in term of IGP security. The 370 operation is internal to the router. The local delay does not 371 increase the attack vector as an attacker could only trigger this 372 mechanism if he already has be ability to disable or enable an IGP 373 link. The local delay does not increase the negative consequences as 374 if an attacker has the ability to disable or enable an IGP link, it 375 can already harm the network by creating instability and harm the 376 traffic by creating forwarding packet loss and forwarding loss for 377 the traffic crossing that link. 379 8. Acknowledgements 381 We wish to thanks the authors of [I-D.ietf-rtgwg-ordered-fib] for 382 introducing the concept of ordered convergence: Mike Shand, Stewart 383 Bryant, Stefano Previdi, and Olivier Bonaventure. 385 9. IANA Considerations 387 This document has no actions for IANA. 389 10. References 391 10.1. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 397 Synchronization", RFC 5443, March 2009. 399 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 400 Convergence", RFC 5715, January 2010. 402 10.2. Informative References 404 [I-D.ietf-rtgwg-microloop-analysis] 405 Zinin, A., "Analysis and Minimization of Microloops in 406 Link-state Routing Protocols", 407 draft-ietf-rtgwg-microloop-analysis-01 (work in progress), 408 October 2005. 410 [I-D.ietf-rtgwg-ordered-fib] 411 Shand, M., Bryant, S., Previdi, S., Filsfils, C., 412 Francois, P., and O. Bonaventure, "Framework for Loop-free 413 convergence using oFIB", draft-ietf-rtgwg-ordered-fib-12 414 (work in progress), May 2013. 416 [I-D.ietf-rtgwg-remote-lfa] 417 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 418 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-04 419 (work in progress), November 2013. 421 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 422 (TE) Extensions to OSPF Version 2", RFC 3630, 423 September 2003. 425 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 426 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 427 Alternate (LFA) Applicability in Service Provider (SP) 428 Networks", RFC 6571, June 2012. 430 Authors' Addresses 432 Stephane Litkowski 433 Orange 435 Email: stephane.litkowski@orange.com 437 Bruno Decraene 438 Orange 440 Email: bruno.decraene@orange.com 442 Pierre Francois 443 IMDEA Networks 445 Email: pierre.francois@imdea.org 447 Clarence Fils Fils 448 Cisco Systems 450 Email: cf@cisco.com