idnits 2.17.1 draft-francois-sr-resiliency-use-case-00.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 121: '... and T2 MUST NOT benefit from local ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 31, 2014) is 3732 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) == Outdated reference: A later version (-01) exists of draft-filsfils-rtgwg-segment-routing-00 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). 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: August 4, 2014 Cisco Systems, Inc. 6 Bruno Decraene 7 Orange 8 Rob Shakir 9 BT 10 January 31, 2014 12 Use-cases for Resiliency in Segment Routing 13 draft-francois-sr-resiliency-use-case-00 15 Abstract 17 This document describes the use cases for resiliency in SR 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 August 4, 2014. 36 Copyright Notice 38 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Management-free local protection . . . . . . . . . . . . . . . 4 56 4. Managed local protection . . . . . . . . . . . . . . . . . . . 4 57 5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1. Introduction 63 Segment Routing (SR) aims at supporting services with tight SLA 64 guarantees [1]. This document reviews alternative techniques to 65 provide Fast Reroute (FRR) for SR traffic. Note that these 66 techniques can be applied to protect LSPs created with LDP as well as 67 pure IP traffic. 69 A FRR technique involves the pre-computation and dataplane pre- 70 installation of backup path such as the repair traffic in 50msec upon 71 failure detection. The term "protection" is often used as a synonym 72 for FRR. Such technique supposes the existing of a sub-10msec 73 failure detection technique. 75 Three key alternatives are described: path protection, local 76 protection without operator management and local protection with 77 operator management. 79 The purpose of this document is to illustrate the different 80 techniques and explain how an operator could combine them in the same 81 network. Solutions are not defined in this document. 83 PE1 84 / \ 85 / \ 86 B------C------D------E 87 /| | \ / | \ / |\ 88 / | | \/ | \/ | \ 89 A | | /\ | /\ | Z 90 \ | | / \ | / \ | / 91 \| |/ \|/ \|/ 92 F------G------H------I 94 Figure 1: Reference topology 96 We use Figure 1 as a reference topology throughout the document. We 97 describe the various use-cases in the next sections. All link 98 metrics are equal to 1, with the exception of the links of PE1 which 99 are configured with a metric of 100. 101 2. Path protection 103 A first protection strategy consists in excluding any local repair 104 but instead use end-to-end path protection. 106 For example, a PW from A to Z can be "path protected" in the 107 direction A to Z in the following manner: the operator configures two 108 SR tunnels T1 and T2 from A to Z. The two tunnels are installed in 109 the forwarding plane of A and hence are ready to encapsulate and 110 forward packets. The two tunnels are installed over disjoint paths 111 using adjacency segments (T1 over segment list {AB, BC, CD, DE, EZ} 112 and T2 over segment list {AF, FG, GH, HI, IZ}). When T1 is up, the 113 packets of the PW are sent on T1. When T1 fails, the packets of the 114 PW are sent on T2. When the tunnel T1 comes back up, the operator 115 either allows for an automated reversion of the traffic onto T1 or 116 selects an operator-driven reversion. The end-to-end liveness of a 117 tunnel is for example checked with BFD. 119 From an SR viewpoint, we would like to highlight the following 120 requirement: the adjacency segments used to support the tunnels T1 121 and T2 MUST NOT benefit from local protection. This is achieved by 122 resetting the B-flag in the related AdjSID's as per the IGP 123 extensions defined in [3]. 125 3. Management-free local protection 127 An alternative protection strategy consists in management-free local 128 protection. 130 For example, a PW from C to E transported by the single segment 131 NodeSID(E) benefits from management-free local protection by having 132 each node along the path (e.g. C and D) to automatically pre-compute 133 and pre-install backup path for the destination E. Upon local 134 detection of the failure (e.g. link BFD), the traffic is repaired 135 over the backup path in sub-50msec. 137 The backup path computation should support the following 138 requirements: 140 o 100% link, node, and SRLG protection in any topology 141 o Automated computation by the IGP 142 o Selection of the backup path such as to minimize the chance for 143 transient congestion and/or delay during the protection period, as 144 reflected by the IGP metric configuration in the network. 146 An SR solution aimed at supporting these requirements is defined in 147 [2]. 149 4. Managed local protection 151 A final alternative protection strategy consists in managed local 152 protection. 154 For policy reasons, the operator may want very specific backup paths 155 to be used. 157 For example, the operator may want the backup path to end at the 158 next-hop (or next-next-hop for node failure) hence excluding IPFRR/ 159 LFA types of backup path. Also, the operator might want to tightly 160 control the backup path to the next-hop: for the destination Z upon 161 the failure of link CD, the backup path CGHD might be desired while 162 the backup paths CGD and CHD are refused. 164 The protection mechanism must support the explicit configuration of 165 the backup path either under the form of high-level constraints (end 166 at the next-hop, end at the next-next-hop, minimize this metric, 167 avoid this SRLG...) or under the form of an explicit segment list. 169 5. Co-existence 171 The operator may want to support several very-different services on 172 the same packet-switching infrastructure. 174 The SR resiliency architecture allows the co-existence of different 175 FRR techniques. 177 Let us illustrate this for adjacency segments with the following 178 example. 180 o Node C is configured with 3 adjacency segments for the connected 181 interface to D: AdjSID(CD1), AdjSID(CD2) and AdjSID(CD3) 182 o SR Flow F1: from A to E over segment list 183 {NodeSID(C), AdjSID(CD1), NodeSID(E)} 184 o SR Flow F2: from F to I over segment list 185 {NodeSID(C), AdjSID(CD2), NodeSID(I)} 186 o SR Flow F3: from G to Z over segment list 187 {NodeSID(C), AdjSID(CD3), NodeSID(Z)} 188 o Node C is configured with a distinct protection technique for each 189 adjacency segment. AdjSID(CD1) is configured without protection, 190 AdjSID(CD2) is configured to benefit from management-free local 191 protection and AdjSID(CD3) is configured for managed local 192 protection over the path {AdjSID(CH), AdjSID(HD)} 194 Such a co-existence is partially supported by the SR IGP extensions 195 [ref tbd] 196 o Multiple adjacency segments can be advertised for the same 197 adjacency 198 o The non-protected property of AdjSID(CD1) is signalled by a reset 199 B flag. 201 o The protected property of AdjSID(CD2) and AdjSID(CD3) are 202 signalled by a set B flag. 204 The SR IGP extension should be extended to discreminate between 205 AdjSID(CD2) and AdjSID(CD3). A single flag could be defined (managed 206 path vs fully automated). 208 6. References 210 [1] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 211 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, 212 S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment 213 Routing Architecture", draft-filsfils-rtgwg-segment-routing-00 214 (work in progress), June 2013. 216 [2] Francois, P., Filsfils, C., Bashandy, A., Decraene, B., and S. 217 Litkowski, "Topology Independent Fast Reroute using Segment 218 Routing", November 2013. 220 [3] Previdi, S., Filsfils, C., and A. Bashandy, "IS-IS Segment 221 Routing Extensions", October 2013. 223 Authors' Addresses 225 Pierre Francois 226 IMDEA Networks 227 Leganes 228 ES 230 Email: pierre.francois@imdea.org 232 Clarence Filsfils 233 Cisco Systems, Inc. 234 Brussels 235 BE 237 Email: cfilsfil@cisco.com 238 Bruno Decraene 239 Orange 240 Issy-les-Moulineaux 241 FR 243 Email: bruno.decraene@orange.com 245 Rob Shakir 246 BT 247 London 248 UK 250 Email: rob.shakir@bt.com