idnits 2.17.1 draft-bashandy-rtgwg-segment-routing-uloop-04.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 (September 24, 2018) is 2040 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) == Unused Reference: '1' is defined on line 267, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 271, 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: Standards Track Cisco Systems, Inc. 4 Expires: March 2019 Stephane Litkowski 5 Orange 6 Pierre Francois 7 Individual Contributor 8 September 24, 2018 10 Loop avoidance using Segment Routing 11 draft-bashandy-rtgwg-segment-routing-uloop-04 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 March 24, 2018. 55 Copyright Notice 57 Copyright (c) 2018 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, and 99 all links have symmetric metrics. We consider the traffic from S to 100 D. 102 +-------R1------R2---+ 103 / \ 104 / \ 105 S---R0 R3-----D 106 \ / 107 \ / 108 +-------R5------R4---+ 109 100 110 Figure 1 Illustrative scenario, failure of link R2-R3 112 When the link between R2 and R3 fails, traffic sent from S to D, 113 initially flowing along S-R0-R1-R2-R3-D is subject to transient 114 forwarding loops while routers update their forwarding state for 115 destination D. For example, if R0 updates its FIB before R5, packets 116 for D may loop between R0 and R5. If R5 updates its FIB before R4, 117 packets for D may loop between R5 and R4. 119 Using segment routing, a headend can enforce an explicit path 120 without creating any state along the desired path. As a result, a 121 converging node can enforce traffic on the post-convergence path in 122 a loop-free manner, using a list of segments (typically short). We 123 suggest that the converging node enforces its post-convergence path 124 to the destination when applying this behavior to ease operation 125 (predictability of path, less capacity planning issues ...); nodes 126 converge over their new optimal path, but temporarily use an SR 127 policy to ensure loop-freeness over that path. 129 In our example, R0 can temporarily steer traffic destined to D over 130 SR path [NodeSID(R4), AdjSID(R4->R3), D]. By doing so, packets for 131 D will be forwarded by R5 as per NodeSID(R4), and by R4 as per 132 AdjSID(R4->R3). From R3 on, the packet is forwarded as per 133 destination D. As a result, traffic follows the desired path, 134 regardless of the forwarding state for destination D at R5 and R4. 135 After some time, the normal forwarding behavior (without using an SR 136 policy) can be applied; routers will converge to their final 137 forwarding state, still consistently forwarding along the post- 138 convergence paths across the network. 140 1.1. Conventions used in this document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 143 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 144 in this document are to be interpreted as described in RFC-2119 145 In this document, these words will appear with that interpretation 146 only when in ALL CAPS. Lower case uses of these words are not to 147 be interpreted as carrying RFC-2119 significance. 149 2. Loop-free two-stage convergence process 151 Upon a topology change, when a node R converging for destination D 152 does not trust the loop-freeness of its post-convergence path for 153 destination D, it applies the following two-stage convergence 154 process for destination D. 156 Stage 1: After computing the new path to D, for a predetermined 157 amount of time C, R installs a FIB entry for D that steers packets 158 to D via a loop-free SR path. C should be greater than or equal to 159 the worst-case convergence time of a node, network-wide. The 160 determination of "C" is outside the scope of this document. The SR 161 path is computed when the event occurs. 163 Stage 2: After C elapses, R installs the normal post-convergence FIB 164 entry for D, i.e. without any additional segments inserted that 165 ensure the loop-free property. 167 Loop-freeness is ensured during this process, because: 169 1. Paths made of non up-to-date routers are loop-free. 171 Routers which forward as per the initial state of the network are 172 consistent. 174 2. A packet reaching a node in stage 1 is ensured to reach its 175 destination. 177 When a packet reaches a router in stage 1, it is steered on a SR 178 path ensuring a loop-free post-convergence path, whatever the state 179 of other routers on the path. 181 3. Paths made of a mix of routers in stage 1 and stage 2 are 182 consistent. 184 After C milliseconds, all routers are forwarding as per their post- 185 convergence paths, either expressed classically or as a loop-free SR 186 path. 188 In our example, when R2-R3 fails, R0 forwards traffic for 189 destination D over SR Path [NodeSID(R4), AdjSID(R4->R3), D], for C 190 milliseconds. During that period, packets sent by R0 to D are loop- 191 free as per the application of the policy. When C elapses, R0 now 192 uses its normal post-convergence path to the destination, forwarding 193 packets for D as is to R5. 195 R5 also implements loop avoidance, and has thus temporarily used a 196 loop-avoiding SR policy for D. This policy is [AdjSID(R4->R3), D], 197 oif R5->R4. If R5 is still applying the stage 1 behavior, the 198 packet will be forwarded using this policy, and will thus safely 199 reach the destination. If R5 also had moved to stage 2, it forwards 200 the packet as per its normal post-convergence path, via R4. The 201 forwarding state of R4 for D at stage 1 and stage 2 are the same: 202 oif R4->R3, as forwarding packets for destination D as is to R3 203 ensures a loop-free post-convergence path. 205 3. Computing loop-avoiding SR policies 207 The computation to turn a post-convergence path into a loop-free 208 list of segments is outside the scope of this document. It is a 209 local behavior at a node. 211 In a future revision of this document, we may provide a reference 212 approach to compute loop-avoiding policies for link up, link metric 213 increase, link down, link metric decrease, node up, and node down 214 events. TI-LFA Repair Tunnel 216 4. Analysis 218 In this section, we review the main characteristics of the proposed 219 solution. These characteristics are illustrated in [3]. 221 4.1. Incremental Deployment 223 There is no requirement for a full network upgrade to get benefits 224 from the solution. 226 (1) Nodes that are upgraded bring benefit for the traffic passing 227 through them. 229 (2) Nodes that are not upgraded to support SR-based loop-avoidance 230 will cause the micro-loops that they were causing before, unless 231 they get avoided by the local behavior of a node supporting the 232 behavior. 234 4.2. No impact on capacity planning 236 By ensuring loop-free post-convergence paths, the behavior remains 237 in line with the natural expected convergence process of the IGP. 238 Enabling SR-based loop-avoidance hence does not require 239 consideration for capacity planning, compared to any loop avoidance 240 mechanism that lets traffic follow a different path than the post- 241 convergence one. The behavior is local. Nothing is expected from 242 remote nodes except the basic support of Prefix and Adjacency SID's. 244 5. Security Considerations 246 The behavior described in this document is internal functionality 247 to a router that result in the ability to explicitly steer traffic 248 over the post convergence path after a remote topology change in a 249 manner that guarantees loop freeness. Because the behavior serves 250 to minimize the disruption associated with a topology changes, it 251 can be seen as a modest security enhancement. 253 6. IANA Considerations 255 No requirements for IANA 257 7. Contributors 259 Additional contributors: Bruno Decraene and Peter Psenak. 261 8. References 263 8.1. Normative References 265 8.2. Informative References 267 [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and 268 Shakir, R., "Segment Routing Architecture", draft-ietf-spring- 269 segment-routing-11 (work in progress), November 2016. 271 [2] Shand, M. and Bryant, S., "IP Fast Reroute Framework", RFC 272 5714, January 2010. 274 [3] Litkowski, S., "Avoiding micro-loops using Segment Routing", 275 MPLS World Congress , 2016. 277 9. Acknowledgments 279 This document was prepared using 2-Word-v2.0.template.dot. 281 Authors' Addresses 283 Ahmed Bashandy 284 Arrcus 285 Email: abashandy.ietf@gmail.com 287 Clarence Filsfils 288 Cisco Systems 289 Brussels, Belgium 290 Email: cfilsfil@cisco.com 292 Stephane Litkowski 293 Orange 294 Email: stephane.litkowski@orange.com 296 Pierre Francois 297 pfrpfr@gmail.com