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

Hi,

 

Not sure whether my chair hat is on or off.

 

Thanks, Alvaro, for raising this. 

 

I read the draft and I can’t see any explanation of why this wouldn’t use a stable and predictable Opcode. To me that seems very odd, while 8126 describes Private Use quite a bit differently.

 

It is possible that I have missed something, but is the Scope field being used to indicate what return path to use (SR-MPLS vs IP/UDP)? That seems to me to be somewhat overloading the field.

 

Cheers,

Adrian

 

From: Tony Li <[email protected]> On Behalf Of Tony Li
Sent: 19 August 2026 16:50
To: Alvaro Retana <[email protected]>
Cc: IETF MPLS List <[email protected]>; MPLS Working Chairs <[email protected]>; spring-chairs <[email protected]>; [email protected]; [email protected]
Subject: [mpls] Re: Private MNA definition (draft-ietf-spring-stamp-srpm-mpls)

 

[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 <[email protected] <mailto:[email protected]> > 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)

_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]