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) <[email protected]> wrote: > 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 https://tools.ietf.org/html/rfc6325#section-4.5.1 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
