[mpls] Re: [Tsv-art] draft-ietf-mpls-stamp-pw-07 telechat Tsvart review

[Vidhi Goel <[e-mail]>]

Hi Rakesh, Gorry,

Thanks for the quick turnaround, and thanks Gorry for the nudge.

All seven issues from my review are addressed, and in a
couple of places the text goes further than I asked for. Specifically:

- Issue 1 (session identification without a 4-tuple): the new Section 3.1.1
  plus the requirement in Section 3 that the SSID be non-zero and be carried
  in both directions resolves this cleanly for Format-2.
- Issue 2 (congestion / test load): Section 6.2 now covers provisioning,
  points at Section 3.1.5 of RFC 8085 for Format-1 and Section 9 of RFC 5085
  for Format-2, and picks up the 5% guidance. Good.
- Issue 3 (UDP checksum): Section 3.2.3 covers the ground I asked about, with
  one loose end that I have written up as item 1 below.
- Issue 4 (source port): the bullets in Section 3 cover this.
- Issue 5 (MTU): Section 6.3 is what I was after, and the octet counts are
  right.
- Issue 6 (punt-path policing vs. loss measurement): Section 6.1 says it
  explicitly, which is what I wanted.
- Issue 7 (reflected packets on a broken reverse path): the last paragraph of
  Section 6.4 covers it.

The nits are all taken care of too.

So from a transport perspective I would now call this ready, and I do not
think any of the following needs to hold up the telechat, though I would like
to see the first item resolved before publication.

1. Section 3.2.3, IPv6 zero-checksum basis

This is the one I would like to see changed. The two references used to
justify a zero UDP checksum for IPv6 are both scoped to protocols that use
UDP as the *outer* tunnel encapsulation: RFC 7510 is MPLS-in-UDP, and
Section 3.4.1 of RFC 8085 is the guidance for "tunnel protocols using UDP".
In this document the layering is the other way round - the UDP datagram is
the innermost payload, carried inside MPLS - so the exception in Section 8.1
of RFC 8200 ("protocols that use UDP as a tunnel encapsulation") does not
obviously apply, and RFC 6936, which is the applicability statement that
Section 8.1 of RFC 8200 points to, is not referenced anywhere in the
document.

Either of these would work for me:

(a) Drop the IPv6 zero-checksum allowance and rely on the checksum
    complement [RFC7820] or the authenticated mode, which the section
    already mentions; or

(b) Keep it, but justify it against RFC 6936 rather than RFC 7510 - i.e.,
    cite RFC 6936 and state which of its Section 5 requirements this
    encapsulation meets. Some you already satisfy and say elsewhere in the
    document: requirement 1 (enabled only for a specific port or port range
    at both endpoints), requirement 4 (corruption must not accumulate
    incorrect state - your "MUST NOT make assumptions regarding the
    correctness of received test packets" covers this), and the
    single-administrative-domain restriction in Section 7.

If you take route (b), please look closely at requirement 5 of Section 5 of
RFC 6936: "A transported protocol with a non-tunnel payload or one that
encapsulates non-IP packets MUST have a CRC or other mechanism for checking
packet integrity". A STAMP test packet is a non-tunnel payload, and in
unauthenticated mode there is no such mechanism, so I think that requirement
points at permitting the IPv6 zero checksum only where the checksum
complement [RFC7820] or the authenticated mode is in use - which is close to
route (a) in practice, and is also the case where the "local processor cannot
recompute the UDP checksum" motivation no longer applies. Restricting the
zero-checksum exception to IPv4 would be another way out.

I have no objection in principle to zero-checksum operation being permitted
here; it is the citation trail and the unauthenticated-mode case that I would
like to see resolved, since an implementer reading Section 3.2.3 against
Section 8.1 of RFC 8200 will otherwise see a conflict.

2. RFC 8085 reference classification

Section 3.2.3 now depends on RFC 8085 normatively ("MUST behave correctly
when a UDP datagram is corrupted as described in [RFC8085]", and the
requirements quoted from its Section 3.4.1), but RFC 8085 is still an
Informative reference. It should move to Normative, alongside RFC 768,
RFC 6056 and RFC 7510.

3. Section 6.2, last bullet

  "Any rate limit applied to the Session-Sender test packets will prevent
   the corresponding reflected test packet traffic from exceeding the
   reverse direction bandwidth capacity."

That only holds if the reverse capacity is at least the forward rate limit,
which the third bullet of the same list says may not be the case. Suggest
qualifying it, e.g. "... provided the rate limit is set with respect to the
lower of the two directions' capacities", or simply dropping the bullet
since the preceding two already make the point.

Minor: Section 3.1.1 gives the identification rules for the Stateful
Session-Reflector only. Since session identification is separate from test
state, and RFC 8972 requires a conforming Session-Reflector to discard
non-matching test packets either way, it would help to either cover the
stateless mode too or say why the rules only apply to the stateful one. A
pointer to Section 4.2 of RFC 8762, where the two modes are defined, would
also help the reader.

Happy to look at updated text if you post another revision.

Thanks,
Vidhi


> On Aug 25, 2026, at 1:55 AM, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 25/08/2026 00:15, Rakesh Gandhi wrote:
>> Hi Vidhi,
>> 
>> FYI:
>> We have posted rev-09 that further refines the previous updates to address your comments.
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-stamp-pw/
>> P.S. Thank you Gorry for your review/suggestions.
>> 
>> Thanks,
>> Rakesh (for authors)
> Vidhi & Rakesh,
> 
> This new revision is much more informative (and improved) from a transport perspective. If you see anything that is notable or can be further improved do continue.  
> 
> Vidhi, if you find time, could you have a quick check to see if the new sections address the issues relating to stamp or they may need further refinement?
> 
> I will schedule time to read this again next week and plan to update my position before the telechat meeting on 2026-09-0.
> 
> Best wishes,
> 
> Gorry
> 
> 
> 
>> 
>> 
>> 
>> On Fri, Aug 21, 2026 at 10:52 AM Rakesh Gandhi <[e-mail] <mailto:[e-mail]>> wrote:
>>> Hi Vidhi,
>>> 
>>> Thank you for the thorough review of the draft.
>>> 
>>> We have posted rev-8 with the suggested updates.
>>> 
>>> URL:      https://www.ietf.org/archive/id/draft-ietf-mpls-stamp-pw-08.txt
>>> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-mpls-stamp-pw
>>> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-stamp-pw-08
>>> 
>>> Please see replies inline with <RG>...
>>> 
>>> 
>>> On Wed, Aug 19, 2026 at 5:13 PM Vidhi Goel via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
>>>> Document: draft-ietf-mpls-stamp-pw
>>>> Title: Encapsulation of Simple Two-Way Active Measurement Protocol for LSPs and
>>>> Pseudowires in MPLS Networks Reviewer: Vidhi Goel Review result: Ready with
>>>> Issues
>>>> 
>>>> This document has been reviewed as part of the transport area review team's
>>>> ongoing effort to review key IETF documents. These comments were written
>>>> primarily for the transport area directors, but are copied to the document's
>>>> authors and WG to allow them to address any issues raised and also to the IETF
>>>> discussion list for information.
>>>> 
>>>> When done at the time of IETF Last Call, the authors should consider this
>>>> review as part of the last-call comments they receive. Please always CC
>>>> [e-mail] <mailto:[e-mail]> if you reply to or forward this review.
>>>> 
>>>> This document specifies how STAMP [RFC8762] [RFC8972] test packets are
>>>> encapsulated for MPLS LSPs and PWs, in two formats: Format-1 with an IP/UDP
>>>> header over the existing IPv4/IPv6 G-ACh types, and Format-2 with no IP/UDP
>>>> header over two new G-ACh types. The document is clearly written and the
>>>> figures and the use case table are helpful.
>>>> 
>>>> >From a transport perspective my main concern is with Format-2: removing the
>>>> IP/UDP header also removes the 4-tuple that RFC 8762/RFC 8972 rely on for
>>>> session identification, and removes the UDP-based guidance on test traffic
>>>> load that this document inherits by reference. Neither is replaced by
>>>> anything in this document. I have listed that and a few related items below.
>>>> I think these are addressable with text, so I would call this ready with
>>>> issues.
>>>> 
>>>> ISSUES:
>>>> 
>>>> 1. Session identification in Format-2 (Sections 3.1, 4.2, 5.2)
>>>> 
>>>> Section 3 of [RFC8972] says: "A STAMP Session is identified by the 4-tuple
>>>> (source and destination IP addresses, source and destination UDP port
>>>> numbers)", and further: "An implementation of the STAMP Session-Reflector
>>>> that supports this specification MUST identify a STAMP Session using the SSID
>>>> in combination with elements of the usual 4-tuple for the session ... A STAMP
>>>> Session-Reflector MUST discard non-matching STAMP test packets."
>>>> 
>>>> In Format-2 there is no 4-tuple at all, so this normative requirement cannot
>>>> be met as written, and the document does not say what replaces it. Section
>>>> 3.1 only explains how Session-Sender packets are told apart from
>>>> Session-Reflector packets (by channel type), not how two concurrent sessions
>>>> between the same pair of PEs over the same LSP or PW are told apart, or what
>>>> "non-matching" means for a Format-2 packet.
>>>> 
>>>> I think the document needs to state explicitly what identifies a STAMP
>>>> session in Format-2 - presumably the LSP/PW context (incoming label) plus the
>>>> SSID [RFC8972] - and, if the SSID is the only per-session discriminator, that
>>>> the SSID MUST be present and non-zero in Format-2 test packets. Note that the
>>>> SSID is only a MAY in Section 3 of [RFC8972], so this needs to be said here.
>>>> The payload references in Figures 3 and 5 already point at Figures 1-4 of
>>>> Section 3 of [RFC8972], i.e., the SSID-bearing formats, but the running text
>>>> never says so, and the SSID appears nowhere in the document except in Table 1
>>>> and in the Security Considerations. 
>>>> 
>>>> Relatedly, 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 say 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.
>>> 
>>> <RG> Added new Section 3.1.1 for this.
>>>  
>>>> 
>>>> 2. No congestion or test-load considerations for the PW / Format-2 case
>>>>    (Sections 6, 7)
>>>> 
>>>> Section 7 of [RFC8762] requires that "The load of the STAMP-Test packets
>>>> offered to a network MUST be carefully estimated" and points at Section 3.1.5
>>>> of [RFC8085] for UDP-based load guidance. This document inherits that by
>>>> reference in Section 7, which is fine for Format-1, but Format-2 test packets
>>>> are not UDP at all, and this document nowhere discusses test packet rate or
>>>> bandwidth.
>>>> 
>>>> More specifically, this document defines a new application of the VCCV
>>>> Control Channel for PWs, and Section 9 ("Congestion Considerations") of
>>>> [RFC5085] says "VCCV applications (i.e., Connectivity Verification (CV)
>>>> Types) MUST consider congestion and bandwidth usage implications and provide
>>>> details on bandwidth or packet frequency management", with a recommended
>>>> limit of 5% of the PW bit rate for the ICMP and MPLS LSP Ping applications.
>>>> Section 7 of this document cites Section 10 of [RFC5085] for message
>>>> throttling, but Section 9 of [RFC5085] is not referenced anywhere.
>>>> 
>>>> This matters most for the constant bit rate services this document explicitly
>>>> targets: PLE [RFC9801] and TDM over IP [RFC5087] PWs. Because the test
>>>> packets deliberately use the same label stack and the same forwarding
>>>> treatment as the client traffic, the test load is taken from inside the PW's
>>>> allocation, which is the opposite of the assumption in Section 9 of [RFC5085]
>>>> ("The bandwidth required for the VCCV channel is taken outside any allocation
>>>> for PW data traffic"). Section 6 should discuss the rate at which test
>>>> packets are transmitted, that it is accounted for when the PW bandwidth is
>>>> provisioned, and that the Section 9 of [RFC5085] guidance applies to both
>>>> formats. Please also state whether any bound applies to the reflected
>>>> direction, given that the Session-Reflector replies to every received test
>>>> packet and the reverse LSP/PW may have less capacity than the forward one.
>>>> 
>>>> [RFC9780], which this document already cites, is a useful precedent for the
>>>> amount of text I am asking for: its Section 6 asks the operator to consider
>>>> the rate of Control packet generation and the extra traffic it produces, and
>>>> even the packet size difference between IP/UDP and G-ACh encapsulation.
>>> 
>>> 
>>> <RG> Added new Section 6.2 for this.
>>> 
>>>  
>>>> 
>>>> 3. UDP checksum handling is unspecified for Format-1 (Sections 4.1, 5.1)
>>>> 
>>>> Neither [RFC8762] nor this document says anything about the UDP checksum, and
>>>> in this encapsulation the question is sharper than in native STAMP: the
>>>> packet is delivered by G-ACh channel type rather than by IP forwarding, and
>>>> the destination address may be a 127/8 or 100:0:0:1::/64 address that never
>>>> appears on the wire outside the tunnel, so an implementation may be tempted
>>>> to skip the checksum. Please state whether the Session-Sender and
>>>> Session-Reflector MUST compute the UDP checksum and whether the receiver MUST
>>>> verify it. For IPv6 in particular, a zero UDP checksum is not permitted by
>>>> default (Section 8.1 of [RFC8200]: "IPv6 receivers must discard UDP packets
>>>> containing a zero checksum"), and the tunnel-encapsulation exception there
>>>> requires following [RFC6936]. If zero-checksum operation is intended for this
>>>> encapsulation, that needs to be stated and justified explicitly.
>>>> 
>>>> Two things make this more than a formality: in unauthenticated mode there is
>>>> no other integrity check on the test packet, and Section 7 relies on
>>>> sanity checks such as "T2 is later than T1" to catch bad packets, which a
>>>> corrupted timestamp can easily pass; and implementations that write the
>>>> transmit timestamp in hardware late in the transmit path have to update the
>>>> checksum accordingly.
>>> 
>>> <RG> Added new Section 3.2.3 for this.
>>>  
>>>> 
>>>> 4. Sender source port should be constrained in Format-1 (Sections 3, 3.1)
>>>> 
>>>> Section 3.1 says the packets are distinguished by destination UDP port, and
>>>> Figure 4 shows the reflected packet's destination port set to the
>>>> Session-Sender's source port. Since [RFC8762] leaves the source port free, a
>>>> Session-Sender that happens to choose the session's destination port (862 or
>>>> the configured port) as its source port makes the two directions
>>>> indistinguishable, and a reflected packet arriving at either node would be
>>>> parsed as a Session-Sender packet and reflected again. Please add a
>>>> requirement that the Session-Sender MUST NOT use the session's destination
>>>> UDP port as its source UDP port, or specify some other unambiguous rule.
>>> 
>>> 
>>> <RG> Updated Section 3 to add this.
>>>  
>>>> 
>>>> 5. No packet size / MTU considerations (Section 6)
>>>> 
>>>> The document does not discuss test packet size. Format-1 adds 4 octets of
>>>> G-ACh and Format-2 adds 4 octets of G-ACh plus, where GAL is used, another 4
>>>> octets of label stack, relative to the data traffic being measured, and
>>>> [RFC8972] allows sizeable padding, with the default symmetric sizing meaning
>>>> the reflected packet matches the size of the received one. A test packet that
>>>> exceeds the LSP or PW MTU will be dropped rather than fragmented - no transit
>>>> LSR will look inside a G-ACh to fragment the payload - so it shows up as
>>>> loss, i.e., as a measurement result rather than as a configuration error, and
>>>> the same applies independently to the reverse direction for the reflected
>>>> packet. A short paragraph in Section 6 noting that the test packet size
>>>> including this overhead has to fit the MTU in both directions, and that
>>>> Format-1 test packets should be sized to avoid IP fragmentation, would be
>>>> useful. Section 6 of [RFC9780] does something similar in noting the size
>>>> difference between the IP/UDP and G-ACh encapsulations.
>>> 
>>> <RG> Added new Section 6.3 for this.
>>>  
>>>> 
>>>> 6. Interaction between punt-path policing and loss measurement (Section 7)
>>>> 
>>>> 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. 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 5 of [RFC9780] makes a similar recommendation for a
>>>> rate limiter on the packets passed to the control plane for processing. This
>>>> is really a note for Section 6 rather than a change to Section 7.
>>> 
>>> <RG> Added new Section 6.1 for this.
>>>  
>>>> 
>>>> 7. Broken-LSP considerations only cover Session-Sender packets (Section 6.1)
>>>> 
>>>> Section 6.1 and the filtering guidance address Session-Sender packets and
>>>> rely on a non-routable destination address. The reflected packet always
>>>> carries a routable destination address, namely the Session-Sender's source
>>>> address (Figure 4), so if the reverse LSP or PW is broken it can be
>>>> IP-forwarded off-path or out of the domain, and destination-address-based
>>>> filtering at the domain edge does not help there. Please say whether the same
>>>> considerations and filtering are expected for the reflected direction, and
>>>> what the Session-Reflector does when no reverse-direction LSP/PW context
>>>> exists at all.
>>> 
>>> <RG> Updated Section 7 to add this.
>>>  
>>>> 
>>>> NITS:
>>>> 
>>>> 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. Suggest aligning the wording, e.g. "uses
>>>> destination UDP port 862 as the default destination port, as specified in
>>>> Section 4.1 of [RFC8762]".
>>> 
>>> <RG> Fixed.
>>>  
>>>> 
>>>> 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.
>>> 
>>> <RG> Fixed.
>>>  
>>>> 
>>>> 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. Consider non-normative phrasing ("needs to") in this section,
>>>> since the normative behaviour is specified in Sections 3 to 5 anyway.
>>> 
>>> <RG> Fixed.
>>>  
>>>> 
>>>> 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". Also, 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] arguably belongs in the normative references, and a
>>>> half-sentence pointing at it would save the next reader the same detour.
>>> 
>>> <RG> Fixed.
>>>  
>>>> 
>>>> Section 5.2, Figure 5 caption: "without IP/ UDP Header" - extra space before
>>>> UDP.
>>> 
>>> <RG> Fixed.
>>>  
>>>> 
>>>> 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." 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."
>>> 
>>> <RG> Fixed.
>>> 
>>> Thanks,
>>> Rakesh (for authors)
>>> 
>>> 
>>>  
>>>> 
>>>> Thanks,
>>>> Vidhi
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> mpls mailing list -- [e-mail] <mailto:[e-mail]>
>>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> 
>> 
>> _______________________________________________
>> Tsv-art mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> _______________________________________________
> Tsv-art mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>