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: nanog@merit.edu From: Craig Labovitz <labovit@merit.edu> Subject: Re: Withdrawls and announcements attempt 2 Return-Path: nanog-owner@merit.edu X-Mailer: exmh version 1.6.6 3/24/96 Reply-To: labovit@merit.edu In-Reply-To: Your message of Fri, 21 Jun 1996 11:24:25 -0400. <9606211524.AA14100@heineken.engeast> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nanog@merit.edu 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" <justin@erols.com> 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 labovit@merit.edu Merit Network, Inc. (313) 764-0252 (office) 4251 Plymouth Road, Suite C. (313) 747-3745 (fax) Ann Arbor, MI 48105-2785

Curtis