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

Hi Huaimo

Thinking about physical topology a little further as with the FT algorithm
it makes sense to decouple the FT from the physical however the overall
coverage is based on those basic parameters of degree number of links and
nodes as well as width and depth of the topology.

Thinking about it further the clos leaf spine DC style topology is much
worse in terms of flooding due to physical topology that leafs don’t
physical connection and are interconnected via the spine creating massive
ECMP and overload of the spine super spine.  So the physical DC leaf spine
topology really exacerbates the flooding due to the non full mesh nature of
the topology.

With a service provider core which is typically a mesh style multi tier
multiple concentric circles mix of full and partial mesh and hub spoke type
physical topologies.

So with flooding with full mesh every node connects with every node so you
don’t have an overload of flooding being funneled through a super spine as
you do with a leaf spine DC architecture.  So in a full mesh which is the
best case scenario for flooding perspective from my point of view which
each node as root connects to all nodes and then you can iteratively grow
the flooding scope and it’s pretty controlled and you can limit the
redundant flooding.  When the physical topology changes to a much more
partially meshed the ECMP paths grow astronomically as does the flooding
and longer convergence time.

So I think in the slide deck and draft look at scenario where their is
tremendous ECMP from partial meshing and how the flood reduction algorithm
improves the flooding and convergence.

Kind regards

Gyan

On Fri, May 22, 2020 at 8:41 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> 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.
>
> 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.
>
> Thank you
>
> Gyan
>
> On Fri, May 22, 2020 at 10:05 AM Huaimo Chen <huaimo.chen@futurewei.com>
> wrote:
>
>> Hi Gyan,
>>
>>     Thanks much for your questions. My answers/explanations are inline
>> below.
>>
>> Best Regards,
>> Huaimo
>> ------------------------------
>> *From:* Gyan Mishra <hayabusagsm@gmail.com>
>> *Sent:* Thursday, May 21, 2020 10:13 PM
>> *To:* Acee Lindem (acee) <acee@cisco.com>
>> *Cc:* Huaimo Chen <huaimo.chen@futurewei.com>; lsr@ietf.org <lsr@ietf.org
>> >
>> *Subject:* Re: [Lsr] Flooding Topology Computation Algorithm -
>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>
>>
>> I think for both drafts it would be good to have a stick diagram at a
>> minimum.
>> [HC]: A diagram for illustrating the steps of the algorithm is in
>> Appendix.
>> I majored in EE with math  minor and both drafts are hard to follow
>> without a diagram with labels showing the exact topology examples.
>>
>> Four main topologies - full mesh, partial mesh and leaf spine ( 2 tier)
>> and CLOS ( 3 tier) - real world scenario’s.
>>
>> From the interim meeting was their a slide deck visual topology shared?
>> [HC]: The set of slides presented in IETF 105 is attached.
>>
>> That would help.
>>
>> https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-cc-lsr-flooding-reduction-08&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446371900&sdata=glKNEHI0pmavkJwY%2BykW0%2BArX10F74JP0WMEvG6FY88%3D&reserved=0>
>>
>> 4.1
>>
>> Step 1 - Build Cq candidate queue
>>
>> For each node B on FT whose D is one (from minimum to maximum
>>        node ID), find a link L attached to B such that L's remote node R
>>        has minimum D and ID, add link L between B and R into FT and
>>        increase B's D and R's D by one.  Return FT.
>>
>> My interpretation is the algorithm an iterative loop and starts with any
>> node in the candidate list so could start from edge and work left to right
>> or vice versa.  For loop to build FT from Cq = with each node B with
>> directly attached node R via link L.  Increment node B from Cq until the FT
>> is build for all nodes.  Instead of starting with a wide diameter FT
>> matching physical topology we start micro topology with D=1 and go node by
>> node.
>> [HC]: This (For each node B on FT .... Return FT.) is an iterative loop
>> after every node is added to FT. This loop connects each node whose D = 1
>> (i.e., there is only one link attached to it on FT) to a node through a
>> link on FT (i.e., add the link to FT) to make every node on FT to have its
>> D > 1. Page 5 of the attached slides shows some details for this loop.
>>
>> 4.2
>>
>> 1.  Finding and removing the first element with node A in Cq that is
>>        not on FT and one PH's D in PHs < MaxD and PH's D < PH's ConMaxD.
>>
>>        If A is root R0, then add the element into FT
>>
>>        otherwise  (i.e., A != R0 with one PH's D in PHs < MaxD and PH's
>>           D < PH's ConMaxD.  Assume that PH is the first one in PHs
>>           whose D < MaxD and PH's D < PH's ConMaxD), PH's D++, and add A
>>           with D = 1 and PHs = {PH} into FT.
>>
>>        Note:  if there is no element with a node in Cq satisfying the
>>           conditions, then algorithm may be restarted from R0, ++MaxD,
>>           Cq = {(R0,D=0,PHs = { })}, FT = { };
>>
>> This is similar to 4.1 with micro topology with 2 directly connected
>> nodes
>> [HC]: It is similar to 1. in section 4.1.
>>
>> https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-chen-lsr-dynamic-flooding-algorithm-00.html&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446371900&sdata=0%2B33ORq8CFVJuZjTNSQwvI1UjK6W8xdcz%2FlOXsYMTxc%3D&reserved=0>
>>
>> My interpretation of the algorithm from the verbiage.
>>
>> So this draft starts in the middle of the topology and is geared towards
>> leaf spine 2 or 3 tier clos topology.
>>
>> For this one we build the bi graph so that could be leaf connected to two
>> spines or spine connected to two leafs and iteratively build out the FT
>> topology 3 node arch  spine leaf spine or leaf spine leaf.
>>
>> Kind regards
>>
>> Gyan
>>
>> On Thu, May 21, 2020 at 7:01 PM Acee Lindem (acee) <acee@cisco.com>
>> wrote:
>>
>> Hi Gyan,
>>
>>
>>
>> *From: *Gyan Mishra <hayabusagsm@gmail.com>
>> *Date: *Thursday, May 21, 2020 at 4:20 PM
>> *To: *Acee Lindem <acee@cisco.com>
>> *Cc: *Huaimo Chen <huaimo.chen@futurewei.com>, "lsr@ietf.org" <
>> lsr@ietf.org>
>> *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>
>>
>>
>>
>>
>> Yes and I have started reviewing the LSR mail archives as I am late in
>> the discussion for this.
>>
>>
>>
>> If you have link to any particular dates in the archives would be helpful.
>>
>>
>>
>> No – it was more an “evolution” than an “epiphany”.
>>
>>
>>
>> That sums up all the questions I have so if all answered in the archives
>> then I am all set.
>>
>>
>>
>> I support the draft moving forward as flood reduction is a much needed
>> feature.
>>
>>
>>
>> I think overall both drafts will really help large data centers with any
>> overlay underlay vxlan spine leaf meshed CLOS highly meshed topology that
>> scales out horizontally with a large spine footprint - this is a much much
>> needed feature.  This also helps eliminate complexity of the workaround of
>> using BGP in the underlay which to me adds tremendous complexity.
>>
>>
>>
>> Here is the other recently presented dynamic flooding draft.
>>
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-lsr-dynamic-flooding-algorithm%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446381892&sdata=iCY2RDNVQtNcoWRomiMNfyyVhtAf7DossHwlhuHdsM0%3D&reserved=0>
>>
>>
>>
>> You can see they both make use of the dynamic flooding infra in
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-dynamic-flooding%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446381892&sdata=m%2FyOgcPdrBoA2ZPOs0jhC%2BT%2B4sxDes%2BooNO9hqQ1CIA%3D&reserved=0>
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Gyan
>>
>>
>>
>> On Thu, May 21, 2020 at 4:07 PM Acee Lindem (acee) <acee@cisco.com>
>> wrote:
>>
>> Speaking as WG Co-chair:
>>
>>
>>
>> Hi Gyan,
>>
>>
>>
>> I guess you’ve joined this discussion late. It might be a good idea to
>> review the LSR mailing list archives.
>>
>>
>>
>> *From: *Gyan Mishra <hayabusagsm@gmail.com>
>> *Date: *Thursday, May 21, 2020 at 1:51 PM
>> *To: *Huaimo Chen <huaimo.chen@futurewei.com>
>> *Cc: *Acee Lindem <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
>> *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>
>>
>>
>>
>>
>>
>>
>> On Thu, May 21, 2020 at 11:01 AM Huaimo Chen <huaimo.chen@futurewei.com>
>> wrote:
>>
>> Hi Gyan,
>>
>>
>>
>>     Thanks much for your questions.
>>
>>
>>
>>  Gyan> How does this draft compare to the WG LC draft for flood
>> reduction.  Would they be two eventual standard options in the operators
>> toolbox  or competing features for optimized flood reduction. Would having
>> two flood reduction features standardized versus one default IGP flood
>> reduction feature be confusing for operators.  Just as it was confusing to
>> me.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-dynamic-flooding%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446391897&sdata=myU2K8Y9ZPNxUZ6LhjTbIJDT5gZo0HBZGCMEwsad6CE%3D&reserved=0>
>>
>>
>>
>>     [HC]: This draft plus the draft for flooding reduction can provide
>> two modes of flooding reductions (i.e., centralized mode and distributed
>> mode). The latter describes the two modes, but does not include any
>> flooding topology computation algorithm for the distributed mode. The
>> former proposes a flooding topology computation algorithm to be used in
>> the distributed mode.
>>
>>
>>
>>    Gyan> It maybe a good idea for both documents to reference each other
>> as to how they play together or  in some respects if any provide a
>> homogeneous complete holistic solution for flooding problem being solved.
>>
>>
>>
>> It is a good idea to have this new draft reference the dynamic-flooding
>> but not vice-versa. The existing dynamic flooding draft provides a
>> framework for any dynamic flooding algorithm that provides a separate
>> flooding topology. This algorithm is just the first to be formally proposed
>> in a draft. Note that another algorithm was presented during the LSR
>> virtual interim which replaced IETF 107.
>>
>>
>>
>> In my opinion it may not be a bad idea even to combine both drafts so the
>> solution is complete and holistic.  This will also make the overall
>> specification flow nicely.
>>
>>
>>
>> No – we’re not going to do this.
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> I know that efforts were made by LSR to have a common IGP solution,
>> however there are many inherent differences between ISIS and OSPF that from
>> IGP Link state protocol perspective you can treat like apples to apples but
>> really it’s apples and oranges.  Maybe it might we wise to have separate
>> draft for both and have references linking together as the same algorithm
>> concept and mathematically however the actual code implementation would
>> vary as the LSDB link state data structures are completely different.
>>
>>
>>
>> Later = Dynamic flooding = 2 modes Centralized leader based and
>> distributed
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-dynamic-flooding%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446401884&sdata=A0He%2BkbFrye6L7vgdHjLIY50hzWE%2Bty0reMCMbE1QF0%3D&reserved=0>
>>
>>
>>
>> This later draft per section excerpt provides both centralized and
>> distributed algorithm see below
>>
>>
>>
>> *6.4 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-dynamic-flooding-05%23section-6.4&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446401884&sdata=K%2BSin3SGk78gUaBME9B5UjYUncvtprSkvLZOF1UWxQE%3D&reserved=0>.  Area Leader Responsibilities*
>>
>>
>>
>>    If the Area Leader operates in centralized mode, it MUST advertise
>>
>>    algorithm 0 in its Area Leader Sub-TLV.  In order for Dynamic
>>
>>    Flooding to be enabled it also MUST compute and advertise a flooding
>>
>>    topology for the area.  The Area Leader may update the flooding
>>
>>    topology at any time, however, it should not destabilize the network
>>
>>    with undue or overly frequent topology changes.  If the Area Leader
>>
>>    operates in centralized mode and needs to advertise a new flooding
>>
>>    topology, it floods the new flooding topology on both the new and old
>>
>>    flooding topologies.
>>
>>
>>
>>    If the Area Leader operates in distributed mode, it MUST advertise a
>>
>>    non-zero algorithm in its Area Leader Sub-TLV.
>>
>>
>>
>>    When the Area Leader advertises algorithm 0 in its Area Leader Sub-
>>
>>    TLV and does not advertise a flooding topology, Dynamic Flooding is
>>
>>    disabled for the area.  Note this applies whether the Area Leader
>>
>>    intends to operate in centralized mode or in distributed mode.
>>
>>
>>
>>    Note that once Dynamic Flooding is enabled, disabling it risks
>>
>>    destabilizing the network.
>>
>>
>>
>> *6.5 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-dynamic-flooding-05%23section-6.5&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446411879&sdata=eqK0e8YFYfRgXo%2F6K%2BSPT3mCdFXDoME6gMLUp%2BcVjB4%3D&reserved=0>.  Distributed Flooding Topology Calculation*
>>
>>
>>
>>    If the Area Leader advertises a non-zero algorithm in its Area Leader
>>
>>    Sub-TLV, all nodes in the area that support Dynamic Flooding and the
>>
>>    value of algorithm advertised by the Area Leader MUST compute the
>>
>>    flooding topology based on the Area Leader's advertised algorithm.
>>
>>
>>
>>    Nodes that do not support the value of algorithm advertised by the
>>
>>    Area Leader MUST continue to use standard flooding mechanism as
>>
>>    defined by the protocol.
>>
>>
>>
>>    Nodes that do not support the value of algorithm advertised by the
>>
>>    Area Leader MUST be considered as Dynamic Flooding incapable nodes by
>>
>>    the Area Leader.
>>
>>
>>
>>    If the value of the algorithm advertised by the Area Leader is from
>>
>>    the range 128-254 (private distributed algorithms), it is the responsibility of the
>>
>> network operator to guarantee that all nodes in the area have a common understanding of what the given algorithm value represents.
>>
>>
>>
>> Former = WG LC
>>
>> https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-cc-lsr-flooding-reduction-08&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446411879&sdata=kIqZH1iGc%2BVFx3SyBaja8Nedu2m7G4OlzHRKxp5Et4o%3D&reserved=0>
>>
>>
>>
>> Provides algorithm for distributed mode for this draft as well as the
>> algorithm to be used for distributed mode later dynamic flooding draft
>>
>>
>>
>> Separate question-
>>
>>
>>
>> In light of the flooding algorithm and seeing that at the bottom of
>> section 6.5 mentions flooding algorithm are the IANA codepoints reserved
>> for flooding unique and non overlapping with the flex algo codepoints I
>> believe 0-127.  I would think the flooding algorithm range of values is
>> completely separate since a different function then flex algo values.
>>
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-07
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-07&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446421873&sdata=s6y04UJjyUATTDuUvKgFl9AtQzuNbV6vgkbeuQw1UNM%3D&reserved=0>
>>
>>
>>
>>
>>
>> Best Regards,
>>
>> Huaimo
>> ------------------------------
>>
>> *From:* Gyan Mishra <hayabusagsm@gmail.com>
>> *Sent:* Thursday, May 21, 2020 10:36 AM
>>
>>
>> *To:* Huaimo Chen <huaimo.chen@futurewei.com>
>> *Cc:* Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; lsr@ietf.org
>> <lsr@ietf.org>
>> *Subject:* Re: [Lsr] Flooding Topology Computation Algorithm -
>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 20, 2020 at 11:59 PM Huaimo Chen <huaimo.chen@futurewei.com>
>> wrote:
>>
>> Hi Gyan,
>>
>>
>>
>>     Thanks much for your questions. My answers are inline below with [HC].
>>
>>
>>
>> Best Regards,
>>
>> Huaimo
>> ------------------------------
>>
>> *From:* Gyan Mishra <hayabusagsm@gmail.com>
>> *Sent:* Wednesday, May 20, 2020 11:14 AM
>> *To:* Huaimo Chen <huaimo.chen@futurewei.com>
>> *Cc:* Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; lsr@ietf.org
>> <lsr@ietf.org>
>> *Subject:* Re: [Lsr] Flooding Topology Computation Algorithm -
>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>
>>
>>
>> Huaimo
>>
>>
>>
>> This is a much needed feature that operators have been needing for
>> densely meshed topologies that commonly exist in data centers to
>> accommodate very high bandwidth E-W traffic.
>>
>> [HC]: Thank you very much.
>>
>>
>>
>> Below is link from Cisco which has introduced feature for dynamic
>> flooding in clos high density ECMP data center topologies.
>>
>>
>>
>> Please look at the feature description and it does seem to be exactly the
>> same as this draft.  Please confirm.
>>
>> [HC]: It seems different.
>>
>>
>>
>> There maybe other vendors due to industry demand have to get the feature
>> deployed before it reaches standards vendor consensus with the IETF.
>>
>>
>>
>>
>> https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743015.html
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Fproducts%2Fcollateral%2Fswitches%2Fnexus-9000-series-switches%2Fwhite-paper-c11-743015.html&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446431887&sdata=WiNe%2B5vVFxheyMEmT92pdJRtoA%2F2WGYtA7HT%2FlJs1J0%3D&reserved=0>
>>
>>
>>
>> We are testing this feature and planning to deploy but wanted to ensure
>> that this is the same as the draft on the standards track.
>>
>> [HC]: The feature appears implemented draft "Dynamic Flooding on Dense
>> Graphs", which does not include any flooding topology computation
>> algorithm..
>>
>>
>>
>>     Gyan> How does this draft compare to the WG LC draft for flood
>> reduction.  Would they be two eventual standard options in the operators
>> toolbox  or competing features for optimized flood reduction. Would having
>> two flood reduction features standardized versus one default IGP flood
>> reduction feature be confusing for operators.  Just as it was confusing to
>> me.
>>
>>
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-dynamic-flooding%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446441864&sdata=RirosOO%2BSH8U3Fyb9Ejxjv%2B%2BeeMwW8%2FHpOLkZGO8FN4%3D&reserved=0>
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Gyan
>>
>>
>>
>>
>>
>> On Tue, May 19, 2020 at 11:52 PM Huaimo Chen <huaimo.chen@futurewei.com>
>> wrote:
>>
>> Hi Gyan,
>>
>>
>>
>>     Thank you very much for your questions and support.
>>
>>
>>
>>     This Flooding Topology Computation algorithm can be used in the
>> Dynamic Flooding on Dense Graphs to compute the flooding topologies for
>> the data center clos dense meshed topologies with many ECMP paths. It can
>> be used by the area leader in the centralized mode to compute the flooding
>> topology.
>>
>>
>>
>> Best Regards,
>>
>> Huaimo
>> ------------------------------
>>
>> *From:* Lsr <lsr-bounces@ietf.org> on behalf of Gyan Mishra <
>> hayabusagsm@gmail.com>
>> *Sent:* Tuesday, May 19, 2020 2:39 AM
>> *To:* Yanhe Fan <yfan@casa-systems.com>
>> *Cc:* lsr@ietf.org <lsr@ietf.org>; Acee Lindem (acee) <acee=
>> 40cisco.com@dmarc.ietf.org>
>> *Subject:* Re: [Lsr] Flooding Topology Computation Algorithm -
>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>
>>
>>
>>
>>
>> I support WG adoption and have a few questions related to the draft.
>>
>>
>>
>> Does this flooding algorithm use the dynamic flooding algorithm used in
>> data center clos dense meshed topologies with many ECMP paths where the
>> flood is decoupled from the physical topology.  In the dynamic flooding
>> algorithm mentioned in centralized mode the flooding is computed by the
>> area leader and distributed to all nodes.  In distributed mode each mode
>> the area leader determines the algorithm and then each node computes the
>> flooding topology based on the algorithm.
>>
>>
>>
>> This dynamic algorithm for optimized flood reduction would reduce the
>> amount of redundant flooding in highly densely meshed ospf or Isis
>> topologies.  So this optimization of flooding would improving overall link
>> state routing protocol convergence.
>>
>>
>>
>> Gyan
>>
>>
>>
>> On Mon, May 18, 2020 at 3:37 PM Yanhe Fan <yfan@casa-systems.com> wrote:
>>
>> Support it as a co-author.
>>
>>
>>
>> Thanks,
>>
>> Yanhe
>>
>>
>>
>> *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of *Acee Lindem (acee)
>> *Sent:* Friday, May 15, 2020 3:40 PM
>> *To:* lsr@ietf.org
>> *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%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446441864&sdata=fqmSXecEZOQbkD0lpbQ8BfAjXZvOZ8bzCWeEsfQojw4%3D&reserved=0>
>>
>>
>>
>> Thanks,
>> Acee
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446451864&sdata=xg2AvQQfqPS228FUYFhK1ueJJeUuuMZsI3yTdsVkji8%3D&reserved=0>
>>
>> --
>>
>> *Error! Filename not specified.*
>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446451864&sdata=h%2BrHjI5NY37uHQIjPKYv5GW6J6chceH6U3dbj3xwb7A%3D&reserved=0>
>>
>> *Gyan
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%250D%250A%2BColumbia%2BPike%2B%250D%250A%2BSilver%250D%250A%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446461859&sdata=b%2FrOXTZ8ayq5rzEPxpOlLuMfEvsw3FPbOVkqQUcnieQ%3D&reserved=0>Mishra*
>>
>>
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%250D%250A%2BColumbia%2BPike%2B%250D%250A%2BSilver%250D%250A%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446471858&sdata=GLW4e%2BMcjf8oIZmuUXtgcfmzrB%2BBWqXsvDquWI492EU%3D&reserved=0>*Network
>> Solutions Architect *
>>
>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>>
>>
>>
>> *M 301 502-1347 13101 Columbia Pike
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446471858&sdata=psm7wBWSK%2BEtFkhnb9B3soi0S6%2FrAXm%2FEXMoo6dnGKM%3D&reserved=0>
>> *Silver Spring, MD
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446481860&sdata=p0ttOIduJDiC0qR91gpSHhFnYJ6uVzJUJdV5qfOCPlw%3D&reserved=0>
>>
>>
>>
>> --
>>
>> *Error! Filename not specified.*
>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446491855&sdata=ik1xhwQyDjOvNfMg%2BQMAIIiMPkWlUER3K5q99T43c%2Fo%3D&reserved=0>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>>
>>
>> *M 301 502-1347
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%250D%250A%2BColumbia%2BPike%2B%250D%250A%2BSilver%250D%250A%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446491855&sdata=2U%2B3C5vUgVYU0GgNHfX2GRpsPVMm43GWWqzxm%2BOdOKQ%3D&reserved=0>13101
>> Columbia Pike
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446501852&sdata=eCAT1E6b8XpInRH0rt3JhcsRLGIoq32a5UOw84kqLQw%3D&reserved=0>
>> *Silver Spring, MD
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446511843&sdata=e6tNSbiepHHR7EJywi46nnEh2sD7JNdlKBF%2Bj%2B2WV8w%3D&reserved=0>
>>
>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>>
>>
>>
>> --
>>
>> *Error! Filename not specified.*
>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446511843&sdata=mlfQG0sJIh5NUKLahCziTmtrCWqimi13RAze0SXZ2cE%3D&reserved=0>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>>
>>
>> *M 301 502-1347 13101 Columbia Pike
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446521838&sdata=9u8%2Fhg6zqPW4BNxxuyEQd%2Fky69FmzGY7bwz7uZW%2FC14%3D&reserved=0>
>> *Silver Spring, MD
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446521838&sdata=9u8%2Fhg6zqPW4BNxxuyEQd%2Fky69FmzGY7bwz7uZW%2FC14%3D&reserved=0>
>>
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446531830&sdata=j7qLXVJD4j8%2FviHXL9MOvkB3MB5k2jEh%2BnprB5sh%2FvA%3D&reserved=0>
>>
>>
>>
>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>>
>> --
>>
>> *Error! Filename not specified.*
>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446541830&sdata=sTN2HQO64Um1VqZkhLZMa8Mi7S8WykmI%2BsqVNa921uI%3D&reserved=0>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>>
>>
>> *M 301 502-1347 13101 Columbia Pike
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446541830&sdata=kvKt%2FhIAtw0TihRjOw2QUQwsciGPZsEvA7Ajyd8nu0Y%3D&reserved=0>
>> *Silver Spring, MD
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446551824&sdata=w5mciZkFOfsgol2MPiv%2BtS3bfa7xI5KZj7WHYnxBFYM%3D&reserved=0>
>>
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446551824&sdata=w5mciZkFOfsgol2MPiv%2BtS3bfa7xI5KZj7WHYnxBFYM%3D&reserved=0>
>>
>>
>>
>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>>
>> --
>>
>> [image: Image removed by sender.]
>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446561816&sdata=faawTrV7ADwTXxvf%2BKE9WX64z1r5ro%2B7bmfhRMbW2Xg%3D&reserved=0>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>>
>>
>> *M 301 502-1347 13101 Columbia Pike
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446571816&sdata=dvcFR%2BGQMsm6kW0RSiWOhNdIFc8ntpHrhdAFFYqWi%2Fc%3D&reserved=0>
>> *Silver Spring, MD
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446571816&sdata=dvcFR%2BGQMsm6kW0RSiWOhNdIFc8ntpHrhdAFFYqWi%2Fc%3D&reserved=0>
>>
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446581809&sdata=uYQI13rtEKidJMaMnowsjiSAqbN3Ygeu4X2eQL7LCts%3D&reserved=0>
>>
>>
>>
>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>>
>> --
>>
>>
>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc9f9e8ddb76b406057d208d7fdf5cb4e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637257104446581809&sdata=D7sb4GOCEOeHEvKNjVxo0Sy004BHtfqiE4k65sSuxiY%3D&reserved=0>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-1347 13101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>> *Silver Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD