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 A3A2D7AF5756 for ; Thu, 23 Oct 2025 05:40:56 -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=unavailable 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 7lGXnzvPALNh for ; Thu, 23 Oct 2025 05:40:55 -0700 (PDT) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (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 6487A7AF5736 for ; Thu, 23 Oct 2025 05:40:55 -0700 (PDT) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-784807fa38dso8718137b3.2 for ; Thu, 23 Oct 2025 05:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761223255; x=1761828055; 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=zusW5MARmSQMGApm+8WngZEGu6DrFBNfA/dH4HtYznQ=; b=AVTnYZiizKamuCoDwDK026leIkt74Cgdxmzv70IN1Fu9Ta8lAA1kNhCyK4393UHX8t vzRll+ylpW131aRRRxz7q9HdjaPDzFH1sy40XFriOaxEymi4vm82mqVHB9C6FPNtHV5O FNcsSQ+tUtM8PAFKMb2C3wNQu4TOecvcJ7XgwK9v3t+f9AZsDW5p9y11BH7A7W1Spt+o /qVjdxjbJUrWN+OKgrqz7f89HOKolv21CeagLc3yEbBak8S5z8UgOo8TqUhZc01LVjdW nlT+DCc7izvLYNTsANMvNLzwktSfc5CaFqTPzk+euDkmR1vuOm+JCBt4PAWGehPUGuGM KXXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761223255; x=1761828055; 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=zusW5MARmSQMGApm+8WngZEGu6DrFBNfA/dH4HtYznQ=; b=dQBI0s2E92xFI4Jzus5iDorn4gK6gj5OGtGksTThmKu1/UTgVf6LN9ixqCqobOKoCI VN4pX6aSFQ6ZOR+sxeKddr0NjKk7jZJcAEShBU1eS76ldOWzDgZhl2UAq5cKXh/7E+o+ X5CwSpus/0tPGeoJ/s3tgZSDXnK7cs9lYlN3F/4OniBFp9eILwrL5eEYyBk3o63u33CT /dvmw8xo4UxKtVpYUze9RYbXx8UQlN2T3NTbnfl25eDeax/3U1S71H6zj1RC9nXdTntd TCqRrDKS8P3wJD7L6aihe24ktaUuDY6si97cc2HXuqe6/x5hb0vOvRHLu+4xNbCA1IZQ U7Sw== X-Forwarded-Encrypted: i=1; AJvYcCXKz0ndhSiqbh7dvzf2YMVW/4CeK1fy0t4canG2SRT39fy826fO5oMh9QmZpXoy+TnmBzN6@ietf.org X-Gm-Message-State: AOJu0YzXhY0aZ7MySSwotE5x5N/9Ta64vgOqIfCU2XsZKzSZH7bgZKhL CCZmdZFWV/xBvZAsoRoJJxkv3lBpQ6j0tQgXljJUvM3Z5vrb0Dmmy8IyG+PUi1CkaTs8Ws/tLsM JqjbOSPKpxhQ9JJFh1LQjMs9WGPRRCTk= X-Gm-Gg: ASbGncuYFhZJ6LVz2ova5T/7t6kcPjcQpTZZYY6/ysma2rlDKjClEAEBnTG0D0dPPZl g2EI8FRBhVoJrdcOvu6U1i5rskYBZoUPvqia2bGoIq9HuBochimSy+ZzVRg4n53R+6/ImOY2VGY xGBbSWoUgybPjlFgHvQOT9MCkwaHtNnmAcPm9KLDQGgCebeipdN7uiD7nhrGMEsumCd1Li2t91s ki9oIeuGdFlxAG2efXYESbDEh6f/bfh8RwlLM1lzm2g06khihfUl6MrxqxKn7bKPjfQfR0SGy72 hfMQJIpVvZ9tsPblmg== X-Google-Smtp-Source: AGHT+IFuzGa87Lqzh5+qmVJdwJyKiHVvj2PcbggPP6J730/ds8eVZUGJtxaF7qOo7/MF3Nivx8yAqVM/E12R1/e2r34= X-Received: by 2002:a05:690c:6d86:b0:73c:d011:5769 with SMTP id 00721157ae682-7836d32682fmr226723207b3.52.1761223254788; Thu, 23 Oct 2025 05:40:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Loa Andersson Date: Thu, 23 Oct 2025 14:40:44 +0200 X-Gm-Features: AWmQ_bnYvYe4QvGWgqOOLXdkIzSSFPvWqtEp8sR0kKx6FNXRDZi4L7CXaM9cv9w Message-ID: To: Rakesh Gandhi Content-Type: multipart/alternative; boundary="00000000000078cc590641d2bea3" Message-ID-Hash: M2OSW2EIIFJ32RGYNWWQFCHYTYJKI5HR X-Message-ID-Hash: M2OSW2EIIFJ32RGYNWWQFCHYTYJKI5HR X-MailFrom: loa.pi.nu@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: "zhangli (CE)" , "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: --00000000000078cc590641d2bea3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Raksh, Inline plz. On Thu, 23 Oct 2025 at 14:24, Rakesh Gandhi 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 b= e > set to an IP address on the Session-Reflector node or an IPv4 address fro= m > 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 o= r > 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=E2=80=AFPM Rakesh Gandhi > 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 th= e >> 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 (match= ing 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 Desti= nation >>> 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 tunne= l >>> 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 STA= MP >>> 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 tun= nel >>> 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 >>> >>> >>> >>> >>> >>> *=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-st= amp >>> >>> >>> >>> >>> >>> [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:00 PDT. >>> >>> Thanks, >>> T >>> >>> >>> _______________________________________________ >>> mpls mailing list -- mpls@ietf.org >>> To unsubscribe send an email to mpls-leave@ietf.org >>> >> _______________________________________________ > mpls mailing list -- mpls@ietf.org > To unsubscribe send an email to mpls-leave@ietf.org > --00000000000078cc590641d2bea3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Raksh,

Inline plz.=C2=A0

On Thu, 23 Oct 2025 at 14:24, = Rakesh Gandhi <rgandhi.ietf@gm= ail.com> wrote:
Hi Li,

I haven't heard back f= rom you.=C2=A0
I assume that my previous = email clarifies your issue.=C2=A0
With th= is, 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>


I thought Greg pointed out a risk that using IP addresse= s associated with destination node may be leaked out of MPLS network.=C2=A0=

s/would be/MUST be/ ?

Also, a PHPed packet that= reaches the LER by definition arrives on the LSP. No problem for payload p= ackets, the LER knows how to forward the packet. What=C2=A0=C2=A0method do = the LER use to decide what LSP the PHPed=C2=A0=C2=A0STAMP packets belong to= ?

/Loa


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 Gandh= i <rgandhi.i= etf@gmail.com> wrote:
Hi Li,

<= font size=3D"2">I am afraid your assertion of the destination=C2=A0address = usage is not correct.

STAMP test packets can carry either address, session-re= flector node address or ipv4 127/8 address (or IPv6 equivalent) in the DA o= f the IP header. This is covered by the STAMP extensions for MPLS defined i= n 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
_______________________________________________
mpls mailing list -- mpl= s@ietf.org
To unsubscribe send an email to mpls-leave@ietf.org
--00000000000078cc590641d2bea3--