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

[Rakesh Gandhi <[e-mail]>]

Hi Li,

I haven't heard back from you.
I assume that my previous email clarifies your issue.
With this, I like to propose the following update to the
draft-ietf-mpls-stamp-pw-01.


*"The destination address in the IP header of the STAMP test packet can be
set to an IP address on the Session-Reflector node or an IPv4 address from
the 127/8 range (or IPv6 equivalent).*

*When using the destination address from the IPv4 127/8 range (or IPv6
equivalent), the procedure defined in [RFC9503] using the destination
address STAMP TLV can be followed. In addition, MPLS encapsulation using
penultimate-hop-popping needs to ensure that the STAMP packets reach the
egress node of the LSP for end-to-end measurement.*

*Either way, the STAMP packets forwarded on a broken LSP would be dropped
just like the data traffic, resulting in STAMP session state being down or
mis-forwarded, leading to incorrect measurement, which would be detected by
the analytics."*

Please advise if this update to draft-ietf-mpls-stamp-pw-01 addresses your
comment.


Thanks,

Rakesh





On Tue, Oct 21, 2025 at 3:54 PM Rakesh Gandhi <[e-mail]>
wrote:

> Hi Li,
>
> I am afraid your assertion of the destination address usage is not correct.
>
> STAMP test packets can carry either address, session-reflector node
> address or ipv4 127/8 address (or IPv6 equivalent) in the DA of the IP
> header. This is covered by the STAMP extensions for MPLS defined in RFC
> 9503.
>
> The STAMP packets would follow the same ECMP path as the data traffic
> under measurement (using the same encapsulation) and they are treated the
> same way along the path. Following two could happen:
>
>
>
> 1.      LSP broken Example 1: STAMP packet is dropped
>
>    1. The transit node that drops the data traffic, would also drop the
>       STAMP packets (for the same reason, e.g., such as label entry not found)
>       irrespective of DA in the IP header of the STAMP packets.
>       2. The STAMP session is down *either way.*
>
>
>
> 2.      LSP broken Example 2: STAMP packet gets mis-forwarded
>
>    1. STAMP packet with DA in IP header set to either 127/8 address (or
>       IPv6 equivalent) or session-reflector node address is exposed on a node,
>       the packet would be locally "punted" to the STAMP reflector (matching STAMP
>       UDP port).
>       2. STAMP measurement is incorrect *either way.*
>
>
> Hope this helps.
>
> Thanks,
> Rakesh
>
>
>
> On Thu, Sep 4, 2025 at 10:01 PM zhangli (CE) <zhangli344=
> [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]
>>
>