On Thu, 14 May 2015, David Lamparter wrote:
That does leave a different situation where this code doesn't do the
right thing. If we have N peers started up correctly, a few weeks pass,
then another peer restarts after having been offline. That peer
implements GR. Your patch will send R=1, which means that other peer
won't wait for us to send our entire table.
Right, you already mentioned that to me and I though I sent a small patch
to address that so that R=1 will only apply to peers read from the config
file. Last weekend? Did you see that?
This is for a peer configured on startup.
Right, which is what it does with the last patch.
Again, this is for a peer configured on startup. It'll send R=1. Even
if 2 weeks have passed, and we have a stable RIB.
Oh, sorry.
If it has been up for 2 weeks, but was partitioned from other routers that
have been up longer, its RIB may be stable however that doesn't mean it
has converged.
If it was right for that restarted peer to hold back on sending its state
to non-restarted peers at t=1s, and t=1m, then it's surely just as right
at t=1h, t=1w, t=1 month. Why wouldn't it be?
The R bit is not "no connection has succeeded to that peer". The R bit
is "we don't have a stable RIB yet."
No, that isn't what the R-bit indicates. The R-bit:
"indicates that the BGP speaker has restarted,"
It's used to allow restarted peers to defer sending updates to peers that
havn't, on the (not universally perfect) premise that in such cases the
restarted peer will tend to have much less complete state than the
longer-lived, non-restarted peer and that it is better for the
restarted-peer to be fed the updates from the other first, to minimise
churn on the other.
The R-bit is there to negotiate whether one side should wait.
None of this is an argument for making the state non-global. Why is "do
we have a stable RIB?" a per-peer consideration?
That isn't what the R-bit indicates. Not even by proxy. Nor is the
stability of the RIB even the important criteria.
A router could have a very stable RIB, cause it's only been connected to a
small network, lost its major connectivity. Its peer could have a very
unstable RIB, simply cause its been connected to a much bigger network
(e.g. greater portions or all of of the Internet). You'd want the router
with the stable RIB to defer UPDATES to the one with the less stable RIB
here.
What the R-bit is a proxy for is "which RIB is the more converged". The
assumption is that the router which has the more stable uptime is more
likely to be better converged with the network that would result once the
partition with the restarted-router is healed.
Not a perfect assumption, but that's what it is.
I'd be all for "Stop sending R=1 based on these facts about what the
speaker knows about the state of the network, peers or its convergence",
but to stop sending R=1 based on an arbitrary timer is a cop-out.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Line Printer paper is strongest at the perforations.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
