Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Tony Przygienda <[e-mail]>]

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=
[e-mail]> 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 [e-mail]" <
> [e-mail] on behalf of [e-mail]> 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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/lsr
>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>