Hi all,
A follow-up on my earlier message in this thread.
After incorporating feedback that the original -00 scope was too broad for an
IPPM individual submission, I replaced it with a narrower draft focused
strictly on the reporting envelope itself. The new revision was posted to the
Datatracker on 2026-05-17:
Datatracker:
https://datatracker.ietf.org/doc/draft-melegassi-ippm-mvps-bundle/
HTMLized:
https://datatracker.ietf.org/doc/html/draft-melegassi-ippm-mvps-bundle
Plain text:
https://www.ietf.org/archive/id/draft-melegassi-ippm-mvps-bundle-00.txt
HTML:
https://www.ietf.org/archive/id/draft-melegassi-ippm-mvps-bundle-00.html
XML source:
https://www.ietf.org/archive/id/draft-melegassi-ippm-mvps-bundle-00.xml
Title:
"Multi-Vantage Path Snapshot (MVPS): A Canonical Bundle Format for Coordinated
Traceroute Measurements"
Status:
Individual submission, Informational, 32 pages.
Scope change vs. the previous announcement
The new draft is intentionally restricted to a reporting-envelope specification:
a canonical bundle structure for coordinated multi-vantage traceroute
snapshots, expressed as both a YANG 1.1 module and an equivalent JSON Schema;
a deterministic SHA-256 path-fingerprint algorithm, including a documented
deviation from RFC 5952 for IPv6 canonicalisation (fully-expanded form used
solely for bit-reproducibility);
conformance test vectors with stable fingerprints;
a minimal Python reference implementation (stdlib only).
The following items from the earlier -observability-00 announcement are now
explicitly out of scope:
MVCI as an analytical or aggregate metric;
predictive layers (EWMA, surprise terms, coherence indices);
reverse-DNS namespace extensions;
dashboard or anomaly-detection semantics.
Those topics may still be useful as separate engineering or research work, but
they are intentionally excluded here so discussion can focus on the
interoperable bundle format itself.
Positioning
Section 1.3 relates MVPS to existing reporting formats, including RIPE Atlas
measurement JSON, CAIDA scamper/warts, Paris Traceroute, and RFC 9198 (AURA).
The contribution here is the canonical bundle plus deterministic
fingerprinting, not new measurement primitives.
Section 3 documents known limitations of this revision, including:
load-balanced paths;
router-versus-interface identity;
ICMP extensions / MPLS labels (RFC 4884 / RFC 4950);
anycast destinations.
Review feedback particularly appreciated
Whether the bundle envelope and YANG model are the right minimum for
interoperable coordinated-traceroute exchange.
Whether the fully-expanded IPv6 canonicalisation deviation from RFC 5952 is
acceptable for deterministic fingerprinting purposes.
Whether IPPM is the appropriate WG for an Informational reporting-format
document of this scope, or whether OPSAWG / Independent Stream would be more
appropriate.
The earlier broad-scope drafts (-observability-00 through -04) are now frozen
for historical reference and will not be revised further. Future revisions, if
any, will continue under draft-melegassi-ippm-mvps-bundle.
Thanks for reading.
Best regards,
Leonardo Melegassi
Catellix
(individual submission, no working-group affiliation)
mailto:[email protected]
Leonardo Melegassi
De: Leonardo Melegassi <[email protected]>
Para: "Leonardo Melegassi"<[email protected]>
Cc: "opsawg"<[email protected]>, "ippm"<[email protected]>,
"int-area"<[email protected]>
Data: sáb., 16 mai. 2026 08:12:05 -0300
Assunto: [Int-area] Re: Enhancing traceroute with contextual per-hop analysis
(Traceroute Aurix)
Hi all,
Following the previous discussion on MVPS and the MVCI analytical extension, an
initial Internet-Draft (-00) is now available.
This is currently an individual submission, intentionally short for a first
review cycle, and not yet submitted to the Datatracker.
draft-melegassi-ippm-mvps-observability-00
Multi-Vantage Path Snapshot (MVPS) and a Coherence-Based Framework for
Distributed Network Observability
Plain text:
https://www.catellix.com/draft-melegassi-ippm-mvps-observability-00.txt
xml2rfc v3:
https://www.catellix.com/draft-melegassi-ippm-mvps-observability-00.xml
The document consolidates material previously spread across the v83/v84
messages and subsequent follow-ups:
the MVPS reporting envelope;
the JSON Schema and canonical YANG 1.1 module;
the MVCI analytical extension;
and the optional predictive/coherence forecasting layer.
The MVPS wire structure itself is unchanged and remains aligned with RFC 9198
(AURA), RFC 7951 and RFC 7950.
MVCI continues to exist strictly as an optional analytical layer under the same
reverse-DNS namespace:
com.catellix.mvps.coherence_v1
Compared to the earlier mailing-list summaries, the -00 mainly adds three
things:
• The three primary axes (C₁ causal, C₂ informational, C₃ topological) are now
defined formally in one place, with explicit references to related prior work:
Padmanabhan & Subramanian (2002)
Bozkurt et al. IMC 2018
Lin (1991)
Endres & Schindelin (2003)
Holterbach et al. ANRW 2017
• The predictive layer (C̃₁, C̃₂, C̃₃) is now described more conservatively as
an experimental EWMA-based coherence forecaster over previous coherence states:
C₋₁, C₋₂, C₋₃
The operational signal remains limited to the surprise term:
Sᵢ = | Cᵢ(obs) − C̃ᵢ(pred) |
No additional protocol semantics or wire-level changes are introduced.
• A small reproducibility section was added, including:
a four-vantage real-world anycast experiment;
a deterministic synthetic validation battery;
and a small predictive loop over repeated rounds.
The collector and analytical engine referenced in the draft are intentionally
minimal and implemented in plain Python stdlib for reproducibility.
One question remains open from my side before iterating on -01:
Would OPSAWG/IPPM prefer:
MVPS and MVCI to remain together in a single informational draft;
or
the analytical/predictive components to be separated into independent documents
from the start?
My current preference is to understand that boundary early before expanding the
document further.
For anyone interested in the longer-form exposition (notation, extended
discussion, limitations and experimental tables), a companion academic paper is
also available:
https://www.catellix.com/mvps-mvci-paper-en.pdf
https://www.catellix.com/mvps-mvci-paper-pt.pdf
That paper is co-authored with Prof. Ricardo César Câmara Ferrari (IFSP) for
academic review purposes only. It is non-normative and not part of the
Internet-Draft itself.
Reviews, criticism and falsification attempts are very welcome, especially
regarding:
the coherence definitions;
operational usefulness;
overlap with existing work;
and the proposed document boundaries.
Thanks again for the careful discussion so far.
Best regards,
Leonardo Melegassi
Catellix
De: Leonardo Melegassi < mailto:[email protected] >
Para: "Leonardo Melegassi"< mailto:[email protected] >
Cc: "opsawg"< mailto:[email protected] >, "ippm"< mailto:[email protected] >,
"int-area"< mailto:[email protected] >
Data: sex., 15 mai. 2026 11:26:20 -0300
Assunto: [Int-area] Re: Enhancing traceroute with contextual per-hop analysis
(Traceroute Aurix)
_______________________________________________
Int-area mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
Hi all,
Just a brief weekend follow-up to the MVCI direction shared earlier,
to better clarify the conceptual intent behind it.
Most operational frameworks evolve progressively from the observed
state outward: measurement → aggregation → interpretation.
What I have been exploring is almost the inverse direction.
Instead of treating multi-vantage traceroute only as a forward
observational process, I started asking whether previous structural
states of coherence could constrain, explain, or anticipate future
observations — i.e., not only “what paths are doing now,” but also
“what prior coherence states make the current observation physically
and informationally plausible.”
That is why MVCI ended up organised around three orthogonal axes:
C₁ — causal coherence
(cross-vantage RTT triangle inequality; cf. Bozkurt et al.,
IMC 2018);
C₂ — informational coherence
(normalised Jensen–Shannon divergence between vantages;
Lin 1991, Endres & Schindelin 2003);
C₃ — topological coherence
(Jaccard complement on the union graph; cf. Holterbach et al.,
ANRW 2017).
Later, this extended to the predictive counterpart C̃₁ C̃₂ C̃₃, where
the tilde denotes a forecast at t+1 derived from antecedent states of
the same three axes (Cᵢ at t−1, t−2, …) — temporal depth over the
same coherence family rather than the introduction of additional axes.
As before, MVPS itself remains unchanged: the wire structure stays
RFC/YANG-aligned (RFC 9198 / RFC 7951 / RFC 7950), and MVCI exists
strictly as an optional analytic extension under the reverse-DNS
namespace com.catellix.mvps.coherence_v1, deterministic and
reproducible bit-by-bit.
That “reverse” perspective — examining antecedent coherence
conditions rather than only forward measurements — is probably the
main conceptual point I wanted to communicate more clearly.
The same WG question from my previous message remains open from my
side: whether this CORE-neutral derivational direction aligns with
what OPSAWG/IPPM would expect from a future informational draft, or
whether MVCI should instead be separated into its own document from
the beginning.
References:
• https://www.catellix.com/aurix-coherence-field.html
(Einstein → C₁, Shannon → C₂, Jaccard → C₃, predictive line C̃)
• https://www.catellix.com/tracerouteaurix.yang
(canonical catellix-mvps YANG module; RFC 7950 aligned)
Thanks again for the thoughtful routing suggestions and for taking
the time to read the drafts.
Best regards,
Leonardo Melegassi
Catellix
De: Leonardo Melegassi < mailto:[email protected] >
Para: "Leonardo Melegassi"< mailto:[email protected] >
Cc: "opsawg"< mailto:[email protected] >, "ippm"< mailto:[email protected] >,
"int-area"< mailto:[email protected] >
Data: qui., 14 mai. 2026 19:42:49 -0300
Assunto: [Int-area] Re: Enhancing traceroute with contextual per-hop analysis
(Traceroute Aurix)
_______________________________________________
Int-area mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
MVPS follow-up: MVCI derivational extension and multi-vantage coherence
Hi Med, Carlos, and all,
Quick follow-up on MVPS since v84.
While the v0.2 work aligned the reporting model with RFC 9198 (AURA) and
established a canonical YANG/RFC 7951 representation for multi-vantage
traceroute reporting, one question still remained open: why is multi-vantage
observability fundamentally stronger than an arbitrarily sophisticated
single-vantage trace?
In v85, we explored this question through a derivational extension called MVCI
(Multi-Vantage Coherence Index). Importantly, MVCI does not alter the MVPS core
model, the canonical YANG module, or any on-the-wire protocol behavior. It
lives entirely as an opt-in analytic extension under a reverse-DNS namespace
(com.catellix.mvps.coherence_v1), while the core MVPS envelope remains limited
to measurement facts.
The starting point is a cross-vantage physical consistency bound for any hop h
observed from two vantages V_a and V_b with known coarse geographic hints:
RTT_a(h) + RTT_b(h) >= 2 * d(V_a, V_b) / c_f
where d(V_a, V_b) is the great-circle distance and c_f is the effective
propagation speed in fibre. The inequality follows directly from the
signal-speed bound combined with the triangle inequality on the Earth surface.
MVCI then evaluates a multi-vantage bundle along three orthogonal axes:
C1 (causal coherence): checks whether shared-hop RTT observations violate the
physical lower bound above, producing a violation-rate term over all comparable
vantage pairs.
C2 (informational coherence): measures how distinct the empirical hop
distributions are across vantages using normalized Jensen-Shannon divergence.
C3 (topological coherence): measures route diversity through the Jaccard
complement of the edge sets derived from the multi-path union graph.
One interesting consequence is that these terms are structurally multi-vantage
by construction. For N=1, the causal pair comparison does not exist, the
normalized JSD degenerates, and the topological diversity term collapses
trivially. In that sense, MVCI behaves as a strict analytical superset of
single-vantage traceroute observability rather than as “just a better
traceroute”.
The implementation is intentionally lightweight and reproducible:
pure Python (stdlib only),
dependency-free,
reproducible bit-for-bit from the public RFC 7951 MVPS example already
published,
fully external to the canonical YANG model and JSON schema.
As a sanity check, the reference demo intentionally detects a physically
inconsistent synthetic RTT pair in the public example bundle, illustrating how
the framework can expose clock skew, geolocation inconsistencies, or
instrumentation issues without relying on an external oracle.
Question for the WG:
Does this direction (CORE-neutral analytic extensions over a stable MVPS
reporting model) look aligned with what OPSAWG/IPPM would expect from a future
informational Internet-Draft? Or would the WG prefer seeing MVCI documented
separately from the base MVPS reporting model itself?
References:
Theorem note: https://www.catellix.com/docs/mvps-theorem-v1.md
Reference impl.: https://www.catellix.com/static/mvps_theorem.py
Demo script: https://www.catellix.com/static/demo_mvps_theorem.py
JSON example: https://www.catellix.com/tracerouteaurix.json
YANG module: https://www.catellix.com/tracerouteaurix.yang
RFC 7951 example: https://www.catellix.com/tracerouteaurix.rfc7951.json
Thanks again,
Leonardo Melegassi
https://www.catellix.com?utm_source=chatgpt.com
Leonardo Melegassi
De: Leonardo Melegassi < mailto:[email protected] >
Para: "CARLOS JESUS BERNARDOS CANO"< mailto:[email protected] >, "opsawg"<
mailto:[email protected] >, "ippm"< mailto:[email protected] >, "mohamedboucadair"<
mailto:[email protected] >
Cc: "int-area"< mailto:[email protected] >
Data: qui., 14 mai. 2026 16:35:04 -0300
Assunto: [Int-area] Re: Enhancing traceroute with contextual per-hop analysis
(Traceroute Aurix)
_______________________________________________
Int-area mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
“Following suggestions from the INTAREA discussion…”
Hi Carlos, Med, and all,
Thanks Carlos for the suggestion, and thanks again Med for the earlier guidance
toward OPSAWG, IPPM, and BMWG.
The operational measurement/reporting aspects do indeed seem more aligned with
OPSAWG and IPPM at this stage, so I have now included those WGs in the
discussion to gather broader feedback on the modeling and reporting approach.
I appreciate the direction and the feedback from both of you.
Thanks again,
Leonardo Melegassi
https://www.catellix.com?utm_source=chatgpt.com
De: CARLOS JESUS BERNARDOS CANO < mailto:[email protected] >
Para: "Leonardo Melegassi"< mailto:[email protected] >
Cc: "int-area"< mailto:[email protected] >
Data: qui., 14 mai. 2026 15:34:44 -0300
Assunto: [Int-area] Re: Enhancing traceroute with contextual per-hop analysis
(Traceroute Aurix)
_______________________________________________
Int-area mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
Hi Leonardo,
I think you should post your questions to OPSAWG and IPPM as well (not sure if
you have done it on a different thread to avoid cross posting) to gather
feedback from those WGs.
Thanks,
Carlos
On Thu, May 14, 2026 at 3:43 PM Leonardo Melegassi <
mailto:[email protected] > wrote:
_______________________________________________
Int-area mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
MVPS follow-up: YANG model, RFC 7951 export, and RFC 9198 alignment
Hi Med, Carlos, and all,
Quick follow-up on MVPS since v79, aligned with the OPSAWG / IPPM / BMWG
direction Med suggested.
Since then, we evolved the reporting model to v0.2 with explicit RFC 9198
(AURA) alignment, including:
per-vantage flow_identity describing Member Route vs Route Ensemble reporting,
optional per-hop arrival/departure interface identifiers (RFC 5837),
arrival timestamps and RTD quartiles over a measurement window,
full backward compatibility with existing v0.1 JSON documents.
We also published the canonical model as a YANG 1.1 module:
Module: catellix-mvps
Namespace: https://catellix.com/yang/catellix-mvps
Revision: 2026-05-14
Imports: ietf-inet-types, ietf-yang-types (RFC 6991)
Validation: pyang --strict (clean)
Alongside the YANG module, we now provide:
an RFC 7951 example instance,
a JSON Schema sibling for backward compatibility,
export support for both classic JSON and RFC 7951 encodings.
The base model intentionally remains vendor-neutral and limited to measurement
facts. Derived analytics continue to live only under reverse-DNS extension
namespaces, and consumers MUST tolerate unknown keys.
Question for the WG:
Does this direction (canonical YANG model + RFC 7951 example + JSON Schema
compatibility layer) look closer to what OPSAWG or IPPM would expect from a
future informational Internet-Draft on multi-vantage traceroute reporting?
If useful, I would be happy to evolve this into an Internet-Draft -00 and align
naming / namespace conventions with WG guidance beforehand.
References:
JSON example: https://www.catellix.com/tracerouteaurix.json
YANG module: https://www.catellix.com/tracerouteaurix.yang
RFC 7951 example: https://www.catellix.com/tracerouteaurix.rfc7951.json
PDF overview: https://www.catellix.com/tracerouteaurix.pdf
Thanks again,
Leonardo Melegassi
https://www.catellix.com?utm_source=chatgpt.com
De: Leonardo Melegassi < mailto:[email protected] >
Para: "CARLOS JESUS BERNARDOS CANO"< mailto:[email protected] >
Cc: "int-area"< mailto:[email protected] >
Data: ter., 12 mai. 2026 09:09:44 -0300
Assunto: [Int-area] Re: Enhancing traceroute with contextual per-hop analysis
(Traceroute Aurix)
Hi Med, Carlos, and all,
Thanks, Med, for routing this toward OPSAWG, IPPM, and BMWG, that lines up well
with our intent.
Quick answer to Carlos on standards involvement: Traceroute Aurix doesn’t
introduce a new wire protocol. It builds on existing standards and operational
practice, IPv4 / IPv6 (RFC 791 / 8200), ICMPv4 / ICMPv6 (RFC 792 / 4443,
including the rate-limiting caveat in §2.4), router behaviour (RFC 1812), DNS
(RFC 1035), SSH (RFC 4251–4254), and RDAP (RFC 9082 / 9083) plus RIPEstat HTTPS
APIs for enrichment.
What is new on our side is an interoperable exchange/document format, not a
protocol: MVPS — Multi-Vantage Path Snapshot (mvps_schema: "catellix-mvps",
version 0.1), shipping in Catellix v79.0.0. MVPS is a versioned JSON document
that captures, in a comparable and reproducible way:
observed hop chains and inferred AS-path-like sequences per vantage;
per-hop RTT / loss as observed by the traceroute, plus per-vantage RTT
summaries (min / avg / p50 / p95 / max / stddev);
country traversal, vantage metadata, timestamps, enrichment provenance, and
explicit privacy annotations.
Each vantage carries three reproducible path fingerprints (IP-chain / AS-path /
country-path SHA-256), with the validation recipe included in the public
example so any consumer can re-derive them locally.
A core operational focus is dual-vantage measurement, combining a
cloud/server-side traceroute with an SSH-initiated edge/router-side traceroute
in the same time-bounded report, because forward-path asymmetry is common and a
single traceroute can be misleading.
Continuous loss/jitter time series and any 0–100 scoring intentionally live
outside the MVPS v0.1 envelope, illustrated as clearly labelled separable
blocks in the example. MVPS keeps the structured measurement facts; analytic /
verdict layers plug on top without polluting the interchange schema.
At this stage MVPS is an implementation and operational exchange format; the
goal now is operational feedback and validation in real-world troubleshooting
and measurement scenarios.
Public references:
JSON example (synthetic, with v0.2-candidate enrichments and validation
recipe): https://www.catellix.com/tracerouteaurix.json
PDF overview (English): https://www.catellix.com/tracerouteaurix.pdf
Repository pointers: schema/mvps-v0.schema.json, app/mvps_export.py,
frontend/static/tracerouteaurix.json,
docs/Traceroute_Aurix_Contribuicao_Mundial_v79.pdf.
If the community sees value, I would be glad to evolve this into an
informational Internet-Draft, a candidate fit could be IPPM (measurement
methodology) or OPSAWG (multi-party operational exchange), with
reproducibility-of-input considerations relevant to BMWG.
Thanks again,
Leonardo Melegassi
De: CARLOS JESUS BERNARDOS CANO < mailto:[email protected] >
Para: "Leonardo Melegassi"< mailto:[email protected] >
Cc: "int-area"< mailto:[email protected] >
Data: dom., 10 mai. 2026 08:22:56 -0300
Assunto: [Int-area] Re: Enhancing traceroute with contextual per-hop analysis
(Traceroute Aurix)
_______________________________________________
Int-area mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
Dear Leonardo,
(with no hats on)
Thanks for your e-mail. I'd like to ask you which IETF standards are
involved/used by your tool and/or if the tool uses additional protocols that
you have an interest in bringing to the IETF.
Thanks!
Carlos
On Thu, Apr 23, 2026 at 12:13 AM Leonardo Melegassi <
mailto:[email protected] > wrote:
_______________________________________________
Int-area mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
Hi all,
My name is Leonardo Melegassi, a network and telecommunications engineer and
the creator of the Catellix project.
I have been working on a practical approach to extend traditional traceroute
diagnostics, called "Traceroute Aurix", which is already implemented and
running in real-world scenarios.
While tools such as traceroute and MTR provide path discovery and continuous
measurements, they can be limited in exposing contextual behavior of each hop
and overall route quality in a structured way.
Aurix focuses on building a more analytical and enriched view of the path by
combining multiple dimensions of measurement and context.
In practical tests, the system is able to:
- Identify each hop with ASN and geolocation enrichment
- Measure per-hop minimum, average, and maximum latency, as well as jitter
- Evaluate the quality of each segment of the route
- Aggregate end-to-end metrics such as average latency, peak latency, and an
overall quality score
- Detect route consistency based on response rate and packet loss behavior
Additionally, the approach includes:
- Route discovery
- IP metadata enrichment
- Correlation analysis across hops
In one test case, traditional traceroute did not clearly expose route
instability, while Aurix highlighted latency variation and per-hop consistency,
making the issue more evident.
The goal is to evolve network diagnostics from a purely descriptive output to a
more analytical model that can support pattern identification, troubleshooting,
and operational decision-making.
I would appreciate feedback from the community, particularly regarding:
- The relevance of this approach
- Possible overlap with existing tools or ongoing work
- Potential directions for experimentation or standardization
I would be happy to share technical details, sample outputs, or further data if
there is interest.
Best regards,
Leonardo Melegassi
https://catellix.com
_______________________________________________
Int-area mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
