Many thanks Alvaro for the update. The latest rev-06 covers the requested updates related to operator-defined value and encoding parameters.
Thanks, Rakesh (for authors) On Tue, Aug 18, 2026 at 12:31 PM Alvaro Retana <[email protected]> wrote: > On August 16, 2026 at 6:44:22 PM, Rakesh Gandhi wrote: > > Rakesh: > > Hi! > > > We have updated the security and operational considerations in the posted > > rev-5 that address your comments listed below. > > Thanks for that. > > See more below. > > > ... > > > > > 2- In section 7.1, a new network action (MNA.TSF) is defined. The > > > > > spring WG is not chartered to define extensions. Aside from the > > > > > definition, its use is unclear because you say it falls within the > > > > > private use range in the registry. In other words, it is not > > > > > registered. Some interoperability-related questions come up: How > does a > > > > > sender determine whether a reflector supports it? Is it actually > > > > > interoperable, or locally configured? > > > > > > > > Right, the Network action opcode and semantics are locally > configured and > > > > not signalled or registered. > > > > > > This is the part I'm not so sure about. If the network action's opcode/ > > > semantics are only locally configured and not signaled or registered, > then > > > a sender has no standard way to know if a reflector supports it -- > that's > > > not really interoperable, and defining it is outside what the WG is > > > chartered to do. At minimum, I would want to see stronger/detailed > > > Operational Considerations around this configuration, failure modes, > etc.. > > We (Chairs) have been talking about this. > > (1) > > §8/rfc9994 is ok with locally defined/private MNAs, which can be manually > configured in the nodes that need its support. > > §10/rfc9994 mentions several things that a "new network action MUST > specify": LSE format, scope, etc. My interpretation is that even a > private-use MNA needs to satisfy this requirement (if we want the sender > and reflector to interoperate). Some of these (scope, for example) are > mentioned in §7.1 for MNA.TSF, but not all. > > > (2) > > Then there's the use of the Private Use Range (from §7.1.1): > > The new locally configured MPLS Network Action opcode MNA.TSF, called > the TSF Network Action and described in this document, has the > following properties and is assigned a value from the "Private Use > Range: 115-126" [RFC9994] on the Session-Reflector node. > > This document doesn't request an assignment (it can't!), but mentioning > the Private Use Range gives the impression that we're standardizing its > use...when in reality you’re proposing that the operator select a value > locally. Right? > > If so, we need you to change the language from "use a value from the > private-use range in the registry" to "use an operator selected value" to > make it clear that there is no specific assignment. > > [Regardless of the Operational Considerations, having an operator-selected > code increases the possibility of something not working...] > > > > Putting that together: standard definition of MNA.TSF + an > operator-selected code... The result seems to be allowed by rfc9994; we > would end up with a standardized definition of a locally assigned MNA. We > will consult the MPLS WG explicitly (after the draft is updated as > suggested above). > > One more thing: the document would be defining an extension (MNA.TSF), > which is something spring is not chartered for. Assuming that the framing > ("standardized definition of a locally assigned MNA") is ok with the MPLS > WG, and given that its use is constrained to SR-MPLS, we may be able to > work something out (process-wise) with the mpls-chairs and AD. > > Thanks! > > Alvaro. > >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
