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

2021-05-25 Thread 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

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

2021-05-25 Thread 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

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

2021-05-25 Thread 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

2021-05-25 Thread 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

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

2021-05-25 Thread 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

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

2021-05-25 Thread 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

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

2021-05-25 Thread 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

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

2021-05-25 Thread 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

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

2021-05-25 Thread 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