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 >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
