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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Greg,

Thanks for providing your opinions on this.

Please see replies inline:

From: Greg Mirsky [mailto:[e-mail]]
Sent: Wednesday, February 22, 2023 12:10 PM
To: Dongjie (Jimmy) <[e-mail]>
Cc: Haoyu Song <[e-mail]>; mpls <[e-mail]>; MPLS Working Group <[e-mail]>; [e-mail]; pals-chairs <[e-mail]>; DetNet WG <[e-mail]>; DetNet Chairs <[e-mail]>
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

Hi Jie,
thank you for pointing this out to me. I have some thoughts about that poll and this discussion:

  *   That poll, as I understood it at the time, was whether PSD part of MNA is needed. And I supported it in that context.
[Jie] Good to know you also support PSD being part of the MNA at that time.

  *   Now, I look at the proposed PSD in MNA solution, and I see that it makes overall MNA too complex.
[Jie] This is interesting. The PSD solution has been stable since the WG poll on the ISD and PSD, what makes you think it is PSD which makes the MNA too complex? What we could tell is people share their concern on the complexity of MNA, while there was no systematic analysis on what caused that complexity yet. Before such analysis is done, maybe it is hard to say where the complexity is, and how it could be mitigated.

  *   I then look at the MNA use cases documented in the WG document and cannot find one that cannot be addressed using ISD MNA.
[Jie] Someone could also say that all those use cases could be addressed using PSD☺ And do you consider the use cases where variable length data needs to be carried or added to the packet? IOAM is just one typical case in that category.
Anyway, the ISD vs PSD discussion has happened last year, I’m not sure whether the WG wants to reopen that discussion.

  *   I then come to conclusion that at this time there is no apparent need to standardize overly complex PSD solution.
  *   I think that it would be beneficial concentrate on improving the ISD MNA mechanism to progress it through IETF process.
  *   Because the ISD solution already has "hooks" for a PSD MNA, I imagine that it will be possible to integrate it if a better PSD MNA solution and/or if a use case which requires use of PSD  brought to the table.
[Jie] These are personal conclusions. As I just said, systematic analysis to the whole MNA solution is needed before attributing all the complexity to the PSD part.
Best regards,
Jie

And thank you for helping getting my thoughts together in the course of our discussion.

Regards,
Greg

On Tue, Feb 21, 2023 at 7:22 PM Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Please see my previous mail to Joel.

It was recorded as the result of MPLS WG poll, hence it is a WG consensus:

  “- The poll shows that there is a strong consensus support for this
   position.

   - There is also a fairly strong opinion that solutions that specify
   the use of ISD, should take special care to provide the motivation
   for the use of ISD.

  The authors of the framework document should make any necessary
  updates to the framework document. Other MNA documents should be
  updated accordingly.”

According to the WG consensus, a complete MNA solution would need include both ISD and PSD.

And in the January Open DT meeting which you also attended, many people indicated their support to poll draft-jags and draft-song together for adoption.

Best regards,
Jie

From: mpls [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Greg Mirsky
Sent: Wednesday, February 22, 2023 8:37 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: mpls <[e-mail]<mailto:[e-mail]>>; MPLS Working Group <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; pals-chairs <[e-mail]<mailto:[e-mail]>>; DetNet WG <[e-mail]<mailto:[e-mail]>>; DetNet Chairs <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 21, 2023 4:03 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>; MPLS Working Group <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; pals-chairs <[e-mail]<mailto:[e-mail]>>; DetNet WG <[e-mail]<mailto:[e-mail]>>; DetNet Chairs <[e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 21, 2023 11:38 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Greg, answers to your two questions: ODT, and the documents under adoption call.
Thanks,
Haoyu

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 21, 2023 11:29 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Tony Li
Sent: Tuesday, February 21, 2023 10:59 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Joel Halpern <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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>