Given Les chimed in I can't resist either now ;-)  Individual musings a bit
having done some of the stuff in the past ;-)

On Fri, Apr 6, 2018 at 1:06 PM, Les Ginsberg (ginsberg) <>

> I think this discussion has already gone much too far in the direction of
> customized flooding optimizations. Such is the nature of the engineering
> mind – give us a problem to solve and we’ll come up with a plethora of
> solutions.
> The right perspective (for me anyway) is this:
> IGPs have been  popular as distribution mechanisms in part because of the
> reliability of  their flooding process. This wasn’t easy to achieve – and
> those of us who have been in the business long enough have seen attempts to
> create something equivalent fall flat on their face because they couldn’t
> handle the corner causes. Simple yet robust has been the guiding principle
> and both IGPs do this well.

yepp, flooding is hard to get right ;-) However, flooding _is_ a problem in
a highly densed mesh @ scale (which DC fabrics are), bandwidth less so then
the sheer amount of updates generated & necessary CPU power needed IME.
That can be addressed in different ways, flooding DAG optimization variants
being one of them ;-)

> I agree with Peter’s suggestion  that a common decentralized algorithm is
> desirable. It will simplify problems associated with reconvergence which I
> think is key.

well, on one hand we have the "telephony networks solution" a.k.a.  a
single node doing all the computation/enforcing state on all. Intoxicating
in its simplicity, unpleasant in its fragility. Plus, what happens if a
_2nd_ node happens to start advertising something else ;-) ?  I think that
e.g. the FlexAlgo currently suggested solution for that problem (i.e.
multiple sources of truth with preference tie-breaking) is a good trade-off
here modulo the necessary convergence time.

On the other hand we have the "fully distributed algorithm" which is
intoxicating in its robustness and frustrating in the time it takes to get
them right if not highly skilled in the art or specs have holes ;-) Well,
for that matter any eventual consistency distributed system is hard (unless
epsilon is inifite ;-)

> And I don’t think we really need to support multiple algorithms – it was
> nice of Peter to allow for that – but as we see now everyone is concerned
> about the upgrade issues that come with introducing a new algorithm.

That I would concur with ...

> Let’s agree on one algorithm and be done.
> A variant on is one
> such candidate.
And here the dog has more hair than what it initially looks like (from
[however quite dated in case of this problem ;-)] implementation
experience).   First, @ scale a single spanning tree tends to be tad
fragile on failures/convergence, generates "hot-links" on which e'one has
to wait to converge. Doing two max disjoint trees is not easy but doable
from experience @ very non-neglectible complexity. And it's still not fully
"load-balancing" flooding which would be the ideal thing of course. Then,
and I think Tony describes the problem quite well in the draft in its
nature, the problems of diameter and fanout control starts to play a role.
A min-diameter algorithm is (non-distributed) AFAIR a clique problem and
with that NP complete (albeit some good heurestics were around, it's too
long for me to recall).

This of course all having to do with trying to solve a generic graph
problem. If we focus on lattices/Haase/partially ordered graphs (think CLOS
as practical variant or anything that has a north and a south) then the
problem of almost optimal flood reduction while load balancing is quite
tractable in distributed fashion we discovered but we're working on it as
we speak so look for the -06 draft update in another group ;-)

my 2c, rusty and dented but not debased l;-)

--- tony
Lsr mailing list

Reply via email to