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

Sarah Chen <sarahchen@arista.com> Fri, 22 May 2020 02:59 UTC

Return-Path: <sarahchen@arista.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160C63A0E06 for <lsr@ietfa.amsl.com>; Thu, 21 May 2020 19:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=arista.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuQysx1Z6v1R for <lsr@ietfa.amsl.com>; Thu, 21 May 2020 19:59:51 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5F33A0DFB for <lsr@ietf.org>; Thu, 21 May 2020 19:59:50 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id w7so8651379wre.13 for <lsr@ietf.org>; Thu, 21 May 2020 19:59:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e8JB7MQNyVrhxRjJN2/GIMAk6Cg4wu2bPcKDcGgoibE=; b=WE1k63hEhc+wj/eCIMu97zTQHyTqka/ylTfWlnq99+ksu/4QG4i3FBh/YahXjAQql+ Wi5V49VnFrpCmHunTsvbm3BomurkGCYcor83cb1QcBrZ9U0yZroWSyYi8OLrtauoUcb7 eVzUnTP6xo9Bmo1wddR5dgJImQOE5JWWeR6RdwzBadgMmq26P9qOpXLPPLmcqiHKYIsP +wwOj6lB0cKGOBve1dLrlS0hPSHRGrSWwb26ZtQDhP4zduvn4n+ivcATTnJeTs/Z1kK0 /CUBAGEQZ8KecfyJODV/XSaADr4YrYn4TklDnatcy4CdM1tkz6E9BqnRF3Fpfh9BnJf5 W/AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e8JB7MQNyVrhxRjJN2/GIMAk6Cg4wu2bPcKDcGgoibE=; b=SN9+CZyrYPZJp3TYIGwn/s/afsp46rL1TgRP5YL/B8zyWPfE5RxD9kjlHotiQkZqKN lR3076my1ABIGe44d7OgUObVgqCEeM2AKWjL95ND1jeMfh1zWWoZfAxT7iB9KmhJqYRv Nzg/0Z5EBfFNk9yTdTshAL67Ghf9ccpg5clVEkNm7RTt21m0syxq+1xaJkObwzu89WZ9 9iSCMbB3n5uh9mSAj79YzaHKmMQA2UhqiiGrENJ41Jk/zBgI5MQ95nT9uvreb9HMQhqh MUcMrxFFFw3ZjuNGLuRbRUdTIOij5pbzjeQw6BsegtofMzyBFiwXCUVdTLYS08mTG7cv b1VA==
X-Gm-Message-State: AOAM531F4eBdpSGaC3SiZIsJ7Zf0/UR3QKs2+aAvcNkNZzaj0o9NjvKt l+JwqvxGbJ6lyDkYUpHFu9qF0iOCXEhjopXOWfRyaOiSczY=
X-Google-Smtp-Source: ABdhPJzeqPAtq2mLNhdBax8medNYNwJFUEIXxCX56t8HenKNvSizBnQmSbHmN0S7wB+Ch3MbRTgqms56TrGfb9Gx0D4=
X-Received: by 2002:adf:f48b:: with SMTP id l11mr1331911wro.312.1590116389099; Thu, 21 May 2020 19:59:49 -0700 (PDT)
MIME-Version: 1.0
References: <63330FD6-EDE8-4938-AA85-948279C57E34@cisco.com> <DM6PR06MB509842BA0E42A4938ACB2B94EEB80@DM6PR06MB5098.namprd06.prod.outlook.com> <CABNhwV3jQ=C6ynJBsKhJW_b=hkq7CKPFG2ci0vXE_0jZH9KtXQ@mail.gmail.com> <MN2PR13MB3117C43CA052E4E29D7428CBF2B60@MN2PR13MB3117.namprd13.prod.outlook.com> <CABNhwV2Y3kemTdHYBamZwAB+m5DefxqTC0shPan2cGHd9TARTg@mail.gmail.com> <MN2PR13MB3117E84C778B11D71FAF8135F2B70@MN2PR13MB3117.namprd13.prod.outlook.com> <CABNhwV1W3EDJpqUjLGj3-E-8L1R=75oAgtHX==9qkfrvrZy2ZQ@mail.gmail.com> <MN2PR13MB3117A5E68B341A203266C64AF2B70@MN2PR13MB3117.namprd13.prod.outlook.com> <CABNhwV3e_qm=RmTQyQ+yCWN+pt_d1Aw8-W9gkRwH+_kAyphu8Q@mail.gmail.com> <424B17B1-D66D-4708-A819-855E972841AF@cisco.com> <CABNhwV2cDoNotaePw30eZa5wE61NC_vh8cFaZHh_nPqs1ibFsg@mail.gmail.com> <E093695B-78DE-4332-B4E7-87343077624E@cisco.com> <CABNhwV1cfOE+trZGM-s44xU0su5RUgL2c7ubRCdc3EFCWsdujw@mail.gmail.com> <CABNhwV0kA5vXxFbwZ__MjDNYsymEfKawMR1qqXoKVr24mOGATw@mail.gmail.com>
In-Reply-To: <CABNhwV0kA5vXxFbwZ__MjDNYsymEfKawMR1qqXoKVr24mOGATw@mail.gmail.com>
From: Sarah Chen <sarahchen@arista.com>
Date: Thu, 21 May 2020 19:59:37 -0700
Message-ID: <CADhmtX3dZwozCJ1Qgcqg6B-1=35xCQ_n6-+_XFfFFDOUMLjrmg@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, Huaimo Chen <huaimo.chen@futurewei.com>
Content-Type: multipart/alternative; boundary="000000000000863e2305a633d200"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1_WO1Hb65JUIT6BCnlPMGMdxOQ8>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2020 02:59:56 -0000

Hi, Gyan,

I presented
https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html in
the last IETF. You may find the slides below helpful in understanding the
algorithm:

https://datatracker.ietf.org/meeting/interim-2020-lsr-01/materials/slides-interim-2020-lsr-01-sessa-2-dynamic-flooding-algo-sarah.pdf

Thanks,
Sarah

On Thu, May 21, 2020 at 7:32 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> I see the diagrams Appendix A -  reviewing
>
> Thanks
>
> Gyan
>
> On Thu, May 21, 2020 at 10:13 PM Gyan Mishra <hayabusagsm@gmail.com>
> wrote:
>
>>
>> I think for both drafts it would be good to have a stick diagram at a
>> minimum.
>>
>> 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?
>>
>> That would help.
>>
>> https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08
>>
>> 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.
>>
>> 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
>>
>> https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html
>>
>> 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>om>, "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/
>>>
>>>
>>>
>>> You can see they both make use of the dynamic flooding infra in
>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>>>
>>>
>>>
>>> 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>om>, "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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327604003&sdata=TGrkecn6m9liviazX7qqPglGqYEWu5Ekg2FRIaDpBZ8%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/
>>>
>>>
>>>
>>> This later draft per section excerpt provides both centralized and
>>> distributed algorithm see below
>>>
>>>
>>>
>>> *6.4 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-05#section-6.4>.  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://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-05#section-6.5>.  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
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> 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>rg>; 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>rg>; 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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327604003&sdata=CPEu2451qkfD9440Ihj1bKPWl%2BzH%2BiuYUwuWpfzR%2B0Q%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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327604003&sdata=TGrkecn6m9liviazX7qqPglGqYEWu5Ekg2FRIaDpBZ8%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>rg>; 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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327614000&sdata=FkKUWXneiQIUtjkGB6RITfo0vAt2qhkwDWB%2BghP7%2FLg%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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327623992&sdata=tyEhpdkwdbAVJqAlvbfzNxb7n1qLGrrEZ%2FBjEKa9rVs%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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327633988&sdata=ii1nTDHCkuMU0AfaMkLjY6N2ww2STRdJBbhHozWSL9I%3D&reserved=0>
>>>
>>> *Gyan
>>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>Mishra*
>>>
>>>
>>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>*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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327653980&sdata=TYHrbd1wDXt4p2yDXi%2Fqm3XEmjK4V7zu3caXeNJFthU%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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327663981&sdata=5b0tVVJLdEO9%2FuAksAsc0BAqy%2F%2F%2BE7EBPjRlkKvvOH4%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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327673971&sdata=Bbk8qEHi1RU7J1x%2FNP11v8CYcnDLszZQiNRLmklSDOY%3D&reserved=0>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>>
>>>
>>> *M 301 502-1347
>>> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327683966&sdata=2sVGWVhM3Sbk84D2ZyaCYUGfp5wDLt8U8uLpgMJuwSU%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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327693961&sdata=OQccpoFntfT0LMaEVNaWmGhkqFbTKJLWu4PIlTuKFoA%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%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327693961&sdata=zKzhCcHJbUpzdvulN4y1N92e6KJKAEqHvdF5KDKJKH8%3D&reserved=0>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>>
>>>
>>> *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>
>>>
>>>
>>>
>>> --
>>>
>>> *Error! Filename not specified.* <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>>
>>>
>>> *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>
>>>
>>>
>>>
>>> --
>>>
>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>>
>>>
>>> *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
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>