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

[Rakesh Gandhi <[e-mail]>]

Hi Vidhi,

Thank you for verifying the updates and your suggestions.

We have posted rev-12 that addresses your further comments.

  https://datatracker.ietf.org/doc/draft-ietf-mpls-stamp-pw/

Please see replies inline with <RG>...



On Thu, Aug 27, 2026 at 8:48 PM Vidhi Goel <[e-mail]> wrote:

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


<RG> Thanks for confirming these 7 issues as addressed.


> The nits are all taken care of too.
>

<RG> Great.


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

<RG> Great, thanks!


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

<RG> We took this approach of (b) in the latest updates.


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

<RG> Hope the latest updates address this concern.


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

<RG> Fixed.


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

<RG> Removed.


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

<RG> for the Stateful is removed.

Thanks,
Rakesh (for authors)



> 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]>
> 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]> 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] 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]
>>> To unsubscribe send an email to [e-mail]
>>>
>>
> _______________________________________________
> Tsv-art mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> Tsv-art mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>