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

[Robert Raszuk <[e-mail]>]

Hi Peter,

Many thx for your comment.

What I had in mind here was use of multi instance (=2) over very reach
physical topologies. So when we construct flooding graph for each such
instance - even in centralized mode - the intention was to avoid flooding
to take common links (just to reduce the impact of any failure to have
effect on both instances). Yes of course data paths are different from
flooding graph so I was just talking about the latter.

I know that perhaps this should be moved to a different thread - the only
reason why I mentioned about it here was that it is not immediately obvious
to me if extensions which we have today defined in draft-li will be
sufficient. Perhaps for centralized indeed they would be just fine as
central graph compute oracle could be smart enough to address it. For
distributed I am not sure.

I did not want to derail the main topic though so let's shift it for other
chat.

Kind regards,
Robert.

primary/backup topologies are used for transmitting user data, not
> necessarily the flooding data. I don't see how they are related to the
> flooding topology, which is used for flooding only.
>
> To the point, if a new distributed algorithm is defined that needs more
> data to be signaled, then we will extend the existing signaling. I don't
> see that being a problem. The way the signaling is defined in
> draft-li-lsr-dynamic-flooding does allow for such thing.
>
> thanks,
> Peter
>