I think distributed is more practical too. For computing routes, we have been using distributed SPF on every node for many years. In fact, we may not need to run the exact algorithm on every node. As long as the algorithms running on different nodes generate the same result, that would work.
Best Regards, Huaimo -----Original Message----- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li Sent: Friday, August 24, 2018 12:29 PM To: Tony Przygienda <tonysi...@gmail.com> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.i...@gmail.com>; Peter Psenak <ppse...@cisco.com>; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward > a) we are talking any kind of topology for the solution, i.e. generic graph? Well, the problem with a topology restriction is that mistakes happen. If we have a solution for a pure bipartite graph (i.e., a leaf-spine topology) and someone mistakenly inserts a leaf to leaf link, what happens? Having the entire DC implode would be a Bad Thing, IMHO. > and then suggestion for IME realistic, operational MUST requirements > > b) req a): the solution should support distributed and centralized algorithm > to compute/signal reduced mesh(es). I personally think distributed is the > more practical choice for something like this but it's my 2c from having > lived the telephony controller fashion, the distributed fashion and the > controller fashion now again ;-) Well, I did think long and hard about this. Being distributed would be very nice. However, that implies that all nodes are going to get to the exact same solution. Which implies that they all must execute the same algorithm, presumably with the same inputs. That’s all well and good, but we don’t have an algorithm to really put on the table yet. We need experience with one. We know we want to tweak things based on biconnectivity, performance, and degree because doing it right day one seems unlikely. Changing algorithms is going to be VERY painful if it’s distributed. However, if it’s centralized, it’s completely trivial. So, my strong preference is to start centralized. Iterate on the algorithm until we have it where we want it. And then take it distributed if there’s a point to it. However, at that point, we have something working. So why fix it? > c) req b): the solution should include redundancy (i.e. @ least 2 maximally > disjoint vertex covers/lifts) to deal with single link failure (unless the > link is unavoidably a minimal cut on the graph) Not everyone agrees with this, but some do. This seems like one possible input to the algorithm. > d) req c): the solution should guarantee disruption free flooding in case of > i) single link failure > ii) single node failure > iii) change in one of the vertex lifts Sorry, I don’t understand point iii). > e) the solution should not lead to "hot-spot" or "minimal-cut" links which > will disrupt flooding between two partitions on failure or lead to flood > throughput bottlenecks Agreed. > I am agnostic to Tony L's thinking about diameter and so on. It makes sense > but is not necessarily easy to pull into the solution. It all boils down to the point that Peter just made about performance. A topology with a high diameter is going to require many flooding hops and hurt performance. To be avoided... > moreover, I observe that IME ISIS is much more robust under such > optimizations since the CSNPs catch (@ a somehow ugly delay cost) any corner > cases whereas OSPF after IDBE will happily stay out of sync forever if > flooding skips something (that may actually become a reason to introduce > periodic stuff on OSPF to do CSNP equivalent albeit it won't be trivial in > backwards compatible way on my first thought, I was thinking a bit about > cut/snapshot consistency check [in practical terms OSPF hellos could carry a > checksum on the DB headers] but we never have that luxury on a link-state > routing protocol [i.e. we always operate under unbounded epsilon consistency > ;-) and in case of BGP stable oscialltions BTW not even that ;^} ]). Emacs Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
