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:12 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 A9AD33A0DEB; Sun, 23 May 2021 18:12:17 -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=unavailable 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 hZsCtdEbRIrS; Sun, 23 May 2021 18:12:11 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5B43A0DED; Sun, 23 May 2021 18:12:11 -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 50D9980E04; Mon, 24 May 2021 01:12:10 +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>
User-agent: mu4e 1.5.13; emacs 27.2
From: Christian Hopps <chopps@chopps.org>
To: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Cc: Tony Li <tony.li@tony.li>, 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>, lsr@ietf.org
Date: Sun, 23 May 2021 21:04:29 -0400
In-reply-to: <D363EE45-B866-43EE-B7AD-68B5D70E17E1@cisco.com>
Message-ID: <m2eedx9bpy.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/WG-tQF7YrZbJKCWpDgtYnRtvvfg>
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:12:18 -0000

"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.

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