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

[Rakesh Gandhi <[e-mail]>]

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