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

[Huaimo Chen]

Hi Gyan,

Gyan> I know we are trying to adopt an flooding algorithm
and from my reading up on all proposed algorithms, the dynamic flooding seems 
to be geared towards Data Center  partial mesh high x ECMP leaf spine 
architecture, where redundant flooding is problematic using either centralized 
area leader or distributed flooding using same dynamic algorithm,  versus the 
call for adoption flood reduction algorithm seems to geared towards full mesh 
but from what I can tell would not be the preferred for clos multi tier DC leaf 
spine topology with high x ECMP paths.

[HC]: The algorithm in the call for adoption is also for (or say, gear towards) 
clos multi tier DC leaf spine topology with high x ECMP paths. In the Appendix 
of the draft, a full mess example topology of 5 nodes is used to illustrate the 
steps of the algorithm in some details. Using this topology is for easily 
"drawing" it and illustrating the steps of the algorithm. "Drawing" a clos 
multi tier DC leaf spine topology high x ECMP paths to illustrate the algorithm 
in details is very hard in the draft.

Best Regards,
Huaimo

From: Gyan Mishra 
Sent: Sunday, May 24, 2020 6:29 PM
To: Sarah Chen ; tony...@tony.li 
Cc: Acee Lindem (acee) ; Huaimo Chen 
; lsr@ietf.org 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Hi Acee

Do you know if the dynamic flooding algorithm discussed during interim ietf by 
Sarah and Toni is the same as the one implemented by Cisco on Nexus platform or 
is Cisco’s Dynamic flooding a proprietary implementation?

Cisco’s flooding algorithm does seem almost identical to dynamic flooding..

Cisco Dynamic flooding - Nexus 9k

https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743015.html


Dynamic Flooding - Arista - Sarah & Toni

https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html

Flood reduction- H Chen - WG adoption pending

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


I know we are trying to adopt an flooding algorithm
and from my reading up on all proposed algorithms, the dynamic flooding seems 
to be geared towards Data Center  partial mesh high x ECMP leaf spine 
architecture, where redundant flooding is problematic using either centralized 
area leader or distributed flooding using same dynamic algorithm,  versus the 
call for adoption flood reduction algorithm seems to geared towards full mesh 
but from what I can tell would not be the preferred for clos multi tier DC leaf 
spine topology with high x ECMP paths.

Why would we not want to adopt the best algorithm that is best for both full 
mesh and non full mesh leaf spine topology algorithm that works for all 
physical topologies and adopt that draft.

Unless a one size fits all won’t work I would like to understand why one best 
solution draft we come up with for an FT algorithm for all possible physical 
topologies cannot be picked for WG adoption.

Why would we want to adopt multiple flooding algorithms?

Gyan

On Sat, May 23, 2020 at 4:43 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


On Fri, May 22, 2020 at 9:02 PM mailto:tony...@tony.li>> wrote:

Hi Gyan,

I think with clos spine leaf the mesh is much more intensive and problematic 
with ECMP then a circular topology nodal mesh that results in duplicate 
redundant flooding that slows down convergence.  With spine leaf it’s like an X 
horizontal width axis and then depth is spine to leaf links.  With spine leaf 
as you grow sideways and the spine expand the redundant ECMP grows and 
redundant flooding grows exponentially and is much worse then circular nodal 
mesh.

One very nice thing about dynamic flooding is that it computes a flooding 
topology at the node level.  If the adjacency between A and B is on the

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

[Huaimo Chen]

Hi Gyan,

Thanks much for your questions. My answers/explanations are inline below.

Best Regards,
Huaimo

From: Gyan Mishra 
Sent: Friday, May 22, 2020 8:41 PM
To: Huaimo Chen 
Cc: Acee Lindem (acee) ; lsr@ietf.org 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Hi Huaimo

Thank you for the slide deck.  That really helps understand the algorithm.

I will let you know if I have any questions.

The goal of the algorithm is to speed up convergence by limiting the 
convergence scope and expanding out 1 link at a time until all nodes and links 
are part of the flood scope.  From the examples in the slide deck I did not see 
mentioned what is done with the dynamic flooding algorithm where when you have 
a meshed network in the slide 5 examples, how do you limit the flooding on 
redundant links duplicate flooding with the many meshed paths as you 
iteratively grow the FT nodes scope Cq().  I believe with the dynamic flooding 
it does a degree of 2 so 2 links between nodes.
[HC]: The slide 5 example illustrates step 4 of the algorithm in section 4.1. 
When the algorithm reaches this step, all the nodes are  on the FT, but some of 
them may have degree of 1 (i.e., one link on the FT connected to the node). 
This step makes sure that every node on the FT has degree of at least 2.  It 
seems that the dynamic flooding expects the FT having its every node with 
degree of at least 2 for redundancy. In the Dynamic Flooding on Dense Graphs, 
link states will be flooded over the links on the FT. For example, for a node 
with degree of N (e.g., 3), when the node receives a link state from one link 
on the FT, it will flood the link state to the other N-1 (e.g., 3-1=2) links on 
the FT.

I think with clos spine leaf the mesh is much more intensive and problematic 
with ECMP then a circular topology nodal mesh that results in duplicate 
redundant flooding that slows down convergence.  With spine leaf it’s like an X 
horizontal width axis and then depth is spine to leaf links.  With spine leaf 
as you grow sideways and the spine expand the redundant ECMP grows and 
redundant flooding grows exponentially and is much worse then circular nodal 
mesh.
[HC]: In the slides, a full mess topology is used to illustrate the algorithm 
in some details. The algorithm can be used to compute FT for any other topology 
such as clos spine leaf. For topology with M (e.g., 100) parallel links between 
any pair of nodes X and Y, the algorithm will just add one link to the FT 
between X and Y, the other M - 1 (e.g., 100-1 = 99) links will not be added to 
the FT. Thus the link states will flood over only this one link between X and Y 
on the FT and will not flood over the other M - 1 (e..g., 100 - 1 = 99) links, 
which are not on the FT.

Thank you

Gyan

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[tony . li]

Hi Gyan,


> Do you know if the dynamic flooding algorithm discussed during interim ietf 
> by Sarah and Toni is the same as the one implemented by Cisco on Nexus 
> platform or is Cisco’s Dynamic flooding a proprietary implementation?


It appears not to be.  Our algorithm is not limited to leaf-spine topologies 
and has been tested against numerous other dense and sparse topologies.


> Why would we not want to adopt the best algorithm that is best for both full 
> mesh and non full mesh leaf spine topology algorithm that works for all 
> physical topologies and adopt that draft.  


Proving that an algorithm is ‘optimal’ is going to be very difficult, both from 
a theoretical and market standpoint. As is frequently the case with IETF, we 
are proposing many ideas and trying to sort through them.


> Unless a one size fits all won’t work I would like to understand why one best 
> solution draft we come up with for an FT algorithm for all possible physical 
> topologies cannot be picked for WG adoption.
> 
> Why would we want to adopt multiple flooding algorithms?


Adoption does not imply that it will be standardized.  It merely means that 
it’s part of the working group’s effort.  It is up to the WG and the market to 
decide which algorithms we should pursue.  Some may be enhanced, some may be 
revised, and some may be discarded. We can also adopt all of them and let the 
market sort it out.  That’s probably not the optimal approach from a 
technological perspective, but making real decisions in the modern IETF is very 
hard.

Tony


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Hi Acee

Do you know if the dynamic flooding algorithm discussed during interim ietf
by Sarah and Toni is the same as the one implemented by Cisco on Nexus
platform or is Cisco’s Dynamic flooding a proprietary implementation?

Cisco’s flooding algorithm does seem almost identical to dynamic flooding.

Cisco Dynamic flooding - Nexus 9k

https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743015.html


Dynamic Flooding - Arista - Sarah & Toni

https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html

Flood reduction- H Chen - WG adoption pending

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


I know we are trying to adopt an flooding algorithm
and from my reading up on all proposed algorithms, the dynamic flooding
seems to be geared towards Data Center  partial mesh high x ECMP leaf spine
architecture, where redundant flooding is problematic using either
centralized area leader or distributed flooding using same dynamic
algorithm,  versus the call for adoption flood reduction algorithm seems to
geared towards full mesh but from what I can tell would not be the
preferred for clos multi tier DC leaf spine topology with high x ECMP paths..

Why would we not want to adopt the best algorithm that is best for both
full mesh and non full mesh leaf spine topology algorithm that works for
all physical topologies and adopt that draft.

Unless a one size fits all won’t work I would like to understand why one
best solution draft we come up with for an FT algorithm for all possible
physical topologies cannot be picked for WG adoption.

Why would we want to adopt multiple flooding algorithms?

Gyan

On Sat, May 23, 2020 at 4:43 PM Gyan Mishra  wrote:

>
>
> On Fri, May 22, 2020 at 9:02 PM  wrote:
>
>>
>> Hi Gyan,
>>
>> I think with clos spine leaf the mesh is much more intensive and
>> problematic with ECMP then a circular topology nodal mesh that results in
>> duplicate redundant flooding that slows down convergence.  With spine leaf
>> it’s like an X horizontal width axis and then depth is spine to leaf
>> links.  With spine leaf as you grow sideways and the spine expand the
>> redundant ECMP grows and redundant flooding grows exponentially and is much
>> worse then circular nodal mesh.
>>
>>
>> One very nice thing about dynamic flooding is that it computes a flooding
>> topology at the node level.  If the adjacency between A and B is on the
>> flooding topology, then any single link between them may be used for
>> flooding.  If you have 128 way parallel links, this is an immediate 128x
>> improvement in flooding overhead.  What’s more, A and B do not need to
>> agree on which link they are using and can use different links, resulting
>> in an asymmetric situation, without any loss of correctness or performance.
>>
>
>Gyan>. Agreed.  The dynamic flooding really helps with X way ECMP
> prevalent in high density data center clos multi tier leaf spine parial
> mesh topologies that scale massive bandwidth breadth wise horizontally for
> E-W flows.
>
>>
>> Regards,
>> Tony
>>
>> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr