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

[Ketan Talaulikar (ketant)]

Hi Shraddha,

My point is that Generic Metric is not a legacy advertisement and it is 
application specific. Therefore, the place to advertise it is within the ASLA 
Sub-TLV - this applies to both ISIS and OSPF.

The references in RFC8919 and RFC8920 are about legacy advertisements and do 
not apply in this discussion.

Thanks,
Ketan

From: Shraddha Hegde 
Sent: 31 May 2021 14:20
To: Ketan Talaulikar (ketant) ; Tony Li 
Cc: Acee Lindem (acee) ; 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

Hi Ketan,

Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Monday, May 31, 2021 1:14 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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,

When you refer to "a single TE application", it is not clear which one you are 
referring to : RSVP-TE or SR Policy?
 It could be either of them

I believe, for ISIS, you are referring to this specific section of RFC8919 : 
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-6.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdZHekgKS$>

There is no ambiguity here. This section is about use of "legacy" 
advertisement. The Generic Metric is a new TLV and hence cannot be considered 
as "legacy" by any interpretation of the word.
 For ISIS, I hope you agree that generic metric sub-TLV is allowed to 
get advertised under TLV 22.

Coming to OSPF, the considerations are similar. Additionally we also have to 
deal with different LSA types here.

Please refer to 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_Adc5YCVr4$>
 for the equivalent discussion for OSPF. This section is about "legacy" 
advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you 
were referring to was RSVP-TE, then there is also additional guidance provided 
here : 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.2.4__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdRkvFDI2$>


Please clarify where RFC8920 describes advertisement of application-specific 
attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.
 From what I understand, you agree that the generic metric sub-TLV 
should be allowed in TE Opaque LSA.
You have concerns only on it being allowed in Extended Link opaque LSA top 
level Extended Link TLV right?



Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org&g

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

[Shraddha Hegde]

Hi Ketan,

Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Monday, May 31, 2021 1:14 PM
To: Shraddha Hegde ; Tony Li 
Cc: Acee Lindem (acee) ; 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,

When you refer to "a single TE application", it is not clear which one you are 
referring to : RSVP-TE or SR Policy?
 It could be either of them

I believe, for ISIS, you are referring to this specific section of RFC8919 : 
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-6.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdZHekgKS$>

There is no ambiguity here. This section is about use of "legacy" 
advertisement. The Generic Metric is a new TLV and hence cannot be considered 
as "legacy" by any interpretation of the word.
 For ISIS, I hope you agree that generic metric sub-TLV is allowed to 
get advertised under TLV 22.

Coming to OSPF, the considerations are similar. Additionally we also have to 
deal with different LSA types here.

Please refer to 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_Adc5YCVr4$>
 for the equivalent discussion for OSPF. This section is about "legacy" 
advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you 
were referring to was RSVP-TE, then there is also additional guidance provided 
here : 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.2.4__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdRkvFDI2$>


Please clarify where RFC8920 describes advertisement of application-specific 
attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.
 From what I understand, you agree that the generic metric sub-TLV 
should be allowed in TE Opaque LSA.
You have concerns only on it being allowed in Extended Link opaque LSA top 
level Extended Link TLV right?



Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ie

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

[Ketan Talaulikar (ketant)]

Hi Shraddha,

When you refer to "a single TE application", it is not clear which one you are 
referring to : RSVP-TE or SR Policy?

I believe, for ISIS, you are referring to this specific section of RFC8919 : 
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1

There is no ambiguity here. This section is about use of "legacy" 
advertisement. The Generic Metric is a new TLV and hence cannot be considered 
as "legacy" by any interpretation of the word.

Coming to OSPF, the considerations are similar. Additionally we also have to 
deal with different LSA types here.

Please refer to https://datatracker.ietf.org/doc/html/rfc8920#section-12.1 for 
the equivalent discussion for OSPF. This section is about "legacy" 
advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you 
were referring to was RSVP-TE, then there is also additional guidance provided 
here : https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4

Please clarify where RFC8920 describes advertisement of application-specific 
attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.

Thanks,
Ketan

From: Shraddha Hegde 
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) ; Tony Li 
Cc: Acee Lindem (acee) ; 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

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of

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

[Shraddha Hegde]

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde ; Tony Li 
Cc: Acee Lindem (acee) ; 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,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of 
generic metric.



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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 Tony,

Please check inline below.

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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


Hi Ketan,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of 
the proposal to adopt and/or to split documents. I have seen this in recent 
past in other WGs. In any case, it is not a poi

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

[tom petch]

From: Lsr  on behalf of gregory.mir...@ztetx.com 

Sent: 25 May 2021 22:02

Inline under 
Tom Petch

Hi Tony,

thank you for clarifying your view on this. Please find my notes in-line below 
under the GIM>> tag.


Regards,

Greg Mirsky


Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


[cid:9ae3e214c17d49ed935d87c674ba3ee2]  [cid:24242e5637af428891c4db731e7765ad]
E: gregory.mir...@ztetx.com
www.zte.com.cn
Original Mail
Sender: TonyLi
Date: 2021/05/25 09:52

Hi Greg,

Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 
nanoseconds or 100 nanoseconds.

Ok.  The specific precision isn’t particularly relevant to me.  The real 
questions are whether microseconds are the right base or not, and whether we 
should shift to floating point for additional range or add more bits.

To Tony's question, the delay is usually calculated from the timestamps 
collected at measurement points (MP). Several formats of a timestamp, but most 
protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits 
represent seconds and 32 bits - a fraction of a second. As you can see, the 
nanosecond-level resolution is well within the capability of protocols like 
OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of 
the packet delay metric, I can think of URLLC in the MEC environment. I was 
told that some applications have an RTT budget of in the tens microseconds 
range.

It’s very true that folks have carried around nanosecond timestamps for a long 
time now.  No question there. My question is whether it is actually useful. 
While NTP has that precision in its timestamps, the actual precision  of NTP’s 
synchronization algorithms aren’t quite that strong.  In effect, many of those 
low order bits are wasted.

GIM>> What I see from deployment of active measurement protocols, e.g., TWAMP 
and STAMP, is the strong interest in using PTP, i.e. IEEE 1588v2, timestamp 
format in the data plane. And the requirement (actually, there are different 
profiles) for the quality of clock synchronization for 5G is, as I understand 
it, achievable with PTP. I have no information if that is the case with NTP.

That’s not a big deal, but when we make the base more precise, we lose range.  
If we go with 32 bits of nanoseconds, we limit ourselves to a link delay of ~4 
seconds. Tolerable, but it will certainly disappoint Vint and his 
inter-planetary Internet. :-)

GIM>> Agree. I would propose to consider 100 usec as a unit, which gets close 
to 7 minutes.

We could go with 64 bits of nanoseconds, but then we’ll probably only rarely 
use the high order bits, so that seems wasteful of bandwidth.

Or we can go to floating point. This will greatly increase the range, at the 
expense of having fewer significant bits in the mantissa.

Personally, I would prefer to stay with 32 bits, but I’m flexible after that.

GIM>> I think that we can stay with a 32 bit-long field and get better 
resolution at the same time.



A related item.  I was looking at draft-ietf-detnet-yang which uses uint32 
nanoseconds for latency so that is another where nanoseconds can be found.

Tom Petch

Tony


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Thanks – I now have all the declarations.
Acee

From: Rajesh M 
Date: Thursday, May 27, 2021 at 12:39 PM
To: Acee Lindem , "lsr@ietf.org" 
Cc: "draft-hegde-lsr-flex-algo-bw-...@ietf.org" 

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

I am not aware of any IPR that applies to this draft.

Thanks,
Rajesh




Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Thursday, May 13, 2021 2:39 AM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: 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]

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 27th, 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

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

[Rajesh M]

I am not aware of any IPR that applies to this draft.

Thanks,
Rajesh




Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Thursday, May 13, 2021 2:39 AM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: 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]

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 27th, 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

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

[William Britto A J]

I am not aware of any IPR related to this draft.

Thanks,
William

From: Lsr  on behalf of Acee Lindem (acee) 

Date: Thursday, 13 May 2021 at 2:51 AM
To: lsr@ietf.org 
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org 

Subject: [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]

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 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee




Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Hi Ketan,

On 27/05/2021 15:37, Ketan Talaulikar (ketant) wrote:



For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that 
different values for different applications is not allowed. Maximum Link 
bandwidth is also allowed with all bits set to zero in SABM/UDABM  or 
each individual application bit set for all applications making use of ASLA.


*/[KT2] Yes, you are correct. The RFC8919 does not mandate or require 
Max Link Bandwidth to be signaled within ASLA (at least that was my 
reading). If so, perhaps it is better to not require that in this 
document – just keep in the base. Would that not work? And if it were 
advertised in the ASLA (as RFC8919 allows it), then perhaps a reference 
to the RFC8919 will be important on how it is to be done – basically 
exactly what you described above./*




given that RFC8919 allows the Max Link Bandwidth to be signaled within 
ASLA, we need to be able to support it, in case someone uses that. What 
we would probably need to do is to look at the ASLA advertisement of Max 
Link Bandwidth first and if none is available fallback to legacy 
advertisement.


thanks,
Peter

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar (ketant)]

Hi Shraddha,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde 
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) ; Tony Li 
Cc: Acee Lindem (acee) ; 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

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of 
generic metric.



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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 Tony,

Please check inline below.

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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


Hi Ketan,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of 
the proposal to adopt and/or to split documents. I have seen this in recent 
past in other WGs. In any case, it is not a point that I wish to argue or 
debate on - especially in the context of this document. My point (8) was 
clarified and hence I fall in the binary YES in this instance.


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it's just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don't know what use-cases might arise. It doesn't seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.

[KT] Regarding metric overflow, I think it would be better to leave it to 
implem

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

[Ketan Talaulikar (ketant)]

Hi Shraddha,

Please check inline below with KT2

From: Lsr  On Behalf Of Shraddha Hegde
Sent: 27 May 2021 18:31
To: Tony Li ; Ketan Talaulikar (ketant) 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

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


Snipped..


5.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints, 
I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA 
- 
https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>,
 in case of ISIS also, it is not really appropriate for use within ASLA 
-https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxHHnJfE7$>?


I'm sorry, I don't understand this comment.
[KT] In 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxAEMtKzf$>


The Maximum Link Bandwidth as advertised by the sub-sub-

   TLV 23 of ASLA [RFC 
8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMntRW1t$>]
 MUST be compared against the Minimum

   bandwidth advertised in FAEMB sub-TLV.

And in the 
https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>


Maximum link bandwidth is an application-independent attribute of the

   link that is defined in 
[RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMwurpJX$>].
  Because it is an application-

   independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.

Somewhat similar for ISIS as well.


I'm sorry, I'm still not understanding your comment. Are you objecting because 
we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested 
this, updating the other two protocols.


 As per RFC 8920, Maximum Link Bandwidth cannot be advertised in 
ASLA. Will update the text to reflect Maximum Link Bandwidth sub-TLV in 
Extended Link TLV of Extended Link opaque LSA.
[KT2] Thanks.

For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that different 
values for different applications is not allowed. Maximum Link bandwidth is 
also allowed with all bits set to zero in SABM/UDABM  or each individual 
application bit set for all applications making use of ASLA.
[KT2] Yes, you are correct. The RFC8919 does not mandate or require Max Link 
Bandwidth to be signaled within ASLA (at least that was my reading). If so, 
perhaps it is better to not require that in this document - just keep in the 
base. Would that not work? And if it were advertised in the ASLA (as RFC8919 
allows it), then perhaps a reference to the RFC8919 will be important on how it 
is to be done - basically exactly what you described above.

Thanks,
Ketan

RFC 8919 sec 4.2.1
"  Maximum link bandwidth is an application-independent attribute of the
   link.  When advertised using the Application-Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised.
   This can be accomplished most efficiently by having a single
   advertisement for a given link where the Application Identifier Bit
   Mask identifies all the applications that are making use of the value
   for that link."


  1.  Document should cover the FAPM aspects for the Generic Metric and 
especially the Bandwidth metric.
 As long as we have fixed length generic metric, there won't be any 
changes to FAPM. We'll add a section to clarify about FAPM



Juniper Business Use Only
From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, May 26, 2021 10:10 PM
To: Ketan Jivan Talaulikar mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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 Ketan,


  1.  Why is the Generic Metri

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

[Ketan Talaulikar (ketant)]

Perhaps, I should have been more careful with the word "variable". Initially, I 
meant allowing either 24 or 32 bits size (to me making it 32 just covers both 
the bases). But then the discussions on delay brought to my mind that perhaps 
even 64-bit metric might be useful. So the variable in my mind was either 32 or 
64.

And I agree that there is no impact on FAPM if we picked the Generic Metric of 
32-bit (or even kept it 24-bit). And yes, thanks Shraddha for agreeing to cover 
the applicability and aspects of FAPM in this document. Similar also applies 
for the OSPF FAAM, btw.

Thanks,
Ketan

-Original Message-
From: Peter Psenak  
Sent: 27 May 2021 18:20
To: Shraddha Hegde ; Tony Li ; Ketan 
Talaulikar (ketant) 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

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

On 27/05/2021 14:36, Shraddha Hegde wrote:
>> we only need the new TLV to carry FAPM if we make the Generic Metric's size 
>> variable. If we keep it fixed size, we >should be fine with the existing 
>> FAPM.
> 
> Yes agree.
> The idea of making generic metric variable length is worth considering.
> I don't see a strong enough usecase right now to make it variable 
> length but will wait

nor do I.

thanks,
Peter



> for inputs from WG.
> 
> Rgds
> Shraddha
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Wednesday, May 26, 2021 10:27 PM
> To: Tony Li ; Ketan Jivan Talaulikar 
> 
> Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee 
> Lindem (acee) 
> 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 Tony, Ketan,
> 
> On 26/05/2021 18:40, Tony Li wrote:
> 
>>> */[KT] Generic Metric is used for the links. When we get to the 
>>> computation of inter-area or external routes, we will need to get 
>>> into FAPM. The draft at a minimum should discuss the applicability 
>>> of the Generic Metric and its use as FAPM. Now, if we do make the 
>>> Generic Metric size variable (as suggested above), then we will 
>>> likely need a new TLV for a variable size FAPM equivalent?/*
>>
>>
>> We would need a new TLV regardless of the metric size as the FAPM TLV 
>> only carries the default metric. We are not proposing that TLV at 
>> this time. That’s future work.
> 
> we only need the new TLV to carry FAPM if we make the Generic Metric's size 
> variable. If we keep it fixed size, we should be fine with the existing FAPM.
> 
> 
> thanks,
> Peter
>>
>> Tony
>>
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[bruno.decraene]

Acee, Chris,

I’m not aware of non-disclosed IPR.

Thanks,
--Bruno

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, May 12, 2021 11:09 PM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

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 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Authors,

There is a lot of interest in the document and sufficient support for WG 
adoption. Please republish as draft-ietf-lsr-flex-algo-bw-con-00.txt.

Of course, the current discussion of some of the finer points can continue.

Thanks,
Chris and Acee


From: Acee Lindem 
Date: Wednesday, May 12, 2021 at 5:09 PM
To: "lsr@ietf.org" 
Cc: "draft-hegde-lsr-flex-algo-bw-...@ietf.org" 

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

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 27th, 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

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

[Shraddha Hegde]

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of 
generic metric.



Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li 
Cc: Acee Lindem (acee) ; 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 Tony,

Please check inline below.

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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


Hi Ketan,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of 
the proposal to adopt and/or to split documents. I have seen this in recent 
past in other WGs. In any case, it is not a point that I wish to argue or 
debate on - especially in the context of this document. My point (8) was 
clarified and hence I fall in the binary YES in this instance.


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it's just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don't know what use-cases might arise. It doesn't seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.

[KT] Regarding metric overflow, I think it would be better to leave it to 
implementations on how to deal with it. A guidance similar to below (from 
draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does 
not cause interop issues. Theoretically, it is something that is independent of 
the size of the metric.

   During the route computation, it is possible for the Flex-Algorithm
   specific metric to exceed the maximum value that can be stored in an
   unsigned 32-bit variable.  In such scenarios, the value MUST be
   considered to be of value 4,294,967,295 during the computation and
   advertised as such.


  1.
  2.  Would be good to cover the max-metric considerations for the Generic 
Metric. Similar to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15*section-15.3__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKigDlnfK$>


Fair



  1.
  2.  Since 

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

[Shraddha Hegde]

Snipped..


5.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints, 
I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA 
- 
https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>,
 in case of ISIS also, it is not really appropriate for use within ASLA 
-https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxHHnJfE7$>?


I'm sorry, I don't understand this comment.
[KT] In 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxAEMtKzf$>


The Maximum Link Bandwidth as advertised by the sub-sub-

   TLV 23 of ASLA [RFC 
8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMntRW1t$>]
 MUST be compared against the Minimum

   bandwidth advertised in FAEMB sub-TLV.

And in the 
https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>


Maximum link bandwidth is an application-independent attribute of the

   link that is defined in 
[RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMwurpJX$>].
  Because it is an application-

   independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.

Somewhat similar for ISIS as well.


I'm sorry, I'm still not understanding your comment. Are you objecting because 
we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested 
this, updating the other two protocols.


 As per RFC 8920, Maximum Link Bandwidth cannot be advertised in 
ASLA. Will update the text to reflect Maximum Link Bandwidth sub-TLV in 
Extended Link TLV of Extended Link opaque LSA.

For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that different 
values for different applications is not allowed. Maximum Link bandwidth is 
also allowed with all bits set to zero in SABM/UDABM  or each individual 
application bit set for all applications making use of ASLA.

RFC 8919 sec 4.2.1
"  Maximum link bandwidth is an application-independent attribute of the
   link.  When advertised using the Application-Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised.
   This can be accomplished most efficiently by having a single
   advertisement for a given link where the Application Identifier Bit
   Mask identifies all the applications that are making use of the value
   for that link."


  1.  Document should cover the FAPM aspects for the Generic Metric and 
especially the Bandwidth metric.
 As long as we have fixed length generic metric, there won't be any 
changes to FAPM. We'll add a section to clarify about FAPM



Juniper Business Use Only
From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, May 26, 2021 10:10 PM
To: Ketan Jivan Talaulikar 
Cc: Acee Lindem (acee) ; 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 Ketan,


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it's just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don't know what use-cases might arise. It doesn't seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.


Thank you for the suggestion. I don't think anyone has suggested a variable 
leng

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

[Peter Psenak]

On 27/05/2021 14:36, Shraddha Hegde wrote:

we only need the new TLV to carry FAPM if we make the Generic Metric's size 
variable. If we keep it fixed size, we >should be fine with the existing FAPM.


Yes agree.
The idea of making generic metric variable length is worth considering.
I don't see a strong enough usecase right now to make it variable length but 
will wait


nor do I.

thanks,
Peter




for inputs from WG.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Peter Psenak 
Sent: Wednesday, May 26, 2021 10:27 PM
To: Tony Li ; Ketan Jivan Talaulikar 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

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 Tony, Ketan,

On 26/05/2021 18:40, Tony Li wrote:


*/[KT] Generic Metric is used for the links. When we get to the
computation of inter-area or external routes, we will need to get
into FAPM. The draft at a minimum should discuss the applicability of
the Generic Metric and its use as FAPM. Now, if we do make the
Generic Metric size variable (as suggested above), then we will
likely need a new TLV for a variable size FAPM equivalent?/*



We would need a new TLV regardless of the metric size as the FAPM TLV
only carries the default metric. We are not proposing that TLV at this
time. That’s future work.


we only need the new TLV to carry FAPM if we make the Generic Metric's size 
variable. If we keep it fixed size, we should be fine with the existing FAPM.


thanks,
Peter


Tony






___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Shraddha Hegde]

>we only need the new TLV to carry FAPM if we make the Generic Metric's size 
>variable. If we keep it fixed size, we >should be fine with the existing FAPM.

Yes agree. 
The idea of making generic metric variable length is worth considering.
I don't see a strong enough usecase right now to make it variable length but 
will wait
for inputs from WG.

Rgds
Shraddha 


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Wednesday, May 26, 2021 10:27 PM
To: Tony Li ; Ketan Jivan Talaulikar 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

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 Tony, Ketan,

On 26/05/2021 18:40, Tony Li wrote:

>> */[KT] Generic Metric is used for the links. When we get to the 
>> computation of inter-area or external routes, we will need to get 
>> into FAPM. The draft at a minimum should discuss the applicability of 
>> the Generic Metric and its use as FAPM. Now, if we do make the 
>> Generic Metric size variable (as suggested above), then we will 
>> likely need a new TLV for a variable size FAPM equivalent?/*
>
>
> We would need a new TLV regardless of the metric size as the FAPM TLV 
> only carries the default metric. We are not proposing that TLV at this 
> time. That’s future work.

we only need the new TLV to carry FAPM if we make the Generic Metric's size 
variable. If we keep it fixed size, we should be fine with the existing FAPM.


thanks,
Peter
>
> Tony
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Hi Tony, Ketan,

On 26/05/2021 18:40, Tony Li wrote:

*/[KT] Generic Metric is used for the links. When we get to the 
computation of inter-area or external routes, we will need to get into 
FAPM. The draft at a minimum should discuss the applicability of the 
Generic Metric and its use as FAPM. Now, if we do make the Generic 
Metric size variable (as suggested above), then we will likely need a 
new TLV for a variable size FAPM equivalent?/*



We would need a new TLV regardless of the metric size as the FAPM TLV 
only carries the default metric. We are not proposing that TLV at this 
time. That’s future work.


we only need the new TLV to carry FAPM if we make the Generic Metric's 
size variable. If we keep it fixed size, we should be fine with the 
existing FAPM.



thanks,
Peter


Tony



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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 Aijun,


>> My suggestion is still not introduce such non-cumulative metric to 
>> cumulative based SPF calculation process.
>  
> Again, what we’re proposing is cumulative.
>  
> [WAJ] My arguments is that your cumulative proposal (section 4.1.1.1 or 
> 4.1.1.2) can get unexpected result, that is, if there is no manual 
> intervention, the E2E sub-optimal path will be selected. You have also 
> confirmed this in 
> https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/ 
> , 
> said as below:
>  
> “Override the metric on B-E-D to be even higher.
>  
> The point of the bandwidth metric (at least in this incarnation) is not to 
> make hop count irrelevant. It isto set the metrics relative to the 
> bandwidth so that traffic skews towards higher bandwidths. Hops are still 
> relevant. An operator can adjust the reference bandwidth and add manual 
> metrics to achieve different effects, depending on their precise needs.”
>  
> The operator must investigate their topology carefully to add necessary 
> manual metric to avoid the unexpected sub-optimal path.  Is it nightmare?
>  


I’m sorry, but I seem to be unable to help you reset your expectations. 

The bandwidth metric is NOT intended to find the absolute highest bandwidth 
path to the destination regardless of all other considerations. It is simply 
using link metrics based on bandwidth as a means of skewing paths towards 
higher bandwidths, but it is still cumulative so that a significantly longer 
path may still drive traffic away from a higher bandwidth.

If it is any consideration, you should be aware that most implementations 
already set their default link metrics based on interface bandwidth. This 
results in EXACTLY this same behavior, with administrators making manual 
adjustments if necessary.

Regards,
Tony


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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 Ketan,

> Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF allows 4 
> byte size and so why not the same for ISIS? Elsewhere in the document, I do 
> see MAX METRIC being referred to as 4,261,412,864.
>  
>  
> Because I’m a lazy sod.
>  
> It’s far easier to detect metric overflow on three byte values than four byte 
> values. True, four byte is not impossible, but it’s just quick and easy with 
> three byte values.  Adding a fourth byte would add range to the metric space, 
> but in practice, this seemed like it was not really relevant. Most areas are 
> not a very high diameter and the need for detailed metric distinctions has 
> not been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) 
> and that seems to work.
> [KT] The Generic Metric is by definition something that will get extended in 
> the future and we don’t know what use-cases might arise. It doesn’t seem 
> right to follow in the steps of an administratively assigned metric type like 
> the TE metric. Therefore, I suggest to make it variable.


Thank you for the suggestion. I don’t think anyone has suggested a variable 
length metric before.  A variable length metric is difficult to implement as if 
the length exceeds your processors word size, you need to resort to long 
integer software emulation packages. These are a huge performance penalty.


> [KT] Regarding metric overflow, I think it would be better to leave it to 
> implementations on how to deal with it. A guidance similar to below (from 
> draft-ietf-lsr-flex-algo) would help handle the condition in a manner that 
> does not cause interop issues. Theoretically, it is something that is 
> independent of the size of the metric.
>  
>During the route computation, it is possible for the Flex-Algorithm
>specific metric to exceed the maximum value that can be stored in an
>unsigned 32-bit variable.  In such scenarios, the value MUST be
>considered to be of value 4,294,967,295 during the computation and
>advertised as such.


In fact, we are not specifying how implementations deal with it.


> 
> For the Max B/w Link attribute and its comparison with the FAD b/w 
> constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not 
> allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7 
> , in case of ISIS 
> also, it is not really appropriate for use within ASLA 
> -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1 
> ?
>  
>  
> I’m sorry, I don’t understand this comment.
> [KT] In 
> https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1
>  
> 
>  
> The Maximum Link Bandwidth as advertised by the sub-sub-
>TLV 23 of ASLA [RFC 8920 ] 
> MUST be compared against the Minimum
>bandwidth advertised in FAEMB sub-TLV.
>  
> And in the https://datatracker.ietf.org/doc/html/rfc8920#section-7 
> 
>  
> Maximum link bandwidth is an application-independent attribute of the
>link that is defined in [RFC3630 
> ].  Because it is an 
> application-
>independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.
>  
> Somewhat similar for ISIS as well.


I’m sorry, I’m still not understanding your comment. Are you objecting because 
we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested 
this, updating the other two protocols.


>  
> Document should cover the FAPM aspects for the Generic Metric and especially 
> the Bandwidth metric.
>  
>  
> Nor this one.
> [KT] Generic Metric is used for the links. When we get to the computation of 
> inter-area or external routes, we will need to get into FAPM. The draft at a 
> minimum should discuss the applicability of the Generic Metric and its use as 
> FAPM. Now, if we do make the Generic Metric size variable (as suggested 
> above), then we will likely need a new TLV for a variable size FAPM 
> equivalent?


We would need a new TLV regardless of the metric size as the FAPM TLV only 
carries the default metric. We are not proposing that TLV at this time. That’s 
future work.


Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Tony:

 

From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Wednesday, May 26, 2021 12:31 AM
To: Aijun Wang 
Cc: lsr ; Ketan Jivan Talaulikar ; Acee Lindem 
(acee) ; 
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

 

 

Hi Aijun,

 

My suggestion is still not introduce such non-cumulative metric to cumulative 
based SPF calculation process.

 

Again, what we’re proposing is cumulative.

 

[WAJ] My arguments is that your cumulative proposal (section 4.1.1.1 or 
4.1.1.2) can get unexpected result, that is, if there is no manual 
intervention, the E2E sub-optimal path will be selected. You have also 
confirmed this in 
https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/, said as 
below:

 

“Override the metric on B-E-D to be even higher.

 

The point of the bandwidth metric (at least in this incarnation) is not to make 
hop count irrelevant. It isto set the metrics relative to the bandwidth so 
that traffic skews towards higher bandwidths. Hops are still relevant. An 
operator can adjust the reference bandwidth and add manual metrics to achieve 
different effects, depending on their precise needs.”

 

The operator must investigate their topology carefully to add necessary manual 
metric to avoid the unexpected sub-optimal path.  Is it nightmare?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

 

 

Tony

 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar (ketant)]

Hi Tony,

Please check inline below.

From: Tony Li  On Behalf Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) 
Cc: Acee Lindem (acee) ; 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


Hi Ketan,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of 
the proposal to adopt and/or to split documents. I have seen this in recent 
past in other WGs. In any case, it is not a point that I wish to argue or 
debate on – especially in the context of this document. My point (8) was 
clarified and hence I fall in the binary YES in this instance.



  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I’m a lazy sod.

It’s far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it’s just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don’t know what use-cases might arise. It doesn’t seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.


[KT] Regarding metric overflow, I think it would be better to leave it to 
implementations on how to deal with it. A guidance similar to below (from 
draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does 
not cause interop issues. Theoretically, it is something that is independent of 
the size of the metric.

   During the route computation, it is possible for the Flex-Algorithm
   specific metric to exceed the maximum value that can be stored in an
   unsigned 32-bit variable.  In such scenarios, the value MUST be
   considered to be of value 4,294,967,295 during the computation and
   advertised as such.


  1.
  2.  Would be good to cover the max-metric considerations for the Generic 
Metric. Similar to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3


Fair




  1.
  2.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic – we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new “application” we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value – sharing 
single advertisement across applications or doing a different one 
per-application.


  1.
  2.  For the newly proposed FAD b/w constraints, I would suggest the following 
names for the constraint sub-TLVs where the b/w value signalled by all is 
compared with the Max Link B/w attribute. This is just to make the meaning, at 
least IMHO, more clear.

 *   Exclude Higher Bandwidth Links
 *   Exclude Lower Bandwidth Links
 *   Include-Only Higher Bandwidth Links
 *   Include-Only Lower Bandwidth Links

  1.  Similar naming for the FAD delay constraints as well would help. Though I 
can only think of the use of “exclude” for links above a certain delay 
threshold to be more practical but perhaps others might eventually be required 
as well?


Thank you for the suggestions.




  1.
  2.  For the Max B/w Link attribute and its comparison with the FAD b/w 
constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not 
allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7, in 
case of ISIS also, it is not really appropriate for use within ASLA 
-https://datatracker.ie

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

Speaking as a WG member:

I think the argument for delays < 1 usec is very weak and haven’t heard any 
compelling arguments.

Thanks,
Acee

From: Lsr  on behalf of Anoop Ghanwani 

Date: Tuesday, May 25, 2021 at 6:08 PM
To: Tony Li 
Cc: lsr , "gregory.mir...@ztetx.com" 
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

>>>
That’s not a big deal, but when we make the base more precise, we lose range.  
If we go with 32 bits of nanoseconds, we limit ourselves to a link delay of ~4 
seconds. Tolerable, but it will certainly disappoint Vint and his 
inter-planetary Internet. :-)
>>>
The current 24 bits of usec delay isn't that much better at ~16 sec.  (Unless 
there is a proposal to change that to 32 bits?)

On Tue, May 25, 2021 at 9:53 AM Tony Li 
mailto:tony...@tony.li>> wrote:

Hi Greg,

Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 
nanoseconds or 100 nanoseconds.

Ok.  The specific precision isn’t particularly relevant to me.  The real 
questions are whether microseconds are the right base or not, and whether we 
should shift to floating point for additional range or add more bits.



To Tony's question, the delay is usually calculated from the timestamps 
collected at measurement points (MP). Several formats of a timestamp, but most 
protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits 
represent seconds and 32 bits - a fraction of a second. As you can see, the 
nanosecond-level resolution is well within the capability of protocols like 
OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of 
the packet delay metric, I can think of URLLC in the MEC environment. I was 
told that some applications have an RTT budget of in the tens microseconds 
range.

It’s very true that folks have carried around nanosecond timestamps for a long 
time now.  No question there. My question is whether it is actually useful. 
While NTP has that precision in its timestamps, the actual precision  of NTP’s 
synchronization algorithms aren’t quite that strong.  In effect, many of those 
low order bits are wasted.

That’s not a big deal, but when we make the base more precise, we lose range.  
If we go with 32 bits of nanoseconds, we limit ourselves to a link delay of ~4 
seconds. Tolerable, but it will certainly disappoint Vint and his 
inter-planetary Internet. :-)

We could go with 64 bits of nanoseconds, but then we’ll probably only rarely 
use the high order bits, so that seems wasteful of bandwidth.

Or we can go to floating point. This will greatly increase the range, at the 
expense of having fewer significant bits in the mantissa.

Personally, I would prefer to stay with 32 bits, but I’m flexible after that.

Tony

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Anoop Ghanwani]

>>>
That’s not a big deal, but when we make the base more precise, we lose
range.  If we go with 32 bits of nanoseconds, we limit ourselves to a link
delay of ~4 seconds. Tolerable, but it will certainly disappoint Vint and
his inter-planetary Internet. :-)
>>>
The current 24 bits of usec delay isn't that much better at ~16 sec.
(Unless there is a proposal to change that to 32 bits?)

On Tue, May 25, 2021 at 9:53 AM Tony Li  wrote:

>
> Hi Greg,
>
> Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps,
> 10 nanoseconds or 100 nanoseconds.
>
>
> Ok.  The specific precision isn’t particularly relevant to me.  The real
> questions are whether microseconds are the right base or not, and whether
> we should shift to floating point for additional range or add more bits.
>
> To Tony's question, the delay is usually calculated from the timestamps
> collected at measurement points (MP). Several formats of a timestamp, but
> most protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where
> 32 bits represent seconds and 32 bits - a fraction of a second. As you can
> see, the nanosecond-level resolution is well within the capability of
> protocols like OWAMP/TWAMP/STAMP. As for use cases that may benefit from
> higher resolution of the packet delay metric, I can think of URLLC in the
> MEC environment. I was told that some applications have an RTT budget of in
> the tens microseconds range.
>
>
> It’s very true that folks have carried around nanosecond timestamps for a
> long time now.  No question there. My question is whether it is actually
> useful. While NTP has that precision in its timestamps, the actual
> precision  of NTP’s synchronization algorithms aren’t quite that strong.
> In effect, many of those low order bits are wasted.
>
> That’s not a big deal, but when we make the base more precise, we lose
> range.  If we go with 32 bits of nanoseconds, we limit ourselves to a link
> delay of ~4 seconds. Tolerable, but it will certainly disappoint Vint and
> his inter-planetary Internet. :-)
>
> We could go with 64 bits of nanoseconds, but then we’ll probably only
> rarely use the high order bits, so that seems wasteful of bandwidth.
>
> Or we can go to floating point. This will greatly increase the range, at
> the expense of having fewer significant bits in the mantissa.
>
> Personally, I would prefer to stay with 32 bits, but I’m flexible after
> that.
>
> Tony
>
> ___
> 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

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

[gregory.mirsky]

Hi Tony,


thank you for clarifying your view on this. Please find my notes in-line below 
under the GIM>> tag.








Regards,


Greg Mirsky






Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division









E: gregory.mir...@ztetx.com 
www.zte.com.cn








Original Mail



Sender: TonyLi
To: gregory mirsky10211915;
CC: lsr;
Date: 2021/05/25 09:52
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,





Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 
nanoseconds or 100 nanoseconds.




Ok.  The specific precision isn’t particularly relevant to me.  The real 
questions are whether microseconds are the right base or not, and whether we 
should shift to floating point for additional range or add more bits.



To Tony's question, the delay is usually calculated from the timestamps 
collected at measurement points (MP). Several formats of a timestamp, but most 
protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits 
represent seconds and 32 bits - a fraction of a second. As you can see, the 
nanosecond-level resolution is well within the capability of protocols like 
OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of 
the packet delay metric, I can think of URLLC in the MEC environment. I was 
told that some applications have an RTT budget of in the tens microseconds 
range.




It’s very true that folks have carried around nanosecond timestamps for a long 
time now.  No question there. My question is whether it is actually useful. 
While NTP has that precision in its timestamps, the actual precision  of NTP’s 
synchronization algorithms aren’t quite that strong.  In effect, many of those 
low order bits are wasted.

GIM>> What I see from deployment of active measurement protocols, e.g., TWAMP 
and STAMP, is the strong interest in using PTP, i.e. IEEE 1588v2, timestamp 
format in the data plane. And the requirement (actually, there are different 
profiles) for the quality of clock synchronization for 5G is, as I understand 
it, achievable with PTP. I have no information if that is the case with NTP.


That’s not a big deal, but when we make the base more precise, we lose range.  
If we go with 32 bits of nanoseconds, we limit ourselves to a link delay of ~4 
seconds. Tolerable, but it will certainly disappoint Vint and his 
inter-planetary Internet. :-)

GIM>> Agree. I would propose to consider 100 usec as a unit, which gets close 
to 7 minutes.


We could go with 64 bits of nanoseconds, but then we’ll probably only rarely 
use the high order bits, so that seems wasteful of bandwidth.

Or we can go to floating point. This will greatly increase the range, at the 
expense of having fewer significant bits in the mantissa.




Personally, I would prefer to stay with 32 bits, but I’m flexible after that.

GIM>> I think that we can stay with a 32 bit-long field and get better 
resolution at the same time.


Tony___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[gregory.mirsky]

Hi Anoop,

thank you for sharing your thoughts. I agree, it is very likely that in most 
cases, the potential inaccuracy of 1 usec per link would not affect the 
construction of a route. But for cases that require very low bounded latency, 
e.g., DetNet, such a level of uncertainty about the actual value of the delay 
might fail to find a route altogether. Consider a case where the measured e2e 
delay is N usec is well within the required level. But the sum of the 
advertised Maximum Link Delays is above that threshold.

I think that using 100 nsec as the unit of the Maximum Link Delay is a 
reasonable compromise between that scale and accuracy.








Regards,


Greg Mirsky






Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division









E: gregory.mir...@ztetx.com 
www.zte.com.cn






Original Mail



Sender: AnoopGhanwani
To: gregory mirsky10211915;
CC: lsr@ietf.org;
Date: 2021/05/25 00:11
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02




Greg,
One thing to keep in mind is that even though we can measure latency at a 
precision of 10's or 100's of nanoseconds, does it hurt to round the link delay 
up to the nearest microsecond?  One way to look at this is that by doing such 
rounding up, we add at most 1 usec worth of additional delay per hop.  That was 
my rationale for thinking it's probably OK to leave the resolution at 1 usec.  

I don't have a strong opinion either way.

Anoop 




On Mon, May 24, 2021 at 7:32 PM  wrote:

Dear All,

thank you for the discussion of my question on the unit of the Maximum Link 
Delay parameter.

Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 
nanoseconds or 100 nanoseconds.

To Tony's question, the delay is usually calculated from the timestamps 
collected at measurement points (MP). Several formats of a timestamp, but most 
protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits 
represent seconds and 32 bits - a fraction of a second. As you can see, the 
nanosecond-level resolution is well within the capability of protocols like 
OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of 
the packet delay metric, I can think of URLLC in the MEC environment. I was 
told that some applications have an RTT budget of in the tens microseconds 
range.




Shraddha, you've said

"The measurement mechanisms and advertisements in ISIS support micro-second 
granularity (RFC 8570)."

Could you direct me to the text in RFC 8570 that defines the measurement 
method, protocol that limits the resolution to a microsecond?




To Acee, I think that

"Any measurement of delay would include the both components of delay"

it depends on where the MP is located (yes, it is another "It depends" 
situation). 




I agree with Anoop that it could be beneficial to have a text in the draft that 
explains three types of delays a packet experiences and how the location of an 
MP affects the accuracy of the measurement and the metric.






Best regards,


Greg Mirsky





Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division









E: gregory.mir...@ztetx.com 
www.zte.com.cn





___
 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

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

[gregory.mirsky]

Hi Shraddha,


thank you for pointing out the text. Though it mentions that the value is the 
average delay calculated over configured, i.e., pre-defined interval, that 
seems it leaves out some important aspects of the measurement method, e.g., 
number of measurements in the set over which the average is calculated. Also, 
I'd note that the average is not the most informative and robust metric as it 
is more sensitive to extremes (spikes and drops) than, for example, median and 
percentile (the most often used are 95, 99, and 99.9).








Regards,


Greg Mirsky






Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division









E: gregory.mir...@ztetx.com 
www.zte.com.cn








Original Mail



Sender: ShraddhaHegde
To: gregory mirsky10211915;lsr@ietf.org;
Date: 2021/05/25 02:46
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02






Snipped …


 

>Shraddha, you've said

>"The measurement mechanisms and advertisements in ISIS support micro-second 
>granularity (RFC 8570)."

>Could you direct me to the text in RFC 8570 that defines the measurement 
>method, protocol that limits the >resolution to a microsecond?

 

Pls refer RFC 8570 sec 4.1. The link delay is encoded in microseconds

“   Delay:  This 24-bit field carries the average link delay over a 
  configurable interval in microseconds, encoded as an integer


  value.  When set to the maximum value 16,777,215


  (16.777215 seconds), then the delay is at least that value and may


  be larger.


“

Exact same text can be found in OSPF RFC 7471 sec 4.1.5 as well.

 

Rgds

Shraddha


 


 


 


 


Juniper Business Use Only



From: Lsr  On Behalf Of gregory.mir...@ztetx.com
 Sent: Tuesday, May 25, 2021 8:03 AM
 To: 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




 


[External Email. Be cautious of content]


 

Dear All,

thank you for the discussion of my question on the unit of the Maximum Link 
Delay parameter.

Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 
nanoseconds or 100 nanoseconds.

To Tony's question, the delay is usually calculated from the timestamps 
collected at measurement points (MP). Several formats of a timestamp, but most 
protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits 
represent seconds and 32 bits - a fraction of a second. As you can see, the 
nanosecond-level resolution is well within the capability of protocols like 
OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of 
the packet delay metric, I can think of URLLC in the MEC environment. I was 
told that some applications have an RTT budget of in the tens microseconds 
range.

 

Shraddha, you've said

"The measurement mechanisms and advertisements in ISIS support micro-second 
granularity (RFC 8570)."

Could you direct me to the text in RFC 8570 that defines the measurement 
method, protocol that limits the resolution to a microsecond?

 

To Acee, I think that

"Any measurement of delay would include the both components of delay"

it depends on where the MP is located (yes, it is another "It depends" 
situation). 

 

I agree with Anoop that it could be beneficial to have a text in the draft that 
explains three types of delays a packet experiences and how the location of an 
MP affects the accuracy of the measurement and the metric.

 

Best regards,


Greg Mirsky


 


Sr. Standardization Expert
 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


 






 E: gregory.mir...@ztetx.com 
 www.zte.com.cn___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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,
> Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 
> nanoseconds or 100 nanoseconds.
> 

Ok.  The specific precision isn’t particularly relevant to me.  The real 
questions are whether microseconds are the right base or not, and whether we 
should shift to floating point for additional range or add more bits.

> To Tony's question, the delay is usually calculated from the timestamps 
> collected at measurement points (MP). Several formats of a timestamp, but 
> most protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 
> bits represent seconds and 32 bits - a fraction of a second. As you can see, 
> the nanosecond-level resolution is well within the capability of protocols 
> like OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher 
> resolution of the packet delay metric, I can think of URLLC in the MEC 
> environment. I was told that some applications have an RTT budget of in the 
> tens microseconds range.
> 

It’s very true that folks have carried around nanosecond timestamps for a long 
time now.  No question there. My question is whether it is actually useful. 
While NTP has that precision in its timestamps, the actual precision  of NTP’s 
synchronization algorithms aren’t quite that strong.  In effect, many of those 
low order bits are wasted.

That’s not a big deal, but when we make the base more precise, we lose range.  
If we go with 32 bits of nanoseconds, we limit ourselves to a link delay of ~4 
seconds. Tolerable, but it will certainly disappoint Vint and his 
inter-planetary Internet. :-)

We could go with 64 bits of nanoseconds, but then we’ll probably only rarely 
use the high order bits, so that seems wasteful of bandwidth.

Or we can go to floating point. This will greatly increase the range, at the 
expense of having fewer significant bits in the mantissa.

Personally, I would prefer to stay with 32 bits, but I’m flexible after that.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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 Aijun,

> My suggestion is still not introduce such non-cumulative metric to cumulative 
> based SPF calculation process.

Again, what we’re proposing is cumulative.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Shraddha Hegde]

Snipped …


>Shraddha, you've said

>"The measurement mechanisms and advertisements in ISIS support micro-second 
>granularity (RFC 8570)."

>Could you direct me to the text in RFC 8570 that defines the measurement 
>method, protocol that limits the >resolution to a microsecond?



Pls refer RFC 8570 sec 4.1. The link delay is encoded in microseconds

“   Delay:  This 24-bit field carries the average link delay over a
  configurable interval in microseconds, encoded as an integer
  value.  When set to the maximum value 16,777,215
  (16.777215 seconds), then the delay is at least that value and may
  be larger.
“

Exact same text can be found in OSPF RFC 7471 sec 4.1.5 as well.



Rgds

Shraddha





Juniper Business Use Only
From: Lsr  On Behalf Of gregory.mir...@ztetx.com
Sent: Tuesday, May 25, 2021 8:03 AM
To: 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

[External Email. Be cautious of content]


Dear All,

thank you for the discussion of my question on the unit of the Maximum Link 
Delay parameter.

Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 
nanoseconds or 100 nanoseconds.

To Tony's question, the delay is usually calculated from the timestamps 
collected at measurement points (MP). Several formats of a timestamp, but most 
protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits 
represent seconds and 32 bits - a fraction of a second. As you can see, the 
nanosecond-level resolution is well within the capability of protocols like 
OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of 
the packet delay metric, I can think of URLLC in the MEC environment. I was 
told that some applications have an RTT budget of in the tens microseconds 
range.



Shraddha, you've said

"The measurement mechanisms and advertisements in ISIS support micro-second 
granularity (RFC 8570)."

Could you direct me to the text in RFC 8570 that defines the measurement 
method, protocol that limits the resolution to a microsecond?



To Acee, I think that

"Any measurement of delay would include the both components of delay"

it depends on where the MP is located (yes, it is another "It depends" 
situation).



I agree with Anoop that it could be beneficial to have a text in the draft that 
explains three types of delays a packet experiences and how the location of an 
MP affects the accuracy of the measurement and the metric.



Best regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


[cid:image001.gif@01D75178.7F44CE20]
[cid:image002.gif@01D75178.7F44CE20]
E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>
www.zte.com.cn<https://urldefense.com/v3/__http:/www.zte.com.cn/__;!!NEt6yMaO-gk!VRzSJtXYzBGvfAj_K6DQpR2shaOjIkVhd7dPvtosaNV9DVJCJkam3Ub0C07UEhVy$>

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Anoop Ghanwani]

Greg,

One thing to keep in mind is that even though we can measure latency at a
precision of 10's or 100's of nanoseconds, does it hurt to round the link
delay up to the nearest microsecond?  One way to look at this is that by
doing such rounding up, we add at most 1 usec worth of additional delay per
hop.  That was my rationale for thinking it's probably OK to leave the
resolution at 1 usec.

I don't have a strong opinion either way.

Anoop

On Mon, May 24, 2021 at 7:32 PM  wrote:

> Dear All,
>
> thank you for the discussion of my question on the unit of the Maximum
> Link Delay parameter.
>
> Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps,
> 10 nanoseconds or 100 nanoseconds.
>
> To Tony's question, the delay is usually calculated from the timestamps
> collected at measurement points (MP). Several formats of a timestamp, but
> most protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where
> 32 bits represent seconds and 32 bits - a fraction of a second. As you can
> see, the nanosecond-level resolution is well within the capability of
> protocols like OWAMP/TWAMP/STAMP. As for use cases that may benefit from
> higher resolution of the packet delay metric, I can think of URLLC in the
> MEC environment. I was told that some applications have an RTT budget of in
> the tens microseconds range.
>
>
> Shraddha, you've said
>
> "The measurement mechanisms and advertisements in ISIS support
> micro-second granularity (RFC 8570)."
>
> Could you direct me to the text in RFC 8570 that defines the measurement
> method, protocol that limits the resolution to a microsecond?
>
>
> To Acee, I think that
>
> "Any measurement of delay would include the both components of delay"
>
> it depends on where the MP is located (yes, it is another "It depends"
> situation).
>
>
> I agree with Anoop that it could be beneficial to have a text in the draft
> that explains three types of delays a packet experiences and how the
> location of an MP affects the accuracy of the measurement and the metric.
>
>
> Best regards,
>
> Greg Mirsky
>
>
> Sr. Standardization Expert
> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R
> Institute/Wireline Product Operation Division
>
>
>
> E: gregory.mir...@ztetx.com
> www.zte.com.cn
> ___
> 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

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

[gregory.mirsky]

Dear All,

thank you for the discussion of my question on the unit of the Maximum Link 
Delay parameter.

Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 
nanoseconds or 100 nanoseconds.

To Tony's question, the delay is usually calculated from the timestamps 
collected at measurement points (MP). Several formats of a timestamp, but most 
protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits 
represent seconds and 32 bits - a fraction of a second. As you can see, the 
nanosecond-level resolution is well within the capability of protocols like 
OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of 
the packet delay metric, I can think of URLLC in the MEC environment. I was 
told that some applications have an RTT budget of in the tens microseconds 
range.




Shraddha, you've said

"The measurement mechanisms and advertisements in ISIS support micro-second 
granularity (RFC 8570)."

Could you direct me to the text in RFC 8570 that defines the measurement 
method, protocol that limits the resolution to a microsecond?




To Acee, I think that

"Any measurement of delay would include the both components of delay"

it depends on where the MP is located (yes, it is another "It depends" 
situation). 




I agree with Anoop that it could be beneficial to have a text in the draft that 
explains three types of delays a packet experiences and how the location of an 
MP affects the accuracy of the measurement and the metric.








Best regards,


Greg Mirsky






Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division









E: gregory.mir...@ztetx.com 
www.zte.com.cn___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Tony:

7.  The document introduces a new Generic Metric type called Bandwidth 
metric. I’ve been trying to follow some of the discussion related to this on 
the mailing list – about it being cumulative or not. I am perhaps somewhat 
confused by those discussions. The OSPF/ISIS SPT computation has always worked 
with cumulative link (and prefix) metrics. If the computation for the Generic 
Metric of this new type b/w is not going to be cumulative (I thought it is – 
but not very clear anymore), then the document needs to describe the 
computation algorithm. Is it then hop count based? Perhaps I am missing 
something very basic here and if so, please point me to the text in the draft.

 

 

I’m sorry if this has been confusing. My understanding is that the metric is 
cumulative. Others had other expectations.

 

When there are multiple links with the same bandwidth, and thus the same 
metric, then the total path metric becomes (link metric) * (number of links).

[WAJ] Such cumulative may be problematic in some situations and would need the 
manual intervention to “override” the automatic calculation “total path metric” 
to achieve the desired results. (please refer to the example in 
https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/

The difficulty is to how to find the unexpected paths in complex topology.

 

My suggestion is still not introduce such non-cumulative metric to cumulative 
based SPF calculation process.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

 

Regards,

Tony

 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Hi Tony,

On 24/05/2021 20:44, Tony Li wrote:


Hi Ketan,

In general, I support the adoption of this document. There is, 
however, one specific point which is not clear to me (8) below that I 
would appreciate some clarity on before adoption.



As the chairs have noted, adoption is binary and not contingent upon 
rough consensus on the content, just on rough consensus on the interest.





 1. Why is the Generic Metric type in ISIS limited to 3 byte size?
OSPF allows 4 byte size and so why not the same for ISIS?
Elsewhere in the document, I do see MAX METRIC being referred to
as 4,261,412,864.



Because I’m a lazy sod.

It’s far easier to detect metric overflow on three byte values than four 
byte values. True, four byte is not impossible, but it’s just quick and 
easy with three byte values.  Adding a fourth byte would add range to 
the metric space, but in practice, this seemed like it was not really 
relevant. Most areas are not a very high diameter and the need for 
detailed metric distinctions has not been that high.  Thus, we went with 
a 3 byte metric in RFC 5305 (sec 3.7) and that seems to work.



1.
 2. Would be good to cover the max-metric considerations for the
Generic Metric. Similar

tohttps://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3



Fair



2.
 3. Since the draft is covering FlexAlgo, I would have expected that
Generic Metric is carried only in the ASLA and this document
specifies usage only for the FA application. Later this can be
also used/extended for other applications but still within ASLA.
Keeping an option of advertising both outside and within the ASLA
is problematic – we will need precedence rules and such. I prefer
we avoid this complication.



We preferred avoiding ASLA.


we are not avoiding ASLA. We allow the ISIS Generic Metric sub-TLV to be 
sent inside or outside ASLA.


For flex-algo purposes we mandate it to be in ASLA. That's all what we 
need for the purpose of this draft. The rest is for future.







3.
 4. For the newly proposed FAD b/w constraints, I would suggest the
following names for the constraint sub-TLVs where the b/w value
signalled by all is compared with the Max Link B/w attribute. This
is just to make the meaning, at least IMHO, more clear.
 1. Exclude Higher Bandwidth Links
 2. Exclude Lower Bandwidth Links
 3. Include-Only Higher Bandwidth Links
 4. Include-Only Lower Bandwidth Links
 5. Similar naming for the FAD delay constraints as well would help.
Though I can only think of the use of “exclude” for links above a
certain delay threshold to be more practical but perhaps others
might eventually be required as well?



Thank you for the suggestions.



5.
 6. For the Max B/w Link attribute and its comparison with the FAD b/w
constraints, I see the reference to ASLA. While in OSPF
max-bandwidth is not allowed in ASLA
-https://datatracker.ietf.org/doc/html/rfc8920#section-7, in case
of ISIS also, it is not really appropriate for use within ASLA
-https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1?



I’m sorry, I don’t understand this comment.



6.
 7. Document should cover the FAPM aspects for the Generic Metric and
especially the Bandwidth metric.



Nor this one.



7.
 8. The document introduces a new Generic Metric type called Bandwidth
metric. I’ve been trying to follow some of the discussion related
to this on the mailing list – about it being cumulative or not. I
am perhaps somewhat confused by those discussions. The OSPF/ISIS
SPT computation has always worked with cumulative link (and
prefix) metrics. If the computation for the Generic Metric of this
new type b/w is not going to be cumulative (I thought it is – but
not very clear anymore), then the document needs to describe the
computation algorithm. Is it then hop count based? Perhaps I am
missing something very basic here and if so, please point me to
the text in the draft.




I’m sorry if this has been confusing. My understanding is that the 
metric is cumulative. Others had other expectations.


my expectation is to be cumulative as well.

thanks,
Peter




When there are multiple links with the same bandwidth, and thus the same 
metric, then the total path metric becomes (link metric) * (number of 
links).


Regards,
Tony



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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 Ketan,

> In general, I support the adoption of this document. There is, however, one 
> specific point which is not clear to me (8) below that I would appreciate 
> some clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.



> Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF allows 4 
> byte size and so why not the same for ISIS? Elsewhere in the document, I do 
> see MAX METRIC being referred to as 4,261,412,864.


Because I’m a lazy sod.

It’s far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it’s just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.

> Would be good to cover the max-metric considerations for the Generic Metric. 
> Similar to 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3
>  
> 

Fair


> Since the draft is covering FlexAlgo, I would have expected that Generic 
> Metric is carried only in the ASLA and this document specifies usage only for 
> the FA application. Later this can be also used/extended for other 
> applications but still within ASLA. Keeping an option of advertising both 
> outside and within the ASLA is problematic – we will need precedence rules 
> and such. I prefer we avoid this complication.


We preferred avoiding ASLA.


> For the newly proposed FAD b/w constraints, I would suggest the following 
> names for the constraint sub-TLVs where the b/w value signalled by all is 
> compared with the Max Link B/w attribute. This is just to make the meaning, 
> at least IMHO, more clear.
> Exclude Higher Bandwidth Links
> Exclude Lower Bandwidth Links
> Include-Only Higher Bandwidth Links
> Include-Only Lower Bandwidth Links
> Similar naming for the FAD delay constraints as well would help. Though I can 
> only think of the use of “exclude” for links above a certain delay threshold 
> to be more practical but perhaps others might eventually be required as well?


Thank you for the suggestions.


> For the Max B/w Link attribute and its comparison with the FAD b/w 
> constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not 
> allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7 
> , in case of ISIS 
> also, it is not really appropriate for use within ASLA 
> -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1 
> ?


I’m sorry, I don’t understand this comment.


> Document should cover the FAPM aspects for the Generic Metric and especially 
> the Bandwidth metric.


Nor this one.


> The document introduces a new Generic Metric type called Bandwidth metric. 
> I’ve been trying to follow some of the discussion related to this on the 
> mailing list – about it being cumulative or not. I am perhaps somewhat 
> confused by those discussions. The OSPF/ISIS SPT computation has always 
> worked with cumulative link (and prefix) metrics. If the computation for the 
> Generic Metric of this new type b/w is not going to be cumulative (I thought 
> it is – but not very clear anymore), then the document needs to describe the 
> computation algorithm. Is it then hop count based? Perhaps I am missing 
> something very basic here and if so, please point me to the text in the draft.
> 

I’m sorry if this has been confusing. My understanding is that the metric is 
cumulative. Others had other expectations.

When there are multiple links with the same bandwidth, and thus the same 
metric, then the total path metric becomes (link metric) * (number of links).

Regards,
Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar (ketant)]

Hello Authors/All,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.

Some questions/comments/suggestions:


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.
  2.  Would be good to cover the max-metric considerations for the Generic 
Metric. Similar to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3
  3.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic – we will need precedence rules and such. I prefer we 
avoid this complication.
  4.  For the newly proposed FAD b/w constraints, I would suggest the following 
names for the constraint sub-TLVs where the b/w value signalled by all is 
compared with the Max Link B/w attribute. This is just to make the meaning, at 
least IMHO, more clear.
 *   Exclude Higher Bandwidth Links
 *   Exclude Lower Bandwidth Links
 *   Include-Only Higher Bandwidth Links
 *   Include-Only Lower Bandwidth Links
  5.  Similar naming for the FAD delay constraints as well would help. Though I 
can only think of the use of “exclude” for links above a certain delay 
threshold to be more practical but perhaps others might eventually be required 
as well?
  6.  For the Max B/w Link attribute and its comparison with the FAD b/w 
constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not 
allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7, in 
case of ISIS also, it is not really appropriate for use within ASLA - 
https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1?
  7.  Document should cover the FAPM aspects for the Generic Metric and 
especially the Bandwidth metric.
  8.  The document introduces a new Generic Metric type called Bandwidth 
metric. I’ve been trying to follow some of the discussion related to this on 
the mailing list – about it being cumulative or not. I am perhaps somewhat 
confused by those discussions. The OSPF/ISIS SPT computation has always worked 
with cumulative link (and prefix) metrics. If the computation for the Generic 
Metric of this new type b/w is not going to be cumulative (I thought it is – 
but not very clear anymore), then the document needs to describe the 
computation algorithm. Is it then hop count based? Perhaps I am missing 
something very basic here and if so, please point me to the text in the draft.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 13 May 2021 02:39
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

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 27th, 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

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

Any measurement of delay would include the both components of delay.
Thanks,
Acee

From: Anoop Ghanwani 
Date: Monday, May 24, 2021 at 11:28 AM
To: Acee Lindem 
Cc: Christian Hopps , 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

The part that Chris mentioned (transmission delay) doesn't depend on speed of 
light or cable length; it only depends on link speed.
The part that you mentioned (propagation delay) depends only on cable length 
and speed of light in that medium and is independent of link speed.

Typically, the speed of light in fiber is estimated to be around 2x10^8 m/sec.

There's also packet processing delay which I mentioned in my other email and 
queueing delay which I forgot to mention.

I think it might be a good idea if the draft mentioned what delay(s) "SHOULD" 
be used.

On Mon, May 24, 2021 at 4:10 AM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:


On 5/23/21, 9:12 PM, "Christian Hopps" 
mailto:cho...@chopps.org>> wrote:


"Acee Lindem (acee)" 
mailto: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=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 mailto:tony1ath...@gmail.com>> on 
behalf of Tony Li
> mailto:tony...@tony.li>>
> Date: Sunday, May 23, 2021 at 4:56 PM
> To: Greg Mirsky mailto:gregimir...@gmail.com>>
> Cc: Shraddha Hegde mailto:shrad...@juniper.net>>, 
"peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>"
> mailto:peng.sha...@zte.com.cn>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>,
    > 
"draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>"
    > 
mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>>,
 Acee Lindem
> mailto: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 
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  40juniper@dmarc.ietf.org<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> 
mailto:peng.sha...@zte.com.cn>>
>         Sent: Thursday, Ma

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

[Anoop Ghanwani]

Yes, I think that would be useful.

On Mon, May 24, 2021 at 8:42 AM Tony Li  wrote:

>
>
> On May 24, 2021, at 8:39 AM, Anoop Ghanwani  wrote:
>
> I thought that it might help operators and vendors think about
> these components.
>
>
>
>
> I would have no objection to simply enumerating the possibilities and
> noting the consistency requirement.
>
> Tony
>
>
>
> On Mon, May 24, 2021 at 8:33 AM Tony Li  wrote:
>
>>
>>
>> On May 24, 2021, at 8:27 AM, Anoop Ghanwani 
>> wrote:
>>
>> I think it might be a good idea if the draft mentioned what delay(s)
>> "SHOULD" be used.
>>
>>
>> Why?
>>
>> It seems like this is local to a domain. The network administrator is
>> free to do as he sees fit and include whatever parameters make sense to
>> them. As long as the network is self-consistent, that should operate
>> correctly.
>>
>> Tony
>>
>>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tony Li]

> On May 24, 2021, at 8:39 AM, Anoop Ghanwani  wrote:
> 
> I thought that it might help operators and vendors think about these 
> components.



I would have no objection to simply enumerating the possibilities and noting 
the consistency requirement.

Tony


> 
> On Mon, May 24, 2021 at 8:33 AM Tony Li  > wrote:
> 
> 
>> On May 24, 2021, at 8:27 AM, Anoop Ghanwani > > wrote:
>> 
>> I think it might be a good idea if the draft mentioned what delay(s) 
>> "SHOULD" be used.
> 
> Why?
> 
> It seems like this is local to a domain. The network administrator is free to 
> do as he sees fit and include whatever parameters make sense to them. As long 
> as the network is self-consistent, that should operate correctly.
> 
> Tony
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Anoop Ghanwani]

I thought that it might help operators and vendors think about
these components.

On Mon, May 24, 2021 at 8:33 AM Tony Li  wrote:

>
>
> On May 24, 2021, at 8:27 AM, Anoop Ghanwani  wrote:
>
> I think it might be a good idea if the draft mentioned what delay(s)
> "SHOULD" be used.
>
>
> Why?
>
> It seems like this is local to a domain. The network administrator is free
> to do as he sees fit and include whatever parameters make sense to them. As
> long as the network is self-consistent, that should operate correctly.
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tony Li]

> On May 24, 2021, at 8:27 AM, Anoop Ghanwani  wrote:
> 
> I think it might be a good idea if the draft mentioned what delay(s) "SHOULD" 
> be used.

Why?

It seems like this is local to a domain. The network administrator is free to 
do as he sees fit and include whatever parameters make sense to them. As long 
as the network is self-consistent, that should operate correctly.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Anoop Ghanwani]

The part that Chris mentioned (transmission delay) doesn't depend on speed
of light or cable length; it only depends on link speed.
The part that you mentioned (propagation delay) depends only on cable
length and speed of light in that medium and is independent of link speed.

Typically, the speed of light in fiber is estimated to be around 2x10^8
m/sec.

There's also packet processing delay which I mentioned in my other email
and queueing delay which I forgot to mention.

I think it might be a good idea if the draft mentioned what delay(s)
"SHOULD" be used.

On Mon, May 24, 2021 at 4:10 AM Acee Lindem (acee)  wrote:

>
>
> On 5/23/21, 9: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.
>
> 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=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  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]
> >
> >
> >
> >
> >
> > 

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

On 5/23/21, 9: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.

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=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  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
>
>

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

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 
  

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

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



[Ex

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> 
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<mailto:40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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<mailto: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> 
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<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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 ca

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> 
> 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 <mailto:40cisco@dmarc.ietf.org>; 
> lsr@ietf.org <mailto:lsr@ietf.org>; draft-hegde-lsr-flex-algo-bw-...@ietf.org 
> <mailto: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
>  
> <mailto: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> 
> 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 <mailto:acee=40cisco@dmarc.ietf.org>; 
> lsr@ietf.org <mailto:lsr@ietf.org>; draft-hegde-lsr-flex-algo-bw-...@ietf.org 
> <mailto: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 

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

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 Aijun,

>>> [WAJ] The operator must plan carefully for the metric assignment 
>>> accordingly to their specific topology to let the traffic pass the 
>>> necessary high bandwidth path as done in the following example.
>> 
>> 
>> That’s only if they have no concerns about the hop count.
> [WAJ] Hop count have little influence on the application performance. Nearly 
> every router can forward traffic in line speed as declared by every device 
> vendor?


Yes, but hop count has a significant impact on the bits * miles/km product that 
represents ISP cost.


>> Previous experience with other routing protocols that have a bandwidth based 
>> metric and do compute a cumulative metric does show that it is indeed 
>> possible to run many large networks this way and get
>> acceptable results.
> [WAJ] We prefer to the solution that can get determined results under various 
> scenarios, not just fit part of them.


There are no solutions that fit all scenarios. Otherwise, we would not have 
traffic engineering and interesting path computation.


 Hops are still relevant. An operator can adjust the reference bandwidth 
 and add manual metrics to achieve different effects, depending on their 
 precise needs.
>>> [WAJ] Is it more simple and easy to get determined results via setting the 
>>> link metric based on the additive information?
>> 
>> 
>> I don’t understand what you’re asking.
> [WAJ] For example, if we set the metric based on the distance between two 
> nodes, we can certainly say that the best path will have the shortest E2E 
> distance; if we set the metric based on the link delay, we can assure the 
> traffic will be forwarded in least delay path. 
> But if we set the metric based on the link bandwidth, I think you cannot 
> assure the E2E traffic will always pass the expected high bandwidth path. Is 
> it right?



Not per the current formulation, but then that’s not what we’re after.



>> Please remember that we are not trying to solve all problems for all people. 
>> We are trying to provide tools so that operators can drive traffic 
>> automatically in the way that they want. We’re trying to provide a variety 
>> of tools, with appropriate nerd knobs so that we can do useful traffic 
>> engineering without resorting to the very big hammer of having a centralized 
>> controller compute everything and program the entire network.
> 
> [WAJ] My observation is that the operator will need more judgment works in 
> their centralized controller to utilize such tools, especially in some 
> complex topology (because you need even manual intervention in some common 
> topology scenarios)
> I am also prefer to more automatic work been done in distributed manner. But 
> shouldn’t such work/tools get determined expected results automatically even 
> in some simple topology?



As I alluded to previously, bandwidth based metrics that have some respect for 
hop count have been found to be automatically helpful in MANY, MANY, MANY 
networks in previous routing protocols.  Perhaps one of my competitors would be 
willing to say the name that I am unable to mention.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Tony:

Aijun Wang
China Telecom

> On May 22, 2021, at 07:35, Tony Li  wrote:
> 
> 
> Hi Aijun,
> 
>> [WAJ] The operator must plan carefully for the metric assignment accordingly 
>> to their specific topology to let the traffic pass the necessary high 
>> bandwidth path as done in the following example.
> 
> 
> That’s only if they have no concerns about the hop count.
[WAJ] Hop count have little influence on the application performance. Nearly 
every router can forward traffic in line speed as declared by every device 
vendor?
> 
> Previous experience with other routing protocols that have a bandwidth based 
> metric and do compute a cumulative metric does show that it is indeed 
> possible to run many large networks this way and get
> acceptable results.
[WAJ] We prefer to the solution that can get determined results under various 
scenarios, not just fit part of them.

> 
> 
>> [WAJ] If such work must be done manually, it certainly weaken the necessary 
>> of the automatic metric calculations based on link bandwidth, also the 
>> introduction of bandwidth metric.
> 
> 
> In many cases, that’s probably not necessary.
> 
> 
>>> The point of the bandwidth metric (at least in this incarnation) is not to 
>>> make hop count irrelevant. It is to set the metrics relative to the 
>>> bandwidth so that traffic skews towards higher bandwidths.
>> 
>> [WAJ] This can be done via the “bandwidth constraints sub TLV” that is 
>> introduced in this document.
> 
> 
> No, that alone would exclude the hop count, resulting in a different path 
> computation.
> 
> 
>>> Hops are still relevant. An operator can adjust the reference bandwidth and 
>>> add manual metrics to achieve different effects, depending on their precise 
>>> needs.
>> [WAJ] Is it more simple and easy to get determined results via setting the 
>> link metric based on the additive information?
> 
> 
> I don’t understand what you’re asking.
[WAJ] For example, if we set the metric based on the distance between two 
nodes, we can certainly say that the best path will have the shortest E2E 
distance; if we set the metric based on the link delay, we can assure the 
traffic will be forwarded in least delay path. 
But if we set the metric based on the link bandwidth, I think you cannot assure 
the E2E traffic will always pass the expected high bandwidth path. Is it right?
> 
> Please remember that we are not trying to solve all problems for all people. 
> We are trying to provide tools so that operators can drive traffic 
> automatically in the way that they want. We’re trying to provide a variety of 
> tools, with appropriate nerd knobs so that we can do useful traffic 
> engineering without resorting to the very big hammer of having a centralized 
> controller compute everything and program the entire network.

[WAJ] My observation is that the operator will need more judgment works in 
their centralized controller to utilize such tools, especially in some complex 
topology (because you need even manual intervention in some common topology 
scenarios)
I am also prefer to more automatic work been done in distributed manner. But 
shouldn’t such work/tools get determined expected results automatically even in 
some simple topology?

> 
> Tonny
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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 Aijun,

> [WAJ] The operator must plan carefully for the metric assignment accordingly 
> to their specific topology to let the traffic pass the necessary high 
> bandwidth path as done in the following example.


That’s only if they have no concerns about the hop count.

Previous experience with other routing protocols that have a bandwidth based 
metric and do compute a cumulative metric does show that it is indeed possible 
to run many large networks this way and get
acceptable results.


> [WAJ] If such work must be done manually, it certainly weaken the necessary 
> of the automatic metric calculations based on link bandwidth, also the 
> introduction of bandwidth metric.


In many cases, that’s probably not necessary.


>> The point of the bandwidth metric (at least in this incarnation) is not to 
>> make hop count irrelevant. It is to set the metrics relative to the 
>> bandwidth so that traffic skews towards higher bandwidths.
> 
> [WAJ] This can be done via the “bandwidth constraints sub TLV” that is 
> introduced in this document.


No, that alone would exclude the hop count, resulting in a different path 
computation.


>> Hops are still relevant. An operator can adjust the reference bandwidth and 
>> add manual metrics to achieve different effects, depending on their precise 
>> needs.
> [WAJ] Is it more simple and easy to get determined results via setting the 
> link metric based on the additive information?


I don’t understand what you’re asking.

Please remember that we are not trying to solve all problems for all people. We 
are trying to provide tools so that operators can drive traffic automatically 
in the way that they want. We’re trying to provide a variety of tools, with 
appropriate nerd knobs so that we can do useful traffic engineering without 
resorting to the very big hammer of having a centralized controller compute 
everything and program the entire network.

Tonny


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Gyan:

Aijun Wang
China Telecom

> On May 22, 2021, at 06:59, Gyan Mishra  wrote:
> 
> 
> Aijun 
> 
> This is a similar concept to what exists today with most vendors CLI 
> configured reference bandwidth that can be overridden by manual metrics link 
> by link to skew traffic to avoid bottle necks, but now applying that same 
> concept that has existed historically to Flex Algo  new “bandwidth metric” 
> static generic metric TLV and new automatic reference bandwidth based metric. 
>  
[WAJ] Yes, I know.  But the reality is that we rarely use such bandwidth based 
automatic metric assignments method because it can’t get the determined results 
as we expected. For example, if two links between the one node pair has 
different bandwidth, the lower bandwidth link will be not utilized at all.
There may exist other issues in large complex network. The operator must take 
care of each possible unexpected scenario manually.
> 
> With this algorithm change the issue that has existed with IGP ECMP parallel 
> links is that they are all treated as individual and so the total group 
> bandwidth is not taken into account. 
[WAJ] But in some situations, especially the high bandwidth path has multiple 
hops than the low bandwidth path, the operator must intervene manually to 
change the automatic obtained bandwidth metric to achieve the expected results, 
as also agree with Tony in our discussed example.
Will you bother yourself for knob?

> So this is a major benefit to now being incorporated into Flex Algo.   Also 
> the concept of being able to exclude links based on minimum bandwidth is as 
> well a benefit so traffic is skewed to the higher bandwidth links.  
[WAJ] Yes, I agree with the introduction of minimum bandwidth constraints in 
Flex-Algorithm, but not the bandwidth metric.
> 
> This is basically another option for operators using Flex Algo in the 
> operators toolbox.
> 
> Kind Regards 
> 
> Gyan
> 
> On Fri, May 21, 2021 at 6:40 PM Tony Li  wrote:
>> 
>> Hi Aijun,
>> 
> With the introduce of additional constraint information, the problem 
> described in “Introduction” part(Section 1) can be solved.
 
 
 Please say more.  Claims without rationale are not reasoning.
>>> [WAJ]  The introduction part talks mainly how to divert the elephant 
>>> traffic away from the low bandwidth link. This can be achieved via the 
>>> introduction of additional constraints information for Flex-ALGO
>> 
>> 
>> Which is exactly what we’ve done: added bandwidth constraints. 
>> 
>> 
> The usage of bandwidth metric in large network is not feasible. 
 
>>> [WAJ] The main reason is that bandwidth metric is not cumulative.  
>> 
>> 
>> ??? What are you seeing that implies that?  That is not my understanding at 
>> all.
>> 
>> 
> And, would you like to explain more for the following statements(in 
> Section 4.1.1.2)
> “In the interface group mode, every node MUST identify the set of
>parallel links between a pair of nodes based on IGP link
>advertisements and MUST consider cumulative bandwidth of the parallel
>links while arriving at the metric of each link.”
> based on example described in Figure 7? 
 
 
 The paragraph immediately above explains exactly that. B->C has two 
 parallel 10Gbps links, so it should be considered to be 20Gbps.
 
  
> How the cumulative bandwidth will be used to achieve the result that 
> traffic from B to D will prefer B-C-F-D, not B-E-D? 
 
 
 B-C-F-D is 20Gbps. B-E-D is 10Gbps.
>>> 
>>> [WAJ] OK, let’s add two nodes between node B and C, say they are node M and 
>>> N. They have also two parallel links to B and C respectively. The two 
>>> possible path from B to D will be:
>>> Path 1: B-M-N-C-F-D
>>> Path 2: B-E-D
>>> If the “reference bandwidth” is 100G, then metric for each link in 
>>> B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1 
>>> “B—N-C-F-D” will be 25, right?
>>> The metric for each link in B-E-D will be 10, the cumulative metric from 
>>> B-D for Path 2 will be 20, right?
>>> How can you prefer to the high bandwidth path?
>> 
>> 
>> Override the metric on B-E-D to be even higher.
>> 
>> The point of the bandwidth metric (at least in this incarnation) is not to 
>> make hop count irrelevant. It is to set the metrics relative to the 
>> bandwidth so that traffic skews towards higher bandwidths. Hops are still 
>> relevant. An operator can adjust the reference bandwidth and add manual 
>> metrics to achieve different effects, depending on their precise needs.
>> 
>> Tony
>> 
>> 
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> -- 
> 
> 
> Gyan Mishra
> Network Solutions Architect 
> Email gyan.s.mis...@verizon.com
> M 301 502-1347
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Gyan:

Aijun Wang
China Telecom

> On May 22, 2021, at 06:59, Gyan Mishra  wrote:
> 
> 
> 
> Aijun 
> 
> This is a similar concept to what exists today with most vendors CLI 
> configured reference bandwidth that can be overridden by manual metrics link 
> by link to skew traffic to avoid bottle necks, but now applying that same 
> concept that has existed historically to Flex Algo  new “bandwidth metric” 
> static generic metric TLV and new automatic reference bandwidth based metric. 
>  
[WAJ] Yes, I know.  But the reality is that we rarely use such bandwidth based 
automatic metric assignments method because it can’t get the determined results 
as we expected. For example, if two links between the one node pair has 
different bandwidth, the lower bandwidth link will be not utilized at all.
There may exist other issues in large complex network. The operator must take 
care of each possible unexpected scenario manually.
> 
> With this algorithm change the issue that has existed with IGP ECMP parallel 
> links is that they are all treated as individual and so the total group 
> bandwidth is not taken into account. 
[WAJ] But in some situations, especially the high bandwidth path has multiple 
hops than the low bandwidth path, the operator must intervene manually to 
change the automatic obtained bandwidth metric to achieve the expected results, 
as also agree with Tony in our discussed example.
Will you bother yourself for knob?

> So this is a major benefit to now being incorporated into Flex Algo.   Also 
> the concept of being able to exclude links based on minimum bandwidth is as 
> well a benefit so traffic is skewed to the higher bandwidth links.  
[WAJ] Yes, I agree with the introduction of minimum bandwidth constraints in 
Flex-Algorithm, but not the bandwidth metric.
> 
> This is basically another option for operators using Flex Algo in the 
> operators toolbox.
> 
> Kind Regards 
> 
> Gyan
> 
>> On Fri, May 21, 2021 at 6:40 PM Tony Li  wrote:
>> 
>> Hi Aijun,
>> 
> With the introduce of additional constraint information, the problem 
> described in “Introduction” part(Section 1) can be solved.
 
 
 Please say more.  Claims without rationale are not reasoning.
>>> [WAJ]  The introduction part talks mainly how to divert the elephant 
>>> traffic away from the low bandwidth link. This can be achieved via the 
>>> introduction of additional constraints information for Flex-ALGO
>> 
>> 
>> Which is exactly what we’ve done: added bandwidth constraints. 
>> 
>> 
> The usage of bandwidth metric in large network is not feasible. 
 
>>> [WAJ] The main reason is that bandwidth metric is not cumulative.  
>> 
>> 
>> ??? What are you seeing that implies that?  That is not my understanding at 
>> all.
>> 
>> 
> And, would you like to explain more for the following statements(in 
> Section 4.1.1.2)
> “In the interface group mode, every node MUST identify the set of
>parallel links between a pair of nodes based on IGP link
>advertisements and MUST consider cumulative bandwidth of the parallel
>links while arriving at the metric of each link.”
> based on example described in Figure 7? 
 
 
 The paragraph immediately above explains exactly that. B->C has two 
 parallel 10Gbps links, so it should be considered to be 20Gbps.
 
  
> How the cumulative bandwidth will be used to achieve the result that 
> traffic from B to D will prefer B-C-F-D, not B-E-D? 
 
 
 B-C-F-D is 20Gbps. B-E-D is 10Gbps.
>>> 
>>> [WAJ] OK, let’s add two nodes between node B and C, say they are node M and 
>>> N. They have also two parallel links to B and C respectively. The two 
>>> possible path from B to D will be:
>>> Path 1: B-M-N-C-F-D
>>> Path 2: B-E-D
>>> If the “reference bandwidth” is 100G, then metric for each link in 
>>> B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1 
>>> “B—N-C-F-D” will be 25, right?
>>> The metric for each link in B-E-D will be 10, the cumulative metric from 
>>> B-D for Path 2 will be 20, right?
>>> How can you prefer to the high bandwidth path?
>> 
>> 
>> Override the metric on B-E-D to be even higher.
>> 
>> The point of the bandwidth metric (at least in this incarnation) is not to 
>> make hop count irrelevant. It is to set the metrics relative to the 
>> bandwidth so that traffic skews towards higher bandwidths. Hops are still 
>> relevant. An operator can adjust the reference bandwidth and add manual 
>> metrics to achieve different effects, depending on their precise needs.
>> 
>> Tony
>> 
>> 
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> -- 
> 
> 
> Gyan Mishra
> Network Solutions Architect 
> Email gyan.s.mis...@verizon.com
> M 301 502-1347
> 
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Tony:

Aijun Wang
China Telecom

> On May 22, 2021, at 06:40, Tony Li  wrote:
> 
> 
> 
> Hi Aijun,
> 
 With the introduce of additional constraint information, the problem 
 described in “Introduction” part(Section 1) can be solved.
>>> 
>>> 
>>> Please say more.  Claims without rationale are not reasoning.
>> [WAJ]  The introduction part talks mainly how to divert the elephant traffic 
>> away from the low bandwidth link. This can be achieved via the introduction 
>> of additional constraints information for Flex-ALGO
> 
> 
> Which is exactly what we’ve done: added bandwidth constraints. 

[WAJ] Yes, I agree with this.

> 
> 
 The usage of bandwidth metric in large network is not feasible. 
>>> 
>> [WAJ] The main reason is that bandwidth metric is not cumulative.  
> 
> 
> ??? What are you seeing that implies that?  That is not my understanding at 
> all.

[WAJ] The operator must plan carefully for the metric assignment accordingly to 
their specific topology to let the traffic pass the necessary high bandwidth 
path as done in the following example.

> 
> 
 And, would you like to explain more for the following statements(in 
 Section 4.1.1.2)
 “In the interface group mode, every node MUST identify the set of
parallel links between a pair of nodes based on IGP link
advertisements and MUST consider cumulative bandwidth of the parallel
links while arriving at the metric of each link.”
 based on example described in Figure 7? 
>>> 
>>> 
>>> The paragraph immediately above explains exactly that. B->C has two 
>>> parallel 10Gbps links, so it should be considered to be 20Gbps.
>>> 
>>>  
 How the cumulative bandwidth will be used to achieve the result that 
 traffic from B to D will prefer B-C-F-D, not B-E-D? 
>>> 
>>> 
>>> B-C-F-D is 20Gbps. B-E-D is 10Gbps.
>> 
>> [WAJ] OK, let’s add two nodes between node B and C, say they are node M and 
>> N. They have also two parallel links to B and C respectively. The two 
>> possible path from B to D will be:
>> Path 1: B-M-N-C-F-D
>> Path 2: B-E-D
>> If the “reference bandwidth” is 100G, then metric for each link in 
>> B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1 “B—N-C-F-D” 
>> will be 25, right?
>> The metric for each link in B-E-D will be 10, the cumulative metric from B-D 
>> for Path 2 will be 20, right?
>> How can you prefer to the high bandwidth path?
> 
> 
> Override the metric on B-E-D to be even higher.

[WAJ] If such work must be done manually, it certainly weaken the necessary of 
the automatic metric calculations based on link bandwidth, also the 
introduction of bandwidth metric.

> 
> The point of the bandwidth metric (at least in this incarnation) is not to 
> make hop count irrelevant. It is to set the metrics relative to the bandwidth 
> so that traffic skews towards higher bandwidths.

[WAJ] This can be done via the “bandwidth constraints sub TLV” that is 
introduced in this document.

> Hops are still relevant. An operator can adjust the reference bandwidth and 
> add manual metrics to achieve different effects, depending on their precise 
> needs.
[WAJ] Is it more simple and easy to get determined results via setting the link 
metric based on the additive information?
> 
> Tony
> 
> 
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Aijun

This is a similar concept to what exists today with most vendors CLI
configured reference bandwidth that can be overridden by manual metrics
link by link to skew traffic to avoid bottle necks, but now applying that
same concept that has existed historically to Flex Algo  new “bandwidth
metric” static generic metric TLV and new automatic reference bandwidth
based metric.

With this algorithm change the issue that has existed with IGP ECMP
parallel links is that they are all treated as individual and so the total
group bandwidth is not taken into account.  So this is a major benefit to
now being incorporated into Flex Algo.   Also the concept of being able to
exclude links based on minimum bandwidth is as well a benefit so traffic is
skewed to the higher bandwidth links.

This is basically another option for operators using Flex Algo in the
operators toolbox.

Kind Regards

Gyan

On Fri, May 21, 2021 at 6:40 PM Tony Li  wrote:

>
> Hi Aijun,
>
> With the introduce of additional constraint information, the problem
> described in “Introduction” part(Section 1) can be solved.
>
>
>
> Please say more.  Claims without rationale are not reasoning.
>
> [WAJ]  The introduction part talks mainly how to divert the elephant
> traffic away from the low bandwidth link. This can be achieved via the
> introduction of additional constraints information for Flex-ALGO
>
>
>
> Which is exactly what we’ve done: added bandwidth constraints.
>
>
> The usage of bandwidth metric in large network is not feasible.
>
>
> [WAJ] The main reason is that bandwidth metric is not cumulative.
>
>
>
> ??? What are you seeing that implies that?  That is not my understanding
> at all.
>
>
> And, would you like to explain more for the following statements(in
> Section 4.1.1.2)
> “In the interface group mode, every node MUST identify the set of
>parallel links between a pair of nodes based on IGP link
>advertisements and MUST consider cumulative bandwidth of the parallel
>links while arriving at the metric of each link.”
> based on example described in Figure 7?
>
>
>
> The paragraph immediately above explains exactly that. B->C has two
> parallel 10Gbps links, so it should be considered to be 20Gbps.
>
>
>
> How the cumulative bandwidth will be used to achieve the result that
> traffic from B to D will prefer B-C-F-D, not B-E-D?
>
>
>
> B-C-F-D is 20Gbps. B-E-D is 10Gbps.
>
>
> [WAJ] OK, let’s add two nodes between node B and C, say they are node M
> and N. They have also two parallel links to B and C respectively. The two
> possible path from B to D will be:
> Path 1: B-M-N-C-F-D
> Path 2: B-E-D
> If the “reference bandwidth” is 100G, then metric for each link in
> B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1
> “B—N-C-F-D” will be 25, right?
> The metric for each link in B-E-D will be 10, the cumulative metric from
> B-D for Path 2 will be 20, right?
> How can you prefer to the high bandwidth path?
>
>
>
> Override the metric on B-E-D to be even higher.
>
> The point of the bandwidth metric (at least in this incarnation) is not to
> make hop count irrelevant. It is to set the metrics relative to the
> bandwidth so that traffic skews towards higher bandwidths. Hops are still
> relevant. An operator can adjust the reference bandwidth and add manual
> metrics to achieve different effects, depending on their precise needs.
>
> Tony
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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 Aijun,

>>> With the introduce of additional constraint information, the problem 
>>> described in “Introduction” part(Section 1) can be solved.
>> 
>> 
>> Please say more.  Claims without rationale are not reasoning.
> [WAJ]  The introduction part talks mainly how to divert the elephant traffic 
> away from the low bandwidth link. This can be achieved via the introduction 
> of additional constraints information for Flex-ALGO


Which is exactly what we’ve done: added bandwidth constraints. 


>>> The usage of bandwidth metric in large network is not feasible. 
>> 
> [WAJ] The main reason is that bandwidth metric is not cumulative.  


??? What are you seeing that implies that?  That is not my understanding at all.


>>> And, would you like to explain more for the following statements(in Section 
>>> 4.1.1.2)
>>> “In the interface group mode, every node MUST identify the set of
>>>parallel links between a pair of nodes based on IGP link
>>>advertisements and MUST consider cumulative bandwidth of the parallel
>>>links while arriving at the metric of each link.”
>>> based on example described in Figure 7? 
>> 
>> 
>> The paragraph immediately above explains exactly that. B->C has two parallel 
>> 10Gbps links, so it should be considered to be 20Gbps.
>> 
>>  
>>> How the cumulative bandwidth will be used to achieve the result that 
>>> traffic from B to D will prefer B-C-F-D, not B-E-D? 
>> 
>> 
>> B-C-F-D is 20Gbps. B-E-D is 10Gbps.
> 
> [WAJ] OK, let’s add two nodes between node B and C, say they are node M and 
> N. They have also two parallel links to B and C respectively. The two 
> possible path from B to D will be:
> Path 1: B-M-N-C-F-D
> Path 2: B-E-D
> If the “reference bandwidth” is 100G, then metric for each link in 
> B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1 “B—N-C-F-D” 
> will be 25, right?
> The metric for each link in B-E-D will be 10, the cumulative metric from B-D 
> for Path 2 will be 20, right?
> How can you prefer to the high bandwidth path?


Override the metric on B-E-D to be even higher.

The point of the bandwidth metric (at least in this incarnation) is not to make 
hop count irrelevant. It is to set the metrics relative to the bandwidth so 
that traffic skews towards higher bandwidths. Hops are still relevant. An 
operator can adjust the reference bandwidth and add manual metrics to achieve 
different effects, depending on their precise needs.

Tony



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Acee:
For adoption call of one document, you are counting the number of support 
votes, not to let the authors solve/explain the disputed part?
My understanding is that the WG Chairs should help to solve the controversial 
points, or make judgements based on his knowledges.

Aijun Wang
China Telecom

> On May 21, 2021, at 23:38, Acee Lindem (acee) 
>  wrote:
> 
> 
> Hi Tony, Aijun,
>  
> From: Tony Li  on behalf of Tony Li 
> Date: Friday, May 21, 2021 at 11:29 AM
> To: Aijun Wang 
> Cc: Acee Lindem , lsr , 
> "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
>  
>  
> Hi Aijun,
> 
> 
> I support the adoption of the “FAD constraint sub-TLV” part(Section 3),  but 
> not support the introduce of  “Bandwidth Metric Advertisement” part (Section 
> 4) and other related parts.
>  
>  
> As I understand it, we don’t get a line item veto, so I don’t know how the 
> chairs will take this.
>  
> As WG chair, I don’t see that Aijun’s concerns would prevent WG adoption. The 
> draft has plenty of support. The discussion can continue after adoption.
>  
> Thanks,
> Acee
>  
>  
> With the introduce of additional constraint information, the problem 
> described in “Introduction” part(Section 1) can be solved.
>  
>  
> Please say more.  Claims without rationale are not reasoning.
> 
> 
>  
> The usage of bandwidth metric in large network is not feasible. 
>  
>  
> Ditto.
>  
> 
> 
> And, would you like to explain more for the following statements(in Section 
> 4.1.1.2)
> “In the interface group mode, every node MUST identify the set of
>parallel links between a pair of nodes based on IGP link
>advertisements and MUST consider cumulative bandwidth of the parallel
>links while arriving at the metric of each link.”
> based on example described in Figure 7? 
>  
>  
> The paragraph immediately above explains exactly that. B->C has two parallel 
> 10Gbps links, so it should be considered to be 20Gbps.
> 
> 
>  
> How the cumulative bandwidth will be used to achieve the result that traffic 
> from B to D will prefer B-C-F-D, not B-E-D? 
>  
>  
> B-C-F-D is 20Gbps. B-E-D is 10Gbps.
>  
> Tony
>  
> ___
> 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

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

[Aijun Wang]

Hi, Tony:

Aijun Wang
China Telecom

> On May 21, 2021, at 23:29, Tony Li  wrote:
> 
> 
> 
> Hi Aijun,
> 
>> I support the adoption of the “FAD constraint sub-TLV” part(Section 3),  but 
>> not support the introduce of  “Bandwidth Metric Advertisement” part (Section 
>> 4) and other related parts.
> 
> 
> As I understand it, we don’t get a line item veto, so I don’t know how the 
> chairs will take this.

[WAJ] The reasonable solution is to take out of the controversial part from the 
adopted document.

> 
> 
>> With the introduce of additional constraint information, the problem 
>> described in “Introduction” part(Section 1) can be solved.
> 
> 
> Please say more.  Claims without rationale are not reasoning.
[WAJ]  The introduction part talks mainly how to divert the elephant traffic 
away from the low bandwidth link. This can be achieved via the introduction of 
additional constraints information for Flex-ALGO.
> 
>  
>> The usage of bandwidth metric in large network is not feasible. 
> 
[WAJ] The main reason is that bandwidth metric is not cumulative.  
> 
> Ditto.
> 
> 
>> And, would you like to explain more for the following statements(in Section 
>> 4.1.1.2)
>> “In the interface group mode, every node MUST identify the set of
>>parallel links between a pair of nodes based on IGP link
>>advertisements and MUST consider cumulative bandwidth of the parallel
>>links while arriving at the metric of each link.”
>> based on example described in Figure 7? 
> 
> 
> The paragraph immediately above explains exactly that. B->C has two parallel 
> 10Gbps links, so it should be considered to be 20Gbps.
> 
>  
>> How the cumulative bandwidth will be used to achieve the result that traffic 
>> from B to D will prefer B-C-F-D, not B-E-D? 
> 
> 
> B-C-F-D is 20Gbps. B-E-D is 10Gbps.

[WAJ] OK, let’s add two nodes between node B and C, say they are node M and N. 
They have also two parallel links to B and C respectively. The two possible 
path from B to D will be:
Path 1: B-M-N-C-F-D
Path 2: B-E-D
If the “reference bandwidth” is 100G, then metric for each link in B-M-N-C-F-D 
will be 5, the cumulative metric from B-D for Path 1 “B—N-C-F-D” will be 25, 
right?
The metric for each link in B-E-D will be 10, the cumulative metric from B-D 
for Path 2 will be 20, right?
How can you prefer to the high bandwidth path?


> 
> Tony
> 
> ___
> 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

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 Tony, Aijun,

From: Tony Li  on behalf of Tony Li 
Date: Friday, May 21, 2021 at 11:29 AM
To: Aijun Wang 
Cc: Acee Lindem , lsr , 
"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


Hi Aijun,


I support the adoption of the “FAD constraint sub-TLV” part(Section 3),  but 
not support the introduce of  “Bandwidth Metric Advertisement” part (Section 4) 
and other related parts.


As I understand it, we don’t get a line item veto, so I don’t know how the 
chairs will take this.

As WG chair, I don’t see that Aijun’s concerns would prevent WG adoption. The 
draft has plenty of support. The discussion can continue after adoption.

Thanks,
Acee


With the introduce of additional constraint information, the problem described 
in “Introduction” part(Section 1) can be solved.


Please say more.  Claims without rationale are not reasoning.



The usage of bandwidth metric in large network is not feasible.


Ditto.



And, would you like to explain more for the following statements(in Section 
4.1.1.2)
“In the interface group mode, every node MUST identify the set of
   parallel links between a pair of nodes based on IGP link
   advertisements and MUST consider cumulative bandwidth of the parallel
   links while arriving at the metric of each link.”
based on example described in Figure 7?


The paragraph immediately above explains exactly that. B->C has two parallel 
10Gbps links, so it should be considered to be 20Gbps.



How the cumulative bandwidth will be used to achieve the result that traffic 
from B to D will prefer B-C-F-D, not B-E-D?


B-C-F-D is 20Gbps. B-E-D is 10Gbps.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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 Aijun,

> I support the adoption of the “FAD constraint sub-TLV” part(Section 3),  but 
> not support the introduce of  “Bandwidth Metric Advertisement” part (Section 
> 4) and other related parts.


As I understand it, we don’t get a line item veto, so I don’t know how the 
chairs will take this.


> With the introduce of additional constraint information, the problem 
> described in “Introduction” part(Section 1) can be solved.


Please say more.  Claims without rationale are not reasoning.

 
> The usage of bandwidth metric in large network is not feasible. 


Ditto.


> And, would you like to explain more for the following statements(in Section 
> 4.1.1.2)
> “In the interface group mode, every node MUST identify the set of
>parallel links between a pair of nodes based on IGP link
>advertisements and MUST consider cumulative bandwidth of the parallel
>links while arriving at the metric of each link.”
> based on example described in Figure 7? 


The paragraph immediately above explains exactly that. B->C has two parallel 
10Gbps links, so it should be considered to be 20Gbps.

 
> How the cumulative bandwidth will be used to achieve the result that traffic 
> from B to D will prefer B-C-F-D, not B-E-D? 


B-C-F-D is 20Gbps. B-E-D is 10Gbps.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, 

I support the adoption of the “FAD constraint sub-TLV” part(Section 3),  but 
not support the introduce of  “Bandwidth Metric Advertisement” part (Section 4) 
and other related parts.

With the introduce of additional constraint information, the problem described 
in “Introduction” part(Section 1) can be solved.

 

The usage of bandwidth metric in large network is not feasible. 

And, would you like to explain more for the following statements(in Section 
4.1.1.2)

“In the interface group mode, every node MUST identify the set of

   parallel links between a pair of nodes based on IGP link

   advertisements and MUST consider cumulative bandwidth of the parallel

   links while arriving at the metric of each link.”

based on example described in Figure 7? 

 

How the cumulative bandwidth will be used to achieve the result that traffic 
from B to D will prefer B-C-F-D, not B-E-D? 

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

 

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 27th, 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

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

[Dongjie (Jimmy)]

Hi Shraddha,

Thanks for your further explanation.

I agree if operators design it properly, it could provide the desired result of 
excluding links whose maximum bandwidth is lower than the specified constraint.

As you said it is not related to the bandwidth management or reservation, thus 
it is more like a mechanism of relative static network planning, without 
considering the dynamics of the link bandwidth utilization.

I don't have further questions.

Best regards,
Jie

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Wednesday, May 19, 2021 6:42 PM
To: Dongjie (Jimmy) ; Acee Lindem (acee) 
; lsr@ietf.org
Cc: 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


>[Jie] I can understand how this works for a single Flex-Algo, while my 
>question was if more than one Flex-Algo use
>bandwidth as constraint to exclude some links, what would be the consequence 
>to the network?

Operators design and plan whether one flex-algo is suitable for their network 
or multiple. The planning also involves
the definition of each flex-algo that is suitable for their network. This 
network planning exercise has to be done
irrespective of whether bandwidth constraints are used in the flex-algo to 
ensure traffic distribution is even.

Rgds
Shraddha





Juniper Business Use Only
From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Wednesday, May 19, 2021 12:59 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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 reply. Please see further inline:

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Hi Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Hi authors,

I've read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?
Yes. Any application can make use of generic metric including 
Flex-algo and SR-TE.
  Sure. I'll add some text to clarify this.

[Jie] OK, thanks.



2.   The "Exclude Minimum Bandwidth" constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?
 The motivation for "Exclude Minimum Bandwidth" is to avoid low 
capacity links for the high band

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

[peng.shaofu]

Dear Acee, Tony,






Thanks!

Tony's explanation gives the essential use of bandwidth-metric. My previous 
understanding is mainly based on the problem to be solved in another draft 
https://datatracker.ietf.org/doc/draft-lp-lsr-fa-bandwidth/. Sorry to insert an 
advertisement in this adoption.  : ) 

In draft-lp, the path will be selected strictly according to the actual 
bandwidth capacity of the link. The main issue is that the computation method  
is not optimal, just a basic expression of this idea. 

Just for the expected requirement "to select a path with the maximum link 
bandwidth from the source node to the destination node", it seems that one 
scheme try to satisfy most of scenarios, and the other try to satisfy 100%.




Regards


PSF











原始邮件



发件人：AceeLindem(acee)
收件人：Tony Li;彭少富10053815;
抄送人：shrad...@juniper.net;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日 期 ：2021年05月20日 18:22
主 题 ：Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02




Speaking as WG member:


 


I agree with Tony.


 


Furthermore, the extensions in the draft provide mechanisms to constraint 
bandwidth beyond your concern that bandwidth be used as a cumulative metric. I 
support WG adoption.


 


Thanks,
 Acee


 



From: Tony Li  on behalf of Tony Li 
 Date: Thursday, May 20, 2021 at 12:20 AM
 To: "peng.sha...@zte.com.cn" 
 Cc: "shrad...@juniper.net" , Acee Lindem 
, "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



 


 


Hi Peng Shaofu,


 



 
 


On May 19, 2021, at 6:55 PM, peng.sha...@zte.com.cn wrote:



 


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, 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 ?




 



 


The whole point of the bandwidth metric (and indeed, of all of FlexAlgo) is to 
get a different path computation result than what we might get with the 
standard IGP metric. What it will do in any given topology is highly dependent 
on the topology, as you’ve seen.  It may or may not ‘work’ by whatever 
definition you have in mind. However, what matters is what the network operator 
is trying to achieve. It doesn’t have to work for every topology or every 
purpose.



 


Tony___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[peng.shaofu]

Hi Shraddha,






Thanks for your reply. I have no questions any more.






Regards,


PSF











原始邮件



发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日 期 ：2021年05月20日 12:17
主 题 ：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,


 


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 "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02




 


[External Email. Be cautious o

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

Speaking as WG member:

I agree with Tony.

Furthermore, the extensions in the draft provide mechanisms to constraint 
bandwidth beyond your concern that bandwidth be used as a cumulative metric. I 
support WG adoption.

Thanks,
Acee

From: Tony Li  on behalf of Tony Li 
Date: Thursday, May 20, 2021 at 12:20 AM
To: "peng.sha...@zte.com.cn" 
Cc: "shrad...@juniper.net" , Acee Lindem 
, "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


Hi Peng Shaofu,



On May 19, 2021, at 6:55 PM, 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn> wrote:

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, 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 ?


The whole point of the bandwidth metric (and indeed, of all of FlexAlgo) is to 
get a different path computation result than what we might get with the 
standard IGP metric. What it will do in any given topology is highly dependent 
on the topology, as you’ve seen.  It may or may not ‘work’ by whatever 
definition you have in mind. However, what matters is what the network operator 
is trying to achieve. It doesn’t have to work for every topology or every 
purpose.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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 Peng Shaofu,


> On May 19, 2021, at 6:55 PM, peng.sha...@zte.com.cn wrote:
> 
> 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, 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 ?


The whole point of the bandwidth metric (and indeed, of all of FlexAlgo) is to 
get a different path computation result than what we might get with the 
standard IGP metric. What it will do in any given topology is highly dependent 
on the topology, as you’ve seen.  It may or may not ‘work’ by whatever 
definition you have in mind. However, what matters is what the network operator 
is trying to achieve. It doesn’t have to work for every topology or every 
purpose.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Shraddha Hegde]

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<mailto: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> 
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<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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<mailto: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<mailto:peng.sha...@zte.com.cn> 
mailto:peng.sha...@zte.com.cn>>
Sent: Monday, May 17, 2021 7:40 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: acee=40cisco@dmarc.ietf.org<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and

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

[peng.shaofu]

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, 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 ?






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

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

[Shraddha Hegde]

>[Jie] I can understand how this works for a single Flex-Algo, while my 
>question was if more than one Flex-Algo use
>bandwidth as constraint to exclude some links, what would be the consequence 
>to the network?

Operators design and plan whether one flex-algo is suitable for their network 
or multiple. The planning also involves
the definition of each flex-algo that is suitable for their network. This 
network planning exercise has to be done
irrespective of whether bandwidth constraints are used in the flex-algo to 
ensure traffic distribution is even.

Rgds
Shraddha





Juniper Business Use Only
From: Dongjie (Jimmy) 
Sent: Wednesday, May 19, 2021 12:59 PM
To: Shraddha Hegde ; Acee Lindem (acee) 
; lsr@ietf.org
Cc: 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 reply. Please see further inline:

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Hi Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Hi authors,

I've read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?
Yes. Any application can make use of generic metric including 
Flex-algo and SR-TE.
  Sure. I'll add some text to clarify this.

[Jie] OK, thanks.



2.   The "Exclude Minimum Bandwidth" constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?
 The motivation for "Exclude Minimum Bandwidth" is to avoid low 
capacity links for the high bandwidth traffic. For example if the Flex-algo 128 
carries high bw traffic flows of bw greater than 10g, it makes sense to remove 
1g links from this flex-algo topology since these links if happen to carry 
traffic, it  will get congested and traffic will be dropped. The introduction 
section talks about this motivation.

[Jie] I can understand how this works for a single Flex-Algo, while my question 
was if more than one Flex-Algo use bandwidth as constraint to exclude some 
links, what would be the consequence to the network?





Perhaps a more general question is, what would be the benefit of introducing 
bandwidth attribute into Flex-Algo based distributed path computation?  It is 
known that bandwidth can be used in centralized computation for efficient path 
placement and resource management, can distributed computation with bandwidth 
constraint achieve the same, or is there some advantages compared with 
centralized computation?

 Many network operators assign link metric relative to bandwidth of 
the link and it is 

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

[Dongjie (Jimmy)]

Hi Shraddha,

Thanks for your reply. Please see further inline:

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Hi Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Hi authors,

I've read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?
Yes. Any application can make use of generic metric including 
Flex-algo and SR-TE.
  Sure. I'll add some text to clarify this.

[Jie] OK, thanks.



2.   The "Exclude Minimum Bandwidth" constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?
 The motivation for "Exclude Minimum Bandwidth" is to avoid low 
capacity links for the high bandwidth traffic. For example if the Flex-algo 128 
carries high bw traffic flows of bw greater than 10g, it makes sense to remove 
1g links from this flex-algo topology since these links if happen to carry 
traffic, it  will get congested and traffic will be dropped. The introduction 
section talks about this motivation.

[Jie] I can understand how this works for a single Flex-Algo, while my question 
was if more than one Flex-Algo use bandwidth as constraint to exclude some 
links, what would be the consequence to the network?





Perhaps a more general question is, what would be the benefit of introducing 
bandwidth attribute into Flex-Algo based distributed path computation?  It is 
known that bandwidth can be used in centralized computation for efficient path 
placement and resource management, can distributed computation with bandwidth 
constraint achieve the same, or is there some advantages compared with 
centralized computation?

 Many network operators assign link metric relative to bandwidth of 
the link and it is an existing practice. The draft is defining new attributes 
and constraints in order to simplify and automate this process.

It does not propose any bandwidth reservation/ bandwidth management solutions 
that a centralized computation or distributed RSVP based solutions provide.



[Jie] OK it is clear that this mechanism will not replace the centralized 
bandwidth computation or distributed bandwidth reservation solutions.  While if 
the purpose is just to simplify and automate the metric configuration process, 
, it seems the gain is relatively limited?





3.   With the automatic metric calculation, it could introduce per 
Flex-Algo link metric value, while the existing Flex-Algo only refers to the 
metric of the link via metric type. Is this the expected behavior? Will it be 
further extended to make other link attributes flex-algo specific?



4.   In the reference bandwidth method, the draft says it simplifies the 
management in case the reference bandwidt

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

[Shraddha Hegde]

Hi Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) 
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) ; Acee Lindem (acee) 
; lsr@ietf.org
Cc: 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]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

Hi authors,

I've read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?
Yes. Any application can make use of generic metric including 
Flex-algo and SR-TE.
  Sure. I'll add some text to clarify this.


2.   The "Exclude Minimum Bandwidth" constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?
 The motivation for "Exclude Minimum Bandwidth" is to avoid low 
capacity links for the high bandwidth traffic. For example if the Flex-algo 128 
carries high bw traffic flows of bw greater than 10g, it makes sense to remove 
1g links from this flex-algo topology since these links if happen to carry 
traffic, it  will get congested and traffic will be dropped. The introduction 
section talks about this motivation.



Perhaps a more general question is, what would be the benefit of introducing 
bandwidth attribute into Flex-Algo based distributed path computation?  It is 
known that bandwidth can be used in centralized computation for efficient path 
placement and resource management, can distributed computation with bandwidth 
constraint achieve the same, or is there some advantages compared with 
centralized computation?

 Many network operators assign link metric relative to bandwidth of 
the link and it is an existing practice. The draft is defining new attributes 
and constraints in order to simplify and automate this process.

It does not propose any bandwidth reservation/ bandwidth management solutions 
that a centralized computation or distributed RSVP based solutions provide.



3.   With the automatic metric calculation, it could introduce per 
Flex-Algo link metric value, while the existing Flex-Algo only refers to the 
metric of the link via metric type. Is this the expected behavior? Will it be 
further extended to make other link attributes flex-algo specific?



4.   In the reference bandwidth method, the draft says it simplifies the 
management in case the reference bandwidth needs to be changed. Since the 
reference bandwidth applies to the metric calculation of all the links in the 
flex-algo with the same proportion, it seems the change of the reference 
bandwidth will not impact the result of the path computation in the flex-algo. 
In which case the reference bandwidth need to be changed?
 Lets take a hypothetical example. Lets say a network starts with all 
1G links and 10G reference bw.
Over the years, many links get upgraded to 10G links and some get upgraded to 
100G links. Using a 10G reference bandwidth will not be feasible and reference 
bw need to get increased to a value > 100G.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

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/<https://urldefense.com/

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

[Shraddha Hegde]

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<mailto: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<mailto:peng.sha...@zte.com.cn> 
mailto:peng.sha...@zte.com.cn>>
Sent: Monday, May 17, 2021 7:40 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: acee=40cisco@dmarc.ietf.org<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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<mailto: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<mailto:peng.sha...@zte.com.cn> 
mailto:peng.sha...@zte.com.cn>>
Sent: Thursday, May 13, 2021 1:05 PM
To: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Cc: acee=40cisco@dmarc.ietf.org<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf

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

[Dongjie (Jimmy)]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) ; lsr@ietf.org
Cc: 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

Hi authors,

I’ve read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?


2.   The “Exclude Minimum Bandwidth” constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?



Perhaps a more general question is, what would be the benefit of introducing 
bandwidth attribute into Flex-Algo based distributed path computation?  It is 
known that bandwidth can be used in centralized computation for efficient path 
placement and resource management, can distributed computation with bandwidth 
constraint achieve the same, or is there some advantages compared with 
centralized computation?



3.   With the automatic metric calculation, it could introduce per 
Flex-Algo link metric value, while the existing Flex-Algo only refers to the 
metric of the link via metric type. Is this the expected behavior? Will it be 
further extended to make other link attributes flex-algo specific?



4.   In the reference bandwidth method, the draft says it simplifies the 
management in case the reference bandwidth needs to be changed. Since the 
reference bandwidth applies to the metric calculation of all the links in the 
flex-algo with the same proportion, it seems the change of the reference 
bandwidth will not impact the result of the path computation in the flex-algo. 
In which case the reference bandwidth need to be changed?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

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 27th, 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

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

[peng.shaofu]

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

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

[Shraddha Hegde]

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 "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<mailto: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<mailto:peng.sha...@zte.com.cn> 
mailto:peng.sha...@zte.com.cn>>
Sent: Thursday, May 13, 2021 1:05 PM
To: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Cc: acee=40cisco@dmarc.ietf.org<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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<mailto:lsr@ietf.org>;
抄送人：draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsL6l_0sA$>
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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsET5yKGD$>

Please indicate your support or objection by May 27th, 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

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

[peng.shaofu]

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  
 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 27th, 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

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

[Dongjie (Jimmy)]

Hi Peter, 

Thanks for your reply, please see inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, May 14, 2021 5:12 PM
> To: Dongjie (Jimmy) ; Acee Lindem (acee)
> ; lsr@ietf.org
> Cc: 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
> 
> Hi Jie,
> 
> please see the response for one of your questions inline:
> 
> On 14/05/2021 09:52, Dongjie (Jimmy) wrote:
> > Hi authors,
> >
> > I’ve read the latest version of this document and have the following
> > comments:
> >
> > 1.Is the generic metric type applicable to applications other than
> > Flex-Algo? If so, it is better to make this clear in the document, or
> > perhaps it may be defined separately from the Flex-Algo specific extensions?
> >
> > 2.The “Exclude Minimum Bandwidth” constraint is compared with the
> > maximum link bandwidth to exclude the links from the computation, it
> > would be helpful if there is some analysis about how much this can
> > help in traffic engineering, such as to reduce the congestion or
> > improve the link utilization. One simple example is, if multiple
> > Flex-Algos use this constraint to exclude the same set of links, this
> > may increase the possibility of congestion on the rest of the links?
> >
> > Perhaps a more general question is, what would be the benefit of
> > introducing bandwidth attribute into Flex-Algo based distributed path
> > computation?  It is known that bandwidth can be used in centralized
> > computation for efficient path placement and resource management, can
> > distributed computation with bandwidth constraint achieve the same, or
> > is there some advantages compared with centralized computation?
> >
> > 3.With the automatic metric calculation, it could introduce per
> > Flex-Algo link metric value, while the existing Flex-Algo only refers
> > to the metric of the link via metric type. Is this the expected behavior?
> > Will it be further extended to make other link attributes flex-algo
> > specific?
> 
> we need to distinguish between:
> 
> a) flex-algo application specific metric (applies to all flex-algos)
> b) flex-algo X specific metric

Yes, here I mean flex-algo number specific metric.

> 
> (a) already exists in the form of the ASLA advertisement for delay and 
> TE-metric.
> Bandwidth metric will be no different.
> 
> (b) there has been no such thing as flex-algo X specific metric/attribute 
> defined
> so far. And we are not defining it in this draft either. The draft defines 
> sub-TLVs
> for automatic bandwidth metric calculation. It is the winning FAD for the
> Flex-Algorithm X that specifies whether the automatic bandwidth metric
> calculation is done or not and it would be rather complicated (certainly 
> possible)
> to have the parameters for such calculation being advertised outside of the
> FAD.
> 
> You are right these being part of the FAD may result in the calculated 
> bandwidth
> metric being different for each flex-algo on the same link.
> The intention was NOT to have the different per algo bandwidth metric value,
> rather it was the convenience of reusing the FAD that was the motivation for
> the existing encoding.

Understood. Perhaps some text to clarify this would be helpful, such as:

The reference bandwidth is considered a global parameter for the network, it is 
not expected to use different reference bandwidth for different flex-algos.

> 
> So to answer your question, we do NOT intend to make any link attributes per
> flex-algo number.

This answer is clear, thanks.

Best regards,
Jie

> 
> thanks,
> Peter
> 
> 
> 
> 
> >
> > 4.In the reference bandwidth method, the draft says it simplifies the
> > management in case the reference bandwidth needs to be changed. Since
> > the reference bandwidth applies to the metric calculation of all the
> > links in the flex-algo with the same proportion, it seems the change
> > of the reference bandwidth will not impact the result of the path
> > computation in the flex-algo. In which case the reference bandwidth
> > need to be changed?
> >
> > Best regards,
> >
> > Jie
> >
> > *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
> > (acee)
> > *Sent:* Thursday, May 13, 2021 5:09 AM
> > *To:* lsr@ietf.org
> > *Cc:* draft-hegde-lsr-flex-algo-bw-...@ietf.org
> > *Subject:* [Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> > Bandwidth, Delay, Metrics and Constrai

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

[Peter Psenak]

Hi Jie,

please see the response for one of your questions inline:

On 14/05/2021 09:52, Dongjie (Jimmy) wrote:

Hi authors,

I’ve read the latest version of this document and have the following 
comments:


1.Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or 
perhaps it may be defined separately from the Flex-Algo specific extensions?


2.The “Exclude Minimum Bandwidth” constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it 
would be helpful if there is some analysis about how much this can help 
in traffic engineering, such as to reduce the congestion or improve the 
link utilization. One simple example is, if multiple Flex-Algos use this 
constraint to exclude the same set of links, this may increase the 
possibility of congestion on the rest of the links?


Perhaps a more general question is, what would be the benefit of 
introducing bandwidth attribute into Flex-Algo based distributed path 
computation?  It is known that bandwidth can be used in centralized 
computation for efficient path placement and resource management, can 
distributed computation with bandwidth constraint achieve the same, or 
is there some advantages compared with centralized computation?


3.With the automatic metric calculation, it could introduce per 
Flex-Algo link metric value, while the existing Flex-Algo only refers to 
the metric of the link via metric type. Is this the expected behavior? 
Will it be further extended to make other link attributes flex-algo 
specific?


we need to distinguish between:

a) flex-algo application specific metric (applies to all flex-algos)
b) flex-algo X specific metric

(a) already exists in the form of the ASLA advertisement for delay and 
TE-metric. Bandwidth metric will be no different.


(b) there has been no such thing as flex-algo X specific 
metric/attribute defined so far. And we are not defining it in this 
draft either. The draft defines sub-TLVs for automatic bandwidth metric 
calculation. It is the winning FAD for the Flex-Algorithm X that 
specifies whether the automatic bandwidth metric calculation is done or 
not and it would be rather complicated (certainly possible) to have the 
parameters for such calculation being advertised outside of the FAD.


You are right these being part of the FAD may result in the calculated 
bandwidth metric being different for each flex-algo on the same link. 
The intention was NOT to have the different per algo bandwidth metric 
value, rather it was the convenience of reusing the FAD that was the 
motivation for the existing encoding.


So to answer your question, we do NOT intend to make any link attributes 
per flex-algo number.


thanks,
Peter






4.In the reference bandwidth method, the draft says it simplifies the 
management in case the reference bandwidth needs to be changed. Since 
the reference bandwidth applies to the metric calculation of all the 
links in the flex-algo with the same proportion, it seems the change of 
the reference bandwidth will not impact the result of the path 
computation in the flex-algo. In which case the reference bandwidth need 
to be changed?


Best regards,

Jie

*From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem (acee)
*Sent:* Thursday, May 13, 2021 5:09 AM
*To:* lsr@ietf.org
*Cc:* draft-hegde-lsr-flex-algo-bw-...@ietf.org
*Subject:* [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: 
Bandwidth, Delay, Metrics and Constraints" - 
draft-hegde-lsr-flex-algo-bw-con-02


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

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

[Dongjie (Jimmy)]

Hi authors,

I’ve read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?


2.   The “Exclude Minimum Bandwidth” constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?



Perhaps a more general question is, what would be the benefit of introducing 
bandwidth attribute into Flex-Algo based distributed path computation?  It is 
known that bandwidth can be used in centralized computation for efficient path 
placement and resource management, can distributed computation with bandwidth 
constraint achieve the same, or is there some advantages compared with 
centralized computation?



3.   With the automatic metric calculation, it could introduce per 
Flex-Algo link metric value, while the existing Flex-Algo only refers to the 
metric of the link via metric type. Is this the expected behavior? Will it be 
further extended to make other link attributes flex-algo specific?



4.   In the reference bandwidth method, the draft says it simplifies the 
management in case the reference bandwidth needs to be changed. Since the 
reference bandwidth applies to the metric calculation of all the links in the 
flex-algo with the same proportion, it seems the change of the reference 
bandwidth will not impact the result of the path computation in the flex-algo. 
In which case the reference bandwidth need to be changed?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

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 27th, 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

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

[Lizhenbin]

Hi All,
I support the WG adoption.

Best Regards,
Zhenbin (Robin)




--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com
发件人：Acee Lindem (acee) 
收件人：lsr 
抄 送：draft-hegde-lsr-flex-algo-bw-con 
时 间：2021-05-13 06:14:57
主 题：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

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 27th, 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

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

[Ron Bonica]

Support




Juniper Business Use Only
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, May 12, 2021 5:09 PM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: [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]

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 27th, 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

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

[Tony Li]

Support as co-author.

I am not aware of any IPR on this draft.

Tony


> On May 12, 2021, at 2:09 PM, Acee Lindem (acee)  wrote:
> 
> 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 27th, 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

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

[Shraddha Hegde]

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 
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<mailto:lsr@ietf.org>;
抄送人：draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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<mailto: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 27th, 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

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

[Peter Psenak]

Hi Acee,

I am not aware of any IPR related to this draft.

thanks,
Peter


On 12/05/2021 23:09, Acee Lindem (acee) wrote:

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

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

[peng.shaofu]

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 27th, 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

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

[peng.shaofu]

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/100)






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 be S-D, not 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 27th, 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

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

[Gyan Mishra]

I support WG Adoption.

Kind Regards

Gyan

On Thu, May 13, 2021 at 2:33 AM Shraddha Hegde  wrote:

> I am not aware of any IPR related to this draft.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Acee Lindem (acee) 
> *Sent:* Thursday, May 13, 2021 2:39 AM
> *To:* lsr@ietf.org
> *Cc:* draft-hegde-lsr-flex-algo-bw-...@ietf.org
> *Subject:* 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]*
>
>
>
> 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 27th, 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
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Shraddha Hegde]

I am not aware of any IPR related to this draft.

Rgds
Shraddha



Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Thursday, May 13, 2021 2:39 AM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: 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]

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 27th, 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

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

[Jeff Tantsura]

Yes/support 

Regards,
Jeff

> On May 12, 2021, at 15:14, Acee Lindem (acee) 
>  wrote:
> 
> 
> 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 27th, 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