Network Working Group S. Dikshit Internet-Draft Aruba Networks, HPE Intended status: Informational 26 August 2026 Expires: 27 February 2027 Scoping and Comparability Requirements for Exported Network Telemetry Identifiers draft-dikshit-nmop-telemetry-identifier-scoping-00 Abstract Several documents currently in progress across multiple IETF working groups define identifiers that are exported from a network element and consumed by a remote collector, controller, or receiver: a flow identifier, a path segment identifier, a per-peer or per-Route-Distinguisher counter, and a period or sequence number are examples already found in active work. In each case examined in this document, the identifier is defined without a stated scope of uniqueness, so the receiver cannot determine, from the exported value alone, whether two records observed at different times or from different sources describe the same object. This document catalogs six such instances found independently across five working groups, defines a short vocabulary for stating an identifier's scope of uniqueness, and sets out requirements for documents that define exported telemetry identifiers going forward. 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 27 February 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 27 February 2027 [Page 1] Internet-Draft Telemetry Identifier Scoping August 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement: Six Instances of One Gap . . . . . . . . 4 4. Relationship to Existing Work . . . . . . . . . . . . . . . . 6 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Applicability to the Six Instances . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Network Telemetry [RFC9232] moved the industry from polling a device for its own state toward streaming that state to a collector, controller, or analytics system that may be several hops, and several minutes, removed from the device that produced it. Once a value leaves the device, whatever the device meant by an identifier travels with the bytes but not with the intent behind them. A flow identifier, a path segment identifier, a per-peer counter, or a period number can be re-used by two different devices, at two different times, or within two different administrative domains, and the exported record gives the receiver no way to tell which of those has happened. This is not a hypothetical concern. Between July and August 2026, six independent technical reviews across five working groups converged on the same finding, described in Section 3. Each review was written before this pattern was recognized as a single problem, which is itself evidence that the gap is structural rather than a property of any one document. A working group reviewing its own export format rarely asks what happens once that format is compared against a second device's output; a receiver-side reviewer asks exactly that, and each of the six reviews below came from that vantage point. This document does not propose new wire formats. It proposes a short piece of vocabulary, set out in Section 2, together with a small number of requirements, set out in Section 5, that a document defining an exported telemetry identifier can adopt with a sentence or two of text. The intent is that future IPFIX Information Elements, YANG-Push augmentations, and BMP TLVs state their scope as a matter of course, the same way they already state their wire encoding. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology Exported identifier: a value placed into a telemetry record by an originating platform for the purpose of letting a receiver correlate that record with other records, other objects, or other points in time. Flow identifiers, path segment identifiers, per-peer or per-Route-Distinguisher counters, and period or sequence numbers are all exported identifiers under this definition. Scope of uniqueness: the domain within which two occurrences of the same exported identifier value are guaranteed by the originator to refer to the same object. This document defines four scope values: Node-local: the value is guaranteed unique only within the originating platform. The same value observed from two different platforms carries no relationship to each other. Domain-local: the value is guaranteed unique within a stated administrative or protocol domain (for example, an IGP area, an SRv6 domain, or a BGP Route Distinguisher's scope), spanning more than one platform within that domain but not beyond it. Controller-scoped: the value is guaranteed unique only within the set of platforms managed by a single controller or orchestration system, and only for as long as that controller's assignment record is retained. Globally unique: the value is guaranteed unique across every platform and every domain, independent of any controller or administrative boundary, for the lifetime stated by the defining document. Comparability rule: a statement, made by the document defining an exported identifier, of the reference frame (typically a time base or a per-domain sequence) against which values of that identifier gathered from more than one node may be compared. 3. Problem Statement: Six Instances of One Gap The following six instances were each found during a separate, independently written review. They are listed here together because their similarity is the evidence for this document, not because they were originally treated as related. [I-D.ietf-opsawg-ipfix-path-segment] exports a Path Segment Identifier (PSID) for correlating IPFIX records with the SRv6 path a packet traversed. One part of the document's own text describes PSID uniqueness as ensured by the implementation, while registry text elsewhere in the same document requires the value to be globally unique; the two statements describe different scopes without reconciling them. [I-D.ietf-opsawg-ipfix-alt-mark] exports a 20-bit FlowMonID and a Period Number. The scope over which the 20 bits of FlowMonID are unique is not stated, and the Period Number is intended to be compared across nodes without a defined shared time base, so two collectors receiving the same Period Number from two different nodes have no way to know whether the numbers refer to the same measurement interval. [I-D.ietf-ippm-on-path-telemetry-yang] carries flow-mon-id as an optional leaf in the exported YANG-Push data. Because the field is optional, a collector can receive a record with no flow-mon-id at all, which removes the possibility of correlating that record with anything else regardless of what scope the identifier would otherwise have had. [I-D.ietf-spring-srv6-path-segment] allocates the same PSID concept discussed above at the point of definition. Section 3 of that document states that the PSID allocation scheme is out of scope and use-case dependent, while Section 3.1 requires the PSID to be globally unique within the SRv6 domain. Read together, the two sections leave open which entity is responsible for the uniqueness the later section requires. [I-D.ietf-grow-bmp-stats-informational-tlv] reports gauge-type BGP statistics, including a Median (P50) entry type, without requiring the reporting router to disclose the sampling interval or the method used to compute that percentile. Two implementations can therefore report a numerically different P50 for the same underlying distribution, and a collector combining reports from both has no way to detect that the two numbers are not directly comparable. [I-D.ietf-nvo3-rfc7348bis] carries VTEP-local MTU state that has no defined path across the tenant and underlay boundary to the party, typically an orchestration system, that would need it to detect a mismatch before it causes packet loss. The state exists; its scope, and the mechanism for exporting it beyond the VTEP that holds it, do not. Table 1 summarizes the six instances against the vocabulary defined in Section 2. +===============================+========================+ | Document | Missing scope statement| +===============================+========================+ | ipfix-path-segment | PSID scope | | ipfix-alt-mark | FlowMonID, Period No. | | ippm-on-path-telemetry-yang | flow-mon-id presence | | spring-srv6-path-segment | PSID allocation entity | | grow-bmp-stats-informational | percentile method scope| | nvo3-rfc7348bis | MTU state export path | +===============================+========================+ Table 1 4. Relationship to Existing Work [I-D.ietf-opsawg-collected-data-manifest] is the closest existing work to the problem described here, and any document building on this proposal needs to be read alongside it rather than in place of it. That document defines a Platform Manifest and a Data Collection Manifest: metadata that lets a collector recover which platform produced a datapoint, which YANG modules and revisions that platform was running, and what collection period was actually used for a given subscription. Its "id" leaf for a platform is explicitly scoped ("has to be unique within the network scope at every point in time"), and its "current-period" augmentation solves a narrower version of the period-comparability problem described in Section 3: it tells a collector what collection cadence a single node actually used, which is a necessary but not sufficient condition for comparing a period number, a counter, or a percentile across two nodes. What the Data Manifest does not cover is the scope of an identifier carried inside the telemetry payload itself, once that payload leaves the platform and subscription context the Manifest describes. A FlowMonID, a PSID, or a per-peer BMP counter is data, not collection metadata, and the Data Manifest's Platform and Data Collection Manifests have no leaf that describes the scope of uniqueness of a value inside that payload. The six instances in Section 3 sit in that gap: adjacent to a document the IESG is close to approving, but not covered by it. 5. Requirements REQ1: A document that defines an identifier exported from a network element to a remote collector, controller, or receiver MUST state the scope of uniqueness of that identifier, using one of the terms defined in Section 2, or MUST define an equivalent term and explain its relationship to those in Section 2. REQ2: A collector or receiver that observes an exported identifier for which no scope of uniqueness is stated MUST NOT assume a scope wider than node-local. Two records bearing the same identifier value MUST be treated as describing the same object only when both records were observed from the same originating platform, unless a wider scope has been established out of band. REQ3: A document that defines a counter, sequence number, period number, or percentile-type statistic intended to be compared across records from more than one node MUST also define the comparability rule (Section 2) against which those values are comparable, or MUST state explicitly that no cross-node comparison is defined for that value. REQ4: Where an exported identifier's presence in a record is OPTIONAL, the defining document MUST state what a receiver is expected to do with a record that omits it, rather than leaving the record's correlability undefined by omission. 6. Applicability to the Six Instances Applying REQ1 to [I-D.ietf-opsawg-ipfix-path-segment] and [I-D.ietf-spring-srv6-path-segment] would require the two documents to agree on a single scope for the PSID and name the entity responsible for it, resolving the disagreement between their allocation text and their registry text without requiring either document to change its wire format. Applying REQ1 and REQ3 to [I-D.ietf-opsawg-ipfix-alt-mark] would require a stated scope for FlowMonID and a stated time base for Period Number, so that a collector could distinguish "same flow, different node" from "different flow, coincidentally equal identifier." Applying REQ4 to [I-D.ietf-ippm-on-path-telemetry-yang] would require the document to state what a receiver does with a record whose flow-mon-id is absent, rather than leaving that case silent. Applying REQ3 to [I-D.ietf-grow-bmp-stats-informational-tlv] would require a reporting router to disclose, alongside a Median or Average entry, the sampling interval or method used to compute it, so that two collectors combining reports from different implementations could tell whether the values are directly comparable. [I-D.ietf-nvo3-rfc7348bis] illustrates REQ1 at a different layer: the VTEP-local MTU state described in Section 3 has an implicit scope of node-local today. Naming that scope explicitly would make clear that a mismatch cannot be detected without an additional, currently undefined, export path to a party with visibility across VTEPs. 7. IANA Considerations This document defines a vocabulary for use in other IETF documents and does not itself request any IANA action. A future document may wish to register the terms defined in Section 2 as a shared YANG identity base, so that documents defining exported identifiers can reuse a single "identifier-scope" identity rather than each defining its own; this document does not itself define that identity. 8. Security Considerations An exported identifier whose scope of uniqueness is wrongly assumed by a receiver can be misused in two opposite directions. A receiver that assumes a wider scope than the originator intended can merge records from two distinct flows, paths, or peers into a single correlated object, which can mislead an automated system into taking a remediation action against the wrong target, or into suppressing an alert that should have fired separately for each object. A receiver that assumes a narrower scope than intended can fail to correlate records that describe the same object, hiding a real condition, such as a route flap visible only when per-peer counters from two peers are combined under a domain-local Route Distinguisher scope. Because the requirements in this document affect how records are correlated rather than how they are encoded or transported, they do not introduce a new attack surface on the wire. A platform that misreports its own scope, whether by error or by compromise, can still cause a receiver to draw the wrong correlation; this risk already exists in every one of the six documents examined in Section 3 and is not created by this document. Implementers should treat a stated scope as a claim made by the originating platform, not as a property independently verified by the receiver, and should apply the same transport and authentication protections to the identifier as to the rest of the telemetry payload. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [I-D.ietf-opsawg-ipfix-path-segment] Yao, K., Liu, Y., and others, "Export of Path Segment Identifier in IP Flow Information Export (IPFIX)", Work in Progress, Internet-Draft, draft-ietf-opsawg-ipfix-path-segment-05, 2026, . [I-D.ietf-opsawg-ipfix-alt-mark] "IPFIX Information Elements for Alternate Marking Method", Work in Progress, Internet-Draft, draft-ietf-opsawg-ipfix-alt-mark-07, 2026, . [I-D.ietf-ippm-on-path-telemetry-yang] "A YANG Data Model for On-Path Telemetry", Work in Progress, Internet-Draft, draft-ietf-ippm-on-path-telemetry-yang-05, 2026, . [I-D.ietf-spring-srv6-path-segment] "Path Segment in SRv6 (Segment Routing in IPv6)", Work in Progress, Internet-Draft, draft-ietf-spring-srv6-path-segment, . [I-D.ietf-grow-bmp-stats-informational-tlv] Srivastava, M., Kolenchery, S., and C. Lin, "BMP Statistics Information TLV", Work in Progress, Internet-Draft, draft-ietf-grow-bmp-stats-informational-tlv-00, 12 May 2026, . [I-D.ietf-nvo3-rfc7348bis] "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", Work in Progress, Internet-Draft, draft-ietf-nvo3-rfc7348bis-04, 2026, . [I-D.ietf-opsawg-collected-data-manifest] Claise, B., Quilbeuf, J., Lopez, D. R., Dominguez, I., and T. Graf, "A Data Manifest for Contextualized Telemetry Data", Work in Progress, Internet-Draft, draft-ietf-opsawg-collected-data-manifest-14, 19 August 2026, . Author's Address Saumya Dikshit Aruba Networks, Hewlett Packard Enterprise Email: saumya.dikshit@hpe.com