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
