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

[Rakesh Gandhi <[e-mail]>]

Hi Greg,

Thank you for your reply.
Please see replies inline with <RG>..


On Tue, Oct 21, 2025 at 4:49 PM Greg Mirsky <[e-mail]> wrote:

> Hi Rakesh,
> thank you for your response. Please find my notes below tagged GIM>>.
>
> Regards,
> Greg
>
> On Tue, Oct 21, 2025 at 12:55 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.
>>
> GIM>> AFAICS, RFC 9503 defines a number of STAMP extensions, including the
> Destination Node Address TLV. If you consider that TLV, then I agree with
> you that it can carry any IP address. I cannt find in RFC 9503 definition
> of setting IP DA for IP/UDP encapsulation of a STAMP test packet. I
> appreciate you helping me with pointing me to the right place in the RFC
> 9503.
>

<RG> RFC 8762 is based on IP addresses of the sender and reflectors. This
can be used in an MPLS network "as is" for performance measurement.
<RG> RFC 9503 extends it, for example, when DA is from 127/8 addresses, as
explained in Appendix A.



>
>> 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.*
>>
>> GIM>> The case of a broken LSP that we consider is the one when a packet
> with IP/UDP encapsulated STAMP test packet is terminated at a transit
> node, not the intended Session-Reflector. As I understand it, after the
> MPLS label stack is removed, and as the IP DA is not one of the IP
> addresses associated with the node, the IP packet is forwarded over the IP
> network, not punted to the control plane. In other words, OAM packet is
> leaked from the MPLS network into the IP network thus violating clause 2 in
> Section 2.1 of RFC 4379:
>    2. If an LSP is broken in such a way that it prematurely terminates,
>       the diagnostic packet MUST NOT be IP forwarded.
> Hence our conclusion that IP DA of IP/UDP encapsulated STAMP (and any OAM
> protocol for that matter) MUST guarantee that the packet is not leaked into
> the IP network. For that, draft-mirsky-mpls-stamp requires that for IPv4 an
> address from the loopback address range be used, and for IPv6 - an address
> from the IPv6 Dummy Prefix range.
>

<RG> RFC 4379 is for the MPLS Echo Request/Reply as a diagnostic tool.
There is no mention of performance measurement in that RFC.
<RG> MPLS nodes can perform IP packet forwarding, for example, for IMP-NULL
LSPs.

Thanks,
Rakesh




>
>>    1.
>>
>>
>> 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]
>>>
>> _______________________________________________
>> mpls mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>