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

[Rakesh Gandhi <[e-mail]>]

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)



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