Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Yingzhen Qu <[e-mail]>]

Hi Tony,

Thanks for jumping in and the explanation. I support the idea of tradeoffs between pefection and simplicity. Analysis about the change of topology can be tricky, especially when adding links, and for a distributed algorithm it’s more important to achieve a definitive result. Maybe it’s easier to optimize some cases in a centralized-mode, but we always need to consider benefit-cost ratio.

The text in the draft is “MUST be”, so I thought I’d ask to confirm.

Thanks,
Yingzhen

From: Tony Li <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Friday, June 5, 2020 at 2:56 PM
To: Yingzhen Qu <[e-mail]>
Cc: "Acee Lindem (acee)" <acee=[e-mail]>, "[e-mail]" <[e-mail]>, Huaimo Chen <[e-mail]>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Hi,



I have a question regarding the draft. At the end of section 3, it says if there is any change in the base topology, the flooding topology MUST be re-computed. So in case of a link failure in the base topo, it’s possible that the link is not part of the flooding topology (e.g. one of the multiple links between two nodes), it might be optimal if we can figure it out and save recalculation here.


This comment isn’t specific to this algorithm, so you’ll pardon me if I jump in.

Always recomputing the flooding topology is always a safe thing to do and for the case of a distributed algorithm is probably the safest design choice.

Doing the analysis about the change is not exactly trivial and computing the flooding topology is not that hard.  We are typically not short of CPU cycles and recomputing the flooding topology is outside of the critical convergence window, so while there is some theoretical benefit, it’s not at all clear that it’s of great practical benefit.  But it is up to those specifying the algorithm.

Regards,
Tony