On 5/23/21, 9:12 PM, "Christian Hopps" <cho...@chopps.org> wrote:
"Acee Lindem (acee)" <acee=40cisco....@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.
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 <tony1ath...@gmail.com> on behalf of Tony Li
> <tony...@tony.li>
> Date: Sunday, May 23, 2021 at 4:56 PM
> To: Greg Mirsky <gregimir...@gmail.com>
> Cc: Shraddha Hegde <shrad...@juniper.net>, "peng.sha...@zte.com.cn"
> <peng.sha...@zte.com.cn>, "lsr@ietf.org" <lsr@ietf.org>,
> "draft-hegde-lsr-flex-algo-bw-...@ietf.org"
> <draft-hegde-lsr-flex-algo-bw-...@ietf.org>, Acee Lindem
> <a...@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 <gregimir...@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....@dmarc.ietf.org> wrote:
>
> Hi Pengshaofu,
>
>
>
> Pls see inline..
>
>
>
>
>
> Juniper Business Use Only
>
> From: peng.sha...@zte.com.cn <peng.sha...@zte.com.cn>
> Sent: Thursday, May 20, 2021 7:26 AM
> To: Shraddha Hegde <shrad...@juniper.net>
> Cc: acee=40cisco....@dmarc.ietf.org; lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-...@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....@dmarc.ietf.org;lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-...@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.sha...@zte.com.cn <peng.sha...@zte.com.cn>
> Sent: Monday, May 17, 2021 12:49 PM
> To: Shraddha Hegde <shrad...@juniper.net>
> Cc: acee=40cisco....@dmarc.ietf.org; lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-...@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....@dmarc.ietf.org;lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-...@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.sha...@zte.com.cn <peng.sha...@zte.com.cn>
> Sent: Monday, May 17, 2021 7:40 AM
> To: Shraddha Hegde <shrad...@juniper.net>
> Cc: acee=40cisco....@dmarc.ietf.org; lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-...@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....@dmarc.ietf.org;lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-...@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.sha...@zte.com.cn <peng.sha...@zte.com.cn>
> Sent: Thursday, May 13, 2021 1:05 PM
> To: peng.sha...@zte.com.cn
> Cc: acee=40cisco....@dmarc.ietf.org; lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-...@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-...@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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
