Re: [Lsr] Working Group Last Call on "Advertising L2 Bundle Member Link Attributes in OSPF" - draft-ietf-lsr-ospf-l2bundles-03
If I have router R1 connected to an L2 switch by an L2 bundle, and router R2 connected to that L2 switch by a single link, is it still OK to configure R1 to send L2 Bundle Member Link Attributes? I think it would be helpful to include that clarification in the draft. On Thu, May 5, 2022 at 10:51 AM Acee Lindem (acee) wrote: > This begins a Working Group Last Call for draft-ietf-lsr-ospf-l2bundles. > While there hasn’t been as much discussion as I would like on the draft, > it is filling a gap in OSPF corresponding to IS-IS Link Bundles (RFC > 8668). Please review and send your comments, support, or objection to this > list before 12 AM UTC on May 20th, 2022. > > > > Thanks, > > 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
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 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
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&D > 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
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
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
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&v=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 is talking propagation delay. Chris is talking transmission delay. Link delay is the sum of propagation and transmission delay. (Perhaps that clarification should be added to the draft?) But most ASICs have a minimum delay just to get the packet through the ASIC. The smallest numbers I have seen are around 200 nsec, and they are rare. This must be added to the transmission delay. Cables can be quite short within a data center. See slide 8: https://www.ieee802.org/3/400GSG/public/13_11/booth_400_01a_1113.pdf But I don't think this technology is too interesting for use inside a data center, and even if it was rounding such links to 1 usec would probably be OK. As such, to me the 1 usec granularity looks OK. On Sun, May 23, 2021 at 6:12 PM Christian Hopps wrote: > > "Acee Lindem (acee)" writes: > > > Hi Greg, > > > > > > > > Additionally, in a vacuum light will only travel 300 meters in a > > microsecond. So, in a nanosecond, that is less than a foot. What > > transmission technology and application do you anticipate that will > > require this this precision? > > Off by a few magnitude; light travels just shy of 300,000,000 meters per > second. > > Consider that 100Gbps links transmit 100 bits every nanosecond. So about 5 > nanoseconds to send a minimum sized ethernet frame (sans the pre/postamble). > > Thanks, > Chris. > > > > > > > > > > Thanks, > > > > Acee > > > > > > > > From: Tony Li on behalf of Tony Li > > > > Date: Sunday, May 23, 2021 at 4:56 PM > > To: Greg Mirsky > > Cc: Shraddha Hegde , "peng.sha...@zte.com.cn" > > , "lsr@ietf.org" , > > "draft-hegde-lsr-flex-algo-bw-...@ietf.org" > > , Acee Lindem > > > > Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: > > Bandwidth, Delay, Metrics and Constraints" - > > draft-hegde-lsr-flex-algo-bw-con-02 > > > > > > > > > > > > Hi Greg, > > > > > > > > That’s a very fair question and not one that has been discussed. > > > > > > > > Do we have that kind of accuracy from any of our measurement tools? > > Is that even on the horizon? I haven’t seen that… > > > > > > > > If it is time for nanosecond level measurement, then is it time to > > shift to floating point to give us more range? > > > > > > > > Tony > > > > > > > > On May 23, 2021, at 1:04 PM, Greg Mirsky > > wrote: > > > > > > > > Hi Shraddha, Authors, et al., > > > > I apologize if my question has already been discussed. The unit > > for the maximum link delay in the draft is a microsecond. There > > is a group of services that require a highly accurate bounded > > delay. Have you considered using a nanosecond as the unit for the > > link delay? > > > > > > > > Regards, > > > > Greg > > > > > > > > On Wed, May 19, 2021 at 9:17 PM Shraddha Hegde > 40juniper@dmarc.ietf.org> wrote: > > > > Hi Pengshaofu, > > > > > > > > Pls see inline.. > > > > > > > > > > > > Juniper Business Use Only > > > > From: peng.sha...@zte.com.cn > > Sent: Thursday, May 20, 2021 7:26 AM > > To: Shraddha Hegde > > Cc: acee=40cisco@dmarc.ietf.org; lsr@ietf.org; > > draft-hegde-lsr-flex-algo-bw-...@ietf.org > > Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible > > Algorithms: Bandwidth, Delay, Metrics and Constraints" - > > draft-hegde-lsr-flex-algo-bw-con-02 > > > > > > > > [External Email. Be cautious of content] > > > > > > > > > > > > Hi Shraddha, > > > > > > > > Thanks. Actually, I don't really want to define other metric > > types. > > > > Let's go back to the bandwidth-metric related to bandwidth > > capability. My worry is that bandwidth-metric (whether it is > > automatically calculated or manually configured) is not > > cumulative in nature, > > > > Yes that is correct. > > > > which is different from IGP default metric/TE metric/delay > > metric, > > > > > > > > so that SPF based on bandwidth-metric may get an unexpected > > path (see the example of the original mail). > > > > Can more text be added in the draft to describe why this can > > work ? > > > > Knowing that metric derived inversely from the > > link bandwidth is not additive in nature, should set the > > expectation right. I can add some text in this regard. > > > > > > > > Regards, > > > > PSF > > > > > > > > > > > > 原始邮件 > > > > 发件人：ShraddhaHegde > > > > 收件人：彭少富10053815; > > > > 抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org; > > draft-hegde-lsr-flex-algo-bw-...@ietf.org; > > > > 日期：2021年05月18日 13:01 > > > > 主题：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible > > Algorithms: Bandwidth, Delay, Metrics and Constraints" - > > draft-hegde-lsr-flex-algo-bw-con-02 > > > > Hi Pengshaofu, > > > > > > >
