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

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.

But there there should be no room for debate, one side is right and the
other side is wrong. If there is really a grey area, the solution is to
fix the wording of the standards document, not to try and overlook the

I agree that in this case it is possible to have ignored the bad AS PATH
and drop the route without disturbing the session originating the bad
information. This is one specific example could probably have been handled
better with a non-fatal notification (with big red lights and buzzers).
However, it was unacceptable for that router to propagate the bad
information to others.