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

[James Guichard <[e-mail]>]

Dear authors/WG/chairs,

As the responsible AD I would like to clarify that aside from an unrelated DISCUSS during IESG evaluation, this document has been approved by the IESG for publication. While the text in question is somewhat unusual, it is my understanding that it was discussed at length in the WG, and a fair compromise was reached by including text that makes the intent of the WG clear with regards to publication of the document. From a procedural standpoint the MNA solution document must make its way through the standard publication process, and if it is eventually published as an RFC then this document will be moved to Historic.

I would like to suggest a slight change to the text as follows:

Note that in parallel to the work of this document, there is ongoing work on MPLS Network Actions (MNA) [RFC9613]. The MPLS performance measurement with the Alternate-Marking method can also be achieved by MNA encapsulation. In addition, MNA will provide a broader use case applicability. That means the MNA encapsulation is expected to provide a more advanced solution, when published as an RFC and it is agreed that this document will be made Historic at that time.

Thanks!

Jim
From: Tony Li <[e-mail]> on behalf of Tony Li <[e-mail]>
Date: Tuesday, September 10, 2024 at 9:44 AM
To: Stewart Bryant <[e-mail]>
Cc: xiao. min2 <[e-mail]>, draft-ietf-mpls-inband-pm-encapsulation <[e-mail]>, [e-mail] <[e-mail]>, mpls <[e-mail]>, mpls-chairs <[e-mail]>, The IESG <[e-mail]>
Subject: Re: [mpls] John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)

Hi Stewart,


> I am not sure I understand the need to say anything about anticipated obsolescence of the protocol.
>
> Once it is released in the wild it will have a life of its own determined by the needs of the operators. If they want to keep using it they will and we should not prevent them. As a method it is harmless and by using an ESPL it does not take any critical resources.
>
> It is very rare that we actively obsolete anything like this unless it is actually harmful, or blocks some other more valuable method, neither of which apply here.
>
> So why are we actively promoting the obsolescence of this technique rather than letting the market decide which is our normal approach?


Because the WG is potentially generating two approaches to doing the same function in a relatively short time. Many concerns were expressed about the confusion that it would create. Some wanted this document to not be published. The authors of this draft very much wanted it to be published (as PS) because of their existing deployments. This compromise was the way of respecting all parties.

I’ve heard compromises described as deals where everyone walks away unhappy.  If we want the IETF to be a place where compromise and statesmanship are the norm, then we have to accept the fact that compromise will lead to outcomes that we don’t care for. The alternative is that every topic polarizes us, we sit and argue endlessly, and no progress is made.

T