[mpls] Regarding IPRs in adopting mna solution documents

Hi Tom,

I changed the subject which I think should be better.
The IPR disclosure with the same term applies to both MNA solution drafts, draft-jags-mpls-mna-hdr and draft-song-mpls-extension-header. 
I just think we should consider both drafts, not only one.

Cheers,
Tianran
-----Original Message-----
From: tom petch [mailto:ietfc@btconnect.com] 
Sent: Wednesday, February 22, 2023 6:25 PM
To: Tianran Zhou <zhoutianran@huawei.com>; Tony Li <tony.li@tony.li>; Haoyu Song <haoyu.song@futurewei.com>
Cc: mpls@ietf.org
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

From: mpls <mpls-bounces@ietf.org> on behalf of Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>
Sent: 22 February 2023 07:21

I do not think the combination of IPR and technique discussion is reasonable. I hope we can divide and conquer.

<tp>
Agreed so I was going to change the subject but then this is still about adoption so what do I change it to?

Technically this is at the periphery of my understanding but IPR I have been involved with for decades and that has not changed much,  I share the view of Tony that the IPR claim makes this unsuitable for the WG to work on.

A similar situation arose in the Security Area and when it was pointed out to the (different) organisation  the terms used by e.g. Cisco, which were widely accepted, then the organisation changed the terms of its IPR Claim

Tom Petch

On one hand,
It's OK if the working group get the consensus that PSD is not necessary.
I believe the community can find the best way for us all to implement all the use cases. The complexity is surely very important.

On the other hand,
I noticed Stewart indicated an IPR wrt draft-jags-mpls-mna-hdr:
https://mailarchive.ietf.org/arch/msg/mpls/TX2y7soChCCSfUPCxttg7MtHOb4
I will ask the IPR engineer to check.

Best,
Tianran

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tony Li
Sent: Wednesday, February 22, 2023 3:24 AM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: mpls@ietf.org
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

Hi Haoyu,

The situation has changed. The IPR licensing terms warrant further consideration by the working group, IMHO. You're welcome to think it is unwise. I think it is a necessity.

Tony

> On Feb 21, 2023, at 11:19 AM, Haoyu Song <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> On Behalf Of Tony Li
> Sent: Tuesday, February 21, 2023 10:59 AM
> To: Haoyu Song <haoyu.song@futurewei.com>
> Cc: Joel Halpern <jmh@joelhalpern.com>; 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
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls