Network Working Group S. Dikshit Internet-Draft HPE Intended status: Informational 2 November 2026 Expires: 6 May 2027 Operational Telemetry Comparability for IP Performance Measurements draft-dikshit-bpm-telemetry-comparability-00 Abstract Operational telemetry is often used to compare network performance across observation points, traffic classes, service instances, paths, devices, and time intervals. The numeric value of a metric is not sufficient for such comparison unless the observation context and the comparability conditions are also known. This document describes a common interoperability problem in operational measurement systems: values such as delay, loss, ECN marking, queue occupancy, packet counts, byte counts, and flow correlation identifiers can be exported from different observation points or under different aggregation rules while still appearing to be directly comparable. A collector or controller can therefore combine values that do not describe the same measurement domain. The document defines requirements for describing the observation point, metric source, aggregation interval, traffic class, flow scope, sampling rule, timestamp basis, freshness, and comparability domain associated with operational telemetry used for IP performance measurement. The goal is to make operational measurement results easier to compare without prescribing one measurement protocol, one data model, or one congestion control mechanism. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Dikshit Expires 6 May 2027 [Page 1] Internet-Draft Operational Telemetry Comparability November 2026 Table of Contents 1. Introduction 2. Problem Statement 3. Terminology 4. Motivating Cases 4.1. ECN and Congestion Telemetry 4.2. Queue and Delay Measurements 4.3. AI Network Fabric Measurements 4.4. Flow Correlation Across Observation Points 4.5. Metric Freshness for Traffic Steering 5. Comparability Requirements 6. Relationship to Existing Work 7. Security Considerations 8. IANA Considerations 9. Acknowledgements 10. References 1. Introduction IP performance measurements are increasingly consumed by automated systems. Collectors, controllers, service assurance systems, and traffic steering systems compare telemetry from multiple devices, paths, and service locations. Such systems often receive numeric values that appear to be comparable: delay values, packet loss counters, ECN marking counters, queue depth measurements, packet and byte counts, or flow identifiers. In practice, these values are not self describing. A delay value may be measured at an application boundary, an RDMA completion boundary, a packet forwarding boundary, or a device internal observation point. An ECN marking count may be collected at ingress, egress, or an intermediate point. A queue measurement may refer to a port, a traffic class, a virtual output queue, or an implementation specific internal queue. A loss counter may include or exclude retransmitted traffic. A flow identifier may be unique in one observation domain but reused in another. These differences matter because a consumer can reach a wrong operational conclusion while every exported value is syntactically valid. The problem is not the encoding of the value. The problem is the missing statement of the measurement domain in which the value is meaningful and comparable. This document defines requirements for operational telemetry used as input to IP performance measurement. It does not define a new metric and does not replace protocol specific data models. Instead, it describes the context that needs to accompany measurements when those measurements are compared, aggregated, or used by automated systems. Existing IPPM work already requires metrics to be concrete, well defined, repeatable, and useful to operators and users. RFC 7799 distinguishes active, passive, and hybrid methods and points to the importance of observation points or measurement points. IPFIX and PSAMP define observation points, observation domains, packet selection, and scoped fields. IOAM defines data fields collected inside a limited domain and uses namespace context to interpret fields such as node identifiers, timestamps, and queue information. Alternate Marking shows why counters from different measurement points need aligned packet blocks or marking periods before they can be compared. This document builds on those ideas. It provides a checklist for a consumer that asks a simple operational question: given two telemetry values, what context is needed before the values can be compared, joined, aggregated, or used as input to an automated decision? 2. Problem Statement Two telemetry values can have the same metric name and the same unit while still describing different measurement domains. For example, two delay values may both be expressed in microseconds, but one may measure endpoint processing and fabric forwarding while the other measures only device boundary delay. Two ECN counters may both count marked packets, but one may represent ingress observations while the other represents egress observations after remarking, tunneling, or encapsulation changes. A collector that receives these values needs to know whether they can be compared. A controller that uses these values to make a steering decision needs to know whether a stale service metric and a fresh network metric can be combined. A troubleshooting system needs to know whether a counter reset, missing record, traffic class change, or observation point change created a new measurement series. Current telemetry work often defines the metric or the encoding, but the comparability rule is left implicit or is distributed across protocol specific context. This leads to at least five operational risks: 1. Incorrect aggregation: values from different observation points are summed or averaged as if they described one measurement domain. 2. Incorrect comparison: values collected at different boundaries or under different traffic class rules are ranked as if they were equivalent. 3. Incorrect correlation: flow or measurement identifiers are joined across domains where they are not unique or do not identify the same observation. 4. Incorrect automation: controllers react to measurements that were collected at different times or with different aggregation rules. 5. Incorrect fault isolation: endpoint delay, queueing delay, and fabric forwarding delay are mixed without a way to identify which component produced the change. A specification can avoid these risks by making the measurement domain explicit. The same metric name and unit are not enough. The consumer also needs to know where the measurement was made, which packets or flows were included, which time interval was used, whether sampling or filtering was applied, which traffic class or forwarding treatment was observed, and whether the value is still fresh enough for the intended decision. 3. Terminology Observation Point: The location and logical boundary at which a measurement is made. Examples include ingress interface, egress interface, device internal counter, endpoint software boundary, RDMA operation boundary, fabric boundary, or service contact instance boundary. Measurement Domain: The set of conditions under which a telemetry value is meaningful. This can include observation point, traffic class, flow scope, encapsulation state, sampling rule, aggregation interval, and metric source. Comparability Domain: The set of values with which a telemetry value may be compared without changing its meaning. Values outside this domain may still be useful, but the consumer needs a rule for interpreting the difference. Freshness Context: Information that allows a consumer to determine when a metric was measured, when it was exported, and whether it is still valid for the decision being made. Aggregation Scope: The set of packets, flows, traffic classes, interfaces, service instances, or time intervals included in a reported value. Series Identity: The set of fields that identifies one continuous measurement series. A change in exporter, observation point, sampling rule, counter state, traffic class, aggregation interval, or timestamp basis can create a different series. 4. Motivating Cases 4.1. ECN and Congestion Telemetry ECN telemetry can be exported as packet counts, byte counts, marking ratios, codepoint observations, or flow records. A collector needs to know whether the value was observed before or after remarking, decapsulation, encapsulation, load balancing, or traffic class mapping. It also needs to know whether the reported series includes all packets for the flow, sampled packets, one direction of the flow, or both directions. If those conditions are not explicit, an ECN marking rate can be compared with the wrong denominator or correlated with the wrong traffic direction. Example: an exporter reports a CE packet counter for a flow at ingress, while another exporter reports a CE packet counter for the same apparent flow at egress. If traffic was remarked, tunneled, sampled, or load balanced between the two points, the two counters do not by themselves describe the same series. A collector needs the observation point, direction, traffic class, sampling rule, packet or byte denominator, and interval before it can compute or compare a marking rate. 4.2. Queue and Delay Measurements Queue and delay measurements are sensitive to the observation boundary. An endpoint boundary measurement can include application, transport, and completion queue behavior. A network boundary measurement can include fabric delay but not endpoint processing. A device internal queue measurement can expose a useful signal, but it may be implementation specific and not directly comparable with another device. The exported value therefore needs to carry enough context for a consumer to know whether it is comparing endpoint delay, fabric delay, queue occupancy, or a combined value. Example: one system reports latency from an application request to an application response. Another system reports delay between two fabric boundary points. Both values can be useful, but they should not be ranked as if they were the same metric. The first value includes endpoint and service processing. The second value describes network forwarding within a selected boundary. 4.3. AI Network Fabric Measurements AI network fabric measurements often combine workload behavior, endpoint behavior, and fabric behavior. Training and inference traffic can use different message sizes, burst patterns, traffic classes, congestion control parameters, and pause behavior. A result that reports latency, ECN marking, PFC events, queue depth, or throughput is not comparable unless the observation point and traffic conditions are known. Controlled benchmarking work can define these conditions for a lab test. Operational telemetry needs a related but separate rule: the exported measurement should state the observation context and the comparability domain so that values collected from live systems are not mixed incorrectly. Example: a controller compares queue depth from one switch port with a completion latency value from an endpoint. The two values may both indicate congestion pressure, but they do not measure the same part of the system. A consumer needs the observation boundary before it can decide whether the values support the same conclusion. 4.4. Flow Correlation Across Observation Points Flow identifiers and correlation keys can be reused or scoped by an exporter, observation domain, interface, tunnel, service instance, or measurement session. A collector needs to know the uniqueness scope before it joins records from different sources. A common numeric identifier does not by itself prove that two records describe the same flow or the same measurement event. The exported context must define the joining rule. Example: two exporters use the same flow identifier value. The value is unique only within each exporter and observation domain. Joining the records on the numeric identifier alone can merge unrelated measurements. The join rule needs to include the exporter, observation domain, and any measurement session or namespace needed to make the identifier unique. 4.5. Metric Freshness for Traffic Steering Traffic steering systems can combine service metrics and network metrics. A path selector might use service load, network delay, packet loss, and reachability to select a service contact instance or egress forwarder. The selected result can be wrong if these inputs were measured at different times or have different validity periods. Example: a service load metric says that a service instance is lightly loaded, but the value was collected before a sudden workload change. At the same time, a fresh network metric says that the network path is healthy. Combining the stale service metric with the fresh network metric can steer traffic to an overloaded instance. A consumer needs freshness context and a validity rule before using those values in one decision. Freshness is also part of stability. If steering decisions react to every small metric change, the system can create oscillation. A specification that expects automated use should identify whether hold time, damping, thresholding, or another stability method is expected. 5. Comparability Requirements Specifications that define or use operational telemetry for IP performance measurement should state the following information when the values are expected to be compared, aggregated, or used by automated systems. REQ1: The specification should identify the Observation Point for each metric or metric series. REQ2: The specification should identify the traffic class, forwarding treatment, encapsulation state, and direction of traffic to which the value applies, when these affect the interpretation of the metric. REQ3: The specification should identify the Aggregation Scope of the value, including the time interval, packet set, flow set, interface set, service instance set, or traffic class set represented by the metric. REQ4: The specification should state the Comparability Domain for the value. If values from different observation points, traffic classes, or aggregation scopes are not directly comparable, that condition should be stated. REQ5: The specification should define how a consumer detects a new measurement series when the observation point, exporter, sampling rule, counter state, traffic class, or aggregation interval changes. REQ6: The specification should provide Freshness Context when a measurement can be used by a controller, path selector, assurance system, or other automated consumer. This can include timestamp, sequence number, validity interval, or update reason. REQ7: The specification should state how missing records, counter resets, exporter restarts, and stale values are represented. A missing delta record should not be silently interpreted as zero traffic unless the specification explicitly defines that behavior. REQ8: The specification should define the uniqueness scope and join rule for any identifier used to correlate measurements across observation points or exporters. REQ9: The specification should state whether the measurement method is active, passive, or hybrid, when that affects interpretation of the value. If the method changes the packet stream, observes an existing packet stream, or adds in situ data to packets, that fact should be visible to the consumer. REQ10: The specification should identify the timestamp basis and clock context used by a metric when timing affects comparison. Values measured using different timestamp formats, clock domains, or synchronization assumptions should not be treated as directly comparable unless the specification defines the conversion rule. 6. Relationship to Existing Work RFC 2330 defines the general IPPM goal of concrete, well defined, repeatable, and useful metrics. This document does not alter that framework. It applies the same discipline to operational telemetry values that are consumed after export by collectors and automated systems. RFC 7799 defines active, passive, and hybrid methods. This document uses that distinction because the method affects the meaning of a value. A metric derived from generated test traffic, a metric based only on observed production packets, and a metric derived from in situ data placed in production packets can have different assumptions about packet selection, packet modification, and measurement points. RFC 7011 and RFC 7012 define IPFIX observation points, observation domains, scoped fields, counters, and flow records. This document is consistent with that model. It asks specifications that use exported measurements to make the observation and scope rules visible when a consumer is expected to compare or aggregate values. RFC 5475 describes packet selection, sampling, filtering, and packet streams. Sampling and filtering are part of the measurement domain. A metric collected from sampled packets is not automatically comparable with a metric collected from all packets unless the specification defines the relationship. RFC 8321 and related Alternate Marking work show that counters from multiple measurement points are comparable only when they refer to the same packet block or marking period. This document generalizes that lesson: a consumer needs a common aggregation scope before it compares values from different points. RFC 9197 defines IOAM data fields collected within a limited domain. IOAM namespaces provide context for interpreting node identifiers, timestamp formats, queue data, and other fields. This document does not change IOAM. It uses IOAM as an example of why context and namespace are part of measurement interpretation. Benchmarking methodology work can define controlled test procedures, reporting requirements, and benchmark conditions. This document is concerned with operational telemetry used outside a single controlled test. The two topics are related because both need clear observation points and comparability rules, but the deployment assumptions are different. This document is also related to telemetry identifier scoping work. Identifier scoping addresses whether a value uniquely identifies the same object or observation. This document focuses on whether measurement values may be compared or aggregated. Both properties are needed by collectors and automated consumers. Existing IPPM metrics and measurement protocols remain unchanged by this document. The requirements in this document are intended to help future specifications state the context needed to interpret those metrics in operational telemetry systems. 7. Security Considerations Missing or incorrect comparability context can lead to incorrect operational decisions. A controller could steer traffic away from a healthy path, select an overloaded service instance, or suppress a valid alarm if it compares stale or mismatched measurements. Telemetry context can also expose sensitive operational information, including topology, traffic class use, service placement, load, and congestion state. Specifications using the requirements in this document should consider confidentiality, integrity, and access control for both the measurement value and its context. 8. IANA Considerations This document has no IANA actions. 9. Acknowledgements The motivation for this document came from discussions about IPPM, BMWG, IPFIX, and operational telemetry models where measurement values need explicit scope before they can be compared. 10. References 10.1. Informative References [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009. [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export Protocol for the Exchange of Flow Information", RFC 7011, September 2013. [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export", RFC 7012, September 2013. [RFC7799] Morton, A., "Active and Passive Metrics and Methods", RFC 7799, May 2016. [RFC8321] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and T. Mizrahi, "Alternate Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, January 2018. [RFC9197] Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In Situ Operations, Administration, and Maintenance", RFC 9197, May 2022. [I-D.ietf-ippm-on-path-telemetry-yang] Fioccola, G., Zhou, T., Zhu, Y., Zhang, W., and K. Zhu, "On-Path Telemetry YANG Data Model", draft-ietf-ippm-on-path-telemetry-yang-06, August 2026. [I-D.ietf-ippm-alt-mark-yang] Graf, T., Wang, M., Fioccola, G., Zhou, T., and X. Min, "A YANG Data Model for the Alternate-Marking Method", draft-ietf-ippm-alt-mark-yang-06, August 2026. [I-D.ietf-cats-framework] Li, C., Du, Z., Boucadair, M., Contreras, L., and J. Drake, "A Framework for Computing-Aware Traffic Steering", draft-ietf-cats-framework-24, April 2026. Author's Address Saumya Dikshit HPE Email: saumya.dikshit@hpe.com Dikshit Expires 6 May 2027 [Page 9]