[39182] in North American Network Operators' Group
Re: Global BGP - 2001-06-23 - Vendor X's statement...
daemon@ATHENA.MIT.EDU (Steve Schaefer)
Wed Jun 27 20:57:14 2001
Date: Wed, 27 Jun 2001 17:56:28 -0700 (PDT)
From: Steve Schaefer <schaefer@simone.dashbit.com>
To: <lucifer@lightbearer.com>
Cc: "E.B. Dreger" <eddy+public+spam@noc.everquick.net>,
Matt Levine <matt@deliver3.com>, <jes@nl.demon.net>,
"'Chance Whaley'" <chance@dreamscope.com>, <nanog@merit.edu>
In-Reply-To: <20010627231104.25627.qmail@prophecy.lightbearer.com>
Message-ID: <Pine.LNX.4.33.0106271740010.32178-100000@simone.dashbit.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
It seems that the right way to handle a malformed route or two depends on
who's speaking and who's listening.
If I'm a backbone provider and I hear a bad route from a customer, I'm
going to drop that connection. I have no incentive to take any risks.
This is just as the RFC currently reads.
If I'm a customer, I really don't want to shut off the service that I'm
paying for. If I'm not going to propagate the routes beyond my borders,
why should I drop the whole session? The risk is entirely mine, and a
partially corrupted table is better than no connectivity at all.
From this point of view, it seems that the RFC should be loosened to allow
configuration of a BGP peer to continue the session and ignore the route.
Perhaps there should be wording to the effect that it is not acceptable
practice to propagate routes from the offending router beyond your
borders.
Maybe there is even a way to phrase it that means "it's not OK to
propagate routes from a suspect router back into the core of the
Internet." In practice these words have meaning because "upstream" and
"downstream" are defined by the flow of money, and economics suppresses
loops.
Steve Schaefer
Dashbit - The Leader In Internet Topology
www.dashbit.com www.traceloop.com
