idnits 2.17.1 draft-ietf-spring-resiliency-use-cases-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 138: '... paths T1 and T2 MUST NOT benefit from...' RFC 2119 keyword, line 269: '...ING architecture SHOULD provide soluti...' RFC 2119 keyword, line 279: '... architecture SHOULD allow for the c...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 6, 2016) is 2936 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 ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pierre Francois 3 Internet-Draft Clarence Filsfils 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: October 8, 2016 Bruno Decraene 6 Orange 7 Rob Shakir 8 Jive Communications, Inc. 9 April 6, 2016 11 Use-cases for Resiliency in SPRING 12 draft-ietf-spring-resiliency-use-cases-03 14 Abstract 16 This document describes the use cases for resiliency in SPRING 17 networks. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 8, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Path protection . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Management free local protection . . . . . . . . . . . . . . . 4 56 3.1. Management free bypass protection . . . . . . . . . . . . . 5 57 3.2. Management-free shortest path based protection . . . . . . 5 58 4. Managed local protection . . . . . . . . . . . . . . . . . . . 6 59 4.1. Managed bypass protection . . . . . . . . . . . . . . . . . 6 60 4.2. Managed shortest path protection . . . . . . . . . . . . . 6 61 5. Loop avoidance . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Co-existence . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 SPRING aims at providing a network architecture supporting services 69 with tight SLA guarantees [1]. This document reviews various use 70 cases for the protection of services in a SPRING network. Note that 71 these use cases are in particular applicable to existing LDP based 72 and pure IP networks. 74 Three key alternatives are described: path protection, local 75 protection without operator management and local protection with 76 operator management. 78 Path protection lets the ingress node be in charge of the failure 79 recovery, as discussed in Section 2. 81 The rest of the document focuses on approaches where protection is 82 performed by the node adjacent to the failed component, commonly 83 referred to as local protection techniques or Fast Reroute 84 techniques. 86 We discuss two different approaches to provide unmanaged local 87 protection, namely link/node bypass protection and shortest path 88 based protection, in Section 3. 90 In Section 5, we discuss the opportunity for the SPRING architecture 91 to provide loop-avoidance mechanisms, such that transient forwarding 92 state inconsistencies during routing convergence does not lead to 93 traffic loss. 95 A case is then made to allow the operator to manage the local 96 protection behavior in order to accommodate specific policies, in 97 Section 4. 99 The purpose of this document is to illustrate the different 100 approaches and explain how an operator could combine them in the same 101 network (see Section 6). Solutions are not defined in this document. 103 B------C------D------E 104 /| | \ / | \ / |\ 105 / | | \/ | \/ | \ 106 A | | /\ | /\ | Z 107 \ | | / \ | / \ | / 108 \| |/ \|/ \|/ 109 F------G------H------I 111 Figure 1: Reference topology 113 We use Figure 1 as a reference topology throughout the document. All 114 link metrics are equal to 1, with the exception of the links from/to 115 A and Z, which are configured with a metric of 100. 117 2. Path protection 119 A first protection strategy consists in excluding any local repair 120 but instead use end-to-end path protection. 122 For example, a Pseudo Wire (PW) from A to Z can be "path protected" 123 in the direction A to Z in the following manner: the operator 124 configures two SPRING paths T1 and T2 from A to Z. The two paths are 125 installed in the forwarding plane of A and hence are ready to forward 126 packets. The two paths are made disjoint using the SPRING 127 architecture. 129 T1 is established over path {AB, BC, CD, DE, EZ} and T2 over path 130 {AF, FG, GH, HI, IZ}. When T1 is up, the packets of the PW are sent 131 on T1. When T1 fails, the packets of the PW are sent on T2. When T1 132 comes back up, the operator either allows for an automated reversion 133 of the traffic onto T1 or selects an operator-driven reversion. The 134 solution to detect the end-to-end liveness of the path is out of the 135 scope of this document. 137 From a SPRING viewpoint, we would like to highlight the following 138 requirement: the two configured paths T1 and T2 MUST NOT benefit from 139 local protection. 141 3. Management free local protection 143 This section describes two alternatives to provide local protection 144 without requiring operator management, namely bypass protection and 145 shortest-path based protection. 147 For example, a demand from A to Z, transported over the shortest 148 paths provided by the SPRING architecture, benefits from management- 149 free local protection by having each node along the path 150 automatically pre-compute and pre-install a backup path for the 151 destination Z. Upon local detection of the failure, the traffic is 152 repaired over the backup path in sub-50msec. 154 The backup path computation should support the following 155 requirements: 157 o 100% link, node, and SRLG protection in any topology 158 o Automated computation by the IGP 159 o Selection of the backup path such as to minimize the chance for 160 transient congestion and/or delay during the protection period, as 161 reflected by the IGP metric configuration in the network. 163 3.1. Management free bypass protection 165 One way to provide local repair is to enforce a failover along the 166 shortest path around the failed component, ending at the protected 167 nexthop, so as to bypass the failed component and re-join the pre- 168 convergence path at the nexthop. In the case of node protection, 169 such bypass ends at the next-nexthop. 171 In our example, C protects Z, that it initially reaches via CD, by 172 enforcing the traffic over the bypass {CH, HD}. The resulting end- 173 to-end path between A and Z, upon recovery against the failure of 174 C-D, is depicted in Figure 2. 176 B * * *C------D * * *E 177 *| | * / * * / |* 178 * | | */ * */ | * 179 A | | /* * /* | Z 180 \ | | / * * / * | * 181 \| |/ **/ *|* 182 F------G------H------I 184 Figure 2: Bypass protection around link C-D 186 3.2. Management-free shortest path based protection 188 An alternative protection strategy consists in management-free local 189 protection, aiming at providing a repair for the destination based on 190 shortest path state for that destination. 192 In our example, C protects Z, that it initially reaches via CD, by 193 enforcing the traffic over its shortest path to Z, considering the 194 failure of the protected component. The resulting end-to-end path 195 between A and Z, upon recovery against the failure of C-D, is 196 depicted in Figure 3. 198 B * * *C------D------E 199 *| | * / | \ * |* 200 * | | */ | \* | * 201 A | | /* | *\ | Z 202 \ | | / * | * \ | * 203 \| |/ *|* \|* 204 F------G------H * * *I 206 Figure 3: Reference topology 208 4. Managed local protection 210 There may be cases where a management free repair does not fit the 211 policy of the operator. For example, in our illustration, the 212 operator may want to not have C-D and C-H used to protect each other, 213 in fear of a shared risk among the two links. 215 In this context, the protection mechanism must support the explicit 216 configuration of the backup path either under the form of high-level 217 constraints (end at the next-hop, end at the next-next-hop, minimize 218 this metric, avoid this SRLG...) or under the form of an explicit 219 path. 221 We discuss such aspects for both bypass and shortest path based 222 protection schemes. 224 4.1. Managed bypass protection 226 Let us illustrate the case using our reference example. For the 227 demand from A to B, the operator does not want to use the shortest 228 failover path to the nexthop, {CH, HD}, but rather the path 229 {CG,GH,HD}, as illustrated in Figure 4. 231 B * * *C------D * * *E 232 *| * \ / * * / |* 233 * | * \/ * */ | * 234 A | * /\ * /* | Z 235 \ | * / \ * / * | * 236 \| */ \*/ *|* 237 F------G * * *H------I 239 Figure 4: Managed bypass protection 241 4.2. Managed shortest path protection 243 In the case of shortest path protection, the case is the one of an 244 operator who does not want to use the shortest failover via link C-H, 245 but rather reach H via {CG, GH}. 247 The resulting end-to-end path upon activation of the protection is 248 illustrated in Figure 5. 250 B * * *C------D------E 251 *| * \ / | \ * |* 252 * | * \/ | \* | * 253 A | * /\ | *\ | Z 254 \ | * / \ | * \ | * 255 \| */ \|* \|* 256 F------G * * *H * * *I 258 Figure 5: Managed shortest path protection 260 5. Loop avoidance 262 Transient inconsistencies among the Forwarding Information Bases of 263 routers converging after a change in the state of links of the 264 network can occur. Such inconsistencies (some nodes forwarding 265 traffic according to the past network topology while some other nodes 266 are forwarding packets according to the new topology) may lead to 267 forwarding loops. 269 The SPRING architecture SHOULD provide solutions to prevent the 270 occurrence of micro-loops during convergence following a change in 271 the network state. A SPRING enabled router could take advantage of 272 the increased packet steering capabilities offered by SPRING in order 273 to steer packets in a way that packets do not enter such loops. 275 6. Co-existence 277 The operator may want to support several very-different services on 278 the same packet-switching infrastructure. As a result, the SPRING 279 architecture SHOULD allow for the co-existence of the different use 280 cases listed in this document, in the same network. 282 Let us illustrate this with the following example. 284 o Flow F1 is supported over path {C, C-D, E} 285 o Flow F2 is supported over path {C, C-D, I) 286 o Flow F3 is supported over path {C, C-D, Z) 287 o Flow F4 is supported over path {C, C-D, Z} 288 o It should be possible for the operator to configure the network to 289 achieve path protection for F1, management free shortest path 290 local protection for F2, managed protection over path {C-G, G-H, 291 Z} for F3, and management free bypass protection for F4. 293 7. References 295 [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. 296 Shakir, "Segment Routing Architecture", 297 draft-ietf-spring-segment-routing-07 (work in progress), 298 December 2015. 300 Authors' Addresses 302 Pierre Francois 303 Cisco Systems, Inc. 304 Vimercate 305 IT 307 Email: pifranco@cisco.com 309 Clarence Filsfils 310 Cisco Systems, Inc. 311 Brussels 312 BE 314 Email: cfilsfil@cisco.com 316 Bruno Decraene 317 Orange 318 Issy-les-Moulineaux 319 FR 321 Email: bruno.decraene@orange.com 323 Rob Shakir 324 Jive Communications, Inc. 325 Orem 326 US 328 Email: rjs@rob.sh