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

Sigh, the motto "be liberal in what you accept and conservative in what
you send" applies to BOTH parties. The failure of one party not to
liberally accept what is received does not excuse the sending party from
being conservative in what they send. And vice-versa.

Just because one vendor has issued a patch does not excuse the other
vendor.

No, but in this case, assuming it was as stated, the announcement in
question specifically should not have been accepted. Its rejection is
a mechanism intended to prevent the propagation of malformed routes.
The problem would have been contained at the source had the original
router receiving the announcement behaved properly and closed the
session without propagating it.

-c

Sigh, the motto "be liberal in what you accept and
conservative in what you send" applies to BOTH parties. The
failure of one party not to liberally accept what is received
does not excuse the sending party from being conservative in
what they send. And vice-versa.

Just because one vendor has issued a patch does not excuse the other
vendor.

Ahh.. So what it sounds like your saying is: "If some vendor makes a
bug, then the other vendors should quickly change their code to violate
the standards, and accept that bug." I know that cant be the case. :slight_smile:

There is a very limited and defined space in being liberal here. The RFC
is very clear on the statement - and for very good reason. When someone
sends corrupt information you must send a NOTIFICATION and close the
session. End of story.

For those of you not playing the home game:

   When any of the conditions described here are detected, a
   NOTIFICATION message with the indicated Error Code, Error Subcode,
   and Data fields is sent, and the BGP connection is closed. If no
   Error Subcode is specified, then a zero must be used.

   The phrase "the BGP connection is closed" means that the transport
   protocol connection has been closed and that all resources for that
   BGP connection have been deallocated. Routing table entries
   associated with the remote peer are marked as invalid. The fact that
   the routes have become invalid is passed to other BGP peers before
   the routes are deleted from the system.

So would you prefer that Vendor X liberally accepted the false
information and propagated it to its other peers? Or would you prefer
that it follows the spec. and protect the global table from false info?

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.

.chance
(again speaking only for himself)

Sean Donelan <sean@donelan.com> writes:

Sigh, the motto "be liberal in what you accept and conservative in what
you send" applies to BOTH parties.

Making guesses as to what is meant when one gets malformed routing
updates is well beyond the scope of being "liberal in what you
accept". It is only noteworthy that the bad update didn't crash the
Brand "C" router because it used to be notoriously easy to kick
one over by that method.

The failure of one party not to
liberally accept what is received does not excuse the sending party from
being conservative in what they send. And vice-versa.

Being "conservative in what you send" refers to interpretations of the
specification, backwards compatability with older specifications,
requiring weird extensions to the protocol, etc. These all fall along
the axis of "what might be expected in a properly functioning
implementation". Output that is clearly wrong, as is the case here,
is not just breaking conservatism in what one sends, it's a sign that
Something is Screwed Up (tm).

A convincing argument can be made for a "max-malformed-update-resets"
knob such that if the peer sends bogons and gets reset more than N
times in T minutes, the session is admin-downed the same way it is
when it exceeds max-prefixes.

Of course, if more router manufacturers were to enable clairvoyant
route update divination (CRUD), Sean would get more interesting
outages to write about, so at least _someone_ is ahead. :slight_smile:

                                        ---Rob