IMO 1. Error handling must be simple, lest we have to handle errors of the error handling, ad infinitum...
2. Error handling should be restricted to error isolation and reporting. It should refrain from attempting error recovery. If an error can be isolated to a set of NLRI, withdraw them. If an error can only be isolated to a session, reset it. Tracking and analysing multiple errors to decide on a reset violates point 1. On Sunday, April 15, 2012 8:07 PM, Robert Raszuk <> wrote: >> Independently of that, I think that trying to maintain a session in >> the face of multiple errors is a clear waste of time and effort on >> all parties. At some point, there is more effort and complexity >> spent on error recovery than on correct transmission, and that's just >> backwards. I support the suggestion of binary exponential back off >> on session restarts. >> >> Regards, Tony > > I would highly agree that the notion to keep the session at all cost > is just a wrong thing to do. > > Such notion comes often from the fact that operator did not provided > path redundancy or are trigger by seemingly correct observation that > single malformed update should not impact other correct updates > received over the same session. > > However neither the error handling IDR spec nor it's early > implementations provide a way to still allow the reset to happen if X > % of UPDATE messages in the window of time T sec are malformed. > > Perhaps Rob's document as set of requirements could add such > requirement to the spec ? > > Regards, > R. -- Jakob Heitz. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
