Dear Gunter, On behalf of the authors, thank you very much for your detailed review and comments.
We addressed your feedback together with Tim's, Mike's, Med's, Deb's, Éric's, Greg's and Gorry's as following https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-20&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-on-path-telemetry/refs/heads/main/draft-ietf-opsawg-ipfix-on-path-telemetry-21.txt GV> (see DISCUSS) There seems to be a miscommunication i here. The alt-mark-framework is not measuring by inserting timestamps, but my setting bits and alternating these bits to measure a delay based upon the event when a a bit goes up or down. Completely agree. The initial authors thoughts where that Enhanced Alternate Marking is a subset auf Alternate Marking and therefore mentioning the term Alternate Marking in the introduction and detail int section 7.5, In-Packet OAM Application, would give clarity, however we understood from various feedback that this was ambiguous. Therefore we removed Alternate Marking references and focus on Enhanced Alternate Marking instead throughout the document. Enhanced Alternate Marking does include a timestamp in the packet. GV> ## (DISCUSS#4) In the below snip, on line 180 it is unclear what is a "mean"? This is described in section 4.4.2.1, OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean I hope this addresses your comments. Looking forward to your review. Best wishes Thomas -----Original Message----- From: Gunter Van de Velde via Datatracker <[email protected]> Sent: Monday, August 4, 2025 1:35 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: [OPSAWG]Gunter Van de Velde's Discuss on draft-ietf-opsawg-ipfix-on-path-telemetry-20: (with DISCUSS and COMMENT) Gunter Van de Velde has entered the following ballot position for draft-ietf-opsawg-ipfix-on-path-telemetry-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-opsawg-ipfix-on-path-telemetry-20 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-on-path-telemetry-20.txt # I observed a few DISCUSS items. I think most will be reasonable easy to resolve, and some suggestions to increase readability in few paragraphs. # in generak the draft is a nice and comfortable read. # DISCUSS # ======== ## (DISCUSS#1) in the below snip (line 126-129) Alternative marking does not operate by inserting timestamps. The insinuation in the text seems from that perspective wrong. (alternate marking uses the event of a bit going up->down or visa versa, an dnot by insreting timestamps) 126 Maintenance (IOAM) Deployment [RFC9378] and Alternate Marking 127 Deployment Framework [I-D.ietf-ippm-alt-mark-deployment], the path 128 delay between two endpoints is measured by inserting a timestamp in 129 the packet. ## (DISCUSS#2) IANA expert review comments reports issue that needs to be resolved ## (DISCUSS#3) In the below snip it is assumed that there is a timestamp carried in the dataplane packet, which is not the situation when alternate marking is used. Instead the slope of the bit going up/down/up is used instead. This may have to be made more explicit in the below snip. ## (DISCUSS#4) In the below snip, on line 180 it is unclear what is a "mean"? Is there a reference that can be pointed towards? from mathematical perspective there are various way to compute a "mean" (i.e. Arithmetic Mean, Weighted Mean, Geometric Mean, Harmonic Mean, Moving Average (Rolling Mean), Running/Incremental Mean, Trimmed or Winsorized Mean). 176 Assuming time synchronization on devices, the delay is measured by 177 calculating the difference between the timestamp imposed with On-Path 178 Telemetry in the packet at the OAM encapsulating node and the 179 timestamp exported in the IPFIX flow record from the OAM transit and 180 decapsulating nodes. The lowest, highest, mean, and/or the sum of 181 measured path delay can be exported, thanks to the different IPFIX IE 182 specifications. ## (DISCUSS#5) In the below what is an "IP Flow"? On line 260 there is a reference "Flow" but the term "IP Flow" by itself is not specified. Can this be clarified or defined what exactly is meant with the term? 238 * Encapsulating Node: Receives the IP Flow packets, encapsulates the 239 packets with the OAM header and adds the timestamp into the OAM 240 header. GV> (DISCUSS#6) Considering the below snip, in the routing world the term one-way is not used so much, but unidirectional is. for example see: * https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-metric-type * "Min Unidirectional Link Delay" as defined in [RFC8570, Section 4.2] and [RFC7471, Section 4.2]. Also the existing TE metrics speak about unidirectional delay and not one-way metric. There is inconsistency. Could the term unidirectional be used instead? 286 3.1. IP One-Way Delay Hybrid Type I Passive Performance Metrics ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Detailed Review # =============== 16 This document specifies new IP Flow Information Export (IPFIX) 17 Information Elements to export the On-Path Telemetry measured delay 18 in the OAM transit and decapsulating nodes. GV> What about the following alternative proposal to have slightly more elaborate abstract: " This document defines a set of IP Flow Information Export (IPFIX) Information Elements to support the export of on-path telemetry data. By standardizing the export format for on-path telemetry using IPFIX, this document facilitates interoperable data collection and analysis across multi-vendor network environments. The Information Elements defined herein support various telemetry paradigms, including in-situ OAM (IOAM), Alternate Marking, and hybrid schemes, and enable comprehensive visibility into packet-level behavior observed along the network path. " 108 1. Introduction 110 Network operators usually gather and maintain some forms of 111 statistical delay view of their networks (or segments of their 112 networks). That view is meant to help with understanding where in 113 the network, for which customer traffic or services, how much, and 114 why abnormal delay is being accumulated. To that aim, delay-related 115 data needs to be reported from devices covering both data and control 116 planes. In order to understand which customer traffic is affected, 117 delay-related data needs to be reported in the context of the 118 customer data-plane. That enables network operators to quickly 119 identify when the control-plane updates the current path with a 120 different set of intermediate hops (that is, a change of the 121 forwarding path) and interfaces, how the path delay changes for which 122 customer traffic. GV> I found the text here reasonable confusing to digest. Suggest a rephrasing to consider with the following alternative: " Network operators commonly maintain statistical views of delay across their networks to support diagnostics and performance analysis. These views assist in identifying the location, extent, and potential causes of abnormal delay affecting specific customer traffic or services. To achieve this, delay-related telemetry must be collected from both the data and control planes and correlated with the customer data plane. This correlation enables timely detection of changes in forwarding paths, such as updated intermediate hops or interfaces, and the resulting impact on delay experienced by customer traffic. " 124 With On-Path Telemetry, described in the Network Telemetry Framework 125 [RFC9232] and applied in In Situ Operations, Administration, and 126 Maintenance (IOAM) Deployment [RFC9378] and Alternate Marking 127 Deployment Framework [I-D.ietf-ippm-alt-mark-deployment], the path 128 delay between two endpoints is measured by inserting a timestamp in 129 the packet. GV> (see DISCUSS) There seems to be a miscommunication i here. The alt-mark-framework is not measuring by inserting timestamps, but my setting bits and alternating these bits to measure a delay based upon the event when a a bit goes up or down. 131 At least two modes of On-Path Telemetry can be distinguished. 132 Passport mode, where only the last hop in the forwarding path of the 133 On-Path Telemetry domain exposes all the metrics, and postcard mode, 134 where the metrics are also exposed in transit nodes. In both modes 135 the forwarding path exposes performance metrics allowing to determine 136 how much delay has been accumulated on which hop. The proposal in 137 this document makes more sense for the postcard mode. GV> What about the following proposal: " Two modes of on-path telemetry are generally recognized: passport mode, in which only the egress node of the telemetry domain reports metrics; and postcard mode, in which transit nodes also export telemetry data. Both modes enable exposure of per-hop performance metrics, including delay accumulation. The approach defined in this document is primarily applicable to postcard mode. " 139 In order to export the delay-related metrics via IPFIX [RFC7011], 140 this document defines four new IPFIX Information Elements (IEs), 141 exposing the On-Path delay on OAM transit and decapsulating nodes, 142 following the postcard mode principles. Since these IPFIX IEs are 143 performance metrics [RFC8911], they are also registered in the "IANA 144 Performance Metric Registry [IANA-PERF-METRIC] . 145 146 Following the guidelines for Registered Performance Metric Requesters 147 and Reviewers [RFC8911], the different characteristics of the 148 performance metrics (Identifier, Name, URI, Status, Requester, 149 Revision, Revision Date, Description, etc.) must be clearly specified 150 in the "IANA Performance Metric Registry [IANA-PERF-METRIC] in order 151 for the measurement results using the Performance Metrics to be 152 comparable even if they are performed using different implementations 153 and in different networks. The first performance metric 154 characteristic is the selection of a meaningful name, following the 155 "MetricType_Method_SubTypeMethod_... Spec_Units_Output" naming 156 convention (See Section 7.1.2 of [RFC8911]). GV> alternative proposal: " To enable the export of delay-related metrics via IPFIX [RFC7011], this document defines four new IPFIX Information Elements (IEs) that report on-path delay at OAM transit and decapsulating nodes, consistent with postcard mode telemetry. As these IEs represent performance metrics, they are also registered in the IANA Performance Metric Registry [IANA-PERF-METRIC] in accordance with [RFC8911]. In line with the guidelines for Registered Performance Metric Requesters and Reviewers [RFC8911], each metric is specified with its required characteristics (e.g., Identifier, Name, URI, Status, Requester, Revision, Description) to ensure comparability of measurement results across implementations and environments. Metric naming follows the "MetricType_Method_SubTypeMethod_..._Spec_Units_Output" convention defined in Section 7.1.2 of [RFC8911] " 176 Assuming time synchronization on devices, the delay is measured by 177 calculating the difference between the timestamp imposed with On-Path 178 Telemetry in the packet at the OAM encapsulating node and the 179 timestamp exported in the IPFIX flow record from the OAM transit and 180 decapsulating nodes. The lowest, highest, mean, and/or the sum of 181 measured path delay can be exported, thanks to the different IPFIX IE 182 specifications. GV> (see DISCUSS) With alternative marking there is no timestamp within the packet, but it contains an alternating slope of a bit used for marking packets. GV> (See DISCUSS) Another observation i have is what is meant with "mean"? There are various ways to compute a mean value. 210 The advantage of this solution is that the delay metrics (min, max, 211 and mean) can be computed on the OAM node, and aggregated directly 212 within the Flow Record, saving export bandwidth and computation on 213 the Collector. For the computation of the min, max, and mean delay 214 metric to be computed locally on the OAM node, the exporter Metering 215 Process requires some local caching/processing computation (for each 216 new packets in the flow), specifically the mean value when Flow 217 Aggregation [RFC7015] is being used. A less computational heavy 218 solution for the OAM node is the export of the delay sum instead of 219 the delay mean; on the Collector, the delay mean can easily be 220 computed by a single division operation (using the packet count). 221 The alternative, with no delay monitoring on the OAM node, requires 222 the export of every single packet as a separate Flow Record, 223 including the timestamps information, as described in 224 [I-D.ietf-opsawg-ipfix-alt-mark] for Alternate Marking, for the 225 Collector to compute delay metrics (min, max, and mean), before 226 recomputing the aggregated Flow Record. GV> What about the following alternative: " This solution enables the computation of delay metrics (minimum, maximum, and mean) directly on the OAM node, allowing aggregation within the Flow Record. This reduces both export bandwidth and processing requirements on the Collector. To compute these metrics locally, the Exporter’s Metering Process must perform per-packet caching and processing, particularly when computing mean delay under Flow Aggregation [RFC7015]. A less computationally intensive alternative is to export the sum of delays, allowing the Collector to compute the mean via a simple division using the packet count. In contrast, if no delay processing occurs on the OAM node, each packet must be exported as an individual Flow Record, including timestamp information, as specified in [I-D.ietf-opsawg-ipfix-alt-mark]. The Collector must then compute the delay metrics and reconstruct the aggregated Flow Record accordingly. " 238 * Encapsulating Node: Receives the IP Flow packets, encapsulates the 239 packets with the OAM header and adds the timestamp into the OAM 240 header. GV> (See DISCUSS) what is an "IP Flow"? On line 260 is made to a reference "Flow" but the term "IP Flow" by itself is not specified. Thanks for this write-up. Gunter Van de Velde RTG Area Director
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
