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
