idnits 2.17.1 draft-bryant-shand-lf-applicability-06.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 333. 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 Copyright Line does not match the current year -- 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 (October 30, 2008) is 5649 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-ipfrr-framework-08 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant 3 Internet-Draft M. Shand 4 Intended status: Informational Cisco Systems 5 Expires: May 3, 2009 October 30, 2008 7 Applicability of Loop-free Convergence 8 draft-bryant-shand-lf-applicability-06 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 3, 2009. 35 Abstract 37 This draft describes the applicability of loop free convergence 38 technologies to a number of network applications. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 4 44 2.1. Component Failure . . . . . . . . . . . . . . . . . . . . . 4 45 2.2. Component Repair . . . . . . . . . . . . . . . . . . . . . 5 46 2.3. Managing withdrawal of a component . . . . . . . . . . . . 5 47 2.4. Managing Insertion of a Component . . . . . . . . . . . . . 5 48 2.5. Managing Change of a Link Cost . . . . . . . . . . . . . . 5 49 2.6. External Cost Change . . . . . . . . . . . . . . . . . . . 6 50 2.7. MPLS Applicability . . . . . . . . . . . . . . . . . . . . 6 51 2.8. Routing Vector and Path Vector Convergence . . . . . . . . 6 52 3. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 7 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 54 5. Informative References . . . . . . . . . . . . . . . . . . . . 7 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 56 Intellectual Property and Copyright Statements . . . . . . . . . . 9 58 1. Introduction 60 When there is a change to the network topology (due to the failure or 61 restoration of a link or router, or as a result of management action) 62 the routers need to converge on a common view of the new topology, 63 and the paths to be used for forwarding traffic to each destination. 64 During this process, referred to as a routing transition, packet 65 delivery between certain source/destination pairs may be disrupted. 66 This occurs due to the time it takes for the topology change to be 67 propagated around the network together with the time it takes each 68 individual router to determine and then update the forwarding 69 information base (FIB) for the affected destinations. During this 70 transition, packets may be lost due to the continuing attempts to use 71 the failed component, and/or due to forwarding loops. Forwarding 72 loops arise due to the inconsistent FIBs that occur as a result of 73 the difference in time taken by routers to execute the transition 74 process. This is a problem that occurs in both IP networks and MPLS 75 networks that use LDP [RFC5036] as the label switched path (LSP) 76 signaling protocol. 78 The service failures caused by routing transitions are largely hidden 79 by higher-level protocols that retransmit the lost data. However new 80 Internet services are emerging which are more sensitive to the packet 81 disruption that occurs during a transition. To make the transition 82 transparent to their users, these services require a short routing 83 transition. Ideally, routing transitions would be completed in zero 84 time with no packet loss. 86 Regardless of how optimally the mechanisms involved have been 87 designed and implemented, it is inevitable that a routing transition 88 will take some minimum interval that is greater than zero. This has 89 led to the development of a TE fast-reroute mechanism for MPLS 90 [RFC4090]. Alternative mechanisms that might be deployed in an MPLS 91 network and mechanisms that may be used in an IP network are work in 92 progress in the IETF [I-D.ietf-rtgwg-ipfrr-framework] . Any repair 93 mechanism may however be disrupted by the formation of micro-loops 94 during the period between the time when the failure is announced, and 95 the time when all FIBs have been updated to reflect the new topology. 97 This disruptive effect of micro-loops led the IP fast re-route 98 designers to develop mechanisms to control the re-convergence of 99 networks in order to prevent disruption of the repair and collateral 100 damage to other traffic in the network 101 [I-D.bryant-shand-lf-conv-frmwk], 102 [I-D.ietf-rtgwg-microloop-analysis]. 104 The purpose of this note is to draw the attention of the IETF 105 community to the more general nature of the micro-looping problem, 106 and the wider applicability of loop-free convergence technology. 108 2. Applicability 110 Loop free convergence strategies are applicable to any problem in 111 which inconsistency in the FIB causes the formation of micro-loops. 113 For example, the convergence of a network following: 115 1) Component failure. 117 2) Component repair. 119 3) Managing withdrawal of a component. 121 4) Managing insertion or a component. 123 5) Management change of link cost (either positive or negative). 125 6) External cost change, for example change of external gateway as 126 a result of a BGP change. 128 7) A shared risk link group (SRLG) failure. 130 In each case, a component may be a link or a router. 132 2.1. Component Failure 134 When fast-reroute is used to provide the temporary repair of a failed 135 component, the use of a loop-free convergence mechanism enables the 136 re-convergence of the network to be performed without additional 137 packet loss caused by starvation or micro-looping. 139 The need for loop-free convergence was first appreciated during the 140 design of IP fast reroute. However the mechanism is also applicable 141 to the case where an MPLS-TE tunnel is used to provide a link or node 142 repair within an MPLS network where LDP is used to distribute labels. 144 Except in special circumstances, controlled convergence in the 145 presence of component failure should only be used when a temporary 146 repair is available. This is because controlled convergence is 147 always slower than uncontrolled (traditional) convergence, and would 148 result in an extended period of traffic lost as a result of the 149 failure if there were no other means of delivering the traffic. 151 2.2. Component Repair 153 Micro-loops may form when a component is (re)introduced into a 154 network. All of the known loop-free convergence methods are capable 155 of avoiding such micro-loops. It is not necessary to employ any 156 repair mechanism to take advantage of this facility, because the new 157 component may be used to provide connectivity before its presence is 158 made known to the rest of the network. 160 2.3. Managing withdrawal of a component 162 From the perspective of the routing protocol, management withdrawal 163 of a component is indistinguishable from an unexpected component 164 failure, and will be subject to the same micro-loops. The network 165 will therefore benefit from the use of a micro-loop prevention 166 mechanism. 168 Unlike the failure case, the component being withdrawn may be used to 169 forward packets during the transition, and therefore no repair 170 mechanism is needed. 172 Unlike the case of component failure or repair, management withdrawal 173 of a component is normally not time critical. Consideration may 174 therefore be given to the use of the incremental cost change loop- 175 free convergence mechanism. This mechanism was discarded as a 176 candidate in the case of fast re-route because of its slow time to 177 converge, however it is a mechanism that is backwards compatible with 178 existing routers and may therefore be of use in this application. 179 Note that unlike any of the other mechanism described here, this 180 technique can be used without modification to ANY router in the 181 network. 183 2.4. Managing Insertion of a Component 185 From the perspective of the routing protocol, management insertion of 186 a component is indistinguishable from component repair, and will be 187 subject to the same micro-loops. The network will therefore benefit 188 from the use of a micro-loop prevention mechanism. No repair 189 mechanism is needed and it is not normally time critical. 191 2.5. Managing Change of a Link Cost 193 Component failure and component repair are extreme examples of cost 194 change. Micro-loops may also form when a link cost is changed (in 195 either direction) during the process of network re-configuration. 196 The use of a loop-free convergence technique prevents the formation 197 of micro-loops during this otherwise benign process. No repair 198 mechanism is needed in this case, because the link is still available 199 for use. 201 2.6. External Cost Change 203 An external cost change can result in a change to the preferred 204 external route to a destination. Micro-loops may form during the 205 process of switching from the old border router to the new one. The 206 loop-free control of this change will prevent the loss of packets 207 during this network transition. 209 2.7. MPLS Applicability 211 Where the network is an MPLS enabled network using the LDP protocol 212 to learn labels, and fast re-route is provided through the use of 213 single hop MPLS-TE tunnels protected by MPLS-TE fast reroute, micro 214 loops may form during convergence. Loop free convergence is 215 therefore applicable to this network configuration. 217 2.8. Routing Vector and Path Vector Convergence 219 The work to date on controlled convergence has focused on link state 220 IGPs. The ability to control the convergence of routing vector and 221 path vector routing protocols would also be useful tools in the 222 management of the Internet. 224 Routing vector convergence may be controlled by incrementally 225 changing the link cost one unit at a time and waiting for the network 226 to converge. In link state routing protocols employing wide metrics 227 such a solution would normally be considered as too slow to deploy, 228 although recent work on optimizing the number of increments has 229 significantly improved the convergence time. In the case of distance 230 vector routing protocols the much smaller maximum metric makes this 231 more tractable, provided that is, the per metric change convergence 232 time is considered acceptable. 234 Similarly with path vector routing protocols the path length can be 235 incrementally padded. Since practical path vector routing protocols 236 which use path length as an input to the routing decision are 237 equivalent to using the hop count as a metric (i.e. the maximum per 238 hop metric is one ,or in special cases a very small number) the 239 number of increments needed is limited to the length of the path 240 around the failure. This property may make this a tractable 241 approach. [I-D.bryant-shand-lf-conv-frmwk] (Section 5.1), although 242 the per change convergence time may still be a significant concern. 244 3. IANA considerations 246 There are no IANA considerations that arise from this draft. 248 4. Security Considerations 250 All micro-loop control mechanisms raise significant security issues 251 which must be addressed in their detailed technical description. 253 5. Informative References 255 [I-D.bryant-shand-lf-conv-frmwk] 256 Bryant, S. and M. Shand, "A Framework for Loop-free 257 Convergence", draft-bryant-shand-lf-conv-frmwk-03 (work in 258 progress), October 2006. 260 [I-D.ietf-rtgwg-ipfrr-framework] 261 Shand, M. and S. Bryant, "IP Fast Reroute Framework", 262 draft-ietf-rtgwg-ipfrr-framework-08 (work in progress), 263 February 2008. 265 [I-D.ietf-rtgwg-microloop-analysis] 266 Zinin, A., "Analysis and Minimization of Microloops in 267 Link-state Routing Protocols", 268 draft-ietf-rtgwg-microloop-analysis-01 (work in progress), 269 October 2005. 271 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 272 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 273 May 2005. 275 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 276 Specification", RFC 5036, October 2007. 278 Authors' Addresses 280 Stewart Bryant 281 Cisco Systems 282 250, Longwater, Green Park, 283 Reading RG2 6GB, UK 284 UK 286 Email: stbryant@cisco.com 287 Mike Shand 288 Cisco Systems 289 250, Longwater, Green Park, 290 Reading RG2 6GB, UK 291 UK 293 Email: mshand@cisco.com 295 Full Copyright Statement 297 Copyright (C) The IETF Trust (2008). 299 This document is subject to the rights, licenses and restrictions 300 contained in BCP 78, and except as set forth therein, the authors 301 retain all their rights. 303 This document and the information contained herein are provided on an 304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 306 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 307 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 308 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 311 Intellectual Property 313 The IETF takes no position regarding the validity or scope of any 314 Intellectual Property Rights or other rights that might be claimed to 315 pertain to the implementation or use of the technology described in 316 this document or the extent to which any license under such rights 317 might or might not be available; nor does it represent that it has 318 made any independent effort to identify any such rights. Information 319 on the procedures with respect to rights in RFC documents can be 320 found in BCP 78 and BCP 79. 322 Copies of IPR disclosures made to the IETF Secretariat and any 323 assurances of licenses to be made available, or the result of an 324 attempt made to obtain a general license or permission for the use of 325 such proprietary rights by implementers or users of this 326 specification can be obtained from the IETF on-line IPR repository at 327 http://www.ietf.org/ipr. 329 The IETF invites any interested party to bring to its attention any 330 copyrights, patents or patent applications, or other proprietary 331 rights that may cover technology that may be required to implement 332 this standard. Please address the information to the IETF at 333 ietf-ipr@ietf.org.