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