Hi Ilya,
I very much agree with your adjustments. My goal was to just provide an
example of what one could do.
Then to play devil's advocate one could observe that we should perhaps
not bind the updates to sessions at all. In fact persistence draft is
just about cutting that binding.
I guess the fact that we use TCP for BGP is sort of legacy and perhaps
the more Shakespeare we put in BGP (on 179 or different instance) we
should revisit how we transport the UPDATE messages betwen BGP peers.
Best,
R.
On Apr 17, 2012, at 02:24 , Christopher Morrow wrote:
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)
I'd propose a variation of above:
if number of prefix in "bad update" is higher than configured X% of all prefixes
(alternatively - 'of best path') learned from this peer (regardless of time) then reset session. If
X configured to be 100, then effectively it means "never drop this session" (unless
really all that this peer sends is bad).
/iLya
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
