idnits 2.17.1 draft-ietf-teas-sr-rsvp-coexistence-rec-03.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 (April 25, 2018) is 2186 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: October 27, 2018 I. Minei 6 Google, Inc. 7 S. Sivabalan 8 Cisco Systems, Inc. 9 April 25, 2018 11 Recommendations for RSVP-TE and Segment Routing LSP co-existence 12 draft-ietf-teas-sr-rsvp-coexistence-rec-03.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 October 27, 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 . . . . . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Appendix A. Multiplier value range . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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. In most practical 99 instances given the static nature of the traffic demands, limiting 100 the available reservable bandwidth available to RSVP-TE has been an 101 acceptable solution. However, in the case of SR traffic, there is 102 assumed to be very dynamic traffic demands and there is considerable 103 risk associated with stranding capacity or overbooking service 104 traffic resulting in traffic drops. 106 The high level requirements or assumptions to consider are: 108 1. Placement of SR LSPs in the same domain as RSVP-TE LSPs MUST NOT 109 introduce inaccuracies in the TED used by distributed or 110 centralized path computation engines. 112 2. Engines that compute RSVP-TE paths may have no knowledge of the 113 existence of the SR paths in the same domain. 115 3. Engines that compute RSVP-TE paths SHOULD NOT require a software 116 upgrade or change to their path computation logic. 118 4. Protocol extensions SHOULD be avoided or be minimal as in many 119 cases this co-existence of RSVP-TE and SR MAY be needed only 120 during a transition phase. 122 5. Placement of SR LSPs in the same domain as RSVP-TE LSPs that are 123 computed in a distributed fashion MUST NOT require migration to a 124 central controller architecture for the RSVP-TE LSPs. 126 2. Conventions used in this document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 3. Solution options 136 3.1. Static partitioning of bandwidth 138 In this model, the static reservable bandwidth of an interface can be 139 statically partitioned between SR and RSVP-TE and each can operate 140 within that bandwidth allocation and SHOULD NOT preempt each other. 142 While it is possible to configure RSVP-TE to only reserve up to a 143 certain maximum link bandwidth and manage the remaining link 144 bandwidth for other services, this is a deployment where SR and RSVP- 145 TE are separated in the same network (ships in the night) and can 146 lead to suboptimal link bandwidth utilization not allowing each to 147 consume more, if required and constraining the respective 148 deployments. 150 The downside of this approach is the inability to use the reservable 151 bandwidth effectively and inability to use bandwidth left unused by 152 the other protocol. 154 3.2. Centralized management of available capacity 156 In this model, a central controller performs path placement for both 157 RSVP-TE and SR LSPs. The controller manages and updates its own view 158 of the in-use and the available capacity. As the controller is a 159 single common entity managing the network it can have a unified and 160 consistent view of the available capacity at all times. 162 A practical drawback of this model is that it requires the 163 introduction of a central controller managing the RSVP-TE LSPs as a 164 prerequisite to the deployment of any SR LSPs. Therefore, this 165 approach is not practical for networks where distributed TE with 166 RSVP-TE LSPs is already deployed, as it requires a redesign of the 167 network and is not backwards compatible. This does not satisfy 168 requirement 5. 170 Note that it is not enough for the controller to just maintain the 171 unified view of the available capacity, it must also perform the path 172 computation for the RSVP-TE LSPs, as the reservations for the SR LSPs 173 are not reflected in the TED. This does not fit with assumption 2 174 mentioned earlier. 176 3.3. Flooding SR utilization in IGP 178 Using techniques in [RFC7810], [RFC7471] and [RFC7823], the SR 179 utilization information can be flooded in IGP-TE and the RSVP-TE path 180 computation engine (CSPF) can be changed to consider this 181 information. This requires changes to the RSVP-TE path computation 182 logic and would require upgrades in deployments where distributed 183 computation is done across the network. 185 This does not fit with requirements 3 and 4 mentioned earlier. 187 3.4. Running SR over RSVP-TE 189 SR can run over dedicated RSVP-TE LSPs that carry only SR traffic. 190 In this model, the LSPs can be one-hop or multi-hop and can provide 191 bandwidth reservation for the SR traffic based on functionality such 192 as auto-bandwidth. The model of deployment would be similar in 193 nature to running LDP over RSVP-TE. This would allow the TED to stay 194 consistent across the network and any other RSVP-TE LSPs will also be 195 aware of the SR traffic reservations. In this approach, non-SR 196 traffic MUST NOT take the SR-dedicated RSVP-TE LSPs, unless required 197 by policy. 199 The drawback of this solution is that it requires SR to rely on RSVP- 200 TE for deployment. Furthermore, the accounting accuracy/frequency of 201 this method is dependent on performance of auto-bandwidth for RSVP- 202 TE. Note that for this method to work, the SR-dedicated RSVP-TE LSPs 203 must be set up with the best setup and hold priorities in the 204 network. 206 3.5. TED consistency by reflecting SR traffic 208 The solution relies on dynamically measuring SR traffic utilization 209 on each TE interface and reducing the bandwidth allowed for use by 210 RSVP-TE. It is assumed that SR traffic receives precedence in terms 211 of the placement on the path over RSVP traffic (that is, RSVP traffic 212 can be preempted from the path in case of insufficient resources). 213 This is logically equivalent to SR traffic having the best preemption 214 priority in the network. Note that this does not necessarily mean 215 that SR traffic has higher QoS priority, in fact, SR and RSVP traffic 216 may be in the same QoS class. 218 Reducing the bandwidth allowed for use by RSVP-TE can be explored 219 using the three parameters available in IGP-TE ([RFC5305],[RFC3630]), 220 namely Maximum-Link-Bandwidth, Maximum-Reservable-Bandwidth and 221 Unreserved-Bandwidth. 223 o Maximum-Link-Bandwidth: This parameter can be adjusted to 224 accommodate the bandwidth required for SR traffic with cascading 225 impacts on Maximum-Reservable-Bandwidth and Unreserved-Bandwidth. 226 However, changing the maximum bandwidth for the TE link will 227 prevent any compute engine for SR or RSVP from determining the 228 real static bandwidth of the TE link. Further, when the Maximum- 229 Reservable-Bandwidth is derived from the Maximum-Link-Bandwidth, 230 its definition changes since Maximum-Link-Bandwidth will account 231 for the SR traffic. 233 o Unreserved-Bandwidth: SR traffic could directly adjust the 234 Unreserved-Bandwidth, without impacting Maximum-Link-Bandwidth or 235 Maximum-Reservable-Bandwidth. This model is equivalent to the 236 option described in Section 3.4. Furthermore this would result in 237 overloading IGP-TE advertisements to directly reflect both RSVP-TE 238 bandwidth bookings and SR bandwidth measurements. 240 o Maximum-Reservable-Bandwidth: As the preferred option, SR traffic 241 could adjust the Maximum-Reservable-Bandwidth, with cascading 242 impact on the Unreserved-Bandwidth. 244 The following methodology can be used at every TE node for this 245 solution, using the following parameters: 247 o T: Traffic statistics collection time interval 249 o k: The number of traffic statistics samples that can provide a 250 smoothing function to the statistics collection. The value of k 251 is a constant integer multiplier greater or equal to 1. 253 o N: Traffic averaging calculation (adjustment) interval such that N 254 = k * T 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. The measured SR traffic 288 includes all labelled SR traffic and any traffic entering the SR 289 network over that TE interface. Further, at every interval N, given 290 a configured SR traffic threshold percentage and a set of collected 291 SR traffic statistics samples across the interval N, the SR traffic 292 average (or any other traffic metric depending on the algorithm used) 293 over this period is calculated. This method of sampling traffic 294 statistics and adjusting bandwidth reservation accordingly is similar 295 to how bandwidth gets adjusted for auto-bandwidth RSVP-TE LSPs. 297 If the difference between the new calculated SR traffic average and 298 the current SR traffic average (that was computed in the prior 299 adjustment) is at least SR traffic threshold percentage, then two 300 values MUST be updated: 302 o New Maximum-Reservable-Bandwidth = Initial Maximum-Reservable- 303 Bandwidth - (new SR traffic average * M) 305 o New RSVP-unreserved-bandwidth-at-priority-X = New Maximum- 306 Reservable-Bandwidth - sum of (existing reservations at priority X 307 and all priorities better than X) 309 A DS-TE LSR that advertises Bandwidth Constraints TLV should update 310 the bandwidth constraints for class-types based on operator policy. 311 For example, when Russian Dolls Model (RDM) [RFC4127] is in use, then 312 only BC0 may be updated. Whereas, when Maximum Allocation Model 313 (MAM) [RFC4125] is in use, then all BCs may be updated equally such 314 that the total value updated is equal to the newly calculated SR 315 traffic average. 317 Note that the computation of the new RSVP-unreserved-bandwidth-at- 318 priority-X MAY result in RSVP-TE LSPs being hard or soft preempted. 319 Such preemption will be based on relative priority (e.g. low to high) 320 between RSVP-TE LSPs. It is RECOMMENDED that the IGP-TE update 321 threshold SHOULD be lower in order to flood unreserved bandwidth 322 updates often. From an operational point of view, an implementation 323 SHOULD be able to expose both the configured and the actual values of 324 the Maximum-Reservable-Bandwidth. 326 If LSP preemption is not acceptable, then the RSVP-TE Maximum- 327 Reservable-Bandwidth cannot be reduced below what is currently 328 reserved by RSVP-TE on that interface. This may result in bandwidth 329 not being available for SR traffic. Thus, it is required that any 330 external controller managing SR LSPs SHOULD be able to detect this 331 situation (for example by subscribing to TED updates [RFC7752]) and 332 SHOULD take action to reroute existing SR paths. 334 Generically, SR traffic (or any non-RSVP-TE traffic) should have its 335 own priority allocated from the available priorities. This would 336 allow SR to preempt other traffic according to the preemption 337 priority order. 339 In this solution, the logic to retrieve the statistics, calculating 340 averages and taking action to change the Maximum-Reservable-Bandwidth 341 is an implementation choice, and all changes are local in nature. 342 However, note that this is a new network trigger for RSVP-TE 343 preemption and thus is a consideration for the operator. 345 The above solution offers the advantage of not introducing new 346 network-wide mechanisms especially during scenarios of migrating to 347 SR in an existing RSVP-TE network and reusing existing protocol 348 mechanisms. 350 4. Acknowledgements 352 The authors would like to thank Steve Ulrich for his detailed review 353 and comments. 355 5. Contributors 357 The following individuals contributed to this document: 359 Chandra Ramachandran 360 Juniper Networks 361 Email: csekar@juniper.net 363 Raveendra Torvi 364 Juniper Networks 365 Email: rtorvi@juniper.net 367 Sudharsana Venkataraman 368 Juniper Networks 369 Email: sudharsana@juniper.net 371 Martin Vigoureux 372 Nokia 373 Email: martin.vigoureux@nokia.com 375 6. IANA Considerations 377 This draft does not have any request for IANA. 379 7. Security Considerations 381 This document describes solution options for the co-existence of 382 RSVP-TE and SR LSPs in the same administrative domain. These 383 solution options do not require any new security considerations 384 beyond those that are already part of RSVP-TE and SR architectures. 385 With the solution specified in Section 3.5, a malicious party might 386 be able to use a hijacked SR traffic stream to cause disruption to 387 RSVP-TE LSPs. The defensive mechanisms described in the base RSVP-TE 388 and SR security frameworks could be employed to guard against 389 situations that result in traffic hijacking or denial of service. 390 The security requirements and mechanisms for SR are described in 391 [I-D.ietf-spring-segment-routing]. The security considerations 392 pertaining to RSVP-TE are described in [RFC5920]. 394 8. References 396 8.1. Normative References 398 [I-D.ietf-spring-segment-routing] 399 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 400 Litkowski, S., and R. Shakir, "Segment Routing 401 Architecture", draft-ietf-spring-segment-routing-15 (work 402 in progress), January 2018. 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, 406 DOI 10.17487/RFC2119, March 1997, 407 . 409 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 410 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 411 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 412 . 414 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 415 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 416 May 2017, . 418 8.2. Informative References 420 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 421 (TE) Extensions to OSPF Version 2", RFC 3630, 422 DOI 10.17487/RFC3630, September 2003, 423 . 425 [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of 426 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 427 DOI 10.17487/RFC4124, June 2005, 428 . 430 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth 431 Constraints Model for Diffserv-aware MPLS Traffic 432 Engineering", RFC 4125, DOI 10.17487/RFC4125, June 2005, 433 . 435 [RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints 436 Model for Diffserv-aware MPLS Traffic Engineering", 437 RFC 4127, DOI 10.17487/RFC4127, June 2005, 438 . 440 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 441 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 442 2008, . 444 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 445 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 446 . 448 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 449 Previdi, "OSPF Traffic Engineering (TE) Metric 450 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 451 . 453 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 454 S. Ray, "North-Bound Distribution of Link-State and 455 Traffic Engineering (TE) Information Using BGP", RFC 7752, 456 DOI 10.17487/RFC7752, March 2016, 457 . 459 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 460 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 461 RFC 7810, DOI 10.17487/RFC7810, May 2016, 462 . 464 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 465 "Performance-Based Path Selection for Explicitly Routed 466 Label Switched Paths (LSPs) Using TE Metric Extensions", 467 RFC 7823, DOI 10.17487/RFC7823, May 2016, 468 . 470 Appendix A. Multiplier value range 472 The following is a suggestion for the range of values for M: 474 M is a per-node positive real number that ranges from 0 to 2 with a 475 default of 1 and may be expressed as a percentage. 477 o If M < 1, then the SR traffic average is being understated, which 478 can result in the link getting full even though Maximum- 479 Reservable-Bandwidth does not reach zero. 481 o If M > 1, then the SR traffic average is overstated, thereby 482 resulting in the Maximum-Reservable-Bandwidth reaching zero before 483 the link gets full. If the reduction of Maximum-Reservable- 484 Bandwidth becomes a negative value, then a value of zero SHOULD be 485 used and advertised. 487 Authors' Addresses 489 Harish Sitaraman (editor) 490 Juniper Networks 491 1133 Innovation Way 492 Sunnyvale, CA 94089 493 US 495 Email: hsitaraman@juniper.net 497 Vishnu Pavan Beeram 498 Juniper Networks 499 10 Technology Park Drive 500 Westford, MA 01886 501 US 503 Email: vbeeram@juniper.net 504 Ina Minei 505 Google, Inc. 506 1600 Amphitheatre Parkway 507 Mountain View, CA 94043 508 US 510 Email: inaminei@google.com 512 Siva Sivabalan 513 Cisco Systems, Inc. 514 2000 Innovation Drive 515 Kanata, Ontario K2K 3E8 516 Canada 518 Email: msiva@cisco.com