idnits 2.17.1 draft-sitaraman-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1. Placement of SR LSPs in the same domain as RSVP-TE LSPs MUST not introduce inaccuracies in the TED used by distributed or centralized path computation engines. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 3. Engines that compute RSVP-TE paths SHOULD not require a software upgrade or change to their path computation logic. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 5. Placement of SR LSPs in the same domain as RSVP-TE LSPs that are computed in a distributed fashion MUST not require migration to a central controller architecture for the RSVP-TE LSPs. -- The document date (July 18, 2016) is 2833 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 (~~), 5 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: January 19, 2017 I. Minei 6 Google, Inc. 7 July 18, 2016 9 Recommendations for RSVP-TE and Segment Routing LSP co-existence 10 draft-sitaraman-sr-rsvp-coexistence-rec-00.txt 12 Abstract 14 Operators are looking to introduce services over Segment Routing (SR) 15 LSPs in networks running Resource Reservation Protocol (RSVP-TE) 16 LSPs. In some instances, operators are also migrating existing 17 services from RSVP-TE to SR LSPs. For example, there might be 18 certain services that are well suited for SR and need to co-exist 19 with RSVP-TE in the same network. In other cases, services running 20 on RSVP-TE might be migrated to run over SR. Such introduction or 21 migration of traffic to SR might require co-existence with RSVP-TE in 22 the same network for an extended period of time depending on the 23 operator's intent. The following document provides solution options 24 for keeping the traffic engineering database (TED) consistent across 25 the network, accounting for the different bandwidth utilization 26 between SR and RSVP-TE. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 19, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions used in this document . . . . . . . . . . . . . . 3 64 3. Solution options . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Partitioning of static bandwidth . . . . . . . . . . . . 3 66 3.2. Centralized management of available capacity . . . . . . 4 67 3.3. Flooding SR utilization in IGP . . . . . . . . . . . . . 4 68 3.4. Running SR over RSVP-TE . . . . . . . . . . . . . . . . . 4 69 3.5. TED consistency by reducing RSVP-TE subscription . . . . 5 70 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 8.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 Introduction of SR [I-D.ietf-spring-segment-routing] in the same 82 network domain as RSVP-TE [RFC3209] presents the problem of 83 accounting for SR traffic and making RSVP-TE aware of the actual 84 available bandwidth on the network links. RSVP-TE is not aware of 85 how much bandwidth is being consumed by SR services on the network 86 links and hence both at computation time (for a distributed 87 computation) and at signaling time RSVP-TE LSPs will incorrectly 88 place loads. This is true where RSVP-TE paths are distributed or 89 centrally computed without a common entity managing both SR and RSVP- 90 TE computation for the entire network domain. 92 The problem space can be generalized as a dark bandwidth problem to 93 cases where any other service exists in the network that runs in 94 parallel across common links and whose bandwidth is not reflected in 95 the available and reserved values in the TED. While it is possible 96 to configure RSVP-TE to only reserve up to a certain maximum link 97 bandwidth and manage the remaining link bandwidth for other services, 98 this is a deployment where SR and RSVP-TE are separated in the same 99 network (ships in the night) and can lead to suboptimal link 100 bandwidth utilization not allowing each to consume more, if required 101 and constraining the respective deployments. 103 The high level requirements or assumptions to consider are: 105 1. Placement of SR LSPs in the same domain as RSVP-TE LSPs MUST not 106 introduce inaccuracies in the TED used by distributed or 107 centralized path computation engines. 109 2. Engines that compute RSVP-TE paths MAY have no knowledge of the 110 existence of the SR paths in the same domain. 112 3. Engines that compute RSVP-TE paths SHOULD not require a software 113 upgrade or change to their path computation logic. 115 4. Protocol extensions MUST be avoided or minimal as in many cases 116 this co-existence of RSVP-TE and SR MAY be needed only during a 117 transition phase. 119 5. Placement of SR LSPs in the same domain as RSVP-TE LSPs that are 120 computed in a distributed fashion MUST not require migration to a 121 central controller architecture for the RSVP-TE LSPs. 123 2. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. Solution options 131 3.1. Partitioning of static bandwidth 133 In this model, the static reservable bandwidth of an interface can be 134 statically partitioned between SR and RSVP-TE and each can operate 135 within that bandwidth allocation and SHOULD NOT preempt each other. 137 The downside of this approach is the inability to use the reservable 138 bandwidth effectively and inability to use bandwidth left unused by 139 the other protocol. 141 3.2. Centralized management of available capacity 143 In this model, a central controller performs path placement for both 144 RSVP-TE signaled and SR LSPs. The controller manages and updates its 145 own view of the in-use and the available capacity. As the controller 146 is a single common entity managing the network it can have a unified 147 and consistent view of the available capacity at all times. 149 A practical drawback of this model is that it requires the 150 introduction of a central controller managing the RSVP-TE signaled 151 LSPs as a prerequisite to the deployment of any SR-signaled LSPs. 152 Therefore, this approach is not practical for networks where 153 distributed TE with RSVP-TE signaled LSPs is already deployed, as it 154 requires a redesign of the network and is not backwards compatible. 155 This does not satisfy requirement 5. 157 Note that it is not enough for the controller to just maintain the 158 unified view of the available capacity, it must also perform the path 159 computation for the RSVP-TE LSPs, as the reservations for the SR LSPs 160 are not reflected in the TED. This does not fit with assumption 2 161 mentioned earlier. 163 3.3. Flooding SR utilization in IGP 165 Using techniques in [RFC7810], [RFC7471] and [RFC7823], the SR 166 utilization information can be flooded in IGP-TE and the RSVP-TE path 167 computation engine (CSPF) can be changed to consider this 168 information. This requires changes to the RSVP-TE path computation 169 logic and would require upgrades in deployments where distributed 170 computation is done across the network. 172 This does not fit with requirements 3 and 4 mentioned earlier. 174 3.4. Running SR over RSVP-TE 176 SR can run over dedicated RSVP-TE LSPs that carry only SR traffic. 177 In this model, the LSPs can be one-hop or multi-hop and can provide 178 bandwidth reservation for the SR traffic based on functionality such 179 as auto-bandwidth. The model of deployment would be similar in 180 nature to running LDP over RSVP-TE. This would allow the TED to stay 181 consistent across the network and any other RSVP-TE LSPs will also be 182 aware of the SR traffic reservations. In this approach, steps must 183 be taken to prevent non-SR traffic from taking the SR-dedicated RSVP- 184 TE LSPs, unless required by policy. 186 The drawback of this solution is that it requires SR to rely on RSVP- 187 TE for deployment. Furthermore, the accounting accuracy/frequency of 188 this method is dependent on performance of auto-bandwidth for RSVP- 189 TE. Note that for this method to work, the SR-dedicated RSVP-TE LSPs 190 must be set up with the best setup and hold priorities in the 191 network. 193 3.5. TED consistency by reducing RSVP-TE subscription 195 The solution relies on dynamically measuring SR traffic utilization 196 on each TE interface and reducing the bandwidth allowed for use by 197 RSVP-TE. It is assumed that SR traffic is higher priority than RSVP- 198 TE and there can be different priority RSVP-TE LSPs. The following 199 methodology can be used at every TE node for this solution: 201 o T: Traffic statistics collection interval 203 o N: Traffic averaging calculation (adjustment) interval such that N 204 = k * T, where k is a constant multiplier 206 o RSVP-TE subscription percentage: The percentage of static 207 bandwidth of an interface that is usable by RSVP-TE 209 o SR traffic threshold percentage: The percentage difference of 210 traffic demand that when exceeded can result in a change to the 211 RSVP-TE subscription percentage 213 o IGP-TE update threshold: Specifies the frequency at which IGP-TE 214 updates should be triggered based on TE bandwidth updates on a 215 link 217 At every interval T, each node SHOULD collect the SR traffic 218 statistics for each of its TE interfaces. Further, at every interval 219 N, given a configured SR traffic threshold percentage and a set of 220 collected SR traffic statistics samples across the interval N, the SR 221 traffic average (or any other traffic metric depending on the 222 algorithm used) over this period is calculated. 224 If the difference between the calculated SR traffic average and the 225 current SR traffic average (that was computed in the prior 226 adjustment) is at least SR traffic threshold percentage, then the 227 RSVP-TE subscription percentage for that interface MUST be adjusted. 228 This MAY result in updates to maximum reservable link bandwidth in 229 IGP-TE. 231 As SR traffic is considered higher priority compared to RSVP-TE, the 232 reduction in RSVP-TE subscription percentage can result in RSVP-TE 233 LSPs being hard or soft preempted. Such preemption will be based on 234 relative priority (e.g. low to high) between RSVP-TE LSPs. It is 235 RECOMMENDED that the IGP-TE update threshold SHOULD be lower in order 236 to flood unreserved bandwidth updates often. 238 If LSP preemption is not acceptable, then the RSVP-TE subscription 239 percentage cannot be reduced below what is currently reserved by 240 RSVP-TE on that interface. This may result in bandwidth not being 241 available for SR traffic. Thus, it is required that any external 242 controller managing SR LSPs should be able to detect this situation 243 (for example by subscribing to TED updates [RFC7752]) and should take 244 action to reroute existing SR paths. 246 Generically, SR traffic (or any non-RSVP-TE traffic) should have its 247 own priority allocated from the available priorities. This would 248 allow SR to preempt other traffic according to the preemption 249 priority order. 251 In this solution, the logic to retrieve the statistics, calculating 252 averages and taking action to change the subscription percentages is 253 an implementation choice, and all changes are local in nature. 255 The above solution offers the advantage of not introducing new 256 network-wide mechanisms especially during scenarios of migrating to 257 SR in an existing RSVP-TE network and reusing existing protocol 258 mechanisms. 260 4. Acknowledgements 262 5. Contributors 264 The following individuals contributed to this document: 266 Chandra Ramachandran 267 Juniper Networks 268 Email: csekar@juniper.net 270 Raveendra Torvi 271 Juniper Networks 272 Email: rtorvi@juniper.net 274 Sudharsana Venkataraman 275 Juniper Networks 276 Email: sudharsana@juniper.net 278 6. IANA Considerations 280 This draft does not have any request for IANA. 282 7. Security Considerations 284 No new security issues are introduced in this document beyond is 285 already part of RSVP-TE and Segment routing architectures. 287 8. References 289 8.1. Normative References 291 [I-D.ietf-spring-segment-routing] 292 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 293 and R. Shakir, "Segment Routing Architecture", draft-ietf- 294 spring-segment-routing-09 (work in progress), July 2016. 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 302 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 303 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 304 . 306 8.2. Informative References 308 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 309 Previdi, "OSPF Traffic Engineering (TE) Metric 310 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 311 . 313 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 314 S. Ray, "North-Bound Distribution of Link-State and 315 Traffic Engineering (TE) Information Using BGP", RFC 7752, 316 DOI 10.17487/RFC7752, March 2016, 317 . 319 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 320 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 321 RFC 7810, DOI 10.17487/RFC7810, May 2016, 322 . 324 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 325 "Performance-Based Path Selection for Explicitly Routed 326 Label Switched Paths (LSPs) Using TE Metric Extensions", 327 RFC 7823, DOI 10.17487/RFC7823, May 2016, 328 . 330 Authors' Addresses 332 Harish Sitaraman (editor) 333 Juniper Networks 334 1133 Innovation Way 335 Sunnyvale, CA 94089 336 US 338 Email: hsitaraman@juniper.net 340 Vishnu Pavan Beeram 341 Juniper Networks 342 10 Technology Park Drive 343 Westford, MA 01886 344 US 346 Email: vbeeram@juniper.net 348 Ina Minei 349 Google, Inc. 350 1600 Amphitheatre Parkway 351 Mountain View, CA 94043 352 US 354 Email: inaminei@google.com