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. 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. 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. On to the nits: 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 to opsawg-le...@ietf.org
