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 <[email protected]>
Para: "Leonardo Melegassi"<[email protected]>
Cc: "opsawg"<[email protected]>, "ippm"<[email protected]>,
"int-area"<[email protected]>
Data: qui., 14 mai. 2026 19:42:49 -0300
Assunto: [Int-area] Re: Enhancing traceroute with contextual per-hop analysis
(Traceroute Aurix)
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]
