Withdrawls and announcements attempt 2
yakov at cisco.com
Fri Jun 21 17:34:12 UTC 1996
> > Keeping track of the state of who got announced what is likely
> > to be a very very very bad idea for busy BGP talkers carrying
> > today's amount of NLRI and instability.
> > There are some hacks around the simplistic "if it's in my RIB,
> > I have to propagate withdrawals to all my neighbours" for some
> > cases, but a more comprehensive fix would require some Thinking.
> > This should probably get migrated over to the BGP list.
> > Sean.
> Its a solved problem, solved in gated more than 2 years ago. Dennis
> did some real good work in that area. No need to continue on any
Please note that propagating withdrawals to all neighbors is
*not* the problem we are trying to solve now, as such propagation
accounts for only a small fraction of the total withdraws (see attached).
In fact, we've yet to see any empirical evidences that propagating
withdrawals to all neighbors is a problem.
Now could we return (perhaps on the BGP list) to the discussion
about the *real* issue we need to solve - ~5*10^6 daily withdraws.
-- using template mhl.format --
Date: Fri, 21 Jun 96 12:04:59 EDT
To: nanog at merit.edu
From: Craig Labovitz <labovit at merit.edu>
Subject: Re: Withdrawls and announcements attempt 2
Return-Path: nanog-owner at merit.edu
X-Mailer: exmh version 1.6.6 3/24/96
Reply-To: labovit at merit.edu
In-Reply-To: Your message of Fri, 21 Jun 1996 11:24:25 -0400.
<9606211524.AA14100 at heineken.engeast>
Content-Type: text/plain; charset=us-ascii
Sender: owner-nanog at merit.edu
A quick clarification -- the liberal BGP widthraw policy implemented by Cisco
(and a few other vendors) only accounts for a small fraction of the ~5 million
plus daily withdraws in the default-free Internet. The real source of all
these spurious withdraws remains a bit of a mystery. Our data shows some
strange sort of 30 second looping/oscilation behavior is taking place.
Possible causes of this behavior include configuration errors, unexpected
IGP-EGP interactions, vendor implementation bugs, and problems inherent with
the BGP protocol itself.
The source of the millions of BGP withdraws is NOT Cisco's "liberal BGP
withdraw" policy -- this generates a fairly minor number of extra withdraws
(O(n) per router), and there are a quite a few valid and compelling reasons
for wanting implementing BGP this way.
at Fri, 21 Jun 1996 11:24:25 EDT, you wrote:
> "Justin W. Newton" <justin at erols.com> writes
> * Its /a little/ more complex than that. The RFC does /not/ call for closin
> * down a BGP session when you change your route filters. Cisco's have to do
> * this, but its not part of the RFC. So, if I, for the sake of argument,
> * added a new filter /after/ I made an announcement to someone I would have
> * somewhere keep track of the fact that I made the announcement. It seems t
> * me that this could get to be a bit memory intensive (keeping track of the
> * state of every announcement made to every peer).
> * This leads me to wonder whether if we had infinite memory (just for the sa
> * of argument), if it would be more processor intensive to keep track of all
> * of your announcements or if the overhead invloved in dealing with withdraw
> * that don't affect me is less.
> There are however vendors out there that do exactly what you described
> above and can therefore change policies and have them take effect
> without having to take down a BGP session. And they only withdraw a
> prefix if they sent an update for it in the first place.
Craig Labovitz labovit at merit.edu
Merit Network, Inc. (313) 764-0252 (office)
4251 Plymouth Road, Suite C. (313) 747-3745 (fax)
Ann Arbor, MI 48105-2785
More information about the NANOG