+1 Tony
On Apr 15, 2012, at 8:22 PM, Jakob Heitz wrote: > 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 > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
