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

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

Gorry Fairhurst has entered the following ballot position for
draft-ietf-mpls-stamp-pw-07: 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,

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/

### 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. "usescdestination UDP port 862 as the
default destination port, as specified incSection 4.1 of [RFC8762]".

### 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 is unspecified for Format-1?
- see details in
https://datatracker.ietf.org/doc/review-ietf-mpls-stamp-pw-07-tsvart-telechat-goel-2026-08-19/

### 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/

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


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

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