[mpls] Re: Private MNA definition (draft-ietf-spring-stamp-srpm-mpls)

[Tony Li <[e-mail]>]

[WG chair hat: off]

Hi Alvaro,

No, this is not as intended.  If the semantics are standard, then the opcode should also be standard.

The approach that you are taking will yield sub-optimal results in the market, where implementations will have to have additional knobs so that each operator can configure their local opcode value.

What is the point of the IETF as a standards body if you are not going to standardize things???

Regards,
Tony


> On Aug 19, 2026, at 2:40 AM, Alvaro Retana - aretana.ietf at gmail.com <[e-mail]> wrote:
> 
> Dear mpls WG/Chairs:
> 
> I'm writing about draft-ietf-spring-stamp-srpm-mpls, which is close to WGLC in spring.
> 
> https://datatracker.ietf.org/doc/draft-ietf-spring-stamp-srpm-mpls/ 
> 
> The document defines a new MPLS Network Action, MNA.TSF ("Timestamp and Forward"), used for a loopback measurement mode with STAMP over SR-MPLS (see Section 7). Its opcode is operator-selected (not a registered/signaled value) — so the draft standardizes the definition of MNA.TSF while leaving the code point to local configuration.
> 
> That combination — a standardized definition of a locally assigned MNA — isn't something we've seen before.
> 
> Before we go further, we'd like the MPLS WG's read on:
> 
> (1) Whether this "standard definition + operator-selected opcode" pattern is consistent with how rfc9994 intended private-use MNAs to work.
> 
> (2) Whether the MPLS WG has any concerns with a document outside this WG defining an MNA this way. Note that the use is constrained to SR-MPLS.
> 
> 
> Thanks!
> 
> Alvaro (for the spring-chairs)