Re: [RRG] Geoff Huston's article on BGP stability, update statistics and damping

[ksriram@nist.gov]

Please see a question about MRAI below. Thank you.

Sriram
http://www.antd.nist.gov/~ksriram/
Quoting Geoff Huston <gih@apnic.net>:

> Robin Whittle wrote:
> > Geoff Huston has a new article "Damping BGP":
> > 
> >   http://www.potaroo.net/ispcol/2007-06/dampbgp.html
> > 
> > He proposes methods of identifying updates which are usually
> > associated with path hunting.  Typically this is one or multiple
> > announcements of a longer path for the prefix, followed by the
> > withdrawal of the prefix.  I understand from this that he
> > supports "path length damping" as described by Tony Li:
> > 
> >    http://tools.ietf.org/html/draft-li-bgp-stability
> > 
> > How such filtering would work when all routers implement it I am
> > not sure, but it seems like a good idea.
> 
> The withdrawal would propagate, or the path would stabilise. One way to 
>   view it is as a more selective form of Min Route Advert Interval Timer.
My understanding is that MRAI does not apply to 
explicit withdrawals (the AWs and WWs in your taxonomy).
Did you happen to verify this based on the observed data?
The reason I am asking is if this were implemented,
then in your illustration of Fig. 1 (path hunting),
all the withdraws (W) will make it quickly to Router 5.
BGP Router 5 may have sent one AA+ in response to the very first withdraw
from Router 2 but any subsequent AA+ it tries to send will be
held back for MRAI interval and during that time the
other withdraws from Routers 3 and 4 will make it to Router 5
(because they are not subjected to MRAI), and hence Router 5
will send only one AA+ and then a withdraw.
If "not applying MRAI to explicit withdrawals" is implemented,
then withdrawals propagate much faster than AA+ or AA0 updates, 
hence path hunting related updates would be significantly reduced.
I would think this is how MRAI was intended to expedite
BGP convergence and reduce churn.
 
> 
> 
> > I learnt some interesting things, including that BGP routers
> > often use TCP to throttle the updates from peers to a rate they
> > can handle.  One reason this is done is to prevent local input
> > queues from taking up too much memory.
> 
> Thank you John Scudder for clearly explaining this to me earlier this year.
> 
> > 
> > Meanwhile, the peers perform "output queue compression".  They
> > look into the queue of updates which are waiting to be sent and
> > remove any messages which have been rendered incorrect by events
> > which transpired since that message was put in the queue.
> 
> Thank you John Scudder for clearly explaining this to me earlier this year.
> 
> > 
> > There is also a diagram depicting path hunting, and graphs
> > depicting the statistics of updates, based on research in April
> > this year.
> > 
> >   "10% of announced prefixes being responsible for 53% of all
> >    routing updates, and the busiest 1% of prefixes responsible
> >    for 24% of the routing updates for the month."
> > 
> >   "It can?t be the case that more than a million routing updates
> >    actually reflect true underlying changes in topology of the
> >    network, given that these one million updates only refer to
> >    2,000 prefixes."
> > 
> > I think the time analysis of the updates would be of interest to
> > anyone concerned about BGP stability.
> 
> I would hope so. A significant proportion of the BGP traffic appears to 
> be concerned with a relatively small number of "pathologies" where BGP 
> itself is the amplifier.
> 
>     Geoff
> 
> 
> 
> 
> --
> to unsubscribe send a message to rrg-request@psg.com with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
> 



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg