[mpls] Re: [EXTERNAL] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim

Tianran Zhou <zhoutianran@huawei.com> Sat, 22 February 2025 03:45 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA67C1D52EC for <mpls@ietfa.amsl.com>; Fri, 21 Feb 2025 19:45:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.204
X-Spam-Level:
X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8BYdiQul9XK for <mpls@ietfa.amsl.com>; Fri, 21 Feb 2025 19:45:53 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C496C1DA1EB for <mpls@ietf.org>; Fri, 21 Feb 2025 19:45:53 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Z0CXl3HKwz6K9fJ; Sat, 22 Feb 2025 11:44:07 +0800 (CST)
Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 7C3D31400DC; Sat, 22 Feb 2025 11:45:50 +0800 (CST)
Received: from kwepemf500007.china.huawei.com (7.202.181.245) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Sat, 22 Feb 2025 03:45:49 +0000
Received: from kwepemf100007.china.huawei.com (7.202.181.221) by kwepemf500007.china.huawei.com (7.202.181.245) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 22 Feb 2025 11:45:47 +0800
Received: from kwepemf100007.china.huawei.com ([7.202.181.221]) by kwepemf100007.china.huawei.com ([7.202.181.221]) with mapi id 15.02.1544.011; Sat, 22 Feb 2025 11:45:44 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Tony Li <tony.li@tony.li>
Thread-Topic: [mpls] [EXTERNAL] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim
Thread-Index: AQHbhMIkYOMD4eFc9kaI2KgeuQKtZbNSflCQ//9/P4CAAIpE8P//l0IAgACNOBA=
Date: Sat, 22 Feb 2025 03:45:44 +0000
Message-ID: <207d56b907c54fee85f5438b288f2f8d@huawei.com>
References: <67b83dc5.0c0a0220.288dc3.13e2SMTPIN_ADDED_BROKEN@mx.google.com> <A4127697-D3DA-4D5A-A75A-625BA76B4D14@gmail.com> <6B4E7A96-7B96-4FF7-91A4-31C58361360B@tony.li> <b46f2dacf937484a8c79ca6c2c9997d7@huawei.com> <ACDF755E-AB0B-42A5-9A66-73B5A6D001BE@tony.li> <7f67091195164ed7b9d4a92cb2d73afe@huawei.com> <B34DF1C6-5CF1-437E-A8AD-EF651F1C6485@tony.li>
In-Reply-To: <B34DF1C6-5CF1-437E-A8AD-EF651F1C6485@tony.li>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.118]
Content-Type: multipart/alternative; boundary="_000_207d56b907c54fee85f5438b288f2f8dhuaweicom_"
MIME-Version: 1.0
Message-ID-Hash: E4FJAQRGPIB5QUVYZISYVJEAWKBJ42MP
X-Message-ID-Hash: E4FJAQRGPIB5QUVYZISYVJEAWKBJ42MP
X-MailFrom: zhoutianran@huawei.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: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, mpls <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [mpls] Re: [EXTERNAL] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/BXdktVmSFWUoI0XDFcritDctV8Y>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

When you put on the chair hat, this statement is really confusing to me.
There are 4 rules in the guideline. Could you please point out which rule you want to mention?
How it relates to my messages.

In the context, we are discussing the document type. And my suggestion is the ISD should be experimental and PSD should be standard track.
Could you please point out how I conflict with the WG consensus?

Tianran

From: Tony Li [mailto:tony1athome@gmail.com] On Behalf Of Tony Li
Sent: Saturday, February 22, 2025 11:11 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; mpls <mpls@ietf.org>
Subject: Re: [mpls] [EXTERNAL] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim

[WG chair hat: on]

Open does not mean that there are no boundaries. The IETF has code of conduct guidelines (https://datatracker.ietf.org/doc/html/rfc7154)  Please review them.
Violating this code has consequences, potentially including being banned from the mailing list.

The WG has reached consensus on progressing ISD and PSD.  This matter is no longer open for discussion.

T



On Feb 21, 2025, at 6:09 PM, Tianran Zhou - zhoutianran at huawei.com <mailforwards@cloudmails.net<mailto:mailforwards@cloudmails.net>> wrote:

I believe IETF is a place working on open standard.
Without open information, open discussion, the protocol can only be private, not be IETF one.
I believe many people share the same opinion on ISD as me.

Tianran


From: Tony Li [mailto:tony1athome@gmail.com] On Behalf Of Tony Li
Sent: Saturday, February 22, 2025 9:11 AM
To: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
Cc: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>>
Subject: Re: [mpls] [EXTERNAL] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim


Operators are not under any obligation to speak to you or the IETF.

I respect your opinion regarding ISD, however, I and many others do not share it.

Reiterating it is not helpful.

T




On Feb 21, 2025, at 4:53 PM, Tianran Zhou - zhoutianran at huawei.com<http://huawei.com/> <mailforwards@cloudmails.net<mailto:mailforwards@cloudmails.net>> wrote:

On one hand customers cannot provide more use cases.
On the other hand ISD is not future proof, with many limitations.
I do not think ISD is a good way to save bSPL.

Tianran

From: Tony Li [mailto:tony1athome@gmail.com] On Behalf Of Tony Li
Sent: Saturday, February 22, 2025 8:38 AM
To: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Cc: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>>
Subject: Re: [mpls] [EXTERNAL] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim


NFFRR is one use case, not the only one.

The whole point of going down this path was to stop burning a bSPL per function.

T





On Feb 21, 2025, at 3:37 PM, Stewart Bryant - stewart.bryant at gmail.com<http://gmail.com/> <mailforwards@cloudmails.net<mailto:mailforwards@cloudmails.net>> wrote:

If that really is the only viable use case perhaps we should just have a method of carrying a bag of bits in the stack.

If we have a use case for PSD with cash on the table maybe we should have a different independent method of doing that.

In other words instead of building a universal solution perhaps we should move to a series of problem specific solutions.

I would rather do this with eSPLs but if there is no consensus for that maybe we should use some of the remaining bSPLs, and hope we do not run.

Stewart




On 21 Feb 2025, at 08:48, Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org<mailto:zhoutianran=40huawei.com@dmarc.ietf.org>> wrote:

Yes, NFFRR is the only use case I have heard.
But if only for this, there is no need for the MNA. Just some small extension is enough.

Tianran





________________________________

Sent from WeLink
发件人: Tony Li<tony.li@tony.li<mailto:tony.li@tony.li>>
收件人: Tianran Zhou<zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
抄送: Dongjie (Jimmy)<jie.dong@huawei.com<mailto:jie.dong@huawei.com>>;Alexander Vainshtein<Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org<mailto:Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org>>;mpls<mpls@ietf.org<mailto:mpls@ietf.org>>
主题: Re: [mpls] [EXTERNAL] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim
时间: 2025-02-21 10:00:34

I am glad to see this. I am always interested about customer voice. But apparently we didn’t hear here on MNA.

My customers have been very vocal with me.  They want NFFRR support on legacy hardware.

T


_______________________________________________
mpls mailing list -- mpls@ietf.org<mailto:mpls@ietf.org>
To unsubscribe send an email to mpls-leave@ietf.org<mailto:mpls-leave@ietf.org>