idnits 2.17.1 draft-atlas-bryant-shand-lf-timers-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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 226. ** 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 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 (Jul 2005) is 6860 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 50, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-isis-caps-03 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Synch of Loop Free Timer Values Jul 2005 4 Network Working Group S. Bryant 5 Internet Draft M. Shand 6 Expiration Date: January 2006 Cisco Systems 8 A. Atlas 9 Google Inc 11 July 2005 13 Synchronisation of Loop Free Timer Values 14 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 41 This draft describes a mechanism that enables routers to agree on a 42 common convergence delay time for use in loop-free convergence. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 48 this document are to be interpreted as described in RFC 2119 49 [RFC2119]. 51 1. Introduction 53 Most of the loop-free convergence mechanisms [LFFWK] require one or 54 more convergence delay timers that MUST have a duration that is 55 consistent throughout the routing domain. This time is the worst 56 case time that any router will take to calculate the new topology, 57 and to make the necessary changes to the FIB. The timer is used by 58 the routers to know when it is safe to transition between the loop- 59 free convergence states. 61 The time taken by a router to complete each phase of the loop-free 62 transition will be dependent on the size of the network and the 63 design and implementation of the router. It can therefore be 64 expected that the optimum delay will need to be tuned from time to 65 time as the network evolves. 67 Manual configuration of the timer is fraught for two reasons, 68 firstly it is always difficult to ensure that the correct value is 69 installed in all of the routers, and secondly, if any change is 70 introduced into the network that results in a need to change the 71 timer, for example due to a change in hardware or software version, 72 then all of the routers need to be reconfigured to use the new 73 timer value. 75 It is therefore desirable that a means be provided by which the 76 convergence delay timer can be automatically synchronized 77 throughout the network. 79 2. Required Properties 81 The timer synchronization mechanism MUST have the following 82 properties: 84 o The convergence delay time must be consistent amongst all 85 routers that are converging on the new topology. 87 o The convergence delay time must be the highest delay required 88 by any router in the new topology. 90 o The mechanism must increase the delay when a new router in 91 introduced to the network that requires a higher delay than is 92 currently in use. 94 o When the router that had the longest delay requirements is 95 removed from the topology, the convergence delay timer value 96 must, within some reasonable time, be reduced to the longest 97 delay required by the remaining routers. 99 o It must be possible for a router to change the convergence 100 delay timer value that it requires. 102 o A router which is in multiple routing areas, or is running 103 multiple routing protocols may signal a different loop-free 104 convergence delay for each area, and for each protocol. 106 How a router determines the time that it needs to execute each 107 convergence phase is an implementation issue, and outside the scope 108 of this specification. However a router that dynamically determines 109 its proposed timer value must do so in such a way that it does not 110 cause the synchronized value to continually fluctuate. 112 3. Mechanism 114 The following mechanism is proposed. 116 A new information element is introduced into the routing protocol 117 that specifies the maximum time (in milliseconds) that the router 118 will take to calculate the new topology and to update its FIB as a 119 result of any topology change. 121 When a topology change occurs, the largest convergence delay time 122 required by any router in the new topology is used by the loop-free 123 convergence mechanism. 125 If a routing protocol message is issued that changes the 126 convergence delay timer value, but does not change the topology, 127 the new timer value MUST be taken into consideration during the 128 next loop-free transition, but MUST NOT instigate a loop-free 129 transition. 131 If a routing protocol message is issued that changes the 132 convergence timer value and changes the topology, a loop-free 133 transition is instigated and the new timer value is taken into 134 consideration. 136 The loop-free convergence mechanism should specify the action to be 137 taken if a timer change (only) message and a topology change 138 message are independently generated during the hold-off time. A 139 suitable action would be to take the same action that would be 140 taken if two uncorrelated topology changes occurred in the network. 142 All routers that support loop-free convergence MUST advertise a 143 loop-free convergence delay time. The loop-free convergence 144 mechanism MUST specify the action to be taken if a router does not 145 advertise a convergence delay time. 147 4. Protocol Details 149 This section describes the protocol changes needed to implement the 150 timer synchronization function. 152 4.1. ISIS 154 The controlled convergence timer value will be carried in a new 155 Sub-TLV of the capability TLV as defined in [ISIS-CAP]. 157 This draft defines one such SUB-TLV where the type is for the 158 worst-case FIB compute/install time, the value is 16 bits and is 159 specified in milliseconds; this gives a max value of about 65s. 161 The format of the Sub-TLV is as shown below. 163 Sub-TLV FIB-Convergence Timer 165 TYPE: 167 Length: 2 octets 169 Value: <16-bit timer value expressed in milliseconds> 171 This MUST be carried in a capability TLV with the S-bit set to zero 172 (indicating that it MUST NOT be leaked between levels). 174 4.2. OSPF 176 A new type-10 opaque LSA (the controlled convergence LSA) will be 177 defined as part of OSPF changed needed to define the loop-free 178 convergence mechanism. This will consist of one or more TLVs. This 179 draft defines one such TLV where the type is for the worst-case FIB 180 compute/install time, the value is 16 bits and is specified in 181 milliseconds; this gives a max value of about 65s. 183 5. IANA considerations 185 There will be IANA considerations that arise as a result of this 186 draft, but they are not yet determined. 188 6. Security Considerations 190 If an abnormally large timer value is proposed by a router, the 191 there is a danger that the loop-free convergence process will take 192 an excessive time. If during that time the routing protocol signals 193 the need for another transition, the loop-free transition will be 194 abandoned and the default best case (traditional) convergence 195 mechanism used. 197 It is still undesirable that the routers select a convergence delay 198 time that has an excessive value. The maximum value that can be 199 specified in the LSP/LSA is limited through the use of a 16 bit 200 field to about 65 seconds. When sufficient implementation 201 experience is gained, an architectural constant will be specified 202 which sets the upper limit of the convergence delay timer. 204 7. Intellectual Property Statement 206 The IETF takes no position regarding the validity or scope of any 207 Intellectual Property Rights or other rights that might be claimed 208 to pertain to the implementation or use of the technology described 209 in this document or the extent to which any license under such 210 rights might or might not be available; nor does it represent that 211 it has made any independent effort to identify any such rights. 212 Information on the procedures with respect to rights in RFC 213 documents can be found in BCP 78 and BCP 79. 215 Copies of IPR disclosures made to the IETF Secretariat and any 216 assurances of licenses to be made available, or the result of an 217 attempt made to obtain a general license or permission for the use 218 of such proprietary rights by implementers or users of this 219 specification can be obtained from the IETF on-line IPR repository 220 at http://www.ietf.org/ipr. 222 The IETF invites any interested party to bring to its attention any 223 copyrights, patents or patent applications, or other proprietary 224 rights that may cover technology that may be required to implement 225 this standard. Please address the information to the IETF at 226 ietf-ipr@ietf.org. 228 8. Full copyright statement 230 Copyright (C) The Internet Society (2005). This document is subject 231 to the rights, licenses and restrictions contained in BCP 78, and 232 except as set forth therein, the authors retain all their rights. 234 This document and the information contained herein are provided on 235 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 236 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 237 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 238 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 239 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 240 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 241 PARTICULAR PURPOSE. 243 9. Normative References 245 Internet-drafts are works in progress available from 246 248 [ISIS-CAP] Vasseur JP. et al, "IS-IS extensions for 249 advertising router information", draft-ietf- 250 isis-caps-03.txt , Work in Progress. 252 10. Informative References 254 Internet-drafts are works in progress available from 255 257 [LFFWK] Bryant, S., Shand, M., A Framework for Loop- 258 free Convergence , (work on progress) 261 11. Acknowledgements 263 Our thanks to Stefano Previdi for his useful coments. 265 12. Authors' Addresses 267 Alia K. Atlas 268 1600 Amphitheatre Parkway 269 Mountain View CA 94043 Email: akatlas@gmail.com 271 Stewart Bryant 272 Cisco Systems, 273 250, Longwater, 274 Green Park, 275 Reading, RG2 6GB, 276 United Kingdom. Email: stbryant@cisco.com 278 Mike Shand 279 Cisco Systems, 280 250, Longwater, 281 Green Park, 282 Reading, RG2 6GB, 283 United Kingdom. Email: mshand@cisco.com