idnits 2.17.00 (12 Aug 2021) /tmp/idnits33453/draft-atlas-bryant-shand-lf-timers-04.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 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 293. 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 (February 14, 2008) is 5203 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: draft-ietf-isis-caps has been published as RFC 4971 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 A. Atlas 3 Internet-Draft BT 4 Intended status: Standards Track S. Bryant 5 Expires: August 17, 2008 M. Shand 6 Cisco Systems 7 February 14, 2008 9 Synchronisation of Loop Free Timer Values 10 draft-atlas-bryant-shand-lf-timers-04 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 August 17, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 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 [1]. 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 [3] require one or more 71 convergence delay timers that MUST have a duration that is consistent 72 throughout the routing domain. This time is the worst case time that 73 any router will take to calculate the new topology, and to make the 74 necessary changes to the FIB. The timer is used by the routers to 75 know when it is safe to transition between the loop- free convergence 76 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 [2] . 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 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 223 Levels", BCP 14, RFC 2119, March 1997. 225 [2] Vasseur, J., "IS-IS Extensions for Advertising Router 226 Information", draft-ietf-isis-caps-07 (work in progress), 227 February 2007. 229 7.2. Informative References 231 [3] Bryant, S. and M. Shand, "A Framework for Loop-free 232 Convergence", draft-bryant-shand-lf-conv-frmwk-03 (work in 233 progress), October 2006. 235 Authors' Addresses 237 Alia K, Atlas 238 BT 240 Email: akatlas@bt.com 242 Stewart Bryant 243 Cisco Systems 244 250, Longwater Ave, 245 Reading, RG2 6GB, 246 UK 248 Email: stbryant@cisco.com 249 Mike Shand 250 Cisco Systems 251 250, Longwater Ave, 252 Reading, RG2 6GB, 253 UK 255 Full Copyright Statement 257 Copyright (C) The IETF Trust (2008). 259 This document is subject to the rights, licenses and restrictions 260 contained in BCP 78, and except as set forth therein, the authors 261 retain all their rights. 263 This document and the information contained herein are provided on an 264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 266 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 267 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 268 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 271 Intellectual Property 273 The IETF takes no position regarding the validity or scope of any 274 Intellectual Property Rights or other rights that might be claimed to 275 pertain to the implementation or use of the technology described in 276 this document or the extent to which any license under such rights 277 might or might not be available; nor does it represent that it has 278 made any independent effort to identify any such rights. Information 279 on the procedures with respect to rights in RFC documents can be 280 found in BCP 78 and BCP 79. 282 Copies of IPR disclosures made to the IETF Secretariat and any 283 assurances of licenses to be made available, or the result of an 284 attempt made to obtain a general license or permission for the use of 285 such proprietary rights by implementers or users of this 286 specification can be obtained from the IETF on-line IPR repository at 287 http://www.ietf.org/ipr. 289 The IETF invites any interested party to bring to its attention any 290 copyrights, patents or patent applications, or other proprietary 291 rights that may cover technology that may be required to implement 292 this standard. Please address the information to the IETF at 293 ietf-ipr@ietf.org. 295 Acknowledgment 297 Funding for the RFC Editor function is provided by the IETF 298 Administrative Support Activity (IASA).