idnits 2.17.1 draft-ietf-spring-resiliency-use-cases-11.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 (May 23, 2017) is 2529 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: November 24, 2017 B. Decraene 6 Orange 7 R. Shakir 8 Google 9 May 23, 2017 11 Resiliency use cases in SPRING networks 12 draft-ietf-spring-resiliency-use-cases-11 14 Abstract 16 This document identifies and describes the requirements for a set of 17 use cases related to network resiliency on Segment Routing (SPRING) 18 networks. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 24, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Path Protection . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Management-free Local Protection . . . . . . . . . . . . . . 5 63 3.1. Management-free Bypass Protection . . . . . . . . . . . . 6 64 3.2. Management-free Shortest Path Based Protection . . . . . 6 65 4. Managed Local Protection . . . . . . . . . . . . . . . . . . 7 66 4.1. Managed Bypass Protection . . . . . . . . . . . . . . . . 7 67 4.2. Managed Shortest Path Protection . . . . . . . . . . . . 8 68 5. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Co-existence of multiple resilience techniques in the same 70 infrastructure . . . . . . . . . . . . . . . . . . . . . . . 9 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 9. Manageability Considerations . . . . . . . . . . . . . . . . 10 74 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 12.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 This document reviews various use cases for the protection of 84 services in a SPRING network. The terminology used hereafter is in 85 line with [RFC5286] and [RFC5714]. 87 This document reviews various use cases for the protection of 88 services in a SPRING network. 90 The resiliency use cases described in this document can be applied 91 not only to traffic that is forwarded according to the SPRING 92 architecture but also to traffic that originally is forwarded using 93 other paradigms such as LDP signalling or pure IP traffic (IP routed 94 traffic). 96 Three key alternatives are described: path protection, local 97 protection without operator management and local protection with 98 operator management. 100 Path protection lets the ingress node be in charge of the failure 101 recovery, as discussed in Section 2. 103 The rest of the document focuses on approaches where protection is 104 performed by the node adjacent to the failed component, commonly 105 referred to as local protection techniques or Fast Reroute techniques 106 ([RFC5286], [RFC5714]). 108 In Section 3 we discuss two different approaches providing unmanaged 109 local protection, namely link/node bypass protection and shortest 110 path based protection. 112 Section 4 illustrates a case allowing the operator to manage the 113 local protection behavior in order to accommodate specific policies. 115 In Section 5 we discuss the opportunity for the SPRING architecture 116 to provide loop-avoidance mechanisms, such that transient forwarding 117 state inconsistencies during routing convergence do not lead into 118 traffic loss. 120 The purpose of this document is to illustrate the different use cases 121 and explain how an operator could combine them in the same network 122 (see Section 6). Solutions are not defined in this document. 124 B------C------D------E 125 /| | \ / | \ / |\ 126 / | | \/ | \/ | \ 127 A | | /\ | /\ | Z 128 \ | | / \ | / \ | / 129 \| |/ \|/ \|/ 130 F------G------H------I 132 Figure 1: Reference topology 134 We use Figure 1 as a reference topology throughout the document. 135 Following link metrics are applied: 137 Link metrics are bidirectional. In other words, the same metric 138 value is configured at both side of each link. 140 Links from/to A and Z are configured with a metric of 100. 142 CH, GD, DI and HE links are configured with a metric of 6. 144 All other links are configured with a metric of 5. 146 2. Path Protection 148 As a reminder, one of the majors network operator requirements is 149 path disjointness capability. Network operators have deployed 150 infrastructures with topologies that allow paths to be computed in a 151 complete disjoint fashion where two paths wouldn't share any 152 component (link or router) hence allowing an optimal protection 153 strategy. 155 A first protection strategy consists in excluding any local repair 156 but instead use end-to-end path protection where each SPRING path is 157 protected by a second disjoint SPRING path. In this case local 158 protection MUST NOT be used. 160 For example, a Pseudo Wire (PW) from A to Z can be "path protected" 161 in the direction A to Z in the following manner: the operator 162 configures two SPRING paths T1 (primary) and T2 (backup) from A to Z. 164 The two paths may be used: 166 o concurrently, where the ingress router sends the same traffic over 167 the primary and secondary path. This is usually known as 1+1 168 protection. 170 o concurrently, where the ingress router splits the traffic over the 171 primary and secondary path. This is usually known as equal cost 172 multi path (ECMP) or unequal cost multi path (UCMP). 174 o as a primary and backup path, where the secondary path is used 175 only when the primary failed. This is usually known as 1:1 176 protection. 178 T1 is established over path {AB, BC, CD, DE, EZ} as the primary path 179 and T2 is established over path {AF, FG, GH, HI, IZ} as the backup 180 path. As a requirement, the two paths MUST be disjoint in their 181 links, nodes or shared risk link groups (SRLGs). 183 In the case of primary/backup paths, when the primary path T1 is up, 184 the packets of the PW are sent on T1. When T1 fails, the packets of 185 the PW are sent on backup path T2. When T1 comes back up, the 186 operator either allows for an automated reversion of the traffic onto 187 T1 or selects an operator-driven reversion. Typically, the 188 switchover from path T1 to path T2 is done in a fast reroute fashion 189 (e.g.: sub-50 milliseconds range) but depending on the service that 190 needs to be delivered, other restoration times may be used. 192 It is essential that the primary and backup path benefit from an end- 193 to-end liveness monitoring/verification. The method and mechanisms 194 that provide such liveness check are outside the scope of this 195 document. An example is given by [RFC5880]. 197 There are multiple options for liveness check, e.g., path liveness 198 where the path is monitored at the network level (either by the head- 199 end node or by a network controller/monitoring system). Another 200 possible approach consists of a service-based path monitored by the 201 service instance (verifying reachability of the endpoint). All these 202 options are given here as examples. While this document does express 203 the requirement for a liveness mechanism, it does not mandate, nor 204 define, any specific one. 206 From a SPRING viewpoint, we would like to highlight the following 207 requirements: 209 o SPRING architecture MUST provide a way to compute paths that MUST 210 NOT be protected by local repair techniques (as illustrated in the 211 example of paths T1 and T2). 213 o SPRING architecture MUST provide a way to instantiate pairs of 214 disjoint paths on a topology based on a protection strategy (link, 215 node or SRLG protection) and allow the validation or re- 216 computation of these paths upon network events. 218 o The SPRING architecture MUST provide end-to-end liveness check of 219 SPRING based paths. 221 3. Management-free Local Protection 223 This section describes two alternatives providing local protection 224 without requiring operator management, namely bypass protection and 225 shortest-path based protection. 227 For example, a demand from A to Z, transported over the shortest 228 paths provided by the SPRING architecture, benefits from management- 229 free local protection by having each node along the path 230 automatically pre-compute and pre-install a backup path for the 231 destination Z. Upon local detection of the failure, the traffic is 232 repaired over the backup path in sub-50 milliseconds. When primary 233 path comes back up, the operator either allows for an automated 234 reversion of the traffic onto it or selects an operator-driven 235 reversion. 237 The backup path computation SHOULD support the following 238 requirements: 240 o 100% link, node, and SRLG protection in any topology. 242 o Automated computation by the IGP. 244 o Selection of the backup path such as to minimize the chance for 245 transient congestion and/or delay during the protection period, as 246 reflected by the IGP metric configuration in the network. 248 3.1. Management-free Bypass Protection 250 One way to provide local repair is to enforce a fail-over along the 251 shortest path around the failed component. 253 In case of link protection, the point of local repair will create a 254 repair path avoiding the protected link and merging back to primary 255 path at the nexthop. 257 In case of node protection, the repair path will avoid the protected 258 node and merge back to primary path at the next-nexthop. 260 In case of SRLG protection, the repair path will avoid members of the 261 same group and merge back to primary path just after. 263 In our example, C protects destination Z against a failure of CD link 264 by enforcing the traffic over the bypass {CH, HD}. The resulting end- 265 to-end path between A and Z, upon recovery against the failure of CD, 266 is depicted in Figure 2. 268 B * * *C------D * * *E 269 *| | * / * \ / |* 270 * | | */ * \/ | * 271 A | | /* * /\ | Z 272 \ | | / * * / \ | / 273 \| |/ **/ \|/ 274 F------G------H------I 276 Figure 2: Bypass protection around link CD 278 When the primary path comes back up, the operator either allows for 279 an automated reversion of the traffic onto the primary path or 280 selects an operator-driven reversion. 282 3.2. Management-free Shortest Path Based Protection 284 An alternative protection strategy consists in management-free local 285 protection, aiming at providing a repair for the destination based on 286 the shortest path to the destination. 288 In our example, C protects Z, that it initially reaches via CD, by 289 enforcing the traffic over its shortest path to Z, considering the 290 failure of the protected component. The resulting end-to-end path 291 between A and Z, upon recovery against the failure of CD, is depicted 292 in Figure 3. 294 B * * *C------D------E 295 *| | * / | \ / |\ 296 * | | */ | \/ | \ 297 A | | /* | /\ | Z 298 \ | | / * | / \ | * 299 \| |/ *|/ \|* 300 F------G------H * * *I 302 Figure 3: Shortest path protection around link CD 304 When the primary path comes back up, the operator either allows for 305 an automated reversion of the traffic onto the primary path or 306 selects an operator-driven reversion. 308 4. Managed Local Protection 310 There may be cases where a management free repair does not fit the 311 policy of the operator. For example, in our illustration, the 312 operator may not want to have CD and CH used to protect each other 313 due the BW availability in each link and that could not suffice to 314 absorb the other link traffic. 316 In this context, the protection mechanism MUST support the explicit 317 configuration of the backup path either under the form of high-level 318 constraints (end at the next-hop, end at the next-next-hop, minimize 319 this metric, avoid this SRLG...) or under the form of an explicit 320 path. Upon local detection of the failure, the traffic is repaired 321 over the backup path in sub-50 milliseconds. When primary path comes 322 back up, the operator either allows for an automated reversion of the 323 traffic onto it or selects an operator-driven reversion. 325 We discuss such aspects for both bypass and shortest path based 326 protection schemes. 328 4.1. Managed Bypass Protection 330 Let us illustrate the case using our reference example. For the 331 demand from A to Z, the operator does not want to use the shortest 332 failover path to the nexthop, {CH, HD}, but rather the path {CG, GH, 333 HD}, as illustrated in Figure 4. 335 B * * *C------D * * *E 336 *| * \ / * \ / |* 337 * | * \/ * \/ | * 338 A | * /\ * /\ | Z 339 \ | * / \ * / \ | / 340 \| */ \*/ \|/ 341 F------G * * *H------I 343 Figure 4: Managed Bypass Protection 345 The computation of the repair path SHOULD be possible in an automated 346 fashion as well as statically expressed in the point of local repair. 348 4.2. Managed Shortest Path Protection 350 In the case of shortest path protection, the operator does not want 351 to use the shortest failover via link CH, but rather reach H via {CG, 352 GH}, for example, due to delay, BW, SRLG or other constraint. 354 The resulting end-to-end path upon activation of the protection is 355 illustrated in Figure 5. 357 B * * *C------D------E 358 *| * \ / | \ / |\ 359 * | * \/ | \/ | \ 360 A | * /\ | /\ | Z 361 \ | * / \ | / \ | * 362 \| */ \|/ \|* 363 F------G * * *H * * *I 365 Figure 5: Managed Shortest Path Protection 367 The computation of the repair path SHOULD be possible in an automated 368 fashion as well as statically expressed in the point of local repair. 370 The computation of the repair path based on a specific constraint 371 SHOULD be possible on a per-destination prefix base. 373 5. Loop Avoidance 375 It is part of routing protocols behavior to have what are called 376 "transient routing inconsistencies". This is due to the routing 377 convergence that happens in each node at different times and during a 378 different lapse of time. 380 These inconsistencies may cause routing loops that last the time that 381 it takes for the node impacted by a network event to converge. These 382 loops are called "microloops". 384 Usually, in a normal routing protocol operations, microloops do not 385 last long enough and in general they are noticed during the time it 386 takes for the network to converge. However, with the emerging of 387 fast-convergence and fast-reroute technologies, microloops may be an 388 issue in networks where sub-50 millisecond convergence/reroute is 389 required. Therefore, the microloop problem needs to be addressed. 391 Networks may be affected by microloops during convergence depending 392 of their topologies. Detecting microloops can be done during 393 topology computation (e.g.: SPF computation) and therefore 394 microloops-avoidance techniques may be applied. An example of such 395 technique is to compute microloop-free path that would be used during 396 network convergence. 398 The SPRING architecture SHOULD provide solutions to prevent the 399 occurrence of microloops during convergence following a change in the 400 network state. Traditionally, the lack of packet steering capability 401 made difficult to apply efficient solutions to microloops. A SPRING 402 enabled router could take advantage of the increased packet steering 403 capabilities offered by SPRING in order to steer packets in a way 404 that packets do not enter such loops. 406 6. Co-existence of multiple resilience techniques in the same 407 infrastructure 409 The operator may want to support several very different services on 410 the same packet-switching infrastructure. As a result, the SPRING 411 architecture SHOULD allow for the co-existence of the different use 412 cases listed in this document, in the same network. 414 Let us illustrate this with the following example: 416 o Flow F1 is supported over path {C, CD, E} 418 o Flow F2 is supported over path {C, CD, I} 420 o Flow F3 is supported over path {C, CD, Z} 422 o Flow F4 is supported over path {C, CD, Z} 424 It should be possible for the operator to configure the network to 425 achieve path protection for F1, management free shortest path local 426 protection for F2, managed protection over path {CG, GH, Z} for F3, 427 and management free bypass protection for F4. 429 7. Security Considerations 431 This document describes requirements for the SPRING architecture to 432 provide resiliency in SPRING networks. As such it does not introduce 433 any new security considerations beyond that is discussed in 434 [RFC7855]. 436 8. IANA Considerations 438 This document does not request any IANA allocations. 440 9. Manageability Considerations 442 This document provides use cases. Solutions aimed at supporting 443 these use cases should provide the necessary mechanisms in order to 444 allow for manageability as described in [RFC7855]. 446 Manageability concerns the computation, installation and 447 troubleshooting of the repair path. Also, necessary mechanisms 448 SHOULD be provided in order for the operator to control when a repair 449 path is computed, how it has been computed and if it's installed and 450 used. 452 10. Contributors 454 Pierre Francois contributed to the writing of the first version of 455 this document. 457 11. Acknowledgements 459 Authors would like to thank Stephane Litkowski and Alexander 460 Vainshtein for the comments and review of this document. 462 12. References 464 12.1. Normative References 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, 468 DOI 10.17487/RFC2119, March 1997, 469 . 471 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 472 Litkowski, S., Horneffer, M., and R. Shakir, "Source 473 Packet Routing in Networking (SPRING) Problem Statement 474 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 475 2016, . 477 12.2. Informative References 479 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 480 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 481 DOI 10.17487/RFC5286, September 2008, 482 . 484 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 485 RFC 5714, DOI 10.17487/RFC5714, January 2010, 486 . 488 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 489 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 490 . 492 Authors' Addresses 494 Clarence Filsfils (editor) 495 Cisco Systems, Inc. 496 Brussels 497 BE 499 Email: cfilsfil@cisco.com 501 Stefano Previdi (editor) 502 Cisco Systems, Inc. 503 Via Del Serafico, 200 504 Rome 00142 505 Italy 507 Email: stefano@previdi.net 509 Bruno Decraene 510 Orange 511 FR 513 Email: bruno.decraene@orange.com 515 Rob Shakir 516 Google, Inc. 517 1600 Amphitheatre Parkway 518 Mountain View, CA 94043 520 Email: robjs@google.com