Re: Withdrawls and announcements attempt 2

[Yakov Rekhter <[e-mail]>]

Curtis,

> Moved to bgp list.

Thanks.

> > 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.
> 
> At MaeEast in many cases 30 to 50 peers hear a withdrawl and then
> withdraw the same route thenselves.  You would expect to see N times
> as many withdraws as was needed for a given withdrawl depending on who
> withdrew it and how many Ciscos they peer with.

As was indicated in the original message from MERIT, this accounts for
only a small fraction of the total withdraws (for the benefits of those
not on the NANOG list I attached the original message from MERIT). So,
to repeat what I said in my previous note let's focus on what seems to
be a much more important issue - ~5*10^6 daily withdraws.

> If you look at the stats and add up the withdraws and announces and
> take the ratio you have a ratio of about 12.  Someone with a Cisco
> router that hears a lot of withdraws will have a very high ratio.
> Someone that flaps a lot will just cause others to have a very high
> ratio.  The ratio of totals should be in line with the average number
> of Cisco peers.
> 
> This should be sufficient emperical evidence to consider fixing the
> problem.  

What you presented is a number - 12. This number, by itself, tells very
little about the *operational* impact of these withdraws. To assess the
operational impact you need to provide such parameters as extra
bandwidth consumed by these withdraws, and extra CPU load imposed
by processing these withdraws. 

Yakov.
--------------------------------------------------------------------------

 -- using template mhl.format --
Date:    Fri, 21 Jun 96 12:04:59 EDT
To:      [e-mail]

From:    Craig Labovitz <[e-mail]>
Subject: Re: Withdrawls and announcements attempt 2 

Return-Path: [e-mail]
X-Mailer: exmh version 1.6.6 3/24/96
Reply-To: [e-mail]
In-Reply-To: Your message of Fri, 21 Jun 1996 11:24:25 -0400.
	 <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender:  [e-mail]
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" <[e-mail]> 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				[e-mail]
Merit Network, Inc.			[phone] (office) 
4251 Plymouth  Road, Suite C.		[phone] (fax)
Ann Arbor, MI 48105-2785



> 
> Curtis