Summary
- The IESG approved
draft-ietf-mpls-mna-ps-hdr-19on 17 August 2026 for publication as a Proposed Standard. Its P bit, offsets, base header and length rules make a Post-Stack MPLS Header locatable and testable; approval does not demonstrate implementation, deployment or successful execution. - The draft explicitly allows a transit node whose Readable Label Depth cannot cover the complete post-stack header to skip its processing. Correct encoding and successful delivery therefore cannot substitute for per-node capability, depth, counter and action-result evidence.
A valid packet can carry a missing outcome
The opening path is hypothetical, not a reported failure. It matters because the packet need not look broken. Its MNA sub-stack can contain the proper indication, its Post-Stack MPLS Header can begin at the declared place, and its lengths can reconcile. A limited transit parser may still be unable to reach the complete container.
In that specific condition, the approved draft says the transit node simply skips post-stack processing. It does not say that insufficient readable depth always causes a drop. The packet can continue with the action unperformed at that node. Later inspection at the egress can confirm arrival and valid structure while saying nothing about the missing invocation in the middle.
That separates three statements operators often compress into one: an action was encoded; a node was meant to process it; the node actually processed it. The first is a property of the packet. The second depends on scope and path selection. The third requires evidence from the node.
The approved format makes the container discoverable
The IESG announcement of 17 August approved version 19 of the MPLS Network Action Post-Stack Header draft for publication as a Proposed Standard. Until the RFC Editor publishes it, it remains an Internet-Draft and several registry values remain marked TBA. Approval is a protocol milestone, not evidence that a vendor, ASIC or production network supports the design.
The format keeps the MNA sub-stack inside the MPLS label stack. A P bit in Format B indicates that a related Post-Stack MPLS Header follows the Bottom of Stack. The post-stack base header carries a first-nibble value, a length and a type; actions and their ancillary data follow.
The container does not always begin immediately after the label stack. A pseudowire control word, a Generic Associated Channel header or another post-stack structure may come first. A start-offset opcode identifies the location in four-octet units from the Bottom of Stack. When the relevant action sub-stack is the first one and no start offset is present, the default is zero. A later P-bit-bearing sub-stack needs an offset.
An optional end offset lets a parser determine the container’s extent and required depth without first parsing the container. The action lengths must sum to the declared PSMH length, which ranges from one to 255 four-octet words after the base header. Unexpected first nibbles, invalid offsets, inconsistent start and end values, and broken length accounting make a packet malformed and require a drop regardless of unknown-action policy.
Those rules are valuable. They turn ambiguity about where an action begins into mechanically checkable syntax. But a map to a room is not proof that every visitor can reach the room.
Readable depth becomes an admission constraint
The draft redefines Readable Label Depth for this context. Instead of counting only label-stack entries, RLD counts four-octet words from the top of the label stack. The change permits a capability statement to cover bytes beyond the Bottom of Stack.
That number has operational force. A node selecting a path needs to know the post-stack MNA capability of relevant transit and egress nodes, the path MTU and the RLD of every node that must inspect the action. The encapsulating node must not add the post-stack header if the egress lacks support, or if a transit node that will remove the associated network-action sub-stack cannot handle the P bit. It must also keep the packet within path MTU.
The draft does not specify how those facts are learned. Configuration, management protocols and control protocols are possible sources, but no discovery mechanism is standardized here. That omission is not a defect in packet syntax; it is an explicit boundary between format and operation. It also means a controller cannot treat “the standard was approved” as a capability signal.
Path computation must bind its decision to evidence with an owner and a time. Which software or hardware version supplied the advertised RLD? Was the value measured, configured or inferred? Did a line-card replacement, feature flag or encapsulation change invalidate it? Was the relevant node actually on the forwarding path? A stale maximum-depth claim can produce a syntactically perfect packet whose intended action is selectively absent.
Skip, malformed and unknown are different branches
Operational diagnosis becomes unreliable if every non-execution is called an unsupported action.
A malformed PSMH is one branch. Its structural checks fail, and the required result is a drop. An unknown action is another branch, governed by the unknown-action handling encoded in the associated MNA sub-stack for nodes that support the P bit. A node that does not support the P bit does not parse the post-stack header, so that derived handling cannot direct post-stack behavior there.
Insufficient RLD is a third branch. The transit node cannot read the complete PSMH and skips its processing. If it also cannot remove the associated PSMH because of depth or lack of start-offset support, it must not remove the MNA sub-stack carrying the P bit. The state stays coupled for a later capable node.
The penultimate-hop rules protect exposed hop-by-hop and ingress-to-egress state for the egress, and the egress removes associated post-stack headers when it removes the action sub-stack. These lifecycle rules prevent a convenient cleanup step from silently severing the indicator from its container. They do not manufacture proof that each earlier node invoked the action.
Scope names intent, not observation
MNA distinguishes hop-by-hop, ingress-to-egress and selected-node scopes. Scope answers where an action is intended to run. It is not a receipt from those nodes.
For a hop-by-hop action, end-to-end success requires more than seeing the packet at both ends. The operator needs to know which forwarding nodes were traversed, whether each supported the P bit and the particular action, whether each had enough RLD, whether local policy accepted the action, and whether invocation succeeded. For selected-node scope, the selection itself must be tied to current topology and capability state. For ingress-to-egress scope, preserving the container until egress is necessary but still not equivalent to a successful egress action.
The draft recommends counters for received PSMHs, RLD exceedance, unknown-action drop or skip, malformed drops and per-action successes and failures. Those counters are the beginning of an evidence model. They should be correlated with path, packet class, action identity, software state and time rather than collapsed into one aggregate “MNA packets processed” number.
The administrative border needs the deepest view
Post-stack actions are extensible, including locally defined actions whose semantics may be unsafe outside their intended domain. The security section therefore requires provider border nodes to be able to filter post-stack MNA packets arriving from another administrative domain before deployment. The filtering node’s RLD must exceed that of every other node inside the provider domain.
This is more than a capacity recommendation. It assigns the border an evidentiary role: the place expected to reject an unsafe external action must be able to see at least everything an internal node could see. A border whose parser is shallower than an internal router can certify only the portion it reached.
Post-stack data may also be modified by intermediate nodes. Critical functions should not rely on it without separate network-wide verification. Sensitive ancillary data must be encrypted in transit or kept out of this mechanism. Performance and scale are outside the draft’s scope, while BIER forwarding-router processing remains outside scope despite informational examples.
The honest deployment claim is consequently narrow: the approved specification defines how a post-stack container is indicated, located, checked and carried through defined lifecycle cases. Whether an operational path can safely and consistently execute it remains a capability, telemetry and governance question.
Sources
- IETF Datatracker — MPLS Network Action Post-Stack Header
- IETF Datatracker — document history
- IETF Datatracker — ballot write-up
- Approved draft text — version 19
- IETF announcement — protocol action
- IANA — MPLS Network Actions registries
- RFC 3032 — MPLS Label Stack Encoding
- RFC 4385 — Pseudowire Emulation Edge-to-Edge Control Word
- RFC 5586 — Generic Associated Channel
- RFC 9613 — MPLS Network Actions framework
- RFC 9789 — MPLS Network Action indicator
- RFC 9790 — MPLS Network Action sub-stack
- RFC 9791 — MPLS Network Action considerations
- RFC 9994 — MPLS Network Actions
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
