| Internet-Draft | MPLS OPT MNA Flag for OAM | August 2026 |
| Song, et al. | Expires 11 February 2027 | [Page] |
This document describes postcard-based on-path telemetry with packet marking (PBT-M) using an MPLS Network Actions (MNA) flag to support Operations, Administration, and Maintenance (OAM) in MPLS networks. The scheme uses a single flag bit carried in a Flag-Based Network Action Indicator (Opcode 1) of the MNA Sub-Stack as defined in RFC 9994. In addition to addressing the protocol requirements for applying PBT-M, this document provides comprehensive operational, manageability, and security considerations.¶
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 11 February 2027.¶
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.¶
To gain detailed data plane visibility to support effective network OAM, it is essential to be able to examine the trace of user packets along their forwarding paths. Such on-path flow data reflect the state and status of each user packet's real-time experience and provide valuable information for network monitoring, measurement, and diagnosis.¶
The telemetry data include but not limited to the detailed forwarding path, the timestamp/latency at each network node, and, in case of packet drop, the drop location as well as the reason. The emerging programmable data plane devices allow user-defined data collection or conditional data collection based on trigger events. Such on-path flow data are from and about the live user traffic, which complements the data acquired through other passive and active OAM mechanisms such as IPFIX [RFC7011] and ICMP [RFC4560].¶
On-path telemetry was developed to cater to the need of collecting on-path flow data. There are two basic modes for on-path telemetry: the passport mode (e.g., IOAM trace option [RFC9197]) and the postcard mode (e.g., IOAM direct export option (DEX) [RFC9326]).¶
In MPLS networks, MPLS Network Action (MNA) [RFC9789] extends the MPLS label stack by supporting extra in-stack network actions and ancillary data encoded in stack, the in-stack MNA Sub-Stack is described in [RFC9994]. MNA also extends the MPLS payload by supporting extra post-stack network actions and ancillary data encoded post-stack, the post-stack MNA header is described in [I-D.ietf-mpls-mna-ps-hdr].¶
This document describes the method to apply a new variation of the postcard mode on-path telemetry, PBT-M, to MPLS networks using an MNA flag only. PBT-M does not require a telemetry instruction header but a single trigger bit in MNA flags. A similar mechanism has been adopted for SRv6 OAM [RFC9259], which uses the O-bit in SRH flags as the marking bit to trigger on-path telemetry. The key benefits of PBT-M are its low overhead and high flexibility. However, extracting telemetry data in this manner introduces unique protocol requirements, alongside critical operational and manageability challenges that must be addressed for real-world deployment. This document discusses these requirements and provides comprehensive solutions for MPLS networks. Crucially, it outlines the operational guidelines necessary for safe deployment, including concrete mechanisms for load control, DoS mitigation, configuration scalability, and managing telemetry across partially upgraded forwarding paths.¶
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 [BCP14] ([RFC2119] and [RFC8174]) when, and only when, they appear in all capitals, as shown here.¶
As the name suggests, PBT-M only needs a marking-bit in the existing headers of user packets to trigger the telemetry data collection and export. The sketch of PBT-M is as follows. If on-path data need to be collected, the user packet is marked at the path head node. At each PBT-M-aware node, if the mark is detected and data collection is enabled, a postcard packet (i.e., the dedicated OAM packet triggered by a marked user packet) is generated and sent to a collector. The postcard contains the data requested by the management plane. The requested data are configured by the management plane. Once the collector receives all the postcards for a single user packet, it can infer the packet's forwarding path and analyze the data set. The path end node is configured to un-mark the packets to its original format if necessary.¶
The overall architecture of PBT-M is depicted in Figure 1.¶
+------------+ +-----------+
| Network | | Telemetry |
| Management |(-------| Data |
| | | Collector |
+-----:------+ +-----------+
: ^
:configurations |postcards
: |(OAM pkts)
...............:.....................|........
: : : | :
: +---------:---+-----------:---+--+-------:---+
: | : | : | : |
V | V | V | V |
+------+-+ +-----+--+ +------+-+ +------+-+
usr pkts | Head | | Path | | Path | | End |
====>| Node |====>| Node |====>| Node |====>| Node |===>
| | | A | | B | | |
+--------+ +--------+ +--------+ +--------+
mark usr pkts gen postcards gen postcards gen postcards
gen postcards unmark usr pkts
The advantages of PBT-M are summarized as follows.¶
1: PBT-M avoids augmenting user packets with large headers and the signaling for telemetry data collection remains in the data plane.¶
2: PBT-M is extensible for collecting arbitrary new data to support possible future use cases. The data set to be collected can be configured through the management plane or control plane.¶
3: PBT-M does not incur extra user packet processing (e.g., packet editing and augmenting) on the transit nodes. The collected data are free to be transported independently through in-band or out-of-band channels. The data collecting, processing, assembly, encapsulation, and transport are, therefore, decoupled from the forwarding of the corresponding user packets and can be performed in data-plane slow-path if necessary.¶
4: For PBT-M, the head node only provides a trigger without stipulating the data types to be collected, and each transit node can export data based on its local configuration which can vary depending on application requirements and node capability.¶
5: PBT-M makes it easy to secure the collected data without exposing it to unnecessary entities. For example, both the configuration and the telemetry data can be encrypted and/or authenticated before being transported, so passive eavesdropping and a man-in-the-middle attack can both be deterred.¶
6: Even if a user packet under inspection is dropped at some node in the network, the postcards collected from the preceding nodes are still valid and can be used to diagnose the packet drop location and reason.¶
7: Raw data can be processed or aggregated in data plane to reduce the exporting traffic load.¶
Although PBT-M has some unique features, it also introduces a few new requirements.¶
Req. 1 (Packet Marking Bit): A user packet needs to be marked to trigger the path-associated data collection. Therefore, PBT-M needs to reserve or reuse a single bit from existing header fields in a specification (e.g., MNA encoding in [RFC9994]).¶
Req. 2 (Configuration): Since the packet header will not carry telemetry instructions anymore, the data plane devices need to be configured to know what data to collect. However, in general, the forwarding path of a flow packet (due to ECMP or dynamic routing) is unknown beforehand. If the per-flow customized data collection is required, configuring the data set for each flow at all data plane devices might be expensive in terms of configuration load and data plane resources.¶
Req. 3 (Data Correlation): Due to the variable transport latency, the dedicated postcard packets for a single packet may arrive at the collector out of order or be dropped in networks for some reason. In order to infer the packet forwarding path, the collector needs some information from the postcard packets to identify the user packet affiliation and the order of path node traversal.¶
Req. 4 (Overhead and Security): The overall network bandwidth and postcard generating/processing overhead of PBT-M can be high. A large number of postcards could add processing pressure on all transit nodes sending postcards as well as data collecting servers. This can be used as an attack vector for DoS.¶
To address the above requirements, we propose several design details for applying PBT-M in MPLS networks.¶
To trigger the path-associated data collection, usually, a single bit from some header field is sufficient. The proposed action encoding is shown in Figure 2 using the MNA Sub-Stack formats defined in [RFC9994].¶
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA-Label = bSPL (4) | TC |S| TTL | (A)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1 | Data=0 |R|IHS|S|NASL=1 |U|NAL=1| (B)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Data=0 |S|P| 0 | (D)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the figure, three LSE formats defined in [RFC9994] are used to form the Network Action Sub-Stack (NAS). Format A (labeled A) is the MNA Sub-Stack Indicator carrying the MNA bSPL (value 4). Format B (labeled B) is the Initial Opcode LSE; it uses the Flag-Based Network Action Indicators without Ancillary Data opcode (Opcode 1, Section 6.2 of [RFC9994]), sets the scope (IHS) for the whole NAS, and points (NAL=1) to one following Format D LSE. Format D (labeled D) carries the PBT-M indicator (P-flag). No Format C LSE is needed, since a Format D LSE only requires a preceding Format A and Format B LSE (Section 4.4 of [RFC9994]).¶
The PBT-M indicator (P-flag) is carried as a single flag in the Format D data field. If the bit is set to '1', every PBT-M-aware node that receives the packet is triggered to collect and export the telemetry data as configured by the control plane. Within the Hop-by-Hop scope of the PBT-M action, this includes the head-end (imposing) node that originates the flag, every on-path transit node, and the egress node. A node with data collection enabled generates and exports one postcard per marked packet as configured by the control plane.¶
Following Section 10 of [RFC9994], the PBT-M network action is defined as follows:¶
Format: a Format D LSE following a Format A and a Format B LSE, where the Format B LSE uses Opcode 1. No Format C LSE and no Ancillary Data are used.¶
Scope: Hop-by-Hop (IHS = 01), so that every on-path PBT-M-aware node processes the flag. The egress node is included in the HbH scope, and the penultimate node MUST NOT remove the NAS.¶
Ancillary Data: None. The action is encoded as a single flag under Opcode 1.¶
Processing: A PBT-M-aware node with data collection enabled generates and exports a postcard when the P-flag is set. A node that does not support this action skips it (U = 0).¶
Interactions: PBT-M does not modify other network actions; it only triggers telemetry export.¶
Because PBT-M marks only a subset of the packets in a flow, the value of the P-flag differs among packets of the same flow. Per Section 5.2 of [RFC9994], such mutable data MUST NOT be placed in the most significant 20 bits (the label value, which is always used for ECMP), nor in the most significant 23 bits when the TC field is also used for ECMP hashing, of a Format B, C, or D LSE; otherwise it may perturb ECMP load-balancing and cause out-of-order delivery within a flow. The P-flag MUST therefore be assigned a bit position that lies outside both the most significant 20 bits and the most significant 23 bits of the LSE, i.e., within the trailing data bits of the Format D LSE (word bits 24-31), so that the marking bit does not affect ECMP load-balancing whether or not the TC field is used in the hash. The concrete bit position is to be allocated by IANA (see Section 7) and is referred to as TBD1 in this document; the position shown for the P-flag in Figure 2 is illustrative only.¶
In case the path that a flow traverses is unknown in advance, all PBT-M-aware nodes should be configured to react to the marked packets by exporting some basic data, such as node ID and per-LSE TTL (see Section 4.3) before a data set template for that flow is configured. This way, the management plane can learn the flow path dynamically.¶
If the management plane wants to collect the on-path data for some flow, it configures the head node with a probability or time interval for the flow packet marking. When the first marked packet is forwarded in the network, the PBT-M-aware nodes will export the basic data set to the collector. Hence, the flow path is identified. If other data types need to be collected, the management plane can further configure the data set's template to the target nodes on the flow's path. The PBT-M-aware nodes collect and export data accordingly if the packet is marked and a data set template is present.¶
To mitigate configuration churn caused by frequent path shifts (e.g., due to dynamic routing or ECMP), controllers SHOULD employ scalable data collection configurations where applicable, and implement a graceful aging mechanism for stale configurations rather than explicitly revoking configurations on every path change. When a path changes, the new path can be quickly learned by the collector, directing the management plane to update nodes on the new path.¶
The collector needs to correlate all the postcard packets for a single user packet. Once this is done, the hop order along the forwarding path can be inferred from the TTL, or from the timestamp if the network time is synchronized. Note, however, that an MPLS packet carries a label stack in which each LSE has its own TTL and only the top LSE TTL is decremented at each hop; PUSH and POP operations change which LSE is on top, so the top-of-stack TTL is not monotonic end-to-end and may, for example, increase after a POP. A single TTL value is therefore insufficient in the general case. A PBT-M node SHOULD instead report the TTL of every LSE in the received label stack (the per-LSE TTL vector) together with its node ID, and the collector reconstructs the hop order from this TTL vector, using IGP topology where needed to resolve label-stack operations along the path. Reporting the received label stack itself is not required for hop ordering; it is useful mainly as the flow ID and for detecting PUSH/POP operations, and the swapped top label is in any case not a stable per-hop identifier. The key issue here is to correlate all the postcards for the same user packet.¶
The first possible approach includes the flow ID in the OAM packets. In case of MPLS, if we consider the aggregated flow sharing the LSP/FEC, the MPLS label stack can serve as the flow ID; if a 5-tuple IP flow needs to be identified, data beyond the label stack needs to be collected to serve as flow ID. If the packet marking interval is large enough, the flow ID can be used to identify a user packet with high likelihood. As a result, all the exported postcard packets for the same flow during a short time interval likely belong to the same user packet.¶
Alternatively, if the network is time-synchronized, then the flow ID plus the timestamp at each node can also infer the postcard affiliation. This requires the participating nodes to share a common time reference (e.g., using PTP or NTP) with a synchronization accuracy that is small relative to the minimum inter-hop latency along the path. Timestamps carried in postcards use a single global epoch and a format that is independent of local time zones (e.g., the PTP or NTP timestamp formats defined in [RFC9197]). Even so, some errors may occur under some circumstances. For example, if two consecutive user packets from the same flow are marked and one exported postcard from a node is lost, the collector may be unable to decide to which user packet the remaining postcard is related. Postcards that cannot be unambiguously correlated MUST be discarded rather than reported as part of a path.¶
If an application requires guaranteed correlation, this can be achieved by ensuring that at most one marked packet is in flight at a time per correlation key that is actually carried in the postcards, i.e., per LSP/label stack when only the label stack is exported, or per finer-grained flow ID when additional identifying data is exported. Because only the ingress node marks packets (see Section 6), the ingress enforces this by spacing the marks so that the marking interval exceeds the maximum in-network packet lifetime plus the maximum postcard export delay. Under this constraint, the carried flow ID correlates all postcards of a single marked packet unambiguously, even under loss or reordering, at the cost of a lower marking rate.¶
Correlation requires all postcards of a single user packet to be evaluated together. Therefore, if postcard processing is distributed across multiple collectors for load balancing (Section 4.4), all postcards that share a correlation key MUST be steered to the same collector (for example, by hashing the correlation key), or to a common correlation function that aggregates them; otherwise the postcards of a single user packet cannot be brought together and the path cannot be reconstructed.¶
PBT-M MUST be applied to only a small subset of packets, never to all packets all the time. It is better used in an interactive environment where the network telemetry applications dynamically decide which subset of traffic is under scrutiny. To bound the DoS vector identified in Req. 4, a PBT-M-aware node MUST enforce two independent rate limits, and it MUST ship with a conservative default posture that is enabled without operator action and that operators MAY tune to their platform and deployment:¶
Marking rate (at the head node): the fraction of a flow's packets that are marked MUST be bounded. The RECOMMENDED default marks no more than 1 in 1000 packets (0.1%) of any single flow. The resulting bandwidth and packet-rate overhead depends on the customer and postcard packet sizes and on the path length, and is quantified in the overhead model below; operators SHOULD re-evaluate it for their own deployment.¶
Postcard generation rate (at every PBT-M-aware node): the number of postcards a node generates MUST be capped, e.g., by a token bucket. The RECOMMENDED default is an average of 1000 postcards per second per node with a burst of 2000, above which the trigger is skipped and the drop is counted (see the counters in Section 5.1) rather than queued. These specific values are starting points intended for calibration by the WG and by operators against node forwarding capacity and collector ingest capacity; the normative requirement is the presence of an enabled-by-default, configurable cap, not the exact numbers.¶
Control-plane protection: postcard generation MUST NOT degrade the node's control-plane functions, in particular IGP (e.g., IS-IS) adjacency maintenance and link-state flooding, whose correct and timely operation is more important than telemetry export. Because postcard generation may be performed on a punt or slow path that may share resources with control-plane processing, such an implementation MUST schedule it at a priority strictly below control-plane traffic and MUST subordinate its CPU, queue, and punt-path usage to control-plane needs. When contention occurs, postcard generation MUST be throttled or skipped (and the drop counted, see the counters in Section 5.1) in favor of control-plane work. Operators SHOULD set the postcard generation cap so that, even under worst-case marking, measured control-plane performance (e.g., IS-IS flooding rate and convergence time) is not affected.¶
The postcard overhead can be estimated as follows. Let m be the marking fraction (the fraction of a flow's packets that are marked; default 1/1000), N the number of PBT-M-aware nodes on the path that each generate a postcard for a marked packet, R the flow's packet rate, Sc the mean size of the monitored (customer) packets, and Sp the mean size of a generated postcard including its own transport encapsulation and the exported data. A single marked packet triggers up to N postcards, one per PBT-M-aware node, so the postcard load is amplified by N across the network. Consequently, each on-path node generates about m*R postcards per second; the network-wide postcard packet rate for the flow is about m*N*R; the added byte load relative to the flow is about m*(Sp/Sc) on any single link and about m*N*(Sp/Sc) network-wide; and the collector ingest is the sum of m*N*R over all monitored flows. As a worked example, with m=1/1000, N=8, R=1,000,000 packets/s, Sc=1000 octets, and Sp=128 octets, each node emits about 1000 postcards/s (which already reaches the default per-node cap above), the network-wide postcard rate is about 8000 packets/s, and the network-wide byte overhead is about 0.1% of the flow. Because these quantities scale linearly with m, N, and Sp/Sc, an operator SHOULD recompute them for its own packet sizes, path lengths, and postcard format and set the marking fraction and the per-node cap accordingly.¶
Marked packets in excess of these limits MUST be forwarded normally but do not trigger a postcard. The postcard packets can be distributed to different collectors to balance the processing load, subject to the correlation constraint in Section 4.3: all postcards sharing a correlation key MUST be delivered to the same collector or to a common correlation function.¶
Because PBT-M sends telemetry data by dedicated postcard packets, it allows data aggregation and compression before exporting from the on-path nodes. Each node can process the generated raw data according to the configured local data-export policies. Such policies may specify how raw data is used to calculate performance metrics, e.g., max, min, mean, percentile, etc.¶
Domain boundary handling (ingress filtering): PBT-M is scoped to a single trust domain (see Section 6). A node at the boundary of that domain MUST, on interfaces that face outside the domain, remove any PBT-M network action (i.e., clear the P-flag) from packets entering the domain, or drop such packets. This ensures the P-flag can be set only by the domain's own head-end (imposing) node and prevents an external party from injecting marked packets to trigger postcard generation. Within the domain, the two rate limits above apply: the marking-rate limit at the head-end (imposing) node, and the postcard-generation-rate cap at every PBT-M-aware node.¶
Following the baseline set by [RFC5706], [RFC9994], and [I-D.ietf-mpls-mna-ps-hdr], PBT-M implementations MUST support the following operational mechanisms:¶
Counters: Nodes MUST maintain counters for marked user packets, triggered postcards, dropped postcards, and malformed MNA instructions.¶
Action Tracking: Success and failure of postcard generation MUST be tracked per action.¶
Rate-limited Alarms: Nodes SHOULD generate rate-limited alarms when postcard dropping exceeds a configured threshold or when anomalous PBT-M flag rates are detected.¶
Correlation Reliability: The confidence with which postcards are associated to a single user packet depends on the marking discipline and, optionally, on time synchronization, as specified in Section 4.3. For deterministic behaviour, operators SHOULD use the single-marked-packet-in-flight discipline of Section 4.3; postcards that cannot be unambiguously correlated are discarded rather than reported as a path.¶
Partial Path Support: In deployments where not all nodes are PBT-M-aware, the collector will receive an incomplete postcard set. Consistent with the capable/incapable node interaction described in Section 12.3 of [RFC9994], a non-PBT-M-aware node leaves the U-bit unset and silently forwards the packet without generating a postcard. To keep the resulting gaps interpretable, operators and analytic systems SHOULD use TTL gaps or IGP topology data to distinguish a PBT-M-aware hop that is idle (aware, but exported no data) from a non-PBT-M-aware hop that cannot respond to the trigger at all.¶
Interaction with MSD: PBT-M imposes an MNA Sub-Stack of three LSEs (Figure 2) on marked packets. On platforms where imposing this Sub-Stack reduces the label-stack depth otherwise available to SR-MPLS, a node that enables PBT-M MUST reflect the reduction in the Maximum SID Depth (MSD) it advertises per [RFC8491], decrementing the advertised value by the number of LSEs PBT-M consumes (up to three), so that a controller (e.g., a centralized path computation element) can correctly determine whether a given SID stack is supported on that node. Because three label positions may be significant on some platforms, operators SHOULD account for this budget when planning SR Policies on PBT-M-enabled paths. A node on which imposing the PBT-M Sub-Stack does not reduce the label-stack depth available to SR-MPLS need not change its advertised MSD. In addition, every PBT-M-aware transit node must be able to read the label stack down to the PBT-M MNA Sub-Stack in order to detect the P-flag; the Sub-Stack MUST therefore be placed within the Readable Label Depth (RLD) of the on-path MNA-capable nodes (see [RFC9994]). Operators SHOULD account for the RLD needed to reach the PBT-M Sub-Stack when positioning it in the stack, since a node whose RLD does not reach the Sub-Stack cannot act on the trigger and will silently behave as a non-PBT-M-aware hop.¶
Access lists with an optional sampler, [RFC5476], should be configured and attached at the ingress of the PBT-M encapsulation node to select the intended flows for PBT-M.¶
Based on the requirements and node capability, the flow data could be exported at each transit node and at the end edge node with IPFIX [RFC7011].¶
The data decomposition can be achieved on the PBT-M-aware node exporting the data or on the IPFIX data collection. [I-D.spiegel-ippm-ioam-rawexport] describes how data is being exported when decomposed at IPFIX data collection. When being decomposed on the PBT-M-aware node the data can be aggregated according to section 5 of [RFC7015].¶
In MPLS networks, the Maximum Label Depth (MLD) that a node can push or read bounds the MNA size and, in turn, the OAM capability. For SR-MPLS, the Maximum SID Depth (MSD) and the resulting PMTU of an SR Policy similarly bound the number of segments a controller can instantiate on a path. PBT-M is well suited to these constraints because its cost is fixed and does not scale with either the path length or the amount of telemetry collected.¶
Specifically, PBT-M adds a single MNA Sub-Stack of three LSEs (Format A, Format B, and Format D; see Figure 2), a fixed 12 octets, to a marked packet. This overhead is constant regardless of how many hops the packet traverses and regardless of how many or how large the telemetry parameters are, because the telemetry data itself is carried out-of-band in postcards rather than in-situ in the packet. By contrast, in-stack passport-mode telemetry adds per-node data at every hop, so its label-stack cost grows with both the path length and the size of the collected data set.¶
The measurable consequences for an operator are: (1) PBT-M consumes a constant three label positions of the MLD/MSD budget, so enabling telemetry on an N-segment SR-TE path reduces the number of segments that fit within a given MSD by at most three, independent of N; and (2) PBT-M adds a fixed 12 octets at the ingress and nothing further along the path, so it has no per-hop PMTU impact, whereas in-stack telemetry can grow the packet by tens to hundreds of octets over a path and risk exceeding the PMTU. Relative to IOAM DEX [RFC9326], which also relies on a marking trigger, PBT-M contributes the MNA flag encoding and the flow path discovery mechanism of Section 4.2, so the controller does not need to pre-configure every on-path data plane node before collection can begin.¶
In the intended operation, only the head-end (imposing) node of the monitored LSP/SR path sets the P-flag, and on-path nodes only read it and react by generating a postcard. This is an authorization expectation, not a property enforced by the encoding: because the P-flag is a mutable, unauthenticated bit processed hop-by-hop, any on-path node that is compromised or misconfigured can set, clear, or otherwise alter it. Setting or spoofing the flag can drive excess postcard generation, a DoS vector against both the nodes and the collector; clearing or flipping it can suppress or falsify telemetry, yielding unreliable measurements.¶
This document does not provide cryptographic integrity protection for the flag. Protecting a single per-packet-mutable bit, per hop and in-band, is impractical and would defeat the low-overhead goal of PBT-M; this property is shared with other lightweight marking triggers such as the SRv6 O-bit [RFC9259] and IOAM DEX [RFC9326]. PBT-M therefore relies on the trust model of the MPLS/MNA domain, which MUST be enforced at the domain boundary. Specifically: ingress filtering at the domain boundary, as defined in Section 4.4, MUST clear or drop the P-flag on packets entering from outside the domain, so that only the domain's head-end (imposing) node can set it; the two enabled-by-default rate limits of Section 4.4 (the marking-rate limit at the head-end node and the postcard-generation cap at every PBT-M-aware node) MUST bound the postcard load so that flag tampering cannot be amplified into a DoS; and the counters and rate-limited alarms (Section 5.1) SHOULD be used to detect abnormal marking or postcard rates indicative of tampering. Protection of the exported postcards and configuration against eavesdropping and modification can be provided by encrypting and/or authenticating them (Section 2). The security considerations of the MNA Sub-Stack in Section 11 of [RFC9994] also apply.¶
The effectiveness and residual risk of these measures are as follows. Ingress filtering at the domain boundary fully mitigates injection of the P-flag from outside the domain, since the flag is meaningful only within the domain and the boundary clears or blocks it on externally originated packets; it does not constrain nodes already inside the trust boundary. The enabled-by-default rate limiting (Section 4.4) bounds the DoS impact by construction and independently of who sets the flag: because the per-node postcard cap is enforced locally, even universal or spoofed marking cannot generate more than the configured postcard rate (excess triggers are skipped and counted), and the control-plane-protection requirement prevents degradation of IGP/IS-IS operation; it bounds rather than prevents postcard generation and does not protect telemetry integrity. The counters and rate-limited alarms (Section 5.1) are a detective measure that surfaces abnormal marking or postcard rates so operators can respond and limit an attack's duration; they do not prevent tampering, and low-rate tampering that stays within configured thresholds may go undetected. Encrypting and/or authenticating the exported postcards and configuration protects the confidentiality and integrity of the collected data and of the management-plane configuration in transit, but does not protect the in-band trigger flag itself.¶
The residual risk is therefore that PBT-M does not cryptographically protect the P-flag: a compromised or misconfigured node inside the trust boundary can still spoof or suppress it. The resulting DoS is bounded by the rate limits and detectable via the counters, but the integrity of measurements originating at such a node cannot be assured. This limitation is inherent to lightweight in-band marking (as with the SRv6 O-bit and IOAM DEX) and is why PBT-M is specified for use within a single trust domain.¶
This document requests IANA to allocate one bit position (TBD1) for the PBT-M network action, with the description "PBT-M (Postcard-Based Telemetry with Packet Marking)", from the "Network Action Flags Without Ancillary Data" registry in the "MPLS Network Actions" registry group created by [RFC9994]. To preserve ECMP load-balancing, the allocated bit position needs to fall within a Format D LSE (word bits 24-31), i.e., outside the most significant 23 bits of the LSE, so that the mutable marking bit does not affect ECMP load-balancing whether or not the TC field is used in the hash (see Section 5.2 of [RFC9994]). The registration procedure for this range (bit positions 20-439) is IETF Review.¶
The authors thank Carlos Pignataro for the OPSDIR review, and Bruno Decraene for the RTGDIR review.¶