idnits 2.17.1 draft-ietf-teas-rsvp-te-scaling-rec-07.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 (September 27, 2017) is 2396 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 TEAS Working Group V. Beeram, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track I. Minei 5 Expires: March 31, 2018 R. Shakir 6 Google, Inc 7 D. Pacella 8 Verizon 9 T. Saad 10 Cisco Systems 11 September 27, 2017 13 Techniques to Improve the Scalability of RSVP Traffic Engineering 14 Deployments 15 draft-ietf-teas-rsvp-te-scaling-rec-07 17 Abstract 19 At the time of writing, networks which utilize RSVP Traffic 20 Engineering (RSVP-TE) Label Switched Paths (LSPs) are encountering 21 limitations in the ability of implementations to support the growth 22 in the number of LSPs deployed. 24 This document defines two techniques, "Refresh-Interval Independent 25 RSVP (RI-RSVP)" and "Per-Peer Flow-Control", that reduce the number 26 of processing cycles required to maintain RSVP-TE LSP state in Label 27 Switching Routers (LSRs) and hence allow implementations to support 28 larger scale deployments. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on March 31, 2018. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Requirement for RFC2961 Support . . . . . . . . . . . . . . . 3 74 2.1. Required Functionality from RFC2961 to be Implemented . . 3 75 2.2. Making Acknowledgements Mandatory . . . . . . . . . . . . 4 76 2.3. Clarifications On Reaching Rapid Retry Limit (Rl) . . . . 4 77 3. Refresh-Interval Independent RSVP (RI-RSVP) . . . . . . . . . 5 78 3.1. Capability Advertisement . . . . . . . . . . . . . . . . 6 79 3.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 6 80 4. Per-Peer RSVP Flow-Control . . . . . . . . . . . . . . . . . 6 81 4.1. Capability Advertisement . . . . . . . . . . . . . . . . 7 82 4.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7 83 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 84 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 86 7.1. Capability Object Values . . . . . . . . . . . . . . . . 8 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 90 9.2. Informative References . . . . . . . . . . . . . . . . . 9 91 Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 9 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 94 1. Introduction 96 At the time of writing, networks which utilize RSVP Traffic 97 Engineering (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are 98 encountering limitations in the ability of implementations to support 99 the growth in the number of LSPs deployed. 101 The set of RSVP Refresh Overhead Reduction procedures [RFC2961] 102 serves as a powerful toolkit for RSVP-TE implementations to help 103 cover a majority of the concerns about soft-state scaling. However, 104 even with these tools in the toolkit, analysis of existing 105 implementations [RFC5439] indicates that the processing required 106 beyond a certain scale may still cause significant disruption to a 107 Label Switching Router (LSR). 109 This document builds on the scaling work and analysis that has been 110 done so far and defines protocol extensions to help RSVP-TE 111 deployments push the envelope further on scaling by increasing the 112 threshold above which an LSR struggles to achieve sufficient 113 processing to maintain LSP state. 115 This document defines two techniques, "Refresh-Interval Independent 116 RSVP (RI-RSVP)" and "Per-Peer Flow-Control", that cut down the number 117 of processing cycles required to maintain LSP state. "RI-RSVP" helps 118 completely eliminate RSVP's reliance on refreshes and refresh- 119 timeouts while "Per-Peer Flow-Control" enables a busy RSVP speaker to 120 apply back pressure to its peer(s). This document defines a unique 121 RSVP Capability [RFC5063] for each technique. Note that the "Per- 122 Peer Flow-Control" technique requires the "RI-RSVP" technique as a 123 prerequisite. In order to reap maximum scaling benefits, it is 124 strongly recommended that implementations support both the 125 techniques. Both the techniques are fully backward compatible and 126 can be deployed incrementally. 128 2. Requirement for RFC2961 Support 130 The techniques defined in Section 3 and Section 4 are based on 131 proposals made in [RFC2961]. Implementations of these techniques 132 will need to support the RSVP messages and procedures defined in 133 [RFC2961] as set out in Section 2.1 with some minor modifications and 134 alterations to recommended time intervals and iteration counts as 135 defined in the remainder of this section. 137 2.1. Required Functionality from RFC2961 to be Implemented 139 An implementation that supports the techniques discussed in Section 3 140 and Section 4 must support the functionality described in [RFC2961] 141 as follows: 143 o It MUST indicate support for RSVP Refresh Overhead Reduction 144 extensions (as specified in Section 2 of [RFC2961]). 146 o It MUST support receipt of any RSVP Refresh Overhead Reduction 147 message as defined in [RFC2961]. 149 o It MUST initiate all RSVP Refresh Overhead Reduction mechanisms as 150 defined in [RFC2961] (including the SRefresh message) with the 151 default behavior being to initiate the mechanisms but offering a 152 configuration override. 154 o It MUST support reliable delivery of Path/Resv and the 155 corresponding Tear/Err messages (as specified in Section 4 of 156 [RFC2961]). 158 o It MUST support retransmission of all unacknowledged RSVP-TE 159 messages using exponential-backoff (as specified in Section 6 of 160 [RFC2961]). 162 2.2. Making Acknowledgements Mandatory 164 The reliable message delivery mechanism specified in [RFC2961] states 165 that "Nodes receiving a non-out of order message containing a 166 MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with 167 a MESSAGE_ID_ACK object." 169 In an implementation that supports the techniques discussed in 170 Section 3 and Section 4, nodes receiving a non-out of order message 171 containing a MESSAGE_ID object with the ACK-Desired flag set, MUST 172 respond with a MESSAGE_ID_ACK object. This MESSAGE_ID_ACK object can 173 be packed along with other MESSAGE_ID_ACK or MESSAGE_ID_NACK objects 174 and sent in an Ack message (or piggy-backed in any other RSVP 175 message). This improvement to the predictability of the system in 176 terms of reliable message delivery is key for being able to take any 177 action based on a non-receipt of an ACK. 179 2.3. Clarifications On Reaching Rapid Retry Limit (Rl) 181 According to section 6 of [RFC2961] "The staged retransmission will 182 continue until either an appropriate MESSAGE_ID_ACK object is 183 received, or the rapid retry limit, Rl, has been reached." The 184 following clarifies what actions, if any, a router should take once 185 Rl has been reached. 187 If Rl has been reached for the retransmission of a message that is 188 neither a Path nor a Resv message, then the router need not take any 189 further action. If Rl has been reached for the retransmission of a 190 Path or a Resv message, then the router starts periodic 191 retransmission of these on a slower timer. The retransmitted 192 messages MUST carry MESSAGE_ID object with ACK_Desired flag set. 193 This periodic retransmission SHOULD continue until an appropriate 194 MESSAGE_ID_ACK object is received indicating acknowledgement of the 195 (retransmitted) Path/Resv message. The configurable periodic 196 retransmission interval for this slower timer SHOULD be less than the 197 regular refresh interval. A default periodic retransmission interval 198 (for this slower timer) of 30 seconds is RECOMMENDED by this 199 document. 201 3. Refresh-Interval Independent RSVP (RI-RSVP) 203 The RSVP protocol relies on periodic refreshes for state 204 synchronization between RSVP neighbors and for recovery from lost 205 RSVP messages. It relies on refresh timeout for stale state cleanup. 206 The primary motivation behind introducing the notion of "Refresh 207 Interval Independent RSVP" (RI-RSVP) is to completely eliminate 208 RSVP's reliance on refreshes and refresh timeouts. This is done by 209 simply increasing the refresh interval to a fairly large value. 210 [RFC2961] and [RFC5439] do talk about increasing the value of the 211 refresh interval to provide linear improvement of transmission 212 overhead, but also point out the degree of functionality that is lost 213 by doing so. This section revisits this notion, but also sets out 214 additional requirements to make sure that there is no loss of 215 functionality incurred by increasing the value of the refresh 216 interval. 218 An implementation that supports RI-RSVP: 220 o MUST support all the requirements specified in Section 2. 222 o MUST make the default value of the configurable refresh interval 223 be a large value (10s of minutes). A default value of 20 minutes 224 is RECOMMENDED by this document. 226 o MUST implement coupling the state of individual LSPs with the 227 state of the corresponding RSVP-TE signaling adjacency. When an 228 RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the 229 speaker MUST act as if all the Path and Resv states learnt via the 230 failed signaling adjacency have timed out. 232 o MUST make use of Node-ID based Hello Session ([RFC3209], 233 [RFC4558]) for detection of RSVP-TE signaling adjacency failures; 234 A default value of 9 seconds is RECOMMENDED by this document for 235 the configurable node hello interval (as opposed to the 5ms 236 default value proposed in Section 5.3 of [RFC3209]). 238 o MUST indicate support for RI-RSVP via the CAPABILITY object 239 [RFC5063] in Hello messages. 241 3.1. Capability Advertisement 243 An implementation supporting the RI-RSVP technique MUST set a new 244 flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello 245 messages. 247 Bit Number TBA1 (TBA2) - RI-RSVP Capable (I-bit): 249 Indicates that the sender supports RI-RSVP. 251 Any node that sets the new I-bit in its CAPABILITY object MUST also 252 set the Refresh-Reduction-Capable bit in the common header of all 253 RSVP-TE messages. If a peer sets the I-bit in the CAPABILITY object 254 but does not set the Refresh-Reduction-Capable bit, then the RI-RSVP 255 functionality MUST NOT be activated for that peer. 257 3.2. Compatibility 259 The RI-RSVP functionality MUST NOT be activated with a peer that does 260 not indicate support for this functionality. 262 4. Per-Peer RSVP Flow-Control 264 The functionality discussed in this section provides an RSVP speaker 265 with the ability to apply back pressure to its peer(s) to reduce/ 266 eliminate a significant portion of the RSVP-TE control message load. 268 An implementation that supports "Per-Peer RSVP Flow-Control": 270 o MUST support all the requirements specified in Section 2. 272 o MUST support "RI-RSVP" (Section 3). 274 o MUST treat lack of ACKs from a peer as an indication of peer's 275 RSVP-TE control plane congestion. If congestion is detected, the 276 local system MUST throttle RSVP-TE messages to the affected peer. 277 This MUST be done on a per-peer basis. (Per-peer throttling MAY 278 be implemented by a traffic shaping mechanism that proportionally 279 reduces the RSVP signaling packet rate as the number of 280 outstanding Acks increases. And when the number of outstanding 281 Acks decreases, the send rate would be adjusted up again.) 283 o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of 284 [RFC2961], suggests using 3). 286 o SHOULD prioritize Hello messages and messages carrying 287 Acknowledgements over other RSVP messages. 289 o SHOULD prioritize Tear/Error over trigger Path/Resv (messages that 290 bring up new LSP state) sent to a peer when the local system 291 detects RSVP-TE control plane congestion in the peer. 293 o MUST indicate support for this technique via the CAPABILITY object 294 [RFC5063] in Hello messages. 296 4.1. Capability Advertisement 298 An implementation supporting the "Per-Peer Flow-Control" technique 299 MUST set a new flag "Per-Peer Flow-Control Capable" in the CAPABILITY 300 object signaled in Hello messages. 302 Bit Number TBA3 (TBA4) - Per-Peer Flow-Control Capable (F-bit): 304 Indicates that the sender supports Per-Peer RSVP Flow-Control. 306 Any node that sets the new F-bit in its CAPABILITY object MUST also 307 set Refresh-Reduction-Capable bit in common header of all RSVP-TE 308 messages. If a peer sets the F-bit in the CAPABILITY object but does 309 not set the Refresh-Reduction-Capable bit, then the Per-Peer Flow- 310 Control functionality MUST NOT be activated for that peer. 312 4.2. Compatibility 314 The Per-Peer Flow-Control functionality MUST NOT be activated with a 315 peer that does not indicate support for this functionality. If a 316 peer hasn't indicated that it is capable of participating in "Per- 317 Peer Flow-Control", then it SHOULD NOT be assumed that the peer would 318 always acknowledge a non-out of order message containing a MESSAGE_ID 319 object with the ACK-Desired flag set. 321 5. Acknowledgements 323 The authors would like to thank Yakov Rekhter for initiating this 324 work and providing valuable inputs. They would like to thank 325 Raveendra Torvi and Chandra Ramachandran for participating in the 326 many discussions that led to the techniques discussed in this 327 document. They would also like to thank Adrian Farrel and Lou Berger 328 for providing detailed review comments. 330 6. Contributors 332 Markus Jork 333 Juniper Networks 334 Email: mjork@juniper.net 336 Ebben Aries 337 Juniper Networks 338 Email: exa@juniper.net 340 7. IANA Considerations 342 7.1. Capability Object Values 344 IANA maintains all the registries associated with "Resource 345 Reservation Protocol (RSVP) Paramaters" (see 346 http://www.iana.org/assignments/rsvp-parameters/rsvp- 347 parameters.xhtml). "Capability Object Values" Registry (introduced 348 by [RFC5063]) is one of them. 350 IANA is requested to assign two new Capability Object Value bit flags 351 as follows: 353 Bit Hex Name Reference 354 Number Value 355 ------------------------------------------------------------------ 356 TBA1 TBA2 RI-RSVP Capable (I) Section 3 357 TBA3 TBA4 Per-Peer Flow-Control Capable (F) Section 4 359 8. Security Considerations 361 This document does not introduce new security issues. The security 362 considerations pertaining to the original RSVP protocol [RFC2205] and 363 RSVP-TE [RFC3209] and those that are described in [RFC5920] remain 364 relevant. 366 9. References 368 9.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, . 375 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 376 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 377 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 378 September 1997, . 380 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 381 and S. Molendini, "RSVP Refresh Overhead Reduction 382 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 383 . 385 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 386 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 387 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 388 . 390 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 391 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 392 A Clarification Statement", RFC 4558, 393 DOI 10.17487/RFC4558, June 2006, . 396 [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to 397 GMPLS Resource Reservation Protocol (RSVP) Graceful 398 Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, 399 . 401 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 402 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 403 May 2017, . 405 9.2. Informative References 407 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 408 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 409 DOI 10.17487/RFC5439, February 2009, . 412 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 413 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 414 . 416 Appendix A. Recommended Defaults 418 (a) Refresh-Interval (R)- 20 minutes (Section 3). 419 Given that an implementation supporting RI-RSVP doesn't rely on 420 refreshes for state sync between peers, the function of RSVP 421 refresh interval is analogous to that of IGP refresh interval (the 422 default of which is typically in the order of 10s of minutes). 424 Choosing a default of 20 minutes allows the refresh timer to be 425 randomly set to a value in the range [10 minutes (0.5R), 30 426 minutes (1.5R)]. 428 (b) Node Hello-Interval - 9 Seconds (Section 3). 429 [RFC3209] defines the hello timeout as 3.5 times the hello 430 interval. Choosing 9 seconds for the node hello-interval gives a 431 hello timeout of 3.5*9 = 31.5 seconds. This puts the hello 432 timeout value in the vicinity of the IGP hello timeout value. 434 (c) Retry-Limit (Rl) - 7 (Section 4). 435 Choosing 7 as the retry-limit results in an overall rapid 436 retransmit phase of 31.5 seconds. This matches up with the 31.5 437 seconds hello timeout. 439 (d) Periodic Retransmission Interval - 30 seconds (Section 2.3). 440 If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7 441 rapid retransmit steps to max out (The last delay from message 6 442 to message 7 is 16 seconds). After the 7 rapid retransmit steps 443 are maxed out, the router starts periodic retransmission on a 444 slower timer. This document recommends the use of the traditional 445 default refresh interval value of 30 seconds for this periodic 446 retransmission interval. 448 Authors' Addresses 450 Vishnu Pavan Beeram (editor) 451 Juniper Networks 453 Email: vbeeram@juniper.net 455 Ina Minei 456 Google, Inc 458 Email: inaminei@google.com 460 Rob Shakir 461 Google, Inc 463 Email: rjs@rob.sh 465 Dante Pacella 466 Verizon 468 Email: dante.j.pacella@verizon.com 469 Tarek Saad 470 Cisco Systems 472 Email: tsaad@cisco.com