On Tue, 5 May 2015, David Lamparter wrote:
"When set (value 1), this bit indicates that the BGP speaker has
restarted" does imply that it's not intended to be set on a newly
created session 500 days after starting the bgp speaker.
Why not?
If that router has been partitioned for 500 days from others, you surely
still want the churn minimising aspects of GR to work as it joins back
with others?
(Though, for that length of time, you really want a logical clock and long
sequence/RIB-generation numbers).
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.
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.
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.
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.
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.
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.
My patch could add that startup timer back, but it should control the
deferral decision - not the R-bit send.
I don't get it, is this a linear C<->A<->B<->D peering scenario, or is
this an everyone-with-everyone? Why would A wait on D, it doesn't even
have a session to D?
It's a sub-graph. I've drawn a chain for ASCII convenience, but it can be
as complex as you want.
Also, the R-bit is pairwise, you could be sending 1 to one session and 0
to another (which came up later for example).
Yes, it can be pair-wise, so it permits more combinations. For simplicity,
I didn't go into that.
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.
It's just introducing a needless blockage to convergence.
GR is meant to make restarted routers be more careful about how they join
back in to a running network, and minimise the churn they can cause. It
shouldn't though make convergence between only-restarted-routers slower
(which is what startup-timer-R-bit-advertising does, IMO).
This timer can differ between implementations and also is configurable.
Further, there are many reasons why a speaker might not be able to bring
up sessions within the timer delay after a restart.
Ah, I see what you mean. Well, you *can* handle "all done?" on a
per-SAFI level, i.e. start selecting and sending updates when all peers
on a particular AFI/SAFI have indicated !GR || R=0 || EoR(AFI/SAFI).
Also, you can send R=0 and send "false" EoRs, which has the same effect
as R=1 for the particular AFI/SAFI you sent the EoR for.
(In fact, the R bit is redundant - you could as well just send EoRs
directly first thing, and it'd have the same effect.)
Yes, quite possibly.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Art is anything you can get away with.
-- Marshall McLuhan.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
