RE: Global BGP - 2001-06-23 - Vendor X's statement...

[Sean Donelan <sean () donelan com>]

On Tue, 26 June 2001, "Richard A. Steenbergen" wrote:
> > 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...

Flapping 100,000 routes because one route has some bits set in a way one
implementation (not vendor) thinks is Ok, and another implementation (not
vendor) things is wrong, isn't the best solution.  It should flap that
one route, not the other 100,000 routes.

Even if that one route is never propagate beyond that point, the flapping
of the 100,000 routes will be.  The RFC 1771 solution requires the flapping
of *ALL* routes, not just the bad ones.

There will always be cases where Vender A thinks they are correct and Vendor
B thinks they are correct, and they differ.  And you are correct, either
the sender has done something wrong or the receiver has done something wrong,
hence the Internet motto.

The sender should conservatively send only "good" data.

The receiver should liberally accept what it can, and only reject "bad" data.

I don't think the receiver should be changed to understand the bad data, just
not to reject "good" data.

Under RFC 1771, the receiver is rejecting both "good" and "bad" data.  It
should be revised so when there are both "bad" routes and "good" routes, the
receiver should accept the "good" routes and only reject the "bad" routes.

If a TELNET implementation doesn't understand an escape code, it shouldn't
terminate the entire TELNET session.

There is a flaw in both the sender's implementation and RFC 1771's method
of handling errors.