idnits 2.17.1 draft-ietf-teas-rsvp-te-scaling-rec-08.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 30, 2017) is 2367 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: May 3, 2018 R. Shakir 6 Google, Inc 7 D. Pacella 8 Verizon 9 T. Saad 10 Cisco Systems 11 October 30, 2017 13 Techniques to Improve the Scalability of RSVP Traffic Engineering 14 Deployments 15 draft-ietf-teas-rsvp-te-scaling-rec-08 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 May 3, 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 . . 4 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 . . . . . . . . . . . . . . . . 10 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 (Support for CAPABILITY 122 object is a prerequisite for implementing these techniques). Note 123 that the "Per-Peer Flow-Control" technique requires the "RI-RSVP" 124 technique as a prerequisite. In order to reap maximum scaling 125 benefits, it is strongly recommended that implementations support 126 both the techniques and have them enabled by default. Both the 127 techniques are fully backward compatible and can be deployed 128 incrementally. 130 2. Requirement for RFC2961 Support 132 The techniques defined in Section 3 and Section 4 are based on 133 proposals made in [RFC2961]. Implementations of these techniques 134 will need to support the RSVP messages and procedures defined in 135 [RFC2961] as set out in Section 2.1 with some minor modifications and 136 alterations to recommended time intervals and iteration counts (see 137 Appendix A for the set of recommended defaults) as defined in the 138 remainder of this section. 140 2.1. Required Functionality from RFC2961 to be Implemented 142 An implementation that supports the techniques discussed in Section 3 143 and Section 4 must support the functionality described in [RFC2961] 144 as follows: 146 o It MUST indicate support for RSVP Refresh Overhead Reduction 147 extensions (as specified in Section 2 of [RFC2961]). 149 o It MUST support receipt of any RSVP Refresh Overhead Reduction 150 message as defined in [RFC2961]. 152 o It MUST initiate all RSVP Refresh Overhead Reduction mechanisms as 153 defined in [RFC2961] (including the SRefresh message) with the 154 default behavior being to initiate the mechanisms but offering a 155 configuration override. 157 o It MUST support reliable delivery of Path/Resv and the 158 corresponding Tear/Err messages (as specified in Section 4 of 159 [RFC2961]). 161 o It MUST support retransmission of all unacknowledged RSVP-TE 162 messages using exponential-backoff (as specified in Section 6 of 163 [RFC2961]). 165 2.2. Making Acknowledgements Mandatory 167 The reliable message delivery mechanism specified in [RFC2961] states 168 that "Nodes receiving a non-out of order message containing a 169 MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with 170 a MESSAGE_ID_ACK object." 172 In an implementation that supports the techniques discussed in 173 Section 3 and Section 4, nodes receiving a non-out of order message 174 containing a MESSAGE_ID object with the ACK-Desired flag set, MUST 175 respond with a MESSAGE_ID_ACK object. This MESSAGE_ID_ACK object can 176 be packed along with other MESSAGE_ID_ACK or MESSAGE_ID_NACK objects 177 and sent in an Ack message (or piggy-backed in any other RSVP 178 message). This improvement to the predictability of the system in 179 terms of reliable message delivery is key for being able to take any 180 action based on a non-receipt of an ACK. 182 2.3. Clarifications On Reaching Rapid Retry Limit (Rl) 184 According to section 6 of [RFC2961] "The staged retransmission will 185 continue until either an appropriate MESSAGE_ID_ACK object is 186 received, or the rapid retry limit, Rl, has been reached." The 187 following clarifies what actions, if any, a router should take once 188 Rl has been reached. 190 If Rl has been reached for the retransmission of a message that is 191 neither a Path nor a Resv message, then the router need not take any 192 further action. If Rl has been reached for the retransmission of a 193 Path or a Resv message, then the router starts periodic 194 retransmission of these on a slower timer. The retransmitted 195 messages MUST carry MESSAGE_ID object with ACK_Desired flag set. 196 This periodic retransmission SHOULD continue until an appropriate 197 MESSAGE_ID_ACK object is received indicating acknowledgement of the 198 (retransmitted) Path/Resv message. The configurable Periodic 199 Retransmission Interval for unacknowledged Path/Resv messages (uR) 200 SHOULD NOT be more than the regular Refresh Interval (R). A default 201 uR of 30 seconds is RECOMMENDED by this document. 203 3. Refresh-Interval Independent RSVP (RI-RSVP) 205 The RSVP protocol relies on periodic refreshes for state 206 synchronization between RSVP neighbors and for recovery from lost 207 RSVP messages. It relies on refresh timeout for stale state cleanup. 208 The primary motivation behind introducing the notion of "Refresh 209 Interval Independent RSVP" (RI-RSVP) is to completely eliminate 210 RSVP's reliance on refreshes and refresh timeouts. This is done by 211 simply increasing the refresh interval to a fairly large value. 212 [RFC2961] and [RFC5439] do talk about increasing the value of the 213 refresh interval to provide linear improvement of transmission 214 overhead, but also point out the degree of functionality that is lost 215 by doing so. This section revisits this notion, but also sets out 216 additional requirements to make sure that there is no loss of 217 functionality incurred by increasing the value of the refresh 218 interval. 220 An implementation that supports RI-RSVP: 222 o MUST support all the requirements specified in Section 2. 224 o MUST make the default value of the configurable refresh interval 225 be a large value (10s of minutes). A default value of 20 minutes 226 is RECOMMENDED by this document. 228 o MUST implement coupling the state of individual LSPs with the 229 state of the corresponding RSVP-TE signaling adjacency. When an 230 RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the 231 speaker MUST act as if all the Path and Resv states learnt via the 232 failed signaling adjacency have timed out. 234 o MUST make use of Node-ID based Hello Session ([RFC3209], 235 [RFC4558]) for detection of RSVP-TE signaling adjacency failures; 236 A default value of 9 seconds is RECOMMENDED by this document for 237 the configurable node hello interval (as opposed to the 5ms 238 default value proposed in Section 5.3 of [RFC3209]). 240 o MUST indicate support for RI-RSVP via the CAPABILITY object 241 [RFC5063] in Hello messages. 243 3.1. Capability Advertisement 245 An implementation supporting the RI-RSVP technique MUST set a new 246 flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello 247 messages. 249 Bit Number TBA1 (TBA2) - RI-RSVP Capable (I-bit): 251 Indicates that the sender supports RI-RSVP. 253 Any node that sets the new I-bit in its CAPABILITY object MUST also 254 set the Refresh-Reduction-Capable bit in the common header of all 255 RSVP-TE messages. If a peer sets the I-bit in the CAPABILITY object 256 but does not set the Refresh-Reduction-Capable bit, then the RI-RSVP 257 functionality MUST NOT be activated for that peer. 259 3.2. Compatibility 261 The RI-RSVP functionality MUST NOT be activated with a peer that does 262 not indicate support for this functionality. Inactivation of the RI- 263 RSVP functionality MUST result in the use of the traditional smaller 264 refresh interval [RFC2205]. 266 4. Per-Peer RSVP Flow-Control 268 The functionality discussed in this section provides an RSVP speaker 269 with the ability to apply back pressure to its peer(s) to reduce/ 270 eliminate a significant portion of the RSVP-TE control message load. 272 An implementation that supports "Per-Peer RSVP Flow-Control": 274 o MUST support all the requirements specified in Section 2. 276 o MUST support "RI-RSVP" (Section 3). 278 o MUST treat lack of ACKs from a peer as an indication of peer's 279 RSVP-TE control plane congestion. If congestion is detected, the 280 local system MUST throttle RSVP-TE messages to the affected peer. 281 This MUST be done on a per-peer basis. (Per-peer throttling MAY 282 be implemented by a traffic shaping mechanism that proportionally 283 reduces the RSVP signaling packet rate as the number of 284 outstanding Acks increases. And when the number of outstanding 285 Acks decreases, the send rate would be adjusted up again.) 287 o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of 288 [RFC2961], suggests using 3). 290 o SHOULD prioritize Hello messages and messages carrying 291 Acknowledgements over other RSVP messages. 293 o SHOULD prioritize Tear/Error over trigger Path/Resv (messages that 294 bring up new LSP state) sent to a peer when the local system 295 detects RSVP-TE control plane congestion in the peer. 297 o MUST indicate support for this technique via the CAPABILITY object 298 [RFC5063] in Hello messages. 300 4.1. Capability Advertisement 302 An implementation supporting the "Per-Peer Flow-Control" technique 303 MUST set a new flag "Per-Peer Flow-Control Capable" in the CAPABILITY 304 object signaled in Hello messages. 306 Bit Number TBA3 (TBA4) - Per-Peer Flow-Control Capable (F-bit): 308 Indicates that the sender supports Per-Peer RSVP Flow-Control. 310 Any node that sets the new F-bit in its CAPABILITY object MUST also 311 set Refresh-Reduction-Capable bit in common header of all RSVP-TE 312 messages. If a peer sets the F-bit in the CAPABILITY object but does 313 not set the Refresh-Reduction-Capable bit, then the Per-Peer Flow- 314 Control functionality MUST NOT be activated for that peer. 316 4.2. Compatibility 318 The Per-Peer Flow-Control functionality MUST NOT be activated with a 319 peer that does not indicate support for this functionality. If a 320 peer hasn't indicated that it is capable of participating in "Per- 321 Peer Flow-Control", then it SHOULD NOT be assumed that the peer would 322 always acknowledge a non-out of order message containing a MESSAGE_ID 323 object with the ACK-Desired flag set. 325 5. Acknowledgements 327 The authors would like to thank Yakov Rekhter for initiating this 328 work and providing valuable inputs. They would like to thank 329 Raveendra Torvi and Chandra Ramachandran for participating in the 330 many discussions that led to the techniques discussed in this 331 document. They would also like to thank Adrian Farrel, Lou Berger 332 and Elwyn Davies for providing detailed review comments and text 333 suggestions. 335 6. Contributors 337 Markus Jork 338 Juniper Networks 339 Email: mjork@juniper.net 341 Ebben Aries 342 Juniper Networks 343 Email: exa@juniper.net 345 7. IANA Considerations 347 7.1. Capability Object Values 349 IANA maintains all the registries associated with "Resource 350 Reservation Protocol (RSVP) Paramaters" (see 351 http://www.iana.org/assignments/rsvp-parameters/rsvp- 352 parameters.xhtml). "Capability Object Values" Registry (introduced 353 by [RFC5063]) is one of them. 355 IANA is requested to assign two new Capability Object Value bit flags 356 as follows: 358 Bit Hex Name Reference 359 Number Value 360 ------------------------------------------------------------------ 361 TBA1 TBA2 RI-RSVP Capable (I) Section 3 362 TBA3 TBA4 Per-Peer Flow-Control Capable (F) Section 4 364 8. Security Considerations 366 This document does not introduce new security issues. The security 367 considerations pertaining to the original RSVP protocol [RFC2205] and 368 RSVP-TE [RFC3209] and those that are described in [RFC5920] remain 369 relevant. 371 9. References 373 9.1. Normative References 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, 377 DOI 10.17487/RFC2119, March 1997, . 380 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 381 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 382 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 383 September 1997, . 385 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 386 and S. Molendini, "RSVP Refresh Overhead Reduction 387 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 388 . 390 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 391 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 392 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 393 . 395 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 396 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 397 A Clarification Statement", RFC 4558, 398 DOI 10.17487/RFC4558, June 2006, . 401 [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to 402 GMPLS Resource Reservation Protocol (RSVP) Graceful 403 Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, 404 . 406 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 407 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 408 May 2017, . 410 9.2. Informative References 412 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 413 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 414 DOI 10.17487/RFC5439, February 2009, . 417 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 418 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 419 . 421 Appendix A. Recommended Defaults 423 (a) Refresh-Interval (R)- 20 minutes (Section 3). 424 Given that an implementation supporting RI-RSVP doesn't rely on 425 refreshes for state sync between peers, the function of RSVP 426 refresh interval is analogous to that of IGP refresh interval (the 427 default of which is typically in the order of 10s of minutes). 428 Choosing a default of 20 minutes allows the refresh timer to be 429 randomly set to a value in the range [10 minutes (0.5R), 30 430 minutes (1.5R)]. 432 (b) Node Hello-Interval - 9 Seconds (Section 3). 433 [RFC3209] defines the hello timeout as 3.5 times the hello 434 interval. Choosing 9 seconds for the node hello-interval gives a 435 hello timeout of 3.5*9 = 31.5 seconds. This puts the hello 436 timeout value in the vicinity of the IGP hello timeout value. 438 (c) Retry-Limit (Rl) - 7 (Section 4). 439 Choosing 7 as the retry-limit results in an overall rapid 440 retransmit phase of 31.5 seconds. This matches up with the 31.5 441 seconds hello timeout. 443 (d) Periodic Retransmission Interval for unacknowledged Path/Resv 444 messages (uR) - 30 seconds (Section 2.3). 445 If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7 446 rapid retransmit steps to max out (The last delay from message 6 447 to message 7 is 16 seconds). After the 7 rapid retransmit steps 448 are maxed out, the router starts periodic retransmission on a 449 slower timer. This document recommends the use of the traditional 450 default refresh interval value of 30 seconds for this periodic 451 retransmission interval. 453 Authors' Addresses 455 Vishnu Pavan Beeram (editor) 456 Juniper Networks 458 Email: vbeeram@juniper.net 460 Ina Minei 461 Google, Inc 463 Email: inaminei@google.com 464 Rob Shakir 465 Google, Inc 467 Email: rjs@rob.sh 469 Dante Pacella 470 Verizon 472 Email: dante.j.pacella@verizon.com 474 Tarek Saad 475 Cisco Systems 477 Email: tsaad@cisco.com