
On Tue, 26 June 2001, Robert E. Seastrom wrote:
> > Killing 100,000 routes because you don't like one seems a bit excessive.
> 
> Accepting a clearly defective route that may be a bellwether for a
> router that has gone completely nuts seems a little bit naive and
> trusting.

Why do people believe it is so simple to decide what is the "bad" route?  If
the sender thought it was a bad route, they wouldn't have sent it in the first
place.  The reason they sent it was, 1) they thought it was an Ok route, 2)
they didn't check it closely, 3) it changed after they checked it.

You need both sides of the equation.

Conservative sending: Do not send bad routes.
Liberal receive: Accept the good routes, reject only the bad ones

Conservative receive: If anything is wrong, reject everything (NOT THE
 INTERNET WAY)

You seem to be saying, if you find ANY error (or even a disagreement) reject
everything because you can trust nothing.  This is exactly what the Internet
motto cautions against. Yes, it may be a bellweather for something, but
frequently the Internet has muddled along with 99.999% of things working.
ISO/OSI loved to tear down sessions when it found a single bit which one
side or the other thought was set wrong. The search for perfection is long,
and life is short.

I agree the bad route should not have been sent.  However, I do not think the
appropriate error action when there is a disagreement between implementations
is the BGP death penalty.

I believe the appropriate error handling mechanism is to accept those routes
which pass your sanity check, reject those routes that do not, and ALERT the
sender and operator something is wrong with some of the routes.

Other implementations do not need to fix the bad route.  They should not
propagate the bad route.  Rejecting 100,000 other good routes, which pass
their sanity checks, is not a good thing.



