Return-Path: X-Original-To: mpls@mail2.ietf.org Delivered-To: mpls@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 89B8A7AF30E1 for ; Thu, 23 Oct 2025 05:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNOa_a5T8PTl for ; Thu, 23 Oct 2025 05:23:37 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 262727AF3007 for ; Thu, 23 Oct 2025 05:23:07 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-62fc0b7bf62so1120629a12.2 for ; Thu, 23 Oct 2025 05:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761222186; x=1761826986; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7cJzZ2pU69dVcf92+/v9P+kpXzcJttQUN9k8mye9plw=; b=gXeakjbywKpqdbhw+nQuYjARXJ3pw5JvN8iiR89Bucjeq1KYuDW5Un3a4hNtEV7wJo envhiq8KDW/MhUYIfizbKceKGJQ6PHjlOibIvWFH5NkYoRBjaLu2dCTNSJxBVoXXJ1ux tNTe2GZ8NK+RlQE13nKST/93HBKslj+Vo1JXTjsjlci4EfqLNlSZvXJxkxq207jYqndH YSYFEPziqwcCvKdoN5DnGre5tnv1sv2vj5LkKBqETGt15KeMBgP/2IP0buyYdLVrUH6Q R5PKnfYs1Z/XmgSh1XR6wS5OndA8s24qatUnp2LC/PyuAAdAhHRd/+ZUeB7fnUg6aK0p 1qPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761222186; x=1761826986; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7cJzZ2pU69dVcf92+/v9P+kpXzcJttQUN9k8mye9plw=; b=KDltn6xGYWHSMsNfZ/AbGR1VjmFV5s2T9DzcOzpmjYJUX3b4HcJyORMp2ONHqwH8Up exZ6BdgwCj8COtQJegcqzEysizcldhJUj4xDzWyFs4+LfawdvD52aZKp/kV57L1MWJKi BlqxifN2aURLmYVsLNfauoAeF80yesIbzW4mTXHBafpBN3gocklxy6TbNh65emZ6SVwb X6WYSAOi7xUjgKbtTVXLMMfxyaWb+1QSlH7zKlyf0PSU0MqVXQOC60rK1GNd2ILpnOhB Lt41El6+GRT+8wijam/hpgM0TNNXzyBScBcb3fY+2SMWCzQSiIjAaZALfO98YoAWC10b K8GQ== X-Forwarded-Encrypted: i=1; AJvYcCV6VPXTKX2mpMFO3ekslECoEXcwlb6iR0Ngpz/nNBEkQtq+MAz+wF6/fTJVHz1slUYTpR0t@ietf.org X-Gm-Message-State: AOJu0YxbvzHq4pC0L5fgRBmZro7bJZwvHBBbYDhVOvu2KgXN+qIQBm5W bYAyd99btxsMkwqQI02kN1qJfz52yv5riF+y7xtypo51pvHPHV1O5sHm3ea2WHHIeUyfSnHi2ny JjPJ9ysLZMtvVdmcjGL4Oxhmh0jViiMEVXK2TLg== X-Gm-Gg: ASbGnctQFZGQaKJjlIBG0HJ82/uGlSBnOtLOtIrnKuw14AhnL97UWcH+NK/3jNb2IYn KIGe3H2pM+5ouodmxl2PYK2cdFk/559zBLmOOsneRcVH1ftV8IUTrRVi0ZmxqVRwNFReU5zM4w/ 79pO4FGwT38WNKsgkSka2x1sMDExzX6zfc4vNn7sMh/FMdhWn2pvDmYIWAOqIYDKF4FnLjqKjmT ch2rL/RKREbZkZwOe2kRXmO4Fl8hinWcpecgMaZnGZ/6shE/YOLTP9gHjcW X-Google-Smtp-Source: AGHT+IG5Jd7WAkiGm+oZwEnbaWT+1pLNbMAU6KtY+KDvdT1y6xClolKqR2xbBIUem8w9o/kJJoTekachZTxAJC9/q5Q= X-Received: by 2002:a05:6402:1ed2:b0:63c:276b:1504 with SMTP id 4fb4d7f45d1cf-63c276b1683mr23192719a12.19.1761222185834; Thu, 23 Oct 2025 05:23:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rakesh Gandhi Date: Thu, 23 Oct 2025 08:22:53 -0400 X-Gm-Features: AS18NWCGsE05c5dC7u9jhVqXrVt9DhTGYxoYd-Ey9IhLaLZaZBklcLvORBQjHxM Message-ID: To: "zhangli (CE)" Content-Type: multipart/alternative; boundary="000000000000c1dc040641d27ed5" Message-ID-Hash: OGAFRDRUPK3WOWDDNJHZWZCUC4TUUCWG X-Message-ID-Hash: OGAFRDRUPK3WOWDDNJHZWZCUC4TUUCWG X-MailFrom: rgandhi.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "draft-ietf-mpls-stamp-pw@ietf.org" , mpls X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_Adoption_poll_for_draft-mirsky-mpls-stamp?= List-Id: Multi-Protocol Label Switching WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000c1dc040641d27ed5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Rakesh Gandhi wrote: > Hi Li, > > I am afraid your assertion of the destination address usage is not correc= t. > > 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 f= ound) > 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 (matchi= ng STAMP > UDP port). > 2. STAMP measurement is incorrect *either way.* > > > Hope this helps. > > Thanks, > Rakesh > > > > On Thu, Sep 4, 2025 at 10:01=E2=80=AFPM zhangli (CE) 40huawei.com@dmarc.ietf.org> 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 Destin= ation >> IP address of IP/UDP form of the STAMP test packet. >> >> 1. draft-ietf-mpls-stamp-pw defines that the Destination IP >> Address=3DSession-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 STAM= P >> 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 tunn= el >> 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-m= pls-stamp-pw, >> then we can remove this part and reference draft-ietf-mpls-stamp-pw to >> avoid overlap. >> >> >> >> Best regards >> >> Li >> >> >> >> >> >> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Tony Li *=E4=BB= =A3=E8=A1=A8 *Tony Li >> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2025=E5=B9=B49=E6=9C=881=E6=97= =A5 23:51 >> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* mpls >> *=E4=B8=BB=E9=A2=98:* [mpls] Re: Adoption poll for draft-mirsky-mpls-sta= mp >> >> >> >> >> >> [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=E2=80=AFAM, Tony Li 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:0= 0 >> PDT. >> >> Thanks, >> T >> >> >> _______________________________________________ >> mpls mailing list -- mpls@ietf.org >> To unsubscribe send an email to mpls-leave@ietf.org >> > --000000000000c1dc040641d27ed5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Li,
=

I haven't = heard back from you.=C2=A0
I assume that = my previous email clarifies your issue.=C2=A0
With this, I like to propose the following update to the=C2=A0draft-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 defin= ed in [RFC9503] using the destination address STAMP TLV can be followed. In addit= ion, MPLS encapsulation using penultimate-hop-popping needs to ensure that the S= TAMP packets reach the egress node of the LSP for end-to-end measurement.<= /span>

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."<= span>


Please advise if this update to=C2=A0draft-ietf-= mpls-stamp-pw-01=C2=A0addresses your comment.


Thanks,

=

Rakesh





On Tue, Oct 21,= 2025 at 3:54=E2=80=AFPM Rakesh Gandhi <rgandhi.ietf@gmail.com> wrote:
Hi Li,
I am afraid your assertion of the desti= nation=C2=A0address usage is not correct.

STAMP test packets can carry either= address, session-reflector node address or ipv4 127/8 address (or IPv6 equ= ivalent) in the DA of the IP header. This is covered by the STAMP extension= s 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:

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 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.

    =C2=A0

    2.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 LSP broken Example 2: STAMP packet gets mis-forw= arded

      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.
      <= /ol>

      =C2=A0

      <= font size=3D"2">Hope this helps.

Thanks,
Ra= kesh



On Thu, Sep 4, 2025 at 10:01= =E2=80=AFPM zhangli (CE) <zhangli344=3D40huawei.com@dmarc.ietf.org> wrote:<= br>

Hi Tony,

=C2=A0

Thanks for proposing this question, I just have a discussion wit= h other co-authors of draft-= mirsky-mpls-stamp, here is our reply:

=C2=A0

Both of these two drafts defines the =C2=A0encapsulation of a ST= AMP Test Packet over MPLS LSP, but they have different definitions for the Destin= ation IP address of IP/UDP form of the STAMP test packet.

= 1.=C2=A0=C2=A0=C2=A0 draft-ietf-mpls-stamp-pw defines that the Destination IP A= ddress=3DSession-Reflector IPv4 or IPv6 Address.

= 2.=C2=A0=C2=A0=C2=A0 draft-mirsky-mpls-stamp defines that the destination IP ad= dress MUST be chosen from the IPv4 127/8 range or IPv6 Dummy Prefix range.<= u>

=C2=A0

Both of the above solution can get a correct result when the MPL= S tunnel is not broken.

=C2=A0

However, when the MPLS tunnel is broken, the first solution defi= ned 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 wi= ll discard the miswired IP/UDP encapsulated STAMP packet when the MPLS tunn= el is broken, because the destination IP address is not reachable.

=C2=A0

So, based on the above analysis, the second solution seems more = reasonable.

=C2=A0

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-m= pls-stamp-pw to avoid overlap.

=C2=A0

Best regards

Li

=C2=A0

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: Tony Li <tony1athome@gmail.com> =E4= =BB=A3=E8=A1=A8 Tony Li
=E5= =8F=91=E9=80=81=E6=97=B6=E9=97=B4:= 2025= =E5=B9=B49=E6=9C=881=E6=97=A5 23:51
=E6=94=B6=E4=BB=B6=E4=BA=BA: mpls <mpls@ietf.org>
=E4=B8=BB=E9=A2=98: [mpls] Re: Adoption poll for draft-mirsky-mpls-stamp<= /span>

=C2=A0

=C2=A0

[WG chair hat: off]

=C2=A0

Hi,

=C2=A0

Could the authors please compar= e and contrast their draft with=C2=A0draft-ietf-mpls-stamp-pw?



Thanks,<= /span>

T=





On Sep 1, 2025, at 8:47<= span lang=3D"EN-US" style=3D"font-family:"Times New Roman",serif"= >=E2=80=AFAM, Tony Li <tony.li@tony.li> wrote:

=C2=A0

[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 P= DT.

Thanks,
T

=C2=A0

_______________________________________________
mpls mailing list -- mpl= s@ietf.org
To unsubscribe send an email to mpls-leave@ietf.org
--000000000000c1dc040641d27ed5--