Early Review of draft-ietf-mpls-stamp-pw-04
review-ietf-mpls-stamp-pw-04-perfmetrdir-early-pignataro-2026-06-07-00

Hello,

I have been selected as the Performance Metrics Directorate (perfmetrdir)
reviewer for this Internet-Draft.The Performance Metrics Directorate assists
the OPS Area Directors, Chairs, and ADs, to review performance-related
documents. This is an early review requested by the WG chairs.

Document: draft-ietf-mpls-stamp-pw-04
Reviewer: Carlos Pignataro
Review Date: 2026-06-07
Intended Status: Standards Track

Summary: I have some concerns about this document that I think should be
resolved before publication.

Comments:
The document describes encapsulation of STAMP (RFC 8762, RFC 8972) test packets
over MPLS LSPs and PWs, covering two formats: with IP/UDP header (Format1) and
without (Format2). The two new G-ACh channel types for Format2 are a clean,
justified addition. The use case matrix in Table 1 and the packet diagrams are
helpful. The document is generally well-structured and readable.

The Performance Metrics Directorate, in addition to Perf Metrics specific
review, applies the guidelines from RFC 6390.

1. Routable destination address undermines measurement validity (Section 4.1)

Allowing a routable destination address means that if the MPLS label stack is
mishandled by an intermediate node, the test packet may be IP-forwarded via a
different path — the session stays up and the operator sees no indication the
measurement is off-path. Section 3.2 acknowledges this but treats it as a
network analytics problem rather than a normative constraint.

The non-routable alternatives (127/8, 100:0:0:1::/64) exist precisely to
prevent this. The document should add normative guidance — at minimum a SHOULD
NOT — against using routable addresses where LSP measurement fidelity is
required.

2. Metric scope is not stated

The document does not say which metrics this encapsulation supports — delay,
loss, or both. The T1–T4 timestamps imply delay, but loss measurement has
different sensitivity to path consistency. This ought to be stated explicitly.

3. Path consistency for ECMP is asserted, not verified

The document asserts test packets follow the same ECMP path as data traffic.
This depends on intermediate nodes treating the G-ACh header identically to CW
for hashing purposes, which is not guaranteed. This is a potential
repeatability issue per RFC 6390 and should be noted.

4. Missed opportunity with S6.  Operational Considerations

Section 6 is a single-sentence pointer. For a Standards Track document, the
operational considerations specific to this encapsulation, including ECMP
sensitivity, broken LSP detection, domain edge filtering, should be summarized
here rather than (or in addition to) dispersed through Sections 3 and 7.

5. Is RFC 8762 a more precise citation in Section 7, rather than RFC 8545 (for
port 862)?

6. Reference classification errors:

RFC 5082 and RFC 6790 are classified as Informative but carry normative weight:
Section 3.2 contains a MUST derived directly from RFC 5082 (TTL=255), and
Section 1.1 contains two MUSTs conditioned on RFC 6790 (Entropy Label ECMP
behavior). Both should move to Normative References. RFC 9801 (PLE) is also
Informative but describes specific encapsulation requirements for an explicitly
supported use case -- it can be argued either way, but please make an
intentional decision.

6. GAL Missing from FIgures 3 and 5 (or not explained why omitted)

For Format2 (Figures 3 and 5, without IP/UDP header), the G-ACh is being used
on an LSP context, which per RFC 5586 requires a GAL (label value 13)
immediately below the LSP label stack and above the ACH. The GAL row is absent
from the diagrams. The figures should either show the GAL row (with a note that
it applies to the LSP case) or explicitly state in the accompanying text why it
is omitted.

7. A nit -- Table 1, Type 3, s/Format 1/Format1/;

I hope these are useful and clear.

Thanks, and best,

Carlos Pignataro.