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]
