Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 23 February 2023 02:18 UTC

Return-Path: <jie.dong@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 53132C14CEED for <mpls@ietfa.amsl.com>; Wed, 22 Feb 2023 18:18:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.795
X-Spam-Level:
X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 wV7oBGoqvVlt for <mpls@ietfa.amsl.com>; Wed, 22 Feb 2023 18:18:40 -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 11E44C14CEE3 for <mpls@ietf.org>; Wed, 22 Feb 2023 18:18:40 -0800 (PST)
Received: from lhrpeml100006.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4PMc5S37czz6J6X0 for <mpls@ietf.org>; Thu, 23 Feb 2023 10:13:48 +0800 (CST)
Received: from kwepemi100017.china.huawei.com (7.221.188.163) by lhrpeml100006.china.huawei.com (7.191.160.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Thu, 23 Feb 2023 02:18:36 +0000
Received: from kwepemi500017.china.huawei.com (7.221.188.110) by kwepemi100017.china.huawei.com (7.221.188.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Thu, 23 Feb 2023 10:18:34 +0800
Received: from kwepemi500017.china.huawei.com ([7.221.188.110]) by kwepemi500017.china.huawei.com ([7.221.188.110]) with mapi id 15.01.2507.017; Thu, 23 Feb 2023 10:18:34 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, Joel Halpern <jmh@joelhalpern.com>
CC: mpls <mpls@ietf.org>
Thread-Topic: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?
Thread-Index: AQHZRlOWdX/KuXVW5UaFfD395E0pg67ZprgAgAEYmoCAAQr4cA==
Date: Thu, 23 Feb 2023 02:18:34 +0000
Message-ID: <2d587c97adc54256b1024dc5cfdda725@huawei.com>
References: <27b7ff60-4ce1-c053-5c87-42cb4919d79e@joelhalpern.com> <BY3PR13MB4787D662D08331C19F7FB4679AA59@BY3PR13MB4787.namprd13.prod.outlook.com> <97F4AD9B-E131-4BDB-A713-33DD3B0D1D16@tony.li> <BY3PR13MB4787643941C35EACB322010F9AA59@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+RyBmWQPZ8Yu2Xitw1JbEc_v7ZPPHkcj1L-5+fPTkZ36b-X1Q@mail.gmail.com> <BY3PR13MB4787D59355E94935CDEC21359AA59@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+RyBmVxm21a=1istKUcnzFHsabYTNqYk9oPpP98i8P9xMvN1Q@mail.gmail.com> <BY3PR13MB47878D42A5F93813F0863A6E9AA59@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+RyBmVD=apZX2UCT=cYEUg61qcEz8myeP2aNbzERkhK1d50eA@mail.gmail.com> <BY3PR13MB47879B845928B62F600CF47B9AAA9@BY3PR13MB4787.namprd13.prod.outlook.com> <979aa1f2-016d-5a5f-15ce-35893e66a4e0@joelhalpern.com> <79242C42-DF57-44F0-AD57-5B4E2222624D@gmail.com>
In-Reply-To: <79242C42-DF57-44F0-AD57-5B4E2222624D@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.66]
Content-Type: multipart/alternative; boundary="_000_2d587c97adc54256b1024dc5cfdda725huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/b3wYFMrGP2SPdfltI1nQvlhtEQg>
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2023 02:18:42 -0000

Hi Stewart,

The procedure described by Joel would be correct if there were no WG consensus, only agreement within the design team.

However it is not the case for MNA.  As I reminded Joel in one mail yesterday, there was a WG poll on “ISD and PSD in the MNA framework”, and the WG consensus is to have both ISD and PSD as part of the MNA framework. This is also reflected in the current MNA framework document.

Procedurally any change to that consensus requires another round of discussion, WG poll, and potential update of the MNA framework first, and in that case both of the solution documents would need to wait.

Best regards,
Jie

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Thursday, February 23, 2023 2:11 AM
To: Joel Halpern <jmh@joelhalpern.com>
Cc: mpls <mpls@ietf.org>
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

Procedurally Joel is completely correct

Stewart


On 22 Feb 2023, at 01:26, Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>> wrote:


Whatever the design team may or may not have agreed, a design team does not speak for a working group.  The working group has the right and responsibility to re-examine, and where appropriate revisit, any and all decisions of an IETF design team.  What that says about spending two years in a design team is a completely different question and not my concern.

Yours,

Joel


On 2/21/2023 7:19 PM, Haoyu Song wrote:
Hi Greg,

I don’t want to play the word game. You personally attended all the ODT meetings and participated in all the discussions. We reached the point to progress the two drafts which I think reflects the consensus although no official poll was made but the discussion results clearly show these are the outputs we’d like to progress. I think It’s wrong time to try to revoke the discussion results now. I remember you also raised the concerns for the solution’s complexity after the presentation of draft-jags. If the ODT now has other thoughts, then we have to restart all the work. I don’t feel that the way we want to go.

Best,
Haoyu

From: Greg Mirsky <gregimirsky@gmail.com><mailto:gregimirsky@gmail.com>
Sent: Tuesday, February 21, 2023 4:03 PM
To: Haoyu Song <haoyu.song@futurewei.com><mailto:haoyu.song@futurewei.com>; mpls <mpls@ietf.org><mailto:mpls@ietf.org>; MPLS Working Group <mpls-chairs@ietf.org><mailto:mpls-chairs@ietf.org>; pals@ietf.org<mailto:pals@ietf.org>; pals-chairs <pals-chairs@ietf.org><mailto:pals-chairs@ietf.org>; DetNet WG <detnet@ietf.org><mailto:detnet@ietf.org>; DetNet Chairs <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

Hi Haoyu,
can you refer me to the announcement by Chairs of the WGs that chartered the ODT of the "consensus"? Or your claim reflects your personal opinion?

Regards,
Greg

On Tue, Feb 21, 2023 at 3:46 PM Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>> wrote:
Greg,

I said it’s the ODT consensus and decision to progress the two draft as a unified MNA solution. Of course, once they are adopted, it’s MPLS WG’s duty to progress them.

Thanks,
Haoyu

From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Sent: Tuesday, February 21, 2023 11:38 AM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

Hi Haoyu,
can you point out the poll conducted by WGs Chairs that is the basis for your claims of the "consensus"?

Regards,
Greg

On Tue, Feb 21, 2023, 11:33 Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>> wrote:
Greg, answers to your two questions: ODT, and the documents under adoption call.
Thanks,
Haoyu

From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Sent: Tuesday, February 21, 2023 11:29 AM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
Cc: Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>>
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

Hi Haoyu,
can you please clarify which group you have in mind when stating that there's a consensus? I think that the consensus was demonstrated on the MNA drafts adopted by the MPLS WG. Which documents you consider also having the same level of support?

Regards
Greg

On Tue, Feb 21, 2023, 11:19 Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>> wrote:
Hi Tony and Joel,

All those issues have been discussed many times and now the documents reflect the consensus. I don’t think it's a wise idea to rewind the discussion back to the state as two years ago.

Best regards,
Haoyu

-----Original Message-----
From: Tony Li <tony1athome@gmail.com<mailto:tony1athome@gmail.com>> On Behalf Of Tony Li
Sent: Tuesday, February 21, 2023 10:59 AM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
Cc: Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?


Hi Haoyu,


> IOAM is not the only use case. You can check the use case document for more examples.


I checked. I didn’t see any. Section 2.5.1 does specify that ISD or PSD could be used. That certainly doesn’t seem like a compelling use case for PSD.  In fact, in latency sensitive applications, I would think you would want to use ISD simply for the performance benefits.


> I'm sure there are even more use cases once we have this mechanism.  Actually, IOAM DEX, which is a postcard method, also need post stack encapsulation for the instruction header.


I believe that there are changes in IOAM DEX that will remove that requirement.


> As for the complexity, I've evaluated that and given presentations that post stack data parsing is simpler than in-stack data parsing. The action processing is a property of the action itself so it's location is out of consideration.
> During the ODT discussion, many people actually raised the question that weather the ISD is necessary because PSD can basically support all use cases, regardless the size of the data. The conclusion is still true: considering all the possible use cases, if only one mechanism exists, it should be PSD. We resort to having both because ISD can handle some use cases with small data.



As we’ve discussed MANY times, PSD will have a significant performance impact on several architectures, most notably legacy (i.e., currently deployed) hardware. As a result, MNA is effectively undeployable without ISD.  And given ISD, we have no need for PSD.

Tony

_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=05%7C01%7Chaoyu.song%40futurewei.com%7Ce5400b24b98f46ed0e8a08db14682d61%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638126209893469665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nLnT4iwS%2F0s%2F%2BvNO1lD%2FXvy9u7ozdLY1UbAb76FpYUw%3D&reserved=0>



_______________________________________________

mpls mailing list

mpls@ietf.org<mailto:mpls@ietf.org>

https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls