For two decades, RSVP-TE has been the standard answer to a deceptively simple question: how do you make traffic follow a path other than the shortest one? Its answer was to signal. Each tunnel is established hop by hop with PATH and RESV messages. Every router along the way holds state for every tunnel that crosses it, and refreshes that state periodically so it does not time out.

This design made sense when explicit paths were rare and networks were small. It scales poorly when they are neither. A full mesh of tunnels across N edge routers grows as N squared. The burden lands disproportionately on core midpoints that never originate or terminate a single LSP. Operators have spent years tuning refresh reduction, tunnel hierarchies, and auto-bandwidth to keep the control plane from buckling under its own bookkeeping.

Segment Routing Traffic Engineering takes a different stance. Instead of asking the network to remember paths, it asks packets to carry them. The source encodes a route as an ordered list of segments, and transit nodes simply execute instructions. This shift relocates complexity rather than removing it, moving path intelligence toward the headend and the controller. Understanding where that complexity goes, and what it makes possible, explains why SR-TE has become the default choice for new traffic engineering designs.

RSVP-TE is a stateful protocol in the fullest sense. A headend computes a constrained path with CSPF, then sends a PATH message carrying an Explicit Route Object toward the tail. Each hop installs a path state block. The tail replies with RESV, and labels are allocated in the upstream direction. The resulting LSP exists as distributed soft state, maintained by periodic refreshes and torn down when they stop.

Segment Routing removes that conversation entirely. Labels, called Segment Identifiers, are distributed once through the IGP using extensions to IS-IS or OSPF. A prefix-SID identifies a node and steers traffic along the ECMP-aware shortest path to it. An adjacency-SID identifies a specific link and forces traffic across it. Because these identifiers are advertised domain-wide, any headend can compose a path from them without negotiating with anyone.

An explicit path then becomes a segment list pushed onto the packet. In SR-MPLS this is a label stack. In SRv6 it is a Segment Routing Header containing IPv6 addresses that double as instructions. A transit node reading the active segment needs no knowledge of the end-to-end path, the policy it belongs to, or the other flows sharing it. It performs a forwarding lookup on information it already holds for every other purpose.

The consequences ripple outward. Midpoint state drops from per-tunnel to per-topology, so adding a thousand policies at the edge costs the core nothing. Recovery no longer depends on signaling detour or bypass LSPs. TI-LFA computes post-convergence repair paths locally, delivering sub-50-millisecond protection with full topology coverage. The protocol stack also shrinks, with RSVP and often LDP leaving the control plane along with their timers and interoperability quirks.

The trade-off is header overhead and hardware constraints. Every segment consumes label stack depth or SRH bytes. Line cards impose limits on how many labels they can push or read, a capability advertised as Maximum SID Depth. Binding SIDs and Flexible Algorithm help by compressing long paths into shorter instructions or by creating constraint-specific topologies. Even so, path expressiveness is ultimately bounded by silicon rather than by signaling.

Takeaway

RSVP-TE stores the path in the network; SR-TE stores it in the packet. Most of Segment Routing's operational advantages follow from that single relocation of state.

Removing midpoint state also removes something RSVP-TE provided implicitly: admission control. When an RSVP LSP reserves bandwidth, every router along the path deducts it from its local pool and rejects reservations that would oversubscribe a link. SR-TE has no equivalent mechanism in the data plane. If bandwidth guarantees matter, something must track them. That something is usually a centralized controller acting as a stateful Path Computation Element.

The controller builds a live model of the network from BGP Link-State, which exports IGP topology including SIDs and TE attributes. Streaming telemetry adds measured link utilization. With a global view, the controller can solve problems that distributed CSPF handles poorly. It can avoid bin-packing deadlocks, compute disjoint paths for diverse services across different headends, and reoptimize many policies at once rather than letting each headend react independently to the same congestion event.

Paths are delivered as SR Policies, identified by a headend, a color, and an endpoint. The color encodes intent, such as low latency or path diversity. BGP routes tagged with a matching color community are automatically steered into the corresponding policy. The controller installs candidate paths through PCEP with SR extensions or through the BGP SR Policy address family. Only the headend holds the policy; the rest of the network remains unaware that it exists.

This architecture inverts the RSVP-TE scaling model. State concentrates in two places that scale well: the controller, which runs on general-purpose compute, and the headend, which tracks only the policies it originates. A core router carrying traffic for ten thousand policies is configured identically to one carrying none. Reoptimization becomes a matter of updating a segment list at a single node, without make-before-break signaling across every hop of both the old and new paths.

Centralization introduces its own design questions. Controllers must be redundant and must handle network partitions gracefully. This is why headends typically retain local fallback behavior, and why SR Policies support multiple candidate paths ranked by preference. Bandwidth accounting also becomes an estimate based on telemetry rather than a hard reservation. That is an acceptable trade for most traffic, but it is a meaningful shift for services that relied on strict RSVP guarantees.

Takeaway

SR-TE does not eliminate path state so much as move it to where computation is cheap and the view is global. The network becomes a programmable fabric, and the controller becomes the place where intent is translated into instructions.

Few operators can switch off RSVP-TE overnight. Production networks carry services built on years of tunnel design, from L3VPN steering to FRR-protected premium circuits. The practical question is not whether SR-TE can replace RSVP-TE, but how the two can coexist long enough to move traffic safely. MPLS gives them a shared data plane, and that commonality makes incremental migration far more tractable than protocol replacements usually are.

The first phase is typically enabling SR in the IGP alongside existing protocols. Routers advertise prefix-SIDs from a Segment Routing Global Block while RSVP-TE and LDP continue operating unchanged. Where some routers cannot yet run SR, a mapping server advertises SIDs on their behalf, and SR-LDP interworking stitches label paths across the boundary. At this stage nothing changes in forwarding. The network has simply gained a second, dormant set of labels.

Coexistence on the same links raises a bandwidth question. RSVP-TE assumes it controls reservable link capacity, yet SR traffic consumes that capacity without appearing in any reservation. Common approaches include statically lowering the RSVP-reservable bandwidth to leave headroom for SR, or having the controller measure SR traffic and adjust advertised availability. Neither is perfect, which is why migrations benefit from moving traffic classes in deliberate batches rather than letting both mechanisms compete indefinitely.

Binding SIDs provide a clean bridge between the two worlds. An RSVP-TE tunnel can be assigned a binding SID, allowing an SR Policy to reference the entire tunnel as a single segment, and the reverse also works. Domains can therefore migrate independently, stitched at their boundaries, with a core still running RSVP while metro and access layers move to SR. Protection follows a similar sequence: TI-LFA is enabled and validated before RSVP FRR bypass tunnels are retired.

The final phase is cutover and cleanup. Headends begin preferring SR labels over LDP. Explicit services move from RSVP LSPs to colored SR Policies, and RSVP state drains gradually until the protocol can be disabled. Some operators continue on to SRv6, reusing the same policy model with a different encapsulation. Throughout the process, the reversibility of each step matters more than speed, because a working rollback is what makes progressive migration safe.

Takeaway

Migrations succeed when each step is independently reversible. Because SR-TE and RSVP-TE share the MPLS data plane, Segment Routing can grow inside an existing network instead of replacing it in a single disruptive event.

The move from RSVP-TE to SR-TE reflects a broader pattern in network architecture. Forwarding devices do less remembering and more executing, while intelligence migrates to the edges and to software with a global view. Source routing appeared early in internet history and was set aside. Segment Routing revives the idea with many of its earlier limitations addressed.

What emerges is a network defined by intent. Colors describe what traffic needs, controllers translate those needs into segment lists, and the fabric carries out the instructions. SRv6 extends this further, letting segments represent services and functions as well as paths, which blurs the line between routing and computation.

The deeper implication is that path control is becoming a software problem. Protocols that once negotiated every tunnel hop by hop are giving way to programmable infrastructure, where the interesting engineering happens in models, optimizers, and policy rather than in signaling state machines.