[mpls] Re: draft-ietf-mpls-on-path-telemetry-flag early Rtgdir review

[[e-mail]]

Hi Haoyu,

Sorry for my late reply.
Thank you for considering my comments, for your below reply, and for the updated draft version.
Thank you especially for your good will and in-depth considerations of the comments. Very much appreciated.

-03 works for me.

Best regards,
--Bruno

From: Haoyu Song <[e-mail]>
Sent: Monday, August 10, 2026 8:26 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>; mpls <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: draft-ietf-mpls-on-path-telemetry-flag early Rtgdir review

Hi Bruno,

Thank you very much for the careful and detailed RTGDIR review! It's of great help for us to improve the draft. We have addressed all the comments in the -03 revision. Please see our inline response marked with [HS] for each point on the specific change we made.

Best regards,
Haoyu

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, August 5, 2026 8:22 AM
To: mpls <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: draft-ietf-mpls-on-path-telemetry-flag early Rtgdir review


Document: draft-ietf-mpls-on-path-telemetry-flag-02

Title: MPLS On-Path Telemetry Network Action Flag for OAM

Reviewer: Bruno Decraene

Review result: Has Issues



Hello,



I have been approached (but not formally selected due to misunderstanding on my side) to do a routing directorate "early" review of this draft.

https://www.ietf.org/archive/id/draft-ietf-mpls-on-path-telemetry-flag-02.html

Having reviewed the draft, I'm sending the comments regardless of the formal selection.



The routing directorate will, on request from the working group chair, perform

an "early" review of a draft before it is submitted for publication to the

IESG. The early review can be performed at any time during the draft's lifetime

as a working group document.



Document: draft-ietf-mpls-on-path-telemetry-flag-02

Reviewer: Bruno Decraene

Review date: 2026-08-05





Summary

-------
In general, the draft is clear and readable. Thank you.
I have some comments, including a few major ones, that I think should be addressed before proceeding.

Major:
-------
§7
"This document requests IANA to allocate one bit position (TBA1, suggested value 42)"
Draft should not indicate a suggested value. cf https://datatracker.ietf.org/doc/html/rfc8126#section-3
This looks very close to squatting code points, which leads to interop issues. Please remove.

[HS] Fixed. We remove (TBA1, suggested value 42) and now just request a single bit position as "TBD1"  with no suggested value, and remove the sentence asserting "Bit Position 42 falls in a Format D LSE...". We keep the allocation constraint as guidance to IANA rather than suggesting a squatted value.

---

§4.1
"The P-flag is therefore placed at Bit Position 42"
This is codepoint squatting.
Please remove from the spec (until IANA has allocated a code point)

[HS] Fixed. We replace the hardcoded "Bit Position 42 as numbered in Section 13.2.1 of RFC 9994" with a normative placement requirement (the P-flag MUST be assigned a position outside the MS 20 and MS 23 bits, i.e. in Format D word bits 24-31) and a "TBD1" placeholder pointing to the IANA section. Figure 2 is now labelled "illustrative only" so the drawn position is not read as an allocation.

---
§4.3
This section essentially states that the data correlation is unreliable.
I don't think that this is good enough for important networks.
(At minimum, this should be discussed in the operation consideration section.)

[HS] Addressed. We rewrite Sec 4.3 to provide a deterministic correlation mode: at most one marked packet in flight per correlation key actually carried, enforced at the ingress, and a deterministic failure rule: postcards that cannot be unambiguously correlated MUST be discarded rather than reported as a path. A "Correlation Reliability" item was also added to the Operational and Manageability Considerations (Sec 5.1), as you requested.

---
The document does not specify the interaction with MSD.

RFC 9491 says [MSD] "advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network."
https://datatracker.ietf.org/doc/html/rfc8491

This document adds 3 LSE to the label stack. In some platforms, this may reduce the MSD usable by SR-MPLS.  MUST such node decrement their MSD signaling (by 3) to allow controller to perform correct computation?
Such impact should probably be discussed in the ops consideration section, as 3 may be relatively significant for some platform.

[HS] Addressed. We add an "interaction with MSD"  item in Sec. 5.1: a node that enables PBT-M and whose usable SR-MPLS label depth is reduced by the 3-LSE Sub-Stack MUST decrement its advertised (per RFC 8491) by the number of LSEs consumed (up to three) so controllers compute correct SID stacks; nodes unaffected by the imposition need not adjust. RFC8491 is added as an informative reference.

Minor:
-------
§2
"1: PBT-M avoids augmenting user packets with new headers "
Well, draft seems to do exactly that (augmenting user packet with a new header). You may want to rephrase. (e.g. "large header")

[HS] Fixed. Change "new headers" to "new large headers"
--

"3: PBT-M can avoid interfering with the normal forwarding."
pushing the MPLS MNA header seems to interfere with normal forwarding (by reducing the available MSD on the Head Node, and the RLD on all transit nodes)

[HS] Fixed. Our real meaning here is that PBT-M doesn't incur extra user packet processing (e.g., modify or augment the user packets). We rephrase this sentence to avoid ambiguity. The imposition cost is now also treated explicitly: MSD  (decrement the advertised MSD) and RLD (the Sub-Stack MUST lie within the Readable Label Depth of the on-path MNA-capable nodes, and a node whose RLD does not reach the Sub-Stack silently behaves as non-PBT-M-aware) in Sec 5.1.

--

"4: For PBT-M, the types of data collected from each node can vary depending on application requirements and node capability."
I would assume that this would be true even without PBT-M, otherwise this would seem difficult to deploy.

[HS] Clarified. For the other on-path telemetry techniques (e.g., IOAM trace and DEX), the head node stipulates the data types to be collected, and each transit node must all be able to export the data exactly as requested. For PBT-M, the head node only provides a trigger without stipulating the data types, and each transit node can export data based on its local configuration.
--

§3
"Req. 1 (Packet Marking Bit): A user packet needs to be marked to trigger the path-associated data collection. Since PBT-M aims to avoid the need to augment user packets with new headers, it needs to reserve or reuse a single bit from the existing header fields."
Do you mean an existing header field in a specification or in the customer packet?
The former would still augment user packer. The latter would restrict the usage to MPLS packets already carrying MNA.
Please clarify.

[HS] Clarified. Rephrased as "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., the MNA encoding)."
--

"Req. 4 (Overhead and Security): Since each postcard packet has its header, the overall network bandwidth overhead of PBT-M can be high. A large number of postcards could add processing pressure on data collecting servers. That can be used as an attack vector for DoS."

Also it add processing pressure on all transit nodes sending a postcard. (which are likely more limited than a server)

[HS] Good catch. We rephrase the sentence as  "A large number of postcards could add processing pressure on all transit nodes sending postcards as well as data collecting servers."
---
§4.1
"Format D (labeled D) carries the P-flag."

The P-flag has never been defined/introduced as this point. May be :s/P-flag/PBT-M indicator

[HS] Fixed.

---

"If the bit is set to '1', a node is triggered to collect and export the telemetry data as configured by the control plane."

Since this flag is essentially the main part of the specification, could you please specify what "a node" is?

(in particular, according to Figure 1, this seems to include the Head Node, which does not seem completely obvious)

[HS] Fixed. Change to "when the bit is set, every PBT-M-aware node that receive the packet is triggered - explicitly the head-end (originating) node, every on-path transit node, and the egress node within the Hop-by-Hop scope." to rigidify the scope.

---
§4.3
" Once this is done, the TTL (or the timestamp, if the network time is synchronized) can be used to infer the flow forwarding path."
In the general case, the MPLS packet carries a label _stack_.
- The TTL may be set differently in each LSE.
- And even if not, since only the TTL of the top label is decremented, TTL will be different across LSE.

Hence this does not seem to work as written. (e.g., after a POP, the TTL on the top LSE is likely to _increase_)
You may want to expand, e.g., by specifying the use of all TTL of all LSEs.

[HS] Thank you for pointing this out. The bug is fixed.  Sec. 4.3 now states plainly that TTL-based hop ordering can't rely on a single TTL because only the top LSE's TTL is decremented and PUSH/POP make the top-of-stack TTL non-monotonic (it can increase after a POP). A PBT-M node SHOULD report the per-LSE TTL vector plus its node ID, and the collector reconstructs hop order from that vector, using IGP topology to resolve label operations. We also make Sec 4.2's basic export set consistent ("node ID and per-LSE TTL").
---

"The first possible approach includes the flow ID in the OAM packets. In case of MPLS, the MPLS label stack can serve as the flow ID."
I don't think that this is reliable enough. An MPLS LSP typically aggregates a very large number of flows, so is not good enough to identify a flow.

[HS] Clarified. A flow could be an aggregated flow sharing the LSP/FEC. If a 5-tuple flow needs to be identified, data beyond the label stack needs to be collected. Text is updated to reflect this change.

"If the packet marking interval is large enough, the flow ID is enough to identify a user packet."
Probably the "interval between two successive packet marking operation".
Again, I disagree that this is enough and reliable enough. If you stand with your statement, please provides data, the math and the resulting probabilities of collisions.

[HS] Updated. Change "If the packet marking interval is large enough" to "If the interval between two successive packet marking operation is large enough". We admit that the original statement is not enough and reliable. We add a paragraph to explain how to acquire guaranteed correlation: "If an application requires guaranteed correlation, this can be achieved by spacing the marks so that at most one marked packet of a flow is in flight in the domain at a time (i.e., the marking interval exceeds the maximum path traversal plus postcard export delay). The flow ID then correlates the postcards unambiguously even under loss or reordering, at the cost of a lower marking rate."

"As a result, it can be assumed that all the exported postcard packets for the same flow during a short time interval belong to the same user packet."
No, it cannot. This seems overly simplified. We need deterministic behavior, and networks/spec which works all the time. Especially for a troubleshooting tool.

[HS] Agreed. We now only state that those postcard packets likely belong to the same user packet. The new paragraph mentioned above explains how to achieve the guaranteed correlation.

"Alternatively, if the network is synchronized, then the flow ID plus the timestamp at each node can also infer the postcard affiliation."
What do you mean by "synchronized"? How much precision? Does the format of the timestamp account for different timezone?

[HS] Clarified. "synchronized" is now explained in new text: "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)."

"In many cases, such a rare error has no catastrophic consequence. Therefore it is tolerable."
Says who? This seems like a personal opinion. I, for one, do not share it. I don't think that this is good enough for an IETF spec.
Care to elaborate for the other cases which have catastrophic consequences?

[HS] Agreed. The statement is now deleted and replaced with a deterministic rule: uncorrelatable postcards MUST be discarded, not reported as a path.

----
§4.4 Load Control
"PBT-M should not be applied to all the packets all the time."
So 99% works fine??
It seems to me that the sentence should be much more conservative. e.g., "PBT-M MUST be applied to a very small subset of packets."

Again, could be discussed in the ops consideration section.

[HS] Updated to "PBT-M MUST be applied to a small subset of packets."


"The RECOMMENDED default marks no more than 1 in 1000 packets (0.1%) of any single flow, which keeps the added postcard traffic within roughly 0.1% of the monitored flow rate."

This may be seen as still a significant number for some platforms. I wish we had the same performance for IS-IS flooding, especially given its importance relative for postcard.
I'd like to see a discussion and recommendation for reduced impact on the router. e.g., I would not want IS-IS flooding performance be reduced by postcard generation.

Also, the math for the monitored flow rate is not much detailed. It seems to rely on assumptions such as the size of customer packets, the size of the postcard, the number of nodes in transit (N nodes generates N packets for a single customer packet)... Could you please detail your assumptions and math? Especially since I expect a network operator to re-evaluate the numbers based on its own deployment)

[HS] Addressed. We replace the number with an explicit model: variables m (marking fraction), N (PBT-M-aware hops), R (flow rate), Sc (customer packet size), Sp (postcard size),  giving per-node rate  m·R, network-wide  m·N·R, byte overhead m·(Sp/Sc) per link and m·N·(Sp/Sc) network-wide, plus a worked example and a note that operators should recompute for their own deployment.
[HS] We also add a normative control-plane-protection requirement in Sec. 4.4: postcard generation MUST NOT degrade control-plane functions (IGP adjacency, link-state flooding), MUST run at strictly lower priority with CPU/queue/punt-path subordinated to the control plane, MUST be throttled or skipped (and counted) under contention, and operators SHOULD size the cap so worst-case marking leaves IS-IS flooding rate and convergence unaffected.

---
"Marked packets in excess of these limits are forwarded normally but do not trigger a postcard."
probably :s/are/MUST be

[HS] Fixed.
---

"The postcard packets can be distributed to different collectors to balance the processing load."
Section 4.3 seems to say that correlation is already hard/unreliable with a single collector. Introducing multiple collectors would probably significantly increase the difficulty and section 4.3 would need to be updated to reflect this.

[HS] Sec. 4.3 has been updated to expose the challenges and potential solutions. If there are multiple collectors, different distribution algorithms and correlation mechanisms can be applied. In Sec 4.3 now we state that all postcards sharing a correlation key MUST be steered to the same collector (e.g., by hashing the key) or to a common correlation function; otherwise the packet's postcards cannot be brought together.

----
"Because PBT-M sends telemetry data by dedicated postcard packets, it allows data aggregation and compression."
not being familiar with postcard, it's not clear to me what type of data aggregation and compression you are referring to.
A priori, the proposal seems to be willing to track a packet on all transit nodes. I'm not sure to see what aggregation one may do.
At minimum, please elaborate on which node is doing the data aggregation: collector or transit node?

[HS] Clarified. Postcard exporting nodes can do data aggregation and export only aggregated data. For example,
the node can be configured to export "the total packets received since the last flag" or "the maximum buffer depth since the last flag".
Such policies are out of the scope of this document. We just point out the possibility.
We update the text to eliminate the ambiguity as suggested: aggregation/compression is performed on the on-path node before export;
the collector receives already-processed data.

-----
§6  Security Considerations

"Only the ingress node is allowed to set these flag bits."

You do mean "MPLS ingress node", not "LSP ingress" do you?
If so, I'm not seeing this restriction in the specification. And this seems to significantly reduce its usage.

[HS] Clarified. The ingress node here is the LSP ingress node (or path head node), complying with RFC9994.
---

"The other on-path nodes can only react to the bit values. "
What do you mean by "can only"?
It seems to me that any node could modify the flag en route.
If you don't want this to happen, you need measures to avoid this. (e.g., cryptographic signature). Since this specification do not propose any measure to propose any tampering of the flag, I find the sentence misleading. Especially in a security consideration section.

[HS] Agreed.  "can only react" describes only the authorized behavior, but not an enforced property. We rephrase the text  to state the threat model honestly: the P-flag is a mutable, unauthenticated bit, so any on-path node could tamper with it. We do not add per-flag cryptographic integrity (impractical for a single per-packet-mutable, hop-by-hop bit carried in-band, and contrary to the low-overhead goal; the SRv6 O-bit and IOAM DEX marking triggers share this property). Instead PBT-M relies on the MPLS/MNA domain trust model, enforced at the boundary by ingress filtering, bounded by the default rate-limiting posture (so tampering cannot be amplified into DoS), and made detectable by the counters/anomaly alarms. We'll make these limits explicit rather than implying the flag cannot be modified.

---

"Therefore, security measures MUST be taken to ensure the proper functioning of these actions."
Right. Which are those security measures? And how effective are they?
This is the kind of discussion I would expect in a security consideration section.
Especially for a specification which indicates that it can be used as an attack vector for DoS.

[HS] Agreed. We expand the section to assess each measure rather than just assert it, mapping the threats
(external flag injection; on-path spoofing to DoS;  on-path clearing/flipping to falsified telemetry; attacks on the export channel)
to the mitigations and stating effectiveness and residual risk explicitly,  including the residual risk that we cannot close.

---
"Specifically, ingress filtering and the default rate-limiting posture MUST be applied"
What do you mean by the former?
Please elaborate on the later (which postures, on which nodes). Any existing reference to this posture? Otherwise, please specify those in the body of this specification.

[HS] Good catch. The rate-limiting posture is now fully specified in Section 4.4 (the marking-rate limit at the head-end node and the postcard-generation-rate cap at every PBT-M-aware node, both enabled by default),
and we make the Security section cross-reference it explicitly rather than referring to it loosely. "Ingress filtering" was indeed used without definition. We add a normative domain-boundary rule to the body (Sec.4.4)  and reference it here.


____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.