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