On Sunday, April 15, 2012 8:56 PM, Robert Raszuk <mailto:[email protected]> wrote:
>> Your algorithm has an error. >> You forgot to reset the counter after resetting the session. >> How will you handle that error? > > No it does not. This counter is part of dozen of other per session > counters and variables which get reset and cleared when session goes > down. No need to for any specific handling of just this counter. We all say "Oh, I meant to do that" when we find a bug. > > R. > > > >> 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
