Dear Greg, Please see inline.
> On 9 Jul 2024, at 17:25, Greg Mirsky <gregimir...@gmail.com> wrote: > > 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 Section 7.4, we explain how delay values can be calculated using the currently proposed on-path telemetry methods from the IETF. For Alternate Marking, Enhanced Alt-mark can be used [https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-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. This is a good point. It just makes more sense to use postcard mode, we will remove this reference. > 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'? In section 3.8 of RFC7799, the Hybrid performance metrics can be categorized in subtypes active and passive. And given that it is the first time defining a performance metric for a hybrid category, we used the guidelines defined in https://datatracker.ietf.org/doc/html/rfc8911#name-name MetricType_Method_SubTypeMethod_… Spec_Units_Output Is this correct? > 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? Let’s discuss live as this is not an issue for this draft, but 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. Fixed. > Furthermore, the Uniform Resource Identifier (URI) column must be specific > for each new metric (as listed in Section 3.1.1.3) Fixed. > 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? Good catch. We took a passive performance metric as a template. It is the first hybrid performance metric and there is no template to base this section on. What would you suggest in this section? Regards, Alex > > Regards, > Greg > > > On Mon, Jul 8, 2024 at 11:40 AM Benoit Claise <benoit.cla...@huawei.com > <mailto: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 >> <mailto: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 <mailto:opsawg@ietf.org> >> > To unsubscribe send an email to opsawg-le...@ietf.org >> > <mailto:opsawg-le...@ietf.org> >>
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
