Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Robert Raszuk <[e-mail]>]

I fully agree and support proceeding with  draft-li-dyanmic-flooding and to
include protocol extensions in it for centralized topology propagation as
well as basic hooks like "execute dynamic protocol number X" for
distributed calculations.

However one may observe that separate distributed algorithms may define
their own protocol extensions and they should not break the above in any
way.

Then there is already some requirements of building two disjoined
topologies in any rich ECMP DC fabric one say for primary paths the other
for backup flows. (Case of active-active dual streaming applications).
Question arises if this would be addressed also as part of basic spec, be
combined with one or many of distributed algorithms or will require yet one
more document which in turn will "extend" all of the above ? And before
anyone suggests multi instance approach with logical or physical link
separation it is not the right direction here. If anything perhaps MTR or
SR come a bit closer.

Kind regards,
Robert.


On Sun, Feb 3, 2019 at 9:14 PM <[e-mail]> wrote:

>
> I think that this discussion would be greatly clarified if we clearly
> separated the discussion between
>
> a) the algorithm for computing the flooding topology, and
> b) the signaling to indicate how to proceed.
>
> I think that we are all in agreement that the algorithms can and should be
> separated from the signaling.
>
> I think that we are all in agreement that each algorithm should be
> independent.
>
> I’m of the opinion that the centralized signaling is a bit more extensive
> than the signaling for the distributed mode, but that there is also
> considerable overlap and that things would
> be unnecessarily redundant if we were to separate them. I believe that we
> are not in disagreement about the basics for the distributed signaling.
>
> If you disagree with this, please clearly articulate why you feel the
> signaling should be separated.
>
> Regards,
> Tony
>
>