On Fri, May 08, 2015 at 10:21:09PM +0100, Paul Jakma wrote: > To follow-up on an off-list discussion we had on GR, here's that tweak. > > I gather you're also concerned about internal queueing and batching to > minimise CPU churn.
Indeed, I'd appreciate if we could work on making full GR out of https://github.com/CumulusNetworks/quagga/commit/2ca83e1825158650546b82791834b87c2bb829fa instead of doing this ;) > This patch set doesn't co-ordinate tracking of EoR-received state across > all peers, but the current code doesn't have that either, and this set > shouldn't of itself be an impediment to that. [...] > As noted by David Lamparter, the stateful R-bit flag, to ensure R-bit was > set for the first session to peers, also would apply to peers added > later. > Which just doesn't make sense - having added a peer means you havn't > restarted per se. Limit it to peers created from the config file. This should indeed fix the issue I pointed out on IRC, however this leaves another issue (if I'm brain-executing the code correctly): If we start up with N peers (i.e. PEER_STATUS_GR_SEND_R_BIT), and one of them is down/unreachable/plain doesn't exist anymore, we will forever stay in GR=1 status, since bgp_update_all_eor_recvd includes that peer and thus will never be true. This, in turn, will cause extra churn on other nodes, to whom we're sending GR=1 ("don't wait on me") and who in turn may prematurely exit their GR and churn on updates we're still sending. Worse yet, the admin can't do anything about it, because deleting the peer (after the other N-1 have already finished & sent their EoR) will not re-trigger the all_eor_recvd check; thus we'll stay in GR=1 until some other peer happens to send an EoR. If only we had a timer... -David [Unless I misread the code and above description doesn't match the code: NAK on all patches in this thread.] _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
