Hi Jeff, > That was a bug, but the customers had NO OPTIONS TO WORK AROUND THIS. > Their ONLY CHOICE was to wait for a patch from their vendor (for folks > whose vendor routers did this)
+ > the operator can buy time to diagnose it in detail, or wait for his > vendor to provide a software update, or whatever. I think you have just hit the nail on it's head above. I think waiting for vendor's fix is just not acceptable for production environments .. it just takes too long [read days if not weeks] (not to mention that a lot of deployed hardware requires reload when you upgrade). When we originally discussed error handling solutions in junisco one option was to allow operator to apply filter to BGP messages between TCP and BGP. If the error is known it is pretty trivial to match on arbitrary string in such BGP pre-parser and filter it out or clear or reset the bit/bits if NOC decides it is operationally safe. The point is that for critical protocol like BGP4 (with current choice of transport) I am of the opinion that we should build a much more universal mechanism rather then add fixed twicks which may or may not always help and when operator has zero control on what such "session saver" twick actually does. Cheers, R. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
