On Thu, May 14, 2015 at 09:01:24PM +0100, Paul Jakma wrote:
> On Thu, 14 May 2015, David Lamparter wrote:
> > 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.
Which might be an argument for some other logic for determining whether
our table has converged, but not for breaking this up per-peer.
> 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 restarted peer is the other peer, which also has R=1. We're talking
about "us", the side that has been running for a month with all other
peers up & stable. Your patch makes *us* send R=1, and that is not
right because we have a stable converged RIB at that point.
> > 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,"
... which is equal to "is building up from an empty RIB" - and very much
not a per-peer state.
> 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.
Yes, though really it's not just sending updates, it's processing them
in the first place. The restarting peer would want to run its bestpath
selection once for each prefix, not N times for N incoming updates about
that prefix.
Note that this only makes sense when multiple peers are coming up
simultaneously. If only one peer is coming up (either at startup, or
later with other sessions already up), there's no point in delaying
processing or outgoing updates.
(The other peer should do that, if it's receiving updates from multiple
peers; but this shouldn't be "us" making the assumption that that peer
will send us multiple updates per prefix. The information to make that
decision is present at the other peer, so it should have effect there.)
> The R-bit is there to negotiate whether one side should wait.
It's the opposite, it indicates that the router with R=1 doesn't have a
full RIB in place, and thus shouldn't be waited upon.
> > 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.
Er. It is. See below.
> 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.
That's not what GR specifies. The stable router is supposed to send its
entire table to the less stable one as quickly as possible, and then
indicate that it is *done*. The restarted router will wait for *all* of
its peers to finish doing so, then perform *one* bestpath selection for
all routes with all information in place, then start sending out its
selected routes.
R=1 says that the router is doing that right now. It's not running
bestpath selection and not sending out updates (which of course it can't
do without bestpath selection, what would it send if not its best path?)
Since we're not doing that currently, we should always send R=0.
> What the R-bit is a proxy for is "which RIB is the more converged".
Yeah. Going back to my example, isn't it the less far-fetched
assumption to think the longer-up peer is more converged? That'd be
"us", with the 2-{week,month,year} uptime. Why would we send R=1 to a
peer that is coming up -- just because we had it in config at startup?
And, really, why would this be per-peer? Our *table* will converge.
That's not a peer thing.
> 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.
Yes, I see that you can come up with a scenario where your patch
provides better behaviour. So did I in my previous mail, for the
actual GR behaviour. And I'm quite confident the behaviour I'm
suggesting is what the RFC intends, and it corresponds to update-delay
(which is of course global state). How would we reconcile your patch
with the Full-GR startup update process plugging?
> 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.
We should send R=1 based on our delaying of update processing. Hence,
the right thing to do would be right now to always send R=0. I would
like to get the update-delay patch merged, and then send R=1 if and
exactly if the update-delay is currently corking bestpath selection.
Your patch goes off on a completely unrelated tangent, sending R=1 based
on a newly thought-up state-machine. It is diametral to full GR
behaviour with update corking on startup. I would like to work towards
full GR behaviour as specified in the RFC, thus I'm opposed to your
patch.
Know what, scratch "working towards." I just sat down and hooked it up
- took all of 20 minutes, including compile-testing. Incoming to ML in
separate mails.
-David
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
