idnits 2.17.1 draft-ietf-teas-rsvp-te-scaling-rec-06.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 (August 10, 2017) is 2448 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: February 11, 2018 R. Shakir 6 Google, Inc 7 D. Pacella 8 Verizon 9 T. Saad 10 Cisco Systems 11 August 10, 2017 13 Implementation Recommendations to Improve the Scalability of RSVP-TE 14 Deployments 15 draft-ietf-teas-rsvp-te-scaling-rec-06 17 Abstract 19 The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed 20 is growing continually and the onus is on RSVP-TE implementations 21 across the board to keep up with this increasing demand. 23 This document introduces a couple of techniques - "Refresh-Interval 24 Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help 25 RSVP-TE deployments push the envelope on scaling. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 11, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Conventions used in this document . . . . . . . . . . . . 3 63 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. "RFC2961 Specific" Recommendations . . . . . . . . . . . 3 65 2.1.1. Basic Prerequisites . . . . . . . . . . . . . . . . . 3 66 2.1.2. Making Acknowledgements Mandatory . . . . . . . . . . 4 67 2.1.3. Clarifications On Reaching Rapid Retry Limit (Rl) . . 4 68 2.2. Refresh-Interval Independent RSVP . . . . . . . . . . . . 5 69 2.2.1. Capability Advertisement . . . . . . . . . . . . . . 5 70 2.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . 6 71 2.3. Per-Peer RSVP Flow-Control . . . . . . . . . . . . . . . 6 72 2.3.1. Capability Advertisement . . . . . . . . . . . . . . 7 73 2.3.2. Compatibility . . . . . . . . . . . . . . . . . . . . 7 74 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 5.1. Capability Object Values . . . . . . . . . . . . . . . . 8 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 7.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get 88 deployed is growing continually and there is considerable onus on 89 RSVP-TE implementations across the board to keep up with this 90 increasing demand in scale. 92 The set of RSVP Refresh Overhead Reduction procedures [RFC2961] 93 serves as a powerful toolkit for RSVP-TE implementations to help 94 cover a majority of the concerns about soft-state scaling. However, 95 even with these tools in the toolkit, analysis of existing 96 implementations [RFC5439] indicates that the processing required 97 under certain scale may still cause significant disruption to an LSR. 99 This document builds on the scaling work and analysis that has been 100 done so far and makes a set of concrete implementation 101 recommendations to help RSVP-TE deployments push the envelope further 102 on scaling - push higher the threshold above which an LSR struggles 103 to achieve sufficient processing to maintain LSP state. 105 This document advocates the use of a couple of techniques - "Refresh- 106 Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - 107 for significantly cutting down the amount of processing cycles 108 required to maintain LSP state. "RI-RSVP" helps completely eliminate 109 RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer 110 Flow-Control" enables a busy RSVP speaker to apply back pressure to 111 its peer(s). In order to reap maximum scaling benefits, it is 112 strongly RECOMMENDED that implementations support both the 113 techniques. 115 1.1. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Recommendations 123 2.1. "RFC2961 Specific" Recommendations 125 The implementation recommendations discussed in this section are 126 based on the proposals made in [RFC2961] and act as prerequisites for 127 implementing the techniques discussed in Sections 2.2 and 2.3. 129 2.1.1. Basic Prerequisites 131 An implementation that supports the techniques discussed in Sections 132 2.2 and 2.3 must meet certain basic prerequisites. 134 o It MUST indicate support for RSVP Refresh Overhead Reduction 135 extensions (as specified in Section 2 of [RFC2961]). 137 o It MUST support receipt of any RSVP Refresh Overhead Reduction 138 message as defined in [RFC2961]. 140 o It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms 141 as defined in [RFC2961] (including the SRefresh message) with the 142 default behavior being to initiate the mechanisms but offering a 143 configuration override. 145 o It MUST support reliable delivery of Path/Resv and the 146 corresponding Tear/Err messages (as specified in Section 4 of 147 [RFC2961]). 149 o It MUST support retransmission of all unacknowledged RSVP-TE 150 messages using exponential-backoff (as specified in Section 6 of 151 [RFC2961]). 153 2.1.2. Making Acknowledgements Mandatory 155 The reliable message delivery mechanism specified in [RFC2961] states 156 that "Nodes receiving a non-out of order message containing a 157 MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with 158 a MESSAGE_ID_ACK object." 160 In an implementation that supports the techniques discussed in 161 Sections 2.2 and 2.3, nodes receiving a non-out of order message 162 containing a MESSAGE ID object with the ACK-Desired flag set, MUST 163 respond with a MESSAGE_ID_ACK object. This MESSAGE_ID_ACK object can 164 be packed along with other MESSAGE_ID_ACK or MESSAGE_ID_NACK objects 165 and sent in an Ack message (or piggy-backed in any other RSVP 166 message). This improvement to the predictability of the system in 167 terms of reliable message delivery is key for being able to take any 168 action based on a non-receipt of an ACK. 170 2.1.3. Clarifications On Reaching Rapid Retry Limit (Rl) 172 According to section 6 of [RFC2961] "The staged retransmission will 173 continue until either an appropriate MESSAGE_ID_ACK object is 174 received, or the rapid retry limit, Rl, has been reached." The 175 following clarifies what actions, if any, a router should take once 176 Rl has been reached. 178 If Rl has been reached for the retransmission of a message that is 179 neither a Path nor a Resv message, then the router need not take any 180 further action. If Rl has been reached for the retransmission of a 181 Path or a Resv message, then the router starts periodic 182 retransmission of these on a slower timer. The retransmitted 183 messages MUST carry MESSAGE_ID object with ACK_Desired flag set. 184 This periodic retransmission SHOULD continue until an appropriate 185 MESSAGE_ID_ACK object is received indicating acknowledgement of the 186 (retransmitted) Path/Resv message. The configurable periodic 187 retransmission interval for this slower timer SHOULD be less than the 188 regular refresh interval. A default periodic retransmission interval 189 interval (for this slower timer) of 30 seconds is RECOMMENDED by this 190 document. 192 2.2. Refresh-Interval Independent RSVP 194 The RSVP protocol relies on periodic refreshes for state 195 synchronization between RSVP neighbors and for recovery from lost 196 RSVP messages. It relies on refresh timeout for stale state cleanup. 197 The primary motivation behind introducing the notion of "Refresh 198 Interval Independent RSVP" (RI-RSVP) is to completely eliminate 199 RSVP's reliance on refreshes and refresh timeouts. This is done by 200 simply increasing the refresh interval to a fairly large value. 201 [RFC2961] and [RFC5439] do talk about increasing the value of the 202 refresh-interval to provide linear improvement on transmission 203 overhead, but also point out the degree of functionality that is lost 204 by doing so. This section revisits this notion, but also proposes 205 sufficient recommendations to make sure that there is no loss of 206 functionality incurred by increasing the value of the refresh 207 interval. 209 An implementation that supports RI-RSVP: 211 o MUST support all the recommendations made in Section 2.1. 213 o MUST make the default value of the configurable refresh interval 214 be a large value (10s of minutes). A default value of 20 minutes 215 is RECOMMENDED by this document. 217 o MUST implement coupling the state of individual LSPs with the 218 state of the corresponding RSVP-TE signaling adjacency. When an 219 RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the 220 speaker MUST act as if all the Path and Resv states learnt via the 221 failed signaling adjacency have timed out. 223 o MUST make use of Node-ID based Hello Session ([RFC3209], 224 [RFC4558]) for detection of RSVP-TE signaling adjacency failures; 225 A default value of 9 seconds is RECOMMENDED by this document for 226 the configurable node hello interval (as opposed to the 5ms 227 default value proposed in Section 5.3 of [RFC3209]). 229 o MUST indicate support for RI-RSVP via the CAPABILITY object in 230 Hello messages. 232 2.2.1. Capability Advertisement 234 An implementation supporting the RI-RSVP recommendations MUST set a 235 new flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello 236 messages. 238 Bit Number TBA1 (TBA2) - RI-RSVP Capable (I-bit): 240 Indicates that the sender supports RI-RSVP. 242 Any node that sets the new I-bit in its CAPABILITY object MUST also 243 set Refresh-Reduction-Capable bit in common header of all RSVP-TE 244 messages. If a peer sets the I-bit in the CAPABILITY object but does 245 not set the Refresh-Reduction-Capable bit, then the RI-RSVP 246 functionality MUST NOT be activated for that peer. 248 2.2.2. Compatibility 250 The RI-RSVP functionality MUST NOT be activated with a peer that does 251 not indicate support for this functionality. 253 2.3. Per-Peer RSVP Flow-Control 255 The set of recommendations discussed in this section provide an RSVP 256 speaker with the ability to apply back pressure to its peer(s) to 257 reduce/eliminate RSVP-TE control plane congestion. 259 An implementation that supports "Per-Peer RSVP Flow-Control": 261 o MUST support all the recommendations made in Sections 2.1 and 2.2. 263 o MUST treat lack of ACKs from a peer as an indication of peer's 264 RSVP-TE control plane congestion. If congestion is detected, the 265 local system MUST throttle RSVP-TE messages to the affected peer. 266 This MUST be done on a per-peer basis. (Per-peer throttling MAY 267 be implemented by a traffic shaping mechanism that proportionally 268 reduces the RSVP signaling packet rate as the number of 269 outstanding Acks increases. And when the number of outstanding 270 Acks decreases, the send rate would be adjusted up again.) 272 o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of 273 [RFC2961], suggests using 3). 275 o SHOULD prioritize Hello messages and messages carrying 276 Acknowledgements over other RSVP messages. 278 o SHOULD prioritize Tear/Error over trigger Path/Resv (messages that 279 bring up new LSP state) sent to a peer when the local system 280 detects RSVP-TE control plane congestion in the peer. 282 o MUST indicate support for all recommendations in this section via 283 the CAPABILITY object in Hello messages. 285 2.3.1. Capability Advertisement 287 An implementation supporting the "Per-Peer Flow-Control" 288 recommendations MUST set a new flag "Per-Peer Flow-Control Capable" 289 in the CAPABILITY object signaled in Hello messages. 291 Bit Number TBA3 (TBA4) - Per-Peer Flow-Control Capable (F-bit): 293 Indicates that the sender supports Per-Peer RSVP Flow-Control. 295 Any node that sets the new F-bit in its CAPABILITY object MUST also 296 set Refresh-Reduction-Capable bit in common header of all RSVP-TE 297 messages. If a peer sets the F-bit in the CAPABILITY object but does 298 not set the Refresh-Reduction-Capable bit, then the Per-Peer Flow- 299 Control functionality MUST NOT be activated for that peer. 301 2.3.2. Compatibility 303 The Per-Peer Flow-Control functionality MUST NOT be activated with a 304 peer that does not indicate support for this functionality. If a 305 peer hasn't indicated that it is capable of participating in "Per- 306 Peer Flow-Control", then it SHOULD NOT be assumed that the peer would 307 always acknowledge a non-out of order message containing a MESSAGE ID 308 object with the ACK-Desired flag set. 310 3. Acknowledgements 312 The authors would like to thank Yakov Rekhter for initiating this 313 work and providing valuable inputs. They would like to thank 314 Raveendra Torvi and Chandra Ramachandran for participating in the 315 many discussions that led to the recommendations made in this 316 document. They would also like to thank Adrian Farrel and Lou Berger 317 for providing detailed review comments. 319 4. Contributors 321 Markus Jork 322 Juniper Networks 323 Email: mjork@juniper.net 325 Ebben Aries 326 Juniper Networks 327 Email: exa@juniper.net 329 5. IANA Considerations 331 5.1. Capability Object Values 333 IANA maintains all the registries associated with "Resource 334 Reservation Protocol (RSVP) Paramaters" (see 335 http://www.iana.org/assignments/rsvp-parameters/rsvp- 336 parameters.xhtml). "Capability Object Values" Registry (introduced 337 by [RFC5063]) is one of them. 339 IANA is requested to assign two new Capability Object Value bit flags 340 as follows: 342 Bit Hex Name Reference 343 Number Value 344 ------------------------------------------------------------------ 345 TBA1 TBA2 RI-RSVP Capable (I) Section 2.2.1 346 TBA3 TBA4 Per-Peer Flow-Control Capable (F) Section 2.3.1 348 6. Security Considerations 350 This document does not introduce new security issues. The security 351 considerations pertaining to the original RSVP protocol [RFC2205] and 352 RSVP-TE [RFC3209] and those that are described in [RFC5920] remain 353 relevant. 355 7. References 357 7.1. Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, 361 DOI 10.17487/RFC2119, March 1997, 362 . 364 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 365 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 366 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 367 September 1997, . 369 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 370 and S. Molendini, "RSVP Refresh Overhead Reduction 371 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 372 . 374 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 375 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 376 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 377 . 379 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 380 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 381 A Clarification Statement", RFC 4558, 382 DOI 10.17487/RFC4558, June 2006, 383 . 385 [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to 386 GMPLS Resource Reservation Protocol (RSVP) Graceful 387 Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, 388 . 390 7.2. Informative References 392 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 393 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 394 DOI 10.17487/RFC5439, February 2009, 395 . 397 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 398 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 399 . 401 Appendix A. Recommended Defaults 403 (a) Refresh-Interval (R)- 20 minutes (Section 2.2). 404 Given that an implementation supporting RI-RSVP doesn't rely on 405 refreshes for state sync between peers, the function of RSVP 406 refresh interval is analogous to that of IGP refresh interval (the 407 default of which is typically in the order of 10s of minutes). 408 Choosing a default of 20 minutes allows the refresh timer to be 409 randomly set to a value in the range [10 minutes (0.5R), 30 410 minutes (1.5R)]. 412 (b) Node Hello-Interval - 9 Seconds (Section 2.2). 413 [RFC3209] defines the hello timeout as 3.5 times the hello 414 interval. Choosing 9 seconds for the node hello-interval gives a 415 hello timeout of 3.5*9 = 31.5 seconds. This puts the hello 416 timeout value in the vicinity of the IGP hello timeout value. 418 (c) Retry-Limit (Rl) - 7 (Section 2.3). 419 Choosing 7 as the retry-limit results in an overall rapid 420 retransmit phase of 31.5 seconds. This matches up with the 31.5 421 seconds hello timeout. 423 (d) Periodic Retransmission Interval - 30 seconds (Section 2.1.3). 424 If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7 425 rapid retransmit steps to max out (The last delay from message 6 426 to message 7 is 16 seconds). After the 7 rapid retransmit steps 427 are maxed out, the router starts periodic retransmission on a 428 slower timer. This document recommends the use of the traditional 429 default refresh interval value of 30 seconds for this periodic 430 retransmission interval. 432 Authors' Addresses 434 Vishnu Pavan Beeram (editor) 435 Juniper Networks 437 Email: vbeeram@juniper.net 439 Ina Minei 440 Google, Inc 442 Email: inaminei@google.com 444 Rob Shakir 445 Google, Inc 447 Email: rjs@rob.sh 449 Dante Pacella 450 Verizon 452 Email: dante.j.pacella@verizon.com 454 Tarek Saad 455 Cisco Systems 457 Email: tsaad@cisco.com