Hi Joe,
Thanks for your review.
On 10/11/2024 10:45 AM, Joe Clarke (jclarke) wrote:
I have read this draft and I think it’s nearly ready. I found a few
nits, but my biggest concern is with section 7.5 (btw, thanks for the
operational considerations). In this section, you outline a few
approaches that can be used to calculate the delay metrics. If using
IOAM, you mention Edge-to-Edge with bits 2 and 3. This is very good as
the IOAM RFC states:
“Within the IOAM encapsulating node, the time that the timestamp is
retrieved can depend on the implementation. Some possibilities are 1)
the time at which the packet was received by the node, 2) the time at
which the packet was transmitted by the node, or 3) when a tunnel
encapsulation is used, the point at which the packet is encapsulated
into the tunnel. Each implementation has to document when the E2E
timestamp that is going to be put in the packet is retrieved.”
This point about an implementation documenting /where/ the timestamp
is recorded in the feature/packet path is critical IMHO.
Agreed.
The other methods outlined in section 7.5 do not provide this detail.
I think it is incumbent on your draft to state that implementations,
regardless of approach, document where the metrics are calculated so
that meaningful action can be taken.
Exactly. This must be described in the RFC8911 IP performance metrics
registry
See section 3.1.2 in our draft
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean: This
metric assesses the mean of one-way delays of all successfully
_forwarded IP packets constituting a single Flow_._We consider the
measurement of one-way delay based on a single
Observation Point (OP) [RFC7011] somewhere in the network._
This implies that it depends on how you create your Flow Records in the
IPFIX Metering Process.
To take you 3 examples
1) the time at which the packet was received by the node,
=> this would be the case if the IPFIX Metering Process is enabled
on the input interface, in the ingress direction
2) the time at which the packet was transmitted by the node, or
=> this would be the case if the IPFIX Metering Process is enabled
on the output interface, in the egress direction
Note: in such as case, there is always the issue of having
precise timestamps or not
3) when a tunnel encapsulation is used, the point at which the packet is
encapsulated into the tunnel.
=> this would be the case if the IPFIX Metering Process is enabled
on the tunnel interface, in the egress direction
We tried to make the performance metric generic, based on the IPFIX
Observation Point definition
Another question on Section 1. When you say, “The advantage 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”,
wouldn’t the collector typically have the resources for such
computation whereas the router may be more constrained? Meaning,
pushing this to the router might be the wrong approach, especially in
this day and age of huge central data processing facilities.
Let's keep in mind that we want to export the min, the max, and the mean
delays.
This implies that we have to look at every single packet, deduce the
delay, and evaluate whether we face the min and the max... trivial.
Now, for the mean, we need to re-calculate it with every single new
packet of this flow.
If we want to do on the collector, this requires the export of every
single packet of that flow (basically, a series of Flow Records of one
packet), to be able to compute the delays on the collector.
Once it's done, we need the aggregate all these one packet Flow Records
into a single one with: the right number of packets, and the delays
So to save computing on the router, we are going to increase the IPFIX
export bandwidth (multiply it by average number of monitored packets in
the Flows)
Re-reading section 7.5, I found a mistake
OLD:
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 to recompute the
aggregated Flow Record.
NEW:
The alternative, without 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), before recomputing the
aggregated Flow Record.
ALTERNATIVE NEW:
The alternative, with no 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), before recomputing the
aggregated Flow Record.
On to the nits:
Thanks for the nits.
Regards, Benoit
Section 1:
OLD:
That view is meant to help understanding
NEW:
That view is meant to help with understanding
OLD:
In order to understand which customer traffic is affected,
delay-related data need to be reported into customer data-plane
NEW:
In order to understand which customer traffic is affected,
delay-related data need to be reported in the context of the
customer data-plane
OLD:
In the usecase shown in Figure 1
NEW:
In the use case shown in Figure 1
OLD:
The advantages of this solution is that the delay metrics
NEW:
The advantage of this solution is that the delay metrics
Section 3.1.1.3
Might want to add your RFC editor note here for “RFC-to-be”.
Section 3.1.2
Add your RFC editor notes here, too.
Section 9.2
OLD:
Huawei implemented the following IEs as part of a a production
NEW:
Huawei implemented the following IEs as part of a production
Joe
*From: *Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org>
*Date: *Thursday, October 10, 2024 at 11:23
*To: *opsawg@ietf.org <opsawg@ietf.org>
*Subject: *[OPSAWG]WG LAST CALL: Export of Delay Performance Metrics
in IP Flow Information eXport (IPFIX)
This starts a two week WG LC for
draft-ietf-opsawg-ipfix-on-path-telemetry
<https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/>.
The authors have been polled and there is no known IPR on this work
that has been disclosed at this time.
Please post comments and thoughts on this document’s readiness to the
list. If you are interested in being the shepherd for this document,
please email opsawg-chairs@.
The WG LC will run until October 24.
Thanks.
Joe
_______________________________________________
OPSAWG mailing list --opsawg@ietf.org
To unsubscribe send an email toopsawg-le...@ietf.org
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
