idnits 2.17.1 draft-sitaraman-sr-rsvp-coexistence-rec-01.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 (September 6, 2016) is 2789 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-09 -- 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: March 10, 2017 I. Minei 6 Google, Inc. 7 S. Sivabalan 8 Cisco Systems, Inc. 9 September 6, 2016 11 Recommendations for RSVP-TE and Segment Routing LSP co-existence 12 draft-sitaraman-sr-rsvp-coexistence-rec-01.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 March 10, 2017. 47 Copyright Notice 49 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . 7 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 8.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 o RSVP-unreserved-bandwidth-at-priority-X: Maximum-Reservable- 232 Bandwidth - sum of (existing reservations at priority X and all 233 priorities better than X) 235 o SR traffic threshold percentage: The percentage difference of 236 traffic demand that when exceeded can result in a change to the 237 RSVP-TE Maximum-Reservable-Bandwidth 239 o IGP-TE update threshold: Specifies the frequency at which IGP-TE 240 updates should be triggered based on TE bandwidth updates on a 241 link 243 o M: An optional multiplier that can be applied to the SR traffic 244 average. This multiplier provides the ability to grow or shrink 245 the bandwidth used by SR 247 At every interval T, each node SHOULD collect the SR traffic 248 statistics for each of its TE interfaces. Further, at every interval 249 N, given a configured SR traffic threshold percentage and a set of 250 collected SR traffic statistics samples across the interval N, the SR 251 traffic average (or any other traffic metric depending on the 252 algorithm used) over this period is calculated. 254 If the difference between the new calculated SR traffic average and 255 the current SR traffic average (that was computed in the prior 256 adjustment) is at least SR traffic threshold percentage, then two 257 values MUST be updated: 259 o New Maximum-Reservable-Bandwidth = Current Maximum-Reservable- 260 Bandwidth - (SR traffic average * M) 262 o New RSVP-unreserved-bandwidth-at-priority-X = New Maximum- 263 Reservable-Bandwidth - sum of (existing reservations at priority X 264 and all priorities better than X) 266 Note that the computation of the new RSVP-unreserved-bandwidth-at- 267 priority-X MAY result in RSVP-TE LSPs being hard or soft preempted. 268 Such preemption will be based on relative priority (e.g. low to high) 269 between RSVP-TE LSPs. It is RECOMMENDED that the IGP-TE update 270 threshold SHOULD be lower in order to flood unreserved bandwidth 271 updates often. From an operational point of view, an implementation 272 SHOULD be able to expose both the configured and the actual values of 273 the Maximum-Reservable-Bandwidth. 275 If LSP preemption is not acceptable, then the RSVP-TE Maximum- 276 Reservable-Bandwidth cannot be reduced below what is currently 277 reserved by RSVP-TE on that interface. This may result in bandwidth 278 not being available for SR traffic. Thus, it is required that any 279 external controller managing SR LSPs SHOULD be able to detect this 280 situation (for example by subscribing to TED updates [RFC7752]) and 281 SHOULD take action to reroute existing SR paths. 283 Generically, SR traffic (or any non-RSVP-TE traffic) should have its 284 own priority allocated from the available priorities. This would 285 allow SR to preempt other traffic according to the preemption 286 priority order. 288 In this solution, the logic to retrieve the statistics, calculating 289 averages and taking action to change the Maximum-Reservable-Bandwidth 290 is an implementation choice, and all changes are local in nature. 291 However, note that this is a new network trigger for RSVP-TE 292 preemption and thus is a consideration for the operator. 294 The above solution offers the advantage of not introducing new 295 network-wide mechanisms especially during scenarios of migrating to 296 SR in an existing RSVP-TE network and reusing existing protocol 297 mechanisms. 299 4. Acknowledgements 301 The authors would like to thank Steve Ulrich for his detailed review 302 and comments. 304 5. Contributors 306 The following individuals contributed to this document: 308 Chandra Ramachandran 309 Juniper Networks 310 Email: csekar@juniper.net 312 Raveendra Torvi 313 Juniper Networks 314 Email: rtorvi@juniper.net 316 Sudharsana Venkataraman 317 Juniper Networks 318 Email: sudharsana@juniper.net 320 6. IANA Considerations 322 This draft does not have any request for IANA. 324 7. Security Considerations 326 No new security issues are introduced in this document beyond is 327 already part of RSVP-TE and Segment routing architectures. 329 8. References 331 8.1. Normative References 333 [I-D.ietf-spring-segment-routing] 334 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 335 and R. Shakir, "Segment Routing Architecture", draft-ietf- 336 spring-segment-routing-09 (work in progress), July 2016. 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, 340 DOI 10.17487/RFC2119, March 1997, 341 . 343 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 344 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 345 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 346 . 348 8.2. Informative References 350 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 351 Previdi, "OSPF Traffic Engineering (TE) Metric 352 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 353 . 355 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 356 S. Ray, "North-Bound Distribution of Link-State and 357 Traffic Engineering (TE) Information Using BGP", RFC 7752, 358 DOI 10.17487/RFC7752, March 2016, 359 . 361 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 362 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 363 RFC 7810, DOI 10.17487/RFC7810, May 2016, 364 . 366 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 367 "Performance-Based Path Selection for Explicitly Routed 368 Label Switched Paths (LSPs) Using TE Metric Extensions", 369 RFC 7823, DOI 10.17487/RFC7823, May 2016, 370 . 372 Authors' Addresses 373 Harish Sitaraman (editor) 374 Juniper Networks 375 1133 Innovation Way 376 Sunnyvale, CA 94089 377 US 379 Email: hsitaraman@juniper.net 381 Vishnu Pavan Beeram 382 Juniper Networks 383 10 Technology Park Drive 384 Westford, MA 01886 385 US 387 Email: vbeeram@juniper.net 389 Ina Minei 390 Google, Inc. 391 1600 Amphitheatre Parkway 392 Mountain View, CA 94043 393 US 395 Email: inaminei@google.com 397 Siva Sivabalan 398 Cisco Systems, Inc. 399 2000 Innovation Drive 400 Kanata, Ontario K2K 3E8 401 Canada 403 Email: msiva@cisco.com