[39105] in North American Network Operators' Group
RE: Global BGP - 2001-06-23 - Vendor X's statement...
daemon@ATHENA.MIT.EDU (Richard A. Steenbergen)
Tue Jun 26 16:02:56 2001
Date: Tue, 26 Jun 2001 16:02:34 -0400 (EDT)
From: "Richard A. Steenbergen" <ras@e-gerbil.net>
To: Sean Donelan <sean@donelan.com>
Cc: chance@dreamscope.com, nanog@merit.edu
Message-ID: <Pine.BSF.4.21.0106261553220.29677-100000@overlord.e-gerbil.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
On Tue, Jun 26, 2001 at 11:56:21AM -0700, Sean Donelan wrote:
>
> On Tue, 26 June 2001, "Chance Whaley" wrote:
> > How would you like Vendor X to liberally handle the situation? There is
> > a point when being too liberal causes issue - like this one. The idea is
> > that if the original peer followed the spec it would of been contained
> > at the source and this would of never happened. Where is the line?
> > Something about GIGO comes to mind.
>
> I would prefer implementations (not vendors) reject the one router
> which they don't like, and accept the other 100,000+ routes in the
> global Internet without flapping BGP sessions.
>
> Killing 100,000 routes because you don't like one seems a bit
> excessive.
There are only two situations where you will have a route that "isn't
liked", 1) The sender does something wrong, 2) The receiver incorrectly
handles something that is actually right. Either way, there is a
fundamental flaw in someone's BGP implementation, and that needs to get
resolved immediately. Flapping between the offender and its peer is
probably an acceptable way to go about finding these, flapping over the
entire internet because vendor C chooses to ignore the protocol spec and
vendor F does not is probably not...
--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
