Summary

  • RFC 9994 specifies how an MPLS Network Action Sub-Stack carries action indicators and ancillary data. Its syntax is not evidence of path-wide capability, authority or outcome.
  • Scope, readable label depth, learned capabilities, unknown-action rules and node role determine whether and how a packet-borne action is handled.
  • A credible operational record separates encoding, admission, per-node handling, forwarding result and observed service effect.

An MPLS packet has traditionally been read as a sequence of forwarding labels. RFC 9994 adds a defined place in that sequence for something more expressive: a Network Action Sub-Stack, or NAS. It can carry a network action and ancillary data, and the RFC says MNA may influence forwarding decisions, carry OAM information or support user-defined operations. That is a real extension of packet grammar. It is not a transfer of operational sovereignty to a sender.

The first NAS entry uses the MNA base Special-Purpose Label, value 4; the next must be a Format B entry with an initial opcode and fields that describe the NAS. Further Format C and Format D entries can carry more actions and data. An opcode tells an implementation which semantic family is in view. It does not by itself supply the full contract for using that semantic family. RFC 9994 requires any document that defines a new Network Action Indicator to state its format, scope, ancillary-data syntax and quantity, processing procedure, and interactions with other actions. The allocation is a reference.

The action definition and local implementation still do the operative work.

That distinction matters because the word action tempts readers to compress too many stages into one event. A label can say an action is present. The next node may still be unable to read far enough into the stack, lack the relevant capability, regard the opcode as unknown, apply a scope rule that excludes it, reject malformed data, or process the action without producing the business or service result a sender expected. A packet is evidence of a request encoded in a common grammar. It is not a receipt.

Scope is a boundary, not a deployment report

RFC 9994 makes the boundary visible in the IHS field. A NAS has one scope for all its contained action indicators. Ingress-to-Egress means only the egress node processes the action. Hop-by-Hop means nodes on the path process the NAS. Select means only particular nodes that bring the NAS to the top of the stack perform it. Multiple scopes require multiple NASes.

Those labels are precise instructions for an MNA-capable implementation. They are not a claim that every intervening router is capable, reachable under the intended label depth, configured to participate, or known to the encapsulating node. The RFC therefore puts a serious duty on the encapsulating side: it must ensure that transit and egress nodes can process the NAS, and the resulting packet must fit the path MTU. Path selection needs information about MNA capabilities and readable label depth; that information may be configured, collected by management protocols or distributed by control protocols.

The means of learning it is outside the RFC's scope.

This is the operational fact hidden by a compact opcode: the path is not passive. It has its own capability state, readable-depth limits and control-plane knowledge. A sender that has not established those conditions has not established execution merely by encoding a NAS correctly.

The unknown-action field makes this even clearer. If a node does not understand an action, the U bit directs it either to skip to the next action or to drop the packet. The field is useful because it makes failure treatment explicit. It is not authentication, consent, a cross-domain authorization or a guarantee of graceful passage. The same syntactic NAS can therefore produce different permitted local responses depending on the action a node recognizes and the handling bit the sender set.

The node roles preserve local responsibility

RFC 9994 divides processing among roles rather than inventing a magic in-stack command. A transit node processes NASes in their prescribed order and follows the unknown-action rule. A penultimate node must keep the last exposed Hop-by-Hop or Ingress-to-Egress NAS so that egress can process it. An egress node removes any NAS it receives. An encapsulating node may add NASes in line with its policy, placement restrictions and learned capabilities.

The role separation is more than an implementation detail. It tells an operator where to look when an intended action and an observed result diverge. Was the action encoded? Was the path computed with readable-label-depth and capability information? Did the transit node recognize the opcode? Did a Select-scope node bring the NAS to top of stack? Did a penultimate operation preserve what egress needed? Was the NAS removed after processing? Without answers at those layers, “the MPLS action ran” is an assertion, not evidence.

Ancillary data must also be treated as data, not a clean audit trail. RFC 9994 warns that changing label-value bits can alter ECMP selection and reorder packets in a flow. In relevant deployments, mutable data must not be placed in those bits. The RFC proposes placement mitigations; it does not provide a universal performance assessment, a proof that local forwarding hash behavior is known, or an assurance that a future MNA application scales.

Its security and operational sections are equally restrained. An encapsulating action can affect nodes along a path; locally defined actions receive limited oversight; intermediate nodes may modify ancillary data; and sensitive data needs protection in transit. Provider border nodes need filtering capability before cross-administration MNA traffic is deployed. Useful counters include received MNA packets, processed NASes, per-action events and drops or skips caused by unknown actions. None of those recommendations creates a universal execution ledger.

Heng Lu's Running-Code Primacy provides the right editorial test. The shared specification should be as thin as interoperability requires. A packet may state an action, but operational truth arrives only through locally verifiable implementation and evidence. Syntax, learned capability, local admission, per-role handling, forwarding effect and service outcome are different reality layers. Confusing them gives a packet more authority than a running network has agreed to grant it.