I don't think treat-as-withdraw is trying to fix a single session reset. Graceful restart can fix that. It's the rolling resets that need a human to remove a buggy router or a config that triggered the bug. That takes several hours. Treat-as-withdraw limits the damage during those hours.
Could we please settle on that without trying to solve the impossible? Cheers, Jakob Sent from my iPoo. On Dec 31, 2012, at 1:21 AM, "Robert Raszuk" <[email protected]> wrote: > How about if we would mandate Enhance Route Refresh request to be send > to such peer who's bad updates triggered treat-as-withdraw action ? > > If we resync databases OK the likehood of "bad things" should be > minimal. If we fail to sync (get another malformed update(s)) then > IMHO resetting the session should be granted. > > Yes that means that "treat-as-withdraw" should be applied only to > those peers which support Enhanced Route Refresh. > > Happy New Year, > R. > > >> On Mon, Dec 31, 2012 at 4:09 AM, John Leslie <[email protected]> wrote: >> >> Brian Dickson <[email protected]> wrote: >>> >>> But, the basic problem is this: missing an UPDATE won't trigger either >>> condition, it will at worst cause sub-optimal routing. Missing a WITHDRAW >>> _CAN_ cause Bad Things (TM) to happen. >> >> +1 >> >> -- >> John Leslie <[email protected]> >> _______________________________________________ >> Idr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
