On Tue, May 05, 2015 at 04:05:26PM +0100, Paul Jakma wrote: > On Tue, 5 May 2015, David Lamparter wrote: > > Receiving the R bit set means that you shouldn't wait for any EoRs from > > that router, not that updates must be sent immediately or anything. It > > simply excludes the session from the set of sessions for which the > > set-and "all done" is evaluated. > > It's an XOR thing, it depends on the combination of each side's bits - > some of my earlier text wasn't explicit on that, but I thought later bits > of the email were. > > If you set the R-bit, you're saying you will defer sending updates if the > other side has /not/ set the R-bit.
This is not correct. If you set the R-bit, you're saying the peer shouldn't wait on EoRs from you. It has no influence on whether you'll defer sending updates or not. The latter solely depends on the "all done?" boolean. > Currently, the timer controls whether we send the R-bit. After that, when > we go to send routes, it depends purely on the combination of whether we > sent an R-bit (however long ago) and whether we received one - if EoR > hasn't been received. (I'm not saying the current code is correct -- as you may have noticed I spotted a mistake in my understanding of the mechanism, so I need to re-check whether the current behaviour is valid, broken, incomplete, or something else.) > > A restarting box will, while it's in startup mode (= for a limited > > time), look at the "all done?" boolean. That boolean moves to true when > > either: > > - the timer is up (i.e. we don't want to wait anymore) > > - all sessions fall in one of these three: > > - not sent GR capability, thus don't send EoR > > - have sent GR capab + have sent EoR > > - have sent GR capab + have sent R bit > > > > Until "all done?" is true, not route selection happens and no outbound > > routes are advertised - not even to non-GR boxes or GR boxes with R bit. > > Note that the timer isn't a factor when we get to deciding whether to > defer sending updates. The timer is only a factor earlier, at OPEN, in > deciding whether to send the R-bit. Note that the actual deferred selection is implemented in a separate patch that we don't have on master: https://github.com/CumulusNetworks/quagga/commit/3e2a4c3513b1c896f92085bbb8f2bfb60c16f1e2 > > Well, you always want updates ASAP ;) - this is not what the R bit is > > for. The R-bit is to tell the peer that you're minding your own > > business and it might be an extra minute until an EoR shows up from you. > > The R-bits (sent and received) are being used by Quagga currently to > decide whether or not to send to a route update to a peer, or whether to > defer and let the other side send all its updates first. That's what I meant when I said "we're implementing a subset of GR that is neither 'receiver/helper' nor 'full'" last week in private chat :) > Only a restarted speaker (i.e. R-bit sent) can defer, and it can only do > so with peers which have not-restarted (XOR), until the EoR comes in or > the Selection_Deferral_Timer fires. No, all routers can defer[*], if they send either !GR, or R=1, or EoR. And they can defer with peers that have restarted, too. They just need to make sure they don't have the deferral depend on these peers. > Actually, we don't implement the Selection_Deferral_Timer bound on > deferall /at all/ currently, except sometimes accidentally if the startup > timer fires before sending R-bit. If it fires after sending R-bit, well we > don't check any timer later (after OPEN and deciding R-bit) when we decide > whether to defer sending a route. > > So the current code is wrong, regardless. Yes, we need to pick up the patch linked above. For some reason, that patch uses a separate timer; the timers should probably be one and the same. > My patch could add that startup timer back, but it should control the > deferral decision - not the R-bit send. And the R-bit send should depend on whether we're currently deferring. It should _not_ be independently stateful. It reflects global state of the BGP instance. > > The 0 routers would be propagating their updates immediately since > > that's what they said: R=0 "i'm operating normally, you can expect an > > EoR from me in reasonable time". And the 1 routers would go to R=0 > > after their timer expires, which on wallclock time would happen > > simultaneously? > > No, a 1 router will defer and wait for EoR with 0 neighbours, and not > defer on other 1 neighbours. > > By having a restarted neigbour go 0, before sessions with other restarted > neighbours come up, then those other neighbours will unnecessarily defer > and wait for it. No, they won't, because the restarted neighbor that went to R=0 will send its entire table expediently and follow that up with an EoR. That's what R=0 means for a speaker that implements the spec correctly, it's a promise that an EoR will come soon-ish. After all, the entire point of the entire thing is cut short the wait for the expiry of the deferral timer, by merit of having all sessions up and EoR'd. (or R=1, or !GR.) Worst case it will self-fix by expiry of the deferral timer [in a correct implementation]. -David _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
