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.
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.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
