The TED isn’t the LSDB

In traffic engineering discussions, it’s common to hear the Traffic Engineering Database (TED) described as an “extension” of the Link State Database—as if the TED is simply the LSDB with a few extra bits. The implication is that traffic engineering is just normal routing with more metadata, and that the distinction is mostly academic.

That oversimplification has become especially common in recent Segment Routing (SR) conversations. Because SR is so tightly coupled to the IGP, and because so much confidence is placed in the abstraction or “magic” of centralized controllers, the role of the TED is often treated as secondary—or ignored entirely. The assumption is that once paths are expressed differently, or once computation is externalized, the traditional building blocks of TE are no present.

But that framing misses something important. The LSDB and the TED may share a common topological starting point, but they serve fundamentally different purposes. One exists to ensure consistent shortest-path forwarding across a distributed routing domain. The other exists to model the network as a set of constrained resources, enabling intent-driven path computation and path placement. The LSDB is about knowing where links go. The TED is about knowing what links can do.

The Link State Database (LSDB)

The Link State Database is the shared topological foundation of a link-state routing domain. Built from flooded link-state advertisements, it gives every router a consistent view of what the network looks like: which nodes exist, how they connect, and the metrics or cost associated with those links. The LSDB is fundamentally about reachability and shortest-path forwarding.

The scope of the LSDB is the IGP domain—the set of routers participating in a single instance of OSPF or IS-IS, where all nodes exchange topology information and compute paths using the same rules. Within that domain, the LSDB provides the common input to SPF, ensuring that distributed forwarding remains consistent and loop-free.

From the LSDB, routers run the SPF algorithm to compute next hops and populate the routing table. Its purpose is not to reason about bandwidth, constraints, or service intent, but simply to ensure that all routers agree on the network graph well enough to forward packets.

The Traffic Engineering Database (TED)

The Traffic Engineering Database begins with the same topological foundation as the LSDB, but extends it with the attributes required for constraint-based path computation. A TED captures not only that a link exists, but what it can support: reservable bandwidth, affinities, SRLG membership, TE metrics, and other policy-relevant properties. It is a database built for engineering paths, not simply discovering connectivity.

In practice, the TED is often constructed using the topology learned through the LSDB as its baseline input. However, unlike the LSDB, the TED is not inherently bounded by the local IGP flooding domain. It may be augmented through additional information sources such as BGP Link-State, controller-provided abstractions, or policy overlays, enabling a broader and more resource-aware view of the network than IGP alone provides.

The TED is scoped to the traffic engineering domain—the set of nodes and links considered available for constraint-based routing and optimization. This domain may align with an IGP area, span multiple areas or levels, or be represented abstractly through centralized computation.

Where the LSDB enables shortest-path routing, the TED enables traffic-engineered routing—supporting CSPF, RSVP-TE, Segment Routing policies, and PCE-based optimization. In other words, the TED is not simply “more LSDB,” but a different abstraction: one that treats the network as a set of resources to allocate and constraints to satisfy, rather than just a graph to traverse.

An Illustration – Inter “Domain” TE

Modern networks are rarely confined to a single routing domain. Multi-area, multi-level, multi-instance, and even multi-BGP AS designs are common, resulting in an infrastructure composed of multiple distinct IGP domains. While this segmentation is operationally useful, it introduces an important tension: the network may be partitioned for routing, but still needs to be managed as a single traffic engineering domain in order to achieve globally optimal path placement and meet end-to-end SLA objectives.

Consider the multi-level IS-IS example below. Routers A, B, C, and D participate in the IS-IS Level 2 domain, while routers C, D, E, and F participate in the Level 1 domain. From router A’s perspective, destinations in the remote domain remain reachable, but the detailed topology of that domain is not. In particular, links such as D<–>F, C<–>E, and E<–>F are not present in A’s local LSDB, because they fall outside the scope of its local flooding domain.

To support traffic engineering across this broader network, router A’s TED can be augmented through additional information sources. For example, BGP Link-State can provide visibility into the remote domain’s topology and resource attributes, enabling a more complete traffic engineering view than the LSDB alone can offer. This is illustrated in the simplified diagram below.

Even in this simplified form, the example highlights the key distinction: a node’s LSDB reflects only what its IGP domain knows, while its TED may represent a broader, resource-aware model of the network needed for constraint-based optimization.

In conclusion …

Conflating the LSDB with the TED leads to more than just sloppy terminology—it leads to confused architectural debates. Shortest-path routing and traffic engineering are not separated by a few additional link attributes; they represent different problem spaces. The LSDB supports distributed agreement on reachability and forwarding. The TED supports constraint satisfaction, resource reasoning, and optimization against intent.

Treating one as a simple extension of the other understates the complexity of traffic engineering and obscures where additional control, computation, and state actually enter the system. The LSDB is the network’s map. The TED is the network’s planning model. And that difference is exactly where traffic engineering begins.