idnits 2.17.1 draft-beeram-teas-rsvp-te-scaling-rec-00.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 (July 3, 2015) is 3219 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) == Outdated reference: A later version (-05) exists of draft-mtaillon-mpls-summary-frr-rsvpte-00 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 Vishnu Pavan Beeram (Ed) 3 Internet Draft Juniper Networks 4 Intended status: Proposed Standard Ina Minei 5 Google, Inc 6 Rob Shakir 7 British Telecom 8 Ebben Aries 9 Facebook 10 Dante Pacella 11 Verizon 12 Tarek Saad 13 Cisco Systems 14 Markus Jork 15 Juniper Networks 17 Expires: January 3, 2016 July 3, 2015 19 Implementation Recommendations to Improve the Scalability of RSVP-TE 20 Deployments 21 draft-beeram-teas-rsvp-te-scaling-rec-00 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on January 3, 2016. 46 Copyright Notice 47 Copyright (c) 2015 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 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described in 57 Section 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 Abstract 62 The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed 63 is growing continually and the onus is on RSVP-TE implementations 64 across the board to keep up with this increasing demand. 66 This document makes a set of implementation recommendations to help 67 RSVP-TE deployments push the envelope on scaling and advocates the 68 use of a couple of techniques - "Refresh Interval Independent RSVP 69 (RI-RSVP)" and "Per-Peer flow-control" - for improving scaling. 71 Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC-2119 [RFC2119]. 77 Table of Contents 79 1. Introduction...................................................3 80 2. Recommendations................................................4 81 2.1. "RFC2961 specific" Recommendations........................4 82 2.1.1. Basic Pre-Requisites.................................4 83 2.1.2. Making Acknowledgements mandatory....................4 84 2.1.3. Clarifications on reaching Rapid Retry Limit (Rl)....4 85 2.2. Refresh Interval Independent RSVP.........................5 86 2.2.1. Capability Advertisement.............................6 87 2.2.2. Compatibility........................................6 88 2.3. Per-Peer RSVP Flow Control................................7 89 2.3.1. Capability Advertisement.............................7 90 2.3.2. Compatibility........................................8 91 2.4. Other Recommendations.....................................8 92 2.4.1. Summary FRR..........................................8 93 3. Security Considerations........................................8 94 4. IANA Considerations............................................9 95 4.1. Capability Object Values..................................9 96 5. References.....................................................9 97 5.1. Normative References......................................9 98 5.2. Informative References...................................10 99 6. Acknowledgments...............................................10 100 Appendix A. Recommended Defaults.................................10 101 Authors' Addresses...............................................11 103 1. Introduction 105 The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get 106 deployed is growing continually and there is considerable onus on 107 RSVP-TE implementations across the board to keep up with this 108 increasing demand in scale. 110 The set of RSVP Refresh Overhead Reduction procedures [RFC2961] 111 serves as a powerful toolkit for RSVP-TE implementations to help 112 cover a majority of the concerns about soft-state scaling. However, 113 even with these tools in the toolkit, analysis of existing 114 implementations [RFC5439] indicates that the processing required 115 under certain scale may still cause significant disruption to an 116 LSR. 118 This document builds on the scaling work and analysis that has been 119 done so far and makes a set of concrete implementation 120 recommendations to help RSVP-TE deployments push the envelope 121 further on scaling - push higher the threshold above which an LSR 122 struggles to achieve sufficient processing to maintain LSP state. 124 This document advocates the use of a couple of techniques - "Refresh 125 Interval Independent RSVP (RI-RSVP)" and "Per-Peer flow-control" - 126 for significantly cutting down the amount of processing cycles 127 required to maintain LSP state. "RI-RSVP" helps completely eliminate 128 RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer 129 Flow-Control" enables a busy RSVP speaker to apply back pressure to 130 its peer(s). In order to reap maximum scaling benefits, it is 131 strongly RECOMMENDED that implementations support both the 132 techniques, but it is possible for an implementation to support just 133 one but not the other. 135 2. Recommendations 137 2.1. "RFC2961 specific" Recommendations 139 The implementation recommendations discussed in this section are 140 based on the proposals made in [RFC2961] and act as pre-requisites 141 for implementing either or both of the techniques discussed in 142 Sections 2.2 and 2.3. 144 2.1.1. Basic Pre-Requisites 146 An implementation that supports either or both of the techniques 147 discussed in Sections 2.2 and 2.3: 149 - SHOULD indicate support for RSVP Refresh Overhead Reduction 150 extensions (as specified in Section 2 of [RFC2961]) by default, 151 with the ability to override the default via configuration. 153 - MUST support reliable delivery of Path/Resv and the corresponding 154 Tear/Err messages using the procedures specified in [RFC2961]. 156 - MUST support retransmit of all RSVP-TE messages using exponential- 157 backoff, as specified in Section 6 of [RFC2961]. 159 2.1.2. Making Acknowledgements mandatory 161 The reliable message delivery mechanism specified in [RFC2961] 162 states that "Nodes receiving a non-out of order message containing a 163 MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with 164 a MESSAGE_ID_ACK object." 166 In an implementation that supports either or both of the techniques 167 discussed in Sections 2.2 and 2.3, nodes receiving a non-out of 168 order message containing a MESSAGE ID object with the ACK-Desired 169 flag set, MUST respond with a MESSAGE_ID_ACK object. This 170 improvement to the predictability of the system in terms of reliable 171 message delivery is key for being able to take any action based on a 172 non-receipt of an ACK. 174 2.1.3. Clarifications on reaching Rapid Retry Limit (Rl) 176 According to section 6 of [RFC2961] "The staged retransmission will 177 continue until either an appropriate MESSAGE_ID_ACK object is 178 received, or the rapid retry limit, Rl, has been reached." The 179 following clarifies what actions, if any, a router should take once 180 Rl has been reached. 182 If it is the retransmission of Tear/Err messages and Rl has been 183 reached, the router need not take any further actions. If it is the 184 retransmission of Path/Resv messages and Rl has been reached, then 185 the router starts periodic retransmission of these messages. The 186 retransmitted messages MUST carry MESSAGE_ID object with ACK_Desired 187 flag set. This periodic retransmission SHOULD continue until an 188 appropriate MESSAGE_ID ACK object is received indicating 189 acknowledgement of the (retransmitted) Path/Resv message. The 190 configurable periodic retransmission interval SHOULD be less than 191 the regular refresh interval. A default periodic retransmission 192 interval of 30 seconds is RECOMMENDED by this document. 194 2.2. Refresh Interval Independent RSVP 196 The RSVP protocol relies on periodic refreshes for state 197 synchronization between RSVP neighbors and for recovery from lost 198 RSVP messages. It relies on refresh timeout for stale state cleanup. 199 The primary motivation behind introducing the notion of "Refresh 200 Interval Independent RSVP" (RI-RSVP) is to completely eliminate 201 RSVP's reliance on refreshes and refresh timeouts. This is done by 202 simply increasing the refresh interval to a fairly large value. 203 [RFC2961] and [RFC5439] do talk about increasing the value of the 204 refresh-interval to provide linear improvement on transmission 205 overhead, but also point out the degree of functionality that is 206 lost by doing so. This section revisits this notion, but also 207 proposes sufficient recommendations to make sure that there is no 208 loss of functionality incurred by increasing the value of the 209 refresh interval. 211 An implementation that supports RI-RSVP: 213 - MUST support all the recommendations made in Section 2.1 215 - MUST make the default value of the configurable refresh interval 216 be a large value (10s of minutes). A default value of 20 minutes 217 is RECOMMENDED by this document. 219 - MUST implement coupling the state of individual LSPs with the 220 state of the corresponding RSVP-TE signaling adjacency. When an 221 RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the 222 speaker MUST act as if the all the Path and Resv state learnt via 223 the failed signaling adjacency has timed out. 225 - MUST make use of Node-ID based Hello Session ([RFC3209], 226 [RFC4558]) for detection of RSVP-TE signaling adjacency failures; 227 A default value of 9 seconds is RECOMMENDED by this document for 228 the configurable node hello interval (as opposed to the 5ms 229 default value proposed in Section 5.3 of [RFC3209]). 231 - (If Bypass FRR [RFC4090] is supported,) MUST implement procedures 232 specified in [RI-RSVP-FRR] which describes methods to facilitate 233 FRR that works independently of the refresh-interval. 235 - MUST indicate support for RI-RSVP via the CAPABILITY object in 236 Hello messages. 238 2.2.1. Capability Advertisement 240 An implementation supporting the RI-RSVP recommendations MUST set a 241 new flag "RI-RSVP Capable" in the CAPABILITY object signaled in 242 Hello messages. 244 The new flag that will be introduced to CAPABILITY object is 245 specified below. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Length | Class-Num(134)| C-Type (1) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Reserved |I|T|R|S| 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 I bit 257 Indicates that the sender supports RI-RSVP. 259 Any node that sets the new I-bit in its CAPABILITY object MUST also 260 set Refresh-Reduction-Capable bit in common header of all RSVP-TE 261 messages. 263 2.2.2. Compatibility 265 The RI-RSVP functionality MUST be activated only between peers that 266 indicate their support for this functionality. The RI-RSVP specific 267 Bypass FRR procedures discussed in [RI-RSVP-FRR] introduce a few new 268 protocol extensions and those MUST get activated only if the 269 participating nodes support RI-RSVP functionality. 271 2.3. Per-Peer RSVP Flow Control 273 The set of recommendations discussed in this section provide an RSVP 274 speaker with the ability to apply back pressure to its peer(s) to 275 reduce/eliminate RSVP-TE control plane congestion. 277 An implementation that supports "Per-Peer RSVP Flow Control": 279 - MUST support all the recommendations made in Section 2.1 281 - MUST use lack of ACKs from a peer as an indication of peer's RSVP- 282 TE control plane congestion. If congestion is detected, the local 283 system MUST throttle RSVP-TE messages to the affected peer. This 284 MUST be done on a per-peer basis. (Per-peer throttling MAY be 285 implemented by a traffic shaping mechanism that proportionally 286 reduces the RSVP signaling packet rate as the number of 287 outstanding Acks increases. And when the number of outstanding 288 Acks decreases, the send rate would be adjusted up again.) 290 - SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of 291 [RFC2961], suggests using 3). 293 - 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 - MUST indicate support for all recommendations in this section via 298 the CAPABILITY object in Hello messages. 300 2.3.1. Capability Advertisement 302 An implementation supporting the "Per-Peer Flow Control" 303 recommendations MUST set a new flag "Per-Peer Flow Control Capable" 304 in the CAPABILITY object signaled in Hello messages. 306 The new flag that will be introduced to CAPABILITY object is 307 specified below. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Length | Class-Num(134)| C-Type (1) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Reserved |F|I|T|R|S| 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 F bit 319 Indicates that the sender supports Per-Peer RSVP Flow Control 321 Any node that sets the new I-bit in its CAPABILITY object MUST also 322 set Refresh-Reduction-Capable bit in common header of all RSVP-TE 323 messages. 325 2.3.2. Compatibility 327 The "Per-Peer Flow Control" functionality MUST be activated only if 328 both peers support it. If a peer hasn't indicated that it is capable 329 of participating in "Per-Peer Flow Control", then it is risky to 330 assume that the peer would always acknowledge a non-out of order 331 message containing a MESSAGE ID object with the ACK-Desired flag 332 set. 334 2.4. Other Recommendations 336 The following scaling recommendations have no interdependency with 337 any of the techniques/recommendations specified in Sections 2.2 and 338 2.3. These are stand-alone functionalities that help improve RSVP-TE 339 scalability. 341 2.4.1. Summary FRR 343 If Bypass FRR [RFC4090] is supported by an implementation, it SHOULD 344 support the procedures discussed in [SUMMARY-FRR]. These procedures 345 reduce the amount of RSVP signaling required for Fast Reroute 346 procedures and subsequently improve the scalability of RSVP-TE 347 signaling when undergoing FRR convergence post a link or node 348 failure. 350 3. Security Considerations 352 This document does not introduce new security issues. The security 353 considerations pertaining to the original RSVP protocol [RFC2205] 354 and RSVP-TE [RFC3209] and those that are described in [RFC5920] 355 remain relevant. 357 4. IANA Considerations 359 4.1. Capability Object Values 361 [RFC5063] defines the name space for RSVP Capability Object Values. 362 The name space is managed by IANA. 364 IANA registry: RSVP PARAMETERS 366 Subsection: Capability Object Values 368 A Capability flag called "RI-RSVP Capable" is defined in Section 369 2.2.1 of this document. The bit number for this flag is TBD. 371 A Capability flag called "Per-Peer Flow Control Capable" is defined 372 in Section 2.3.1 of this document. The bit number for this flag is 373 TBD. 375 5. References 377 5.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC2205] Braden, R., "Resource Reservation Protocol (RSVP)", 383 RFC 2205, September 1997. 385 [RFC2961] Berger, L., "RSVP Refresh Overhead Reduction 386 Extensions", RFC 2961, April 2001. 388 [RFC3209] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP 389 Tunnels", RFC 3209, December 2001. 391 [RFC4090] Pan, P., "Fast Reroute Extensions to RSVP-TE for LSP 392 Tunnels", RFC 4090, May 2005. 394 [RFC4558] Ali, Z., "Node-ID Based Resource Reservation (RSVP) 395 Hello: A Clarification Statement", RFC 4558, June 2006. 397 [RFC5063] Satyanarayana, A., "Extensions to GMPLS Resource 398 Reservation Protocol Graceful Restart", RFC5063, October 399 2007. 401 [RI-RSVP-FRR] Ramachandran, C., "Refresh Interval Independent FRR 402 Facility Protection", draft-chandra-mpls-ri-rsvp-frr, 403 (work in progress) 405 [SUMMARY-FRR] Taillon, M., "RSVP-TE Summary Fast Reroute Extensions 406 for LSP Tunnels", draft-mtaillon-mpls-summary-frr- 407 rsvpte-00, (work in progress) 409 5.2. Informative References 411 [RFC5439] Yasukawa, S., "An Analysis of Scaling Issues in MPLS-TE 412 Core Networks", RFC 5439, February 2009. 414 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 415 Networks", RFC5920, July 2010. 417 6. Acknowledgments 419 The authors would like to thank Yakov Rekhter for initiating this 420 work and providing valuable inputs. They would like to thank 421 Raveendra Torvi and Chandra Ramachandran for participating in the 422 many discussions that led to the recommendations made in this 423 document. They would also like to thank Adrian Farrel for providing 424 detailed review comments. 426 Appendix A. Recommended Defaults 428 (a) Refresh-Interval (R)- 20 minutes (Section 2.2) 429 Given that an implementation supporting RI-RSVP doesn't rely on 430 refreshes for state sync between peers, the RSVP refresh interval is 431 sort of analogous to IGP refresh interval, the default of which is 432 typically in the order of 10s of minutes. Choosing a default of 20 433 minutes allows the refresh timer to be randomly set to a value in 434 the range [10 minutes (0.5R), 30 minutes (1.5R)]. 436 (b) Node Hello-Interval - 9 Seconds (Section 2.2) 437 [RFC3209] defines the hello timeout as 3.5 times the hello interval. 438 Choosing 9 seconds for the node hello-interval gives a hello timeout 439 of 3.5*9 = 31.5 seconds. This puts the hello timeout value to be in 440 the same ballpark as the IGP hello timeout value. 442 (c) Retry-Limit (Rl) - 7 (Section 2.3) 443 Choosing 7 as the retry-limit results in an overall rapid retransmit 444 phase of 31.5 seconds. This nicely matches up with the 31.5 seconds 445 hello timeout. 447 (d) Periodic Retransmission Interval - 30 seconds (Section 2.1.3) 448 If the Retry-Limit (Rl) is 7, then it takes about 30 (31.5 to be 449 precise) seconds for the 7 rapid retransmit steps to max out. (The 450 last delay from message 6 to message 7 is 16 seconds). The 30 451 seconds interval also matches the traditional default refresh time. 453 Authors' Addresses 455 Vishnu Pavan Beeram (Ed) 456 Juniper Networks 457 Email: vbeeram@juniper.net 459 Ina Minei 460 Google, Inc 461 Email: inaminei@google.com 463 Rob Shakir 464 British Telecom 465 Email: rob.shakir@bt.com 467 Ebben Aries 468 Facebook 469 Email: exa@fb.com 471 Dante Pacella 472 Verizon 473 Email: dante.j.pacella@verizon.com 475 Tarek Saad 476 Cisco Systems 477 Email: tsaad@cisco.com 479 Markus Jork 480 Juniper Networks 481 Email: mjork@juniper.net