RFC 8426

Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence

📅 published July 2018, from ietf

Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence 🎀

Okay so this is RFC 8426, published by the IETF in July 2018. It's marked Informational, which means it's not a standards-track spec, just really good advice from people who know their stuff 💅

  • Authors: H. Sitaraman (Ed.) from Juniper Networks, V. Beeram from Juniper Networks, I. Minei from Google, Inc., and S. Sivabalan from Cisco Systems, Inc.
  • ISSN: 2070-1721
  • Obsoletes/Updates: it doesn't list anything it obsoletes or updates 🙈

Abstract ✨

Okay so operators want to run services over Segment Routing (SR) Label Switched Paths (LSPs) in networks that already have Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs 🦋 Sometimes they're even moving existing services from RSVP-TE over to SR LSPs. Like, some services are just perfect for SR and have to live alongside RSVP-TE in the same network. That kind of introduction or migration might mean the two have to coexist for a really long time, depending on what the operator wants, obviously 🌸 This document gives solution options for keeping the traffic engineering database consistent across the whole network, while accounting for the fact that SR and RSVP-TE use bandwidth differently. Main character energy for network consistency 👑

Status of This Memo ✨

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8426.

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
3.  Solution Options  . . . . . . . . . . . . . . . . . . . . . .   3
  3.1.  Static Partitioning of Bandwidth  . . . . . . . . . . . .   4
  3.2.  Centralized Management of Available Capacity  . . . . . .   4
  3.3.  Flooding SR Utilization in IGP  . . . . . . . . . . . . .   5
  3.4.  Running SR over RSVP-TE . . . . . . . . . . . . . . . . .   5
  3.5.  TED Consistency by Reflecting SR Traffic  . . . . . . . .   5
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
  6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
Appendix A.  Multiplier Value Range . . . . . . . . . . . . . . .  11
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction 🧚

Okay so bringing SR [RFC8402] into the same network domain as RSVP-TE [RFC3209] creates a real problem 😭 You have to account for SR traffic and make RSVP-TE actually aware of how much bandwidth is really available on the network links. RSVP-TE has no idea how much bandwidth SR services are eating up on those links. So both during computation (for a distributed computation) and at signaling time, RSVP-TE LSPs will place loads incorrectly. This is true whether RSVP-TE paths are computed in a distributed way or centrally, unless one common entity manages both the SR and RSVP-TE computation for the whole network domain.

The problem space can be generalized as a dark bandwidth problem 🌈 That's when any other service runs in parallel across the same links, and its bandwidth isn't reflected in the available and reserved values in the Traffic Engineering Database (TED). In most real-world cases, traffic demands are pretty static, so limiting the reservable bandwidth available to RSVP-TE has been an acceptable fix. But SR traffic is assumed to have very dynamic demands, and there's a lot of risk: you could strand capacity, or overbook service traffic and end up dropping packets 💀

The high-level requirements to consider are:

  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.
  2. Engines that compute RSVP-TE paths may have no knowledge of the existence of the SR paths in the same domain.
  3. Engines that compute RSVP-TE paths should not require a software upgrade or change to their path-computation logic.
  4. Protocol extensions should be avoided or be minimal as, in many cases, this coexistence of RSVP-TE and SR may be needed only during a transition phase.
  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.

2. Conventions Used in This Document 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Solution Options 💅

Okay so this section lists the SR and RSVP coexistence solution options. No single solution is recommended, because they're all valid, even though some won't satisfy every requirement. If a solution works for an operator based on their deployment model, they can totally pick it 🫶

3.1. Static Partitioning of Bandwidth 🦋

In this model, the static reservable bandwidth of an interface gets statically partitioned between SR and RSVP-TE. Each one can operate inside its own bandwidth allocation and SHOULD NOT preempt the other.

You can configure RSVP-TE to only reserve up to a certain maximum link bandwidth and let the leftover link bandwidth go to other services. But this is a setup where SR and RSVP-TE are separated in the same network (ships in the night) 🌙 It can lead to suboptimal link bandwidth utilization, since neither one is allowed to consume more when it needs to, and it constrains each deployment.

The downside is that you can't use the reservable bandwidth effectively, and you can't use bandwidth the other protocol leaves unused 😔

3.2. Centralized Management of Available Capacity 👑

In this model, a central controller does path placement for both RSVP-TE and SR LSPs. The controller manages and updates its own view of in-use and available capacity. Since the controller is one single common entity running the network, it can have a unified and consistent view of available capacity at all times ✨

The practical drawback is that you need to introduce a central controller managing the RSVP-TE LSPs before you can deploy any SR LSPs. So this approach isn't practical for networks where distributed TE with RSVP-TE LSPs is already deployed, because it would mean redesigning the network, and it isn't backwards compatible 🙈 This does not satisfy requirement 5.

Note that it isn't enough for the controller to just keep the unified view of available capacity. It must also perform the path computation for the RSVP-TE LSPs, because the reservations for the SR LSPs are not reflected in the TED.

3.3. Flooding SR Utilization in IGP 🌸

Using the techniques in [RFC7810], [RFC7471], and [RFC7823], SR utilization information can be flooded in IGP-TE, and the RSVP-TE path computation engine (Constrained Shortest Path First (CSPF)) can be changed to take that information into account. This requires changes to the RSVP-TE path computation logic, and it would need upgrades in deployments where distributed computation happens across the network 🛠️

This does not fit with requirements 3 and 4 mentioned earlier.

3.4. Running SR over RSVP-TE 🧚‍♀️

SR can run over dedicated RSVP-TE LSPs that carry only SR traffic. In this model, the LSPs can be one-hop or multi-hop, and they can provide bandwidth reservation for SR traffic based on functionality like auto-bandwidth. The deployment would be similar in nature to running LDP over RSVP-TE. This would keep the TED consistent across the network, and any other RSVP-TE LSPs will also be aware of the SR traffic reservations 🍓 In this approach, non-SR traffic MUST NOT take the SR-dedicated RSVP-TE LSPs, unless policy requires it.

The drawback is that SR has to rely on RSVP-TE for deployment. On top of that, how accurate and how often this method accounts for things depends on how well auto-bandwidth for RSVP-TE performs. Also, for this method to work, the SR-dedicated RSVP-TE LSPs must be set up with the best setup and hold priorities in the network 🥺

3.5. TED Consistency by Reflecting SR Traffic

okay so this is the big one bestie 💅✨ the whole solution is about measuring how much SR traffic is actually using each TE interface and then shrinking the bandwidth RSVP-TE is allowed to use to match. it's giving self-aware network 🦋

SR traffic gets the top spot when it comes to placement on the path. RSVP traffic can get kicked off the path if resources run out. this is logically the same as SR having the best preemption priority in the network 👑 BUT, and this is important bestie, that doesn't mean SR is higher QoS priority. SR and RSVP can totally share the same QoS class 🙈

Shrinking RSVP's allowance can be done with three parameters from IGP-TE ([RFC5305] [RFC3630]): Maximum-Link-Bandwidth, Maximum-Reservable-Bandwidth, and Unreserved-Bandwidth.

  • Maximum-Link-Bandwidth: you can tweak this to make room for SR traffic, which cascades into Maximum-Reservable-Bandwidth and Unreserved-Bandwidth 🌸 but changing the max bandwidth of the TE link means no compute engine for SR or RSVP can figure out the real static bandwidth of that link 😭 And when Maximum-Reservable-Bandwidth is derived from Maximum-Link-Bandwidth, its definition changes, since Maximum-Link-Bandwidth now accounts for SR traffic.
  • Unreserved-Bandwidth: SR traffic could adjust this directly, without touching Maximum-Link-Bandwidth or Maximum-Reservable-Bandwidth. This is basically the same model as Section 3.4. It would also mean overloading IGP-TE advertisements so they reflect both RSVP-TE bookings and SR measurements at once, which is a lot 💀
  • Maximum-Reservable-Bandwidth: the preferred option 🍓 SR traffic adjusts this, and the change cascades into Unreserved-Bandwidth.

Every TE node can use this methodology, with these parameters:

  • T: the traffic statistics collection interval.
  • k: the number of traffic statistics samples that smooth out the collection. k is a constant integer multiplier that is greater than or equal to 1.
  • N: the traffic averaging calculation (adjustment) interval, where N = k * T.
  • Maximum-Reservable-Bandwidth: the maximum available bandwidth for RSVP-TE.
  • If Diffserv-aware MPLS Traffic Engineering (DS-TE) [RFC4124] is enabled, Maximum-Reservable-Bandwidth SHOULD be read as the aggregate bandwidth constraint across all Class-Types, no matter which Bandwidth Constraints model is used.
  • Initial Maximum-Reservable-Bandwidth: the Maximum-Reservable-Bandwidth for TE when there are no SR traffic or RSVP-TE reservations on the interface.
  • RSVP-unreserved-bandwidth-at-priority-X: Maximum-Reservable-Bandwidth minus the sum of (existing reservations at priority X and all priorities better than X).
  • SR traffic threshold percentage: the percentage difference in traffic demand that, once exceeded, can change the RSVP-TE Maximum-Reservable-Bandwidth.
  • IGP-TE update threshold: how often IGP-TE updates should get triggered based on TE bandwidth updates on a link.
  • M: an optional multiplier applied to the SR traffic average, so you can grow or shrink the bandwidth SR uses. Appendix A has more guidance on M.

At every interval T, each node SHOULD collect SR traffic statistics for each of its TE interfaces. The measured SR traffic includes all labeled SR traffic plus any traffic entering the SR network over that TE interface. Then, at every interval N, using a configured SR traffic threshold percentage and the set of samples collected across interval N, the SR traffic average (or whatever other traffic metric the algorithm uses) gets calculated for that period. This is basically the same way bandwidth gets adjusted for auto-bandwidth RSVP-TE LSPs, so it's not a brand new vibe ✨

If the new calculated SR traffic average differs from the current SR traffic average (the one computed in the prior adjustment) by at least the SR traffic threshold percentage, then two values MUST be updated:

  • New Maximum-Reservable-Bandwidth = Initial Maximum-Reservable-Bandwidth - (new SR traffic average * M)
  • New RSVP-unreserved-bandwidth-at-priority-X = New Maximum-Reservable-Bandwidth - sum of (existing reservations at priority X and all priorities better than X)

A DS-TE LSR that advertises a Bandwidth Constraints TLV should update the bandwidth constraints for class-types based on operator policy. For example, with the Russian Dolls Model (RDM) [RFC4127], only BC0 may be updated. With the Maximum Allocation Model (MAM) [RFC4125], all Bandwidth Constraints (BCs) may be updated equally, so the total updated value equals the newly calculated SR traffic average 🧚

Heads up, the new RSVP-unreserved-bandwidth-at-priority-X computation MAY cause RSVP-TE LSPs to get hard or soft preempted. That preemption goes by relative priority between RSVP-TE LSPs (low to high) 😭 The IGP-TE update threshold SHOULD allow more frequent flooding of unreserved bandwidth. From an operational point of view, an implementation SHOULD be able to expose both the configured and the actual values of Maximum-Reservable-Bandwidth 🫶

If LSP preemption isn't acceptable, then RSVP-TE Maximum-Reservable-Bandwidth can't be reduced below what RSVP-TE is currently reserving on that interface. This might mean there's no bandwidth left for SR traffic. So it is REQUIRED that any external controller managing SR LSPs SHOULD be able to detect this situation (for example, by subscribing to TED updates [RFC7752]) and SHOULD take action to reroute existing SR paths. Yes, it's a bit of a tongue twister, but the controller has homework 📚

Generically, SR traffic (or any non-RSVP-TE traffic) should get its own priority from the available priorities. That lets SR preempt other traffic according to the preemption priority order 👑

In this solution, the logic for retrieving stats, calculating averages, and changing Maximum-Reservable-Bandwidth is an implementation choice, and every change stays local. But heads up: this is a new network trigger for RSVP-TE preemption, so the operator should keep it in mind 👀

The big win here is that this doesn't introduce any new network-wide mechanisms, especially when you're migrating to SR in an existing RSVP-TE network. It just reuses existing protocol mechanisms 🌈

4. IANA Considerations ✨

This document has no IANA actions.

5. Security Considerations 🔥

This document describes solution options for RSVP-TE and SR LSPs coexisting in the same administrative domain. The security considerations for SR are in [RFC8402]. The security considerations for RSVP-TE are in [RFC5920]. Each architecture's security considerations are typically unaffected by the other's presence. HOWEVER, when RSVP-TE and SR LSPs coexist, a hijacked SR traffic stream could maliciously eat up enough bandwidth to disrupt RSVP-TE LSPs 😱 With the solution option in Section 3.5, the impact on RSVP-TE traffic can be controlled and paths can be re-routed. There's still some latent risk of disruption, though, because this solution takes statistics samples and only adopts new traffic flows after the adjustment period. The defensive mechanisms described in the base SR security framework should be used to guard against SR traffic hijacking or denial of service 🛡️

6. References ✨

6.1. Normative References

6.2. Informative References

Appendix A. Multiplier Value Range 💅

okay bestie, this appendix is a suggestion for what range the multiplier M should live in 🧚 M is a per-node positive real number from 0 to 2, with a default of 1, and it can also be written as a percentage 📈

  • If M < 1, then the SR traffic average is being understated 📉, which can result in the link getting full even though Maximum-Reservable-Bandwidth does not reach zero 😬
  • If M > 1, then the SR traffic average is overstated 📈, so Maximum-Reservable-Bandwidth hits zero before the link is actually full 🙈 If the reduction of Maximum-Reservable-Bandwidth would become negative, then a value of zero SHOULD be used and advertised 🫶

Acknowledgements ✨

the authors want to give a huge thank-you to Steve Ulrich for his detailed review and comments 🫶💖

Contributors 🌸

these lovely people helped shape the work too 💜

Chandra Ramachandran
Juniper Networks
Email: csekar@juniper.net

Raveendra Torvi
Juniper Networks
Email: rtorvi@juniper.net

Sudharsana Venkataraman
Juniper Networks
Email: sudharsana@juniper.net

Martin Vigoureux
Nokia
Email: martin.vigoureux@nokia.com

Authors' Addresses 🦋

and here's where you can find the authors 🎀

Harish Sitaraman (editor)
Juniper Networks
1133 Innovation Way
Sunnyvale, CA  94089
United States of America

Email: hsitaraman@juniper.net


Vishnu Pavan Beeram
Juniper Networks
10 Technology Park Drive
Westford, MA  01886
United States of America

Email: vbeeram@juniper.net


Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA  94043
United States of America

Email: inaminei@google.com


Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario  K2K 3E8
Canada

Email: msiva@cisco.com
📦 where this page comes from