[mpls] Re: John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)

[Greg Mirsky <[e-mail]>]

Hi,
I am following the discussion, and I need a clarification. Does the latest
proposal to remove the WG agreement to move this specification to Historic
ones draft-cx-mpls-mna-inband-pm
<https://datatracker.ietf.org/doc/draft-cx-mpls-mna-inband-pm/> approved
for publication or actually is published? Otherwise, we enable two
solutions that address the same case as it appears. Multiple solutions, as
been demonstrated before, usually increase complexity and cost to a
customer. Although the MNA-based solution is yet to be considered for WG
adoption, I think that is a better approach to supporting the Alternate
Marking in addition to the existing RFC 8957
<https://datatracker.ietf.org/doc/rfc8957/> Synonymous Flow Label
Framework. In my opinion, if the WG agreement on moving this specification
to Historic when the condition is appropriate is removed, then it would be
reasonable for the WG to re-evaluate the agreement to publish this document
as a Standard.

Regards,
Greg

On Sun, Sep 8, 2024 at 7:37 PM Tony Li <[e-mail]> wrote:

>
> Hi Deborah,
>
> Please see inline.
>
> I’d suggest it would be more helpful if this sentence troubling Eric would
> clarify operationally why MNA will be a better solution (to provide a hint
> to vendors/operators of a new capability under development) and not simply
> say MNA can do the same thing.  And not say there is agreement on Historic
> when no one knows what will be decided.
>
>
>
> We are trying to make that decision now. We would like to not have to have
> the same round of discussions again in the future.  This is the compromise
> between the authors and the WG. It respects the existing implementors and
> implementations who very much would like to see their work published as a
> Proposed Standard now and leaves the door open for the subsequent MNA
> approach to supersede it without unnecessary recapitulation.
>
>
> Suggest:
> can also be achieved by MNA encapsulation, it is agreed .will be made
> Historic/s/can also be achieved by MNA encapsulation and, in addition, MNA
> will provide a broader use case applicability. The MNA encapsulation will
> provide an alternative, more advanced solution, when published as an RFC.
> [XM]>>> The text you suggested looks good to me. As an editor of this
> document, I'll let the ADs and MPLS WG chairs to comment before using your
> text in the next revision.
>
>
>
> I’m not sure I can precisely follow the notation that you’ve used, but I
> understand your intent and have no issue with it.
>
> Tony
> MPLS co-chair
> Document shepherd
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>