RE: Global BGP - 2001-06-23 - Vendor X's statement...
On Tue, 26 June 2001, "Chance Whaley" wrote:
Vendor X released a limited statement to their customers describing the issue - and their view on it. The large incumbent vendor that we all know and love has confirmed the issue, and released a "patch" to some of their customers. Vendor X also went on to state that at no time did their boxes crash, mis-forward, reset, or have any issue resulting from the events of the past weekend.
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.
On Tue, Jun 26, 2001 at 11:01:58AM -0700, Sean Donelan wrote:
On Tue, 26 June 2001, "Chance Whaley" wrote:
Vendor X released a limited statement to their customers describing the issue - and their view on it. The large incumbent vendor that we all know and love has confirmed the issue, and released a "patch" to some of their customers. Vendor X also went on to state that at no time did their boxes crash, mis-forward, reset, or have any issue resulting from the events of the past weekend.
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.
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
On Tue, 26 June 2001, "Sean Donelan" wrote: 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. :) 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)
participants (3)
-
Chance Whaley -
Clayton Fiske -
Sean Donelan