Subject: Re: draft-ietf-idr-bgp-analysis-03.txt

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 May 2003 18:06:08 -0400

In message <[email-masked]>, David Meyer writes:
> 
> 	Curtis,
> 	
> 	These are great comments. One point
> 
> >> ------------
> >> 
> >> The following statement is incorrect:
> >> 
> >>    Finally, since the dynamic properties of the network cannot be
> >>    quantitatively bounded, stability must be addressed via heuristics
> >>    such as BGP Route Flap Damping [RFC2439]. Due to the nature of BGP,
> >>    such damping should be viewed as a matter local to an autonomous
> >>    system matter (see also Appendix F.2 of [BGP4]).
> >> 
> >> The amount of change is inherently bounded in BGP (as I described
> >> above).  BGP Route Flap Damping was initially proposed for two
> >> reasons, 1) to protect a specific commercial implementation that was
> >> not sufficiently robust, 2) to improve convergence of stable routes.
> >> BGP Route Flap Damping is not necessary to bound the amount of change
> >> in BPG routing.
> 
> 	Yes, but route flap dampening is just a heuristic that we
> 	use because the dynamics can't be bounded; that's what I
> 	was after. Do you disagree with this?
> 
> 	Dave

I made a comment on that later in my earlier note but I'll provide
more detail.

There were two initial motivations for BGP Route Flap Damping.  One
was a certain BGP implementation wasn't robust when we first started
but was much more robust by the time the RFC came out.  Initially if
you pushed hard enough it would fall over.  The second reason was even
after implementations out there were all quite robust, convergence for
stable routes was a lot slower than we'd like if there were a lot of
unstable routes.  [A third reason was a certain router would drop
packets when it had a route cache implementation but we'd all rather
forget about that design error.]  Anyway these reasons motivated the
idea and kept it going.

BGP is inherently work conserving, meaning that above some amount of
incoming change for a given number of prefixes, the amount of work and
the amount of outgoing change was either bound by the number of
flapping prefixes or constant above some number of prefixes (saturated
CPU).  This amount of work and outgoing (advertised out) churn is
bounded but still quite high.  BGP Route Flap Damping was deployed in
recognition of the fact that a very small percentage of the prefixes
representing an even smaller part of the reachable address space where
contributing most of the churn and the vast majority of prefixes were
quite stable.  That was the practical reason that providers were
willing to turn on BGP Route Flap Damping and have to deal with the
occasional headache of clearing the history for prefixes that they'd
rather not get damped (or where the problem was know to have been
fixed - like when some other NOC called).

[ As a side note, BGP Route Flap Damping was never implemented
correctly.  It should take the AS path into consideration and only
damp an unstable path if another existed that was quite stable, not
damp the prefix.  It was known that per prefix damping would cause
problems so in the spec, the AS path as part of the key field was not
optional.  If it had been implemented correctly we would not have the
problems with BGP Route Flap Damping that we have experienced. ]

My argument amounts to 1) route churn IS bounded, however 2) BGP Route
Flap Damping exists because a) the bounds is uncomfortably high, b)
there used to be some broken implementations in use that were not
sufficiently robust, c) a small percentage of prefixes contributed
most of the churn, d) getting rid of that small percentage was
percieved as good for the Internet at large (the majority of stable
prefixes and reachable destinations).

Curtis