idnits 2.17.1 draft-atlas-bryant-shand-lf-timers-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 297. 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 (July 5, 2007) is 6133 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Atlas 3 Internet-Draft Google Inc. 4 Intended status: Standards Track S. Bryant 5 Expires: January 6, 2008 M. Shand 6 Cisco Systems 7 July 5, 2007 9 Synchronisation of Loop Free Timer Values 10 draft-atlas-bryant-shand-lf-timers-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 6, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This draft describes a mechanism that enables routers to agree on a 44 common convergence delay time for use in loop-free convergence. 46 Requirements Language 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC2119 [RFC2119]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Required Properties . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Intellectual Property and Copyright Statements . . . . . . . . . . 8 68 1. Introduction 70 Most of the loop-free convergence mechanisms 71 [I-D.bryant-shand-lf-conv-frmwk] require one or more convergence 72 delay timers that MUST have a duration that is consistent throughout 73 the routing domain. This time is the worst case time that any router 74 will take to calculate the new topology, and to make the necessary 75 changes to the FIB. The timer is used by the routers to know when it 76 is safe to transition between the loop- free convergence states. 78 The time taken by a router to complete each phase of the loop-free 79 transition will be dependent on the size of the network and the 80 design and implementation of the router. It can therefore be 81 expected that the optimum delay will need to be tuned from time to 82 time as the network evolves. 84 Manual configuration of the timer is fraught for two reasons, firstly 85 it is always difficult to ensure that the correct value is installed 86 in all of the routers, and secondly, if any change is introduced into 87 the network that results in a need to change the timer, for example 88 due to a change in hardware or software version, then all of the 89 routers need to be reconfigured to use the new timer value. 91 It is therefore desirable that a means be provided by which the 92 convergence delay timer can be automatically synchronized throughout 93 the network. 95 2. Required Properties 97 The timer synchronization mechanism MUST have the following 98 properties: 100 o The convergence delay time must be consistent amongst all 101 routers that are converging on the new topology. 103 o The convergence delay time must be the highest delay required by 104 any router in the new topology. 106 o The mechanism must increase the delay when a new router in 107 introduced to the network that requires a higher delay than is 108 currently in use. 110 o When the router that had the longest delay requirements is 111 removed from the topology, the convergence delay timer value must, 112 within some reasonable time, be reduced to the longest delay 113 required by the remaining routers. 115 o It must be possible for a router to change the convergence delay 116 timer value that it requires. 118 o A router which is in multiple routing areas, or is running 119 multiple routing protocols may signal a different loop-free 120 convergence delay for each area, and for each protocol. 122 How a router determines the time that it needs to execute each 123 convergence phase is an implementation issue, and outside the scope 124 of this specification. However a router that dynamically determines 125 its proposed timer value must do so in such a way that it does not 126 cause the synchronized value to continually fluctuate. 128 3. Mechanism 130 The following mechanism is proposed. 132 A new information element is introduced into the routing protocol 133 that specifies the maximum time (in milliseconds) that the router 134 will take to calculate the new topology and to update its FIB as a 135 result of any topology change. 137 When a topology change occurs, the largest convergence delay time 138 required by any router in the new topology is used by the loop-free 139 convergence mechanism. 141 If a routing protocol message is issued that changes the convergence 142 delay timer value, but does not change the topology, the new timer 143 value MUST be taken into consideration during the next loop-free 144 transition, but MUST NOT instigate a loop-free transition. 146 If a routing protocol message is issued that changes the convergence 147 timer value and changes the topology, a loop-free transition is 148 instigated and the new timer value is taken into consideration. 150 The loop-free convergence mechanism should specify the action to be 151 taken if a timer change (only) message and a topology change message 152 are independently generated during the hold-off time. A suitable 153 action would be to take the same action that would be taken if two 154 uncorrelated topology changes occurred in the network. 156 All routers that support loop-free convergence MUST advertise a loop- 157 free convergence delay time. The loop-free convergence mechanism 158 MUST specify the action to be taken if a router does not advertise a 159 convergence delay time. 161 4. Protocol Details 163 This section describes the protocol changes needed to implement the 164 timer synchronization function. 166 4.1. ISIS 168 The controlled convergence timer value will be carried in a new Sub- 169 TLV of the capability TLV as defined in [I-D.ietf-isis-caps] . 171 This draft defines one such SUB-TLV where the type is for the worst- 172 case FIB compute/install time, the value is 16 bits and is specified 173 in milliseconds; this gives a max value of about 65s. 175 The format of the Sub-TLV is as shown below. 177 Sub-TLV FIB-Convergence Timer 179 TYPE: 181 Length: 2 octets 183 Value: <16-bit timer value expressed in milliseconds> 185 This MUST be carried in a capability TLV with the S-bit set to zero 186 (indicating that it MUST NOT be leaked between levels). 188 4.2. OSPF 190 A new type-10 opaque LSA (the controlled convergence LSA) will be 191 defined as part of OSPF changed needed to define the loop-free 192 convergence mechanism. This will consist of one or more TLVs. This 193 draft defines one such TLV where the type is for the worst-case FIB 194 compute/install time, the value is 16 bits and is specified in 195 milliseconds; this gives a max value of about 65s. 197 5. IANA considerations 199 There will be IANA considerations that arise as a result of this 200 draft, but they are not yet determined. 202 6. Security Considerations 204 If an abnormally large timer value is proposed by a router, the there 205 is a danger that the loop-free convergence process will take an 206 excessive time. If during that time the routing protocol signals the 207 need for another transition, the loop-free transition will be 208 abandoned and the default best case (traditional) convergence 209 mechanism used. 211 It is still undesirable that the routers select a convergence delay 212 time that has an excessive value. The maximum value that can be 213 specified in the LSP/LSA is limited through the use of a 16 bit field 214 to about 65 seconds. When sufficient implementation experience is 215 gained, an architectural constant will be specified which sets the 216 upper limit of the convergence delay timer. 218 7. References 220 7.1. Normative References 222 [I-D.ietf-isis-caps] 223 Vasseur, J., "IS-IS Extensions for Advertising Router 224 Information", draft-ietf-isis-caps-07 (work in progress), 225 February 2007. 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 7.2. Informative References 232 [I-D.bryant-shand-lf-conv-frmwk] 233 Bryant, S. and M. Shand, "A Framework for Loop-free 234 Convergence", draft-bryant-shand-lf-conv-frmwk-03 (work in 235 progress), October 2006. 237 Authors' Addresses 239 Alia K, Atlas 240 Google Inc. 241 1600 Amphitheatre Parkway 242 Mountain View CA 94043 244 Email: akatlas@gmail.com 245 Stewart Bryant 246 Cisco Systems 247 250, Longwater Ave, 248 Reading, RG2 6GB, 249 UK 251 Email: stbryant@cisco.com 253 Mike Shand 254 Cisco Systems 255 250, Longwater Ave, 256 Reading, RG2 6GB, 257 UK 259 Full Copyright Statement 261 Copyright (C) The IETF Trust (2007). 263 This document is subject to the rights, licenses and restrictions 264 contained in BCP 78, and except as set forth therein, the authors 265 retain all their rights. 267 This document and the information contained herein are provided on an 268 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 269 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 270 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 271 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 272 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 273 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 275 Intellectual Property 277 The IETF takes no position regarding the validity or scope of any 278 Intellectual Property Rights or other rights that might be claimed to 279 pertain to the implementation or use of the technology described in 280 this document or the extent to which any license under such rights 281 might or might not be available; nor does it represent that it has 282 made any independent effort to identify any such rights. Information 283 on the procedures with respect to rights in RFC documents can be 284 found in BCP 78 and BCP 79. 286 Copies of IPR disclosures made to the IETF Secretariat and any 287 assurances of licenses to be made available, or the result of an 288 attempt made to obtain a general license or permission for the use of 289 such proprietary rights by implementers or users of this 290 specification can be obtained from the IETF on-line IPR repository at 291 http://www.ietf.org/ipr. 293 The IETF invites any interested party to bring to its attention any 294 copyrights, patents or patent applications, or other proprietary 295 rights that may cover technology that may be required to implement 296 this standard. Please address the information to the IETF at 297 ietf-ipr@ietf.org. 299 Acknowledgment 301 Funding for the RFC Editor function is provided by the IETF 302 Administrative Support Activity (IASA).