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

[John Drake <[e-mail]>]

 Gyan,
As Tony pointed out, the MPLS WG does not have implementation or interoperability requirements to progress a draft.  This includes both the original MPLS work and the subsequent GMPLS work.
John

    On Sunday, September 29, 2024 at 08:23:20 PM PDT, Gyan Mishra <[e-mail]> wrote:  
 
 
Dear Chairs & WG 
To clarify my position on PSD work is that the work should be completed meaning at a minimum implemented by two vendors for interoperability and at WGLC state.  The MNA header draft now in WGLC could then be progressed including PSD solution.
Thank you 
Gyan






On Sun, Sep 29, 2024 at 3:33 AM Gyan Mishra <[e-mail]> wrote:


Dear Chairs & WG
I agree with points raised by  Zafar, Jimmy, Tianran, Loe and other WG members that this is a hardware implementation that is standards track and that said must have a minimum two interoperable implementations.
I support both ISD and PSD.
There has been a lot of discussions on ML about both and I think both should be included in this draft as they are in the MNA framework architecture draft section 3.6.
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-fwk-10#name-encoding-of-post-stack-data
I agree the PSD work should be completed before we move forward with progressing this document.
This was from “IOAM and PSD” discussion this past summer:
>From Michel Menth 8/3/23 below - presented some results at an interim meeting before:

https://datatracker.ietf.org/meeting/interim-2024-mpls-01/session/mpls


IOAM requires mutable data. In combination with multiple labels, e.g., for SR, these mutable data need to be near the bottom of the stack, otherwise they get popped along the way. Moving them to PSD makes encoding more efficient without increasing the effective header length that needs  to be parsed. Therefore, we think PSD is the better option for applications like IOAM.
This draft is not ready for progression at this time.
Kind Regards 




Gyan Mishra

Network Solutions Architect 

Email [e-mail]


M 301 502-1347





On Sun, Sep 29, 2024 at 1:24 AM Zafar Ali (zali) <zali=[e-mail]> wrote:


Dear chairs and the WG, 

 

I agree with points raised by Jimmy, Tianran, Loe and others.

 

This is hardware implementation.

The ask is to progress the document as a standards track RFC.

Having at least two interoperable implementations by vendors should be a bare minimum bar.

 

Support for PSD is part of the MNA architecture.

There was a rather encrypted WG poll on PSD interest which shows clear support from vendors and operators to work on the PSD option.

However, the working group has not heard any outcome of the poll.

The PSD draft remains an individual draft.

 

Let’s first have the working group complete the work on PSD and all the pieces.

The document is not ready for progression as a standards track RFC at this point in time. 

 

Thanks

 

Regards … Zafar

 

From:Tianran Zhou <zhoutianran=[e-mail]>
Date: Thursday, September 26, 2024 at 7:48 PM
To: Dongjie (Jimmy) <jie.dong=[e-mail]>, Tarek Saad <[e-mail]>, [e-mail] <[e-mail]>
Cc: MPLS Working Chairs <[e-mail]>, [e-mail] <[e-mail]>
Subject: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)

Hi Tarek and WG,

 

I do not support the publication of this draft.

I agree with Jimmy there are serious concerns about ISD implementation and performance.

I believe ISD is not the right approach for MNA, we will not implement it.

I need a knob in existing MNA hdr to disable ISD and enable PSD.

 

Best,

Tianran

 

From: Dongjie (Jimmy) [mailto:jie.dong=[e-mail]]
Sent: Friday, September 27, 2024 12:28 AM
To: Tarek Saad <[e-mail]>; [e-mail]
Cc: MPLS Working Chairs <[e-mail]>; [e-mail]
Subject: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)

 

Hi Tarek,

 

Before the 1st WG LC, some implementation experience with the -04 version of this draft was presented on an interim meeting:https://datatracker.ietf.org/meeting/interim-2024-mpls-01/session/mpls. That implementation was from Academia.

 

As shown in the meeting materials, the implementors met some challenges with the encodings in -04 version, they asked some questions and also gave some proposals for possible optimization. As part of the WG LC, it would be important to check whether the issues raised at that time have be addressed by the latest version. It would be helpful if some feedback on the latest version can be provided by those implementors.

 

At IETF 120 I asked one question about the implementation report. Are we aware of any other implementation of this document, besides the implementation of the -04 version from Academia? This would be important to gauge the maturity of the document and the interest in implementing it.

 

Best regards,

Jie

 

From: Tarek Saad <[e-mail]>
Sent: Tuesday, September 24, 2024 9:25 PM
To: [e-mail]
Cc: MPLS Working Chairs <[e-mail]>;[e-mail]
Subject: [mpls] Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)

 

Dear WG,

 

This email starts a two-week Working Group last call fordraft-ietf-mpls-mna-hdr. This is the 2nd WG last call for this document.

Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version, and it is ready for publication in your opinion. As always, review comments and nits are most welcome.

 

Please send your comments to the mpls WG mailing list ([e-mail])

If necessary, comments may be sent unidirectional to the WG chairs.

 

Note, currently there are 5 IPR disclosures against this document athttps://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-mna-hdr

 

This poll runs until October 8, 2024.

 

Thank you,

Tarek (for the MPLS WG co-chairs)
_______________________________________________
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]