[RRG] BGP Graceful Restart (was Re: Geoff Huston's article ...)

[ksriram@nist.gov]

For the purpose of damping BGP or reducing its churn, 
another important tool that should be quite useful is the 
BGP graceful restart (BGP-GR) mechanism (RFC 4724).
I was at the recent NANOG-40 where in the Peering BOF
session it was discussed that BGP restart is an available
feature generally in BGP routers but it is turned off
by default, and it appears that many smaller ISPs do not 
activate it. It would be interesting to know (if there is
data available) how often BGP session restarts occur
(due to software upgrades or any other reasons).
A BGP restart at a BGP speaker causes its peer to withdraw 
routes learnt from that BGP speaker (in the absence of BGP-GR).
This produces churn and can also trigger Route Flap Damping (RFD)
(two or more hops away from that BGP speaker), which adds 
substantial delay to convergence or re-convergence.
These problems are avoidable by activating BGP-GR on all or most 
BGP peering sessions. BGP-GR can also be an effective countermeasure
against deliberate attacks that seek to cause BGP session restarts.
Some references that discuss this topic further:
http://csrc.nist.gov/publications/drafts/800-54/Draft-SP800-54-version2-
Jun2007.pdf
(see BGP-GR overview and discussion in Section 5.1)
http://www.antd.nist.gov/~ksriram/BGP_Security_Sriram_IEEE_JSAC.pdf
(see Section V)

Sriram
 

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.
> 
> 
> > 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