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,
[email protected]<mailto:[email protected]> 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
<[email protected]><mailto:[email protected]>
Envoyé : mardi 23 juillet 2024 02:37
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]><mailto:[email protected]>
Cc : Benoit Claise <[email protected]><mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Greg Mirsky
<[email protected]><mailto:[email protected]>; Aitken, Paul
<[email protected]><mailto:[email protected]>
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,
[email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>>
Envoyé : dimanche 21 juillet 2024 20:10
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Greg Mirsky
<[email protected]<mailto:[email protected]>>; Aitken, Paul
<[email protected]<mailto:[email protected]>>
Objet : Re: Review of draft-ietf-opsawg-ipfix-on-path-telemetry-08
Hi Med,
On 7/16/2024 6:03 AM,
[email protected]<mailto:[email protected]> 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:
1. 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.
1. 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.
1. 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
1.
2. Update security considerations with IEs specifics (see my previous
message).
Ok, updated
[Med] Please consider this one as fixed. Thanks.
1.
2. 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.
1.
Minor comments:
1. 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”.
1.
2. 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
1.
Cheers,
Med
De : Benoit Claise <[email protected]><mailto:[email protected]>
Envoyé : mardi 16 juillet 2024 11:51
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]><mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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,
[email protected]<mailto:[email protected]> wrote:
Hi Benoît
Thanks for the follow up.
Please see inline.
Cheers,
Med
De : Benoit Claise <[email protected]><mailto:[email protected]>
Envoyé : samedi 13 juillet 2024 12:20
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]><mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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,
[email protected]<mailto:[email protected]> wrote:
Hi all,
FWIW, please find below my review of this draft:
1. 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$>
2. 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,
1. 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.
2. 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.
3. 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.
4. 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).
5. I would insist more on time synchronization matter early in the document.
6. The exploitation of the various delay-related metric may be problematic
in the absence of reference measurement intervals, etc.
7. 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 -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
____________________________________________________________________________________________________________
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 -- [email protected]
To unsubscribe send an email to [email protected]
