> > > > b) Non-GR peers sit in update-delay mode until one or both send > keepalives > > to kick the other out of update-delay mode. > > Again, they stay in update-delay mode until all peers globally are in an > acceptable state, or the timer expires. The "look for Keepalive instead > of EoR" thing seems to be a Cumulus invention, we could strip that out > if needed. It's not a core aspect of the functionality, really. > > (With Non-GR, we don't really know when the peer is done sending us > their full table... using keepalives for that seems, hm, "innovative", > though I agree with you it might turn out to be a bad idea. Should > investigate this further.) > > The "wait for the first KA as a sign that the peer has finished sending updates" was something we did at cisco in the first implementation of update-delay. GR hadn't been invented yet so this was how we signalled to a peer that we were finished sending our initial set of updates. I would leave it, it is handy on the off chance that you are interacting with an implementation that hasn't implemented even GR helper.
Daniel
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
