idnits 2.17.1 draft-bashandy-rtgwg-segment-routing-uloop-11.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 has text resembling 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 (June 23, 2021) is 1037 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 274, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 278, 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 Individual 3 Intended status: Standards Track Clarence Filsfils 4 Expires: December 2021 Stephane Litkowski 5 Cisco Systems, Inc. 6 Bruno Decraene 7 Orange 8 Pierre Francois 9 INSA Lyon 10 Peter Psenak 11 Cisco Systems 12 June 23, 2021 14 Loop avoidance using Segment Routing 15 draft-bashandy-rtgwg-segment-routing-uloop-11 17 Abstract 19 This document presents a mechanism aimed at providing loop avoidance 20 in the case of IGP network convergence event. The solution relies on 21 the temporary use of SR policies ensuring loop-freeness over the 22 post-convergence paths from the converging node to the destination. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 This document may contain material from IETF Documents or IETF 30 Contributions published or made publicly available before November 31 10, 2008. The person(s) controlling the copyright in some of this 32 material may not have granted the IETF Trust the right to allow 33 modifications of such material outside the IETF Standards Process. 34 Without obtaining an adequate license from the person(s) 35 controlling the copyright in such materials, this document may not 36 be modified outside the IETF Standards Process, and derivative 37 works of it may not be created outside the IETF Standards Process, 38 except to format it for publication as an RFC or to translate it 39 into languages other than English. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other 48 documents at any time. It is inappropriate to use Internet-Drafts 49 as reference material or to cite them other than as "work in 50 progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 This Internet-Draft will expire on December 23, 2021. 60 Copyright Notice 62 Copyright (c) 2021 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with 70 respect to this document. Code Components extracted from this 71 document must include Simplified BSD License text as described in 72 Section 4.e of the Trust Legal Provisions and are provided without 73 warranty as described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction...................................................2 78 1.1. Conventions used in this document.........................4 79 2. Loop-free two-stage convergence process........................4 80 3. Computing loop-avoiding SR policies............................5 81 4. Analysis.......................................................5 82 4.1. Incremental Deployment....................................5 83 4.2. No impact on capacity planning............................5 84 5. Security Considerations........................................6 85 6. IANA Considerations............................................6 86 7. Contributors...................................................6 87 8. References.....................................................6 88 8.1. Normative References......................................6 89 8.2. Informative References....................................6 90 9. Acknowledgments................................................6 92 1. Introduction 94 Forwarding loops happen during the convergence of the IGP, as a 95 result of transient inconsistency among forwarding states of the 96 nodes of the network. 98 This document provides a mechanism leveraging SR-MPLS and/or SRv6 to 99 ensure loop-freeness during the IGP reconvergence process following 100 a link-state change event. 102 We use Figure 1 to illustrate the mechanism. In this scenario, all 103 the IGP link metrics are 1, excepted R3-R4 whose metric is 100, and 104 all links have symmetric metrics. We consider the traffic from S to 105 D. 107 +-------R1------R2---+ 108 / \ 109 / \ 110 S---R0 R3-----D 111 \ / 112 \ / 113 +-------R5------R4---+ 114 100 115 Figure 1 Illustrative scenario, failure of link R2-R3 117 When the link between R2 and R3 fails, traffic sent from S to D, 118 initially flowing along S-R0-R1-R2-R3-D is subject to transient 119 forwarding loops while routers update their forwarding state for 120 destination D. For example, if R0 updates its FIB before R5, packets 121 for D may loop between R0 and R5. If R5 updates its FIB before R4, 122 packets for D may loop between R5 and R4. 124 Using segment routing, a headend can enforce an explicit path 125 without creating any state along the desired path. As a result, a 126 converging node can enforce traffic on the post-convergence path in 127 a loop-free manner, using a list of segments (typically short). We 128 suggest that the converging node enforces its post-convergence path 129 to the destination when applying this behavior to ease operation 130 (predictability of path, less capacity planning issues ...); nodes 131 converge over their new optimal path, but temporarily use an SR 132 policy to ensure loop-freeness over that path. 134 In our example, R0 can temporarily steer traffic destined to D over 135 SR path [NodeSID(R4), AdjSID(R4->R3), D]. By doing so, packets for 136 D will be forwarded by R5 as per NodeSID(R4), and by R4 as per 137 AdjSID(R4->R3). From R3 on, the packet is forwarded as per 138 destination D. As a result, traffic follows the desired path, 139 regardless of the forwarding state for destination D at R5 and R4. 140 After some time, the normal forwarding behavior (without using an SR 141 policy) can be applied; routers will converge to their final 142 forwarding state, still consistently forwarding along the post- 143 convergence paths across the network. 145 1.1. Conventions used in this document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 148 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 149 in this document are to be interpreted as described in RFC-2119 151 In this document, these words will appear with that interpretation 152 only when in ALL CAPS. Lower case uses of these words are not to 153 be interpreted as carrying RFC-2119 significance. 155 2. Loop-free two-stage convergence process 157 Upon a topology change, when a node R converging for destination D 158 does not trust the loop-freeness of its post-convergence path for 159 destination D, it applies the following two-stage convergence 160 process for destination D. 162 Stage 1: After computing the new path to D, for a predetermined 163 amount of time C, R installs a FIB entry for D that steers packets 164 to D via a loop-free SR path. C should be greater than or equal to 165 the worst-case convergence time of a node, network-wide. The 166 determination of "C" is outside the scope of this document. The SR 167 path is computed when the event occurs. 169 Stage 2: After C elapses, R installs the normal post-convergence FIB 170 entry for D, i.e. without any additional segments inserted that 171 ensure the loop-free property. 173 Loop-freeness is ensured during this process, because: 175 1. Paths made of non up-to-date routers are loop-free. 177 Routers which forward as per the initial state of the network are 178 consistent. 180 2. A packet reaching a node in stage 1 is ensured to reach its 181 destination. 183 When a packet reaches a router in stage 1, it is steered on a SR 184 path ensuring a loop-free post-convergence path, whatever the state 185 of other routers on the path. 187 3. Paths made of a mix of routers in stage 1 and stage 2 are 188 consistent. 190 After C milliseconds, all routers are forwarding as per their post- 191 convergence paths, either expressed classically or as a loop-free SR 192 path. 194 In our example, when R2-R3 fails, R0 forwards traffic for 195 destination D over SR Path [NodeSID(R4), AdjSID(R4->R3), D], for C 196 milliseconds. During that period, packets sent by R0 to D are loop- 197 free as per the application of the policy. When C elapses, R0 now 198 uses its normal post-convergence path to the destination, forwarding 199 packets for D as is to R5. 201 R5 also implements loop avoidance, and has thus temporarily used a 202 loop-avoiding SR policy for D. This policy is [AdjSID(R4->R3), D], 203 oif R5->R4. If R5 is still applying the stage 1 behavior, the 204 packet will be forwarded using this policy, and will thus safely 205 reach the destination. If R5 also had moved to stage 2, it forwards 206 the packet as per its normal post-convergence path, via R4. The 207 forwarding state of R4 for D at stage 1 and stage 2 are the same: 208 oif R4->R3, as forwarding packets for destination D as is to R3 209 ensures a loop-free post-convergence path. 211 3. Computing loop-avoiding SR policies 213 The computation to turn a post-convergence path into a loop-free 214 list of segments is outside the scope of this document. It is a 215 local behavior at a node. 217 In a future revision of this document, we may provide a reference 218 approach to compute loop-avoiding policies for link up, link metric 219 increase, link down, link metric decrease, node up, and node down 220 events. TI-LFA Repair Tunnel 222 4. Analysis 224 In this section, we review the main characteristics of the proposed 225 solution. These characteristics are illustrated in [3]. 227 4.1. Incremental Deployment 229 There is no requirement for a full network upgrade to get benefits 230 from the solution. 232 (1) Nodes that are upgraded bring benefit for the traffic passing 233 through them. 235 (2) Nodes that are not upgraded to support SR-based loop-avoidance 236 will cause the micro-loops that they were causing before, unless 237 they get avoided by the local behavior of a node supporting the 238 behavior. 240 4.2. No impact on capacity planning 242 By ensuring loop-free post-convergence paths, the behavior remains 243 in line with the natural expected convergence process of the IGP. 245 Enabling SR-based loop-avoidance hence does not require 246 consideration for capacity planning, compared to any loop avoidance 247 mechanism that lets traffic follow a different path than the post- 248 convergence one. The behavior is local. Nothing is expected from 249 remote nodes except the basic support of Prefix and Adjacency SID's. 251 5. Security Considerations 253 The behavior described in this document is internal functionality 254 to a router that result in the ability to explicitly steer traffic 255 over the post convergence path after a remote topology change in a 256 manner that guarantees loop freeness. Because the behavior serves 257 to minimize the disruption associated with a topology changes, it 258 can be seen as a modest security enhancement. 260 6. IANA Considerations 262 No requirements for IANA 264 7. Contributors 266 Additional contributors: Bruno Decraene and Peter Psenak. 268 8. References 270 8.1. Normative References 272 8.2. Informative References 274 [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and 275 Shakir, R., "Segment Routing Architecture", draft-ietf-spring- 276 segment-routing-11 (work in progress), November 2016. 278 [2] Shand, M. and Bryant, S., "IP Fast Reroute Framework", RFC 279 5714, January 2010. 281 [3] Litkowski, S., "Avoiding micro-loops using Segment Routing", 282 MPLS World Congress , 2016. 284 9. Acknowledgments 286 This document was prepared using 2-Word-v2.0.template.dot. 288 Authors' Addresses 290 Ahmed Bashandy 291 Individual 292 Email: abashandy.ietf@gmail.com 294 Clarence Filsfils 295 Cisco Systems 296 Brussels, Belgium 297 Email: cfilsfil@cisco.com 299 Stephane Litkowski 300 Cisco 301 Email: slitkows.ietf@gmail.com 303 Bruno Decraene 304 Orange 305 Email: bruno.decraene@orange.com 307 Pierre Francois 308 INSA Lyon 309 Email: pierre.francois@insa-lyon.fr 311 Peter Psenak 312 Cisco System 313 Email: ppsenak@cisco.com