Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

[Robert Raszuk <[e-mail]>]

> This is true, btw, of the centralized flood reduction mechanisms I've
seen,

Really ?

My understanding it that only LSP originator limits the flooding scope
based on the optimized topology reception (or in distributed case local
computation) not any via node.

Cheers,
R.



On Sat, Jan 9, 2021 at 12:30 AM <[e-mail]> wrote:

>
> > I agree with Les. While you might get some flooding reduction out of
> > this, it wouldn’t be hard to better with a flooding next-neighbor
> > algorithm that was more well-thought (e.g., RFC 5614). Here are my
> > concerns:
>
> We are trying to avoid the LLS work in OSPF ...
>
> In testing, this shows a dramatic decrease in the amount of flooding in 3
> and 5 stage fabrics. Of course, this would also work for any random
> topology (even MANET networks), so it's not really limited to DC fabric use.
>
> > 1.    It seems that while it is a distributed algorithm, the change of
> > flooding scope makes it somewhat quasi-centralized as you are making the
> > flooding decision for your neighbor. Perhaps, these parts of the
> > algorithm were developed with different Email addresses 😉
>
> I switched off gmail ... which is probably a good thing. 😊
>
> > 2.    I don’t like the fact that IS-IS routers are changing the
> > flooding scope of an LSP that they didn’t originate themselves (Les’s
> > concern). This flooding scope modification could be removed but then
> > that would take away the novelty of the algorithm.
>
> This, it seems to me, is always going to be true of any flooding
> optimization -- unless you have the originator "mark" where each LSP
> "should go," something like a BIER bitfield embedded in the packet. This is
> true, btw, of the centralized flood reduction mechanisms I've seen, and is
> even true of 5614.
>
> > 3.    The mechanisms for recovering from flooding failures is pretty
> > brute force…. A CNSP with every neighbor at sub-second intervals? Seems
> > this could negate much of what you are saving in flooding.
>
> It's not constant subsecond CSNPs, but rather a single additional CSNP.
>
> > 4.    The way the document is written, the flooding decision is made
> > independently for every LSP. This seems unnecessary and it be per
> > neighbor (or even less granular) with no loss of optimization.
>
> I don't think it's implemented this way ... perhaps Shraddha can comment
> on how she implemented it. The FR/R implementation is not per LSP, either,
> AFAIK, but I can poke at the code again.
>
> 😊 /r
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>