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] Q for OSPF Transport Instance

[Aijun Wang]

Hi, Yingzhen:

Thanks for your answers to the previous questions.
Detail responses inline[WAJ].


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Yingzhen Qu
Sent: Tuesday, May 25, 2021 5:47 AM
To: lsr@ietf.org
Subject: [Lsr] Q for OSPF Transport Instance

Hi,

On behalf of co-authors, thanks for the support of WG adoption of this draft.

There were some questions asked, and we’ve compiled them together into this 
Q Comments and questions are welcome.

Thanks,
Yingzhen


Q: In section 4.3 of this draft, it says: 
   "The OSPF transport instance is not dependent on any other OSPF
   instance.  It does, however, have much of the same as topology
   information must be advertised to satisfy the "condition of
   reachability".  
   Then, this transport instance should also advertise the topology
   information. Right?
   But in section 4.5, the advertisement of inter-area information is
   omitted(Summary-LSA for OSPFv2/inter-area-prefix-LSA for OSPFv3). 
   So, how to transfer the non-routing information across different areas?
   Using the remote OSPF neighbor?

A: OSPF transport instance is not dependent on any other OSPF instance. 
   It’s possible that you run OSPF transport instance without regular OSPF
   instance.
   The topology information advertised by OSPF transport instance is to 
   satisfy the "condition of reachability", not for routing table/RIB update.
   We'll clarify in OSPFv2 this will include the type-4 summaries related to the
   transport instance topology. 
 [WAJ] Should be Type-3 summaries?


Q: The reason that we use the IGP to transfer the non-routing information is
   that the IGP assures the reachability/dissemination of such information.
   Using independent transport instance, the operator need again the design and
   deployment of the distributed topology. And most important, the correlation
   between the routing information and non-routing information is not solved or
   covered within the current draft, which is the merit of other solutions.
   There should be solutions/considerations to the possible problem as that
   described in
   https://datatracker.ietf.org/doc/html/draft-bowers-lsr-isis-gen-info-clarifi
   cations-00 for IS-IS.

A: The topology of OSPF transport instance may or may not be the same as
   the regular OSPF instance, and it's up to the applications that uses OSPF
   transport instance. The support of sparse topology and remote neighbor
   makes it possible for only some routers in the network get the application
   info.
   It is expected the applications in the transport instance will advertise
   non-routing information and, hence, there will be no requirement for
   correlation between route routing and non-routing instance. 
[WAJ] Transport Instance can certainly be used to advertise non-routing 
information. But the most usage of these non-routing information will be 
coupled with routing information, for example the use cases you mentioned in 
section 3.1 and section 3.2.
My understanding is that "Transport Instance" does not solve the ultimate 
requirements of flooding application information via IGP protocol. In most of 
scenarios, nearly every node within the IGP nodes should know these non-routing 
information.


Q: Section 4.7 described the "Non-Routing Sparse Topologies". It requires
   again the careful design and deployment. Is it more straightforward to let
   the IGP routers relay such information and only the necessary nodes to
   store/utilize it? 

A: As mentioned above, sparse topologies make it possible for only routers
   interested in certain applications get involved, and this doesn't impact 
   other routes and routing calculations in regular OSPF instance.
   I don't understand your suggestion of only necessary nodes to store/utilize
   it. This seems not consistent with the idea of link state protocol.
[WAJ] My intension is that the information is relayed via the IGP protocol, but 
such information does not participate in the SPF process, and only be consumed 
in necessary nodes.


Q: Add a section on how to advertise information in a transport instance if 
   an application requires, per-link resource information to be advertised in 
   transport instance.

A: This is dependent on the application and while it may be better for some
   applications to advertise separate LSAs per link, for others, it may make
   sense to have a lists of interfaces in a single LSA. 


Q: Some applications may require to co-relate the information in transport 
instance
   to a specific routing-instance. This requirement to be addressed.

A: This should be addressed by the application draft when using OSPF transport 
   instance. Again, it is expected that routing information will be in the 
routing
   instance. 


Q: There may be cases when application information gets associated with 
   prefixes rather than nodes. We should allow advertisement of Extended  
   Prefix-LSA and 

[Lsr] Q for OSPF Transport Instance

[Yingzhen Qu]

Hi,

On behalf of co-authors, thanks for the support of WG adoption of this draft.

There were some questions asked, and we’ve compiled them together into this 
Q Comments and questions are welcome.

Thanks,
Yingzhen


Q: In section 4.3 of this draft, it says: 
   "The OSPF transport instance is not dependent on any other OSPF
   instance.  It does, however, have much of the same as topology
   information must be advertised to satisfy the "condition of
   reachability".  
   Then, this transport instance should also advertise the topology
   information. Right?
   But in section 4.5, the advertisement of inter-area information is
   omitted(Summary-LSA for OSPFv2/inter-area-prefix-LSA for OSPFv3). 
   So, how to transfer the non-routing information across different areas?
   Using the remote OSPF neighbor?

A: OSPF transport instance is not dependent on any other OSPF instance. 
   It’s possible that you run OSPF transport instance without regular OSPF
   instance.
   The topology information advertised by OSPF transport instance is to 
   satisfy the "condition of reachability", not for routing table/RIB update.
   We'll clarify in OSPFv2 this will include the type-4 summaries related to the
   transport instance topology. 


Q: The reason that we use the IGP to transfer the non-routing information is
   that the IGP assures the reachability/dissemination of such information.
   Using independent transport instance, the operator need again the design and
   deployment of the distributed topology. And most important, the correlation
   between the routing information and non-routing information is not solved or
   covered within the current draft, which is the merit of other solutions.
   There should be solutions/considerations to the possible problem as that
   described in
   https://datatracker.ietf.org/doc/html/draft-bowers-lsr-isis-gen-info-clarifi
   cations-00 for IS-IS.

A: The topology of OSPF transport instance may or may not be the same as
   the regular OSPF instance, and it's up to the applications that uses OSPF
   transport instance. The support of sparse topology and remote neighbor
   makes it possible for only some routers in the network get the application
   info.
   It is expected the applications in the transport instance will advertise
   non-routing information and, hence, there will be no requirement for
   correlation between route routing and non-routing instance. 


Q: Section 4.7 described the "Non-Routing Sparse Topologies". It requires
   again the careful design and deployment. Is it more straightforward to let
   the IGP routers relay such information and only the necessary nodes to
   store/utilize it? 

A: As mentioned above, sparse topologies make it possible for only routers
   interested in certain applications get involved, and this doesn't impact 
   other routes and routing calculations in regular OSPF instance.
   I don't understand your suggestion of only necessary nodes to store/utilize
   it. This seems not consistent with the idea of link state protocol.


Q: Add a section on how to advertise information in a transport instance if 
   an application requires, per-link resource information to be advertised in 
   transport instance.

A: This is dependent on the application and while it may be better for some
   applications to advertise separate LSAs per link, for others, it may make
   sense to have a lists of interfaces in a single LSA. 


Q: Some applications may require to co-relate the information in transport 
instance
   to a specific routing-instance. This requirement to be addressed.

A: This should be addressed by the application draft when using OSPF transport 
   instance. Again, it is expected that routing information will be in the 
routing
   instance. 


Q: There may be cases when application information gets associated with 
   prefixes rather than nodes. We should allow advertisement of Extended  
   Prefix-LSA and E-Intra-area-Prefix-LSA/E-Inter-Area-Prefix-LSA 
Advertisements 
   inside transport instance.

A: While an application could define prefix-level information with semantics 
identical
   to these LSAs, it would not use these LSAs. There are for routing 
information. 


Q: It seems like we could reuse RI-LSA and originate RI-LSA in transport 
   instance with application-ID TLV. What is the Need to define yet another 
   opaque LSA?

A:  so we have a clear cut of application data, and hopefully this can
simplify implementations.


___
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] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Ketan Talaulikar (ketant)]

Hello Authors,

Some post adoption comments/feedback on the draft :

1) RFC6823 for ISIS GenApp allows that top-level TLV to be also advertised in 
the "default instance". Each application is able to specify whether this is 
allowed or not for itself. Any plans to follow the same approach in OSPF?

2) The application specific information may not only be associated with the 
node. We also need the ability to advertise the application specific info 
associated with the link and prefix as well. There was some feedback on this 
point during the adoption call as well with which I concur. How would this be 
addressed? Via Transport Link and Prefix LSAs? Or is each application expect to 
be bring in the link and prefix descriptors under the application TLV in the 
proposed LSA? IMHO, it would be valuable to preserve the granularity of 
advertisement offered by OSPF via LSAs for this use-case as well.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 21 May 2021 20:35
To: Christian Hopps 
Cc: lsr@ietf.org; lsr-...@ietf.org; 
draft-acee-lsr-ospf-transport-insta...@ietf.org
Subject: Re: [Lsr] WG adoption call for 
draft-acee-lsr-ospf-transport-instance-02


The work is adopted, authors please resubmit as:

draft-ietf-lsr-ospf-transport-instance-00

Thanks,
Chris.

Christian Hopps  writes:

> This begins a 2 week WG adoption call for the following draft:
>
>https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/
>
> Please indicate your support or objection by May 16th, 2021.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Historical Note: The original OSPF transport instance document was adopted by 
> the OSPF WG back in 2009, it was last updated in 2014, and then revived as an 
> individual submission to LSR in Sep 2020. :)
>
> Thanks,
> Chris.
>
> ___
> 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

[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>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>,
> 
"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> 
wrote:
>
> Hi Pengshaofu,
>
>
>
> Pls see inline..
>
>
>
>
>
>   Juniper Business Use Only
>
> From: peng.sha...@zte.com.cn 
mailto:peng.sha...@zte.com.cn>>
> Sent: Thursday, May 20, 2021 7:26 AM
> To: Shraddha Hegde 
mailto:shrad...@juniper.net>>
> Cc: 
acee=40cisco@dmarc.ietf.org; 
lsr@ietf.org;
> 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
> Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible
> Algorithms: Bandwidth, Delay, Metrics and Constraints" -
> draft-hegde-lsr-flex-algo-bw-con-02
>
>
>
> 

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

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
>
> 收件人：彭少富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