Fast ReRoute: The Rise of Optimization and Constraint-Aware FRR
Introduction Fast Reroute (FRR) is one of the defining capabilities of RSVP-TE, enabling networks to recover from failures in tens of milliseconds rather than waiting for full control-plane convergence. By precomputing backup paths and shifting protection into the data plane, FRR allows traffic to be redirected almost instantaneously at the point of failure (Point of…
A Systems Approach to Understanding the Bandwidth Management Control Loop
Bandwidth management(BW) in traffic-engineered (TE) networks is often discussed in terms of specific protocols or architectural models. Yet before debating different architectural models or protocol specific details, it is useful to step back and understand the functional problem being solved. At its core, bandwidth management is a control loop. It observes network conditions, interprets those…
Does Segment Routing Simplify Traffic Engineering?
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,…
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…
State, Signaling, and the Cost of Simplified Narratives
This article is not a comparison of protocols, nor an argument for or against any specific traffic engineering architecture. Instead, it is an examination of how architectural narratives form, how they simplify complex histories, and how those simplifications can quietly shape design assumptions long after the original context has faded. One of the most persistent…
Think Abstract not Explicit
When we talk about path computation in networks, we often frame it as a technical problem: algorithms, constraints, and optimization. But in practice, it’s just as much a human problem. We don’t think in terms of individual links and nodes all day long. We think in regions, failure domains, performance expectations, and operational boundaries. We…
Bandwidth-Aware Traffic Engineering: First Principles for Real Networks
Traffic engineering exists because networks are finite. Links have limits, traffic competes, and assumptions eventually collide with physics. Over decades of network evolution, architectures and control systems have come and gone, but the fundamental challenge has not changed: How to move traffic through a shared infrastructure without exceeding what the network can safely deliver? In…
A Traffic Engineering Process Perspective
RFC 9522 provides a useful framing for the realization of traffic engineered networks by introducing the principles of TE. This post focuses on describing the problem space of TE, the requirements that fall out of it, and a balanced architectural approach. RFC 9522 Matters Traffic engineering discussions often drift toward technical protocol advocacy and arguments…
tedigest.com 