Summary

  • Revision 14 of draft-ietf-mpls-mna-ioam, posted on 11 September 2026, adds an explicit rule for an MPLS node whose load-balancing technique is unknown.
  • For a packet flow identified by Flow ID MNA, the 19-bit portion of Sequence Number MNA beginning at bit 1 of the LSE must remain immutable when the node hashes label-stack information—and now also when its technique is unknown.
  • The draft leaves discovery of a node's load-balancing technique out of scope. Freezing bits therefore reduces one possible source of path variation; it does not prove that the measurement path is stable.
  • Operators need a local receipt that records the hashing assumption, its evidence and the capture context before treating IOAM-DEX sequence observations as comparable.

A counter can become a steering input

The design problem sits at an awkward boundary between measurement and forwarding. IOAM Direct Export, or IOAM-DEX, can attach a Flow ID and a Sequence Number to packets so exported records can be correlated and loss or ordering can be studied. Under RFC 9326, the sequence normally begins at zero and advances by one for each packet of the same flow that carries DEX.

In the MPLS encoding proposed by draft-ietf-mpls-mna-ioam-14, the optional Flow ID MNA and Sequence Number MNA each occupy a complete 32-bit Format D Label Stack Entry. After the fixed leading bit and the MPLS bottom-of-stack S bit are removed, each carries a 30-bit value. That packaging matters because some devices can use label-stack information as an input to equal-cost or other flow load balancing. A value introduced to observe a flow can then influence which path that flow takes.

The draft already covered two known cases. If label-stack information is known to be part of the load-balancing decision, the 19-bit portion of Sequence Number MNA starting at bit 1 of the LSE must not change for a given Flow ID. If a node is known to use another technique, all sequence-number bits may vary. The official comparison of revisions 13 and 14 shows the new third branch: if the technique is not known, the same 19-bit portion must remain immutable.

That is a conservative default. Unknown behavior is treated like the label-stack-hash case rather than like permission to vary every bit. The text does not define a discovery protocol, configuration query or test for deciding which branch applies. It expressly leaves mechanisms for learning node load-balancing techniques outside scope.

What revision 14 actually changes

The change is narrow but normative. It does not redesign the IOAM architecture in RFC 9197, which already treats IOAM as a limited-domain facility and tells operators to consider interactions with ECMP and load balancing. Nor does it change the basic role of Flow ID in RFC 9326: the identifier can help correlate exports belonging to the same flow, while the method for assigning it remains outside that RFC.

Revision 14 also tightens adjacent encoding rules. It states that the Flow ID and Sequence Number use full Format D LSEs and that the corresponding LSE, including its fixed bits, must be absent when the presence flag is clear. When alternate marking is not used, the Post-Stack Block-Number now must, rather than should, be zero. Several illegal combinations—such as carrying a post-stack action inside a Network Action Sub-Stack or duplicating the in-stack DEX action in one sub-stack—are defined as malformed and require a drop.

These details sit inside the wider MPLS Network Actions architecture of RFC 9789 and its base solution in RFC 9994. The draft also depends on the evolving MNA post-stack header specification and maps existing IOAM fields, including entries in the IANA IOAM Trace-Type registry, into the proposed MPLS forms.

The procedural status remains important. The Datatracker document page identifies an active MPLS Working Group Internet-Draft intended for Proposed Standard. Its working-group state is “Submitted to IESG for Publication,” while the IESG state is “Publication Requested”; the history records the revisions. The requested action opcodes remain TBA. Revision 14 is evidence of edited proposed text, not an allocated code point, implementation report, interoperability event, IESG approval or RFC publication.

Nineteen fixed bits are not a stable path certificate

The rule removes one suspected perturbation: a changing sequence field should not churn the selected path merely because an unknown node happens to hash this part of the label stack. It cannot say which fields the node really hashes, whether the relevant label depth is visible, whether the hash behavior changes with configuration or software, or whether another node later in the path makes a different choice.

Nor can the Flow ID settle those questions by itself. It identifies the packet flow for the rule and helps correlate records; it does not certify that every node shares the same flow definition or that a telemetry probe is representative of uninstrumented production packets. A clean-looking sequence can coexist with path divergence, export loss, reordering elsewhere, or a mistaken assumption about the hash surface.

The security boundary is similarly explicit. The draft intends these actions for one trusted administrative domain. Border nodes must filter relevant packets arriving from another domain or an untrusted source before admission. Ancillary data may be carried in clear and must not be relied on for integrity without additional protection. Those statements make a sequence value evidence to be qualified, not a self-authenticating fact.

Sources