Dear Authors, thank you for updating the draft; I've read it. I hope that adding IPPM WG to discussion of new performance metrics is reasonable. I appreciate your consideration of my notes and questions below:
- If I understand correctly, the delay measurement using on-path telemetry is achieved inserting a timestamp into the packet: With On-Path Telemetry, described in the Network Telemetry Framework [RFC9232] and applied in In-situ OAM [I-D.ietf-ippm-ioam-deployment] and Alternate Marking Deployment Framework [I-D.ietf-ippm-alt-mark-deployment], the path delay between two endpoints is measured by inserting a timestamp in the packet. Can you clarify which document specifies delay measurement using timestamp with Alternate Marking. - In your opinion, what is the value of references to passport and postcard modes considering that the conclusion, with which I fully agree, notes: In both modes the forwarding path exposes performance metrics allowing to determine how much delay has been accumulated on which hop. - All names of the new performance metrics combine 'hybrid' and 'passive'. I assume that 'hybrid' refers to the characterization of on-path telemetry measurement methods according to RFC 7799. If that is the case, what is the interpretation of the 'passive'? - Delay measurement method defined as follows: The delay is measured by calculating the difference between the timestamp imposed with On-Path Telemetry in the packet at the IOAM encapsulation node and the timestamp exported in the IPFIX flow record from the IOAM transit and decapsulation nodes. - I think that the purpose of one-way delay measurement is to produce accurate metrics that reflect network conditions as experienced by the packet equipped by, e.g., IOAM header. When considering the one-way delay measurement, I think that it is essential, among a number of factors, to specify when the wall-clock value must be read and the quality of clock synchronization used in the forwarding path. AFAIK, RFC 9197 does not specify when IOAM Node Data fields Timestamp (seconds and fractions) are obtained. - When considering an impact of clock synchronization, quality of clock synchronization on the accuracy of one-way delay measurement, we may consider another IOAM Node Data field that might provide information about the delay and support localization of any bottleneck along the path that, at the same time, does not depend on the issue of clock synchronization. I think that Transit time, a.k.a. Residence Time has advantages compared to collecting local timestamps. What are your thoughts? - Alternatively, to compensate for systematic and random errors in one-way time measurement a system may use calibration, e.g., as described in Section 5.4.4 of OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile <https://www.iana.org/assignments/performance-metrics/OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile>. In your opinion, could calibration be used for delay measurement using IOAM? - As I understand it, Section 3.1 lists variation and constant column entries in the IANA Performance Metrics registry: All column entries besides the ID, Name, Description, and Output Reference Method categories are the same Two notes on that: - I cannot find the Output Reference Method column in the referenced IANA registry. - Furthermore, the Uniform Resource Identifier (URI) column must be specific for each new metric (as listed in Section 3.1.1.3) - I got confused by the text in 3.4.2.6. Calibration Passive Measurements at an OP could be calibrated against an Active Measurement at host A where the Active Measurement represents the ground truth. Would calibration be required on all transit IOAM nodes as well as the decapsulating IOAM node? Also, could you clarify the "Passive Measurements" classification. Is it related to IOAM or another measurement method? Regards, Greg On Mon, Jul 8, 2024 at 11:40 AM Benoit Claise <benoit.cla...@huawei.com> wrote: > Dear all, > > We reviewed one more time the double IANA registrations, both for the IP > Performance Registry and for the IPFIX Registry. > I feel (more) confident (than before) that the IANA procedure on the > right track. > This document is ready for WGLC IMO. > > I would like to have a 10 min presentation to over the last changes, and > mainly the IANA aspects. > > Regards, Benoit > > > On 7/8/2024 6:33 PM, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-opsawg-ipfix-on-path-telemetry-08.txt is now > > available. It is a work item of the Operations and Management Area > Working > > Group (OPSAWG) WG of the IETF. > > > > Title: Export of On-Path Delay in IPFIX > > Authors: Thomas Graf > > Benoit Claise > > Alex Huang Feng > > Name: draft-ietf-opsawg-ipfix-on-path-telemetry-08.txt > > Pages: 29 > > Dates: 2024-07-08 > > > > Abstract: > > > > This document introduces new IP Flow Information Export (IPFIX) > > information elements to expose the On-Path Telemetry measured delay > > on the IOAM transit and decapsulation nodes. > > > > The IETF datatracker status page for this Internet-Draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/ > > > > There is also an HTMLized version available at: > > > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-08 > > > > A diff from the previous version is available at: > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-on-path-telemetry-08 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > OPSAWG mailing list -- opsawg@ietf.org > > To unsubscribe send an email to opsawg-le...@ietf.org > >
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
