idnits 2.17.1 draft-ietf-rtgwg-routing-timer-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 -- The document date (October 28, 2017) is 2372 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 (-19) exists of draft-ietf-isis-segment-routing-msd-04 == Outdated reference: A later version (-25) exists of draft-ietf-ospf-segment-routing-msd-05 Summary: 0 errors (**), 0 flaws (~~), 3 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: May 1, 2018 C. Bowers 6 Juniper Networks 7 October 28, 2017 9 Routing Timer Parameter Synchronization 10 draft-ietf-rtgwg-routing-timer-param-sync-00 12 Abstract 14 This document describes a mechanism for a link state routing protocol 15 to coordinate the value of a routing timer parameter amongst routers 16 in the flooding domain. The document also defines the solution to 17 one specific case: the agreement of a common convergence timer value 18 for use by routers in network convergence. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 1, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Overview of Mechanism . . . . . . . . . . . . . . . . . . . . 3 57 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Convergence Time . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Required Properties . . . . . . . . . . . . . . . . . . . 6 62 5.2. Definition of the Convergence Timer . . . . . . . . . . . 7 63 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6.1. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.3. Routing Timer Parameter Synchronization Registry . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 69 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 9 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 10.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 There exist use cases where it desirable for a network to use a 78 common value for a routing timer parameter across all nodes. In the 79 past, these types of use case have been addressed by setting the 80 parameter to a constant value in the protocol definition itself, or 81 by requiring that the same value of the parameter be configured at 82 every node. 84 Setting the routing timer parameter to a constant value in the 85 protocol definition makes it difficult to change the parameter, since 86 a change would require formal modification to the protocol. In 87 practice, such a change is impractical, so the constant value needs 88 to be chosen conservatively. This may impose a fundamental 89 restriction on the eventual use of the protocol. 91 Manual or "static" configuration of the timer parameter is fraught 92 for two reasons. First, it is can be difficult to ensure that the 93 correct, identical, value is installed in all of the routers. 94 Second, if any change is introduced into the network that results in 95 a need to change the value (for example due to a change in hardware 96 or software version) then all of the routers need to be reconfigured 97 to use the new timer parameter value. Such consistency may be 98 ensured by deploying automated means such as enforcing the new value 99 by invoking the management interface of all involved routers. For 100 example, a central management entity may be responsible for 101 communicating the new configuration value by means of vendor-specific 102 command line interface (CLI), NETCONF[RFC6241], etc. This approach 103 may be attractive if all involved nodes expose technology-agnostic 104 and vendor-independent interfaces to modify a given network-wide 105 configuration parameter. 107 This document describes a protocol extension that propagates a 108 routing timer parameter throughout the flooding domain, which can be 109 used as an alternative to the centralized approach described above. 110 The method of choosing between one or more different advertised 111 values, the flooding scope, and the action to be taken when the 112 parameter changes MUST be provided in the definition of the parameter 113 type. 115 This document also creates one parameter type: Convergence Timer 116 intended for use in IP Fast-reroute applications [RFC5714] [RFC5715]. 118 Note that this protocol is only intended to be used for the 119 propagation of parameters needed to support the operation of the 120 routing system. It MUST NOT be used as a general purpose parameter 121 exchange protocol, and in particular it MUST NOT be used as a 122 parameter negotiation protocol, since such use may degrade the 123 ability of the underlying link-state routing protocol to carry our 124 its essential purpose. 126 2. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC2119 [RFC2119]. 132 3. Overview of Mechanism 134 Routing Timer parameter values that can be disseminated by means of 135 the attribute defined in this specification MUST be defined as a 136 configurable parameter or a default parameter in the corresponding 137 specification. 139 A new information element is introduced into the routing protocol 140 that specifies the parameter. Each router taking part in the 141 parameter synchronization is expected to advertise a specific value 142 of the parameter, which that router determines based mainly on 143 considerations local to that router. In general, different routers 144 in the flooding domain may advertise different values of the 145 parameter. How the values advertised by a router are determined is 146 out of scope of this document. 148 A router receiving the parameter values advertised by all routers in 149 the flooding domain will use a well-defined method to select the 150 operational value of the parameter that it uses in the running of the 151 protocol. All routers MUST use the same method applied to the same 152 set of advertised parameter values. All routers SHALL therefore 153 choose the same operational value for the parameter. 155 Note the operational value for the parameter selected SHOULD NOT 156 directly affect the value for the parameter advertised by a router, 157 since this introduces a form of negotiation leading to additional 158 routing protocol traffic and possibly to instability in the routing 159 protocol. 161 The method of selecting from a range of advertised parameter values 162 MUST be provided in the parameter definition. 164 The definition of the parameter MUST specify the action to be taken 165 when a new parameter value is advertised that would cause a change in 166 the selected value. 168 The definition of the parameter MUST specify the action to be taken 169 in the legacy/migration case, where not all routers advertise the 170 parameter. 172 4. Protocol Details 174 This section describes the protocol extensions needed to implement 175 this functionality. 177 4.1. ISIS 179 A new Routing Timer Parameter Synchronization (RTPS) sub-TLV is 180 introduced into the IS-IS Router CAPABILITY TLV (TLV #242 defined in 181 [RFC7981]). The setting of the S-bit in TLV #242 (indicating whether 182 the parameter should be leaked between levels) MUST be included in 183 the specific routing parameter definition. 185 0 1 2 3 186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length | Sub-Type | Duration . 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 . Duration continued | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: Routing Timer Parameter Synchronization ISIS Sub-TLV 195 The Type (1 octet) of this sub-TLV to be assigned by IANA. 197 Length is variable (minimum value 5, multiple of 5 octets) and 198 represents the total Length of the field. 200 Sub-Type consists of a one octet identifier of the timer type. 202 Duration is a 32 bit value representing is the length of the timer in 203 milliseconds. This is capable of expressing a time in the range 1ms 204 to just under 50 days. 206 4.2. OSPF 208 A new Routing Timer Parameter Synchronization TLV is defined for the 209 OSPF Router Information LSA. This new TLV may be carried in a type 210 10 or type 11 OSPF Opaque LSA depending on the required flooding 211 scope. 212 The specification of a the specific routing timer parameter MUST 213 define the appropriate flooding scope(s) for that parameter. 215 0 1 2 3 216 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type | Length | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Sub-Type | Duration . 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 . Durn. cont. | 223 +-+-+-+-+-+-+-+-+ 225 Figure 2: Routing Timer Parameter Synchronization OSPF TLV 227 The Type (2 octets) of this sub-TLV to be assigned by IANA. 229 Length is variable (minimum value 5, multiple of 5 octets) and 230 represents the total Length of the field. 232 Sub-Type consists of a one octet identifier of the timer type. 234 Duration is a 32 bit value representing is the length of the timer in 235 milliseconds. This is capable of expressing a time in the range 1ms 236 to just under 50 days. 238 5. Convergence Time 240 Routers running a fast-reroute mechanism such as Maximally Redundant 241 Tree (MRT) [RFC7812] fast re-route require a network wide convergence 242 time value so that know how long they need continue using the repair 243 path before it is safe to use the base path. This time is set to be 244 the worst case time that any router will take to calculate the new 245 topology, and to make the necessary changes to the FIB. 247 The time taken by a router to complete each phase of the transition 248 will be dependent on the size of the network and the design and 249 implementation of the router. It can therefore be expected that the 250 optimum delay will need to be tuned from time to time as the network 251 evolves. 253 5.1. Required Properties 255 The Convergence Time mechanism MUST have the following properties: 257 o The operational convergence delay time MUST be consistent among 258 all routers that are converging on the new topology. 260 o The operational convergence delay time MUST be the highest delay 261 time advertised by any router in the new topology. 263 o The mechanism MUST increase the delay when a new router in 264 introduced to the network that requires a higher delay than 265 is currently in use. 267 o When the router that had the longest delay requirements is 268 removed from the topology, the convergence delay timer 269 value MUST, within some reasonable time, be reduced to 270 the longest delay required by the remaining routers. 272 o It MUST be possible for a router to change the 273 convergence delay timer value that it requires. 275 o A router which is in multiple routing areas, or is running 276 multiple routing protocols MAY signal a different loop-free 277 convergence delay for each area. 279 How a router determines the time that it needs to execute each 280 convergence phase is an implementation issue, and outside the scope 281 of this specification. However a router that dynamically determines 282 its proposed delay value must do so in such a way that it does not 283 cause the synchronized value to continually fluctuate. 285 5.2. Definition of the Convergence Timer 287 It is RECOMMENDED that the routing convergence timer be limited to a 288 maximum of 60 seconds. 290 The routing convergence timer value selected is the largest value 291 advertised. 293 If a routing protocol message is issued that changes the Convergence 294 Timer value, but does not change the topology, the new timer value 295 MUST be taken into consideration during the next network transition, 296 but MUST NOT instigate a new transition. 298 If a routing protocol message is issued that changes both the 299 Convergence Timer value and the topology, a transition is instigated 300 and the new timer value MUST be taken into consideration. 302 The convergence mechanism MUST specify the action to be taken if a 303 timer change (only) message and a topology change message are 304 independently generated during the hold-off time. 306 A router running ISIS that supports convergence timer synchronization 307 SHOULD advertise the Routing Timer Parameter Synchronization sub-TLV 308 with the value of the Convergence Timer in the Duration field of this 309 sub-TLV. The S-bit is set to zero indicating that the Convergence 310 Timer RPTS sub-TLV MUST NOT be leaked between levels. 312 A router running OSPF that supports convergence timer synchronization 313 SHOULD advertise the Routing Timer Parameter Synchronization TLV 314 with the value of the Convergence Timer in the Duration field of this 315 TLV. The TLV SHOULD only be carried in the type 10 Opaque LSA which 316 prevents propagation outside the OSPF area. 318 6. IANA considerations 320 6.1. ISIS 322 IANA is requested to allocate a new Sub-TLVs for TLV 242 from the IS- 323 IS TLV Codepoints name space. 325 Value Description Reference 326 ---------------------------------------------- 327 TBD Routing Timer Parameter This Document 328 Synchronization 330 6.2. OSPF 332 IANA is requested to allocate a new OSPF Router Information (RI) TLV 333 from the Open Shortest Path First (OSPF) Parameters name space 335 Value TLV Name Reference 336 -------------------------------------------------- 337 TBD Routing Timer Parameter This document 338 Synchronization 340 A value in the range 12 to 32767 is requested. 342 6.3. Routing Timer Parameter Synchronization Registry 344 IANA is requested to create a new Routing Timer Parameter 345 Synchronization Registry within its own name space, and to allocate 346 one value from it. 348 Value Name Reference 349 ------------------------------------------------ 350 0 Reserved This document 351 1 Convergence Timer This document 352 2..255 Reserved This document 354 Allocations within this registry require IETF Consensus. This link 355 state protocol extension MUST NOT be used for any purpose other than 356 one associated with the routing system timer parameters. 358 7. Security Considerations 360 The introduction of this parameter advertising mechanism does not 361 introduce a significant vulnerability into the base routing protocol 362 and is secured in exactly the same way as the other TLVs that are 363 carried. 365 In specifying a new parameter, consideration must be given to the 366 impact of the additional parameter, and in particular the rate of 367 change of that parameter, on the dynamics of the link-state routing 368 protocol in use. In the specific case of the Convergence Timer, the 369 amount of data being carried and the rate of change of the parameter 370 value will have a negligible impact on the link-state routing 371 protocol in use. 373 A rouge router deliberately introducing an anomalous parameter value 374 is just as capable of introducing many other anomalies into the 375 routing domain. 377 As far as possible, care should be taken to validate that the 378 parameter is reasonable. 380 In the specific case of the Convergence Time RTPS, the following 381 considerations apply. 383 If an abnormally large timer value is proposed by a router, the there 384 is a danger that the convergence process will take an excessive time. 385 If during that time the routing protocol signals the need for another 386 transition, the transition will be abandoned and the default best 387 case (traditional) convergence mechanism used. 389 It is RECOMMENDED that implementations prohibit the configuration of 390 a router convergence timer value in excess of 60 seconds. 392 8. Acknowledgments 394 The authors thank Les Ginsberg and the other authors of 395 [I-D.ietf-isis-segment-routing-msd] and 396 [I-D.ietf-ospf-segment-routing-msd] , Mohamed Boucadair for their 397 review comments and proposed text, and Tom Petch for his review 398 comments. 400 9. Contributing Authors 402 Mike Shand 403 Independent 404 mike@mshand.org.uk 406 10. References 408 10.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, . 415 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 416 for Advertising Router Information", RFC 7981, 417 DOI 10.17487/RFC7981, October 2016, . 420 10.2. Informative References 422 [I-D.ietf-isis-segment-routing-msd] 423 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 424 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 425 ietf-isis-segment-routing-msd-04 (work in progress), June 426 2017. 428 [I-D.ietf-ospf-segment-routing-msd] 429 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 430 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 431 ietf-ospf-segment-routing-msd-05 (work in progress), June 432 2017. 434 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 435 RFC 5714, DOI 10.17487/RFC5714, January 2010, 436 . 438 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 439 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 440 2010, . 442 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 443 and A. Bierman, Ed., "Network Configuration Protocol 444 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 445 . 447 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 448 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 449 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 450 . 452 Authors' Addresses 454 Stewart Bryant 455 Huawei Technologies 457 Email: stewart.bryant@gmail.com 459 Alia Atlas 460 Juniper Networks 462 Email: akatlas@gmail.com 464 Chris Bowers 465 Juniper Networks 467 Email: cbowers@juniper.net