[mpls] Re: Adoption poll for draft-mirsky-mpls-stamp

[Greg Mirsky <[e-mail]>]

Hi Rakesh,
please find my notes below tagged GIM>>.

Regards,
Greg

On Thu, Oct 23, 2025 at 5:45 AM Rakesh Gandhi <[e-mail]>
wrote:

> Hi Tony,
>
> Since your email says, “ I was hoping for more depth to the comparison,
> beyond just addressing.”,  I am summarizing my thoughts.
>
>
>
> *Reminder for STAMP*
>
> 1.      TWAMP with IP/UDP header defined in RFC 5357
>
>    - Using control channel signaling
>
> 2.      STAMP with IP/UDP header defined in RFC 8762 and optional
> extensions in RFC 8972
>
>    - Removes the need for control channel signaling
>       - Protocol simplification (just like S-BFD that removed LSP Ping
>       bootstrapping)
>
> 3.      STAMP extensions for SR-MPLS defined in RFC 9503
>
>    - MPLS Return Path STAMP TLV
>       - (Intended) Destination address STAMP TLV - for example, when
>       using an IPv4 address from 127/8 (or IPv6 equivalent) as the destination
>       address in the IP header
>
> GIM>> As I undertand the Destination Node Address TLV
<https://www.rfc-editor.org/rfc/rfc9503.html#name-destination-node-address-tl>,
it might be useful for deployments that use the Session-Reflector in
promiscious mode, i.e., the Session-Reflector is not aware of permitted
identities of Session-Senders. Would you agree?
GIM>> Furthermore, where in RFC 9503 is the choice of IP Destination
Address in the IP/UDP encapsulation of the STAMP packet specified?

>
>
>
>
> *MPLS Encapsulation Procedure*
>
> 1.      MPLS WG document *draft-ietf-mpls-stamp-pw-01* “*Encapsulation*
> of Simple Two-Way Active Measurement Protocol for Pseudowires and LSPs in
> MPLS Networks” covers the *delta* for MPLS LSPs and PWs, with or without
> IP/UDP header
>
> 2.      An update, if any, for MPLS encapsulation should be covered in
> the existing WG adopted document (*draft-ietf-mpls-stamp-pw*) as part of
> the normal WG review process.
>
> 3.      Section 2 titled “Encapsulation of a STAMP Test Packet” of the
> individual document *draft-mirsky-mpls-stamp-13* seems to repeat what is
> covered in this document (and above RFCs)
>
GIM>> I strongly disagree. Specified in draft-ietf-mpls-stamp-pw choice of
IP DA, i.e., routable address associated with the Session-Reflector,
violates the Clause 2 in Section 2.1 of RFC 8029
<https://www.rfc-editor.org/rfc/rfc8029.html#section-2.1>:
   2.  If an LSP is broken in such a way that it prematurely terminates,
       the diagnostic packet MUST NOT be IP forwarded.
The authors of draft-mirsky-mpls-stamp brought that to the attention of the
WG and will discuss it in our presentation in Montreal. The approach
specified in draft-mirsky-mpls-stamp doesn't repeat what is covered in
draft-ietf-mpls-stamp-pw or RFC 9503, but defiens the technically correct
approach to selecting the IP DA for IP/UDP encapsulation of a STAMP packet
in the MPLS network.

>
>
>
>
> *LSP Ping for STAMP in draft-mirsky-mpls-stamp-13*
>
> LSP Ping extension is defined in Section 3 titled “Bootstrap STAMP Using
> LSP Ping” of the individual document *draft-mirsky-mpls-stamp-13*:
>
>    1. Control-plane signaling
>    2. Optional
>    3. Specific to the “stateful” mode of the reflector
>    4. A standard method is already defined in RFC 9503 using the STAMP
>    return path TLV
>
> GIM>> AFAICS, RFC 9503 defines an optional STAMP extension that may be
used in some deployments.

>
>    1. It could progress in a separate document if the WG decides to work
>    on it
>    2. Strictly speaking, it is going against the protocol simplification
>    - it’s like adding LSP Ping to bootstrap S-BFD!
>
> GIM>> As noted above, the need to use the Destination Node Address TLV, in
my opinion, results from the way a specific implementation of STAMP is
deployed. Other implementations may not have the problem mitigated by the
Destination Node Address TLV.

>
>
> Thanks,
>
> Rakesh
>
>
>
>
> On Fri, Sep 5, 2025 at 1:50 PM Tony Li <[e-mail]> wrote:
>
>>
>> [WG chair hat: off]
>>
>>
>> Hi Zhangli,
>>
>> Thank you.  I was hoping for more depth to the comparison, beyond just
>> addressing.
>>
>> It seems to me that draft-ietf-mpls-stamp-pw requires the use of the PW
>> mechanism, but as a result, does not require the use of IP with STAMP.
>>
>> On the other hand, draft-mirsky-mpls-stamp requires UDP (and IP), but not
>> PW.
>>
>> I first have to ask: do we need both mechanisms?  So far, I see no reason
>> for having both in the toolbox.  Either will suffice.
>>
>> As such, do we really need two drafts?
>>
>> Thanks,
>> T
>>
>>
>> On Sep 4, 2025, at 7:00 PM, zhangli (CE) - zhangli344 at huawei.com <
>> [e-mail]> wrote:
>>
>> Hi Tony,
>>
>> Thanks for proposing this question, I just have a discussion with other
>> co-authors of draft-mirsky-mpls-stamp, here is our reply:
>>
>> Both of these two drafts defines the  encapsulation of a STAMP Test
>> Packet over MPLS LSP, but they have different definitions for the Destination
>> IP address of IP/UDP form of the STAMP test packet.
>> 1.    draft-ietf-mpls-stamp-pw defines that the Destination IP
>> Address=Session-Reflector IPv4 or IPv6 Address.
>> 2.    draft-mirsky-mpls-stamp defines that the destination IP address
>> MUST be chosen from the IPv4 127/8 range or IPv6 Dummy Prefix range.
>>
>> Both of the above solution can get a correct result when the MPLS tunnel
>> is not broken.
>>
>> However, when the MPLS tunnel is broken, the first solution defined in
>> draft-ietf-mpls-stamp-pw will make the miswired IP/UDP encapsulated STAMP
>> packet be routed to the destination and the metric will not be
>> representative of the network conditions.
>> While the second solution defined in draft-ietf-mpls-stamp-pw will
>> discard the miswired IP/UDP encapsulated STAMP packet when the MPLS tunnel
>> is broken, because the destination IP address is not reachable.
>>
>> So, based on the above analysis, the second solution seems more
>> reasonable.
>>
>> If we can reach consensus at this point with the authors of draft-ietf-mpls-stamp-pw,
>> then we can remove this part and reference draft-ietf-mpls-stamp-pw to
>> avoid overlap.
>>
>> Best regards
>> Li
>>
>>
>> *发件人:* Tony Li <[e-mail]> *代表 *Tony Li
>> *发送时间:* 2025年9月1日 23:51
>> *收件人:* mpls <[e-mail]>
>> *主题:* [mpls] Re: Adoption poll for draft-mirsky-mpls-stamp
>>
>>
>> [WG chair hat: off]
>>
>> Hi,
>>
>> Could the authors please compare and contrast their draft
>> with draft-ietf-mpls-stamp-pw?
>>
>>
>> Thanks,
>> T
>>
>>
>>
>>
>> On Sep 1, 2025, at 8:47 AM, Tony Li <[e-mail]> wrote:
>>
>>
>>
>> [WG chair hat: on]
>>
>> Hi all,
>>
>> This note begins a working group adoption poll for
>> draft-mirsky-mpls-stamp.
>>
>> Please express support or objection (with cause) by Monday, Sept. 1 12:00
>> PDT.
>>
>> Thanks,
>> T
>>
>>
>> _______________________________________________
>> mpls mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>