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>et>, "peng.shaofu@zte.com.cn"
>> <peng.shaofu@zte.com.cn>cn>, "lsr@ietf.org" <lsr@ietf.org>rg>,
>> "draft-hegde-lsr-flex-algo-bw-con@ietf.org"
>> <draft-hegde-lsr-flex-algo-bw-con@ietf.org>rg>, 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