Summary

  • Ordinary IOAM Direct Export postcards can identify every reporting router yet leave the multicast tree ambiguous because they do not say which downstream node followed which fork.
  • RFC 9630 adds an eight-octet Multicast Branch ID or exports accumulated trace at section boundaries, reducing redundant telemetry while preserving the correlation needed to rebuild the observed tree.
  • Operations still need separate receipts for option processing, branch-label epoch, export coverage, postcard transport, collector custody, reconstruction, receiver delivery and application outcome.

Every node was present; the edge was missing

Imagine a source packet passing A and reaching branching router B. One copy goes through C to E; another goes through D. Each router sends a postcard. The collector receives A, B, C, D and E, all with valid local observations. The inventory is complete. The topology is not. From those cards alone, E might follow C or D.

That is the failure RFC 9630 isolates. Per-hop export avoids copying the same upstream trace into every multicast replica, but node identity is not edge identity. A bag of truthful vertices does not encode a graph. Correlating the cards with a separately learned tree can fill the gap, yet then the claimed data-plane reconstruction depends on another evidence source.

The distinction is operationally important. A dashboard can show five green exporters while placing one node under the wrong parent. Delay or loss can then be attributed to the wrong link, and automation can move traffic away from an innocent branch. Completeness of records and correctness of relationships require different receipts.

Full traces repeat the common path

The alternative is to keep an IOAM trace in every packet. Before the first fork, that trace describes the common path. Replication copies it into each child packet. At the leaves, every copy carries the same prefix plus its own branch suffix. The method preserves adjacency, but repeats the largest shared section as the tree grows.

RFC 9630 treats this as more than storage inconvenience. Repeated trace consumes packet header space and bandwidth and creates work at the collector. Large or deep trees multiply the same evidence. The system can preserve graph structure while becoming too expensive to observe at the rate operators need.

The design problem is therefore not “trace or postcards” in the abstract. It is how to retain the minimum join information that makes separate observations composable. RFC 9630 supplies two answers, each with a different execution boundary.

The Branch ID names a forked edge

The DEX solution carries a Multicast Branch ID from one branch fork until the next. Its semantic tuple is a three-octet Branching Node ID plus a two-octet Interface Index. Three padding octets bring the optional field to eight octets. A fork assigns a distinct identifier to each outgoing branch in the multicast-tree instance, and every downstream observer exports the received identifier in its postcard.

Flow ID and Sequence Number correlate cards belonging to the same observed traffic. The Branch ID says which section of the tree joins them. Now E's card can carry the branch created for B-to-C, while D carries B's other branch. The collector no longer has to guess the parent edge from the set of node names.

This is a precise receipt, not a universal identity. The Interface Index is meaningful with the Branching Node ID and the relevant tree/configuration epoch. Reuse after a topology change may be legitimate. An archive that discards time, namespace, flow and sequence context can make two locally valid labels look like one durable branch.

Two bits must travel together

RFC 9326 assigns four octets to each DEX extension flag. The Branch ID needs eight, so RFC 9630 uses two flags. N announces the Branching Node ID half; I announces the Interface Index half. Both must be set or both clear. A half-present identifier is malformed and the packet must be dropped.

The unused octets must also be zero. Nonzero padding makes the header malformed and again requires a drop. These rules prevent a permissive parser from manufacturing an adjacency label from incomplete or ambiguous bytes.

That strictness creates an observable failure mode. A drop is not merely “telemetry unavailable”; it is data traffic affected by invalid telemetry encoding. Operators need counters that distinguish absent optional telemetry, rejected malformed telemetry and downstream postcard loss. Collapsing all three into a missing branch hides whether the problem occurred in packet construction, forwarding or export custody.

Section postcards move the cut line

RFC 9630's second solution keeps the ordinary trace format. At a branch node, the accumulated trace is exported before replication. Each copy then begins a new section seeded with the branch node's information; the node-data list is cleared and RemainingLen reset. Leaf nodes export the final sections.

The collector receives path segments rather than either full duplicated traces or isolated vertices. The shared prefix is sent once, and the branch node provides the join between parent and child sections. No new trace header format is required, but the configuration of every fork and leaf becomes part of the evidence.

A fork can export only facts common before the copies diverge. Ingress interface and ingress timestamp may be shared; egress interface, egress timestamp and per-copy delay are branch-specific. If an implementation records a single egress fact before replication, it has compressed away precisely the difference the telemetry is supposed to reveal.

Sampling limits coverage before reconstruction begins

RFC 9630 explicitly leaves traffic-subset selection and protection of the network or collector from overload out of scope. Its security section warns that multicast's built-in amplification makes DEX export risk greater than in unicast. It recommends packet selection, export-rate limits or enabling only a subset of nodes, such as branch routers.

Those are sensible controls, but they change the claim. A reconstructed tree is the tree evidenced by the selected packets and enabled observers. It is not automatically the tree followed by every packet. A missing postcard may mean a lost export, an uninstrumented node, rate limiting, sampling exclusion, collector rejection or an actual missing branch.

Coverage must therefore be first-class metadata. Record the selector, sample probability or rule, enabled-node set, export cap, drop counters, collector admission policy and effective time. Without them, a neat tree diagram can conceal large regions where no observation was possible.

Mtrace2 and the control plane answer another question

Mtrace2 follows multicast tree-building messages from a receiver toward the source and appends diagnostic response blocks. It can help a management system learn routers of interest. RFC 9630 notes that Mtrace2 does not integrate directly with IOAM, and each multicast protocol needs its own on-path treatment.

Control-plane state is valuable corroboration. It can show the path routers intended to build. DEX and trace postcards describe selected data-plane observations. Agreement strengthens confidence; disagreement is a diagnostic signal. Substituting one for the other destroys that distinction.

For PIM, PIM-SSM, MVPN, mLDP, P2MP RSVP-TE, ingress replication or PIM MDT, retain the protocol and tunnel context alongside the IOAM tuple. The same visible node sequence can have different forwarding meaning under another tree, VPN or tunnel epoch.

Reconstruction is not delivery

RFC 9630 aims to reconstruct and visualize the multicast tree, measure delay and jitter, and locate packet drops. The Branch ID makes the postcards correlatable enough to support that analysis. It does not place a receipt inside the receiver application.

A leaf-router observation may precede an access-link loss. A receiver may obtain the packet but fail to decode a keyframe. A correct path for one sampled sequence does not prove the behavior of an unsampled burst. A collector may build the right tree from late cards after the service incident has already ended.

Preserve the layers: packet admitted to the IOAM domain; option processed; fork label created; postcard emitted; postcard transported; collector retained it; graph reconstructed; forwarding corroborated; receiver observed the packet; application produced a usable outcome. Moving directly from “tree reconstructed” to “customers received the stream” is the same category error in a more attractive diagram.

Build a topology receipt that survives an incident

For each reconstruction, retain the IOAM namespace, Flow ID, Sequence Number, source and group, multicast-tree identifier, tunnel context and time window. For every fork, retain raw Branch ID bytes, decoded node and interface components, configuration epoch and validation result. For every postcard, retain exporter identity, exact node data, transmission time, collector arrival, duplicate status and custody hash.

The graph builder should report unexplained vertices, missing parents, collisions, duplicate sequence observations and edges inferred from external control-plane data. It should never silently draw an edge because the layout engine needs one. An incomplete graph is more useful than a complete fiction.

Finally, link receiver-side evidence without merging it into the topology claim. RFC 9630 gives operators a better language for the observed multicast tree. Leadership earns trust by preserving where that language stops.

Sources