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

All,

I think that Tony and Adrian said most of what needs to be said.

I understand that using an opcode from the "Private Use" range will work.

Adrian ask "why this wouldn’t use a stable and predictable Opcode".

I have a little teak on that question, what are the positive effect by 
using an opcode from the private use range, doesn't it just increase the 
configuration activities needed by operators?

I guess I'd be comfortable with the MPLS WG recommending the SPRING WG 
to use an opcode from the IETF REVIEW range.

/Loa

Den 2026-08-19 kl. 22:36, skrev Adrian Farrel:
> 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 <mpls- 
> [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/
>     <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)
> 
> 
> _______________________________________________
> mpls mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

-- 
Loa Andersson
Retired
[email protected]
[email protected]

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