On Tue, 5 May 2015, David Lamparter wrote:
The R bit is intended to be based on wallclock time. While setting the
R bit doesn't break anything per se, setting the R bit is not intended
by the spec when bringing up a new session.
No, *route selection* is meant to be deferred until the EoR comes in, or
the timer expires.
The RFC is quiet about when to unset the R-bit. There are a number of
reasonable interpretations on that. Using the timer is one, but I don't
think it's a good one, see below.
In particular, if bringing up a new session from a "good" router
(non-restarted recently) to a restarted router, setting the R bit will
cause extraneous incoming update noise from the restarted router to the
good router.
It's the other way around. Not setting the R-bit when we have restarted is
what leads to extra noise and timer + runtime dependent behaviour (which
can vary).
If R-bit is *not* set, the other side will wait for EoR.
(But if the R-bit is set for new sessions, this will inadvertedly
trigger the deadlock-avoidal mechanism and send all updates as they
arrive, causing potentially many incoming updates for each individual
net.)
Right, which is what you want if you have in fact restarted.
If you restart, your RIB comes up empty, you want the remotes to send
their routes ASAP. So you need to set the R-bit.
Note that the timer is configurable, and not negotiated, and can differ on
each side. Though, the RFC
Also interesting is that the R-bit in the OPEN is global, but the EoRs are
per-AFI/SAFI - slight conceptual mismatch in the spec maybe.
Nope, the R-bit is overall deadlock-avoidal, it's not tied to an AFI or
SAFI.
Well, yes, I am well aware the point is deadlock removal.
The point is to ensure that deferring route selection is done only when it
is useful, where one side genuinely has restarted and the other not.
I.e. we want XOR on the restart-state. For 1-1 or 0-0 R-bit, there's no
point anyone waiting (and obviously deadlock prone), so the point is to
ensure that it only happens for 0-1 or 1-0. Which ensures you never get
both sides deferring.
With a timer on the restart-bit (and remember, it is configurable on each
side), you can get 2 sides restarting (A-B = 1-1) but the session coming
up after the timer has expired on one (A-B = 1-0). So now you've got 1
side pointlessly waiting for the other.
Further, those speakers could also be received routes from other routers
that didn't restart, and so have a fully-up-to-date RIB:
C-A-B-D
0-1-0-0
So C is sending routes to A, D and B are sending routes to each other, A
is waiting on C (correctly) and on D (incorrectly - D had restarted).
For the above example the reality is:
C-A-B-D
0-1-1-0
What should happen is that A and B each wait on C and D to send their full
RIBs, and also update each other (no wait). Once C and D are done sending,
they send EoR, and /now/ finally A and B can send their best routes to C
and D.
That should happen deterministically with this patch.
You could have a longer chain of this, where it should be 0-1-1-1-1-1-0,
but you get 0-1-0-1-0-1-0 and you now a series of arbitrary bottle-necks
to routes propogating, with routers waiting on others unnecessarily.
Without this patch it is dependent on timer and timing issues. Different
things could happen on different days. I hate that kind of behaviour
myself.
The comment about the EoR being per-AFI/SAFI and R-bit global is an aside.
If you're trying to deterministically determine when to clear R-bit
according to the actual connection state, then it would have been nice if
R-bit and EoR were at same level.
All in all, the old code seems correct - and beautiful in its
simplicity. While the new code isn't technically wrong and won't cause
persistent issues (as far as I can see), there is the downside of above
scenario where it causes extra load - and I can see no upside?
It's state-indeterministic. It depends on (invisible remote) configured
timer and runtime-variability (e.g. load induced issues), which I find
annoying and nasty.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
On the eighth day, God created FORTRAN.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
