idnits 2.17.1 draft-atlas-bryant-shand-lf-timers-02.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 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 223. ** 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 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 (October 2006) is 6396 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) == Outdated reference: A later version (-07) exists of draft-ietf-isis-caps-06 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Bryant 2 Internet Draft M. Shand 3 Expiration Date: May 2007 Cisco Systems 5 A. Atlas 6 Google Inc 8 October 2006 10 Synchronisation of Loop Free Timer Values 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 a mechanism that enables routers to agree on a 39 common convergence delay time for use in loop-free convergence. 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 1. Introduction 50 Most of the loop-free convergence mechanisms [LFFWK] require one or 51 more convergence delay timers that MUST have a duration that is 52 consistent throughout the routing domain. This time is the worst 53 case time that any router will take to calculate the new topology, 54 and to make the necessary changes to the FIB. The timer is used by 55 the routers to know when it is safe to transition between the loop- 56 free convergence states. 58 The time taken by a router to complete each phase of the loop-free 59 transition will be dependent on the size of the network and the 60 design and implementation of the router. It can therefore be 61 expected that the optimum delay will need to be tuned from time to 62 time as the network evolves. 64 Manual configuration of the timer is fraught for two reasons, 65 firstly it is always difficult to ensure that the correct value is 66 installed in all of the routers, and secondly, if any change is 67 introduced into the network that results in a need to change the 68 timer, for example due to a change in hardware or software version, 69 then all of the routers need to be reconfigured to use the new 70 timer value. 72 It is therefore desirable that a means be provided by which the 73 convergence delay timer can be automatically synchronized 74 throughout the network. 76 2. Required Properties 78 The timer synchronization mechanism MUST have the following 79 properties: 81 o The convergence delay time must be consistent amongst all 82 routers that are converging on the new topology. 84 o The convergence delay time must be the highest delay required 85 by any router in the new topology. 87 o The mechanism must increase the delay when a new router in 88 introduced to the network that requires a higher delay than is 89 currently in use. 91 o When the router that had the longest delay requirements is 92 removed from the topology, the convergence delay timer value 93 must, within some reasonable time, be reduced to the longest 94 delay required by the remaining routers. 96 o It must be possible for a router to change the convergence 97 delay timer value that it requires. 99 o A router which is in multiple routing areas, or is running 100 multiple routing protocols may signal a different loop-free 101 convergence delay for each area, and for each protocol. 103 How a router determines the time that it needs to execute each 104 convergence phase is an implementation issue, and outside the scope 105 of this specification. However a router that dynamically determines 106 its proposed timer value must do so in such a way that it does not 107 cause the synchronized value to continually fluctuate. 109 3. Mechanism 111 The following mechanism is proposed. 113 A new information element is introduced into the routing protocol 114 that specifies the maximum time (in milliseconds) that the router 115 will take to calculate the new topology and to update its FIB as a 116 result of any topology change. 118 When a topology change occurs, the largest convergence delay time 119 required by any router in the new topology is used by the loop-free 120 convergence mechanism. 122 If a routing protocol message is issued that changes the 123 convergence delay timer value, but does not change the topology, 124 the new timer value MUST be taken into consideration during the 125 next loop-free transition, but MUST NOT instigate a loop-free 126 transition. 128 If a routing protocol message is issued that changes the 129 convergence timer value and changes the topology, a loop-free 130 transition is instigated and the new timer value is taken into 131 consideration. 133 The loop-free convergence mechanism should specify the action to be 134 taken if a timer change (only) message and a topology change 135 message are independently generated during the hold-off time. A 136 suitable action would be to take the same action that would be 137 taken if two uncorrelated topology changes occurred in the network. 139 All routers that support loop-free convergence MUST advertise a 140 loop-free convergence delay time. The loop-free convergence 141 mechanism MUST specify the action to be taken if a router does not 142 advertise a convergence delay time. 144 4. Protocol Details 146 This section describes the protocol changes needed to implement the 147 timer synchronization function. 149 4.1. ISIS 151 The controlled convergence timer value will be carried in a new 152 Sub-TLV of the capability TLV as defined in [ISIS-CAP]. 154 This draft defines one such SUB-TLV where the type is for the 155 worst-case FIB compute/install time, the value is 16 bits and is 156 specified in milliseconds; this gives a max value of about 65s. 158 The format of the Sub-TLV is as shown below. 160 Sub-TLV FIB-Convergence Timer 162 TYPE: 164 Length: 2 octets 166 Value: <16-bit timer value expressed in milliseconds> 168 This MUST be carried in a capability TLV with the S-bit set to zero 169 (indicating that it MUST NOT be leaked between levels). 171 4.2. OSPF 173 A new type-10 opaque LSA (the controlled convergence LSA) will be 174 defined as part of OSPF changed needed to define the loop-free 175 convergence mechanism. This will consist of one or more TLVs. This 176 draft defines one such TLV where the type is for the worst-case FIB 177 compute/install time, the value is 16 bits and is specified in 178 milliseconds; this gives a max value of about 65s. 180 5. IANA considerations 182 There will be IANA considerations that arise as a result of this 183 draft, but they are not yet determined. 185 6. Security Considerations 187 If an abnormally large timer value is proposed by a router, the 188 there is a danger that the loop-free convergence process will take 189 an excessive time. If during that time the routing protocol signals 190 the need for another transition, the loop-free transition will be 191 abandoned and the default best case (traditional) convergence 192 mechanism used. 194 It is still undesirable that the routers select a convergence delay 195 time that has an excessive value. The maximum value that can be 196 specified in the LSP/LSA is limited through the use of a 16 bit 197 field to about 65 seconds. When sufficient implementation 198 experience is gained, an architectural constant will be specified 199 which sets the upper limit of the convergence delay timer. 201 7. Intellectual Property Statement 203 The IETF takes no position regarding the validity or scope of any 204 Intellectual Property Rights or other rights that might be claimed 205 to pertain to the implementation or use of the technology described 206 in this document or the extent to which any license under such 207 rights might or might not be available; nor does it represent that 208 it has made any independent effort to identify any such rights. 209 Information on the procedures with respect to rights in RFC 210 documents can be found in BCP 78 and BCP 79. 212 Copies of IPR disclosures made to the IETF Secretariat and any 213 assurances of licenses to be made available, or the result of an 214 attempt made to obtain a general license or permission for the use 215 of such proprietary rights by implementers or users of this 216 specification can be obtained from the IETF on-line IPR repository 217 at http://www.ietf.org/ipr. 219 The IETF invites any interested party to bring to its attention any 220 copyrights, patents or patent applications, or other proprietary 221 rights that may cover technology that may be required to implement 222 this standard. Please address the information to the IETF at 223 ietf-ipr@ietf.org. 225 8. Full copyright statement 227 Copyright (C) The Internet Society (2006). This document is subject 228 to the rights, licenses and restrictions contained in BCP 78, and 229 except as set forth therein, the authors retain all their rights. 231 This document and the information contained herein are provided on 232 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 233 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 234 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 235 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 236 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 237 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 238 PARTICULAR PURPOSE. 240 9. Normative References 242 Internet-drafts are works in progress available from 243 245 [ISIS-CAP] Vasseur JP. et al, "IS-IS extensions for 246 advertising router information", draft-ietf- 247 isis-caps-06.txt , Work in Progress. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to 250 Indicate Requirement Levels", BCP 14, RFC 251 2119, March 1997. 253 10. Informative References 255 Internet-drafts are works in progress available from 256 258 [LFFWK] Bryant, S., Shand, M., A Framework for Loop- 259 free Convergence , (work on progress) 262 11. Acknowledgements 264 Our thanks to Stefano Previdi for his useful coments. 266 12. Authors' Addresses 268 Alia K. Atlas 269 1600 Amphitheatre Parkway 270 Mountain View CA 94043 Email: akatlas@gmail.com 272 Stewart Bryant 273 Cisco Systems, 274 250, Longwater, 275 Green Park, 276 Reading, RG2 6GB, 277 United Kingdom. Email: stbryant@cisco.com 279 Mike Shand 280 Cisco Systems, 281 250, Longwater, 282 Green Park, 283 Reading, RG2 6GB, 284 United Kingdom. Email: mshand@cisco.com