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

[[e-mail]]

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.
---

§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)

---
§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.)

---
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.

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")
--

"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)
--

"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.
--

§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.
--

"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)
---
§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
---

"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)

---
§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.
---

"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.

"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.

"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.

"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?

"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?

----
§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.

"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)

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

"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.

----
"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?
-----
§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.
---

"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.
---

"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.

---
"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.

____________________________________________________________________________________________________________
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.