Exporting MVPS Coherence Events over Standard Telemetry Channels (syslog, IPFIX, YANG-Push)
draft-melegassi-opsawg-mvps-telemetry-export-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Leonardo Melegassi Costa | ||
| Last updated | 2026-05-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 15 errors, 8 warnings | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-melegassi-opsawg-mvps-telemetry-export-00
Operations and Management Area L. Melegassi
Internet-Draft Catellix
Intended status: Standards Track 28 May 2026
Expires: 29 November 2026
Exporting MVPS Coherence Events over Standard
Telemetry Channels (syslog, IPFIX, YANG-Push)
draft-melegassi-opsawg-mvps-telemetry-export-00
Abstract
Multi-Vantage Path Snapshot (MVPS) deployments raise coherence
events -- ALARM, BYZANTINE EVENT, and phase transitions such as
MPLS_CAMOUFLAGE_SUSPECTED -- that operators must ingest into existing
monitoring systems (Network Management Systems, SIEMs, time-series
collectors). This document specifies a single canonical MVPS event
object and three NORMATIVE, lossless mappings of that object onto
standard, vendor-neutral telemetry channels: structured syslog
(RFC 5424), IP Flow Information Export (IPFIX, RFC 7011), and
YANG-Push subscribed notifications (RFC 8639, RFC 8641) carried over
NETCONF or RESTCONF. A consumer MAY ingest MVPS events from any one
channel without loss of the fields required to reproduce the alarm
decision, and the same stable event identifier is carried on every
channel so that deduplication across channels is consistent.
This document specifies CHANNELS, not products. No monitoring
product is named normatively; a non-normative companion guide
demonstrates ingestion into one open-source system. Every mapping
property is validated by scripts/validate_telemetry_export.py
(8/8 PASS, exit 0) and recorded in
evidence/telemetry_export_receipt.json.
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 29 November 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. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Relationship to other MVPS documents . . . . . . . . . . 3
1.2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Canonical MVPS Event Object . . . . . . . . . . . . . . . 4
3.1. Fields . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Severity . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. The Stable Event Identifier . . . . . . . . . . . . . . . 6
4. Mapping A: Structured syslog (RFC 5424) . . . . . . . . . . . 7
5. Mapping B: IPFIX (RFC 7011) . . . . . . . . . . . . . . . . . 8
6. Mapping C: YANG-Push (RFC 8639/8641) . . . . . . . . . . . . 9
7. Cross-Channel Consistency Requirements . . . . . . . . . . . 10
8. Numerical Receipt . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. YANG Module . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Worked Example (all three channels) . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
An MVPS broker (see the MVPS bundle format
[I-D.melegassi-ippm-mvps-bundle] and the Coherence-BFD fast path
[I-D.melegassi-coherence-bfd]) emits operational events: it raises an
ALARM when the multi-vantage Mahalanobis distance D^2 crosses
threshold for M consecutive ticks, a BYZANTINE EVENT when max and
minimax aggregation diverge, and phase transitions such as
MPLS_CAMOUFLAGE_SUSPECTED [I-D.melegassi-ippm-mvps-mpls].
These events are useless if they cannot reach the operator's existing
tooling. Operators do not deploy new dashboards per framework; they
ingest into the Network Management System (NMS), SIEM, or time-series
collector they already run. Those systems consume a small set of
standard, vendor-neutral channels.
This document defines ONE canonical MVPS event object (Section 3) and
three NORMATIVE mappings onto those standard channels:
A. Structured syslog, RFC 5424 [RFC5424], using a registered
STRUCTURED-DATA element. Ubiquitous; every NMS/SIEM parses
it.
B. IPFIX, RFC 7011 [RFC7011], using enterprise-specific
Information Elements. For collectors already on a flow
pipeline.
C. YANG-Push subscribed notifications, RFC 8641 [RFC8641] over
the dynamic-subscription mechanism of RFC 8639 [RFC8639],
carried by NETCONF [RFC6241] or RESTCONF [RFC8040], using the
YANG module in Appendix A. For model-driven telemetry stacks.
The design goal is LOSSLESS, CONSISTENT export: a consumer reading
any single channel obtains every field needed to reproduce the alarm
decision, and the same stable event identifier (Section 3.3) appears
on all channels so cross-channel deduplication is well defined.
1.1. Relationship to other MVPS documents
This document is the EXPORT surface of the MVPS family. It does not
define new detection mathematics; it transports the events already
defined elsewhere:
o The event payload fields (D^2, phase, vantage count, Byzantine
fraction) are produced by the core detector
[I-D.melegassi-ippm-mvps-bundle] and its profiles.
o The MVPS Operational Log Format
[I-D.melegassi-opsawg-mvps-logging] is the INTERNAL, append-only,
tamper-evident record. THIS document is the EXTERNAL push to
third-party monitoring. An exported event SHOULD carry the
log seq and prev/record hash of its log entry so an investigator
can pivot from the NMS back into the anchored log.
o When integrity of the exported stream matters, the anchor head of
the Coherent-Witness Trust checkpoint
[I-D.melegassi-santos-ippm-mvps-cwt] and/or the Proof Envelope
[I-D.melegassi-ippm-mvps-proof-envelope] MAY be carried as an
opaque field; verification of that anchor is out of scope here.
1.2. Scope and Non-Goals
In scope:
o A canonical, hash-stable MVPS event object.
o Three lossless field mappings (syslog, IPFIX, YANG-Push).
o Cross-channel consistency rules (identifier, severity ordering).
Out of scope (NON-GOALS):
o Naming or endorsing any monitoring product. The mappings target
open standards; any conformant collector can consume them. A
separate, NON-NORMATIVE companion guide shows one open-source
ingestion as an illustration only.
o Transport security and authentication of the channels themselves;
these are provided by the underlying transports (syslog over TLS
[RFC5425]; NETCONF/RESTCONF over SSH/TLS). See Section 9.
o Re-specifying detection, trust, or log-integrity mathematics;
those live in the cited drafts and are not weakened or restated
here.
o A bidirectional control channel. This document is EXPORT only
(telemetry out); it defines no command or actuation path.
2. Terminology
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.
MVPS event object: the channel-independent, canonical representation
of a single MVPS operational event (Section 3).
Channel: one of the three standard telemetry encodings (syslog,
IPFIX, YANG-Push) onto which the event object is mapped.
Consumer: any NMS, SIEM, or collector that ingests one or more
channels.
Canonical form: the JSON Canonicalization Scheme (JCS) [RFC8785]
serialization of the event object, used for the stable identifier
and for the test vectors in Appendix B.
3. The Canonical MVPS Event Object
An MVPS event is a flat object of typed fields. The canonical form
is its JCS [RFC8785] serialization. Every channel mapping in
Sections 4-6 is a total function on this object: each REQUIRED field
maps to exactly one channel element, and no channel element is
introduced that does not correspond to a field defined here. This
one-to-one property is the basis of the lossless guarantee
(Section 7) and is checked by T-TEL-LOSSLESS-1.
3.1. Fields
+==================+==========+==========================+=========+
| Field | Type | Meaning | Req'd? |
+==================+==========+==========================+=========+
| event_id | string | Stable identifier | MUST |
| | | (Section 3.3) | |
+------------------+----------+--------------------------+---------+
| event_type | enum | alarm | byzantine | | MUST |
| | | phase | vantage | anchor | |
+------------------+----------+--------------------------+---------+
| severity | enum | Section 3.2 | MUST |
+------------------+----------+--------------------------+---------+
| timestamp | string | RFC 3339 UTC instant | MUST |
+------------------+----------+--------------------------+---------+
| bundle_seq | uint64 | Coordination-window seq | MUST |
+------------------+----------+--------------------------+---------+
| phi_d | decimal | Phase distance Phi_D | SHOULD |
+------------------+----------+--------------------------+---------+
| d2 | decimal | Mahalanobis D^2 | SHOULD |
+------------------+----------+--------------------------+---------+
| vantage_count | uint16 | N admitted vantages | SHOULD |
+------------------+----------+--------------------------+---------+
| byzantine_frac | decimal | Estimated f (0..1) | MAY |
+------------------+----------+--------------------------+---------+
| phase | enum | Operational phase label | SHOULD |
+------------------+----------+--------------------------+---------+
| path_fingerprint | string | 64 hex (bundle FP) | MAY |
+------------------+----------+--------------------------+---------+
| log_seq | uint64 | Log entry seq (logging) | MAY |
+------------------+----------+--------------------------+---------+
| log_record_hash | string | 64 hex (logging) | MAY |
+------------------+----------+--------------------------+---------+
| anchor_head | string | Opaque CWT/Envelope head | MAY |
+------------------+----------+--------------------------+---------+
Table 1: MVPS event fields
A producer MUST emit every field marked MUST; it SHOULD emit SHOULD
fields whenever the value exists; it MAY omit MAY fields. A consumer
MUST tolerate the absence of any non-MUST field.
The "phase" enumeration includes at least: NOMINAL, DEGRADED,
ALARM, BYZANTINE, MPLS_CAMOUFLAGE_SUSPECTED. Additional phase
labels MAY be defined by profiles; consumers MUST treat an
unrecognized phase as opaque and not as an error.
3.2. Severity
MVPS severity is an enumeration aligned ONE-TO-ONE with the syslog
SEVERITY numeric scale of RFC 5424 (Table 2 of [RFC5424]), so that
ordering is preserved across all channels by construction:
MVPS severity syslog code typical use
------------- ----------- ------------------------
emergency 0 (reserved; not emitted)
alert 1 fleet-wide BYZANTINE
critical 2 BYZANTINE EVENT
error 3 admission / auth failure
warning 4 ALARM raised
notice 5 phase transition
info 6 vantage join/leave
debug 7 diagnostic
The map severity -> syslog code is a strictly decreasing bijection on
the eight labels; lower numeric code means higher urgency. Every
channel mapping MUST preserve this ordering (T-TEL-SEV-1). Note that
the "audit" marker of the MVPS log format is NOT a severity here; an
audit event carries its own severity plus an audit=true marker, so
ordering remains total.
3.3. The Stable Event Identifier
event_id is a stable, channel-independent identifier computed as the
lowercase hex SHA-256 of the JCS serialization of the event object
with the "event_id" key itself removed:
event_id = SHA-256( JCS( event \ {event_id} ) ) [64 hex chars]
Two producers given the same event fields MUST compute the same
event_id (determinism), and the identifier MUST be carried unchanged
on every channel. Consumers use it as the deduplication key, so an
event delivered redundantly on two channels is recognized as one
event (T-TEL-IDEMPOTENT-1). Because event_id binds every field, a
field change yields a different identifier (T-TEL-CANON-1).
4. Mapping A: Structured syslog (RFC 5424)
Each MVPS event is emitted as one RFC 5424 SYSLOG message.
o PRI: PRIVAL = FACILITY * 8 + SEVERITY. FACILITY defaults to 16
(local0) and is configurable; SEVERITY is the code from
Section 3.2.
o HEADER: VERSION = 1; TIMESTAMP = the event timestamp in RFC 3339
with mandatory fractional seconds; HOSTNAME = broker host;
APP-NAME = "mvps"; MSGID = event_type.
o STRUCTURED-DATA: a single SD-ELEMENT with SD-ID "mvps@32473",
where 32473 is the example Private Enterprise Number reserved for
documentation [RFC5612]; a deployment MUST substitute its own
IANA-assigned PEN. Each event field of Table 1 becomes one
SD-PARAM whose PARAM-NAME is the field name and whose PARAM-VALUE
is the field value rendered as a UTF-8 string. The three
characters '"', '\', and ']' inside a PARAM-VALUE MUST be escaped
with a backslash per RFC 5424 Section 6.3.3.
o MSG: a short human-readable summary; it is informational and MUST
NOT be required to recover any field (all fields live in the
SD-ELEMENT).
Example (folded for layout; one physical line on the wire):
<132>1 2026-05-28T18:00:00.500Z broker01 mvps alarm.raise
[mvps@32473 event_id="b3d1..." event_type="alarm"
severity="warning" bundle_seq="41" d2="38.7" phi_d="0.91"
vantage_count="12" phase="ALARM"] ALARM D2=38.7 over M ticks
PRIVAL 132 = 16*8 + 4 (local0, warning). A consumer recovers the
event object by reading the SD-PARAMs; the round trip object ->
syslog -> object is lossless on all present fields (T-TEL-SYSLOG-1)
and the framing is well-formed (T-TEL-SYSLOG-2).
5. Mapping B: IPFIX (RFC 7011)
For collectors on a flow pipeline, each MVPS event is one IPFIX Data
Record described by an enterprise-specific Template (RFC 7011
Section 3.2, enterprise bit set, Private Enterprise Number as in
Section 4). Information Elements (abstract data types per RFC 7011
Section 6):
Field IE name (enterprise) abstractDataType
--------------- -------------------- ----------------
event_id mvpsEventId octetArray[32]
event_type mvpsEventType unsigned8 (enum)
severity mvpsSeverity unsigned8
timestamp mvpsEventTime dateTimeMilliseconds
bundle_seq mvpsBundleSeq unsigned64
d2 mvpsD2Milli unsigned32 (D^2*1000)
phi_d mvpsPhiDMilli unsigned32 (Phi_D*1000)
vantage_count mvpsVantageCount unsigned16
byzantine_frac mvpsByzFracMilli unsigned16 (f*1000)
phase mvpsPhase unsigned8 (enum)
path_fingerprint mvpsPathFingerprint octetArray[32]
Decimal fields are carried as fixed-point integers scaled by 1000
("milli" suffix) to avoid floating-point on the wire; a consumer
divides by 1000 to recover the value. The scale is exact for the
three decimal places that MVPS reports; encode/decode round-trips
within type width (T-TEL-IPFIX-1). event_id and path_fingerprint
are carried as the raw 32-octet digests, not hex.
Optional fields absent from a given event are omitted from the
Template for that record set; a collector keys records by the
Template ID it received.
6. Mapping C: YANG-Push (RFC 8639/8641)
For model-driven stacks, MVPS events are delivered as YANG
notifications via a dynamic subscription (RFC 8639) using the
periodic/on-change push mechanics of RFC 8641, transported over
NETCONF [RFC6241] or RESTCONF [RFC8040]. The notification is the
"mvps-coherence-event" of the YANG module in Appendix A.
Each event field of Table 1 maps to one leaf:
event_id -> leaf event-id (string, 64 hex)
event_type -> leaf event-type (enumeration)
severity -> leaf severity (enumeration)
timestamp -> leaf event-time (yang:date-and-time)
bundle_seq -> leaf bundle-seq (uint64)
d2 -> leaf d2 (decimal64 fd=3)
phi_d -> leaf phi-d (decimal64 fd=3)
vantage_count -> leaf vantage-count (uint16)
byzantine_frac -> leaf byzantine-frac (decimal64 fd=3)
phase -> leaf phase (enumeration)
path_fingerprint -> leaf path-fingerprint (string, 64 hex)
log_seq -> leaf log-seq (uint64)
log_record_hash -> leaf log-record-hash (string, 64 hex)
anchor_head -> leaf anchor-head (string)
The leaf types match the field types of Table 1; a notification
instance whose leaves carry the field values validates against the
module (T-TEL-YANG-1). REQUIRED fields are "mandatory true"; all
others are optional leaves.
7. Cross-Channel Consistency Requirements
A conformant producer MUST satisfy, for every event it emits:
C1 Identity. The event_id (Section 3.3) is byte-identical on every
channel the event is emitted on (T-TEL-IDEMPOTENT-1).
C2 Severity ordering. The severity-to-channel encoding preserves
the total order of Section 3.2 on every channel
(T-TEL-SEV-1).
C3 Lossless coverage. The union of fields recoverable from any one
channel includes every REQUIRED field and every SHOULD field the
producer populated; no channel may silently drop a populated
field (T-TEL-LOSSLESS-1).
C4 Canonical determinism. Given identical event fields, two
independent producers compute the same canonical form and hence
the same event_id (T-TEL-CANON-1).
A consumer that ingests more than one channel MUST deduplicate by
event_id and MUST NOT treat the same event arriving on two channels
as two distinct events.
8. Numerical Receipt
All properties of Sections 3-7 are validated CONSTRUCTIVELY by
scripts/validate_telemetry_export.py, which builds a synthetic event,
maps it onto all three channels, round-trips each mapping, and checks
C1-C4. It writes evidence/telemetry_export_receipt.json with the
per-check results, the demo event_id, and the platform fingerprint.
The validator returns exit 0 iff all eight checks
(T-TEL-CANON-1, T-TEL-SYSLOG-1, T-TEL-SYSLOG-2, T-TEL-IPFIX-1,
T-TEL-YANG-1, T-TEL-SEV-1, T-TEL-IDEMPOTENT-1, T-TEL-LOSSLESS-1)
pass.
9. Security Considerations
This document defines an EXPORT encoding; it does not itself provide
confidentiality, integrity, or authentication of the channel. Those
are the responsibility of the underlying transport:
o syslog MUST be carried over the TLS transport [RFC5425] when it
leaves a trusted segment; cleartext UDP syslog [RFC5426] is
acceptable only on an isolated management network.
o NETCONF/RESTCONF carry their own mandatory transport security
(SSH/TLS); subscription state is protected by that channel.
o IPFIX SHOULD use the transport protections of RFC 7011 Section 11.
The exported event reveals operational posture (alarm state,
Byzantine fraction, vantage count) that an adversary could use for
timing or reconnaissance. Producers SHOULD restrict export to
authenticated collectors and SHOULD NOT include optional fields
(path_fingerprint, anchor_head) on channels crossing untrusted
segments unless the transport is encrypted.
Because event_id binds every field by SHA-256, a consumer can detect
in-flight modification of a single channel's payload by recomputing
the identifier; this is an integrity CHECK, not a replacement for
transport authentication, and it does not by itself prove freshness
(replay protection is the transport's job).
This export path is strictly read-only: it carries no command,
configuration, or actuation, so it adds no remote-control attack
surface to an MVPS deployment.
10. IANA Considerations
This document requests, upon adoption:
o Registration of the YANG module "mvps-telemetry" (Appendix A) in
the "YANG Module Names" registry, with an assigned namespace URI
of the form urn:ietf:params:xml:ns:yang:mvps-telemetry.
o Allocation of the enterprise-specific IPFIX Information Elements
of Section 5 under the registrant's Private Enterprise Number;
these are enterprise elements and require no IANA IE allocation,
but are listed here for interoperability.
The SD-ID "mvps@32473" uses the documentation PEN 32473 [RFC5612];
deployments substitute their own PEN and no IANA action is required
for the syslog SD-ID.
This version (-00) defines no other IANA actions.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
March 2009.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, September 2013.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, September 2019.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, September 2019.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, January 2017.
11.2. Informative References
[RFC5425] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed.,
"Transport Layer Security (TLS) Transport Mapping for
Syslog", RFC 5425, March 2009.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",
RFC 5426, March 2009.
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
Documentation Use", RFC 5612, August 2009.
[I-D.melegassi-ippm-mvps-bundle]
Melegassi, L., "The MVPS Bundle Format", Work in Progress,
Internet-Draft, draft-melegassi-ippm-mvps-bundle-00.
[I-D.melegassi-coherence-bfd]
Melegassi, L., "Coherence-BFD", Work in Progress,
Internet-Draft, draft-melegassi-coherence-bfd-00.
[I-D.melegassi-ippm-mvps-mpls]
Melegassi, L., "MVPS Path Coherence under MPLS
Camouflage", Work in Progress, Internet-Draft,
draft-melegassi-ippm-mvps-mpls-00.
[I-D.melegassi-opsawg-mvps-logging]
Melegassi, L., "The MVPS Operational Log Format", Work in
Progress, Internet-Draft,
draft-melegassi-opsawg-mvps-logging-00.
[I-D.melegassi-santos-ippm-mvps-cwt]
Melegassi, L. and Santos, "Coherent-Witness Trust", Work
in Progress, Internet-Draft,
draft-melegassi-santos-ippm-mvps-cwt-00.
[I-D.melegassi-ippm-mvps-proof-envelope]
Melegassi, L., "The MVPS Proof Envelope", Work in
Progress, Internet-Draft,
draft-melegassi-ippm-mvps-proof-envelope-00.
Appendix A. YANG Module
This module defines the notification used by Mapping C. It is
non-normative pending IANA namespace assignment and is provided so
that the YANG-Push mapping is fully specified and machine-checkable.
<CODE BEGINS> file "mvps-telemetry@2026-05-28.yang"
module mvps-telemetry {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:mvps-telemetry";
prefix mvpst;
import ietf-yang-types { prefix yang; }
organization "Catellix Research";
contact "Leonardo Melegassi <melegassi@catellix.com>";
description
"Export notification for MVPS coherence events. Read-only
telemetry; carries no configuration or actuation.";
revision 2026-05-28 {
description "Initial -00 revision.";
reference "draft-melegassi-opsawg-mvps-telemetry-export-00";
}
typedef hex64 {
type string {
pattern '[0-9a-f]{64}';
}
description "Lowercase hex SHA-256 digest (64 chars).";
}
notification mvps-coherence-event {
description "One MVPS operational event.";
leaf event-id { type hex64; mandatory true; }
leaf event-type {
type enumeration {
enum alarm; enum byzantine; enum phase;
enum vantage; enum anchor;
}
mandatory true;
}
leaf severity {
type enumeration {
enum emergency; enum alert; enum critical; enum error;
enum warning; enum notice; enum info; enum debug;
}
mandatory true;
}
leaf event-time { type yang:date-and-time; mandatory true; }
leaf bundle-seq { type uint64; mandatory true; }
leaf d2 { type decimal64 { fraction-digits 3; } }
leaf phi-d { type decimal64 { fraction-digits 3; } }
leaf vantage-count { type uint16; }
leaf byzantine-frac { type decimal64 { fraction-digits 3; } }
leaf phase {
type enumeration {
enum NOMINAL; enum DEGRADED; enum ALARM; enum BYZANTINE;
enum MPLS_CAMOUFLAGE_SUSPECTED;
}
}
leaf path-fingerprint { type hex64; }
leaf log-seq { type uint64; }
leaf log-record-hash { type hex64; }
leaf anchor-head { type string; }
leaf audit { type boolean; default false; }
}
}
<CODE ENDS>
Appendix B. Worked Example (all three channels)
Canonical event object (JCS-serialized, pretty-printed here):
{
"anchor_head": "68d3f86d...",
"bundle_seq": 41,
"d2": 38.7,
"event_type": "alarm",
"phase": "ALARM",
"phi_d": 0.91,
"severity": "warning",
"timestamp": "2026-05-28T18:00:00.500Z",
"vantage_count": 12
}
event_id = SHA-256(JCS(object without event_id)). The exact value
for this example is printed by the validator and pinned in
evidence/telemetry_export_receipt.json (field "demo_event_id").
syslog (Mapping A): the message of Section 4.
IPFIX (Mapping B): one Data Record with mvpsD2Milli=38700,
mvpsPhiDMilli=910, mvpsBundleSeq=41, mvpsVantageCount=12,
mvpsSeverity=4, mvpsPhase=ALARM(enum), mvpsEventTime=the instant.
YANG-Push (Mapping C): an <mvps-coherence-event> notification whose
leaves carry the same values, d2=38.700, phi-d=0.910.
All three recover the identical event_id, demonstrating C1.
Author's Address
Leonardo Melegassi
Catellix Research
Email: melegassi@catellix.com