Nope.
This is about recognizing duplicate update which good implementation
should be able to do regardless.
Nothing to do with error itself.
Regards,
R.
So you're going to _remember what error occurred_????
Complexity++
No thanks,
Tony
On Apr 16, 2012, at 12:43 PM, Robert Raszuk wrote:
Ilya,
I meant to say that you would increment the counter only for unique updates. So
duplicate updates with the same NLRIs would not be counted N times.
On the other hand, if a session is reset (due to errors per other
rules) there's chance that problems will occur again. Rather than
bouncing session for extended period, I'd prefer such troublesome
peers to stay down. We spoke about this behaviour few times, but I'm
not sure if we have reached consensus.
I agree. We could have max-prefix like configurable restart as an option.
Rgs,
R.
Robert,
-----Original Message-----
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.
Let's consider following scenario: a router in no-longer-kingdom far-away
sends malformed update that somehow manages to slip through multiple
intermediate routers and comes to me via a peer that sends me few dozen
thousands of other prefixes (everyone has seen this in the wild not too long
ago). I increase "error tracking counter", the far-away router for some
reason sends update again, I increase counter again, at some point I reach
threshold. Clearly, resetting my session with a peer that sends me large
number of "good" prefixes isn't to my advantage, especially that it won't
repair distant router. My personal preference would be to ignore such errors
until kingdom come.
On the other hand, if a session is reset (due to errors per other rules)
there's chance that problems will occur again. Rather than bouncing session
for extended period, I'd prefer such troublesome peers to stay down. We
spoke about this behaviour few times, but I'm not sure if we have reached
consensus.
/iLya
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
