[mpls] Re: 答复: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)

["[e-mail]" <[e-mail]>]

When you were pushing for a PSD solution, you blithely ignored items 1 and 2, and I am not inclined to believe that item 3 is relevant, because all that is being proposed by the opponents of the subject draft is an existence proof of feasibility 

Sent from my iPhone

On Oct 14, 2024, at 1:36 PM, Haoyu Song <[e-mail]> wrote:



I’d like to share my thoughts on the P4 evaluation. The P4 evaluation only shows the feasibility of the header parsing part without considering the efficiency and the action execution. There are several issues:

1. The actual action execution could have deeper performance implications than the heard parsing. An overall evaluation is needed, especially when one of the MNA design principles is to allow upgrading the old in-field devices.
2. The parser needs to support all the other normal packet header parsing functions as well, so the parsing efficiency needs to be considered. It can’t consume most of the resources without leaving enough for the others.
3. P4-based programmable switches are discontinued and we can hardly claim it as golden standard. We need evaluations on other types of platforms to gain the confidence to encourage adoption and deployment.

 

Best regards,

Haoyu

 

From: John Drake <[e-mail]>
Sent: Monday, October 14, 2024 6:52 AM
To: Loa Andersson <[e-mail]>; Greg Mirsky <[e-mail]>
Cc: [e-mail]; MPLS Working Chairs <[e-mail]>; [e-mail]
Subject: Re: [mpls] Re: 答复: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)

 

Snipped, comment inline.

 

On Sunday, October 13, 2024 at 11:10:32 AM PDT, Greg Mirsky <[e-mail]> wrote:

 

 

Hi Loa,

I read your thoughts on the discussion with great interest, thank you for sharing. I've added my notes below tagged GIM>>.

 

Regards,

Greg

 

On Sat, Oct 12, 2024 at 11:49 AM Loa Andersson <[e-mail]> wrote:

I agree that it is important to take the input we can get from
implementations. I'm quite surprised by the perceived resistance for the
WG chair that has spoken up on this. Taking the lessons we can from
existing implementations has been there for MPLS Standard Track RFCs,
since the start.

GIM>> I am surprised that you discard all the great work and valuable information the group received from Michael Menth and Fabiam Ihle on their outstanding work with implementing MNA on the P4 platform. As I understand it, they don't find any severe obstacles to implementing the MNA ISD solution based on the current version of the draft.

I agree that input from implementations is important but, as I understand it, the MPLS WG never before required that to progress any document. I believe that if the WG is transforming into an MPLS maintenance group, then adopting a more protective charter which would require validation by an implementation seems reasonable to me. Otherwise, I cannot find any practical reason in further stalling the progress of the MNA ISD document. 

 

JD:  It is also the case that during the MNA Design Team meetings, members expressed the opinion that P4 implementations were the gold standard.

 

_____________________________________

However we have never wanted to make it a formal criteria, since we very
quickly learnt that vendors are extremely reluctant to respond to
implementation polls-

GIM>> So how is the case on MNA different? It is optional and, in my opinion, is no different from any other MPLS extensions that use SPL.

 

JD:  It shouldn't be, and I haven't heard any arguments for why it should be.

.

>
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]

_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

__________mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]