idnits 2.17.1 draft-ietf-teas-sr-rsvp-coexistence-rec-02.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 (March 5, 2018) is 2243 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: September 6, 2018 I. Minei 6 Google, Inc. 7 S. Sivabalan 8 Cisco Systems, Inc. 9 March 5, 2018 11 Recommendations for RSVP-TE and Segment Routing LSP co-existence 12 draft-ietf-teas-sr-rsvp-coexistence-rec-02.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. In other cases, services running 22 on RSVP-TE might be migrated to run over SR. Such introduction or 23 migration of traffic to SR might require co-existence with RSVP-TE in 24 the same network for an extended period of time depending on the 25 operator's intent. The following document provides solution options 26 for keeping the traffic engineering database (TED) consistent across 27 the network, accounting for the different bandwidth utilization 28 between SR and RSVP-TE. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 6, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions used in this document . . . . . . . . . . . . . . 3 66 3. Solution options . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Static partitioning of bandwidth . . . . . . . . . . . . 3 68 3.2. Centralized management of available capacity . . . . . . 4 69 3.3. Flooding SR utilization in IGP . . . . . . . . . . . . . 4 70 3.4. Running SR over RSVP-TE . . . . . . . . . . . . . . . . . 5 71 3.5. TED consistency by reflecting SR traffic . . . . . . . . 5 72 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Appendix A. Multiplier value range . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 Introduction of SR [I-D.ietf-spring-segment-routing] in the same 85 network domain as RSVP-TE [RFC3209] presents the problem of 86 accounting for SR traffic and making RSVP-TE aware of the actual 87 available bandwidth on the network links. RSVP-TE is not aware of 88 how much bandwidth is being consumed by SR services on the network 89 links and hence both at computation time (for a distributed 90 computation) and at signaling time RSVP-TE LSPs will incorrectly 91 place loads. This is true where RSVP-TE paths are distributed or 92 centrally computed without a common entity managing both SR and RSVP- 93 TE computation for the entire network domain. 95 The problem space can be generalized as a dark bandwidth problem to 96 cases where any other service exists in the network that runs in 97 parallel across common links and whose bandwidth is not reflected in 98 the available and reserved values in the TED. The general problem is 99 management of dark bandwidth pools and can be generalized to cases 100 where any other service exists in the network that runs in parallel 101 across common links and whose bandwidth is not reflected in the 102 available and reserved values in the TED. In most practical 103 instances given the static nature of the traffic demands, limiting 104 the available reservable bandwidth available to RSVP-TE has been an 105 acceptable solution. However, in the case of SR traffic, there is 106 assumed to be very dynamic traffic demands and there is considerable 107 risk associated with stranding capacity or overbooking service 108 traffic resulting in traffic drops. 110 The high level requirements or assumptions to consider are: 112 1. Placement of SR LSPs in the same domain as RSVP-TE LSPs MUST NOT 113 introduce inaccuracies in the TED used by distributed or 114 centralized path computation engines. 116 2. Engines that compute RSVP-TE paths MAY have no knowledge of the 117 existence of the SR paths in the same domain. 119 3. Engines that compute RSVP-TE paths SHOULD NOT require a software 120 upgrade or change to their path computation logic. 122 4. Protocol extensions SHOULD be avoided or be minimal as in many 123 cases this co-existence of RSVP-TE and SR MAY be needed only 124 during a transition phase. 126 5. Placement of SR LSPs in the same domain as RSVP-TE LSPs that are 127 computed in a distributed fashion MUST NOT require migration to a 128 central controller architecture for the RSVP-TE LSPs. 130 2. Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 3. Solution options 138 3.1. Static partitioning of bandwidth 140 In this model, the static reservable bandwidth of an interface can be 141 statically partitioned between SR and RSVP-TE and each can operate 142 within that bandwidth allocation and SHOULD NOT preempt each other. 144 While it is possible to configure RSVP-TE to only reserve up to a 145 certain maximum link bandwidth and manage the remaining link 146 bandwidth for other services, this is a deployment where SR and RSVP- 147 TE are separated in the same network (ships in the night) and can 148 lead to suboptimal link bandwidth utilization not allowing each to 149 consume more, if required and constraining the respective 150 deployments. 152 The downside of this approach is the inability to use the reservable 153 bandwidth effectively and inability to use bandwidth left unused by 154 the other protocol. 156 3.2. Centralized management of available capacity 158 In this model, a central controller performs path placement for both 159 RSVP-TE and SR LSPs. The controller manages and updates its own view 160 of the in-use and the available capacity. As the controller is a 161 single common entity managing the network it can have a unified and 162 consistent view of the available capacity at all times. 164 A practical drawback of this model is that it requires the 165 introduction of a central controller managing the RSVP-TE LSPs as a 166 prerequisite to the deployment of any SR LSPs. Therefore, this 167 approach is not practical for networks where distributed TE with 168 RSVP-TE LSPs is already deployed, as it requires a redesign of the 169 network and is not backwards compatible. This does not satisfy 170 requirement 5. 172 Note that it is not enough for the controller to just maintain the 173 unified view of the available capacity, it must also perform the path 174 computation for the RSVP-TE LSPs, as the reservations for the SR LSPs 175 are not reflected in the TED. This does not fit with assumption 2 176 mentioned earlier. 178 3.3. Flooding SR utilization in IGP 180 Using techniques in [RFC7810], [RFC7471] and [RFC7823], the SR 181 utilization information can be flooded in IGP-TE and the RSVP-TE path 182 computation engine (CSPF) can be changed to consider this 183 information. This requires changes to the RSVP-TE path computation 184 logic and would require upgrades in deployments where distributed 185 computation is done across the network. 187 This does not fit with requirements 3 and 4 mentioned earlier. 189 3.4. Running SR over RSVP-TE 191 SR can run over dedicated RSVP-TE LSPs that carry only SR traffic. 192 In this model, the LSPs can be one-hop or multi-hop and can provide 193 bandwidth reservation for the SR traffic based on functionality such 194 as auto-bandwidth. The model of deployment would be similar in 195 nature to running LDP over RSVP-TE. This would allow the TED to stay 196 consistent across the network and any other RSVP-TE LSPs will also be 197 aware of the SR traffic reservations. In this approach, non-SR 198 traffic MUST NOT take the SR-dedicated RSVP-TE LSPs, unless required 199 by policy. 201 The drawback of this solution is that it requires SR to rely on RSVP- 202 TE for deployment. Furthermore, the accounting accuracy/frequency of 203 this method is dependent on performance of auto-bandwidth for RSVP- 204 TE. Note that for this method to work, the SR-dedicated RSVP-TE LSPs 205 must be set up with the best setup and hold priorities in the 206 network. 208 3.5. TED consistency by reflecting SR traffic 210 The solution relies on dynamically measuring SR traffic utilization 211 on each TE interface and reducing the bandwidth allowed for use by 212 RSVP-TE. It is assumed that SR traffic receives precedence in terms 213 of the placement on the path over RSVP traffic (that is, RSVP traffic 214 can be preempted from the path in case of insufficient resources). 215 This is logically equivalent to SR traffic having the best preemption 216 priority in the network. Note that this does not necessarily mean 217 that SR traffic has higher QoS priority, in fact, SR and RSVP traffic 218 may be in the same QoS class. 220 Reducing the bandwidth allowed for use by RSVP-TE can be explored 221 using the three parameters available in IGP-TE ([RFC5305],[RFC3630]), 222 namely Maximum-Link-Bandwidth, Maximum-Reservable-Bandwidth and 223 Unreserved-Bandwidth. 225 o Maximum-Link-Bandwidth: This parameter can be adjusted to 226 accommodate the bandwidth required for SR traffic with cascading 227 impacts on Maximum-Reservable-Bandwidth and Unreserved-Bandwidth. 228 However, changing the maximum bandwidth for the TE link will 229 prevent any compute engine for SR or RSVP to decipher the real 230 static bandwidth of the TE link. Further, when the Maximum- 231 Reservable-Bandwidth is derived from the Maximum-Link-Bandwidth, 232 its definition changes since Maximum-Link-Bandwidth will account 233 for the SR traffic. 235 o Unreserved-Bandwidth: SR traffic could directly adjust the 236 Unreserved-Bandwidth, without impacting Maximum-Link-Bandwidth or 237 Maximum-Reservable-Bandwidth. This model is equivalent to the 238 option described in Section 3.4. Furthermore this would result in 239 overloading IGP-TE advertisements to directly reflect both RSVP-TE 240 bandwidth bookings and SR bandwidth measurements. 242 o Maximum-Reservable-Bandwidth: As the preferred option, SR traffic 243 could adjust the Maximum-Reservable-Bandwidth, with cascading 244 impact on the Unreserved-Bandwidth. 246 The following methodology can be used at every TE node for this 247 solution: 249 o T: Traffic statistics collection time interval 251 o N: Traffic averaging calculation (adjustment) interval such that N 252 = k * T, where k is a constant integer multiplier greater or equal 253 to 1. Its purpose is to provide a smoothing function to the 254 statistics collection. 256 o Maximum-Reservable-Bandwidth: The maximum available bandwidth for 257 RSVP-TE. 259 If Differentiated-Service (Diffserv)-aware MPLS Traffic 260 Engineering (DS-TE) [RFC4124] is enabled, the Maximum-Reservable- 261 Bandwidth SHOULD be interpreted as the aggregate bandwidth 262 constraint across all Class-Types independent of the Bandwidth 263 Constraints model. 265 o Initial Maximum-Reservable-Bandwidth: The Maximum-reservable- 266 bandwidth for TE when no SR traffic or RSVP-TE reservations exist 267 on the interface. 269 o RSVP-unreserved-bandwidth-at-priority-X: Maximum-Reservable- 270 Bandwidth - sum of (existing reservations at priority X and all 271 priorities better than X) 273 o SR traffic threshold percentage: The percentage difference of 274 traffic demand that when exceeded can result in a change to the 275 RSVP-TE Maximum-Reservable-Bandwidth 277 o IGP-TE update threshold: Specifies the frequency at which IGP-TE 278 updates should be triggered based on TE bandwidth updates on a 279 link 281 o M: An optional multiplier that can be applied to the SR traffic 282 average. This multiplier provides the ability to grow or shrink 283 the bandwidth used by SR. Appendix A offers further guidance on 284 M. 286 At every interval T, each node SHOULD collect the SR traffic 287 statistics for each of its TE interfaces. Further, at every interval 288 N, given a configured SR traffic threshold percentage and a set of 289 collected SR traffic statistics samples across the interval N, the SR 290 traffic average (or any other traffic metric depending on the 291 algorithm used) over this period is calculated. 293 If the difference between the new calculated SR traffic average and 294 the current SR traffic average (that was computed in the prior 295 adjustment) is at least SR traffic threshold percentage, then two 296 values MUST be updated: 298 o New Maximum-Reservable-Bandwidth = Initial Maximum-Reservable- 299 Bandwidth - (new SR traffic average * M) 301 o New RSVP-unreserved-bandwidth-at-priority-X = New Maximum- 302 Reservable-Bandwidth - sum of (existing reservations at priority X 303 and all priorities better than X) 305 A DS-TE LSR that advertises Bandwidth Constraints TLV should update 306 the bandwidth constraints for class-types based on operator policy. 307 For example, when Russian Dolls Model (RDM) [RFC4127] is in use, then 308 only BC0 may be updated. Whereas, when Maximum Allocation Model 309 (MAM) [RFC4125] is in use, then all BCs may be updated equally such 310 that the total value updated is equal to the newly calculated SR 311 traffic average. 313 Note that the computation of the new RSVP-unreserved-bandwidth-at- 314 priority-X MAY result in RSVP-TE LSPs being hard or soft preempted. 315 Such preemption will be based on relative priority (e.g. low to high) 316 between RSVP-TE LSPs. It is RECOMMENDED that the IGP-TE update 317 threshold SHOULD be lower in order to flood unreserved bandwidth 318 updates often. From an operational point of view, an implementation 319 SHOULD be able to expose both the configured and the actual values of 320 the Maximum-Reservable-Bandwidth. 322 If LSP preemption is not acceptable, then the RSVP-TE Maximum- 323 Reservable-Bandwidth cannot be reduced below what is currently 324 reserved by RSVP-TE on that interface. This may result in bandwidth 325 not being available for SR traffic. Thus, it is required that any 326 external controller managing SR LSPs SHOULD be able to detect this 327 situation (for example by subscribing to TED updates [RFC7752]) and 328 SHOULD take action to reroute existing SR paths. 330 Generically, SR traffic (or any non-RSVP-TE traffic) should have its 331 own priority allocated from the available priorities. This would 332 allow SR to preempt other traffic according to the preemption 333 priority order. 335 In this solution, the logic to retrieve the statistics, calculating 336 averages and taking action to change the Maximum-Reservable-Bandwidth 337 is an implementation choice, and all changes are local in nature. 338 However, note that this is a new network trigger for RSVP-TE 339 preemption and thus is a consideration for the operator. 341 The above solution offers the advantage of not introducing new 342 network-wide mechanisms especially during scenarios of migrating to 343 SR in an existing RSVP-TE network and reusing existing protocol 344 mechanisms. 346 4. Acknowledgements 348 The authors would like to thank Steve Ulrich for his detailed review 349 and comments. 351 5. Contributors 353 The following individuals contributed to this document: 355 Chandra Ramachandran 356 Juniper Networks 357 Email: csekar@juniper.net 359 Raveendra Torvi 360 Juniper Networks 361 Email: rtorvi@juniper.net 363 Sudharsana Venkataraman 364 Juniper Networks 365 Email: sudharsana@juniper.net 367 Martin Vigoureux 368 Nokia 369 Email: martin.vigoureux@nokia.com 371 6. IANA Considerations 373 This draft does not have any request for IANA. 375 7. Security Considerations 377 No new security issues are introduced in this document beyond is 378 already part of RSVP-TE and Segment routing architectures. 380 8. References 382 8.1. Normative References 384 [I-D.ietf-spring-segment-routing] 385 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 386 Litkowski, S., and R. Shakir, "Segment Routing 387 Architecture", draft-ietf-spring-segment-routing-15 (work 388 in progress), January 2018. 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, 392 DOI 10.17487/RFC2119, March 1997, 393 . 395 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 396 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 397 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 398 . 400 8.2. Informative References 402 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 403 (TE) Extensions to OSPF Version 2", RFC 3630, 404 DOI 10.17487/RFC3630, September 2003, 405 . 407 [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of 408 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 409 DOI 10.17487/RFC4124, June 2005, 410 . 412 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth 413 Constraints Model for Diffserv-aware MPLS Traffic 414 Engineering", RFC 4125, DOI 10.17487/RFC4125, June 2005, 415 . 417 [RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints 418 Model for Diffserv-aware MPLS Traffic Engineering", 419 RFC 4127, DOI 10.17487/RFC4127, June 2005, 420 . 422 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 423 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 424 2008, . 426 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 427 Previdi, "OSPF Traffic Engineering (TE) Metric 428 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 429 . 431 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 432 S. Ray, "North-Bound Distribution of Link-State and 433 Traffic Engineering (TE) Information Using BGP", RFC 7752, 434 DOI 10.17487/RFC7752, March 2016, 435 . 437 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 438 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 439 RFC 7810, DOI 10.17487/RFC7810, May 2016, 440 . 442 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 443 "Performance-Based Path Selection for Explicitly Routed 444 Label Switched Paths (LSPs) Using TE Metric Extensions", 445 RFC 7823, DOI 10.17487/RFC7823, May 2016, 446 . 448 Appendix A. Multiplier value range 450 The following is a suggestion for the range of values for M: 452 M is a per-node positive real number that ranges from 0 to 2 with a 453 default of 1 and may be expressed as a percentage. 455 o If M < 1, then the SR traffic average is being understated, which 456 can result in the link getting full even though Maximum- 457 Reservable-Bandwidth does not reach zero. 459 o If M > 1, then the SR traffic average is overstated, thereby 460 resulting in the Maximum-Reservable-Bandwidth reaching zero before 461 the link gets full. If the reduction of Maximum-Reservable- 462 Bandwidth becomes a negative value, then a value of zero SHOULD be 463 used and advertised. 465 Authors' Addresses 467 Harish Sitaraman (editor) 468 Juniper Networks 469 1133 Innovation Way 470 Sunnyvale, CA 94089 471 US 473 Email: hsitaraman@juniper.net 474 Vishnu Pavan Beeram 475 Juniper Networks 476 10 Technology Park Drive 477 Westford, MA 01886 478 US 480 Email: vbeeram@juniper.net 482 Ina Minei 483 Google, Inc. 484 1600 Amphitheatre Parkway 485 Mountain View, CA 94043 486 US 488 Email: inaminei@google.com 490 Siva Sivabalan 491 Cisco Systems, Inc. 492 2000 Innovation Drive 493 Kanata, Ontario K2K 3E8 494 Canada 496 Email: msiva@cisco.com