idnits 2.17.1 draft-bryant-shand-lf-applicability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 272. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 3) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jun 2005) is 6882 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) == Missing Reference: 'RFC2119' is mentioned on line 47, but not defined -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT A Framework for Loop-free Convergence Jun 2005 4 Network Working Group S. Bryant 5 Internet Draft M. Shand 6 Expiration Date: Dec 2005 Cisco Systems 8 Jun 2005 10 Applicability of Loop-free Convergence 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 38 This draft describes the applicability of loop free convergence 39 technologies to a number of network applications. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 45 this document are to be interpreted as described in RFC 2119 46 [RFC2119]. 48 Table of Contents 49 1. Introduction........................................................3 51 2. Applicability.......................................................4 52 2.1. Component Failure...............................................4 53 2.2. Component Repair................................................4 54 2.3. Management withdrawal of a component............................5 55 2.4. Management Insertion of a Component.............................5 56 2.5. Management Change of a Link Cost................................5 57 2.6. External Cost Change............................................5 58 2.7. MPLS Applicability..............................................6 59 2.8. Routing Vector and Path Vector Convergence......................6 60 3. IANA considerations.................................................6 62 4. Security Considerations.............................................6 64 5. Intellectual Property Statement.....................................6 66 6. Full copyright statement............................................7 68 7. Normative References................................................7 70 8. Informative References..............................................7 72 9. Authors' Addresses..................................................8 73 1. Introduction 75 When there is a change to the network topology (due to the failure 76 or restoration of a link or router, or as a result of management 77 action) the routers need to converge on a common view of the new 78 topology, and the paths to be used for forwarding traffic to each 79 destination. During this process, referred to as a routing 80 transition, packet delivery between certain source/destination 81 pairs may be disrupted. This occurs due to the time it takes for 82 the topology change to be propagated around the network together 83 with the time it takes each individual router to determine and then 84 update the forwarding information base (FIB) for the affected 85 destinations. During this transition, packets are lost due to the 86 continuing attempts to use of the failed component, and due to 87 forwarding loops. Forwarding loops arise due to the inconsistent 88 FIBs that occur as a result of the difference in time taken by 89 routers to execute the transition process. This is a problem that 90 occurs in both IP networks and MPLS networks that use LDP [RFC3036] 91 as the label switched path (LSP) signaling protocol. 93 The service failures caused by routing transitions are largely 94 hidden by higher-level protocols that retransmit the lost data. 95 However new Internet services are emerging which are more sensitive 96 to the packet disruption that occurs during a transition. To make 97 the transition transparent to their users, these services require a 98 short routing transition. Ideally, routing transitions would be 99 completed in zero time with no packet loss. 101 Regardless of how optimally the mechanisms involved have been 102 designed and implemented, it is inevitable that a routing 103 transition will take some minimum interval that is greater than 104 zero. This has led to the development of a TE fast-reroute 105 mechanism for MPLS [MPLS-TE]. Alternative mechanisms that might be 106 deployed in an MPLS network and mechanisms that may be used in an 107 IP network are work in progress in the IETF [IPFRR]. Any repair 108 mechanism may however be disrupted by the formation of micro-loops 109 during the period between the time when the failure is announced, 110 and the time when all FIBs have been updated to reflect the new 111 topology. 113 This disruptive effect of micro-loops led the IP fast re-route 114 designers to develop mechanisms to control the re-convergence of 115 networks in order to prevent disruption of the repair and 116 collateral damage to other traffic in the network [LFFWK],[ZININ]. 118 The purpose of this note is to draw the attention of the IETF 119 community to the more general nature of the micro-looping problem, 120 and the wider applicability of loop-free convergence technology. 122 2. Applicability 124 Loop free convergence strategies are applicable to any problem in 125 which inconsistency in the FIB causes the formation of micro-loops. 127 For example the convergence of a network following: 129 1) Component failure. 131 2) Component repair. 133 3) Management withdrawal of a component. 135 4) Management insertion or a component. 137 5) Management change of link cost (either positive or negative). 139 6) External cost change, for example change of external gateway as 140 a result of a BGP change. 142 7) An SRLG failure. 144 In each case, a component may be a link or a router. 146 2.1. Component Failure 148 When fast-reroute is used to provide the temporary repair of a 149 failed component, the use of a loop-free convergence mechanism 150 enables the re-convergence of the network without additional packet 151 loss caused by starvation or micro-looping as a result of 152 inconsistent FIBs. 154 The need for loop-free convergence was first appreciated during the 155 design of IP fast reroute. However the mechanism is also applicable 156 to the case where an MPLS-TE tunnel is used to provide a link or 157 node repair within an MPLS network where LDP is used to distribute 158 labels. 160 Except in special circumstances, controlled convergence in the 161 presence of component failure should only be used when a temporary 162 repair is available. This is because controlled convergence is 163 always slower than uncontrolled (traditional) convergence, and 164 would result in an extended period of traffic lost as a result of 165 the failure if there were no other means of delivering the traffic. 167 2.2. Component Repair 169 Micro-loops may form when a component is (re)introduced into a 170 network. All of the known loop-free convergence methods are capable 171 of avoiding such micro-loops. It is not necessary to employ any 172 repair mechanism to take advantage of this facility, because the 173 new component may be used to provide connectivity before its 174 presence is made known to the rest of the network. 176 2.3. Management withdrawal of a component 178 From the perspective of the routing protocol, management withdrawal 179 of a component is indistinguishable from an unexpected component 180 failure, and will be subject to the same micro-loops. The network 181 will therefore benefit from the use of a micro-loop prevention 182 mechanism. 184 Unlike the failure case the component being withdrawn may be used 185 to forward packets during the transition, and therefore no repair 186 mechanism is needed. 188 Unlike the case of component failure or repair, management 189 withdrawal of a component is normally not time critical. 190 Consideration may therefore be given to the use of the incremental 191 cost change loop-free convergence mechanism. This mechanism was 192 discarded as a candidate in the case of fast re-route because of 193 its slow time to converge, however it is a mechanism that is 194 backwards compatible with existing routers and may therefore be of 195 use in this application. 197 2.4. Management Insertion of a Component 199 From the perspective of the routing protocol, management insertion 200 of a component is indistinguishable from component repair, and will 201 be subject to the same micro-loops. The network will therefore 202 benefit from the use of a micro-loop prevention mechanism. No 203 repair mechanism is needed and is not normally time critical. 205 2.5. Management Change of a Link Cost 207 Component failure and component repair are extreme examples of cost 208 change. Micro-loops may also form when a link cost is changed (in 209 either direction) during the process of network re-configuration. 210 The use of a loop-free convergence technique prevents the formation 211 of micro-loops during this otherwise benign process. No repair 212 mechanism is needed in this case, because the link is still 213 available for use. 215 2.6. External Cost Change 217 An external cost change can result in a change to the preferred 218 external route to a destination. Micro-loops may form during the 219 process of switching from the old boarder router to the new one. 220 The loop-free control of this change will prevent the loss of 221 packets during this network transition. 223 2.7. MPLS Applicability 225 Where the network is an MPLS enabled network using the LDP protocol 226 to learn labels, and fast re-route is provided through the use of 227 single hop MPLS-TE tunnels protected by MPLS-TE fast reroute, micro 228 loops may form during convergence. Loop free convergence is 229 therefore applicable to this network configuration. 231 2.8. Routing Vector and Path Vector Convergence 233 The work to date on controlled convergence has focused on link 234 state IGPs. The ability to control the convergence of routing 235 vector and path vector routing protocols would also be useful tools 236 in the management of the Internet. 238 At the time of writing however no suitable mechanism has been 239 proposed. 241 3. IANA considerations 243 There are no IANA considerations that arise from this draft. 245 4. Security Considerations 247 All micro-loop control mechanisms raise significant security issues 248 which must be addressed in their detailed technical description. 250 5. Intellectual Property Statement 252 The IETF takes no position regarding the validity or scope of any 253 Intellectual Property Rights or other rights that might be claimed 254 to pertain to the implementation or use of the technology described 255 in this document or the extent to which any license under such 256 rights might or might not be available; nor does it represent that 257 it has made any independent effort to identify any such rights. 258 Information on the procedures with respect to rights in RFC 259 documents can be found in BCP 78 and BCP 79. 261 Copies of IPR disclosures made to the IETF Secretariat and any 262 assurances of licenses to be made available, or the result of an 263 attempt made to obtain a general license or permission for the use 264 of such proprietary rights by implementers or users of this 265 specification can be obtained from the IETF on-line IPR repository 266 at http://www.ietf.org/ipr. 268 The IETF invites any interested party to bring to its attention any 269 copyrights, patents or patent applications, or other proprietary 270 rights that may cover technology that may be required to implement 271 this standard. Please address the information to the IETF at 272 ietf-ipr@ietf.org. 274 6. Full copyright statement 276 Copyright (C) The Internet Society (2005). This document is subject 277 to the rights, licenses and restrictions contained in BCP 78, and 278 except as set forth therein, the authors retain all their rights. 280 This document and the information contained herein are provided on 281 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 282 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 283 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 284 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 285 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 286 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 287 PARTICULAR PURPOSE. 289 7. Normative References 291 There are no normative references. 293 8. Informative References 295 Internet-drafts are works in progress available from 296 298 [IPFRR] Shand, M., "IP Fast-reroute Framework", 299 , June 300 2004, (work in progress). 302 [RFC3036] Andersson, L., Doolan, P., Feldman, N., 303 Fredette, A. and B. Thomas, "LDP 304 Specification", RFC 3036, 305 January 2001. 307 [MPLS-TE] Ping Pan, et al, "Fast Reroute Extensions to 308 RSVP-TE for LSP Tunnels", 309 , 310 (work in progress). 312 [LFFWK] Bryant, S., Shand, M., A Framework for Loop- 313 free Convergence , (work on progress) 316 [ZININ] Zinin, A., "Analysis and Minimization of 317 Microloops in Link-state Routing Protocols", 318 , May 319 2005 (work in progress). 321 9. Authors' Addresses 323 Mike Shand 324 Cisco Systems, 325 250, Longwater, 326 Green Park, 327 Reading, RG2 6GB, 328 United Kingdom. Email: mshand@cisco.com 330 Stewart Bryant 331 Cisco Systems, 332 250, Longwater, 333 Green Park, 334 Reading, RG2 6GB, 335 United Kingdom. Email: stbryant@cisco.com