Your algorithm has an error. You forgot to reset the counter after resetting the session. How will you handle that error?
Software is not that easy. Get my point? On Sunday, April 15, 2012 8:34 PM, Robert Raszuk <mailto:[email protected]> wrote: > Hi Jakob, > > Just to make sure you got my point ... > > I am not suggesting adding ton of logic and algorithmic operations. > > All I am suggesting is simple counter (time drained) which would count > how many times in a given period we are performing the > treat-as-withdraw > action. > > Algorithm: > ---------- > > If such counter get's exceeded session get's reset. > > There is tracking (counter++ operation) and one additional conditional > if statement. There is no analysis what so ever. > > Best, > R. > > >> 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
