Re: Withdrawls and announcements attempt 2

[Yakov Rekhter <yakov () cisco com>]

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