Thank you Adrian, Tony and Loa for the feedbacks. We proceed with the standard opcodes + definitions.
Thanks, Rakesh From: Loa Andersson <[email protected]> Date: Friday, August 21, 2026 at 6:04 AM To: [email protected] <[email protected]>; 'Alvaro Retana' <[email protected]> Cc: 'IETF MPLS List' <[email protected]>; 'MPLS Working Chairs' <[email protected]>; 'spring-chairs' <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [mpls] Re: Private MNA definition (draft-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]
