Dear Paul, Thanks a lot for the review. I fixed these editorial typos in -11.
https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-10&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-on-path-telemetry/main/draft-ietf-opsawg-ipfix-on-path-telemetry-11.txt Regards, Alex > On 23 Jul 2024, at 06:50, Aitken, Paul <pait...@ciena.com> wrote: > > 2nd paragraph under Figure 1, typos: > > The advantages of this solution is that the delay metrics (min, max, > and mean) can be computed on the router, and aggregated directly > within the Flow Record, saving export bandwidth and computation on > the Collector. For the computation of the min, max, and mean delay > metric, to be computed locally on the router, the exporter Metering > <--- the first comma isn't needed here > Process requires some local caching/processing computation (for each > <--- "requires" > new packets in the flow), specifically the mean value. A less > computational heavy solution for the router is the export of the > delay sum instead of the delay mean; on the Collector, the delay mean > can easily be computed by a single division operation (using the > packet count). The alternative, w ith any delay monitoring on the <--- > "with" > router, requires the export of every single packet as a separate Flow > Record, including the timestamps information, for the Collector to > compute delay metrics (min, max, and mean) and the recompute the <--- > s/the/to/ ? > aggregated Flow Record. > > > Section 4, typo: > > This section specifies the follwing new IPFIX IEs: > > > 7.4. Measurement Interval: 2x missing closing parenthesis: > The delay metrics are computed for the Flow Record life time. For > long-running Flow, we might miss the temporal distribution of the > delay (for example, a longer delay only at the beginning of Flow. If > this is an operational problem, the IPFIX Metering Process might be > configured with a smaller expiration timeout (see Section 5.1.1. > Flow Expiration , [RFC5470]. > > > > 8. Security Considerations: plural "elements" / "they define" > > The IPFIX Information Element introduced in this doucment do not > directly introduce security issues. Rather, it defines a set of > performance metrics that may, for privacy or business issues, be > considered sensitive information. > > > 10. Acknowledgements > > s/Paul Aikten/Paul Aitken/ > > Sorry to hear about Al Morton :-( > > > P. > > > On 23/07/24 09:48, mohamed.boucad...@orange.com > <mailto:mohamed.boucad...@orange.com> wrote: >> Hi Alex, >> >> Your proposed text works for me. Thanks. >> >> Noted your action point on draft-ietf-opsawg-oam-characterization. >> >> Cheers, >> Med >> >> De : Alex Huang Feng <alex.huang-f...@insa-lyon.fr> >> <mailto:alex.huang-f...@insa-lyon.fr> >> Envoyé : mardi 23 juillet 2024 02:37 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> >> <mailto:mohamed.boucad...@orange.com> >> Cc : Benoit Claise <benoit.cla...@huawei.com> >> <mailto:benoit.cla...@huawei.com>; >> draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org >> <mailto:draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org>; opsawg@ietf.org >> <mailto:opsawg@ietf.org>; Greg Mirsky <gregimir...@gmail.com> >> <mailto:gregimir...@gmail.com>; Aitken, Paul <pait...@ciena.com> >> <mailto:pait...@ciena.com> >> Objet : Re: [OPSAWG]Re: Review of >> draft-ietf-opsawg-ipfix-on-path-telemetry-08 >> >> >> Dear Med, >> >> See inline for the still open issues. I’ll consider the rest of the points >> fixed, unless we receive more comments. >> >> >> On 22 Jul 2024, at 05:50, mohamed.boucad...@orange.com >> <mailto:mohamed.boucad...@orange.com> wrote: >> >> Hi Benoît, >> >> Thanks for the follow-up and changes in -09/-10 to address almost all the >> comments. The new version looks much more better. >> >> FWIW, see inline to help tracking when I think I’m fine with your changes or >> where some changes are still needed. >> >> Cheers, >> Med >> >> De : Benoit Claise <benoit.cla...@huawei.com >> <mailto:benoit.cla...@huawei.com>> >> Envoyé : dimanche 21 juillet 2024 20:10 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com >> <mailto:mohamed.boucad...@orange.com>>; >> draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org >> <mailto:draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org>; opsawg@ietf.org >> <mailto:opsawg@ietf.org>; Greg Mirsky <gregimir...@gmail.com >> <mailto:gregimir...@gmail.com>>; Aitken, Paul <pait...@ciena.com >> <mailto:pait...@ciena.com>> >> Objet : Re: Review of draft-ietf-opsawg-ipfix-on-path-telemetry-08 >> >> >> Hi Med, >> >> On 7/16/2024 6:03 AM, mohamed.boucad...@orange.com >> <mailto:mohamed.boucad...@orange.com> wrote: >> Hi Benoît, >> >> Thanks for taking care of the comments. Much appreciated. >> >> After checking the diff, please find below comments that I think are still >> pending: >> >> I don’t see a discussion about why exporting these new metrics is >> useful/needed compared to exporting sampled Flow timestamps + reception >> timestamp by transit nodes and let the collector compute the new metrics. >> It seems that you are questioning the usefulness of those metric definitions >> :-) >> The main reasons are data aggregation and reduced export bandwidth. >> Your proposed solution requires the export of one packet flow records (with >> the timestamps), for every single (sampled) packet of the flow. >> Now let's assume that your collector does the computation. Typical solutions >> might re-export the IPIFX Flow Records with the computed metrics. >> Hence the required IPFIX IEs. >> >> To address your point (and a point below), I added this text at the end of >> the introduction section >> >> The advantages of this solution is that the delay metrics (min, max, and >> mean) can be computed >> on the router, and aggregated directly within the Flow Record, saving >> export bandwidth and computation on the Collector. >> For the computation of the min, max, and mean delay metric, to be computed >> locally on the router, the exporter Metering >> Process require some local caching/processing computation (for each new >> packets in the flow), specifically the mean value. >> A less computational heavy solution for the router is the export of the >> delay sum instead of the delay mean; on the Collector, the delay mean can >> easily be computed by >> a single division operation (using the packet count). >> The alternative, with any delay monitoring on the router, requires the >> export of every single packet as a separate Flow Record, >> including the timestamps information, for the Collector to compute delay >> metrics (min, max, and mean) and the recompute the aggregated Flow Record >> >> [Med] This is what I was looking for. Consider this point as closed. >> >> >> A discussion about the reference measurement interval/window is needed so >> that the various metrics can be interpreted in a consistent manner. That >> window can be the lifetime of a Flow, but for long-lived/persistent Flows >> some granularity may be needed to be called out. >> Good point. >> Added a new section 7.4 Measurement Interval >> >> The delay metrics are computed for the Flow Record life time. For >> long-running Flow, we might miss >> the temporal distribution of the delay (for example, a longer delay only >> at the beginning of Flow. >> If this is an operational problem, the IPFIX Metering Process might be >> configured with a smaller >> expiration timeout (see Section 5.1.1. Flow Expiration , [RFC 5470] >> >> [Med] Looks good to me. Having an example for to illustrate the long-lived >> flows case would be great, though. >> >> Computing various metrics requires some local caching/processing to be >> supported by the entity that computes them. I would add an explicit mention >> about that pre-requisite. Note that these capabilities may impact the window >> over which an implem can maintain flow-related data. >> Added above. >> [Med] ACK >> >> >> >> >> Update security considerations with IEs specifics (see my previous message). >> Ok, updated >> [Med] Please consider this one as fixed. Thanks. >> >> >> Some key notions refers to expired/individual drafts. These should be made >> normative or (my preference) reword and shorten the list of individual I-Ds. >> Actually, IPFIX is composed of IPFIX Metering Process and the IPFIX >> Exporting Process. >> This document is about the IFPIX Exporting Process, so basically defining >> the IPFIX IEs. >> We believe that the various mechanisms on how to meter the delay should not >> be part of the normative references >> Let's think differently: if there is ever a new delay monitoring protocol in >> the future, should be update this draft with a normative reference? We don't >> think so >> And, let's be honest, we don't want to delay publication :-) >> >> [Med] That’s in part the reason why I wanted you to check the refs :-) I’m >> afraid that some changes are still needed. For example, this text may be >> seen as normative because it explains the applicability to some specific >> cases. Do you really need to specify that here? Why not doing it in the >> other way around (that is, let these I-Ds be updated to explain the >> applicability of your IEs/metrics)? >> [AHF] I think it is useful for the draft to have methods to compute these >> performance metrics. Both ways works IMO. I changed the text of this section >> to this, is this better? >> >> https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-10&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-on-path-telemetry/main/draft-ietf-opsawg-ipfix-on-path-telemetry-11.txt >> [author-tools.ietf.org] >> <https://urldefense.com/v3/__https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-10&url_2=https:**Araw.githubusercontent.com*network-analytics*draft-ietf-opsawg-ipfix-on-path-telemetry*main*draft-ietf-opsawg-ipfix-on-path-telemetry-11.txt__;Ly8vLy8v!!OSsGDw!MPe2Z5epRBwNmW0a4Ce2u6Y97PNQYT-C3ETXLSDlMpMWGmrq1185y_6BsalsfEYuCo8mialOLqroN28I6i0b8d3d$> >> >> This iteration can be submitted during the WG LC. >> >> >> >> == >> In case of Direct Exporting Option-Type, as described in Section 2 of >> [I-D.ahuang-ippm-dex-timestamp-ext], by setting Extension-Flags 2 and >> 3, timestamps can be encoded as defined in Section 4.4.2.3 and >> 4.4.2.4 of [RFC9197]. >> >> For the Enhanced Alternate Marking Method, Section 2 of >> [I-D.zhou-ippm-enhanced-alternate-marking] defines that within the >> metaInfo a nanosecond timestamp can be encoded in the encapsulation >> node and be read at the intermediate and decapsulation node to >> calculate the on-path delay. [RFC9343] defines how this can be >> applied to the IPv6 data-plane and [I-D.fz-spring-srv6-alt-mark] >> defines how this can be applied to the Segment Routing Header in >> SRv6. >> == >> >> I see that you are now referencing I-D.ietf-opsawg-oam-characterization. >> That’s much more better compared to the OLD IOAM ref. However, I don’t know >> what are the plans for publishing that I-D. I suggest you check with the >> authors of I-D.ietf-opsawg-oam-characterization about how to proceed here. >> [AHF] We will do. We don’t think these terms will change in that draft and >> the draft have already been adopted. >> >> >> Minor comments: >> The title can be made clearer as I don’t parse what is an “On-Path Delay” >> We believe that Greg Mirsky proposed that On-path >> >> OLD: Export of On-Path Delay in IP Flow Information eXport (IPFIX) >> NEW: Export of Delay Performance Metrics in IP Flow Information eXport >> (IPFIX) >> >> [Med] This is much more better. Thanks. “on-path delay” was meaningless to >> me or if you will I don’t see how that is different or same as simply >> reasoning about “path delay”. >> >> >> There is no mention of “passport mode” in RFC9197 >> I removed the reference. :-) >> [Med] OK but you still have these concepts there. I won’t be surprised if >> others will ask to provide an authoritative reference for passport/postcard >> thing. Anyway, please consider that point fixed at least for me. >> We will wait a bit to see the current text is ok. >> >> Cheers, >> Alex >> >> >> >> >> Regards, Benoit, on >> >> >> >> >> Cheers, >> Med >> >> De : Benoit Claise <benoit.cla...@huawei.com> >> <mailto:benoit.cla...@huawei.com> >> Envoyé : mardi 16 juillet 2024 11:51 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> >> <mailto:mohamed.boucad...@orange.com>; >> draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org >> <mailto:draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org>; opsawg@ietf.org >> <mailto:opsawg@ietf.org> >> Objet : Re: Review of draft-ietf-opsawg-ipfix-on-path-telemetry-08 >> >> Hi Med, >> >> Many thanks for your thorough review. >> Your comments are addressed >> See >> https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-ipfix-on-path-telemetry-08&url2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-on-path-telemetry/main/draft-ietf-opsawg-ipfix-on-path-telemetry-09.txt&difftype=--html >> [author-tools.ietf.org] >> <https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-ipfix-on-path-telemetry-08&url2=https:**Araw.githubusercontent.com*network-analytics*draft-ietf-opsawg-ipfix-on-path-telemetry*main*draft-ietf-opsawg-ipfix-on-path-telemetry-09.txt&difftype=--html__;Ly8vLy8v!!OSsGDw!MPe2Z5epRBwNmW0a4Ce2u6Y97PNQYT-C3ETXLSDlMpMWGmrq1185y_6BsalsfEYuCo8mialOLqroN28I6hDDlr4I$> >> This is the sum of your (and Paul's) comments. >> >> Attached, in case you can't access the repo. >> >> Regards, Benoit >> >> On 7/15/2024 7:44 AM, mohamed.boucad...@orange.com >> <mailto:mohamed.boucad...@orange.com> wrote: >> Hi Benoît >> >> Thanks for the follow up. >> >> Please see inline. >> >> Cheers, >> Med >> >> De : Benoit Claise <benoit.cla...@huawei.com> >> <mailto:benoit.cla...@huawei.com> >> Envoyé : samedi 13 juillet 2024 12:20 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> >> <mailto:mohamed.boucad...@orange.com>; >> draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org >> <mailto:draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org>; opsawg@ietf.org >> <mailto:opsawg@ietf.org> >> Objet : Re: Review of draft-ietf-opsawg-ipfix-on-path-telemetry-08 >> >> >> Hi Med, >> >> Many thanks for your detailed review. Most of them are inserted. >> >> I don't understand this one comment (and BMI35, BMI36) >> <image001.png> >> >> >> >> >> >> [Med] This is to acknowledge that this text is a copy/past of 8912 + you are >> leveraging an existing standard definition of mean (or other operations) of >> one way delay. >> >> >> For this one below, you are right. We propose to reuse the definitions in >> draft-ietf-opsawg-oam-characterization [datatracker.ietf.org] >> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/__;!!OSsGDw!MPe2Z5epRBwNmW0a4Ce2u6Y97PNQYT-C3ETXLSDlMpMWGmrq1185y_6BsalsfEYuCo8mialOLqroN28I6my9P_rv$>, >> instead of the IOAM specific terms. >> >> [Med] That would be better. OAM characterization terms are not frozen yet, >> though. >> <image002.png> >> >> >> Regards, Benoit. >> >> >> >> >> >> On 7/12/2024 4:42 PM, mohamed.boucad...@orange.com >> <mailto:mohamed.boucad...@orange.com> wrote: >> Hi all, >> >> FWIW, please find below my review of this draft: >> >> pdf: >> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-opsawg-ipfix-on-path-telemetry-08-rev%20Med.pdf >> [github.com] >> <https://urldefense.com/v3/__https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-opsawg-ipfix-on-path-telemetry-08-rev*20Med.pdf__;JQ!!OSsGDw!MPe2Z5epRBwNmW0a4Ce2u6Y97PNQYT-C3ETXLSDlMpMWGmrq1185y_6BsalsfEYuCo8mialOLqroN28I6grQ5c1k$> >> doc: >> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/2024/draft-ietf-opsawg-ipfix-on-path-telemetry-08-rev%20Med.doc >> [github.com] >> <https://urldefense.com/v3/__https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/2024/draft-ietf-opsawg-ipfix-on-path-telemetry-08-rev*20Med.doc__;JQ!!OSsGDw!MPe2Z5epRBwNmW0a4Ce2u6Y97PNQYT-C3ETXLSDlMpMWGmrq1185y_6BsalsfEYuCo8mialOLqroN28I6stVeB2E$> >> >> Overall, >> I think that some motivation is needed to explain the need for the IEs >> compared to an approach where intermediate nodes export the timestamps >> observed in packets and local receiving timestamp and let the collector to >> do the various math operations. >> The IEs do not need to be tightly linked with IOAM. The IEs are applicable >> whenever a timestamp is present in packets. For example, The IEs can be used >> in the context of >> https://datatracker.ietf.org/doc/html/rfc9145#name-new-nsh-variable-length-cont[datatracker.ietf.org] >> >> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9145*name-new-nsh-variable-length-cont__;Iw!!OSsGDw!MPe2Z5epRBwNmW0a4Ce2u6Y97PNQYT-C3ETXLSDlMpMWGmrq1185y_6BsalsfEYuCo8mialOLqroN28I6tTiKAsr$> >> to help detect abnormal traffic steering policies for time-optimized >> service function chains. I suggest the authors to reconsider the current >> description and generalize the use. >> The security considerations are under specified: these IEs are sensitive as >> they may (when blindly trusted) to network reconfiguration. Appropriate >> guards should be in place to control how abnormal delays trigger >> service/network optimization. >> The document includes citations to many individual drafts. Some of the >> citations are obviously normative. I don’t think that’s needed. I would >> cleanup the various citations and focus on a subset for the sake of >> illustration. Please note that some of these are expired, while they are the >> only cited reference for aspects that are presented as key (ex. draft-song). >> I would insist more on time synchronization matter early in the document. >> The exploitation of the various delay-related metric may be problematic in >> the absence of reference measurement intervals, etc. >> The IE naming does not following 7012 rules >> >> Cheers, >> Med >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> _______________________________________________ >> 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> >> >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. > >
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
