Dear Qin, As one of the authors. Thanks a lot for the review.
Regarding point 4 and 6. This has already being raised by Paul at https://mailarchive.ietf.org/arch/msg/opsawg/zAyBkk5I_3SKHvePBjugmFvXlvg/ and is in the queue for -18 revision https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-17&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-on-path-telemetry/refs/heads/main/draft-ietf-opsawg-ipfix-on-path-telemetry-18.txt Please let me know wherever it addresses also your points or not. Regarding point 5. The reason for choosing unsigned64 for pathDelaySumDeltaMicroseconds is because unsigned32 would limit the amount of accounted flows to approx 100'000 if in average the delay for a flow would be 42 milliseconds. Since the standard flow timeout setting for active flows is usually set to 60 seconds, that would lead to approx. 1666 flows per second. Therefore the authors believed unsigned64 might be the better choice. For the other IPFIX entities since it represents one measurement, not the sum, it means that a measurement for up to 4294 seconds can be exported. In reality measurement above one second is very unrealistic. Especially considering that this is most likely only applied in a constraint network environment. Regarding point 7. The same data set can be applied for both, pathDelayMeanDeltaMicroseconds and pathDelaySumDeltaMicroseconds. As described in https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-17#section-7.2, the idea behind pathDelaySumDeltaMicroseconds is to offload the IPFIX exporter from the mean calculation. Therefore from an implementation perspective, realistically an implementer is choosing either pathDelayMeanDeltaMicroseconds or pathDelaySumDeltaMicroseconds. Technically pathDelayMeanDeltaMicroseconds and pathDelaySumDeltaMicroseconds can be exported both. Should this be emphasized more in the Operational Considerations section? On point 1-3, we will get back in a separate email. Best wishes Thomas -----Original Message----- From: Qin Wu via Datatracker <[email protected]> Sent: Saturday, June 7, 2025 12:24 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: draft-ietf-opsawg-ipfix-on-path-telemetry-17 ietf last call Perfmetrdir review Be aware: This is an external email. Document: draft-ietf-opsawg-ipfix-on-path-telemetry Title: Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) Reviewer: Qin Wu Review result: Ready This document specifies 4 new IPFIX IEs for on path delay measurement results reporting. I have read the latest version of this draft and I think the draft is on the right track. Here are a few comments I would like to ask authors to consider: 1. Section 3.2.5 T0 and T1 definitions " T0: T time, the start of a measurement interval (format "date/time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted as the duration of the measurement interval. The start time is controlled through other means. Tf: A time, the end of a measurement interval (format "date/time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", an ending time and date is ignored and Tf is interpreted as the duration of the measurement interval. " Both T0 definition and T1 definition emphasize when T0 is "all-zeros", Tf is interpreted as the duation of the measurement interval, I think it is not necessary to repeat this statement, suggest to remove such duplication in both defintions. 2. Measurement method in section 3.4.2.1, Section 3.4.2.2, section 3.4.2.3, section 3.4.2.4 Since section 3.4.2.3 provide calculation formula for OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max, for consistency, I think section 3.4.2.1, section 3.4.3.2, section 3.4.2.4 should also provide calculation formula for mean, min and sum related metric. 3. Measurement method for section 3.4.2.4 Section 3.4.2.4 said: " However in this case FiniteDelay or MaxDelay MAY be used. " Can you clarify in which circumstance the finitedelay or maxdelay will be used? Also I am wondering whether you use MinDelay or MeanDelay to calculating statistics, see section 4.2.5 and section 4.3.5 of RFC6049 for calculating formula. 4. Table 2 " +-----------+-----------+------+-------------+-------------+-----------+ | ingress | egress | Node | destination | srhActive | Path | | Interface | Interface | | IPv6Address | SegmentIPv6 | Delay | +-----------+-----------+------+-------------+-------------+-----------+ | 271 | 276 | R1 | 2001:db8::2 | 2001:db8::4 | 0 us | +-----------+-----------+------+-------------+-------------+-----------+ | 301 | 312 | R2 | 2001:db8::3 | 2001:db8::4 | 22 us | +-----------+-----------+------+-------------+-------------+-----------+ | 22 | 27 | R3 | 2001:db8::4 | 2001:db8::4 | 42 us | +-----------+-----------+------+-------------+-------------+-----------+ | 852 | 854 | R4 | 2001:db8::4 | 2001:db8::4 | 122 us | +-----------+-----------+------+-------------+-------------+-----------+ Table 2: Example table of measured delay. Ascending by delay. " Consider the example depicted in figure 1, I am wondering whether the destinationIPv6 addresses for both Node R3 and Node R4 should be the same, i.e., 2001::db8::4, can you clarify this? 5. Section 7.3 Can you clarify why Unsigned64 has been chosen as type for pathDelaySumDeltaMicroseconds while Unsigned32 has been choosen as type for IPFIX Information Elements? why not choose unsigned64 or unsigned32 for all new defined IPFIX IEs? 6. Section 3.1.2 The abbreviation of Observation point (OP) has been repeated multiple times, also observation point is defined in RFC7011, I don't see RFC7011 defines abbreviation for Observation point, therefore I suggest to remove such abbreviation as well. Sometime use OP introducing confusing, e.g., quoted the following text in section 3.2.1 " With the OP [RFC7011] typically located between the hosts participating in the IP Flow, the one-way delay metric requires one individual measurement between the OP and sourcing host " For the first reader, he will not understand what "OP" is and also there is no OP abbreviation defined in RFC7011. 7. Aggregated On-Path Delay Examples in Appendix Can I use the same Data Set encoding to carry both pathDelayMeanDeltaMicroseconds and pathDelaySumDeltaMicroseconds? Or you think I should use two different Data Set encoding for pathDelayMeanDeltaMicroseconds and pathDelaySumDeltaMicroseconds respectively?
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
