idnits 2.17.1 draft-ietf-teas-sr-rsvp-coexistence-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 (May 23, 2017) is 2529 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 -- 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 (~~), 2 warnings (==), 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 24, 2017 I. Minei 6 Google, Inc. 7 S. Sivabalan 8 Cisco Systems, Inc. 9 May 23, 2017 11 Recommendations for RSVP-TE and Segment Routing LSP co-existence 12 draft-ietf-teas-sr-rsvp-coexistence-rec-00.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 http://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 November 24, 2017. 47 Copyright Notice 49 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . 7 73 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 8.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 TED. The general problem is 98 management of dark bandwidth pools and can be generalized to cases 99 where any other service exists in the network that runs in parallel 100 across common links and whose bandwidth is not reflected in the 101 available and reserved values in the TED. In most practical 102 instances given the static nature of the traffic demands, limiting 103 the available reservable bandwidth available to RSVP-TE has been an 104 acceptable solution. However, in the case of SR traffic, there is 105 assumed to be very dynamic traffic demands and there is considerable 106 risk associated with stranding capacity or overbooking service 107 traffic resulting in traffic drops. 109 The high level requirements or assumptions to consider are: 111 1. Placement of SR LSPs in the same domain as RSVP-TE LSPs MUST NOT 112 introduce inaccuracies in the TED used by distributed or 113 centralized path computation engines. 115 2. Engines that compute RSVP-TE paths MAY have no knowledge of the 116 existence of the SR paths in the same domain. 118 3. Engines that compute RSVP-TE paths SHOULD NOT require a software 119 upgrade or change to their path computation logic. 121 4. Protocol extensions SHOULD be avoided or be minimal as in many 122 cases this co-existence of RSVP-TE and SR MAY be needed only 123 during a transition phase. 125 5. Placement of SR LSPs in the same domain as RSVP-TE LSPs that are 126 computed in a distributed fashion MUST NOT require migration to a 127 central controller architecture for the RSVP-TE LSPs. 129 2. Conventions used in this document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 3. Solution options 137 3.1. Static partitioning of bandwidth 139 In this model, the static reservable bandwidth of an interface can be 140 statically partitioned between SR and RSVP-TE and each can operate 141 within that bandwidth allocation and SHOULD NOT preempt each other. 143 While it is possible to configure RSVP-TE to only reserve up to a 144 certain maximum link bandwidth and manage the remaining link 145 bandwidth for other services, this is a deployment where SR and RSVP- 146 TE are separated in the same network (ships in the night) and can 147 lead to suboptimal link bandwidth utilization not allowing each to 148 consume more, if required and constraining the respective 149 deployments. 151 The downside of this approach is the inability to use the reservable 152 bandwidth effectively and inability to use bandwidth left unused by 153 the other protocol. 155 3.2. Centralized management of available capacity 157 In this model, a central controller performs path placement for both 158 RSVP-TE and SR LSPs. The controller manages and updates its own view 159 of the in-use and the available capacity. As the controller is a 160 single common entity managing the network it can have a unified and 161 consistent view of the available capacity at all times. 163 A practical drawback of this model is that it requires the 164 introduction of a central controller managing the RSVP-TE LSPs as a 165 prerequisite to the deployment of any SR LSPs. Therefore, this 166 approach is not practical for networks where distributed TE with 167 RSVP-TE LSPs is already deployed, as it requires a redesign of the 168 network and is not backwards compatible. This does not satisfy 169 requirement 5. 171 Note that it is not enough for the controller to just maintain the 172 unified view of the available capacity, it must also perform the path 173 computation for the RSVP-TE LSPs, as the reservations for the SR LSPs 174 are not reflected in the TED. This does not fit with assumption 2 175 mentioned earlier. 177 3.3. Flooding SR utilization in IGP 179 Using techniques in [RFC7810], [RFC7471] and [RFC7823], the SR 180 utilization information can be flooded in IGP-TE and the RSVP-TE path 181 computation engine (CSPF) can be changed to consider this 182 information. This requires changes to the RSVP-TE path computation 183 logic and would require upgrades in deployments where distributed 184 computation is done across the network. 186 This does not fit with requirements 3 and 4 mentioned earlier. 188 3.4. Running SR over RSVP-TE 190 SR can run over dedicated RSVP-TE LSPs that carry only SR traffic. 191 In this model, the LSPs can be one-hop or multi-hop and can provide 192 bandwidth reservation for the SR traffic based on functionality such 193 as auto-bandwidth. The model of deployment would be similar in 194 nature to running LDP over RSVP-TE. This would allow the TED to stay 195 consistent across the network and any other RSVP-TE LSPs will also be 196 aware of the SR traffic reservations. In this approach, non-SR 197 traffic MUST NOT take the SR-dedicated RSVP-TE LSPs, unless required 198 by policy. 200 The drawback of this solution is that it requires SR to rely on RSVP- 201 TE for deployment. Furthermore, the accounting accuracy/frequency of 202 this method is dependent on performance of auto-bandwidth for RSVP- 203 TE. Note that for this method to work, the SR-dedicated RSVP-TE LSPs 204 must be set up with the best setup and hold priorities in the 205 network. 207 3.5. TED consistency by reflecting SR traffic 209 The solution relies on dynamically measuring SR traffic utilization 210 on each TE interface and reducing the bandwidth allowed for use by 211 RSVP-TE. It is assumed that SR traffic receives precedence in terms 212 of the placement on the path over RSVP traffic (that is, RSVP traffic 213 can be preempted from the path in case of insufficient resources). 214 This is logically equivalent to SR traffic having the best preemption 215 priority in the network. Note that this does not necessarily mean 216 that SR traffic has higher QoS priority, in fact, SR and RSVP traffic 217 may be in the same QoS class. The following methodology can be used 218 at every TE node for this solution: 220 o T: Traffic statistics collection time interval 222 o N: Traffic averaging calculation (adjustment) interval such that N 223 = k * T, where k is a constant integer multiplier greater or equal 224 to 1. Its purpose is to provide a smoothing function to the 225 statistics collection. 227 o Maximum-Reservable-Bandwidth: The maximum available bandwidth for 228 TE (this is the maximum available bandwidth on the interface, 229 before any LSP reservations). 231 If Differentiated-Service (Diffserv)-aware MPLS Traffic 232 Engineering (DS-TE) [RFC4124] is enabled, the Maximum-Reservable- 233 Bandwidth SHOULD be interpreted as the aggregate bandwidth 234 constraint across all Class-Types independent of the Bandwidth 235 Constraints model. 237 o RSVP-unreserved-bandwidth-at-priority-X: Maximum-Reservable- 238 Bandwidth - sum of (existing reservations at priority X and all 239 priorities better than X) 241 o SR traffic threshold percentage: The percentage difference of 242 traffic demand that when exceeded can result in a change to the 243 RSVP-TE Maximum-Reservable-Bandwidth 245 o IGP-TE update threshold: Specifies the frequency at which IGP-TE 246 updates should be triggered based on TE bandwidth updates on a 247 link 249 o M: An optional multiplier that can be applied to the SR traffic 250 average. This multiplier provides the ability to grow or shrink 251 the bandwidth used by SR 253 At every interval T, each node SHOULD collect the SR traffic 254 statistics for each of its TE interfaces. Further, at every interval 255 N, given a configured SR traffic threshold percentage and a set of 256 collected SR traffic statistics samples across the interval N, the SR 257 traffic average (or any other traffic metric depending on the 258 algorithm used) over this period is calculated. 260 If the difference between the new calculated SR traffic average and 261 the current SR traffic average (that was computed in the prior 262 adjustment) is at least SR traffic threshold percentage, then two 263 values MUST be updated: 265 o New Maximum-Reservable-Bandwidth = Current Maximum-Reservable- 266 Bandwidth - (SR traffic average * M) 268 o New RSVP-unreserved-bandwidth-at-priority-X = New Maximum- 269 Reservable-Bandwidth - sum of (existing reservations at priority X 270 and all priorities better than X) 272 A DS-TE LSR that advertises Bandwidth Constraints TLV should update 273 the bandwidth constraints for class-types based on operator policy. 274 For example, when Russian Dolls Model (RDM) [RFC4127] is in use, then 275 only BC0 may be updated. Whereas, when Maximum Allocation Model 276 (MAM) [RFC4125] is in use, then all BCs may be updated equally such 277 that the total value updated is equal to the newly calculated SR 278 traffic average. 280 Note that the computation of the new RSVP-unreserved-bandwidth-at- 281 priority-X MAY result in RSVP-TE LSPs being hard or soft preempted. 282 Such preemption will be based on relative priority (e.g. low to high) 283 between RSVP-TE LSPs. It is RECOMMENDED that the IGP-TE update 284 threshold SHOULD be lower in order to flood unreserved bandwidth 285 updates often. From an operational point of view, an implementation 286 SHOULD be able to expose both the configured and the actual values of 287 the Maximum-Reservable-Bandwidth. 289 If LSP preemption is not acceptable, then the RSVP-TE Maximum- 290 Reservable-Bandwidth cannot be reduced below what is currently 291 reserved by RSVP-TE on that interface. This may result in bandwidth 292 not being available for SR traffic. Thus, it is required that any 293 external controller managing SR LSPs SHOULD be able to detect this 294 situation (for example by subscribing to TED updates [RFC7752]) and 295 SHOULD take action to reroute existing SR paths. 297 Generically, SR traffic (or any non-RSVP-TE traffic) should have its 298 own priority allocated from the available priorities. This would 299 allow SR to preempt other traffic according to the preemption 300 priority order. 302 In this solution, the logic to retrieve the statistics, calculating 303 averages and taking action to change the Maximum-Reservable-Bandwidth 304 is an implementation choice, and all changes are local in nature. 305 However, note that this is a new network trigger for RSVP-TE 306 preemption and thus is a consideration for the operator. 308 The above solution offers the advantage of not introducing new 309 network-wide mechanisms especially during scenarios of migrating to 310 SR in an existing RSVP-TE network and reusing existing protocol 311 mechanisms. 313 4. Acknowledgements 315 The authors would like to thank Steve Ulrich for his detailed review 316 and comments. 318 5. Contributors 320 The following individuals contributed to this document: 322 Chandra Ramachandran 323 Juniper Networks 324 Email: csekar@juniper.net 326 Raveendra Torvi 327 Juniper Networks 328 Email: rtorvi@juniper.net 330 Sudharsana Venkataraman 331 Juniper Networks 332 Email: sudharsana@juniper.net 334 6. IANA Considerations 336 This draft does not have any request for IANA. 338 7. Security Considerations 340 No new security issues are introduced in this document beyond is 341 already part of RSVP-TE and Segment routing architectures. 343 8. References 345 8.1. Normative References 347 [I-D.ietf-spring-segment-routing] 348 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 349 and R. Shakir, "Segment Routing Architecture", draft-ietf- 350 spring-segment-routing-11 (work in progress), February 351 2017. 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 359 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 360 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 361 . 363 8.2. Informative References 365 [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of 366 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 367 DOI 10.17487/RFC4124, June 2005, 368 . 370 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth 371 Constraints Model for Diffserv-aware MPLS Traffic 372 Engineering", RFC 4125, DOI 10.17487/RFC4125, June 2005, 373 . 375 [RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints 376 Model for Diffserv-aware MPLS Traffic Engineering", 377 RFC 4127, DOI 10.17487/RFC4127, June 2005, 378 . 380 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 381 Previdi, "OSPF Traffic Engineering (TE) Metric 382 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 383 . 385 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 386 S. Ray, "North-Bound Distribution of Link-State and 387 Traffic Engineering (TE) Information Using BGP", RFC 7752, 388 DOI 10.17487/RFC7752, March 2016, 389 . 391 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 392 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 393 RFC 7810, DOI 10.17487/RFC7810, May 2016, 394 . 396 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 397 "Performance-Based Path Selection for Explicitly Routed 398 Label Switched Paths (LSPs) Using TE Metric Extensions", 399 RFC 7823, DOI 10.17487/RFC7823, May 2016, 400 . 402 Authors' Addresses 404 Harish Sitaraman (editor) 405 Juniper Networks 406 1133 Innovation Way 407 Sunnyvale, CA 94089 408 US 410 Email: hsitaraman@juniper.net 412 Vishnu Pavan Beeram 413 Juniper Networks 414 10 Technology Park Drive 415 Westford, MA 01886 416 US 418 Email: vbeeram@juniper.net 419 Ina Minei 420 Google, Inc. 421 1600 Amphitheatre Parkway 422 Mountain View, CA 94043 423 US 425 Email: inaminei@google.com 427 Siva Sivabalan 428 Cisco Systems, Inc. 429 2000 Innovation Drive 430 Kanata, Ontario K2K 3E8 431 Canada 433 Email: msiva@cisco.com