Network Working Group L. Melegassi Internet-Draft Catellix Intended status: Informational 17 May 2026 Expires: 18 November 2026 Multi-Vantage Path Snapshot (MVPS): A Canonical Bundle Format for Coordinated Traceroute Measurements draft-melegassi-ippm-mvps-bundle-00 Abstract This document specifies the Multi-Vantage Path Snapshot (MVPS) bundle format, a focused envelope for traceroute observations collected in coordination from two or more network vantages towards a common destination. MVPS defines a JSON serialization, a YANG 1.1 module, and a deterministic path-fingerprint algorithm enabling bit- reproducible auditing and cross-implementation interoperability. MVPS is intentionally minimal in scope: it specifies a wire format and the algorithms required to produce it deterministically. Analytical metrics derived from MVPS bundles are out of scope. MVPS complements the AURA architecture defined by RFC 9198, which specifies a measurement architecture but does not normatively specify the result format. MVPS is intended as one possible result format for AURA-style coordinated measurements. MVPS is also positioned relative to existing single-operator reporting formats (RIPE Atlas measurement JSON, CAIDA warts), which are not standardised and which do not provide a deterministic cross-implementation path identity. 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 18 November 2026. Melegassi Expires 18 November 2026 [Page 1] Internet-Draft MVPS Bundle May 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 4 1.2. Relationship to RFC 9198 (AURA) . . . . . . . . . . . . . 4 1.3. Relationship to Existing Reporting Formats . . . . . . . 5 1.3.1. RIPE Atlas Measurement Results . . . . . . . . . . . 5 1.3.2. CAIDA scamper / warts . . . . . . . . . . . . . . . . 5 1.3.3. Other Platforms . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 3. Known Limitations of This Revision . . . . . . . . . . . . . 6 3.1. Load-Balanced Paths . . . . . . . . . . . . . . . . . . . 6 3.2. Router Identity vs. Interface Identity . . . . . . . . . 7 3.3. ICMP Extensions and MPLS Labels . . . . . . . . . . . . . 7 3.4. Anycast Destinations . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 5. MVPS Bundle Format . . . . . . . . . . . . . . . . . . . . . 8 5.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 8 5.2. IPv6 Canonicalization: Deviation from RFC 5952 . . . . . 9 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Path Fingerprint Algorithm . . . . . . . . . . . . . . . . . 10 6.1. Construction . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Opaque Hops . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Test Vectors . . . . . . . . . . . . . . . . . . . . . . 11 7. Coordination Window Semantics . . . . . . . . . . . . . . . . 11 7.1. Window Width and Consumer Use . . . . . . . . . . . . . . 11 7.2. Clock Skew . . . . . . . . . . . . . . . . . . . . . . . 11 7.3. Temporal Uncertainty . . . . . . . . . . . . . . . . . . 12 8. Operational Considerations . . . . . . . . . . . . . . . . . 12 8.1. Parallel Collection . . . . . . . . . . . . . . . . . . . 12 8.2. Missing Hops . . . . . . . . . . . . . . . . . . . . . . 12 8.3. Typical Bundle Size . . . . . . . . . . . . . . . . . . . 12 8.4. Retention . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 Melegassi Expires 18 November 2026 [Page 2] Internet-Draft MVPS Bundle May 2026 10.1. Reconnaissance Amplification . . . . . . . . . . . . . . 13 10.2. Bundle Poisoning . . . . . . . . . . . . . . . . . . . . 13 10.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.4. Information Disclosure . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11.1. YANG Module Name . . . . . . . . . . . . . . . . . . . . 14 11.2. Media Type Registration . . . . . . . . . . . . . . . . 14 11.3. MVPS Bundle Capability Flags Registry . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. YANG Module (Normative) . . . . . . . . . . . . . . 17 Appendix B. JSON Schema (Informative) . . . . . . . . . . . . . 25 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 30 C.1. Minimal Single-Vantage Bundle . . . . . . . . . . . . . . 30 Appendix D. Conformance Test Vectors . . . . . . . . . . . . . . 32 Appendix E. Out-of-Scope Topics . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction Several existing systems coordinate traceroute measurements from distributed vantages towards a common target. Examples include RIPE Atlas, CAIDA Ark, ThousandEyes, and various operator-internal collection frameworks. These systems produce per-vantage observations whose joint analysis enables cross-vantage consistency checks (for example, applying a speed-of-light feasibility bound to pairs of observations of the same hop) and topology comparison (for example, quantifying path divergence between vantages). At the time of writing, no widely deployed envelope provides all of the following properties simultaneously: * A bit-reproducible canonical serialization that allows two independent implementations to produce identical artefacts from identical inputs. * A deterministic path-fingerprint allowing inexpensive path identity comparison and change detection across rounds. * An explicit coordination-window declaration with a bounded clock- skew uncertainty. * A YANG module suitable for use in network management contexts, with a sibling JSON serialization aligned via [RFC7951]. Melegassi Expires 18 November 2026 [Page 3] Internet-Draft MVPS Bundle May 2026 This document specifies such an envelope: the Multi-Vantage Path Snapshot (MVPS) bundle format. 1.1. Scope and Non-Goals In scope: * Bundle serialization (JSON and YANG, aligned via RFC 7951). * Deterministic path-fingerprint algorithm. * Coordination-window semantics with explicit uncertainty. * Conformance test vectors. * Privacy and security considerations for the envelope. Out of scope (see also Appendix E): * Definition of analytical metrics or anomaly detection. * Failure classification, regime detection, or operational dashboards. * Probing protocol details (this document describes a reporting envelope, not a measurement protocol). * Comparison frameworks against external observability platforms. 1.2. Relationship to RFC 9198 (AURA) [RFC9198] defines AURA, an architecture for large-scale active network measurement using cooperating agents. AURA addresses agent registration, capability advertisement, measurement task distribution, and result collection, but does not mandate a specific on-the-wire format for the per-vantage results of a coordinated measurement. MVPS does not replace AURA. An AURA-conforming collector MAY use MVPS as its bundle serialization format when coordinating traceroute measurements. Conversely, an MVPS producer is not required to operate within an AURA-managed deployment; standalone collectors are equally supported. Melegassi Expires 18 November 2026 [Page 4] Internet-Draft MVPS Bundle May 2026 1.3. Relationship to Existing Reporting Formats Several measurement platforms already publish results from coordinated traceroute campaigns in formats that overlap with MVPS in intent. This section briefly distinguishes MVPS from the most widely deployed of these. 1.3.1. RIPE Atlas Measurement Results RIPE Atlas [RIPE-Atlas-Measurements] publishes per-probe traceroute results as JSON, with a stable per-platform schema. The format is operationally mature, widely used, and well-documented, but it is (a) operator-specific, with no normative reference outside RIPE NCC documentation; (b) not aligned with a YANG model; (c) does not define a deterministic cross-implementation path identity; and (d) does not declare a coordination window or a clock-skew uncertainty at the level of a bundle aggregating multiple probes. MVPS aims to provide the same kind of operational utility in a vendor-neutral, RFC-style envelope with explicit coordination semantics and a fingerprint-level identity primitive. 1.3.2. CAIDA scamper / warts CAIDA's scamper tool [CAIDA-Warts] emits measurement results in the binary "warts" format. Warts is rich, efficient, and well-supported by the CAIDA tooling ecosystem, but it is binary, tool-specific, and not designed as a vendor-neutral interchange format. MVPS is text- based JSON (with an aligned YANG model) and is intended for cases where interchange and audit readability are primary concerns; warts and MVPS are therefore complementary rather than competing. 1.3.3. Other Platforms Other coordinated-measurement platforms (commercial and research) typically use proprietary formats. MVPS is intended to be a candidate common denominator for cross-platform publication of bundle-level results. 2. Terminology and Conventions This document uses the JSON data format [RFC8259], the YANG 1.1 data modelling language [RFC7950], common YANG data types from [RFC6991], RTT definitions consistent with [RFC2681], and UUIDs as defined in [RFC4122]. Melegassi Expires 18 November 2026 [Page 5] Internet-Draft MVPS Bundle May 2026 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. Vantage: A network position from which a traceroute measurement is initiated. Identified by a vantage-id (string) and OPTIONALLY by declared geolocation. Snapshot: A single per-vantage observation within a bundle. Contains the ordered hop list, RTT samples, timestamps, and metadata. Bundle: A collection of snapshots of a common destination, gathered within a single coordination window. Path Fingerprint: A deterministic cryptographic hash (SHA-256) of the canonicalized hop sequence of a snapshot, as defined in Section 6. Coordination Window: The time interval [start, end] within which all snapshots of a bundle MUST have been initiated. The width (end - start) declares the coordination tolerance. Hop: An intermediate router observed in a traceroute, identified by its responding IP address (when available) or by an opaque-marker. Opaque Hop: A hop for which the responding IP is not observable (for example, MPLS opaque LSRs, ICMP-disabled routers, or hops redacted per [RFC5837]). 3. Known Limitations of This Revision This revision (-00) makes a number of explicit simplifying choices. They are listed here so that reviewers and implementers can evaluate them up front; future revisions MAY relax some of these. 3.1. Load-Balanced Paths Standard traceroute can return different responding addresses at the same TTL when an intermediate router or load-balancer dispatches probes across multiple equal-cost next-hops. Paris traceroute [ParisTraceroute] and scamper avoid this by constraining the flow identifier across probes. In this revision, MVPS represents a hop as a single address (or opaque_marker); producers observing load- balanced behaviour SHOULD either (a) use a Paris-style probing discipline so that a single canonical hop is observed per TTL, or (b) Melegassi Expires 18 November 2026 [Page 6] Internet-Draft MVPS Bundle May 2026 emit several distinct bundles, one per flow identifier. A multi- address-per-hop encoding is left to a future revision. 3.2. Router Identity vs. Interface Identity A responding IP address identifies an interface, not a router. Two interfaces of the same router can produce different path-fingerprints even though the path traversed is operationally identical. This document treats path-fingerprints as a check on observational identity (same probed bytes produce same fingerprint), not on physical-router identity. Consumers requiring router- level identity SHOULD pair MVPS with an external alias resolution dataset. 3.3. ICMP Extensions and MPLS Labels ICMP extensions per [RFC4884] and the MPLS label information that can be carried in them ([RFC4950]) are not modelled in this revision. Implementations that capture such extensions MAY publish them in a vendor-specific reverse-DNS extension field, but interoperability of such fields is out of scope. 3.4. Anycast Destinations When the destination is an anycast address, different vantages can legitimately reach different sites, producing legitimately different path-fingerprints. The is_anycast flag carries this information so that consumers do not interpret divergent fingerprints as evidence of inconsistency in such cases. 4. Requirements The following requirements apply to producers of MVPS bundles. * *REQ-1.* An MVPS bundle MUST contain at least one snapshot. * *REQ-2.* All snapshots in a bundle MUST share the same destination. * *REQ-3.* Each snapshot MUST declare a vantage-id unique within the bundle. * *REQ-4.* Each snapshot MUST declare a start-timestamp. * *REQ-5.* The bundle MUST declare its coordination-window (start, end) as the envelope of its snapshots' start and end timestamps. * *REQ-6.* Each snapshot's path-fingerprint MUST be computed using the algorithm in Section 6. Melegassi Expires 18 November 2026 [Page 7] Internet-Draft MVPS Bundle May 2026 * *REQ-7.* Implementations MUST produce bit-identical bundles when given the same input traceroute data, by following the canonicalization rules in Section 5. * *REQ-8.* Implementations SHOULD support hop redaction per [RFC5837]. * *REQ-9.* Implementations MUST NOT include vantage credentials, operator-internal hostnames, or personally identifiable information in the bundle. * *REQ-10.* Implementations SHOULD declare a skew-bound-ms estimate (Section 7). * *REQ-11.* In a hop, the fields address and opaque-marker MUST be mutually exclusive: exactly one of them is present in a well- formed hop. 5. MVPS Bundle Format 5.1. Canonicalization To ensure bit-reproducibility (REQ-7), the JSON serialization of an MVPS bundle MUST apply the following canonicalization rules: * UTF-8 encoding, without byte-order mark. * Object keys sorted lexicographically (UTF-16 code unit order), at every nesting level. * No insignificant whitespace. * Numbers serialized in their shortest decimal representation; trailing zeroes after the decimal point are omitted, except as required to preserve declared precision (for example, declared_lat with 6 fraction digits). * IPv4 addresses in dotted decimal. * IPv6 addresses in the fully-expanded lowercase form (eight groups of four lowercase hexadecimal digits separated by ":"; no zero compression; no "::" shorthand). This is a *declared deviation* from [RFC5952], which mandates zero compression: see Section 5.2 for rationale. * Timestamps in RFC 3339 format with timezone "Z" (UTC). Melegassi Expires 18 November 2026 [Page 8] Internet-Draft MVPS Bundle May 2026 This document references the canonicalization rules of [RFC8785] (JSON Canonicalization Scheme) and deviates only where required for IP-address and timestamp normalization above. 5.2. IPv6 Canonicalization: Deviation from RFC 5952 [RFC5952] specifies a recommended textual form for IPv6 addresses that includes lowercase hexadecimal digits, suppression of leading zeros within each 16-bit group, and compression of consecutive all- zero groups using the "::" shorthand (with several disambiguation rules). Implementations of RFC 5952 differ in corner cases (selection of which all-zero run to compress when several are tied, handling of embedded IPv4, etc.), and these differences propagate directly into the SHA-256 path-fingerprint. To eliminate this source of cross-implementation drift, implementations of this document MUST use the fully-expanded lowercase form for IPv6 in both the on-the-wire representation and the canonical hop string used to compute the path-fingerprint (Section 6). The fully-expanded form is unambiguous: each address has exactly one textual representation, derivable trivially from the 128-bit integer. This deviation is intentional and is the only departure from RFC 5952 in this document. Implementations that render addresses for human display MAY apply RFC 5952 compression at presentation time, but MUST NOT use the compressed form in bundle output or in fingerprint input. 5.3. YANG Module The canonical YANG 1.1 module catellix-mvps-bundle is provided in Appendix A. The JSON serialization (Section 5.4) is the RFC 7951 encoding of this module, with the canonicalization rules in Section 5.1 applied. 5.4. JSON Schema A JSON Schema 2020-12 document expressing the same model is provided in Appendix B. Where the YANG module and the JSON Schema disagree, the YANG module is normative. 5.5. Examples Two examples are provided in Appendix C: a minimal one-vantage bundle and a four-vantage bundle with opaque hops and an anycast destination. Melegassi Expires 18 November 2026 [Page 9] Internet-Draft MVPS Bundle May 2026 6. Path Fingerprint Algorithm 6.1. Construction For each snapshot, the path-fingerprint is computed as follows: 1. Build the canonical hop string CANON: CANON = "v1|" || destination_canonical || "|" || join("|", [hop_token(h) for h in hops_in_index_order]) 2. For each hop h, hop_token(h) is defined as follows. * If h.address is present: "ip:" || canonical_ip(h.address). * If h.opaque_marker is present: "op:" || h.opaque_marker. * Otherwise (well-formed bundles cannot reach this branch, per REQ-11): "*". 3. canonical_ip(addr) is the lowercase, dotted- decimal representation for IPv4, and the fully-expanded lowercase form for IPv6 as defined in Section 5.2 (a declared deviation from [RFC5952]). 4. destination_canonical equals canonical_ip(bundle.destination.address). 5. path_fingerprint = lowercase_hex(SHA-256(UTF-8(CANON))). SHA-256 is specified in [RFC6234]. The leading "v1|" identifies the fingerprint version. Future revisions of MVPS that change the fingerprint algorithm MUST use a different prefix. 6.2. Opaque Hops Hops that respond but do not reveal an IP address (for example, MPLS opaque LSRs that do not generate ICMP Time Exceeded, or hops redacted per [RFC5837]) MUST be represented with an opaque-marker rather than a synthetic IP address. Implementations MUST NOT invent IP addresses for opaque hops. Hops that did not respond at all SHOULD be represented with opaque_marker = "noresp". Melegassi Expires 18 November 2026 [Page 10] Internet-Draft MVPS Bundle May 2026 6.3. Test Vectors A set of conformance test vectors is provided in Appendix D. Conformant implementations MUST reproduce all listed fingerprints bit-identically. 7. Coordination Window Semantics 7.1. Window Width and Consumer Use A bundle's snapshots are considered coordinated if all of them have start-timestamp values within the bundle's declared coordination- window [start, end]. The width (end - start) is the maximum coordination tolerance the producer is asserting. Smaller widths permit causality-sensitive analyses; larger widths only support coarser topology comparison. Consumers MAY filter or reject bundles whose window width exceeds an analysis-specific budget. This document does not normatively prescribe specific numeric thresholds; the appropriate budget depends on the consumer's intended use of the bundle. An optional informational hint (tolerance in the JSON serialization and the corresponding YANG leaf) MAY be carried to express the producer's intent at three reference orders of magnitude (sub-second, sub-minute, sub-five- minutes). The hint is non-normative; the only normative time bound on a bundle is its (end - start) value. 7.2. Clock Skew Vantage clocks are assumed to be synchronized via NTPv4 [RFC5905] or PTP. A bundle MAY declare skew_bound_ms as the producer's best estimate (upper bound) of the maximum pairwise clock skew across its vantages at the time of bundle creation. Bundles for which clock synchronization cannot be asserted MUST NOT declare a numeric skew_bound_ms value; consumers MUST NOT use such bundles for timing-sensitive cross-vantage analysis. The skew_bound_ms field is a declaration of uncertainty, not a measurement guarantee. Melegassi Expires 18 November 2026 [Page 11] Internet-Draft MVPS Bundle May 2026 7.3. Temporal Uncertainty When publishing bundles for use by third parties, implementations SHOULD document how skew_bound_ms was estimated (for example, via chronyc tracking offsets, NTP root-distance, or out-of-band PTP statistics). This document does not prescribe a single estimation method. 8. Operational Considerations 8.1. Parallel Collection A typical implementation initiates traceroute probes from all vantages within a short interval and aggregates the per-vantage results into a single bundle. The bundle's coordination-window MUST reflect the earliest start-timestamp and the latest end-timestamp across snapshots. 8.2. Missing Hops Hops that did not respond SHOULD be represented with opaque_marker = "noresp" rather than being silently omitted. The hop list maintains 1-based indices that match the TTL used by the probe. 8.3. Typical Bundle Size A bundle with 4 vantages, 10 hops per snapshot, and 3 RTT samples per hop typically serializes to a few kilobytes uncompressed. Implementations producing high collection rates SHOULD apply gzip or zstd compression at storage time. 8.4. Retention This document does not prescribe retention policies. Operators publishing bundles in compliance with regional regulation should consult their privacy frameworks (for example, GDPR, LGPD). 9. Privacy Considerations Bundles published as research datasets SHOULD apply the following measures: * Operator-internal IP addresses SHOULD be replaced with documentation prefixes per [RFC5737] (192.0.2.0/24, 198.51.100.0/24) or with opaque_marker = "redacted". * Hostnames MUST NOT appear in bundles (the format defines no field for hostnames). Melegassi Expires 18 November 2026 [Page 12] Internet-Draft MVPS Bundle May 2026 * Declared geolocation SHOULD be reduced to a granularity not finer than 0.01 degrees (approximately 1 km). * ASN values MAY be replaced with placeholders when publishing bundles where operator identity must remain confidential. Implementers should be aware that temporal correlation of path- fingerprints across publications can be used to reidentify operators even when individual fields are anonymized. 10. Security Considerations 10.1. Reconnaissance Amplification Coordinated multi-vantage probing can be misused as a reconnaissance amplifier: an attacker controlling a collection point can map internal network topology at a rate disproportionate to single- vantage probing. Implementations SHOULD apply rate-limiting on probe issuance, restrict the set of permitted destinations, and require authentication for control channels that trigger coordinated collection. 10.2. Bundle Poisoning A hostile or compromised vantage may produce a snapshot containing fabricated hops or RTT samples. Consumers SHOULD NOT rely on any single vantage's claims without corroboration. Sanity checks computed by consumers (for example, comparing observed cross-vantage RTTs against speed-of-light feasibility bounds, or comparing path- fingerprints across redundant vantages) can detect a subset of fabrications; the specific analytical machinery is out of scope of this document. A future revision MAY define an optional per-snapshot cryptographic signature to bind a snapshot to its declared vantage. 10.3. Replay Older bundles can be republished and presented as recent observations. Consumers SHOULD validate the coordination-window timestamps against an external time reference, and MAY chain bundles via cryptographic accumulators (out of scope of this document) to detect replay. Melegassi Expires 18 November 2026 [Page 13] Internet-Draft MVPS Bundle May 2026 10.4. Information Disclosure Declared latitude and longitude MUST respect the granularity guidance in Section 9. Path-fingerprints, being deterministic, can reveal the existence of recurring path patterns; this is intended behaviour but should be weighed against the operator's exposure model before publication. 11. IANA Considerations 11.1. YANG Module Name The YANG module shipped with this document uses the namespace urn:catellix:params:xml:ns:yang:catellix-mvps-bundle, which is under the author's control and does not require IANA action. If this document is adopted by an IETF working group, the module name SHOULD be renamed to ietf-mvps-bundle and the namespace to urn:ietf:params:xml:ns:yang:ietf-mvps-bundle in accordance with [RFC8407] section 4.3.1, and the following registration SHOULD be requested in the "YANG Module Names" registry ([RFC6020]): Name: ietf-mvps-bundle Namespace: urn:ietf:params:xml:ns:yang:ietf-mvps-bundle Prefix: mvps Reference: this document 11.2. Media Type Registration IANA is requested to register the media type application/mvps- bundle+json with the following parameters: Type name: application Subtype name: mvps-bundle+json Required parameters: none Optional parameters: none Encoding considerations: see RFC 8259 Security considerations: see Section 10 Interoperability considerations: this document Melegassi Expires 18 November 2026 [Page 14] Internet-Draft MVPS Bundle May 2026 Published specification: this document 11.3. MVPS Bundle Capability Flags Registry IANA is requested to create the "MVPS Bundle Capability Flags" registry, with assignment policy "Specification Required" ([RFC8126]). Initial contents: none. 12. Acknowledgements The author thanks the IPPM working group for prior work on AURA ([RFC9198]) and active measurement primitives, and acknowledges related work on coordinated Internet measurement at RIPE Atlas, CAIDA, and ThousandEyes whose deployment experience motivated this format. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010, . [RFC5837] Atlas, A., "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010, . [RFC5905] Mills, D., "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, . [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010, . [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011, . Melegassi Expires 18 November 2026 [Page 15] Internet-Draft MVPS Bundle May 2026 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 7950, August 2016, . [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, August 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, October 2018, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC9198] Alvarez-Hamelin, J., "Advanced Unidirectional Route Assessment (AURA)", RFC 9198, April 2022, . 13.2. Informative References [CAIDA-Warts] CAIDA, "scamper / warts file format", https://www.caida.org/catalog/software/scamper/, 2024. [ParisTraceroute] Augustin, B., Cuvellier, X., Orgogozo, B., Viger, F., Friedman, T., Latapy, M., Magnien, C., and R. Teixeira, "Avoiding traceroute anomalies with Paris traceroute", ACM IMC 2006, October 2006. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999, . Melegassi Expires 18 November 2026 [Page 16] Internet-Draft MVPS Bundle May 2026 [RFC4122] Leach, P., "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005, . [RFC4884] Bonica, R., "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007, . [RFC4950] Bonica, R., "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007, . [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013, . [RIPE-Atlas-Measurements] RIPE NCC, "RIPE Atlas Measurement Results (operational documentation)", https://atlas.ripe.net/docs/apis/result-format/, 2024. Appendix A. YANG Module (Normative) The full canonical module is distributed alongside this document as mvps-bundle.yang. An identical copy appears below. module catellix-mvps-bundle { yang-version 1.1; namespace "urn:catellix:params:xml:ns:yang:catellix-mvps-bundle"; prefix mvps; import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } organization "Catellix (individual submission; not yet adopted by any IETF working group)"; contact "Author: Leonardo Melegassi "; Melegassi Expires 18 November 2026 [Page 17] Internet-Draft MVPS Bundle May 2026 description "This YANG module defines the canonical data model for the Multi-Vantage Path Snapshot (MVPS) bundle envelope. An MVPS bundle is a coordinated collection of per-vantage traceroute snapshots gathered within a bounded coordination window towards a common destination. This module is the normative source. The JSON serialization follows RFC 7951 (JSON Encoding of Data Modeled with YANG) applied to this module, except that IP-address text forms follow the deviation declared in the companion specification (fully-expanded lowercase form for IPv6, NOT the compressed form of RFC 5952). This module does NOT define analytical metrics, anomaly detection, or failure classification. Such functions are out of scope and are addressed in companion documents. The namespace 'urn:catellix:params:xml:ns:yang:' is used because this is an individual submission and not yet adopted by an IETF working group; the 'urn:ietf:params:xml:ns:yang:' prefix is reserved for adopted IETF modules per RFC 8407 section 4.3.1. Copyright (c) 2026 Catellix and the contributors. Redistribution and use in source and binary forms, with or without modification, is permitted under the Revised BSD License (https://opensource.org/licenses/BSD-3-Clause)."; revision 2026-05-17 { description "Initial individual submission (-00)."; reference "draft-melegassi-ippm-mvps-bundle-00"; } /* * Typedefs */ typedef path-fingerprint { type string { length "64"; pattern "[0-9a-f]{64}"; } description "Lowercase hexadecimal representation of a SHA-256 digest computed over the canonical hop sequence of a snapshot, as Melegassi Expires 18 November 2026 [Page 18] Internet-Draft MVPS Bundle May 2026 defined in Section 5 of the MVPS specification. Note that the fingerprint uses fully-expanded lowercase IPv6 form, which is a declared deviation from RFC 5952; this is intentional to remove ambiguity from the canonicalization step."; } typedef opaque-marker { type enumeration { enum mpls { description "Hop is opaque due to an MPLS Label-Switched Path that does not generate ICMP Time Exceeded."; } enum redacted { description "Hop has been deliberately redacted by the implementation, typically per RFC 5837 considerations."; } enum noresp { description "Hop did not respond within the implementation's timeout."; } enum filtered { description "Hop was filtered by an intermediate device (e.g., ACL dropping ICMP)."; } } description "Reason category for an opaque hop, used when the responding IP address is unavailable."; } typedef coordination-tolerance { type enumeration { enum tight { description "Producer-asserted hint: window width is on the order of less than one second. Intended for causality-sensitive consumers. This is an INFORMATIONAL hint only; the only normative time bound is the (end - start) value of the coordination window."; } enum standard { description "Producer-asserted hint: window width is on the order of less than one minute. Intended for general topology Melegassi Expires 18 November 2026 [Page 19] Internet-Draft MVPS Bundle May 2026 comparison. INFORMATIONAL hint only."; } enum loose { description "Producer-asserted hint: window width is on the order of less than five minutes. Intended for opportunistic aggregation. INFORMATIONAL hint only."; } } description "Optional, non-normative producer hint about the intended use of a bundle's coordination window. Consumers MAY use this hint to pre-filter bundles, but MUST rely on the numeric (end - start) value when making normative decisions."; } /* * Groupings */ grouping vantage-identity { description "Identification of a measurement vantage."; leaf vantage-id { type string { length "1..64"; pattern "[A-Za-z0-9_\\-]+"; } mandatory true; description "Implementation-assigned identifier of the vantage, unique within a bundle. Implementations MUST NOT include operator-internal hostnames or personally identifiable information."; } leaf declared-asn { type inet:as-number; description "Autonomous System Number declared by the vantage operator, when known. Optional; absence MUST NOT be inferred as AS 0."; } leaf declared-lat { type decimal64 { Melegassi Expires 18 November 2026 [Page 20] Internet-Draft MVPS Bundle May 2026 fraction-digits 6; range "-90.0 .. 90.0"; } units "degrees"; description "Declared latitude (WGS-84) of the vantage. Implementations publishing bundles SHOULD round to a granularity not finer than 0.01 degrees (approximately 1 km)."; } leaf declared-lon { type decimal64 { fraction-digits 6; range "-180.0 .. 180.0"; } units "degrees"; description "Declared longitude (WGS-84) of the vantage. See declared-lat for granularity guidance."; } } grouping rtt-sample { description "A single round-trip-time measurement."; leaf value-ms { type decimal64 { fraction-digits 3; range "0.0 .. 60000.0"; } units "milliseconds"; mandatory true; description "Round-trip time in milliseconds."; } leaf probe-sequence { type uint16; description "Per-hop sequence number of the probe that produced this sample, when meaningful."; } } grouping hop { description "A single hop observed in a traceroute."; Melegassi Expires 18 November 2026 [Page 21] Internet-Draft MVPS Bundle May 2026 leaf index { type uint8 { range "1..64"; } mandatory true; description "1-based hop index in the path."; } leaf address { type inet:ip-address; description "Responding IP address of the hop, when observed."; } leaf opaque-marker { type opaque-marker; description "Reason for absence of address. MUST be present if and only if address is absent."; } list rtt-samples { key "value-ms"; uses rtt-sample; description "Observed RTT samples to this hop. An empty list is permitted (indicating no successful probe)."; } } grouping destination { description "Target of the coordinated measurement."; leaf address { type inet:ip-address; mandatory true; description "Destination IP address. Conformant implementations MUST use the same address across all snapshots in a bundle."; } leaf asn { type inet:as-number; description "ASN of the destination, when known."; } Melegassi Expires 18 November 2026 [Page 22] Internet-Draft MVPS Bundle May 2026 leaf is-anycast { type boolean; default "false"; description "True if the destination is known to be served by anycast."; } } grouping coordination-window { description "Temporal envelope of a bundle."; leaf start { type yang:date-and-time; mandatory true; description "Earliest snapshot start timestamp, in UTC."; } leaf end { type yang:date-and-time; mandatory true; description "Latest snapshot end timestamp, in UTC. MUST NOT be earlier than start."; } leaf tolerance { type coordination-tolerance; description "Declared coordination tolerance intent. Consumers MAY use this to filter bundles unsuitable for their analysis."; } leaf skew-bound-ms { type uint32; units "milliseconds"; description "Implementation's best estimate of the maximum pairwise clock skew across vantages in this bundle. Absence indicates that no estimate is provided and the bundle MUST NOT be used for timing-sensitive cross-vantage analysis."; } } grouping snapshot { description Melegassi Expires 18 November 2026 [Page 23] Internet-Draft MVPS Bundle May 2026 "A per-vantage observation in a bundle."; uses vantage-identity; leaf path-fingerprint { type path-fingerprint; mandatory true; description "Deterministic SHA-256 fingerprint of the canonical hop sequence. Computed as specified in Section 5 of the MVPS specification."; } leaf start-timestamp { type yang:date-and-time; mandatory true; description "UTC timestamp at which this snapshot's traceroute was initiated."; } leaf end-timestamp { type yang:date-and-time; description "UTC timestamp of snapshot traceroute completion."; } list hops { key "index"; ordered-by user; uses hop; min-elements 1; description "Ordered list of observed hops."; } } /* * Top-level container */ container bundle { description "A single MVPS bundle."; leaf bundle-id { type yang:uuid; mandatory true; Melegassi Expires 18 November 2026 [Page 24] Internet-Draft MVPS Bundle May 2026 description "UUID of this bundle. Implementations MUST generate it with sufficient entropy (RFC 4122)."; } leaf schema-version { type string { pattern "mvps-bundle-v[0-9]+"; } default "mvps-bundle-v1"; description "Schema version identifier. Conformant implementations of this document produce mvps-bundle-v1."; } container destination { uses destination; description "Common destination of all snapshots in this bundle."; } container coordination-window { uses coordination-window; description "Temporal envelope of this bundle."; } list snapshots { key "vantage-id"; min-elements 1; uses snapshot; description "Per-vantage observations. A bundle MUST contain at least one snapshot. A bundle with exactly one snapshot is well-formed but provides no cross-vantage information."; } } } Appendix B. JSON Schema (Informative) The JSON Schema 2020-12 document is distributed alongside this document as mvps-bundle.schema.json. It is provided for tooling convenience; where it disagrees with the YANG module in Appendix A, the YANG module governs. Melegassi Expires 18 November 2026 [Page 25] Internet-Draft MVPS Bundle May 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://catellix.com/schemas/mvps-bundle/v1.json", "$comment": "Companion of YANG module (RFC 7951).", "title": "MVPS Bundle v1", "description": "JSON serialization (RFC 7951).", "type": "object", "additionalProperties": false, "required": [ "bundle_id", "schema_version", "destination", "coordination_window", "snapshots" ], "properties": { "bundle_id": { "type": "string", "format": "uuid", "description": "RFC 4122 UUID, lowercase." }, "schema_version": { "const": "mvps-bundle-v1", "description": "Schema version identifier." }, "destination": { "$ref": "#/$defs/destination" }, "coordination_window": { "$ref": "#/$defs/coordination_window" }, "snapshots": { "type": "array", "minItems": 1, "items": { "$ref": "#/$defs/snapshot" }, "description": "Per-vantage observations." } }, "$defs": { "destination": { "type": "object", "additionalProperties": false, "required": ["address"], "properties": { Melegassi Expires 18 November 2026 [Page 26] Internet-Draft MVPS Bundle May 2026 "address": { "anyOf": [ { "type": "string", "format": "ipv4" }, { "type": "string", "format": "ipv6" } ], "description": "Destination IP. IPv6 fully-expanded (Sec 5.2)." }, "asn": { "type": "integer", "minimum": 0, "maximum": 4294967295 }, "is_anycast": { "type": "boolean", "default": false } } }, "coordination_window": { "type": "object", "additionalProperties": false, "required": ["start", "end"], "properties": { "start": { "type": "string", "format": "date-time", "description": "RFC 3339, UTC." }, "end": { "type": "string", "format": "date-time", "description": "RFC 3339, UTC. MUST NOT be earlier than start." }, "tolerance": { "type": "string", "enum": ["tight", "standard", "loose"] }, "skew_bound_ms": { "type": "integer", "minimum": 0 } } }, "snapshot": { "type": "object", "additionalProperties": false, Melegassi Expires 18 November 2026 [Page 27] Internet-Draft MVPS Bundle May 2026 "required": [ "vantage_id", "path_fingerprint", "start_timestamp", "hops" ], "properties": { "vantage_id": { "type": "string", "minLength": 1, "maxLength": 64, "pattern": "^[A-Za-z0-9_-]+$" }, "declared_asn": { "type": "integer", "minimum": 0, "maximum": 4294967295 }, "declared_lat": { "type": "number", "minimum": -90.0, "maximum": 90.0 }, "declared_lon": { "type": "number", "minimum": -180.0, "maximum": 180.0 }, "path_fingerprint": { "type": "string", "pattern": "^[0-9a-f]{64}$", "description": "Lowercase hex SHA-256 of canonical hop seq (Section 6)." }, "start_timestamp": { "type": "string", "format": "date-time" }, "end_timestamp": { "type": "string", "format": "date-time" }, "hops": { "type": "array", "minItems": 1, "items": { "$ref": "#/$defs/hop" } } } Melegassi Expires 18 November 2026 [Page 28] Internet-Draft MVPS Bundle May 2026 }, "hop": { "type": "object", "additionalProperties": false, "required": ["index"], "properties": { "index": { "type": "integer", "minimum": 1, "maximum": 64 }, "address": { "anyOf": [ { "type": "string", "format": "ipv4" }, { "type": "string", "format": "ipv6" } ], "description": "Responding IP of the hop, when observed." }, "opaque_marker": { "type": "string", "enum": ["mpls", "redacted", "noresp", "filtered"] }, "rtt_samples": { "type": "array", "items": { "$ref": "#/$defs/rtt_sample" }, "default": [] } }, "allOf": [ { "description": "Exactly one of address or opaque_marker.", "oneOf": [ { "required": ["address"], "not": { "required": ["opaque_marker"] } }, { "required": ["opaque_marker"], "not": { "required": ["address"] } } ] } ] }, "rtt_sample": { "type": "object", Melegassi Expires 18 November 2026 [Page 29] Internet-Draft MVPS Bundle May 2026 "additionalProperties": false, "required": ["value_ms"], "properties": { "value_ms": { "type": "number", "minimum": 0.0, "maximum": 60000.0 }, "probe_sequence": { "type": "integer", "minimum": 0, "maximum": 65535 } } } } } Appendix C. Examples C.1. Minimal Single-Vantage Bundle Melegassi Expires 18 November 2026 [Page 30] Internet-Draft MVPS Bundle May 2026 { "bundle_id": "11111111-1111-4111-8111-111111111111", "coordination_window": { "end": "2026-05-17T18:00:00.500Z", "start": "2026-05-17T18:00:00.000Z", "tolerance": "tight" }, "destination": { "address": "192.0.2.1", "is_anycast": false }, "schema_version": "mvps-bundle-v1", "snapshots": [ { "declared_lat": -23.55, "declared_lon": -46.63, "hops": [ { "address": "198.51.100.1", "index": 1, "rtt_samples": [{"value_ms": 1.234}] }, { "address": "198.51.100.42", "index": 2, "rtt_samples": [{"value_ms": 5.678}] }, { "address": "192.0.2.1", "index": 3, "rtt_samples": [{"value_ms": 12.345}] } ], "path_fingerprint": "55d4f7f8d6a4c5b9a8df7e6c3b2a190f5e4d3c2b1a0e9f8d7c6b5a4938271605", "start_timestamp": "2026-05-17T18:00:00.000Z", "vantage_id": "V0" } ] } (The fingerprint value above is illustrative; conformance test vectors carry exact expected values.) Melegassi Expires 18 November 2026 [Page 31] Internet-Draft MVPS Bundle May 2026 Appendix D. Conformance Test Vectors At minimum 20 conformance test vectors are distributed alongside this document under test-vectors/v01.json through test-vectors/vNN.json. Each vector contains: * a name identifying the case; * an input snapshot; * an expected_path_fingerprint. Implementations conformant to this document MUST reproduce every expected_path_fingerprint bit-identically. Appendix E. Out-of-Scope Topics For clarity to reviewers, the following topics are explicitly out of scope for this document and will be addressed, if at all, in companion documents: * Cross-vantage analytical metrics (speed-of-light feasibility bounds, Jensen-Shannon path divergence, topological-overlap measures, etc.). These belong in a companion Experimental-track document, not in the bundle-format specification. * Anomaly detection, failure classification, regime detection, critical-slowing-down indicators, or any other consumer-side analytical layer. * The probing protocol used to populate a bundle. MVPS is a reporting envelope; the probing protocol is independent (typical implementations use ICMP/UDP traceroute, but MVPS does not constrain this choice). * Visualization, dashboarding, or operator-facing user interfaces. Author's Address Leonardo Melegassi Catellix Brazil Email: melegassi@catellix.com URI: https://www.catellix.com Melegassi Expires 18 November 2026 [Page 32]