idnits 2.17.1 draft-ietf-teas-sr-rsvp-coexistence-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 date (May 16, 2018) is 2173 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group H. Sitaraman, Ed. 3 Internet-Draft V. Beeram 4 Intended status: Informational Juniper Networks 5 Expires: November 17, 2018 I. Minei 6 Google, Inc. 7 S. Sivabalan 8 Cisco Systems, Inc. 9 May 16, 2018 11 Recommendations for RSVP-TE and Segment Routing LSP co-existence 12 draft-ietf-teas-sr-rsvp-coexistence-rec-04.txt 14 Abstract 16 Operators are looking to introduce services over Segment Routing (SR) 17 LSPs in networks running Resource Reservation Protocol (RSVP-TE) 18 LSPs. In some instances, operators are also migrating existing 19 services from RSVP-TE to SR LSPs. For example, there might be 20 certain services that are well suited for SR and need to co-exist 21 with RSVP-TE in the same network. Such introduction or migration of 22 traffic to SR might require co-existence with RSVP-TE in the same 23 network for an extended period of time depending on the operator's 24 intent. The following document provides solution options for keeping 25 the traffic engineering database consistent across the network, 26 accounting for the different bandwidth utilization between SR and 27 RSVP-TE. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 17, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions used in this document . . . . . . . . . . . . . . 3 65 3. Solution options . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Static partitioning of bandwidth . . . . . . . . . . . . 4 67 3.2. Centralized management of available capacity . . . . . . 4 68 3.3. Flooding SR utilization in IGP . . . . . . . . . . . . . 4 69 3.4. Running SR over RSVP-TE . . . . . . . . . . . . . . . . . 5 70 3.5. TED consistency by reflecting SR traffic . . . . . . . . 5 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 8.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Appendix A. Multiplier value range . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 Introduction of SR [I-D.ietf-spring-segment-routing] in the same 84 network domain as RSVP-TE [RFC3209] presents the problem of 85 accounting for SR traffic and making RSVP-TE aware of the actual 86 available bandwidth on the network links. RSVP-TE is not aware of 87 how much bandwidth is being consumed by SR services on the network 88 links and hence both at computation time (for a distributed 89 computation) and at signaling time RSVP-TE LSPs will incorrectly 90 place loads. This is true where RSVP-TE paths are distributed or 91 centrally computed without a common entity managing both SR and RSVP- 92 TE computation for the entire network domain. 94 The problem space can be generalized as a dark bandwidth problem to 95 cases where any other service exists in the network that runs in 96 parallel across common links and whose bandwidth is not reflected in 97 the available and reserved values in the traffic engineering database 98 (TED). In most practical instances given the static nature of the 99 traffic demands, limiting the available reservable bandwidth 100 available to RSVP-TE has been an acceptable solution. However, in 101 the case of SR traffic, there is assumed to be very dynamic traffic 102 demands and there is considerable risk associated with stranding 103 capacity or overbooking service traffic resulting in traffic drops. 105 The high level requirements to consider are: 107 1. Placement of SR LSPs in the same domain as RSVP-TE LSPs must not 108 introduce inaccuracies in the TED used by distributed or 109 centralized path computation engines. 111 2. Engines that compute RSVP-TE paths may have no knowledge of the 112 existence of the SR paths in the same domain. 114 3. Engines that compute RSVP-TE paths should not require a software 115 upgrade or change to their path computation logic. 117 4. Protocol extensions should be avoided or be minimal as in many 118 cases this co-existence of RSVP-TE and SR may be needed only 119 during a transition phase. 121 5. Placement of SR LSPs in the same domain as RSVP-TE LSPs that are 122 computed in a distributed fashion must not require migration to a 123 central controller architecture for the RSVP-TE LSPs. 125 2. Conventions used in this document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. Solution options 135 The following section lists SR and RSVP co-existence solution 136 options. A specific solution is not recommended as all solutions are 137 valid even though some may not satisfy all the requirements. If a 138 solution is acceptable for an operator based on their deployment 139 model then such a solution can be chosen. 141 3.1. Static partitioning of bandwidth 143 In this model, the static reservable bandwidth of an interface can be 144 statically partitioned between SR and RSVP-TE and each can operate 145 within that bandwidth allocation and SHOULD NOT preempt each other. 147 While it is possible to configure RSVP-TE to only reserve up to a 148 certain maximum link bandwidth and manage the remaining link 149 bandwidth for other services, this is a deployment where SR and RSVP- 150 TE are separated in the same network (ships in the night) and can 151 lead to suboptimal link bandwidth utilization not allowing each to 152 consume more, if required and constraining the respective 153 deployments. 155 The downside of this approach is the inability to use the reservable 156 bandwidth effectively and inability to use bandwidth left unused by 157 the other protocol. 159 3.2. Centralized management of available capacity 161 In this model, a central controller performs path placement for both 162 RSVP-TE and SR LSPs. The controller manages and updates its own view 163 of the in-use and the available capacity. As the controller is a 164 single common entity managing the network it can have a unified and 165 consistent view of the available capacity at all times. 167 A practical drawback of this model is that it requires the 168 introduction of a central controller managing the RSVP-TE LSPs as a 169 prerequisite to the deployment of any SR LSPs. Therefore, this 170 approach is not practical for networks where distributed TE with 171 RSVP-TE LSPs is already deployed, as it requires a redesign of the 172 network and is not backwards compatible. This does not satisfy 173 requirement 5. 175 Note that it is not enough for the controller to just maintain the 176 unified view of the available capacity, it must also perform the path 177 computation for the RSVP-TE LSPs, as the reservations for the SR LSPs 178 are not reflected in the TED. 180 3.3. Flooding SR utilization in IGP 182 Using techniques in [RFC7810], [RFC7471] and [RFC7823], the SR 183 utilization information can be flooded in IGP-TE and the RSVP-TE path 184 computation engine (CSPF) can be changed to consider this 185 information. This requires changes to the RSVP-TE path computation 186 logic and would require upgrades in deployments where distributed 187 computation is done across the network. 189 This does not fit with requirements 3 and 4 mentioned earlier. 191 3.4. Running SR over RSVP-TE 193 SR can run over dedicated RSVP-TE LSPs that carry only SR traffic. 194 In this model, the LSPs can be one-hop or multi-hop and can provide 195 bandwidth reservation for the SR traffic based on functionality such 196 as auto-bandwidth. The model of deployment would be similar in 197 nature to running LDP over RSVP-TE. This would allow the TED to stay 198 consistent across the network and any other RSVP-TE LSPs will also be 199 aware of the SR traffic reservations. In this approach, non-SR 200 traffic MUST NOT take the SR-dedicated RSVP-TE LSPs, unless required 201 by policy. 203 The drawback of this solution is that it requires SR to rely on RSVP- 204 TE for deployment. Furthermore, the accounting accuracy/frequency of 205 this method is dependent on performance of auto-bandwidth for RSVP- 206 TE. Note that for this method to work, the SR-dedicated RSVP-TE LSPs 207 must be set up with the best setup and hold priorities in the 208 network. 210 3.5. TED consistency by reflecting SR traffic 212 The solution relies on dynamically measuring SR traffic utilization 213 on each TE interface and reducing the bandwidth allowed for use by 214 RSVP-TE. It is assumed that SR traffic receives precedence in terms 215 of the placement on the path over RSVP traffic (that is, RSVP traffic 216 can be preempted from the path in case of insufficient resources). 217 This is logically equivalent to SR traffic having the best preemption 218 priority in the network. Note that this does not necessarily mean 219 that SR traffic has higher QoS priority, in fact, SR and RSVP traffic 220 may be in the same QoS class. 222 Reducing the bandwidth allowed for use by RSVP-TE can be explored 223 using the three parameters available in IGP-TE ([RFC5305],[RFC3630]), 224 namely Maximum-Link-Bandwidth, Maximum-Reservable-Bandwidth and 225 Unreserved-Bandwidth. 227 o Maximum-Link-Bandwidth: This parameter can be adjusted to 228 accommodate the bandwidth required for SR traffic with cascading 229 impacts on Maximum-Reservable-Bandwidth and Unreserved-Bandwidth. 230 However, changing the maximum bandwidth for the TE link will 231 prevent any compute engine for SR or RSVP from determining the 232 real static bandwidth of the TE link. Further, when the Maximum- 233 Reservable-Bandwidth is derived from the Maximum-Link-Bandwidth, 234 its definition changes since Maximum-Link-Bandwidth will account 235 for the SR traffic. 237 o Unreserved-Bandwidth: SR traffic could directly adjust the 238 Unreserved-Bandwidth, without impacting Maximum-Link-Bandwidth or 239 Maximum-Reservable-Bandwidth. This model is equivalent to the 240 option described in Section 3.4. Furthermore this would result in 241 overloading IGP-TE advertisements to directly reflect both RSVP-TE 242 bandwidth bookings and SR bandwidth measurements. 244 o Maximum-Reservable-Bandwidth: As the preferred option, SR traffic 245 could adjust the Maximum-Reservable-Bandwidth, with cascading 246 impact on the Unreserved-Bandwidth. 248 The following methodology can be used at every TE node for this 249 solution, using the following parameters: 251 o T: Traffic statistics collection time interval 253 o k: The number of traffic statistics samples that can provide a 254 smoothing function to the statistics collection. The value of k 255 is a constant integer multiplier greater or equal to 1. 257 o N: Traffic averaging calculation (adjustment) interval such that N 258 = k * T 260 o Maximum-Reservable-Bandwidth: The maximum available bandwidth for 261 RSVP-TE. 263 If Differentiated-Service (Diffserv)-aware MPLS Traffic 264 Engineering (DS-TE) [RFC4124] is enabled, the Maximum-Reservable- 265 Bandwidth SHOULD be interpreted as the aggregate bandwidth 266 constraint across all Class-Types independent of the Bandwidth 267 Constraints model. 269 o Initial Maximum-Reservable-Bandwidth: The Maximum-reservable- 270 bandwidth for TE when no SR traffic or RSVP-TE reservations exist 271 on the interface. 273 o RSVP-unreserved-bandwidth-at-priority-X: Maximum-Reservable- 274 Bandwidth - sum of (existing reservations at priority X and all 275 priorities better than X) 277 o SR traffic threshold percentage: The percentage difference of 278 traffic demand that when exceeded can result in a change to the 279 RSVP-TE Maximum-Reservable-Bandwidth 281 o IGP-TE update threshold: Specifies the frequency at which IGP-TE 282 updates should be triggered based on TE bandwidth updates on a 283 link 285 o M: An optional multiplier that can be applied to the SR traffic 286 average. This multiplier provides the ability to grow or shrink 287 the bandwidth used by SR. Appendix A offers further guidance on 288 M. 290 At every interval T, each node SHOULD collect the SR traffic 291 statistics for each of its TE interfaces. The measured SR traffic 292 includes all labelled SR traffic and any traffic entering the SR 293 network over that TE interface. Further, at every interval N, given 294 a configured SR traffic threshold percentage and a set of collected 295 SR traffic statistics samples across the interval N, the SR traffic 296 average (or any other traffic metric depending on the algorithm used) 297 over this period is calculated. This method of sampling traffic 298 statistics and adjusting bandwidth reservation accordingly is similar 299 to how bandwidth gets adjusted for auto-bandwidth RSVP-TE LSPs. 301 If the difference between the new calculated SR traffic average and 302 the current SR traffic average (that was computed in the prior 303 adjustment) is at least SR traffic threshold percentage, then two 304 values MUST be updated: 306 o New Maximum-Reservable-Bandwidth = Initial Maximum-Reservable- 307 Bandwidth - (new SR traffic average * M) 309 o New RSVP-unreserved-bandwidth-at-priority-X = New Maximum- 310 Reservable-Bandwidth - sum of (existing reservations at priority X 311 and all priorities better than X) 313 A DS-TE LSR that advertises Bandwidth Constraints TLV should update 314 the bandwidth constraints for class-types based on operator policy. 315 For example, when Russian Dolls Model (RDM) [RFC4127] is in use, then 316 only BC0 may be updated. Whereas, when Maximum Allocation Model 317 (MAM) [RFC4125] is in use, then all BCs may be updated equally such 318 that the total value updated is equal to the newly calculated SR 319 traffic average. 321 Note that the computation of the new RSVP-unreserved-bandwidth-at- 322 priority-X MAY result in RSVP-TE LSPs being hard or soft preempted. 323 Such preemption will be based on relative priority (e.g. low to high) 324 between RSVP-TE LSPs. The IGP-TE update threshold SHOULD allow for 325 more frequent flooding of unreserved bandwidth. From an operational 326 point of view, an implementation SHOULD be able to expose both the 327 configured and the actual values of the Maximum-Reservable-Bandwidth. 329 If LSP preemption is not acceptable, then the RSVP-TE Maximum- 330 Reservable-Bandwidth cannot be reduced below what is currently 331 reserved by RSVP-TE on that interface. This may result in bandwidth 332 not being available for SR traffic. Thus, it is required that any 333 external controller managing SR LSPs SHOULD be able to detect this 334 situation (for example by subscribing to TED updates [RFC7752]) and 335 SHOULD take action to reroute existing SR paths. 337 Generically, SR traffic (or any non-RSVP-TE traffic) should have its 338 own priority allocated from the available priorities. This would 339 allow SR to preempt other traffic according to the preemption 340 priority order. 342 In this solution, the logic to retrieve the statistics, calculating 343 averages and taking action to change the Maximum-Reservable-Bandwidth 344 is an implementation choice, and all changes are local in nature. 345 However, note that this is a new network trigger for RSVP-TE 346 preemption and thus is a consideration for the operator. 348 The above solution offers the advantage of not introducing new 349 network-wide mechanisms especially during scenarios of migrating to 350 SR in an existing RSVP-TE network and reusing existing protocol 351 mechanisms. 353 4. Acknowledgements 355 The authors would like to thank Steve Ulrich for his detailed review 356 and comments. 358 5. Contributors 360 The following individuals contributed to this document: 362 Chandra Ramachandran 363 Juniper Networks 364 Email: csekar@juniper.net 366 Raveendra Torvi 367 Juniper Networks 368 Email: rtorvi@juniper.net 370 Sudharsana Venkataraman 371 Juniper Networks 372 Email: sudharsana@juniper.net 374 Martin Vigoureux 375 Nokia 376 Email: martin.vigoureux@nokia.com 378 6. IANA Considerations 380 This draft does not have any request for IANA. 382 7. Security Considerations 384 This document describes solution options for the co-existence of 385 RSVP-TE and SR LSPs in the same administrative domain. The security 386 considerations for SR are described in 387 [I-D.ietf-spring-segment-routing]. The security considerations 388 pertaining to RSVP-TE are described in [RFC5920]. The security 389 considerations of each architecture are typically unaffected by the 390 presence of the other. However, when RSVP-TE and SR LSPs co-exist, 391 it is possible for a hijacked SR traffic stream to maliciously 392 consume sufficient bandwidth and cause disruption to RSVP-TE LSPs. 393 With the solution option specified in Section 3.5, the impact to 394 RSVP-TE traffic can be controlled and paths re-routed. Some latent 395 risk of disruption still remains because this solution option relies 396 on taking statistics samples and adopting to new traffic flows only 397 after the adjustment period. The defensive mechanisms described in 398 the base SR security framework should be employed to guard against 399 situations that result in SR traffic hijacking or denial of service. 401 8. References 403 8.1. Normative References 405 [I-D.ietf-spring-segment-routing] 406 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 407 Litkowski, S., and R. Shakir, "Segment Routing 408 Architecture", draft-ietf-spring-segment-routing-15 (work 409 in progress), January 2018. 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, 413 DOI 10.17487/RFC2119, March 1997, 414 . 416 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 417 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 418 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 419 . 421 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 422 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 423 May 2017, . 425 8.2. Informative References 427 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 428 (TE) Extensions to OSPF Version 2", RFC 3630, 429 DOI 10.17487/RFC3630, September 2003, 430 . 432 [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of 433 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 434 DOI 10.17487/RFC4124, June 2005, 435 . 437 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth 438 Constraints Model for Diffserv-aware MPLS Traffic 439 Engineering", RFC 4125, DOI 10.17487/RFC4125, June 2005, 440 . 442 [RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints 443 Model for Diffserv-aware MPLS Traffic Engineering", 444 RFC 4127, DOI 10.17487/RFC4127, June 2005, 445 . 447 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 448 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 449 2008, . 451 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 452 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 453 . 455 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 456 Previdi, "OSPF Traffic Engineering (TE) Metric 457 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 458 . 460 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 461 S. Ray, "North-Bound Distribution of Link-State and 462 Traffic Engineering (TE) Information Using BGP", RFC 7752, 463 DOI 10.17487/RFC7752, March 2016, 464 . 466 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 467 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 468 RFC 7810, DOI 10.17487/RFC7810, May 2016, 469 . 471 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 472 "Performance-Based Path Selection for Explicitly Routed 473 Label Switched Paths (LSPs) Using TE Metric Extensions", 474 RFC 7823, DOI 10.17487/RFC7823, May 2016, 475 . 477 Appendix A. Multiplier value range 479 The following is a suggestion for the range of values for M: 481 M is a per-node positive real number that ranges from 0 to 2 with a 482 default of 1 and may be expressed as a percentage. 484 o If M < 1, then the SR traffic average is being understated, which 485 can result in the link getting full even though Maximum- 486 Reservable-Bandwidth does not reach zero. 488 o If M > 1, then the SR traffic average is overstated, thereby 489 resulting in the Maximum-Reservable-Bandwidth reaching zero before 490 the link gets full. If the reduction of Maximum-Reservable- 491 Bandwidth becomes a negative value, then a value of zero SHOULD be 492 used and advertised. 494 Authors' Addresses 496 Harish Sitaraman (editor) 497 Juniper Networks 498 1133 Innovation Way 499 Sunnyvale, CA 94089 500 US 502 Email: hsitaraman@juniper.net 504 Vishnu Pavan Beeram 505 Juniper Networks 506 10 Technology Park Drive 507 Westford, MA 01886 508 US 510 Email: vbeeram@juniper.net 511 Ina Minei 512 Google, Inc. 513 1600 Amphitheatre Parkway 514 Mountain View, CA 94043 515 US 517 Email: inaminei@google.com 519 Siva Sivabalan 520 Cisco Systems, Inc. 521 2000 Innovation Drive 522 Kanata, Ontario K2K 3E8 523 Canada 525 Email: msiva@cisco.com