Network Working Group S. Dikshit Internet-Draft HPE Intended status: Informational 04 September 2026 Expires: 04 March 2027 Scoping and Comparability Requirements for Exported Network Telemetry Identifiers draft-dikshit-nmop-telemetry-identifier-scoping-01 Abstract This document describes a recurring interoperability problem in exported network telemetry: many values are encoded without an explicit definition of the scope in which they are unique, meaningful, and comparable. In practice, the wire representation of a value may be standardized while the semantic context of that value remains implicit. As a result, a receiver may infer that two numerically identical values are equivalent when they were produced in different semantic domains and therefore refer to different objects, states, or observations. This ambiguity is operationally significant. It can lead to incorrect aggregation, incorrect cross-instance comparison, and erroneous conclusions about routing state, forwarding behavior, or network health. The risk is particularly visible in telemetry protocols that export statistics or identifiers in contexts such as VRFs, topology instances, address families, route distinguishers, policy domains, or other instance-specific scopes. This document argues that exported telemetry identifiers and statistics MUST explicitly define both the scope in which a value is unique and meaningful, and the conditions under which it may be compared with values from other contexts. This requirement is not limited to BMP; it applies to any telemetry mechanism in which a value can be generated in multiple semantic domains and therefore cannot be treated as self-describing solely by its encoded form. 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 04 March 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 04 March 2027 [Page 1] Internet-Draft Telemetry Identifier Scoping September 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivating Examples . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Telemetry exports are often designed to preserve the semantics of a measurement, but the semantics are not always carried explicitly in the exported value. A value may be well-formed and well-encoded, while still being meaningful only within a specific instance, domain, or operational context. In such cases, the value is not self-describing in the broader sense required for cross-system interpretation. This problem is not limited to a single protocol family or vendor implementation. It arises whenever a telemetry description encodes a value without clearly stating the scope in which that value is unique, the context in which it is meaningful, and the conditions under which it can be compared with other values. In practice, this creates a recurring interoperability hazard: the same numeric value may be produced in different contexts yet still correspond to different objects, different observations, or different policy domains. From an operator's perspective, this is not an abstract modeling issue. It directly affects decision making in network operations: a receiver may aggregate values across instances, compare counters across domains, or infer equivalence from a common numeric encoding even though the underlying objects are distinct. The result is an incorrect operational understanding of routing state, traffic patterns, policy impact, or network health. In other words, value equality does not imply object identity, and numeric coincidence does not imply semantic comparability. The problem becomes acute in distributed systems because the same identifier or counter may appear in multiple local contexts while remaining semantically distinct. This is a well-understood pattern in network telemetry: a value can be syntactically valid yet not semantically comparable without an explicit description of the relevant scope. The resulting ambiguity is not limited to a single vendor implementation; it is a property of telemetry systems whose semantics depend on instance-specific context. This issue is particularly evident in BMP and related telemetry mechanisms. The per-peer header in RFC 7854 identifies a peer and its local context, but it does not by itself define the complete semantic scope of an exported statistic. The scope is carried in the Stat Data encoding, as defined in RFC 9972. This is a useful example because it shows that scope can be a semantic requirement independent of peer identity. A receiver that treats the same value as comparable across contexts without looking at the scope metadata is at risk of drawing the wrong conclusion. The general problem is broader than BMP. It applies to any telemetry export in which the interpretation of a value depends on a contextual domain such as a VRF, routing instance, AFI/SAFI, topology instance, policy domain, route distinguisher, or other instance-specific scope. The relevant question is not whether the value is encoded correctly, but whether the specification defines the scope in which the value is valid and the comparability rules that apply to values from different contexts. This document does not propose a new transport format or a new telemetry model. Instead, it defines a small set of interoperability requirements for exported telemetry identifiers and statistics. The goal is to encourage future specifications to state the semantic scope of exported values as consistently as they state their wire encoding. In that sense, this document addresses a foundational interoperability requirement: a value should not be treated as comparable merely because it shares a representation with another value. 2. Problem Statement The same numeric value may be produced in multiple semantic contexts and still refer to different objects, different observations, or different operational states. For example, a value exported from one VRF, routing instance, AFI/SAFI, topology domain, or policy scope may be numerically identical to a value exported from another context, yet represent a different object or a different measurement entirely. In such cases, value equality does not imply object identity, and numeric similarity does not imply semantic comparability. If the scope of the value is not explicitly defined in the specification, a receiver may incorrectly infer that values are comparable across instances, devices, or domains, when the exporter never intended such a comparison. This problem is operationally significant. A network operator may normalize or aggregate exported metrics without recognizing that the series include values from different semantic domains. The result is a seemingly consistent dataset that is internally inconsistent in a semantic sense. This can lead to erroneous conclusions about performance, reachability, policy behavior, or route distribution. BMP provides a concrete illustration. RFC 7854 provides peer identity and local context, but it does not by itself define the full semantic scope of a statistic. The scope of a statistic is carried in the Stat Data encoding defined in RFC 9972. This shows that scope is not always a transport concern; it is a semantic concern that affects interpretation. More generally, any telemetry export whose meaning depends on instance-specific or domain-specific context can exhibit the same failure mode when comparability is not explicitly defined. 3. Motivating Examples This issue arises in several telemetry-related scenarios, including protocols and export models that are already widely deployed. BMP statistics: The per-peer header in RFC 7854 identifies a peer and a local context, but it does not by itself determine the full meaning or scope of the exported statistic. In contrast, RFC 9972 carries AFI/SAFI information in the Stat Data encoding. This demonstrates that the semantic scope of an exported value can be orthogonal to peer identity and must therefore be defined in a way that is explicit to the receiver. IPFIX and related flow telemetry: IPFIX records often depend on contextual scope such as an observation domain, exporter identity, or measurement context. A specification that does not state whether values from different observation domains or export contexts are comparable can lead to incorrect assumptions about the meaning of otherwise identical values. This is especially relevant when flow records are aggregated across multiple exporters, interfaces, or administrative domains. RD-scoped or policy-scoped statistics: A statistic may be valid only within a particular route distinguisher, policy state, or instance-specific context. Two values that are numerically identical may still correspond to different objects because the scope differs. From an operational perspective, this matters when counters or route attributes are compared across contexts without a documented comparability rule. YANG-based telemetry and subscription models: Data exported through YANG notifications or streaming telemetry often carries instance identifiers such as interface names, VRFs, network instances, or route targets, but the operational meaning of a metric can depend on the scope of the subscribed object and on the selected view of the device. A metric that is valid for a specific network instance or policy context may be incorrectly aggregated with values from a different context if the model does not state the scope boundary. Counter, gauge, and sampling semantics: Telemetry frequently exports counters, gauges, rates, and sampled observations that are meaningful only with respect to a time window, interval, sample period, or normalization method. A value may be numerically equal across different periods yet represent entirely different rates or different points in the measurement lifecycle. Without explicit definitions of time scope and sampling semantics, a receiver may compare two values that are not comparable. Topology and overlay-underlay contexts: Statistics associated with VNI, EVPN, overlay networks, SRv6 segments, label-switched paths, or underlay paths may share the same numeric encoding while referring to different logical domains. In these cases, a value is not semantically meaningful unless its topology scope and forwarding context are specified. Aggregation and normalization boundaries: Many network operators aggregate telemetry across interfaces, peers, devices, or administrative domains. If the scope of each metric is implicit, an aggregated dataset can appear coherent while still mixing values from different semantic domains. This is particularly dangerous for dashboards, automation systems, and anomaly detection pipelines, which often treat aggregated values as directly comparable. Other telemetry exports: Similar concerns arise when a value depends on topology, address family, route state, observation domain, time window, exporter identity, policy state, or other instance-specific semantics. In all of these cases, the value is not self-describing unless the specification defines both the scope in which it is meaningful and the conditions under which it may be compared to values from other contexts. 4. Requirements A telemetry identifier or statistic SHOULD define the scope in which it is unique and meaningful. In particular, the specification SHOULD state: 1. the scope of uniqueness of the identifier or statistic; 2. the context or instance in which the value is meaningful; 3. the observation domain or measurement domain over which the value is defined; 4. the comparability domain: whether values may be compared across instances, devices, records, exporters, or administrative domains; 5. the time scope of the observation, including whether the value is cumulative, sampled, averaged, delta-based, or interval- scoped; 6. the aggregation or normalization semantics, if the value is intended to be combined with other values; and 7. when value equality is to be interpreted as object identity, and when it is to be interpreted only as numeric coincidence. A specification MUST NOT require implementers to infer semantics from local conventions, registry descriptions, or assumptions about protocol context when the value's interpretation depends on external scope. When a value is meaningful only within a certain instance, policy domain, topology, address family, observation domain, or measurement interval, that scope MUST be part of the formal semantics, not an implicit operational convention. The required semantics are broader than the value encoding itself. A specification may define a value format correctly while still failing to define the domain in which the value is valid. Such a value is syntactically well-formed but semantically ambiguous. This is particularly important for telemetry systems that aggregate or normalize data across many instances. Without an explicit model of scope and comparability, the system may produce a consistent dataset that is nonetheless semantically meaningless when values from different domains are mixed. In operational terms, equality of representation does not imply equality of meaning. In particular, a telemetry definition SHOULD distinguish among the following concepts: o Instance scope: the network instance, VRF, topology, or administrative domain in which the value is defined. o Observation scope: the measurement domain from which the value is produced, such as an exporter, observation domain, or interface set. o Time scope: the interval, event, or collection window during which the value was measured. o Comparability scope: the set of values with which the value may be compared without changing its semantics. o Aggregation scope: the boundary under which a value may be combined with other values and still retain a meaningful interpretation. These distinctions matter because a telemetry value can be valid in one scope and invalid or non-equivalent in another. A document defining an exported identifier or statistic SHOULD therefore be explicit about both the scope of uniqueness and the comparability rule for the value. Without that information, two systems can observe the same encoded value and still reach different conclusions about what it represents. That ambiguity is not a harmless implementation detail; it is an interoperability defect. This requirement applies broadly to telemetry exports, not only to BMP. BMP is used here as a concrete example because the issue is readily visible there, but the general principle applies to any telemetry mechanism in which the meaning of a value depends on the surrounding context, on measurement scale, on sampling semantics, or on the domain in which a value is collected. 5. Security Considerations This document does not introduce new protocol operations or new security-sensitive state changes. It does improve interoperability by reducing ambiguity in the interpretation of exported telemetry values, which can help avoid incorrect operational conclusions and misconfiguration. 6. IANA Considerations This document does not require any IANA actions. 7. Acknowledgements The author thanks the reviewers and contributors in the NMOP, GROW, IPFIX, and telemetry-related discussions that identified the repeated pattern described in this document. 9. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7854] Scudder, J., and R. Raszuk, "BGP Monitoring Protocol (BMP)", RFC 7854, June 2016. [RFC9972] Evers, J., and S. Hares, "Advanced BGP Monitoring Protocol (BMP) Statistics Types", RFC 9972, October 2024. [RFC9232] Song, H., et al., "Network Telemetry Framework", RFC 9232, May 2022. [RFC7011] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol", RFC 7011, September 2013. [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., et al., "Subscription to YANG Notifications for Datastore Updates", RFC 8639, September 2019. [RFC8641] Clemm, A., et al., "Subscription to YANG Notifications for Datastore Updates", RFC 8641, September 2019. [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, March 2018. Author's Address Saumya Dikshit HPE Email: saumya.dikshit@hpe.com