Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
Dear All, I concur with the arguments presented by Les and Peter. Perhaps the Editors of the WG draft will update the document accordingly. 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: PeterPsenak To: Les Ginsberg (ginsberg);lsr@ietf.org;draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; Date: 2021/07/14 01:40 Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt Hi, I'm the co-author of this draft and I have tried to convince the rest of the co-authors that encoding the new Generic Metric sub-TLV only as a application independent value is wrong. Unfortunately, my efforts have failed. As a result, although unwillingly, I have to express my opinions here and let the WG decide. 1) The usage of the Generic Metric sub-TLV is likely going to be associated with the applications, Flex-algo being the first one. Generic Metric sub-TLV can not be used by IGP's native calculation. So having Generic Metric being encoded only in legacy TLV does not make much sense. 2) TE-metric is defined as application specific attribute by RFC 8919/8920 and can be advertised in ASLA. The application specific value advertisement of TE-metric has been already proved in the field. Generic Metric is semantically very similar to TE-metric, so I see no reason why application specific encoding should not be supported. 3) Flex-algo specification mandates the usage of the ASLA attributes and all of the attributes that we are using for flex-algo so far are encoded in ALSA. Encoding the Generic Metric outside of ALSA violates that principle. 4) RFC 8919/8920 violation brought by Les below. thanks, Peter On 13/07/2021 17:39, Les Ginsberg (ginsberg) wrote: > Draft authors - > > I note that the new version has altered the advertisement of the Generic > Metric sub-TLV so that it is no longer supported in the ASLA sub-TLV. > This is in direct violation of RFC 8919/8920. > > For example, https://www.rfc-editor.org/rfc/rfc8919.html#section-6.1 states: > > "New applications that future documents define to make use of the > advertisements defined in this document MUST NOT make use of legacy > advertisements." > > Flex-algo is a "new application" in the scope of these RFCs. > > Please correct this error. > > Thanx. > > Les > > >> -Original Message- >> From: Lsr On Behalf Of internet-dra...@ietf.org >> Sent: Monday, July 12, 2021 9:12 AM >> To: i-d-annou...@ietf.org >> Cc: lsr@ietf.org >> Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Link State Routing WG of the IETF. >> >> Title : Flexible Algorithms: Bandwidth, Delay, Metrics and >> Constraints >> Authors : Shraddha Hegde >>William Britto A J >>Rajesh Shetty >>Bruno Decraene >>Peter Psenak >>Tony Li >> Filename: draft-ietf-lsr-flex-algo-bw-con-01.txt >> Pages : 27 >> Date: 2021-07-12 >> >> Abstract: >> Many networks configure the link metric relative to the link >> capacity. High bandwidth traffic gets routed as per the link >> capacity. Flexible algorithms provides mechanisms to create >> constraint based paths in IGP. This draft documents a generic metric >> type and set of bandwidth related constraints to be used in Flexible >> Algorithms. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/ >> >> There is also an htmlized version available at: >> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-bw-con-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> ___ >> 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___ 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
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
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
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
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
