Segment Routing is frequently positioned as a simpler approach to Traffic Engineering(TE) because it can reduce protocol surface area and eliminate per-LSP signaling in the core. That description is broadly accurate at the signaling layer, but it does not remove the underlying TE requirements. TE still requires intent to be expressed, constraints to be applied, and forwarding behavior to remain aligned with topology and policy. SR changes where these functions live and how they are operated; it does not eliminate them.
RSVP-TE frames the same problem differently than SR. It uses explicit signaling to set up LSPs, and it establishes per-LSP state that directly represents operator intent (requested bandwidth, explicit path constraints, and protection behaviors). SR reduces that signaling state, but it typically shifts more responsibility into computation, encoding, and IGP correctness.
Path Control and Explicitness (SR Instruction Stacks vs. RSVP Signaling)
SR expresses steering through an instruction stack: a label stack in SR-MPLS, or IPv6 destination/SRH semantics in SRv6. The path is enforced by encoding a sequence of segments that the network interprets consistently. This can be effective, but it also means that the path is “explicit” only to the extent that the segment set and their semantics remain stable and correctly interpreted across the domain.
RSVP-TE provides explicitness(precision) through signaling and per-LSP state. A signaled LSP is a concrete object in the network with an identified ingress/egress, explicit route objects (when used), and operationally inspectable state. That state provides a direct representation of what was requested and what was admitted, which can make verification and troubleshooting quite straightforward.
SID Types and TE Coverage (SR Constructs vs. RSVP Features)
The minimal SR model is small, but production TE use cases often require additional constructs. In SR-MPLS, adjacency SIDs, anycast SIDs, and EPE SIDs are used to force specific hops or specific egress behaviors that the base node-SID model may not produce. In SRv6, equivalent steering and service goals are met through locator planning, function SIDs, and endpoint behaviors that define how packets are processed at specific nodes. The balancing act is realizing the required precision for the use-case without exceeding the capabilities of the forwarding plane. (more on this later)
RSVP-TE addresses these “coverage” needs through different primitives. Explicit routes (EROs), affinity/administrative groups, policy constraints, and per-LSP attributes allow operators to express hop-by-hop intent without needing to introduce multiple instruction encodings to compensate for limitations of shortest-path forwarding. The tradeoff is the operational and scaling cost of maintaining per-LSP signaling and state.
Scaling and Encoding Constraints (Label Depth vs. Signaling Overhead)
In SR-MPLS, forwarding constraints such as maximum label stack depth and hardware imposition limits bound how much explicit path information can be carried in the packet. In SRv6, the constraint profile shifts to header growth, MTU planning, fragmentation risk, and whether hardware can parse and act on the SRH and variable-length segment lists at line rate. Techniques such as compression are often adopted because forwarding resources are constrained, not because they are inherently simpler.
RSVP-TE’s equivalent pressure point is state rather than encoding. RSVP does not need to carry an instruction list in every packet; instead it maintains per-LSP state in the network. That avoids packet-level encoding growth, but it shifts the scaling and operational burden into signaling, refresh/recovery behavior, and the volume of maintained forwarding state. Though, as mentioned in the previous blog1 some of this pressure can be alleviated by following the procedures described in RFC8370, 8577, and draft-alibee-teas-rsvp-inplace-lsp-bw-update.
Computation and Control-Plane Coupling (Topology Dependence vs. LSP Objects)
SR tends to increase coupling between path computation and IGP-distributed topology state. Whether computation is done at the ingress, by a PCE, or by a controller, the system requires accurate and current topology information to produce instruction stacks that deliver the intended forwarding behavior. When schemes depend on derived constructs (compressed identifiers, indirection, shared representations), topology changes can force recomputation and re-encoding even when intent is stable and introduce transient loops (uLoops).
RSVP-TE also depends on topology and computation, but it externalizes the result as a signaled object with admitted state. Once an LSP is established, its existence and attributes can be inspected and correlated with the original request (including constraints and, when applicable, reservation state). This does not remove the need for topology correctness, but it provides a stable operational object that can be examined independently of the packet encoding.
Bandwidth Management, Resource Reservation and Admission Control (External Controllers vs. In-Protocol Enforcement)
A structural difference between SR and RSVP-TE is resource enforcement. SR is primarily topology-driven and does not natively provide bandwidth reservation or distributed admission control as part of the transport. SR deployments that require bandwidth guarantees generally rely on controllers/PCEs to account for utilization and constraints, then program SR policies and segment lists to approximate the desired outcome. This may be effective in centralized operational models, but it means SR alone is incomplete for “guaranteed bandwidth” TE without an external decision system and its associated integration (additional protocols), telemetry inputs, and failure handling.
RSVP-TE was designed to enforce resource intent in the transport itself. It can request bandwidth, reserve it along the path, choose non-equal-cost paths, and reject LSP setup when constraints cannot be met. This creates a direct coupling between intent, admission, and forwarding. Further, transit LSRs can choose to selectively preempt, based on various priorities defined by operator intent, transit LSPs to ensure bandwidth availability.
State, Visibility, and Troubleshooting (IGP Consistency vs. Per-LSP State)
SR does not eliminate state; it relocates it. SR reduces per-LSP signaling state in the core, but it increases dependence on IGP link-state distribution, SID advertisement correctness, and consistent programming of behaviors (particularly in SRv6). Troubleshooting often requires validating topology databases, convergence timing, SID consistency, and policy-to-encoding correctness, because these directly impact computed paths and realized forwarding.
RSVP-TE concentrates visibility around LSP objects. Operators can inspect signaled LSP state, reservations, the ERO/RRO, and protection attributes. That does not make debugging trivial, but it provides a clear set of per-LSP artifacts that often map directly to operator intent and allow incremental verification.
Fast Reroute and Protection Semantics (TI-LFA vs. RSVP FRR)
TI-LFA repair behavior is derived from topology and the existence of valid repair anchors (PQ nodes) for particular failure scenarios. In many topologies, this can provide fast local repair, but the resulting repair path may be non-obvious and may change as the topology changes.
In contrast, RSVP-TE protection uses explicit merge points (MPs) at the next-hop (link protection) or next-next-hop (link-node protection), which can make the post-failure behavior easier to reason about and validate. RSVP FRR also aligns with RSVP’s broader model: protection is an attribute of a signaled LSP with inspectable state, rather than an emergent property of topology-derived repair computation.
The protection attribute of a signaled LSP also serves as a mechanism that allows the protection path to inherit the intent of the primary LSPs it protects. The intent may come in the form of TE constraints and/or optimization objectives.
Flexible Algorithms (More Control-Plane Stress)
Flexible Algorithms (Flex-Algo) are often introduced as a way to extend SR into use cases such as network slicing, constraining TI-LFA repair paths or aligning optimization objectives, and/or “lightweight” traffic engineering. While interesting, this model is not free. Each Flex-Algo introduces additional SIDs, additional flooding of Flexible Algorithm Definitions (FADs) which effectively carries TE policy constructs(configuration data) inside the IGP. The control plane becomes a distribution vehicle not only for reachability but also for forwarding policy intent.
Moreover, every configured Flex-Algo results in an independent SPF computation upon topology change. Four Flex-Algos mean four SPF runs for a single event, which directly impacts IGP scaling and convergence characteristics. The net effect is that Flex-Algo adds computation, state, and control-plane weight in order to approximate use cases—such as constrained path selection, policy inheritance, and protection alignment—that RSVP inherently supports within its signaled LSP model.
In Conclusion
SR can reduce signaling protocols and per-LSP state, which can simplify certain operational dimensions. The critique is that the complexity frequently reappears in other forms: additional SID types and behaviors to cover TE cases, encoding and hardware constraints that drive compression and conventions, increased coupling to IGP correctness and computation, and reliance on controllers for functions that RSVP-TE provides directly in the transport. RSVP-TE carries more protocol and per-LSP state, but it also provides transport-native admission control, explicit LSP objects, and inspectable protection semantics that align closely with TE requirements.
[1] https://tedigest.com/2026/02/09/state-signaling-and-the-cost-of-simplified-narratives/
tedigest.com 
Leave a comment