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

[Shraddha Hegde]

Greg and others,

The measurement mechanisms and advertisements in ISIS support micro-second 
granularity (RFC 8570).
The current draft is defining constraints on these advertised link delay.
The thread below seems to be converging towards micro-second granularity but 
even if we needed nano second granularity, it would not be in the scope of this 
document. We will first have to standardize measurement and advertisement of 
link delay in  nano second granularity.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Christian Hopps 
Sent: Monday, May 24, 2021 7:03 AM
To: Christian Hopps 
Cc: Acee Lindem (acee) ; Greg Mirsky 
; peng.sha...@zte.com.cn; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org; Shraddha Hegde 
; Tony Li ; lsr@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


Christian Hopps  writes:

> [[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps 
>  (trust ultimate) created at 
> 2021-05-23T21:12:09-0400 using RSA]]
>
> "Acee Lindem (acee)"  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  on behalf of Tony Li 
>> 
>> Date: Sunday, May 23, 2021 at 4:56 PM
>> To: Greg Mirsky 
>> Cc: Shraddha Hegde , "peng.sha...@zte.com.cn"
>> , "lsr@ietf.org" , 
>> "draft-hegde-lsr-flex-algo-bw-...@ietf.org"
>> , Acee Lindem 
>> 
>> 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 
>> 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 > 40juniper@dmarc.ietf.org> wrote:
>>
>> Hi Pengshaofu,
>>
>>
>>
>> Pls see inline..
>>
>>
>>
>>
>>
>>   Juniper Business Use Only
>>
>> From: peng.sha...@zte.com.cn 
>> Sent: Thursday, May 20, 2021 7:26 AM
>> To: Shraddha Hegde 
>> 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,
>>
>>  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 ?
>>
>>  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

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

[Christian Hopps]

Christian Hopps  writes:


[[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps 
 (trust ultimate) created at 2021-05-23T21:12:09-0400 using 
RSA]]

"Acee Lindem (acee)"  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  on behalf of Tony Li

Date: Sunday, May 23, 2021 at 4:56 PM
To: Greg Mirsky 
Cc: Shraddha Hegde , "peng.sha...@zte.com.cn"
, "lsr@ietf.org" ,
"draft-hegde-lsr-flex-algo-bw-...@ietf.org"
, Acee Lindem

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 
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  wrote:

Hi Pengshaofu,



Pls see inline..





  Juniper Business Use Only

From: peng.sha...@zte.com.cn 
Sent: Thursday, May 20, 2021 7:26 AM
To: Shraddha Hegde 
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,

 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 ?

 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 
Sent: Monday, May 17, 2021 12:49 PM
To: Shraddha Hegde 
Cc: acee=40cisco@dmarc.ietf.org; lsr@ietf.org;
draft-hegde-lsr-fle

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

[Anoop Ghanwani]

Acee is talking propagation delay.
Chris is talking transmission delay.
Link delay is the sum of propagation and transmission delay.  (Perhaps that
clarification should be added to the draft?)
But most ASICs have a minimum delay just to get the packet through the
ASIC.  The smallest numbers I have seen are around 200 nsec, and they are
rare.  This must be added to the transmission delay.

Cables can be quite short within a data center.  See slide 8:
https://www.ieee802.org/3/400GSG/public/13_11/booth_400_01a_1113.pdf
But I don't think this technology is too interesting for use inside a data
center, and even if it was rounding such links to 1 usec would probably be
OK.

As such, to me the 1 usec granularity looks OK.

On Sun, May 23, 2021 at 6:12 PM Christian Hopps  wrote:

>
> "Acee Lindem (acee)"  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  on behalf of Tony Li
> > 
> > Date: Sunday, May 23, 2021 at 4:56 PM
> > To: Greg Mirsky 
> > Cc: Shraddha Hegde , "peng.sha...@zte.com.cn"
> > , "lsr@ietf.org" ,
> > "draft-hegde-lsr-flex-algo-bw-...@ietf.org"
> > , Acee Lindem
> > 
> > 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 
> > 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  > 40juniper@dmarc.ietf.org> wrote:
> >
> > Hi Pengshaofu,
> >
> >
> >
> > Pls see inline..
> >
> >
> >
> >
> >
> >   Juniper Business Use Only
> >
> > From: peng.sha...@zte.com.cn 
> > Sent: Thursday, May 20, 2021 7:26 AM
> > To: Shraddha Hegde 
> > 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,
> >
> >  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 ?
> >
> >  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,
> >
> >
> >
>

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

[Christian Hopps]

"Acee Lindem (acee)"  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  on behalf of Tony Li

Date: Sunday, May 23, 2021 at 4:56 PM
To: Greg Mirsky 
Cc: Shraddha Hegde , "peng.sha...@zte.com.cn"
, "lsr@ietf.org" ,
"draft-hegde-lsr-flex-algo-bw-...@ietf.org"
, Acee Lindem

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 
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  wrote:

Hi Pengshaofu,



Pls see inline..





  Juniper Business Use Only

From: peng.sha...@zte.com.cn 
Sent: Thursday, May 20, 2021 7:26 AM
To: Shraddha Hegde 
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,

 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 ?

 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 
Sent: Monday, May 17, 2021 12:49 PM
To: Shraddha Hegde 
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

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)]

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?

Thanks,
Acee

From: Tony Li  on behalf of Tony Li 
Date: Sunday, May 23, 2021 at 4:56 PM
To: Greg Mirsky 
Cc: Shraddha Hegde , "peng.sha...@zte.com.cn" 
, "lsr@ietf.org" , 
"draft-hegde-lsr-flex-algo-bw-...@ietf.org" 
, Acee Lindem 
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 
mailto: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 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Hi Pengshaofu,

Pls see inline..


Juniper Business Use Only
From: peng.sha...@zte.com.cn 
mailto:peng.sha...@zte.com.cn>>
Sent: Thursday, May 20, 2021 7:26 AM
To: Shraddha Hegde mailto: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,
 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 ?
 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 
mailto:peng.sha...@zte.com.cn>>
Sent: Monday, May 17, 2021 12:49 PM
To: Shraddha Hegde mailto: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 

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

[Tony Li]

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  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 
> mailto:40juniper@dmarc.ietf.org>> 
> wrote:
> Hi Pengshaofu,
> 
>  
> 
> Pls see inline..
> 
>  
> 
>  
> 
> Juniper Business Use Only
> From: peng.sha...@zte.com.cn  
> mailto:peng.sha...@zte.com.cn>> 
> Sent: Thursday, May 20, 2021 7:26 AM
> To: Shraddha Hegde mailto: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,
> 
>  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 ?
> 
>  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  
> mailto:peng.sha...@zte.com.cn>> 
> Sent: Monday, May 17, 2021 12:49 PM
> To: Shraddha Hegde mailto: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 
> cumula

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

[Greg Mirsky]

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  wrote:

> Hi Pengshaofu,
>
>
>
> Pls see inline..
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* peng.sha...@zte.com.cn 
> *Sent:* Thursday, May 20, 2021 7:26 AM
> *To:* Shraddha Hegde 
> *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,
>
>  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 ?
>
>  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 
> *Sent:* Monday, May 17, 2021 12:49 PM
> *To:* Shraddha Hegde 
> *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 
> *Sent:* Monday, May 17, 2021 7:40 AM
> *To:* Shraddha Hegde 
> *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 "Flexib

Re: [Lsr] Erik Kline's Discuss on draft-ietf-lsr-isis-srv6-extensions-14: (with DISCUSS)

[Peter Psenak]

Hi Ben,

please see inline:

On 22/05/2021 00:57, Benjamin Kaduk wrote:

On Thu, May 20, 2021 at 10:59:23AM -0400, Joel Halpern Direct wrote:

None of the cases you described are used for routing.

And advertising information for which we do not know the use seems a bad
idea.


At least, not something that we should feel strongly obligated to put in a
Standards-Track specification.


The abstraction that lets us talk about func bits and arg bits is nice.


It is certainly convenient, and probably even worth having written down.


   But in fact, the operational structures do not depend upon that.


I am inclined to agree.  Pulling in a quote from upthread: "the information
comes from the router, that is where the SRv6 SID is allocated."  The SID
being *allocated by* the router that "owns" the IPv6 block is key to how I
came to reconcile myself with RFC 8986.  The router can allocate and put
structure in its own allocations if it wants to, so long as the protocol
itself doesn't require it, and things mostly remain fine.

It's also mostly fine if the router (or other entity) allocating the SID
values and putting structure on them wants to go and tell somebody else
what it did and how.


above is exactly what the SID Structure TLV was defined for.



However, if we go and define in a standards-track document the way to tell
somebody else how it was done, and the mechanism to do so enforces a
particular structure on the allocation, that becomes problematic for me.


I don't see where the ISIS SRv6 draft enforces any particular structure 
on the SID allocation.


All that the draft does is that it provides a mechanism to advertise the 
SID structure, if the SID was allocated using the structure defined in 
RFC 8986. On top of that, the SID Structure TLV is optional, please see 
the first sentence of section 9.


So there is absolutely no enforcement in this draft in terms of the 
structure of the SID allocation.


  > I think a lot of my unease with this mechanism would go away if it 
was not

described or implied that this is the only way to have structure to a SID
and the option was open for the router to allocate its SIDs (and
communicate about them) in some other way.


the draft does not say anything about this being the only way to have 
structure associated with the SID. It defines the TLV for the only 
structure that RFC 8986 defined. That's all.


thanks,
Peter





(That said, I still think it would be better done in a different document
than this one.)

-Ben


I really think removing section 9 would improve the document and operations.

Yours,
Joel

On 5/20/2021 10:10 AM, Peter Psenak wrote:

Joel,

On 20/05/2021 15:59, Joel M. Halpern wrote:

I have been watching this debate, and I am left with the impression that
the information being defined in section 9 of this draft is simply not
useful for routing.   It confuses operational information with routing
information.  Given taht the information has to come from somewhere
outside the router anyway,


the information comes from the router, that is where the SRv6 SID is
allocated.

Similar to a prefix that is configured on the router and is advertised
together with some additional attributes (e.g. tag). These attributes
may or may not be used for routing.

thanks,
Peter




iand that it is not going to be consumed by
the routers who receive the advertisements, why is it here?

Yours,
Joel

On 5/20/2021 7:49 AM, Peter Psenak wrote:

Hi Erik,

thanks for your comment, please see inline:

On 19/05/2021 03:58, Erik Kline via Datatracker wrote:

Erik Kline has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
DISCUSS:
--

[ section 9 ]

* I share the concerns of several of the others here about SRv6 SIDs
being
     claimed to be IPv6 addresses but kinda not really being IPv6
addresses
     if their internal structure is exposed outside of the given SR
router.



SRv6 SIDs are indeed IPv6 addresses. RFC8986 introduced the SRv6 SID
structure. It also goes into allocation of SIDs where it describes the
carving out of the Block for SRv6 SIDs in the domain, followed by the
allocation of SRv6 Locators to the nodes in the domain. Then the node
allocates the function part when instantiating the SID - and all of this
is signaled via control plane protocols. This is all exposed and know to
the operator who determines the addressing scheme.