Summary

  • RFC 2439 made instability a local state variable: withdrawals raised a route's figure of merit, exponential decay lowered it, and separate cut and reuse thresholds decided when the path became unavailable and usable again.
  • Later experience showed that this memory could penalize a well-connected prefix during ordinary convergence. RFC 7196 did not abolish damping; it recommended more conservative thresholds and an optional calculate-without-suppressing mode.

A route's past became part of its present

In the 1990s, BGP updates were not only descriptions of which destinations could be reached. Their volume also consumed processor time at the receiving router and at peers that received onward announcements. RFC 2439 set out a way to reduce repeated routing change while trying not to slow convergence for relatively stable routes. It was a Standards Track proposal, and its authors reported that commercial implementations and deployments already existed by 1998. That contemporaneous account is evidence about the period, not a claim about current configuration. RFC 2439 RFC 2439 record

The key move was to remember more than the latest UPDATE. A router receiving an external BGP route could maintain a figure of merit for a route identity. Each transition from reachable to unreachable added penalty; when the route remained stable, an exponential decay reduced the accumulated value. The score was not a diagnosis of a broken cable or a dishonest peer. It represented a router's recent observation of route changes, and it influenced whether that router would use and advertise the path. RFC 2439

That distinction created a time lag between restored reachability and restored eligibility. A cutoff, or suppress, threshold determined when the route would be held back. A lower reuse threshold determined when a held route could re-enter use. A maximum hold-down time placed a bound on suppression. Reachability, accumulated penalty, suppression state and best-path selection were related, but none was the same fact. The route might be announced again by a peer while the receiving router still treated it as suppressed. RFC 2439

Memory was not a generic delay timer

RFC 2439 discussed two ways to limit route advertisement. A fixed timer, later associated with the Minimum Route Advertisement Interval, paced updates. The stability-sensitive method instead depended on the route's change history. If the score stayed below the cutoff, an announcement could be used; once suppressed, it stayed unusable until its decayed value crossed the reuse threshold. This made damping conditional on prior instability rather than an identical waiting period after every route change. RFC 2439 BGP-4

The parameters were policy choices with different effects. Half-life set how quickly a score fell while a route was reachable; implementations could use another decay rate, or no decay, while it was unreachable. A higher cutoff tolerated more changes before suppression. A lower reuse threshold required more stability before recovery. RFC 2439's illustrative settings show why these values cannot be collapsed into a universal timer: in one example, a route could be suppressed after two or three withdrawals, then need roughly one and a half to two and a half half-lives of stable announcement before reuse. That is a model under stated assumptions, not a promise about every router. RFC 2439

The design also placed a boundary around where damping should run. RFC 2439 specified application on updates received from external peers and warned that damping routes learned or advertised through iBGP could cause routing loops. It proposed that route identity include the NLRI and, by default, the AS path. A penalty attached only to a destination prefix can tell a different story from a penalty attached to a particular path to that destination. RFC 2439

Implementation details changed who paid

RFC 4277's 2006 operational review reported that the then-current implementations it examined did not preserve route history by unique NLRI or AS path, despite RFC 2439's requirement. In a densely meshed network, the review said, this could suppress a destination too aggressively, in the most severe case after one failure; it also reported such adverse effects had been observed. That is a bounded implementation report, not proof that every router behaved this way. The review separately discussed peer-session damping for persistent errors, which is not the same as per-route flap damping. RFC 4277 RFC 2439

By 2014, RFC 7196 described another cost: topological richness can create more UPDATE messages during normal convergence, so a well-connected site could be penalized precisely because it had many paths and peers. Its cited measurement found fewer damped prefixes at higher suppress thresholds while retaining some reduction in update rate. The study reported a 19% update-rate reduction at a threshold of 6,000 versus no damping, alongside 90% fewer damped prefixes than at 2,000; at 12,000, it reported 0.22% of prefixes damped and an average hourly reduction of 11%. Those are results from the cited week-long study, not universal predictions. RFC 7196

RFC 7196 recommended a threshold of at least 6,000 for operators seeking less-destructive but still somewhat aggressive damping, and 12,000 for conservative operators. At the same time, it said implementations should not change existing configurable defaults in order to avoid breaking operational configurations. It also allowed a test mode that calculates which routes would be damped without actually suppressing them. The 2014 answer was calibration and observability, not a claim that damping was always harmful or that one setting fit every topology. RFC 7196

The historical shift is therefore not simply “damping on, then damping off.” RFC 2439 tried to contain churn by making a route's past count against its immediate reuse. RFC 4277 showed that route identity and implementation could broaden that penalty. RFC 7196 then treated normal convergence and well-connectedness as costs that needed to be measured before suppression. The mechanism could reduce repeated updates, but it could also delay a route that had recovered. None of these RFCs turns a damping score into proof of a failed link, a bad origin or a universal service outage. RFC 2439 RFC 4277 RFC 7196 Scalable Routing Design Principles RFC 2439 Datatracker record

Sources