[mpls] Gorry Fairhurst's Discuss on draft-ietf-mpls-stamp-pw-08: (with DISCUSS and COMMENT)

[Gorry Fairhurst via Datatracker <[e-mail]>]

Gorry Fairhurst has entered the following ballot position for
draft-ietf-mpls-stamp-pw-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-stamp-pw/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Gorry Fairhurst WIT AD comments

Thank you for the work that has been put into this document.

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

I hope that this review helps to improve the document. This review as updated
22 Aug after a revised I-D was issued

Regards, Gorry

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

Thank you for the detailed review provided by Vidhi in:
https://datatracker.ietf.org/doc/review-ietf-mpls-stamp-pw-07-tsvart-telechat-goel-2026-08-19/
This TSV-ART review as very detailed, and rather than paraphrasing it here I
shall refer to it in this DISCUSS, but I am happy to expand on that if it is
useful. Note the full list includes some additional comments.

### Sections 3.1, 4.2, 5.2
Please Explain the method for Session identification in Format-2
- see details in
https://datatracker.ietf.org/doc/review-ietf-mpls-stamp-pw-07-tsvart-telechat-goel-2026-08-19/
- Is this addressed in rev -08?

### Section 3
"The base STAMP test packets can be encapsulated using an IP/UDP header and may
use destination UDP port 862 [RFC8762]." Section 4.1 of [RFC8762] is stronger
than "may use": the Session-Sender MUST use port 862 as the default destination
port. Should the wording be aligned; e.g. "uses destination UDP port 862 as the
default destination port, as specified in Section 4.1 of [RFC8762]". - In rev
-08 "When choosing a destination port from the User Ports range, the possible
impact on the network needs to be carefully studied and agreed on by all users
of the network domain where the test has been planned, as described in Section
4.1 of [RFC8762]." - Can this be converted to requirements rather than
considerations? I note that Section 4.1 of RFC 8762 does provide normative
requirements, and would like to understand why these are relaxed here/.

### Section 4.1
The IANA registry entry for this block records "Destination: False", which
looks at first glance like it contradicts the use here; Section 1 of [RFC9780]
explains that this is deliberate, i.e., a source-only address is used as the
destination precisely to generate an exception. - Since this document depends
on that reasoning, [RFC9780] belongs in the normative references, and a
sentence pointing at it would save the next reader the same detour.

### Sections 6, 7
Please can you explain the reaction to congestion or test-load for the PW /
Format-2 case? - see details in
https://datatracker.ietf.org/doc/review-ietf-mpls-stamp-pw-07-tsvart-telechat-goel-2026-08-19/

###Sections 4.1, 5
Please could you define the UDP checksum handling. I think this may be
unspecified for Format-1? - see details in
https://datatracker.ietf.org/doc/review-ietf-mpls-stamp-pw-07-tsvart-telechat-goel-2026-08-19/

### Section 3.2.3 (in rev -08)
Section 3.4 Checksum Guidelines of RFC 8085 requires an IPv6 UDP checksum,
except for some defined exceptions that need to be justified. Why is it not
possible to use a checksum for the method using IPv6, there may be a case, but
please carefully explain how you meet the criteria in RFC 6936.

### Sections 3, 3.1
How is the sender source port constrained in Format-1 ?
- see details in
https://datatracker.ietf.org/doc/review-ietf-mpls-stamp-pw-07-tsvart-telechat-goel-2026-08-19/

### Section 6
There appears to be no consideration  of the packet size / MTU considerations
considering the addition of extra header octets. The document does not discuss
test packet size and I suspect in ought to. - see details in
https://datatracker.ietf.org/doc/review-ietf-mpls-stamp-pw-07-tsvart-telechat-goel-2026-08-19/
-> The current text in -08 speaks of considerations, can this be converted to
requirements?

### Section 6.1
Broken-LSP considerations only cover Session-Sender packets, please explain
other cases. - see details in
https://datatracker.ietf.org/doc/review-ietf-mpls-stamp-pw-07-tsvart-telechat-goel-2026-08-19/

### Section 6 or 7
Some form of rate-limit or congestion control needs to be discussed for any
IETF protocol that can be used on the general Internet. Section 5 of [RFC9780]
makes a similar recommendation for a rate limiter on the packets passed to the
control plane for processing, which ought to be noted here. This could be a
note for Section 6. - I see new text, however this text does not explain how
this can be achieved for the two use cases, not that this protection is for
other traffic sharing a bottleneck on the path: "The congestion and bandwidth
usage considerations for VCCV applications in Section 9 of [RFC5085] apply to
STAMP test packets carried over PWs, including Format-2 packets that do not
contain UDP." (in rev -08).

### Section 3 (in rev -08)
Why is the the source UDP port not set to a randomised port as per RFC 6056?
This is best practice as per RFC 8085 to provide some protection from off-path
attack? - If this needs instead to be chosen by another method please explain
in the security considerations how the off path protection is provided using
one of the other fields. - Why is this text suggesting using a UDP port that is
registered to another use from the "User Ports" range? - Note please correct
this text if it is not replace: "The source UDP port is chosen by the
Session-Sender from the User Ports range, which MUST be different from 862 "
... because this MUST is either misplaced or is always true, because port 862
is a port in the well-known range, and hence is not in the User Ports range or
the ephemeral ports range.

### Section 3.2.3 (in rev -08)
Section 3.4 Checksum Guidelines of RFC 8085 expects a IPv4 UDP checksum is
enabled. I think this guidance is not being followed currently. Why is it not
possible to enable a UDP checksum for the method discussed?

### There are questions about normative references in the review from
PERFMERDIR, I would like to discuss if these can be fixed.
https://datatracker.ietf.org/doc/review-ietf-mpls-stamp-pw-04-perfmetrdir-early-pignataro-2026-06-07/


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## COMMENTS (non-blocking)

### Section 4.1, Figure 2
"Destination Port = User-configured Destination Port or 862". Section 4.1 of
[RFC8762] requires that, before using a number from the User Ports range, "the
possible impact on the network MUST be carefully studied and agreed on by all
users of the network domain where the test has been planned". - A pointer to
that would be helpful here or in Section 6. - Why is the Destination Port
definition different to RFC 8762?

### Section 1.1
The bulleted requirements use BCP 14 keywords for properties of the solution
("The G-ACh MUST support STAMP test packets with an IP/UDP header") rather than
for implementation behaviour, and "Session-Reflector test packets MAY follow
the reverse underlay path" reads oddly as a requirement. - Please do consider
non-normative phrasing ("needs to") in this section, since the normative
behaviour is specified in Sections 3 to 5 anyway. You could refer to these
sections if you think it helps.

### Section 4.1
"An IPv6 address from the Dummy IPv6 Prefix address 100:0:0:1::/64 block
[RFC9780] [IANA-IPv6-REG]" - "Prefix address ... block" is redundant; suggest
"from the Dummy IPv6 Prefix 100:0:0:1::/64".

### Section 5
Figure 5 caption: "without IP/ UDP Header" - please remove extra space before
UDP.

### Section 6
"An operator may wish to only add MPLS encapsulation in STAMP test packets
destined to addresses within the MPLS administrative domain based on some local
policy." I suggest rewording, e.g. "Based on local policy, an operator may add
the MPLS encapsulation only for STAMP test packets destined to addresses within
the MPLS administrative domain."

### Figure 4
In Format-1 the reflected packet is not the mirror of the received one: per
Figure 4, the Session-Reflector chooses both its source address and its source
port, and the Session-Sender's destination address may have been from 127/8 or
100:0:0:1::/64. So the Session-Sender cannot associate a received reflected
packet with a test session using the 4-tuple either. - It would help to explain
how the Session-Sender is expected to do this association (LSP/PW context plus
SSID and Session-Sender Sequence Number?), or to require the Session-Reflector
to reuse the received destination port as its source port so the 4-tuple is
mirrored.

### Section 6 or 7
Please clarify the interaction between punt-path policing and loss measurement
in Section 7 correctly points at the message throttling of Section 10 of
[RFC5085], and the TTL-expiry method of Section 3.2 means every test packet is
punted to the control plane at both ends. - This may be worth noting
explicitly, as Section 9 of [RFC5085] does ("rate-limiting them can be harmful
as it could translate to incorrectly declaring connectivity failures"), that
policing on the punt path is indistinguishable from network loss to STAMP and
will be reported as such.

### Section 6.2 (in rev -08)
The text states: "Operators should also consider the additional traffic
generated by the Session-Reflector and the rate of control packets passed to
the control plane, as described in Section 6 of [RFC9780]." - I did not find
the additional guidance in RFC 9780, please clarify which text is referenced. -
Please explain what "considered" means in this context and how that
consideration is done.

### There are questions about figures and repeatability with ECMP in the review
from PERFMERDIR, please update the document to address these review comments.
https://datatracker.ietf.org/doc/review-ietf-mpls-stamp-pw-04-perfmetrdir-early-pignataro-2026-06-07/