Geoff Huston's article on BGP stability, update statistics and damping

Hi Noel,

On Jun 21, 2007, at 7:00 AM, Noel Chiappa wrote:

>> From: Robin Whittle <rwfirstpr.com.au>
>
>> Geoff Huston has a new article "Damping
BGP":
>
>>  "... the busiest 1% of prefixes responsible
for 24% of the routing
>>  updates for the month."
>
> While I agree that whatever's causing this ought to be
fixed, there  
> are some
> points we need to not lose sight of.
>
> First, fixing this would be a *one-time* improvement in
the growth  
> curve for
> the update rate (versus long-term time). I.e. you'd see
a flat spot  
> (or a
> drop) in the curve, after which it would resume its
previous growth.


Hopefully, we would see a flat spot, and then an actual
decrease in  
the growth rate of churn.  If we have a mechanism that truly
is  
capable of reducing churn, and assuming that the amount of
churn is  
proportional to the number of prefixes, then we should be
able to  
reduce the update rate to truly reflect the topological
events and  
the growth in number of prefixes.


> Second, 25% is not peanuts, but it's also not an order
of  
> magnitude, and
> eliminating these wouldn't get us into a whole new
operating  
> region. I don't
> know what the current growth rate for BGP updates is,
but if it's  
> anything
> like the growth rate of the table itself (as one might
reasonably  
> assume it
> is), 25% is not a long calendar time.


I believe that the point that we're making is that the churn
rate is  
well _ABOVE_ the growth rate of the table new to new
prefixes.  The  
amplification of path hunting is a major contributor to
unnecessary  
updates.


> Again, it ought to be fixed, but let's not kid
ourselves that this  
> is the
> solution to our problems.


No one was claiming that it was.  As you may recall, we've
identified  
two problems: a) the increase in the size of the table is
giving us  
concern and b) the subsequent update rate seems to grow
unreasonably  
even with respect to (a).  The goal here is to attack only
(b), and  
(a) is an entirely separate issue.

Tony

_______________________________________________
Idr mailing list
Idrietf.org
https://ww
w1.ietf.org/mailman/listinfo/idr