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]
