Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Christian Hopps <chopps@chopps.org> Mon, 24 May 2021 01:36 UTC
Return-Path: <chopps@chopps.org>
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 E24BC3A0FD0; Sun, 23 May 2021 18:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 3_mCjlAvs9uZ; Sun, 23 May 2021 18:36:00 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3AD3A0FCD; Sun, 23 May 2021 18:36:00 -0700 (PDT)
Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 4D7F280E04; Mon, 24 May 2021 01:35:59 +0000 (UTC)
References: <202105200955495710804@zte.com.cn> <CY4PR05MB357659CAE530C61E253AC958D52A9@CY4PR05MB3576.namprd05.prod.outlook.com> <CA+RyBmVRqpSxxFoDKEtdv=zSu6gXbdyDFbpuM7ek93La1n5Hew@mail.gmail.com> <E63007E1-4C5E-479B-A4EE-7EADF93B058A@tony.li> <D363EE45-B866-43EE-B7AD-68B5D70E17E1@cisco.com> <m2eedx9bpy.fsf@ja.int.chopps.org>
User-agent: mu4e 1.5.13; emacs 27.2
From: Christian Hopps <chopps@chopps.org>
To: Christian Hopps <chopps@chopps.org>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Greg Mirsky <gregimirsky@gmail.com>, "peng.shaofu@zte.com.cn" <peng.shaofu@zte.com.cn>, "draft-hegde-lsr-flex-algo-bw-con@ietf.org" <draft-hegde-lsr-flex-algo-bw-con@ietf.org>, Shraddha Hegde <shraddha@juniper.net>, Tony Li <tony.li@tony.li>, lsr@ietf.org
Date: Sun, 23 May 2021 21:33:26 -0400
In-reply-to: <m2eedx9bpy.fsf@ja.int.chopps.org>
Message-ID: <m2bl90ap6p.fsf@ja.int.chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/UzjTMTp8vFWbwfXa_Y8kD-FsjEA>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
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: Mon, 24 May 2021 01:36:06 -0000
Christian Hopps <chopps@chopps.org> writes: > [[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps <chopps@gmail.com> (trust ultimate) created at 2021-05-23T21:12:09-0400 using RSA]] > > "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org> writes: > >> Hi Greg, >> >> >> >> Additionally, in a vacuum light will only travel 300 meters in a >> microsecond. So, in a nanosecond, that is less than a foot. What >> transmission technology and application do you anticipate that will >> require this this precision? > > Off by a few magnitude; light travels just shy of 300,000,000 meters per second. Or not.. getting my kilometers, meters, us and ns mixed up here. :) Your right on the transmission delay, sorry. Thanks, Chris. > Consider that 100Gbps links transmit 100 bits every nanosecond. So about 5 nanoseconds to send a minimum sized ethernet frame (sans the pre/postamble). > > Thanks, > Chris. > > >> >> >> >> Thanks, >> >> Acee >> >> >> >> From: Tony Li <tony1athome@gmail.com> on behalf of Tony Li >> <tony.li@tony.li> >> Date: Sunday, May 23, 2021 at 4:56 PM >> To: Greg Mirsky <gregimirsky@gmail.com> >> Cc: Shraddha Hegde <shraddha@juniper.net>, "peng.shaofu@zte.com.cn" >> <peng.shaofu@zte.com.cn>, "lsr@ietf.org" <lsr@ietf.org>, >> "draft-hegde-lsr-flex-algo-bw-con@ietf.org" >> <draft-hegde-lsr-flex-algo-bw-con@ietf.org>, Acee Lindem >> <acee@cisco.com> >> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: >> Bandwidth, Delay, Metrics and Constraints" - >> draft-hegde-lsr-flex-algo-bw-con-02 >> >> >> >> >> >> Hi Greg, >> >> >> >> That’s a very fair question and not one that has been discussed. >> >> >> >> Do we have that kind of accuracy from any of our measurement tools? >> Is that even on the horizon? I haven’t seen that… >> >> >> >> If it is time for nanosecond level measurement, then is it time to >> shift to floating point to give us more range? >> >> >> >> Tony >> >> >> >> On May 23, 2021, at 1:04 PM, Greg Mirsky <gregimirsky@gmail.com> >> wrote: >> >> >> >> Hi Shraddha, Authors, et al., >> >> I apologize if my question has already been discussed. The unit >> for the maximum link delay in the draft is a microsecond. There >> is a group of services that require a highly accurate bounded >> delay. Have you considered using a nanosecond as the unit for the >> link delay? >> >> >> >> Regards, >> >> Greg >> >> >> >> On Wed, May 19, 2021 at 9:17 PM Shraddha Hegde <shraddha= >> 40juniper.net@dmarc.ietf.org> wrote: >> >> Hi Pengshaofu, >> >> >> >> Pls see inline.. >> >> >> >> >> >> Juniper Business Use Only >> >> From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn> >> Sent: Thursday, May 20, 2021 7:26 AM >> To: Shraddha Hegde <shraddha@juniper.net> >> Cc: acee=40cisco.com@dmarc.ietf.org; lsr@ietf.org; >> draft-hegde-lsr-flex-algo-bw-con@ietf.org >> Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible >> Algorithms: Bandwidth, Delay, Metrics and Constraints" - >> draft-hegde-lsr-flex-algo-bw-con-02 >> >> >> >> [External Email. Be cautious of content] >> >> >> >> >> >> Hi Shraddha, >> >> >> >> Thanks. Actually, I don't really want to define other metric >> types. >> >> Let's go back to the bandwidth-metric related to bandwidth >> capability. My worry is that bandwidth-metric (whether it is >> automatically calculated or manually configured) is not >> cumulative in nature, >> >> <Shraddha> Yes that is correct. >> >> which is different from IGP default metric/TE metric/delay >> metric, >> >> >> >> so that SPF based on bandwidth-metric may get an unexpected >> path (see the example of the original mail). >> >> Can more text be added in the draft to describe why this can >> work ? >> >> <Shraddha> Knowing that metric derived inversely from the >> link bandwidth is not additive in nature, should set the >> expectation right. I can add some text in this regard. >> >> >> >> Regards, >> >> PSF >> >> >> >> >> >> 原始邮件 >> >> 发件人：ShraddhaHegde >> >> 收件人：彭少富10053815; >> >> 抄送人：acee=40cisco.com@dmarc.ietf.org;lsr@ietf.org; >> draft-hegde-lsr-flex-algo-bw-con@ietf.org; >> >> 日期：2021年05月18日 13:01 >> >> 主题：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible >> Algorithms: Bandwidth, Delay, Metrics and Constraints" - >> draft-hegde-lsr-flex-algo-bw-con-02 >> >> Hi Pengshaofu, >> >> >> >> If an operator wants to configure any other metric type draft >> provides a mechanism with generic metric. >> >> Generic metric allows any standard or user-defined type >> metric to be configured. >> >> The draft allows for any computing application such as >> Flex-algo, CSPF etc to make use of the >> >> Metric. The intention of the draft is that for a particular >> computation same metric-type is used >> >> throughout the network. If that is not clear, I’ll add some >> text in the draft. >> >> >> >> Using a combination of different metrics for a single >> computation would need significant change to SPF algorithm >> and it is not in the scope of the draft "Flexible Algorithms: >> Bandwidth, Delay, Metrics and Constraints". >> >> >> >> Hope that clarifies. >> >> >> >> Rgds >> >> Shraddha >> >> >> >> >> >> Juniper Business Use Only >> >> From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn> >> Sent: Monday, May 17, 2021 12:49 PM >> To: Shraddha Hegde <shraddha@juniper.net> >> Cc: acee=40cisco.com@dmarc.ietf.org; lsr@ietf.org; >> draft-hegde-lsr-flex-algo-bw-con@ietf.org >> Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible >> Algorithms: Bandwidth, Delay, Metrics and Constraints" - >> draft-hegde-lsr-flex-algo-bw-con-02 >> >> >> >> [External Email. Be cautious of content] >> >> >> >> >> >> Hi Shraddha, >> >> >> >> The two methods of automatic generation of BW-metric >> introduced in the draft are also likely to be the method of >> manual configuration of BW-metric by operators. Operators >> can certainly manually configure any BW-metric he wants to >> configure. >> >> However, the manually configured BW-metric cannot deviate >> from the actual bandwidth capacity of the link, otherwise it >> could be any other names such as BX-metric. >> >> For manual assignment, the problem may still exist We can >> find an example that the accumulated bandwidth-metric on the >> path may offset the manually increased bandwidth-metric of >> links on the path. >> >> Combination of bandwidth attribute of link and other metric >> that is cumulative may be another co-exist way to completely >> address this issue. >> >> >> >> Regards, >> >> PSF >> >> >> >> >> >> >> >> >> >> 原始邮件 >> >> 发件人：ShraddhaHegde >> >> 收件人：彭少富10053815; >> >> 抄送人：acee=40cisco.com@dmarc.ietf.org;lsr@ietf.org; >> draft-hegde-lsr-flex-algo-bw-con@ietf.org; >> >> 日期：2021年05月17日 12:15 >> >> 主题：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible >> Algorithms: Bandwidth, Delay, Metrics and Constraints" - >> draft-hegde-lsr-flex-algo-bw-con-02 >> >> Hi Pengshaofu, >> >> >> >> I was suggesting to manually assign bandwidth metric which >> will override the automatic metric calculation >> >> as described in the draft section 5. Physically adding more >> fiber/capacity is not a feasible solution. >> >> >> >> Rgds >> >> Shraddha >> >> >> >> >> >> Juniper Business Use Only >> >> From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn> >> Sent: Monday, May 17, 2021 7:40 AM >> To: Shraddha Hegde <shraddha@juniper.net> >> Cc: acee=40cisco.com@dmarc.ietf.org; lsr@ietf.org; >> draft-hegde-lsr-flex-algo-bw-con@ietf.org >> Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible >> Algorithms: Bandwidth, Delay, Metrics and Constraints" - >> draft-hegde-lsr-flex-algo-bw-con-02 >> >> >> >> [External Email. Be cautious of content] >> >> >> >> >> >> Hi Shraddha, >> >> >> >> Thanks for your rely. >> >> So it seems that the scheme may lead to the selection of >> links with less bandwidth. To address this point, the method >> as you described to assign more bandwidth to high bandwidth >> links seems not always possible, e.g, adding more fiber ? >> >> Can this point can be addressed by combination of bandwidth >> attribute of link and other metric that is cumulative ? IMO, >> bandwidth is not cumulative. >> >> >> >> Regards >> >> PSF >> >> >> >> 原始邮件 >> >> 发件人：ShraddhaHegde >> >> 收件人：彭少富10053815; >> >> 抄送人：acee=40cisco.com@dmarc.ietf.org;lsr@ietf.org; >> draft-hegde-lsr-flex-algo-bw-con@ietf.org; >> >> 日期：2021年05月13日 21:01 >> >> 主题：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible >> Algorithms: Bandwidth, Delay, Metrics and Constraints" - >> draft-hegde-lsr-flex-algo-bw-con-02 >> >> Hi Peng shaofu, >> >> >> >> As per the draft, if automatic metric calculation with >> reference bandwidth method is used to calculate the metric >> >> Then as per your example s->D path will be chosen since >> metric is 10. >> >> Lets say operator wants to choose S->X1->X2-àX10->D path then >> operator can manually assign higher bandwidth >> >> Metric on S->D link which will ensure S->D path is not the >> least cost path. >> >> >> >> Rgds >> >> Shraddha >> >> >> >> >> >> Juniper Business Use Only >> >> From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn> >> Sent: Thursday, May 13, 2021 1:05 PM >> To: peng.shaofu@zte.com.cn >> Cc: acee=40cisco.com@dmarc.ietf.org; lsr@ietf.org; >> draft-hegde-lsr-flex-algo-bw-con@ietf.org >> Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible >> Algorithms: Bandwidth, Delay, Metrics and Constraints" - >> draft-hegde-lsr-flex-algo-bw-con-02 >> >> >> >> [External Email. Be cautious of content] >> >> >> >> >> >> Sorry for spelling mistakens in the previous email. >> >> updated text: >> >> >> >> >> >> Hi WG, >> >> >> >> I have a little doubt about the scheme described in this >> document. >> >> See the following example: >> >> >> >> S ---- X1 ----- X2 ---- ... ... ----- X10 ----- D >> >> \----------------------------------------------/ >> >> >> >> Suppose the links in S---X1---X2...---D have the same >> bandwidth 10G, and the link S-D has bandwidth 1G. >> >> Suppose that we select "reference bandwidth = 100G", then, >> >> each link in S---X1---X2...---D will have the same >> bandwidth-metric 10 (i.e., 100/10) >> >> link S-D will have a bandwidth-metric 100 (i.e., 100/1) >> >> >> >> So flex-algo path from S to D based on bandwidth-metric will >> be S-D, not S---X1---X2...---D, because the later has a large >> cumulative bandwitdh-metric (i.e., 11*10). >> >> But our expect path should not be S-D, but >> S---X1---X2...---D, as it has large bandwidth. >> >> Do I misunderstand anything ? >> >> >> >> Regards, >> >> PSF >> >> >> >> >> >> >> >> >> >> 发件人：AceeLindem(acee) >> >> 收件人：lsr@ietf.org; >> >> 抄送人：draft-hegde-lsr-flex-algo-bw-con@ietf.org; >> >> 日期：2021年05月13日 05:49 >> >> 主题：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: >> Bandwidth, Delay, Metrics and Constraints" - >> draft-hegde-lsr-flex-algo-bw-con-02 >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> >> Esteemed Members of the LSR WG, >> >> >> >> This begins a 2 week WG adoption call for the following >> draft: >> >> >> >> https://datatracker.ietf.org/doc/ >> draft-hegde-lsr-flex-algo-bw-con/ >> >> >> >> Please indicate your support or objection by May 27^th, 2021. >> >> >> >> Authors, please respond to the list indicating whether you >> are aware of any IPR that applies to this draft. >> >> >> >> Thanks, >> >> Chris and Acee >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> >> >> >> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > [[End of PGP Signed Part]] > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
- [Lsr] LSR WG Adoption Poll for "Flexible Algorith… Acee Lindem (acee)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Jeff Tantsura
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Gyan Mishra
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… peng.shaofu
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… peng.shaofu
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Peter Psenak
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Ron Bonica
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Lizhenbin
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Dongjie (Jimmy)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Peter Psenak
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Dongjie (Jimmy)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… peng.shaofu
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… peng.shaofu
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Dongjie (Jimmy)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Dongjie (Jimmy)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… peng.shaofu
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Acee Lindem (acee)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… peng.shaofu
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… peng.shaofu
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Dongjie (Jimmy)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Aijun Wang
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Acee Lindem (acee)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Aijun Wang
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Aijun Wang
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Gyan Mishra
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Aijun Wang
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Aijun Wang
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Aijun Wang
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Aijun Wang
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Greg Mirsky
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Acee Lindem (acee)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Christian Hopps
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Anoop Ghanwani
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Christian Hopps
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Acee Lindem (acee)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Anoop Ghanwani
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Anoop Ghanwani
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Anoop Ghanwani
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Acee Lindem (acee)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Ketan Talaulikar (ketant)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Peter Psenak
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Aijun Wang
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… gregory.mirsky
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Anoop Ghanwani
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… gregory.mirsky
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… gregory.mirsky
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… gregory.mirsky
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Anoop Ghanwani
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Acee Lindem (acee)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Ketan Talaulikar (ketant)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Aijun Wang
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Tony Li
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Peter Psenak
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Peter Psenak
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Acee Lindem (acee)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… bruno.decraene
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Ketan Talaulikar (ketant)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Ketan Talaulikar (ketant)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Ketan Talaulikar (ketant)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Peter Psenak
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… William Britto A J
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Rajesh M
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Acee Lindem (acee)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… tom petch
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Ketan Talaulikar (ketant)
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Shraddha Hegde
- Re: [Lsr] LSR WG Adoption Poll for "Flexible Algo… Ketan Talaulikar (ketant)