idnits 2.17.1 draft-francois-spring-resiliency-use-case-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 : ---------------------------------------------------------------------------- ** 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 123: '... paths T1 and T2 MUST NOT benefit from...' RFC 2119 keyword, line 167: '... 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 1, 2014) is 3678 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pierre Francois 3 Internet-Draft IMDEA Networks 4 Intended status: Standards Track Clarence Filsfils 5 Expires: October 3, 2014 Cisco Systems, Inc. 6 Bruno Decraene 7 Orange 8 Rob Shakir 9 BT 10 April 1, 2014 12 Use-cases for Resiliency in SPRING 13 draft-francois-spring-resiliency-use-case-01 15 Abstract 17 This document describes the use cases for resiliency in SPRING 18 networks. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 3, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Path protection . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Management-free local protection . . . . . . . . . . . . . . . 4 57 4. Managed local protection . . . . . . . . . . . . . . . . . . . 4 58 5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 SPRING aims at providing a network architecture supporting services 65 with tight SLA guarantees [1]. This document reviews various use 66 cases for Fast Reroute (FRR) of services in a SPRING network. Note 67 that these use cases are in particular applicable to existing LDP 68 based and pure IP networks. 70 A FRR technique involves the pre-computation and dataplane pre- 71 installation of backup paths so as to repair traffic in 50msec upon 72 failure detection. The term "protection" is often used as a synonym 73 for FRR. Such techniques suppose the existence of a sub-10msec 74 failure detection mechanism. 76 Three key alternatives are described: path protection, local 77 protection without operator management and local protection with 78 operator management. 80 The purpose of this document is to illustrate the different 81 techniques and explain how an operator could combine them in the same 82 network. Solutions are not defined in this document. 84 PE1 85 / \ 86 / \ 87 B------C------D------E 88 /| | \ / | \ / |\ 89 / | | \/ | \/ | \ 90 A | | /\ | /\ | Z 91 \ | | / \ | / \ | / 92 \| |/ \|/ \|/ 93 F------G------H------I 95 Figure 1: Reference topology 97 We use Figure 1 as a reference topology throughout the document. We 98 describe the various use-cases in the next sections. All link 99 metrics are equal to 1, with the exception of the links of PE1 which 100 are configured with a metric of 100. 102 2. Path protection 104 A first protection strategy consists in excluding any local repair 105 but instead use end-to-end path protection. 107 For example, a Pseudo Wire (PW) from A to Z can be "path protected" 108 in the direction A to Z in the following manner: the operator 109 configures two SPRING paths T1 and T2 from A to Z. The two paths are 110 installed in the forwarding plane of A and hence are ready to forward 111 packets. The two paths are made disjoint using the SPRING 112 architecture. 114 T1 is established over path {AB, BC, CD, DE, EZ} and T2 over path 115 {AF, FG, GH, HI, IZ}. When T1 is up, the packets of the PW are sent 116 on T1. When T1 fails, the packets of the PW are sent on T2. When T1 117 comes back up, the operator either allows for an automated reversion 118 of the traffic onto T1 or selects an operator-driven reversion. The 119 solution to detect the end-to-end liveness of the path is out of the 120 scope of this document. 122 From a SPRING viewpoint, we would like to highlight the following 123 requirement: the two configured paths T1 and T2 MUST NOT benefit from 124 local protection. 126 3. Management-free local protection 128 An alternative protection strategy consists in management-free local 129 protection. 131 For example, a PW from C to E, transported over the shortest path to 132 E provided by the SPRING architecture, benefits from management-free 133 local protection by having each node along the path (e.g. C and D) 134 automatically pre-compute and pre-install a backup path for the 135 destination E. Upon local detection of the failure, the traffic is 136 repaired over the backup path in sub-50msec. 138 The backup path computation should support the following 139 requirements: 141 o 100% link, node, and SRLG protection in any topology 142 o Automated computation by the IGP 143 o Selection of the backup path such as to minimize the chance for 144 transient congestion and/or delay during the protection period, as 145 reflected by the IGP metric configuration in the network. 147 4. Managed local protection 149 There may be cases where a management free repair does not fit the 150 policy of the operator. For example, the operator may want the 151 backup path to end at the next-hop (or next-next-hop for node 152 failure) hence excluding IPFRR/LFA types of backup path. Also, the 153 operator might want to tightly control the backup path to the next- 154 hop: for the destination Z upon the failure of link CD, the backup 155 path CGHD might be desired while the backup paths CGD and CHD are 156 refused. 158 The protection mechanism must support the explicit configuration of 159 the backup path either under the form of high-level constraints (end 160 at the next-hop, end at the next-next-hop, minimize this metric, 161 avoid this SRLG...) or under the form of an explicit path. 163 5. Co-existence 165 The operator may want to support several very-different services on 166 the same packet-switching infrastructure. As a result, the SPRING 167 architecture SHOULD allow for the co-existence of the different use 168 cases listed in this document, in the same network. 170 Let us illustrate this with the following example. 172 o Flow F1 is supported over path {C, C-D, E} 173 o Flow F2 is supported over path {C, C-D, I) 174 o Flow F3 is supported over path {C, C-D, Z) 175 o It should be possible for the operator to configure the network to 176 achieve path protection for F1, management free local protection 177 for F2, and managed protection over path {C-H, H-D, Z} for F3. 179 6. References 181 [1] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 182 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, 183 S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment 184 Routing Architecture", draft-filsfils-rtgwg-segment-routing-01 185 (work in progress), October 2013. 187 Authors' Addresses 189 Pierre Francois 190 IMDEA Networks 191 Leganes 192 ES 194 Email: pierre.francois@imdea.org 195 Clarence Filsfils 196 Cisco Systems, Inc. 197 Brussels 198 BE 200 Email: cfilsfil@cisco.com 202 Bruno Decraene 203 Orange 204 Issy-les-Moulineaux 205 FR 207 Email: bruno.decraene@orange.com 209 Rob Shakir 210 BT 211 London 212 UK 214 Email: rob.shakir@bt.com