idnits 2.17.1 draft-bryant-rtgwg-param-sync-02.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 (July 03, 2017) is 2481 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: January 4, 2018 C. Bowers 6 Juniper Networks 7 July 03, 2017 9 Routing Timer Parameter Synchronization 10 draft-bryant-rtgwg-param-sync-02 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 January 4, 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 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 OSPF Router Information LSA TLV is defined. This may be 209 carried in a type 10 or type 11 OSPF Opaque LSA depending on the 210 required flooding scope. 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Type | Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Sub-Type | Duration . 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 . Durn. cont. | 220 +-+-+-+-+-+-+-+-+ 222 Figure 2: Routing Timer Parameter Synchronization OSPF TLV 224 The Type (2 octets) of this sub-TLV to be assigned by IANA. 226 Length is variable (minimum value 5, multiple of 5 octets) and 227 represents the total Length of the field. 229 Sub-Type consists of a one octet identifier of the timer type. 231 Duration is a 32 bit value representing is the length of the timer in 232 milliseconds. This is capable of expressing a time in the range 1ms 233 to just under 50 days. 235 5. Convergence Time 237 Routers running a fast-reroute mechanism such as Maximally Redundant 238 Tree (MRT) [RFC7812] fast re-route require a network wide convergence 239 time value so that know how long they need continue using the repair 240 path before it is safe to use the base path. This time is set to be 241 the worst case time that any router will take to calculate the new 242 topology, and to make the necessary changes to the FIB. 244 The time taken by a router to complete each phase of the transition 245 will be dependent on the size of the network and the design and 246 implementation of the router. It can therefore be expected that the 247 optimum delay will need to be tuned from time to time as the network 248 evolves. 250 5.1. Required Properties 252 The Convergence Time mechanism MUST have the following properties: 254 o The operational convergence delay time MUST be consistent among 255 all routers that are converging on the new topology. 257 o The operational convergence delay time MUST be the highest delay 258 time advertised by any router in the new topology. 260 o The mechanism MUST increase the delay when a new router in 261 introduced to the network that requires a higher delay than 262 is currently in use. 264 o When the router that had the longest delay requirements is 265 removed from the topology, the convergence delay timer 266 value MUST, within some reasonable time, be reduced to 267 the longest delay required by the remaining routers. 269 o It MUST be possible for a router to change the 270 convergence delay timer value that it requires. 272 o A router which is in multiple routing areas, or is running 273 multiple routing protocols MAY signal a different loop-free 274 convergence delay for each area. 276 How a router determines the time that it needs to execute each 277 convergence phase is an implementation issue, and outside the scope 278 of this specification. However a router that dynamically determines 279 its proposed delay value must do so in such a way that it does not 280 cause the synchronized value to continually fluctuate. 282 5.2. Definition of the Convergence Timer 284 It is RECOMMENDED that the routing convergence timer be limited to a 285 maximum of 60 seconds. 287 The routing convergence timer value selected is the largest value 288 advertised. 290 If a routing protocol message is issued that changes the Convergence 291 Timer value, but does not change the topology, the new timer value 292 MUST be taken into consideration during the next network transition, 293 but MUST NOT instigate a new transition. 295 If a routing protocol message is issued that changes both the 296 Convergence Timer value and the topology, a transition is instigated 297 and the new timer value MUST be taken into consideration. 299 The convergence mechanism MUST specify the action to be taken if a 300 timer change (only) message and a topology change message are 301 independently generated during the hold-off time. 303 All routers that support controlled convergence MUST advertise an RPS 304 specifying their required Convergence Time. 306 If the parameter is carried in ISIS the S-bit is set to zero 307 indicating that the Convergence Timer RPS MUST NOT be leaked between 308 levels. 310 If the parameter is carried in OSPF it is only carried in a type 10 311 Opaque LSA which prevents propagation outside the OSPF area. 313 6. IANA considerations 315 6.1. ISIS 317 IANA is requested to allocate a new Sub-TLVs for TLV 242 from the IS- 318 IS TLV Codepoints name space. 320 Value Description Reference 321 ---------------------------------------------- 322 TBD Routing Timer Parameter This Document 323 Synchronization 325 6.2. OSPF 327 IANA is requested to allocate a new OSPF Router Information (RI) TLV 328 from the Open Shortest Path First (OSPF) Parameters name space 330 Value TLV Name Reference 331 -------------------------------------------------- 332 TBD Routing Timer Parameter This document 333 Synchronization 335 A value in the range 12 to 32767 is requested. 337 6.3. Routing Parameter Synchronization Registry 339 IANA is requested to create a new Routing Parameter Synchronization 340 Registry within its own name space, and to allocate one value from 341 it. 343 Value Name Reference 344 ------------------------------------------------ 345 0 Reserved This document 346 1 Convergence Timer This document 347 2..255 Reserved This document 349 Allocations within this registry require IETF Consensus. This link 350 state protocol extension MUST NOT be used for any purpose other than 351 one associated with the routing system. 353 7. Security Considerations 355 The introduction of this parameter advertising mechanism does not 356 introduce a significant vulnerability into the base routing protocol 357 and is secured in exactly the same way as the other TLVs that are 358 carried. 360 In specifying a new parameter, consideration must be given to the 361 impact of the additional parameter, and in particular the rate of 362 change of that parameter, on the dynamics of the link-state routing 363 protocol in use. In the specific case of the Convergence Timer, the 364 amount of data being carried and the rate of change of the parameter 365 value will have a negligible impact on the link-state routing 366 protocol in use. 368 A rouge router deliberately introducing an anomalous parameter value 369 is just as capable of introducing many other anomalies into the 370 routing domain. 372 As far as possible, care should be taken to validate that the 373 parameter is reasonable. 375 In the specific case of the Convergence Time RTPS, the following 376 considerations apply. 378 If an abnormally large timer value is proposed by a router, the there 379 is a danger that the convergence process will take an excessive time. 380 If during that time the routing protocol signals the need for another 381 transition, the transition will be abandoned and the default best 382 case (traditional) convergence mechanism used. 384 It is RECOMMENDED that implementations prohibit the configuration of 385 a router convergence timer value in excess of 60 seconds. 387 8. Acknowledgments 389 The authors thank Les Ginsberg and the other authors of 390 [I-D.ietf-isis-segment-routing-msd] and 391 [I-D.ietf-ospf-segment-routing-msd] , Mohamed Boucadair for their 392 review comments and proposed text, and Tom Petch for his review 393 comments. 395 9. Contributing Authors 397 Mike Shand 398 Independent 399 mike@mshand.org.uk 401 10. References 403 10.1. Normative References 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, 407 DOI 10.17487/RFC2119, March 1997, 408 . 410 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 411 for Advertising Router Information", RFC 7981, 412 DOI 10.17487/RFC7981, October 2016, 413 . 415 10.2. Informative References 417 [I-D.ietf-isis-segment-routing-msd] 418 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 419 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 420 ietf-isis-segment-routing-msd-04 (work in progress), June 421 2017. 423 [I-D.ietf-ospf-segment-routing-msd] 424 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 425 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 426 ietf-ospf-segment-routing-msd-05 (work in progress), June 427 2017. 429 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 430 RFC 5714, DOI 10.17487/RFC5714, January 2010, 431 . 433 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 434 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 435 2010, . 437 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 438 and A. Bierman, Ed., "Network Configuration Protocol 439 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 440 . 442 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 443 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 444 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 445 . 447 Authors' Addresses 449 Stewart Bryant 450 Huawei Technologies 452 Email: stewart.bryant@gmail.com 454 Alia Atlas 455 Juniper Networks 457 Email: akatlas@gmail.com 459 Chris Bowers 460 Juniper Networks 462 Email: cbowers@juniper.net