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

Stewart Bryant <stewart.bryant@gmail.com> Wed, 22 February 2023 18:10 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AE8C151538; Wed, 22 Feb 2023 10:10:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.995
X-Spam-Level:
X-Spam-Status: No, score=-1.995 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vtlZ6yieDaws; Wed, 22 Feb 2023 10:10:28 -0800 (PST)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE36C14CE46; Wed, 22 Feb 2023 10:10:28 -0800 (PST)
Received: by mail-wm1-x32a.google.com with SMTP id j19-20020a05600c1c1300b003e9b564fae9so1322635wms.2; Wed, 22 Feb 2023 10:10:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=XT0RHOPl7Zqd70wWbUekM0gK7ELlVBH5XV/N7PqCKdM=; b=ZcYnNSjD4c5A7m7+sWAaVpK2WLKMLIXal+xVyGKAOkuGpCInstIKJfiyuEuXtpSUt+ sIBUnQgmefH7CGJv1wv1zjdwqPDGgGJJ6WbujVsRAV0DwPavIUqOk1WwrvQUb2Yn26B4 VWQMpR+0l5+5tdWC2vjuMKNZf8NMAZatBtoFl22aQGp75jkrrPC98DfGpMzsVAazl6AE Xb3eyTSq0uWgWUd9Kuh0yG4hMHWCJGwHWWI93mXz0Q79bdHWwGRITGeJLSVomAlV7Pqf cRTjYVA3jwG2Z0mRK2V8bYxUGIF3BMBrXPUdK3+lNv67X4KlcPhX3/4z8ascBmyLQMKR NW4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XT0RHOPl7Zqd70wWbUekM0gK7ELlVBH5XV/N7PqCKdM=; b=gz5An0okqAJyYJmxqnV3Wgffi1YpbzlYU2pHjWglzbURF9/UHrZvj9m7FtoEB1J4Ud QGHe+7C4J4fO3EoVsh6SW1CP70iDsCMq1u/kKGLaFTi2MC20ykU86AcJ+yNrirf1mJ9M YLVU83/AhRrUv8HCM3uadvCgs1adiWMxrziXgCEQvht5vULOqGzGBTD/G7PJiyjGEFw0 5tGPb1wxcbPM9dnlFyExvCApXLFGbJif+COKH68q78TemxI+XvsrJC69yf4RgQKXDN8A 52QO9qSeQHSE75CelaI2dyt0Hobr5EvkteEpbdCzWfspBfXXAIirEEHv23t34w2uerqa UcYw==
X-Gm-Message-State: AO0yUKUj62K9pM5RwUl+oX/Hb4AYDLvP22VXA8ySwvZ4fyDTHYM2Vrjm L9n8W2KoO6WthztYF9ayz1s=
X-Google-Smtp-Source: AK7set8VvhaKNKdLPWVqUX0VZqs1SmkRtjJmIqFYWh+AlApCRPpegXgyB7v1EZ60W3pi/PWlbzX1Qg==
X-Received: by 2002:a05:600c:1713:b0:3db:331b:bd57 with SMTP id c19-20020a05600c171300b003db331bbd57mr1745867wmn.23.1677089426790; Wed, 22 Feb 2023 10:10:26 -0800 (PST)
Received: from smtpclient.apple ([148.252.133.160]) by smtp.gmail.com with ESMTPSA id c15-20020adfef4f000000b002c54c9bd71fsm5932029wrp.93.2023.02.22.10.10.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2023 10:10:26 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <BDD01448-D355-40E0-9A33-4EA797605874@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F2201781-A3EC-4B38-896D-A90CF672F73D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Wed, 22 Feb 2023 18:10:12 +0000
In-Reply-To: <CA+RyBmUQWPgTOeTXCaXYNLRebTg6UQ8-QJoevrsRGFctiv32mQ@mail.gmail.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Haoyu Song <haoyu.song@futurewei.com>, mpls <mpls@ietf.org>, MPLS Working Group <mpls-chairs@ietf.org>, "pals@ietf.org" <pals@ietf.org>, pals-chairs <pals-chairs@ietf.org>, DetNet WG <detnet@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
To: Greg Mirsky <gregimirsky@gmail.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> <CA+RyBmUQWPgTOeTXCaXYNLRebTg6UQ8-QJoevrsRGFctiv32mQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/VqYW2CMzag9zB5GAqDr2uwkOptw>
Subject: Re: [Detnet] [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2023 18:10:32 -0000

I could be persuaded that it is best to progress draft-jags or something similar first, but think that it would be unwise to do so in such way that there was not an obvious path to introduce PSD.

Stewart 

> On 22 Feb 2023, at 00:37, Greg Mirsky <gregimirsky@gmail.com> wrote:
> 
> Hi Haoyu,
> I don't think that using terms properly is a "word game".
> Consensus of a IETF community is the cornerstone of the IETF process, as I understand RFC 2026. And there are mechanisms that help to determine whether the community has reached the consensus on this or that subject of discussion.
> Below are my notes on the situation:
> I still have concerns about the complexity of the proposed MNA solution. 
> I don't see a strong interdependency between draft-jags and draft-song, and agree with the idea, mentioned in the course of this discussion, to progress draft-jags independently as a sole ISD MNA solution. I think that that can be done by removing references to PSD solution and leaving all provisional PSD-related constructs as reserved for future solution (if need to be). 
> I've read draft-jags with that idea in mind, and the resulting specification appears to me leaner and simpler.
> 
> Regards,
> Greg
> 
> On Tue, Feb 21, 2023 at 4:19 PM Haoyu Song <haoyu.song@futurewei.com <mailto:haoyu.song@futurewei.com>> 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
> https://www.ietf.org/mailman/listinfo/mpls