idnits 2.17.1 draft-ietf-teas-rsvp-te-scaling-rec-04.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 12, 2017) is 2600 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 (~~), 2 warnings (==), 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: September 13, 2017 R. Shakir 6 Google, Inc 7 D. Pacella 8 Verizon 9 T. Saad 10 Cisco Systems 11 March 12, 2017 13 Implementation Recommendations to Improve the Scalability of RSVP-TE 14 Deployments 15 draft-ietf-teas-rsvp-te-scaling-rec-04 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 makes a set of implementation recommendations to help 24 RSVP-TE deployments push the envelope on scaling and advocates the 25 use of a couple of techniques - "Refresh-Interval Independent RSVP 26 (RI-RSVP)" and "Per-Peer Flow-Control" - for improving scaling. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 13, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Conventions used in this document . . . . . . . . . . . . 3 64 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. "RFC2961 specific" Recommendations . . . . . . . . . . . 3 66 2.1.1. Basic Pre-Requisites . . . . . . . . . . . . . . . . 3 67 2.1.2. Making Acknowledgements mandatory . . . . . . . . . . 4 68 2.1.3. Clarifications on reaching Rapid Retry Limit (Rl) . . 4 69 2.2. Refresh-Interval Independent RSVP . . . . . . . . . . . . 4 70 2.2.1. Capability Advertisement . . . . . . . . . . . . . . 5 71 2.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . 6 72 2.3. Per-Peer RSVP Flow-Control . . . . . . . . . . . . . . . 6 73 2.3.1. Capability Advertisement . . . . . . . . . . . . . . 7 74 2.3.2. Compatibility . . . . . . . . . . . . . . . . . . . . 7 75 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 76 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 5.1. Capability Object Values . . . . . . . . . . . . . . . . 8 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 7.2. Informative References . . . . . . . . . . . . . . . . . 9 83 Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get 89 deployed is growing continually and there is considerable onus on 90 RSVP-TE implementations across the board to keep up with this 91 increasing demand in scale. 93 The set of RSVP Refresh Overhead Reduction procedures [RFC2961] 94 serves as a powerful toolkit for RSVP-TE implementations to help 95 cover a majority of the concerns about soft-state scaling. However, 96 even with these tools in the toolkit, analysis of existing 97 implementations [RFC5439] indicates that the processing required 98 under certain scale may still cause significant disruption to an LSR. 100 This document builds on the scaling work and analysis that has been 101 done so far and makes a set of concrete implementation 102 recommendations to help RSVP-TE deployments push the envelope further 103 on scaling - push higher the threshold above which an LSR struggles 104 to achieve sufficient processing to maintain LSP state. 106 This document advocates the use of a couple of techniques - "Refresh- 107 Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - 108 for significantly cutting down the amount of processing cycles 109 required to maintain LSP state. "RI-RSVP" helps completely eliminate 110 RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer 111 Flow-Control" enables a busy RSVP speaker to apply back pressure to 112 its peer(s). In order to reap maximum scaling benefits, it is 113 strongly RECOMMENDED that implementations support both the 114 techniques, but it is possible for an implementation to support just 115 one but not the other. 117 1.1. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119] 123 2. Recommendations 125 2.1. "RFC2961 specific" Recommendations 127 The implementation recommendations discussed in this section are 128 based on the proposals made in [RFC2961] and act as pre-requisites 129 for implementing either or both of the techniques discussed in 130 Sections 2.2 and 2.3. 132 2.1.1. Basic Pre-Requisites 134 An implementation that supports either or both of the techniques 135 discussed in Sections 2.2 and 2.3: 137 o SHOULD indicate support for RSVP Refresh Overhead Reduction 138 extensions (as specified in Section 2 of [RFC2961]) by default, 139 with the ability to override the default via configuration. 141 o MUST support reliable delivery of Path/Resv and the corresponding 142 Tear/Err messages using the procedures specified in [RFC2961]. 144 o MUST support retransmit of all RSVP-TE messages using exponential- 145 backoff, as specified in Section 6 of [RFC2961]. 147 2.1.2. Making Acknowledgements mandatory 149 The reliable message delivery mechanism specified in [RFC2961] states 150 that "Nodes receiving a non-out of order message containing a 151 MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with 152 a MESSAGE_ID_ACK object." 154 In an implementation that supports either or both of the techniques 155 discussed in Sections 2.2 and 2.3, nodes receiving a non-out of order 156 message containing a MESSAGE ID object with the ACK-Desired flag set, 157 MUST respond with a MESSAGE_ID_ACK object. This improvement to the 158 predictability of the system in terms of reliable message delivery is 159 key for being able to take any action based on a non-receipt of an 160 ACK. 162 2.1.3. Clarifications on reaching Rapid Retry Limit (Rl) 164 According to section 6 of [RFC2961] "The staged retransmission will 165 continue until either an appropriate MESSAGE_ID_ACK object is 166 received, or the rapid retry limit, Rl, has been reached." The 167 following clarifies what actions, if any, a router should take once 168 Rl has been reached. 170 If it is the retransmission of Tear/Err messages and Rl has been 171 reached, the router need not take any further actions. If it is the 172 retransmission of Path/Resv messages and Rl has been reached, then 173 the router starts periodic retransmission of these messages. The 174 retransmitted messages MUST carry MESSAGE_ID object with ACK_Desired 175 flag set. This periodic retransmission SHOULD continue until an 176 appropriate MESSAGE_ID ACK object is received indicating 177 acknowledgement of the (retransmitted) Path/Resv message. The 178 configurable periodic retransmission interval SHOULD be less than the 179 regular refresh interval. A default periodic retransmission interval 180 of 30 seconds is RECOMMENDED by this document. 182 2.2. Refresh-Interval Independent RSVP 184 The RSVP protocol relies on periodic refreshes for state 185 synchronization between RSVP neighbors and for recovery from lost 186 RSVP messages. It relies on refresh timeout for stale state cleanup. 187 The primary motivation behind introducing the notion of "Refresh 188 Interval Independent RSVP" (RI-RSVP) is to completely eliminate 189 RSVP's reliance on refreshes and refresh timeouts. This is done by 190 simply increasing the refresh interval to a fairly large value. 191 [RFC2961] and [RFC5439] do talk about increasing the value of the 192 refresh-interval to provide linear improvement on transmission 193 overhead, but also point out the degree of functionality that is lost 194 by doing so. This section revisits this notion, but also proposes 195 sufficient recommendations to make sure that there is no loss of 196 functionality incurred by increasing the value of the refresh 197 interval. 199 An implementation that supports RI-RSVP: 201 o MUST support all the recommendations made in Section 2.1. 203 o MUST make the default value of the configurable refresh interval 204 be a large value (10s of minutes). A default value of 20 minutes 205 is RECOMMENDED by this document. 207 o MUST implement coupling the state of individual LSPs with the 208 state of the corresponding RSVP-TE signaling adjacency. When an 209 RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the 210 speaker MUST act as if the all the Path and Resv state learnt via 211 the failed signaling adjacency has timed out. 213 o MUST make use of Node-ID based Hello Session ([RFC3209], 214 [RFC4558]) for detection of RSVP-TE signaling adjacency failures; 215 A default value of 9 seconds is RECOMMENDED by this document for 216 the configurable node hello interval (as opposed to the 5ms 217 default value proposed in Section 5.3 of [RFC3209]). 219 o MUST indicate support for RI-RSVP via the CAPABILITY object in 220 Hello messages. 222 2.2.1. Capability Advertisement 224 An implementation supporting the RI-RSVP recommendations MUST set a 225 new flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello 226 messages. 228 The new flag that will be introduced to CAPABILITY object is 229 specified below. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Length | Class-Num(134)| C-Type (1) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Reserved |I|T|R|S| 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 I bit 241 Indicates that the sender supports RI-RSVP. 243 Any node that sets the new I-bit in its CAPABILITY object MUST also 244 set Refresh-Reduction-Capable bit in common header of all RSVP-TE 245 messages. 247 2.2.2. Compatibility 249 The RI-RSVP functionality MUST be activated only between peers that 250 indicate their support for this functionality. 252 2.3. Per-Peer RSVP Flow-Control 254 The set of recommendations discussed in this section provide an RSVP 255 speaker with the ability to apply back pressure to its peer(s) to 256 reduce/eliminate RSVP-TE control plane congestion. 258 An implementation that supports "Per-Peer RSVP Flow-Control": 260 o MUST support all the recommendations made in Section 2.1 262 o MUST use lack of ACKs from a peer as an indication of peer's RSVP- 263 TE control plane congestion. If congestion is detected, the local 264 system MUST throttle RSVP-TE messages to the affected peer. This 265 MUST be done on a per-peer basis. (Per-peer throttling MAY be 266 implemented by a traffic shaping mechanism that proportionally 267 reduces the RSVP signaling packet rate as the number of 268 outstanding Acks increases. And when the number of outstanding 269 Acks decreases, the send rate would be adjusted up again.) 271 o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of 272 [RFC2961], suggests using 3). 274 o SHOULD prioritize Tear/Error over trigger Path/Resv (messages that 275 bring up new LSP state) sent to a peer when the local system 276 detects RSVP-TE control plane congestion in the peer. 278 o MUST indicate support for all recommendations in this section via 279 the CAPABILITY object in Hello messages. 281 2.3.1. Capability Advertisement 283 An implementation supporting the "Per-Peer Flow-Control" 284 recommendations MUST set a new flag "Per-Peer Flow-Control Capable" 285 in the CAPABILITY object signaled in Hello messages. 287 The new flag that will be introduced to CAPABILITY object is 288 specified below. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Length | Class-Num(134)| C-Type (1) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Reserved |F|I|T|R|S| 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 F bit 300 Indicates that the sender supports Per-Peer RSVP Flow-Control 302 Any node that sets the new I-bit in its CAPABILITY object MUST also 303 set Refresh-Reduction-Capable bit in common header of all RSVP-TE 304 messages. 306 2.3.2. Compatibility 308 The "Per-Peer Flow-Control" functionality MUST be activated only if 309 both peers support it. If a peer hasn't indicated that it is capable 310 of participating in "Per-Peer Flow-Control", then it is risky to 311 assume that the peer would always acknowledge a non-out of order 312 message containing a MESSAGE ID object with the ACK-Desired flag set. 314 3. Acknowledgements 316 The authors would like to thank Yakov Rekhter for initiating this 317 work and providing valuable inputs. They would like to thank 318 Raveendra Torvi and Chandra Ramachandran for participating in the 319 many discussions that led to the recommendations made in this 320 document. They would also like to thank Adrian Farrel for providing 321 detailed review comments. 323 4. Contributors 325 Markus Jork 326 Juniper Networks 327 Email: mjork@juniper.net 329 Ebben Aries 330 Juniper Networks 331 Email: exa@juniper.net 333 5. IANA Considerations 335 5.1. Capability Object Values 337 IANA maintains all the registries associated with "Resource 338 Reservation Protocol (RSVP) Paramaters" (see 339 http://www.iana.org/assignments/rsvp-parameters/rsvp- 340 parameters.xhtml). "Capability Object Values" Registry (introduced 341 by [RFC5063]) is one of them. 343 IANA is requested to assign two new Capability Object Value bit flags 344 as follows: 346 Bit Hex Name Reference 347 Number Value 348 ------------------------------------------------------------------ 349 TBA TBA RI-RSVP Capable (I) Section 2.2.1 350 TBA TBA Per-Peer Flow-Control Capable (F) Section 2.3.1 352 6. Security Considerations 354 This document does not introduce new security issues. The security 355 considerations pertaining to the original RSVP protocol [RFC2205] and 356 RSVP-TE [RFC3209] and those that are described in [RFC5920] remain 357 relevant. 359 7. References 361 7.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 369 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 370 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 371 September 1997, . 373 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 374 and S. Molendini, "RSVP Refresh Overhead Reduction 375 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 376 . 378 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 379 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 380 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 381 . 383 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 384 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 385 A Clarification Statement", RFC 4558, 386 DOI 10.17487/RFC4558, June 2006, 387 . 389 [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to 390 GMPLS Resource Reservation Protocol (RSVP) Graceful 391 Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, 392 . 394 7.2. Informative References 396 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 397 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 398 DOI 10.17487/RFC5439, February 2009, 399 . 401 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 402 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 403 . 405 Appendix A. Recommended Defaults 407 (a) Refresh-Interval (R)- 20 minutes (Section 2.2) Given that an 408 implementation supporting RI-RSVP doesn't rely on refreshes for 409 state sync between peers, the RSVP refresh interval is sort of 410 analogous to IGP refresh interval, the default of which is 411 typically in the order of 10s of minutes. Choosing a default of 412 20 minutes allows the refresh timer to be randomly set to a value 413 in the range [10 minutes (0.5R), 30 minutes (1.5R)]. 415 (b) Node Hello-Interval - 9 Seconds (Section 2.2) [RFC3209] 416 defines the hello timeout as 3.5 times the hello interval. 417 Choosing 9 seconds for the node hello-interval gives a hello 418 timeout of 3.5*9 = 31.5 seconds. This puts the hello timeout 419 value to be in the same ballpark as the IGP hello timeout value. 421 (c) Retry-Limit (Rl) - 7 (Section 2.3) Choosing 7 as the retry- 422 limit results in an overall rapid retransmit phase of 31.5 423 seconds. This nicely matches up with the 31.5 seconds hello 424 timeout. 426 (d) Periodic Retransmission Interval - 30 seconds (Section 2.1.3) 427 If the Retry-Limit (Rl) is 7, then it takes about 30 (31.5 to be 428 precise) seconds for the 7 rapid retransmit steps to max out. 429 (The last delay from message 6 to message 7 is 16 seconds). The 430 30 seconds interval also matches the traditional default refresh 431 time. 433 Authors' Addresses 435 Vishnu Pavan Beeram (editor) 436 Juniper Networks 438 Email: vbeeram@juniper.net 440 Ina Minei 441 Google, Inc 443 Email: inaminei@google.com 445 Rob Shakir 446 Google, Inc 448 Email: rjs@rob.sh 450 Dante Pacella 451 Verizon 453 Email: dante.j.pacella@verizon.com 455 Tarek Saad 456 Cisco Systems 458 Email: tsaad@cisco.com