Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

["Acee Lindem (acee)" <[e-mail]>]

On 5/23/21, 9:12 PM, "Christian Hopps" <[e-mail]> wrote:


    "Acee Lindem (acee)" <acee=[e-mail]> 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.

300,000,000 meters per second / 1,000,000 microseconds per second = 300 meters per microsecond 

So, I don't think this is wrong. Also there is the standard definition of light microsecond - https://www.convert-me.com/en/convert/length/lightmicrosecond.html?u=lightmicrosecond&v=1


Thanks
Acee

    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 <[e-mail]> on behalf of Tony Li
    > <[e-mail]>
    > Date: Sunday, May 23, 2021 at 4:56 PM
    > To: Greg Mirsky <[e-mail]>
    > Cc: Shraddha Hegde <[e-mail]>, "[e-mail]"
    > <[e-mail]>, "[e-mail]" <[e-mail]>,
    > "[e-mail]"
    > <[e-mail]>, Acee Lindem
    > <[e-mail]>
    > 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 <[e-mail]>
    >     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=
    >     [e-mail]> wrote:
    >
    >         Hi Pengshaofu,
    >
    >
    >
    >         Pls see inline..
    >
    >
    >
    >
    >
    >                           Juniper Business Use Only
    >
    >         From: [e-mail] <[e-mail]>
    >         Sent: Thursday, May 20, 2021 7:26 AM
    >         To: Shraddha Hegde <[e-mail]>
    >         Cc: acee=[e-mail]; [e-mail];
    >         [e-mail]
    >         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=[e-mail];[e-mail];
    >         [e-mail];
    >
    >         日期：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: [e-mail] <[e-mail]>
    >         Sent: Monday, May 17, 2021 12:49 PM
    >         To: Shraddha Hegde <[e-mail]>
    >         Cc: acee=[e-mail]; [e-mail];
    >         [e-mail]
    >         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=[e-mail];[e-mail];
    >         [e-mail];
    >
    >         日期：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: [e-mail] <[e-mail]>
    >         Sent: Monday, May 17, 2021 7:40 AM
    >         To: Shraddha Hegde <[e-mail]>
    >         Cc: acee=[e-mail]; [e-mail];
    >         [e-mail]
    >         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=[e-mail];[e-mail];
    >         [e-mail];
    >
    >         日期：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: [e-mail] <[e-mail]>
    >         Sent: Thursday, May 13, 2021 1:05 PM
    >         To: [e-mail]
    >         Cc: acee=[e-mail]; [e-mail];
    >         [e-mail]
    >         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)
    >
    >         收件人：[e-mail];
    >
    >         抄送人：[e-mail];
    >
    >         日期：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
    >         [e-mail]
    >         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
    >         [e-mail]
    >         https://www.ietf.org/mailman/listinfo/lsr
    >
    >
    >
    >
    >
    > _______________________________________________
    > Lsr mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/lsr