idnits 2.17.1 draft-bashandy-rtgwg-segment-routing-uloop-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 12, 2017) is 2534 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 265, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 269, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ahmed Bashandy 2 Internet Draft Clarence Filsfils 3 Intended status: Informational Cisco Systems, Inc. 4 Expires: November 2017 Stephane Litkowski 5 Orange 6 Pierre Francois 7 Individual Contributor 8 May 12, 2017 10 Loop avoidance using Segment Routing 11 draft-bashandy-rtgwg-segment-routing-uloop-00 13 Abstract 15 This document presents a mechanism aimed at providing loop avoidance 16 in the case of IGP network convergence event. The solution relies on 17 the temporary use of SR policies ensuring loop-freeness over the 18 post-convergence paths from the converging node to the destination. 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 This document may contain material from IETF Documents or IETF 26 Contributions published or made publicly available before November 27 10, 2008. The person(s) controlling the copyright in some of this 28 material may not have granted the IETF Trust the right to allow 29 modifications of such material outside the IETF Standards Process. 30 Without obtaining an adequate license from the person(s) 31 controlling the copyright in such materials, this document may not 32 be modified outside the IETF Standards Process, and derivative 33 works of it may not be created outside the IETF Standards Process, 34 except to format it for publication as an RFC or to translate it 35 into languages other than English. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other 44 documents at any time. It is inappropriate to use Internet-Drafts 45 as reference material or to cite them other than as "work in 46 progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 This Internet-Draft will expire on November 12, 2017. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with 65 respect to this document. Code Components extracted from this 66 document must include Simplified BSD License text as described in 67 Section 4.e of the Trust Legal Provisions and are provided without 68 warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction...................................................2 73 1.1. Conventions used in this document.........................3 74 2. Loop-free two-stage convergence process........................4 75 3. Computing loop-avoiding SR policies............................5 76 4. Analysis.......................................................5 77 4.1. Incremental Deployment....................................5 78 4.2. No impact on capacity planning............................5 79 5. Security Considerations........................................6 80 6. IANA Considerations............................................6 81 7. Contributors...................................................6 82 8. References.....................................................6 83 8.1. Normative References......................................6 84 8.2. Informative References....................................6 85 9. Acknowledgments................................................6 87 1. Introduction 89 Forwarding loops happen during the convergence of the IGP, as a 90 result of transient inconsistency among forwarding states of the 91 nodes of the network. 93 This document provides a mechanism leveraging Segment Routing to 94 ensure loop-freeness during the IGP reconvergence process following 95 a link-state change event. 97 We use Figure 1 to illustrate the mechanism. In this scenario, all 98 the IGP link metrics are 1, excepted R3-R4 whose metric is 100. We 99 consider the traffic from S to D. 101 +-------R1------R2---+ 102 / \ 103 / \ 104 S---R0 R3-----D 105 \ / 106 \ / 107 +-------R5------R4---+ 108 100 109 Figure 1 Illustrative scenario, failure of link R2-R3 111 When the link between R2 and R3 fails, traffic sent from S to D, 112 initially flowing along S-R0-R1-R2-R3-D is subject to transient 113 forwarding loops while routers update their forwarding state for 114 destination D. For example, if R0 updates its FIB before R5, packets 115 for D may loop between R0 and R5. If R5 updates its FIB before R4, 116 packets for D may loop between R5 and R4. 118 Using segment routing, a headend can enforce an explicit path 119 without creating any state along the desired path. As a result, a 120 converging node can enforce traffic on the post-convergence path in 121 a loop-free manner, using a list of segments (typically short). We 122 suggest that the converging node enforces its post-convergence path 123 to the destination when applying this behavior to ease operation 124 (predictability of path, less capacity planning issues ...); nodes 125 converge over their new optimal path, but temporarily use an SR 126 policy to ensure loop-freeness over that path. 128 In our example, R0 can temporarily steer traffic destined to D over 129 SR path [NodeSID(R4), AdjSID(R4->R3), D]. By doing so, packets for 130 D will be forwarded by R5 as per NodeSID(R4), and by R4 as per 131 AdjSID(R4->R3). From R3 on, the packet is forwarded as per 132 destination D. As a result, traffic follows the desired path, 133 regardless of the forwarding state for destination D at R5 and R4. 134 After some time, the normal forwarding behavior (without using an SR 135 policy) can be applied; routers will converge to their final 136 forwarding state, still consistently forwarding along the post- 137 convergence paths across the network. 139 1.1. Conventions used in this document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 142 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 143 in this document are to be interpreted as described in RFC-2119 144 In this document, these words will appear with that interpretation 145 only when in ALL CAPS. Lower case uses of these words are not to 146 be interpreted as carrying RFC-2119 significance. 148 2. Loop-free two-stage convergence process 150 Upon a topology change, when a node R converging for destination D 151 does not trust the loop-freeness of its post-convergence path for 152 destination D, it applies the following two-stage convergence 153 process for destination D. 155 Stage 1: After computing the new path to D, for a configured amount 156 of time C, R installs a FIB entry for D that steers packets to D via 157 a loop-free SR path. C is assumed to be configured as per the 158 worst-case convergence time of a node, network-wide. The SR path is 159 computed when the event occurs. 161 Stage 2: After C elapses, R installs the normal post-convergence FIB 162 entry for D, i.e. without any additional segments inserted that 163 ensure the loop-free property. 165 Loop-freeness is ensured during this process, because: 167 1. Paths made of non up-to-date routers are loop-free. 169 Routers which forward as per the initial state of the network are 170 consistent. 172 2. A packet reaching a node in stage 1 is ensured to reach its 173 destination. 175 When a packet reaches a router in stage 1, it is steered on a SR 176 path ensuring a loop-free post-convergence path, whatever the state 177 of other routers on the path. 179 3. Paths made of a mix of routers in stage 1 and stage 2 are 180 consistent. 182 After C milliseconds, all routers are forwarding as per their post- 183 convergence paths, either expressed classically or as a loop-free SR 184 path. 186 In our example, when R2-R3 fails, R0 forwards traffic for 187 destination D over SR Path [NodeSID(R4), AdjSID(R4->R3), D], for C 188 milliseconds. During that period, packets sent by R0 to D are loop- 189 free as per the application of the policy. When C elapses, R0 now 190 uses its normal post-convergence path to the destination, forwarding 191 packets for D as is to R5. 193 R5 also implements loop avoidance, and has thus temporarily used a 194 loop-avoiding SR policy for D. This policy is [AdjSID(R4->R3), D], 195 oif R5->R4. If R5 is still applying the stage 1 behavior, the 196 packet will be forwarded using this policy, and will thus safely 197 reach the destination. If R5 also had moved to stage 2, it forwards 198 the packet as per its normal post-convergence path, via R4. The 199 forwarding state of R4 for D at stage 1 and stage 2 are the same: 200 oif R4->R3, as forwarding packets for destination D as is to R3 201 ensures a loop-free post-convergence path. 203 3. Computing loop-avoiding SR policies 205 The computation to turn a post-convergence path into a loop-free 206 list of segments is outside the scope of this document. It is a 207 local behavior at a node. 209 In a future revision of this document, we may provide a reference 210 approach to compute loop-avoiding policies for link up, link metric 211 increase, link down, link metric decrease, node up, and node down 212 events. TI-LFA Repair Tunnel 214 4. Analysis 216 In this section, we review the main characteristics of the proposed 217 solution. These characteristics are illustrated in [3]. 219 4.1. Incremental Deployment 221 There is no requirement for a full network upgrade to get benefits 222 from the solution. 224 (1) Nodes that are upgraded bring benefit for the traffic passing 225 through them. 227 (2) Nodes that are not upgraded to support SR-based loop-avoidance 228 will cause the micro-loops that they were causing before, unless 229 they get avoided by the local behavior of a node supporting the 230 behavior. 232 4.2. No impact on capacity planning 234 By ensuring loop-free post-convergence paths, the behavior remains 235 in line with the natural expected convergence process of the IGP. 236 Enabling SR-based loop-avoidance hence does not require 237 consideration for capacity planning, compared to any loop avoidance 238 mechanism that lets traffic follow a different path than the post- 239 convergence one. The behavior is local. Nothing is expected from 240 remote nodes except the basic support of Prefix and Adjacency SID's. 242 5. Security Considerations 244 The behavior described in this document is internal functionality 245 to a router that result in the ability to explicitly steer traffic 246 over the post convergence path after a remote topology change in a 247 manner that guarantees loop freeness. As such no additional 248 security risk is introduced by using the mechanisms proposed in 249 this document. 251 6. IANA Considerations 253 No requirements for IANA 255 7. Contributors 257 Additional contributors: Bruno Decraene and Peter Psenak. 259 8. References 261 8.1. Normative References 263 8.2. Informative References 265 [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and 266 Shakir, R., "Segment Routing Architecture", draft-ietf-spring- 267 segment-routing-11 (work in progress), November 2016. 269 [2] Shand, M. and Bryant, S., "IP Fast Reroute Framework", RFC 270 5714, January 2010. 272 [3] Litkowski, S., "Avoiding micro-loops using Segment Routing", 273 MPLS World Congress , 2016. 275 9. Acknowledgments 277 This document was prepared using 2-Word-v2.0.template.dot. 279 Authors' Addresses 281 Ahmed Bashandy 282 Cisco Systems 283 170 West Tasman Dr, San Jose, CA 95134, USA 284 Email: bashandy@cisco.com 286 Clarence Filsfils 287 Cisco Systems 288 Brussels, Belgium 289 Email: cfilsfil@cisco.com 291 Stephane Litkowski 292 Orange 293 Email: stephane.litkowski@orange.com 295 Pierre Francois 296 pfrpfr@gmail.com