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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 5 Jun 2020 16:52:46 +0000

Speaking as WG Member:

Hi Authors,

I have a couple technical comments on the draft.

  1.  The algorithm only computes a single graph with single path to each node. While I-D.ietf-lsr-dynamic-flooding failure and computation of an updated flooding topology, many of the other algorithms (both draft and proprietary) attempt to compute two or more paths to each node.
  2.  Since this algorithm is slated for use as a distributed algorithm, all routers in the area must use the same value for MaxD or they may compute different flooding topologies. This is cannot be guaranteed by a single algorithm IANA value unless we allow some number of algorithm specific parameters to be advertised by the area leader (which might not be a bad idea).
  3.   Similarly, the constraints in section 4.2 must be applied uniformly and different constraints would require new IANA algorithm allocation.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of "Acee Lindem (acee)" <acee=[email-masked]>
Date: Friday, May 15, 2020 at 3:40 PM
To: "[email-masked]" <[email-masked]>
Subject: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

This begins a 3 week (due to holidays) WG adoption call for the “Flooding Topology Computation Algorithm” draft. Please issue your support or objection to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your convenience.

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/

Thanks,
Acee

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 5 Jun 2020 19:37:39 +0000

Hi,

I support adoption of this draft.

Hi Huaimo,

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.

Thanks,
Yingzhen

From: Lsr <[email-masked]> on behalf of "Acee Lindem (acee)" <acee=[email-masked]>
Date: Friday, June 5, 2020 at 10:09 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
Resent-From: <[email-masked]>

Speaking as WG Member:

Hi Authors,

Thanks,
Acee

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cc-lsr-flooding-reduction%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C548f8195e2c645d22c8308d8097321cf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637269737558376155&sdata=ZzzEb%2BAoqJIlp9eAtAnQ8CCgTqamuCYqcBCTeNOMhc0%3D&reserved=0>

Thanks,
Acee

---

From: [email-masked]
Date: Fri, 5 Jun 2020 14:56:13 -0700

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 b…

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

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 5 Jun 2020 22:25:10 +0000

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

Hi,

Regards,
Tony

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 6 Jun 2020 01:03:14 +0000

Hi Acee,

    Thank you very much for your valuable comments.
    My answers/explanations are inline below.

Best Regards,
Huaimo
________________________________
From: Lsr <[email-masked]> on behalf of Acee Lindem (acee) <acee=[email-masked]>
Sent: Friday, June 5, 2020 12:52 PM
To: [email-masked] <[email-masked]>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Speaking as WG Member:

Hi Authors,

  1.  The algorithm only computes a single graph with single path to each node. While I-D.ietf-lsr-dynamic-flooding failure and computation of an updated flooding topology, many of the other algorithms (both draft and proprietary) attempt to compute two or more paths to each node.
[HC]: The flooding topology (or say a graph) computed by the algorithm has at least two paths to each node. At step 4 of the algorithm on page 5 of the draft, for each node B that has only one path to it on the flooding topology (i.e., the Degree of node B is one) , another path is added to it. Thus the final flooding topology (or say graph) computed by the algorithm has  two or more paths to every node.
  2.  Since this algorithm is slated for use as a distributed algorithm, all routers in the area must use the same value for MaxD or they may compute different flooding topologies. This is cannot be guaranteed by a single algorithm IANA value unless we allow some number of algorithm specific parameters to be advertised by the area leader (which might not be a bad idea).
[HC]: You are right. All the routers must use the same value for MaxD. We will update the draft for this accordingly. For now, MaxD has an initial value of 3 (i.e., every router uses this initial value of 3 for MaxD).  The algorithm increases MaxD by one and restarts to compute the flooding topology with this new MaxD if it can not compute a flooding topology with the old MaxD. After some iterations in some cases, the flooding topology is computed. It is a good idea to pass some parameters from the area leader to every router when the leader advertises the algorithm number to every router.  MaxD can be one of the parameters.
  3.   Similarly, the constraints in section 4.2 must be applied uniformly and different constraints would require new IANA algorithm allocation.
[HC]: You are right. All the routers must use the same constraints.  A new (or different) set of constraints need a new algorithm number. We will update the draft for this accordingly.

Thanks,
Acee

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cc-lsr-flooding-reduction%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C1a7e82ec42fa40a9ad8e08d80970ea4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637269727959858751&sdata=eG3iR27JyxGL6qCsqlMow47twBhMpf0%2BsgJo6Q9hBJg%3D&reserved=0>

Thanks,
Acee

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 6 Jun 2020 01:34:02 +0000

Hi Yingzhen,

    Thank you very much for your support and comment.
    My answer/explanation is inline below.

Best Regards,
Huaimo
________________________________
From: Yingzhen Qu <[email-masked]>
Sent: Friday, June 5, 2020 3:37 PM
To: Acee Lindem (acee) <acee=[email-masked]>; [email-masked] <[email-masked]>; Huaimo Chen <[email-masked]>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Hi,

Hi Huaimo,

[HC]: This will make sure that the flooding topologies computed by all the routers will be the same. If the algorithm does not compute a new flooding topology when a link that is not on the current flooding topology fails, we need prove that in any sequence of changes in base topology reaching to different LSDBs in different times the flooding topology computed by the algorithm on one router will be the same as the one computed by the algorithm on another router in this way.  After there is a proof, the optimized algorithm can be used.

Thanks,

Yingzhen

Speaking as WG Member:

Hi Authors,

Thanks,
Acee

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cc-lsr-flooding-reduction%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C41eead7b49484332128d08d80987e8b8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637269826621073729&sdata=mScDoVdFmFXGhPmKPfq0jG5fgJub4Sb8abZ4%2BVVQzVk%3D&reserved=0>

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 6 Jun 2020 18:49:06 +0000

Hi Huaimo,

From: Huaimo Chen <[email-masked]>
Date: Friday, June 5, 2020 at 9:03 PM
To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Hi Acee,

Best Regards,
Huaimo

Speaking as WG Member:

Hi Authors,

Ok – I see this now.

I see you’ve updated this in the latest.

Thanks,

Acee

Thanks,
Acee

Thanks,
Acee