idnits 2.17.1 draft-bryant-rtgwg-param-sync-01.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 (February 27, 2017) is 2615 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: August 31, 2017 C. Bowers 6 Juniper Networks 7 February 27, 2017 9 Synchronisation of Routing Parameters 10 draft-bryant-rtgwg-param-sync-01 12 Abstract 14 This document describes a mechanism for a link state routing protocol 15 to coordinate the value of a network-wide routing parameter amongst 16 routers in the flooding domain. The document also defines the 17 solution to one specific case: the agreement of a common convergence 18 timer value for use 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 August 31, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Required Properties . . . . . . . . . . . . . . . . . . . 5 62 5.2. Definition of the Convergence Timer . . . . . . . . . . . 6 63 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6.1. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.3. Network Wide Parameter . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 69 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 10.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 There exist use cases where it desirable for a network to use a 78 common value for a routing parameter across all nodes. In the past, 79 these use cases have been addressed by setting the parameter to a 80 constant value in the protocol definition itself, or by requiring 81 that the same value of the parameter be configured at every node. 83 Setting the routing parameter to a constant value in the protocol 84 definition makes it very difficult to change the parameter, since a 85 change would require formal modification to the protocol. In 86 practice, such a change is impractical, so the constant value needs 87 to be chosen conservatively. This may impose a fundamental 88 restriction on the eventual use of the protocol. 90 Manual or "static" configuration of the parameter is fraught for two 91 reasons. First, it is can be difficult to ensure that the correct, 92 identical, value is installed in all of the routers. Second, if any 93 change is introduced into the network that results in a need to 94 change the value (for example due to a change in hardware or software 95 version) then all of the routers need to be reconfigured to use the 96 new parameter value. Such consistency may be ensured by deploying 97 automated means such as enforcing the new value by invoking the 98 management interface of all involved routers. For example, a central 99 management entity may be responsible for communicating the new 100 configuration value by means of vendor-specific command line 101 interface (CLI), NETCONF[RFC6241], etc. This approach may be 102 attractive if all involved nodes expose technology-agnostic and 103 vendor-independent interfaces to modify a given network-wide 104 configuration parameter. 106 This document describes a protocol extension that propagates a 107 routing parameter throughout the flooding domain, which can be used 108 as an alternative to the centralized approach described above. The 109 method of choosing between one or more different advertised values, 110 the flooding scope, and the action to be taken when the parameter 111 changes MUST be provided in the definition of the parameter type. 113 This document also creates one parameter type: Convergence Timer 114 intended for use in IP Fast-reroute applications [RFC5714] [RFC5715]. 116 Note that this protocol is only intended to be used for the 117 propagation of parameters needed to support the operation of the 118 routing system. It MUST NOT be used as a general purpose parameter 119 exchange protocol, and in particular it MUST NOT be used as a 120 parameter negotiation protocol, since such use may degrade the 121 ability of the underlying link-state routing protocol to carry our 122 its essential purpose. 124 2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC2119 [RFC2119]. 130 3. Overview of Mechanism 132 Routing Parameter values that can be disseminated by means of the 133 attribute defined in this specification MUST be defined as a 134 configurable parameter or a default parameter in the corresponding 135 specification. 137 A new information element is introduced into the routing protocol 138 that specifies the parameter. Each router taking part in the 139 parameter synchronization is expected to advertise a specific value 140 of the parameter, which that router determines based mainly on 141 considerations local to that router. In general, different routers 142 in the flooding domain may advertise different values of the 143 parameter. How the values advertised by a router are determined is 144 out of scope of this document. 146 A router receiving the parameter values advertised by all routers in 147 the flooding domain will use a well-defined method to select the 148 operational value of the parameter that it uses in the running of the 149 protocol. All routers MUST use the same method applied to the same 150 set of advertised parameter values. All routers SHALL therefore 151 choose the same operational value for the parameter. 153 Note the operational value for the parameter selected SHOULD NOT 154 directly affect the value for the parameter advertised by a router, 155 since this introduces a form of negotiation leading to additional 156 routing protocol traffic and possibly to instability in the routing 157 protocol. 159 The method of selecting from a range of advertised parameter values 160 MUST be provided in the parameter definition. 162 The definition of the parameter MUST specify the action to be taken 163 when a new parameter value is advertised that would cause a change in 164 the selected value. 166 The definition of the parameter MUST specify the action to be taken 167 in the legacy/migration case, where not all routers advertise the 168 parameter. 170 4. Protocol Details 172 This section describes the protocol extensions needed to implement 173 this functionality. 175 4.1. ISIS 177 A new Network Wide Parameter (NWP) sub-TLV is introduced into the IS- 178 IS Router CAPABILITY TLV (TLV #242 defined in [RFC7981]). The 179 setting of the S-bit in TLV #242 (indicating whether the parameter 180 should be leaked between levels) MUST be included in the specific NWP 181 definition. 183 Network Wide Parameter Sub-TLV 184 TYPE: 185 Length: As defined by parameter definition. 187 Sub-sub-TLV 188 NWP Type: (16 bits) as defined in NWP Registry 189 NWP Value: As defined by parameter definition 191 4.2. OSPF 193 THIS NEEDS CHECKING OVER BY AN OSPF EXPERT 195 A new OSPF Router Information LSA TLV is defined. This may be 196 carried in a type 10 or type 11 OSPF Opaque LSA depending on the 197 required flooding scope. 199 Network Wide Parameter TLV 200 TYPE: 201 Length: As defined by parameter definition. 203 Sub-TLV 204 NWP Type: (16 bits) as defined in NWP Registry 205 NWP Value: As defined by parameter definition 207 5. Convergence Time 209 Routers running a fast-reroute mechanism such as Maximally Redundant 210 Tree (MRT) [RFC7812] fast re-route require a network wide convergence 211 time value so that know how long they need continue using the repair 212 path before it is safe to use the base path. This time is set to be 213 the worst case time that any router will take to calculate the new 214 topology, and to make the necessary changes to the FIB. 216 The time taken by a router to complete each phase of the transition 217 will be dependent on the size of the network and the design and 218 implementation of the router. It can therefore be expected that the 219 optimum delay will need to be tuned from time to time as the network 220 evolves. 222 5.1. Required Properties 224 The Convergence Time mechanism MUST have the following properties: 226 o The operational convergence delay time MUST be consistent among 227 all routers that are converging on the new topology. 229 o The operational convergence delay time MUST be the highest delay 230 time advertised by any router in the new topology. 232 o The mechanism MUST increase the delay when a new router in 233 introduced to the network that requires a higher delay than 234 is currently in use. 236 o When the router that had the longest delay requirements is 237 removed from the topology, the convergence delay timer 238 value MUST, within some reasonable time, be reduced to 239 the longest delay required by the remaining routers. 241 o It MUST be possible for a router to change the 242 convergence delay timer value that it requires. 244 o A router which is in multiple routing areas, or is running 245 multiple routing protocols MAY signal a different loop-free 246 convergence delay for each area. 248 How a router determines the time that it needs to execute each 249 convergence phase is an implementation issue, and outside the scope 250 of this specification. However a router that dynamically determines 251 its proposed delay value must do so in such a way that it does not 252 cause the synchronized value to continually fluctuate. 254 5.2. Definition of the Convergence Timer 256 The NWP value is 16 bits and is specified in milliseconds; this gives 257 a maximum value of about 65s. 259 The NWP value selected is the largest value advertised. 261 If a routing protocol message is issued that changes the Convergence 262 Timer value, but does not change the topology, the new timer value 263 MUST be taken into consideration during the next network transition, 264 but MUST NOT instigate a new transition. 266 If a routing protocol message is issued that changes both the 267 Convergence Timer value and the topology, a transition is instigated 268 and the new timer value MUST be taken into consideration. 270 The convergence mechanism MUST specify the action to be taken if a 271 timer change (only) message and a topology change message are 272 independently generated during the hold-off time. 274 All routers that support controlled convergence MUST advertise an NWP 275 specifying their required Convergence Time. 277 If the parameter is carried in ISIS the S-bit is set to zero 278 indicating that the Convergence Timer NWP MUST NOT be leaked between 279 levels. 281 If the parameter is carried in OSPF it is only carried in a type 10 282 Opaque LSA which prevents propagation outside the OSPF area. 284 6. IANA considerations 286 6.1. ISIS 288 IANA is requested to allocate a new Sub-TLVs for TLV 242 from the IS- 289 IS TLV Codepoints name space. 291 Value Description Reference 292 ---------------------------------------------- 293 TBD Network Wide Parameter This Document 295 6.2. OSPF 297 IANA is requested to allocate a new OSPF Router Information (RI) TLV 298 from the Open Shortest Path First (OSPF) Parameters name space 300 Value TLV Name Reference 301 -------------------------------------------------- 302 TBD Network Wide Parameter This document 304 A value in the range 12 to 32767 is requested. 306 6.3. Network Wide Parameter 308 IANA is requested to create a new Network Wide Parameter Registry 309 within its own name space, and to allocate one value from it. 311 Value Name Reference 312 ------------------------------------------------ 313 0 Reserved This document 314 1 Convergence Timer This document 315 2..65535 Reserved This document 317 Allocations within this registry require IETF Consensus. 319 7. Security Considerations 321 The introduction of this parameter advertising mechanism does not 322 introduce a significant vulnerability into the base routing protocol 323 and is secured in exactly the same way as the other TLVs that are 324 carried. 326 In specifying a new parameter, consideration must be given to the 327 impact of the additional parameter, and in particular the rate of 328 change of that parameter, on the dynamics of the link-state routing 329 protocol in use. In the specific case of the Convergence Timer, the 330 amount of data being carried and the rate of change of the parameter 331 value will have a negligible impact on the link-state routing 332 protocol in use. 334 A rouge router deliberately introducing an anomalous parameter value 335 is just as capable of introducing many other anomalies into the 336 routing domain. 338 As far as possible, care should be taken to validate that the 339 parameter is reasonable. 341 In the specific case of the Convergence Time NWP, the following 342 considerations apply. 344 If an abnormally large timer value is proposed by a router, the there 345 is a danger that the convergence process will take an excessive time. 346 If during that time the routing protocol signals the need for another 347 transition, the transition will be abandoned and the default best 348 case (traditional) convergence mechanism used. 350 The maximum value that can be specified in the LSP/LSA is limited 351 through the use of a 16 bit field to about 65 seconds. 353 8. Acknowledgments 355 The authors than Mohamed Boucadair for his review comments and 356 proposed text. 358 9. Contributing Authors 360 Mike Shand 361 Independent 362 mike@mshand.org.uk 364 10. References 366 10.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, 370 DOI 10.17487/RFC2119, March 1997, 371 . 373 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 374 for Advertising Router Information", RFC 7981, 375 DOI 10.17487/RFC7981, October 2016, 376 . 378 10.2. Informative References 380 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 381 RFC 5714, DOI 10.17487/RFC5714, January 2010, 382 . 384 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 385 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 386 2010, . 388 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 389 and A. Bierman, Ed., "Network Configuration Protocol 390 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 391 . 393 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 394 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 395 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 396 . 398 Authors' Addresses 400 Stewart Bryant 401 Huawei Technologies 403 Email: stewart.bryant@gmail.com 405 Alia Atlas 406 Juniper Networks 408 Email: akatlas@gmail.com 409 Chris Bowers 410 Juniper Networks 412 Email: cbowers@juniper.net