idnits 2.17.1 draft-bryant-rtgwg-param-sync-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == Line 203 has weird spacing: '...ertised by an...' -- The document date (October 12, 2016) is 2751 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) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track A. Atlas 5 Expires: April 15, 2017 C. Bowers 6 Juniper Networks 7 October 12, 2016 9 Synchronisation of Network Parameters 10 draft-bryant-rtgwg-param-sync-00 12 Abstract 14 This document describes a mechanism for a link state routing protocol 15 to coordinate the value of a network-wide parameter. The document 16 also defines the solution to one specific case: the agreement of a 17 common convergence timer value for use in network convergence. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 15, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Convergence Time . . . . . . . . . . . . . . . . . . . . . . 4 60 5.1. Required Properties . . . . . . . . . . . . . . . . . . . 5 61 5.2. Definition of the Convergence Timer . . . . . . . . . . . 5 62 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6.1. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.3. Network Wide Parameter . . . . . . . . . . . . . . . . . 6 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 9.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 There exist use cases where it desirable for a network to use a 76 common value for a parameter across all nodes. In the past, these 77 use cases have been addressed by setting the parameter to a constant 78 value in the protocol definition itself, or by requiring that the 79 same value of the parameter be configured at every node. 81 Setting the parameter to a constant value in the protocol definition 82 makes it very difficult to change the parameter, since a change would 83 require formal modification to the protocol. In practice, such a 84 change is impractical, so the constant value needs to be chosen 85 conservatively. This may impose a fundamental restriction on the 86 eventual use of the protocol. 88 Manual or "static" configuration of the parameter is fraught for two 89 reasons. First, it is always difficult to ensure that the correct 90 value is installed in all of the routers. Second, if any change is 91 introduced into the network that results in a need to change the 92 value (for example due to a change in hardware or software version) 93 then all of the routers need to be reconfigured to use the new 94 parameter value. 96 This document describes a protocol extension that propagates a 97 parameter throughout the flooding domain. The method of choosing 98 between one or more different advertised values, the flooding scope, 99 and the action to be taken when the parameter changes MUST be 100 provided in the definition of the parameter type. 102 This document also creates one parameter type: Convergence Timer 103 intended for use in IP Fast-reroute applications [RFC5714] [RFC5715]. 105 2. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC2119 [RFC2119]. 111 3. Mechanism 113 The following mechanism is specified. 115 A new information element is introduced into the routing protocol 116 that specifies the parameter. Each router is expected to advertise a 117 specific value of the parameter, which that router determines based 118 mainly on considerations local to that router. In general, different 119 routers in the flooding domain will advertise different values of the 120 parameter. 122 A router receiving the parameter values advertised by all routers in 123 the flooding domain will use a well-defined method to select the 124 operational value of the parameter that it uses in the running of the 125 protocol. All routers MUST use the same method applied to the same 126 set of advertised parameter values. All routers SHALL therefore 127 choose the same operational value for the parameter. 129 Note the operational value for the parameter selected SHOULD NOT 130 directly affect the value for the parameter advertised a router. 132 The method of selecting from a range of advertised parameter values 133 MUST be provided in the parameter definition. 135 The definition of the parameter MUST specify the action to be taken 136 when a new parameter value is advertised that would cause a change in 137 the selected value. 139 The definition of the parameter MUST specify the action to be taken 140 in the legacy/migration case, where not all routers advertise the 141 parameter. 143 4. Protocol Details 145 This section describes the protocol extensions needed to implement 146 this functionality. 148 4.1. ISIS 150 A new Network Wide Parameter (NWP) sub-TLV is introduced into the IS- 151 IS Router CAPABILITY TLV (TLV #242 defined in [RFC4971]). The 152 setting of the S-bit in TLV #242 (indicating whether the parameter 153 should be leaked between levels) MUST be included in the specific NWP 154 definition. 156 Network Wide Parameter Sub-TLV 157 TYPE: 158 Length: As defined by parameter definition. 160 Sub-sub-TLV 161 NWP Type: (16 bits) as defined in NWP Registry 162 NWP Value: As defined by parameter definition 164 4.2. OSPF 166 THIS NEEDS CHECKING OVER BY AN OSPF EXPERT 168 A new OSPF Router Information LSA TLV is defined. This may be 169 carried in a type 10 or type 11 OSPF Opaque LSA depending on the 170 required flooding scope. 172 Network Wide Parameter TLV 173 TYPE: 174 Length: As defined by parameter definition. 176 Sub-TLV 177 NWP Type: (16 bits) as defined in NWP Registry 178 NWP Value: As defined by parameter definition 180 5. Convergence Time 182 Routers running a fast-reroute mechanism such as Maximally Redundant 183 Tree (MRT) [RFC7812] fast re-route require a network wide convergence 184 time value so that know how long they need continue using the repair 185 path before it is safe to use the base path. This time is set to be 186 the worst case time that any router will take to calculate the new 187 topology, and to make the necessary changes to the FIB. 189 The time taken by a router to complete each phase of the transition 190 will be dependent on the size of the network and the design and 191 implementation of the router. It can therefore be expected that the 192 optimum delay will need to be tuned from time to time as the network 193 evolves. 195 5.1. Required Properties 197 The Convergence Time mechanism MUST have the following properties: 199 o The operational convergence delay time MUST be consistent among 200 all routers that are converging on the new topology. 202 o The operational convergence delay time MUST be the highest delay 203 time advertised by any router in the new topology. 205 o The mechanism MUST increase the delay when a new router in 206 introduced to the network that requires a higher delay than 207 is currently in use. 209 o When the router that had the longest delay requirements is 210 removed from the topology, the convergence delay timer 211 value MUST, within some reasonable time, be reduced to 212 the longest delay required by the remaining routers. 214 o It MUST be possible for a router to change the 215 convergence delay timer value that it requires. 217 o A router which is in multiple routing areas, or is running 218 multiple routing protocols MAY signal a different loop-free 219 convergence delay for each area. 221 How a router determines the time that it needs to execute each 222 convergence phase is an implementation issue, and outside the scope 223 of this specification. However a router that dynamically determines 224 its proposed delay value must do so in such a way that it does not 225 cause the synchronized value to continually fluctuate. 227 5.2. Definition of the Convergence Timer 229 The NWP value is 16 bits and is specified in milliseconds; this gives 230 a maximum value of about 65s. 232 The NWP value selected is the largest value advertised. 234 If a routing protocol message is issued that changes the Convergence 235 Timer value, but does not change the topology, the new timer value 236 MUST be taken into consideration during the next network transition, 237 but MUST NOT instigate a new transition. 239 If a routing protocol message is issued that changes both the 240 Convergence Timer value and the topology, a transition is instigated 241 and the new timer value MUST be taken into consideration. 243 The convergence mechanism MUST specify the action to be taken if a 244 timer change (only) message and a topology change message are 245 independently generated during the hold-off time. 247 All routers that support controlled convergence MUST advertise an NWP 248 specifying their required Convergence Time. 250 If the parameter is carried in ISIS the S-bit is set to zero 251 indicating that the Convergence Timer NWP MUST NOT be leaked between 252 levels. 254 If the parameter is carried in OSPF it is only carried in a type 10 255 Opaque LSA which prevents propagation outside the OSPF area. 257 6. IANA considerations 259 6.1. ISIS 261 IANA is requested to allocate a new Sub-TLVs for TLV 242 from the IS- 262 IS TLV Codepoints name space. 264 Value Description Reference 265 ---------------------------------------------- 266 TBD Network Wide Parameter This Document 268 6.2. OSPF 270 IANA is requested to allocate a new OSPF Router Information (RI) TLV 271 from the Open Shortest Path First (OSPF) Parameters name space 273 Value TLV Name Reference 274 -------------------------------------------------- 275 TBD Network Wide Parameter This document 277 A value in the range 12 to 32767 is requested. 279 6.3. Network Wide Parameter 281 IANA is requested to create a new Network Wide Parameter Registry 282 within its own name space, and to allocate one value from it. 284 Value Name Reference 285 ------------------------------------------------ 286 0 Reserved This document 287 1 Convergence Timer This document 288 2..65535 Reserved This document 290 Allocations within this registry require documentation of the use of 291 the allocated value and approval by the Designated Expert assigned by 292 the IESG. 294 7. Security Considerations 296 The introduction of this parameter advertizing mechanism does not 297 introduce a significant vulnerability into the base routing protocol 298 and is secured in exactly the same way as the other TLVs that are 299 carried. 301 A rouge router deliberately introducing an anomalous parameter value 302 is just as capable of introducing many other anomalies into the 303 routing domain. 305 As far as possible, care should be taken to validate that the 306 parameter is reasonable. 308 In the specific case of the Convergence Time NWP, the following 309 considerations apply. 311 If an abnormally large timer value is proposed by a router, the there 312 is a danger that the convergence process will take an excessive time. 313 If during that time the routing protocol signals the need for another 314 transition, the transition will be abandoned and the default best 315 case (traditional) convergence mechanism used. 317 The maximum value that can be specified in the LSP/LSA is limited 318 through the use of a 16 bit field to about 65 seconds. 320 8. Contributing Authors 322 Mike Shand 323 Independent 324 mike@mshand.org.uk 326 9. References 327 9.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 335 "Intermediate System to Intermediate System (IS-IS) 336 Extensions for Advertising Router Information", RFC 4971, 337 DOI 10.17487/RFC4971, July 2007, 338 . 340 9.2. Informative References 342 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 343 RFC 5714, DOI 10.17487/RFC5714, January 2010, 344 . 346 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 347 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 348 2010, . 350 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 351 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 352 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 353 . 355 Authors' Addresses 357 Stewart Bryant 358 Huawei Technologies 360 Email: stewart.bryant@gmail.com 362 Alia Atlas 363 Juniper Networks 365 Email: akatlas@gmail.com 367 Chris Bowers 368 Juniper Networks 370 Email: cbowers@juniper.net