Introduction
Traffic engineering has always been about optimization under constraints. Operators are trying to keep delay low, use capacity efficiently, avoid persistent hot spots, and maintain service behavior during failures and demand swings. The industry has invested heavily in centralized control and sophisticated path computation, but the operational record is mixed. In some networks these systems help; in others they add complexity, struggle to scale, or fail to deliver the expected responsiveness.
Even with those differences in implementation outcomes, one pattern has remained stable: the output of TE is usually path-oriented. The system computes one path or several candidate paths and then installs forwarding state to realize them.
Multi-Path Traffic Engineering (MPTE) proposes a different output model. Instead of optimizing only paths, MPTE optimizes a forwarding graph. The result is a Directed Acyclic Graph (DAG) that describes loop-free traffic flow from ingress to egress, including split and merge behavior. That graph is then realized using the forwarding mechanisms the network actually has available.
Seen this way, MPTE’s core claim is architectural. It does not claim that prior systems never optimized well. It claims that the optimization artifact itself should be different.
Traditional TE typically produces paths, while MPTE produces a forwarding graph
Traffic Engineering Has Traditionally Optimized Paths
Path selection has been the dominant abstraction for decades. Operators define constraints and objectives, a computation element evaluates topology and policy, and the output is one or more feasible paths that can be installed in the forwarding plane.
Segment Routing fits naturally in that model. SR Policy, as standardized in RFC 9256, allows candidate paths, preference, dynamic computation, and weighted behavior. But even with those features, the control artifact is still path-centric. The system expresses behavior primarily as selected paths between endpoints.
This matters operationally because complexity is often handled by introducing and coordinating additional path objects. That can work, but it can also become brittle when policy interactions and traffic dynamics become more complex.
Optimizing Paths versus Optimizing Forwarding Graphs
MPTE keeps the familiar TE inputs: topology, demand, resource constraints, administrative policy, and service objectives. The change is in the form of the output. Instead of returning independently selected path artifacts, MPTE computes a DAG as one coherent result.
A path represents one ordered sequence of forwarding decisions. A DAG can represent multiple loop-free branches inside the same optimization artifact. That makes it possible to model flow structure directly rather than infer it by coordinating separate path objects after computation.
This is an important distinction, but it should be stated carefully. Path-based TE can approximate many graph-like outcomes in practice. MPTE’s argument is that graph-native output can represent those outcomes more directly and with less[no] policy stitching.
The same network can be represented either as a set of selected paths or as a single DAG with explicit branching.
Why Graphs Matter
Real networks often need behavior that is naturally graph-shaped: concurrent alternatives, asymmetric distribution, selective reconvergence, and adaptation as constraints change. In the SR path-first model, these are typically assembled through combinations of candidate paths and policy logic. In a graph-first model, they are properties of the optimization output.
This approach makes the network’s behavior match operator goals more directly. Instead of choosing paths one traffic class at a time, the system computes a network-wide flow pattern that best meets the stated objectives. The practical benefit is not that graphs are always better. The benefit is that they can be a better fit when the operational objective is system-level flow behavior rather than single-route preference.
DAGs Decouple Optimization from Forwarding
In MPTE, the DAG is not itself a forwarding mechanism. It is an optimization artifact that still must be compiled into deployable forwarding state. That realization may use SR policies, other TE techniques such as MPLS, or some future mechanism yet to be invented.
This boundary is useful because it allows optimization logic and forwarding technology to evolve somewhat independently. It also makes practical limitations visible. If realization cannot preserve graph semantics faithfully, the problem is no longer hidden inside path selection logic.
Controller scalability and responsiveness directly affect what advanced TE features can deliver in practice, including bandwidth-aware steering. When control loops are slow or do not scale, those capabilities degrade regardless of policy elegance. MPTE does not remove that operational constraint, but it clarifies where it resides: in realization and control-loop execution rather than in intent expression.
In MPTE, the forwarding graph forms the boundary between intent-driven optimization and technology-specific realization
A Different Architectural Abstraction
From this perspective, MPTE is not just another protocol option. It is a different abstraction for what TE optimization should return. Traditional TE asks how traffic should traverse the network and answers with paths. MPTE asks how traffic should flow through the network to satisfy a set of objectives and answers with a forwarding graph.
Both models can coexist, and both can be implemented well or poorly depending on the surrounding control architecture. The important difference is the contract between optimization and forwarding.
Control-Plane Considerations
The optimization artifact and the control-plane used to distribute or realize that artifact are related, but they are not the same thing. In a traditional SR deployment, the network usually relies on the IGP as the foundational control-plane for topology and SID distribution, while SR policies are then applied to steer traffic over that base. In other words, the path-centric model is closely tied to what the distributed routing system can advertise and converge on.
MPTE keeps forwarding intent separate from any single signaling mechanism, which means different control-plane choices can be used depending on operational goals. One option is RSVP-based signaling, as described in draft-kbr-teas-mptersvp, which maps MPTE intent into RSVP workflows and can align with environments that already use RSVP-style reservation and signaling semantics. A second option is BGP-based signaling, as described in draft-zzhang-idr-mpte-signaling, which can be attractive where policy distribution and control are already BGP-centric. A third option is controller-based realization, as described in draft-stone-spring-mpte-sr, where a centralized system computes graph intent and programs SR realizations directly.
This flexibility is important because control-plane tradeoffs are real. Distributed approaches can reduce central dependencies but may constrain how quickly complex global objectives are recomputed. Centralized approaches can express richer optimization logic but may introduce scaling and operational bottlenecks if the controller layer underperforms. By allowing multiple realization models, MPTE does not force a single control-plane doctrine; it provides a common optimization abstraction that can be signaled through RSVP, BGP, or controller-driven mechanisms as deployment constraints require.
MPTE does not require a single control-plane model; the same graph intent can be realized through RSVP, BGP, or controller-driven mechanisms
Conclusion
Segment Routing and MPTE are related, but they operate at different conceptual layers. SR provides forwarding constructs for explicit steering. MPTE proposes that optimization should produce a graph-level traffic-flow artifact rather than only a set of paths.
That architectural shift does not depend on assuming controllers are universally successful. In fact, it is more relevant in environments where scaling and operational limits are painful, because it separates intent expression from technology-specific realization details. As forwarding mechanisms and control systems continue to evolve, a graph-first output model may provide a more durable interface between what operators want and what networks can reliably implement.
Leave a Reply