North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Withdrawls and announcements attempt 2
Curtis, > > 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 > list. 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. Yakov. -------------------------------------------------------------------------- -- using template mhl.format -- Date: Fri, 21 Jun 96 12:04:59 EDT To: [email protected] From: Craig Labovitz <[email protected]> Subject: Re: Withdrawls and announcements attempt 2 Return-Path: [email protected] X-Mailer: exmh version 1.6.6 3/24/96 Reply-To: [email protected] In-Reply-To: Your message of Fri, 21 Jun 1996 11:24:25 -0400. <[email protected]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: [email protected] Precedence: bulk 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. - Craig at Fri, 21 Jun 1996 11:24:25 EDT, you wrote: > > "Justin W. Newton" <[email protected]> writes > > * Its /a little/ more complex than that. The RFC does /not/ call for closin g > * 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 to > * somewhere keep track of the fact that I made the announcement. It seems t o > * 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 ke > * 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 ls > * 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. > > -Marten -- Craig Labovitz [email protected] Merit Network, Inc. (313) 764-0252 (office) 4251 Plymouth Road, Suite C. (313) 747-3745 (fax) Ann Arbor, MI 48105-2785 > > Curtis - - - - - - - - - - - - - - - - -
|