Telechat Review of draft-ietf-mpls-stamp-pw-11
review-ietf-mpls-stamp-pw-11-intdir-telechat-linkova-2026-08-28-00

Document: draft-ietf-mpls-stamp-pw
Title: Encapsulation of Simple Two-Way Active Measurement Protocol for LSPs and
Pseudowires in MPLS Networks Reviewer: Jen Linkova Review result: REady with
Nits

I am an assigned INT directorate early reviewer for
draft-ietf-mpls-stamp-pw "Encapsulation of Simple Two-Way Active Measurement
Protocol for LSPs and Pseudowires in MPLS Networks". These comments were
written primarily for the benefit of the Internet Area Directors. Document
editors and shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with any other
Last Call comments that have been received. For more details on the INT
Directorate, see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

TL;DR
I found this document well-written an easy to read.
I have some minor comments, most of them are just editorial nits, and the rest
are suggestions to improve readability, especially in case of a reader not very
familiar with the topic.

Details.

General comment: the document talks about "packets w/o IP header" quite a lot.
An example (just one of many) is section 4.2 which says "data traffic without
an IP header over MPLS-TP LSPs". Do you actually mean a case when a data packet
encapsulated into MPLS has other headers before the IP header (like an Ethernet
header or MPLS-in-UDP/VXLAN? I'd expect the vast majority of the data packets
actually having an IP header, it just might not be the *first* header after the
MPLS one...

Abstract

I found the second sentence of the abstract ("LSPs and PWs are used in MPLS
networks for various services, including L2 and L3 data packets" confusing and
not really related to the draft. If I may, I'd like to suggest some rephrasing:

"This document defines encapsulations for Simple Two-Way Active Measurement
Protocol (STAMP, RFC 8762) and its optional extensions (RFC 8972) in MPLS
networks. It specifies encapsulation for STAMP packets for point-to-point Label
Switched Paths (LSPs) and point-to-point single-segment Pseudowires (PWs), both
with and without an IP/UDP header. To ensure test packets share identical
forwarding and ECMP behavior with data traffic. In addition, two new MPLS
Generalized Associated channel (G-ACh) types are defined.

Section 1. Introduction
a) [Just a nit]  similar to one I have for the Abstract. The text says: "Label
Switched Paths (LSPs) are used in MPLS networks for various services, including
Layer 2 and Layer 3 data packets". I don't think that "packets" are "services",
so maybe "Label Switched Paths (LSPs) are used in MPLS networks for various
services, including forwarding Layer 2 and Layer 3 data packets"? The same
applies for the first sentence of the next paragraph, about PWs.

b)
[just a nit]
The draft says:  "This document describes the procedure for the encapsulation
of STAMP, defined in [RFC8762], and its optional extensions, defined in
[RFC8972]," I think it could be shortened to "STAMP and its extensions", as the
references for STAMP and extensions has been provided earlier in the section.

"When using STAMP for MPLS and MPLS-TP for both LSPs and PWs, there are unique
aspects that need to be considered concerning the use of CW, and these aspects
are addressed in this document." - IMHO it's worth explaining what those
challenges are in this part of the document.

3.1 UDP header

I'm a bit confused why this section is in this document. Are those UDP source
port rules applicable for MPLS encapsulation only (this doc), or is it an
update to RFC8762? I might be missing smth but the UDP ports should be selected
the same way no matter what protocol (MPLS or IP) is used to deliver the STAMP
packets, right?

Section 4.1 Encapsulation Use Cases
 [just a nit]
I'd suggest changing "When using an IP header, the IP version (IPv4 or IPv6) in
the STAMP test packets MUST match the IP version used for the LSPs and PWs
being measured" to "When using an IP header, the IP version (IPv4 or IPv6) in
the STAMP test packets MUST match the IP version of the data traffic carried by
the LSPs and PWs being measured" (I found a phrase "IP version used for LSPs" a
bit confusing. It might mean "IP version of the egress router" which is not
what you mean, I guess.

Section 4.2 VCCV Control Channel Types
[just a nit]
The draft says: "The "In-band VCCV for Control Word with 0001b as first nibble
(Type 1)" defined in Section 5.1.1 of [RFC5085] MUST be added when measuring
PWs with CW to avoid different ECMP hashing behavior"

it's unclear "different behaviour" from what? So maybe "to ensure that STAMP
packets follow the same ECMP path as the data packets"?

Section 4.3 TTL Processing
a) I'd suggest changing the title to "TTL and Hop Limit Processing"
b) While the section says what the sender MUST do, it says nothing about
behaviour of the receiver. IMHO it would be helpful to define it explicitly.

Section 4.5, UDP Checksum Handling

The document only quotes *some* requirements from Section 3.4.1 of RFC 8085.
I think it should be better to require explicitly that all requirements in
Section 3.4.1 of RFC 8085 are applicable.

Also, I'm not sure the reference for  Section 3.1 of [RFC7510]is clear.
 "For IPv6, as described in Section 3.1 of [RFC7510], a UDP checksum value of
 zero is allowed for IP-based MPLS encapsulation in networks under a single
 administrative domain.".

STAMP packets are not the case of an IP-based MPLS encap, right?
So that specific exception is not really applicable? or am I missing something?

Section 6 Session-Reflector Test Packet

a) The section says:
- "The Session-Reflector transmits the reflected test packet on the same path
in the reverse direction of the LSP or PW." - "If the received packet context
is an LSP, the Session-Reflector uses the reverse-direction LSP label stack,
with or without a G-ACh as applicable, to transmit the Session-Reflector test
packet." - "If the Session-Reflector cannot find a reverse-direction LSP or PW
context for the received test packet, it MUST discard the received packet and
MUST NOT transmit a reply."

I have a very stupid question, probably....So if there are no bidirectional
LSPs and all LSPs are unidirectional - STAMP can't be used?

6.1 Session-Reflector Test Packet with IP/UDP Header
The diagram says the source Ip address as "configured on Session-Reflector" -
does it have to be the destination address of the session sender packet? I
assume it does, as the text says 'The STAMP Session-Reflector test packet MUST
use the IP/UDP information from the received test packet when an IP/UDP header
is present in the received test packet.' - so maybe the diagram should say
'Source Ip address: the destination address of the session sender packet,
configured on the reflector"? What do you think?

7.1 STAMP Session State Notification

a) Is this applicable to MPLS networks only? Or it should be applicable to all
STAMP cases? Maybe it's worth clarifying, as that text doesn't seem to be
MPLS-specific.

b) The section also says "The failed state can also be attributed to the
connectivity verification failure of the LSP and PW where the STAMP test was
active." - maybe it's just me but I have difficulties parsing this sentence. I
couldn't  even suggest how to rephrase as I'm not sure I understand what it is
trying to say...

7.2 Rate Limiting
I'm wondering if any recommendations of an explicit configurable CPP policy for
STAMP packets can be made here? If packets dropped by such policy are reported,
it might be useful for an operator as it would allow the alerting system to
correlate STAMP packet being rate-limited with failure notifications

7.5 MTU Handling
I assume that filtering on the edge doesn't help with a situation when both
sender and reflector are within the administrative MPLS domain, as a natively
routed IP packet would still reach the Session-Sender.  If that's the case,
maybe it's worth mentioning explicitly?

Also it looks like using STAMP w/o IP/UDP encap would help in this case, right?

Cheers, Jen Linkova