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

[Loa Andersson <[e-mail]>]

Raksh,

Inline plz.

On Thu, 23 Oct 2025 at 14:24, Rakesh Gandhi <[e-mail]> wrote:

> 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."*
>

I thought Greg pointed out a risk that using IP addresses associated with
destination node may be leaked out of MPLS network.

s/would be/MUST be/ ?

Also, a PHPed packet that reaches the LER by definition arrives on the LSP.
No problem for payload packets, the LER knows how to forward the packet.
What  method do the LER use to decide what LSP the PHPed  STAMP packets
belong to?

/Loa

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