"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. 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
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
