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

[Rakesh Gandhi <[e-mail]>]

Thanks everyone for the comments and discussions.

Attaching the work in progress updates to draft-ietf-mpls-stamp-pw that
address the various comments.

Please let us know your review comments.

Thanks,
Rakesh (for authors)




On Thu, Oct 30, 2025 at 8:10 AM Rakesh Gandhi <[e-mail]>
wrote:

> Hi Loa,
>
> Thanks for your discussions.
> Please see replies inline with <*RG*>...
>
> On Thu, Oct 23, 2025 at 8:40 AM Loa Andersson <[e-mail]> wrote:
>
>> 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.
>>
>
>
> *<RG> I am not sure how STAMP packets leak outside the MPLS domain and not
> the data traffic going over the same broken LSP (that would be a generic
> problem).*
> *<RG> We can add something like the following in the
> draft-ietf-mpls-stamp-pw to address this comment:*
>
>
>
> *" The destination IP address-based filtering in the data plane,
> provisioned on the nodes in an MPLS network to prevent    the packets with
> a destination address to the nodes within the network from leaking to an
> outside IP network, ensures    that the STAMP packets with a destination to
> the egress node (STAMP reflector) of a broken LSP will not be leaked to an
> outside of the MPLS network."*
>
>
>
>
>>
>> s/would be/MUST be/ ?
>>
>
> *<RG> Not sure if the MPLS draft can specify the rule for analytics.*
>
>
>
>>
>> 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?
>>
>
> *<RG> The STAMP reflector replies back to the source address in the STAMP
> packet, there is no need to know which LSP on egress node. Sender knows
> based on the session ID in the reply packet.*
>
> *Thanks,*
> *Rakesh*
>
>
>
>
>> /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]
>>>
>>