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

[Gorry Fairhurst <[e-mail]>]

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 [e-mail]