On Mon, Apr 16, 2012 at 6:01 PM, Robert Raszuk <[email protected]> wrote: > Nope. > > This is about recognizing duplicate update which good implementation should > be able to do regardless.
I think 'good implementations' don't then exist, since ... as shane/danny have presented a few times, a large percentage of update traffic seen is repeats from the same speaker. I'm not sure that being able to track repeats is really necessary though, if one speaker is +10% bad (pick a percent) over the last 5 mins (or 500 update messages, perhaps this is a chance for a knob for either/both/mix) shutdown the session and keep it down (or bounce and re-establish and after X bounces in Y time, shutdown) If the concern is, this peer keeps sending me an update that is unparsable, ignoring it (and logging a note/alert/etc) seems ok. If the problem is that the neighbor did something quite wrong on the session as a whole more immediate action should be taken. There's some sympathy to be had for situations like ATTR-128 though, why bounce 50% of the speakers on the internet repeatedly if some downstream of a downstream screws up? -chris > 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
