Hi Yingzhen,
Thank you very much for your support and comment.
My answer/explanation is inline below.
Best Regards,
Huaimo
________________________________
From: Yingzhen Qu <[email protected]>
Sent: Friday, June 5, 2020 3:37 PM
To: Acee Lindem (acee) <[email protected]>; [email protected]
<[email protected]>; Huaimo Chen <[email protected]>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm -
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
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.
[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
From: Lsr <[email protected]> on behalf of "Acee Lindem (acee)"
<[email protected]>
Date: Friday, June 5, 2020 at 10:09 AM
To: "[email protected]" <[email protected]>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm -
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
Resent-From: <[email protected]>
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 protected]> on behalf of "Acee Lindem (acee)"
<[email protected]>
Date: Friday, May 15, 2020 at 3:40 PM
To: "[email protected]" <[email protected]>
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/<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
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
