OK, good, real work. So from some scar tissue here's one question a) we are talking any kind of topology for the solution, i.e. generic graph?
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 ;-) 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) 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 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 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. 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 ;^} ]). --- tony On Fri, Aug 24, 2018 at 8:36 AM Acee Lindem (acee) <acee= 40cisco....@dmarc.ietf.org> wrote: > Speaking as WG member: > > I agree on this and don't believe we need a separate document or a > protracted discussion. > Additionally, I don't think we should worry about anything going on in > other WGs. > Thanks, > Acee > P.S. I'll provide more input to the discussion as well. As luck would have > it, I initiated the discussion and then had a couple more pressing matters > (including the cable company's fiber installation contractor messing up my > irrigation system ;^( > > On 8/24/18, 11:04 AM, "Lsr on behalf of tony...@tony.li" < > lsr-boun...@ietf.org on behalf of tony...@tony.li> wrote: > > > So, going Old Skool here: > > Since everyone agrees that this is a reasonable direction, how about > we have a real discussion on the list? > > Requirement number 1 is straightforward: a significant reduction in > flooding overhead. > > The basis for this requirement is the understanding that in a dense > topology, there is a great deal of redundancy due to flooding, and that it > is this redundancy that supersaturates the control plane. > > Do we agree on this? > > 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 >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr