In the mid-1990s, the internet had a problem that felt almost existential to the operators keeping it alive: a single flapping link in some obscure corner of the world could send BGP UPDATE storms rippling through every router on the planet. A cheap modem in Kuala Lumpur bouncing up and down every 30 seconds could push CPU load on backbone routers to 100%, and because BGP is a path-vector protocol, every withdrawal and re-announcement had to be recomputed and propagated by everyone. RFC 2439 introduced Route Flap Damping — a mechanism to punish unstable routes by temporarily suppressing them, giving operators back their CPUs.

The mechanism. Each route gets a figure of merit — essentially a penalty counter. Every time the route flaps (a withdrawal followed by re-announcement, or an attribute change), the router adds a fixed penalty (typically 1000). That penalty decays exponentially over time with a configurable half-life (default 15 minutes). When the accumulated penalty crosses a suppress-threshold (default 2000), the router stops announcing the route to peers even though it's technically reachable. Once decay brings the penalty back under reuse-threshold (default 750), the route is un-suppressed. A hard cap called max-suppress-time (default 60 minutes) ensures a route can't be dampened forever.

The key design decisions. The authors — all Cisco/ANS engineers who had personally watched the internet melt — chose exponential decay because it has a critical property: the sum of infinite flaps at a constant rate converges to a finite value. This means you can express thresholds as "flap rate" rather than "flap count," which is what operators actually care about. They also chose to keep state per-route, per-peer, so a flapping route learned from one neighbor doesn't get dampened when the same prefix arrives cleanly from another. And crucially, damping is applied only to received routes, not to your own — you never dampen yourself.

Then came the twist. Damping was widely deployed through the late 1990s and early 2000s. Then in 2002, a paper by Mao, Govindan, Varghese, and Katz — "Route Flap Damping Exacerbates Internet Routing Convergence" — showed that damping was actually making convergence worse. The reason is subtle: normal BGP path exploration during convergence generates transient UPDATE churn that looks identical to real flapping. A route that fails once and reconverges through a few alternate paths could accumulate enough penalty to get suppressed for 30+ minutes, even though the underlying link is perfectly stable. RIPE issued recommendation RIPE-378 in 2006 telling operators to turn damping off. Most did.

Why it still matters. Damping came back — carefully — via RFC 7196 in 2014, which recommended much less aggressive default thresholds (suppress at 6000, reuse at 2000) that avoid punishing normal convergence churn. Many tier-1 networks now run "damping lite" on specific prefix categories. More importantly, RFC 2439 is a wonderful case study in emergent misbehavior: a mechanism that was locally correct, mathematically elegant, and empirically successful in isolation caused systemic harm once deployed globally. Every distributed systems engineer building rate limiters, circuit breakers, or backoff logic is fighting the same class of problem — the difference between "punish bad behavior" and "punish behavior that looks bad during recovery."

The RFC is also notable for being written in prose that assumes you already run a backbone. It reads like an operations runbook with equations, not an academic spec. That was the style of the era: RFCs were written by the people who would deploy them at 3 AM.