idnits 2.17.1 draft-litkowski-rtgwg-uloop-delay-01.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 (August 19, 2013) is 3896 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 371, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-remote-lfa' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC6571' is defined on line 396, 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-02 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: February 20, 2014 P. Francois 6 IMDEA Networks/Cisco Systems 7 August 19, 2013 9 Microloop prevention by introducting a local convergence delay 10 draft-litkowski-rtgwg-uloop-delay-01 12 Abstract 14 This document describes a mechanism for link-state routing protocols 15 to prevent a subset of transient loops during topology changes. It 16 introduces a two-step convergence by introducing a delay between the 17 network wide convergence and the node advertising the failure. As 18 the network wide convergence is delayed in case of down events, this 19 mechanism can be used for planned maintenance or for unplanned outage 20 provided a fast reroute mechanism is used in conjunction to convert a 21 failure into a less urgent topology change. 23 Simulation using real network topologies and costs, with pathological 24 convergence behaviour, have been performed. While the proposed 25 mechanism does not provide a complete solution, it is simple and it 26 solves an interesting fraction of the transient loops in the analyzed 27 SP topologies. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on February 20, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Overview of the solution . . . . . . . . . . . . . . . . . . 3 70 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 72 3.2. Current IGP reactions . . . . . . . . . . . . . . . . . . 4 73 3.3. Local delay . . . . . . . . . . . . . . . . . . . . . . . 4 74 3.3.1. Link down event . . . . . . . . . . . . . . . . . . . 4 75 3.3.2. Link up event . . . . . . . . . . . . . . . . . . . . 5 76 4. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4.1. Applicable case . . . . . . . . . . . . . . . . . . . . . 5 78 4.2. Non applicable case . . . . . . . . . . . . . . . . . . . 6 79 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 80 5.1. Topological applicability . . . . . . . . . . . . . . . . 6 81 6. Deployment considerations . . . . . . . . . . . . . . . . . . 7 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 87 10.2. Informative References . . . . . . . . . . . . . . . . . 8 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 In figure 1, upon link AD down event, for the destination A, if D 93 updates its forwarding entry before C, a transient forwarding loop 94 occurs between C and D. We have a similar loop for link up event, if 95 C updates its forwarding entry A before D. 97 A ------ B 98 | | 99 | | 100 D--------C All the links have a metric of 1 except BC=5 102 Figure 1 104 2. Overview of the solution 106 This document defines a two-step convergence initiated by the router 107 detecting the failure and advertising the topological changes in the 108 IGP. This introduces a delay between the convergence of the local 109 router compared to the network wide convergence. This delay is 110 positive in case of "down" events and negative in case of "up" 111 events. 113 This ordered convergence, is similar to the ordered FIB proposed 114 defined in [I-D.ietf-rtgwg-ordered-fib], but limited to only one hop 115 distance. The proposed mechanism reuses also some concept described 116 in [I-D.ietf-rtgwg-microloop-analysis] with some limitation and 117 improvements. As a consequence, it can only eliminate the loops 118 between the node local to the event and its neighbors. In the SP 119 topologies that were analyzed, this can avoid a high number of 120 transient loops. On the other hand, as this mechanism is local to 121 the router, it can be deployed incrementally with incremental 122 benefit. 124 3. Specification 126 3.1. Definitions 128 This document will refer to the following existing IGP timers: 130 o LSP_GEN_TIMER: to batch multiple local events in one single local 131 LSP update. It is often associated with damping mechanism to 132 slowdown reactions by incrementing the timer when multiple 133 consecutive events are detected. 135 o SPF_TIMER: to batch multiple events in one single computation. It 136 is often associated with damping mechanism to slowdown reactions 137 by incrementing the timer when the IGP is instable. 139 o IGP_LDP_SYNC_TIMER: defined in [RFC5443] to give LDP some time to 140 establish the session and learn the MPLS labels before the link is 141 used. 143 This document introduces the following two new timers : 145 o ULOOP_DELAY_DOWN_TIMER: slowdown the network wide IGP convergence 146 in case of link down events. 148 o ULOOP_DELAY_UP_TIMER: slowdown the local node convergence in case 149 of link up events. 151 3.2. Current IGP reactions 153 Upon a change of status on an adjacency/link, the existing behavior 154 of the router advertising the event is the following: 156 1. UP/Down event is notified to IGP. 158 2. IGP processes the notification and postpones the reaction in 159 LSP_GEN_TIMER msec. 161 3. Upon LSP_GEN_TIMER expiration, IGP updates its LSP/LSA and floods 162 it. 164 4. SPF is scheduled in SPF_TIMER msec. 166 5. Upon SPF_TIMER expiration, SPF is computed and RIB/FIB are 167 updated. 169 3.3. Local delay 171 3.3.1. Link down event 173 Upon an adjacency/link down event, this document introduces a change 174 in step 5 in order to delay the local convergence compared to the 175 network wide convergence: the node SHOULD delay the forwarding entry 176 updates by ULOOP_DELAY_DOWN_TIMER. Such delay SHOULD only be 177 introduced if all the LSDB modifications processed are only reporting 178 down local events. Note that determining that all topological change 179 are only local down events requires analyzing all modified LSP/LSA as 180 a local link or node failure will typically be notified by multiple 181 nodes. If a subsequent LSP/LSA is received/updated and a new SPF 182 computation is triggered before the expiration of 183 ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. 185 As as result of this addition, routers local to the failure will 186 converge slower than remote routers. 188 3.3.2. Link up event 190 Upon an adjacency/link up event, this document introduces the 191 following change in step 3 where the node SHOULD: 193 o Firstly build a LSP/LSA with the new adjacency but setting the 194 metric to MAX_METRIC. It SHOULD flood it but not compute the SPF 195 at this time. 197 o Then build the LSP/LSA with the target metric but SHOULD delay the 198 flooding of this LSP/LSA by SPF_TIMER + ULOOP_DELAY_UP_TIMER. 199 MAX_METRIC is equal to MaxLinkMetric (0xFFFF) for OSPF and 2^24-2 200 (0xFFFFFE) for IS-IS. 202 o Then continue with next steps (SPF computation) without waiting 203 for the expiration of the above timer. In other word, only the 204 flooding of the LSA/LSP is delayed, not the local SPF computation. 206 As as result of this addition, routers local to the failure will 207 converge faster than remote routers. 209 If this mechanism is used in cooperation with "LDP IGP 210 Synchronization" as defined in [RFC5443] then the mechanism defined 211 in RFC 5443 is applied first, followed by the mechanism defined in 212 this document. More precisely, the procedure defined in this 213 document is applied once the LDP session is considered "fully 214 operational" as per [RFC5443]. 216 4. Use case 218 As previously stated, the mechanism only avoids the forwarding loops 219 on the links between the node local to the failure and its neighbor. 220 Forwarding loops may still occur on other links. 222 4.1. Applicable case 224 A ------ B ----- E 225 | / | 226 | / | 227 G---D------------C F All the links have a metric of 1 229 Figure 2 231 Let us consider the traffic from G to F. The primary path is 232 G->D->C->E->F. When link CE fails, if C updates its forwarding entry 233 for F before D, a transient loop occures. 235 By implementing the mechanism defined in this document on C, when the 236 CE link fails, C delays the update of his forwarding entry to F, in 237 order to let some time for D to converge. When the timer expires on 238 C, forwarding entry to F is updated. There is no transient 239 forwarding loop on the link CD. 241 Note that C should implement a protection mechanism during the 242 convergence delay in order to not increase the loss of traffic. 244 4.2. Non applicable case 246 A ------ B ----- E --- H 247 | | 248 | | 249 G---D--------C ------F --- J ---- K 251 All the links have a metric of 1 except BE=15 253 Figure 3 255 Let us consider the traffic from G to K. The primary path is 256 G->D->C->F->J->K. When the CF link fails, if C updates its forwarding 257 entry to K before D, a transient loop occures between C and D. 259 By implementing the mechanism defined in this document on C, when the 260 link CF fails, C delays the update of his forwarding entry to K, 261 letting time for D to converge. When the timer expires on C, 262 forwarding entry to F is updated. There is no transient forwarding 263 loop between C and D. However, a transient forwarding loop may still 264 occur between D and A. In this scenario, this mechanism is not enough 265 to address all the possible forwarding loops. However, it does not 266 create additional traffic loss. Besides, in some cases -such as when 267 the nodes update their FIB in the following order C, A, D, for 268 example because the router A is quicker than D to converge- the 269 mechanism may still avoid the forwarding loop that was occuring. 271 5. Applicability 273 Simulations have been run on multiple service provider topologies. 274 So far, only link down event have been tested. 276 5.1. Topological applicability 278 +----------+------+ 279 | Topology | Gain | 280 +----------+------+ 281 | T1 | 71% | 282 | T2 | 81% | 283 | T3 | 62% | 284 | T4 | 50% | 285 | T5 | 70% | 286 | T6 | 70% | 287 | T7 | 59% | 288 | T8 | 77% | 289 +----------+------+ 291 Table 1: Number of Repair/Dst that may loop 293 We evaluated the efficiency of the mechanism on eight different 294 service provider topologies (different network size, design). The 295 benefit is displayed in the table above. The benefit is evaluated as 296 follows: 298 o We consider a tuple (link A-B, destination D, PLR S, backup 299 nexthop N) as a loop if upon link A-B failure, the flow from a 300 router S upstream from A (A could be considered as PLR also) to D 301 may loop due to convergence time difference between S and one of 302 his neighbor N. 304 o We evaluate the number of potential loop tuples in normal 305 conditions. 307 o We evaluate the number of potential loop tuples using the same 308 topological input but taking into account that S converges after 309 N. 311 o Gain is how much loops we succeed to suppress. 313 6. Deployment considerations 315 Transient forwarding loops have the following drawbacks : 317 o Limit FRR efficiency : even if FRR is activated in 50msec, as soon 318 as PLR has converged, traffic may be affected by a transient loop. 320 o It may impact traffic not directly concerned by the failure (due 321 to link congestion). 323 Our local delay proposal is a transient forwarding loop avoidance 324 mechanism (like OFIB). Even if it does not prevent all transient 325 loops to happen, the efficiency versus complexity comparison of the 326 mechanism makes it a good solution. 328 Delaying convergence time is not an issue if we consider that the 329 traffic is protected during the convergence. It would be up to the 330 service provider to implement the local delay only for protected 331 destinations or for all destinations. Considering that a service 332 provider may implement the local delay for non protected 333 destinations, it must be aware that delaying convergence will 334 increase the loss duration on the affected link but at the same time, 335 will prevent some other link to be congestioned. As a best practice, 336 we recommend to activate the local delay only for protected 337 destinations. 339 7. Security Considerations 341 This document does not introduce change in term of IGP security. The 342 operation is internal to the router. The local delay does not 343 increase the attack vector as an attacker could only trigger this 344 mechanism if he already has be ability to disable or enable an IGP 345 link. The local delay does not increase the negative consequences as 346 if an attacker has the ability to disable or enable an IGP link, it 347 can already harm the network by creating instability and harm the 348 traffic by creating forwarding packet loss and forwarding loss for 349 the traffic crossing that link. 351 8. Acknowledgements 353 We wish to thanks the authors of [I-D.ietf-rtgwg-ordered-fib] for 354 introducing the concept of ordered convergence: Mike Shand, Stewart 355 Bryant, Stefano Previdi, Clarence Filsfils, and Olivier Bonaventure. 357 9. IANA Considerations 359 This document has no actions for IANA. 361 10. References 363 10.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 369 Synchronization", RFC 5443, March 2009. 371 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 372 Convergence", RFC 5715, January 2010. 374 10.2. Informative References 376 [I-D.ietf-rtgwg-microloop-analysis] 377 Zinin, A., "Analysis and Minimization of Microloops in 378 Link-state Routing Protocols", draft-ietf-rtgwg-microloop- 379 analysis-01 (work in progress), October 2005. 381 [I-D.ietf-rtgwg-ordered-fib] 382 Shand, M., Bryant, S., Previdi, S., Filsfils, C., 383 Francois, P., and O. Bonaventure, "Framework for Loop-free 384 convergence using oFIB", draft-ietf-rtgwg-ordered-fib-12 385 (work in progress), May 2013. 387 [I-D.ietf-rtgwg-remote-lfa] 388 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 389 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02 390 (work in progress), May 2013. 392 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 393 (TE) Extensions to OSPF Version 2", RFC 3630, September 394 2003. 396 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 397 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 398 Alternate (LFA) Applicability in Service Provider (SP) 399 Networks", RFC 6571, June 2012. 401 Authors' Addresses 403 Stephane Litkowski 404 Orange 406 Email: stephane.litkowski@orange.com 408 Bruno Decraene 409 Orange 411 Email: bruno.decraene@orange.com 413 Pierre Francois 414 IMDEA Networks/Cisco Systems 416 Email: pierre.francois@imdea.org