[mpls] Re: Next steps with draft-ietf-mpls-mna-nrp-selector-last-call

[Greg Mirsky <[e-mail]>]

Hi Adrian, Authors et al.,
I read Adrian's summary and it seems like we omitted one of issues discussed
by TEAS WG
<https://mailarchive.ietf.org/arch/browse/teas/?gbt=1&index=08YBvm3ZQVe5GprFY263OtQj-zY>
:

“Strict” match indicator
When a dedicated identifier is used as the NRP Selector, is it useful to
have an explicit indicator to determine what to do with a packet that
cannot be mapped to an NRP?
Drop the packet vs Map it to a default set of network resources
The actual encoding of this “indicator” could be different for different
data-plane types and will need to be discussed in the respective WGs
(outside the scope of TEAS WG).

Personally, I think that a packet with an unknown NRPS must be dropped, and
that "default set of network resources" unnecessarily complicates things
potentially leading to complex to understand network behaviors. Unless I
missed it, I couldn't find the issue of unknown NRPS explicitly stated in
the document.
Apologies for bringing this up for the discussion at the 11th hour.

Regards,
Greg

On Mon, Dec 22, 2025 at 8:28 AM Adrian Farrel <[e-mail]> wrote:

> Dear working group,
>
> The discussions started during working group last call of our draft
> draft-ietf-mpls-mna-nrp-selector-last-call have rumbled on, but now
> seem to have gone quiet. Sadly, the discussions did not seem to come
> to any compromises or conclusions beyond the fixes that went into the
> -02 revision.
>
> It's my job as working group chair and document shepherd, to form a
> conclusion so that we can advance the document if possible. I have
> separated out the issues raised and indicated my conclusions. Some of
> the discussions have made links between the issues, but I think we can
> separate them out for clarity. While the consensus is rough on several
> of these points, I believe we can complete our work based on this.
>
> 1. How to handle multiple NRPS Opcodes present in the label stack.
>    Resolved with change in -02 : only the first found is processed.
>    NO FURTHER ACTION REQUIRED IN THIS DOCUMENT
>
> 2. How to handle in-stack and post-stack NRPS if both present.
>    This is a general problem, not restricted to NRPS.
>    This problem must be resolved in draft-ietf-mpls-mna-ps-hdr.
>    NO FURTHER ACTION REQUIRED IN THIS DOCUMENT
>
> 3. There is no purpose to multiple Opcodes except encoding efficiency.
>    The multiple Opcodes addresses the conflict between encoding
>    efficiency and the potential for large NRPSes.
>    While several voices offered opinions about the desirability of
>    different lengths of NRPS, the TEAS WG has not offered any
>    conclusions.
>    No evidence has been presented for the need for more than an 8 bit
>    NRPS, but it seen as important to allow support for up to 20 bits
>    should the implementation/deployment require it.
>    Facilitating optimal encoding in the label stack is important
>    according to RFC 9613.
>    NO FURTHER ACTION REQUIRED IN THIS DOCUMENT
>
> 4. Implementations not supporting all Opcodes may fail to interoperate.
>    Suggestion to make support of all Opcodes was opposed without
>    technical reasons.
>    This is a general problem across all Opcodes in all specifications.
>    The decision is either to mandate support of all the Opcodes or to
>    allow interop issues.
>    In the absence of consensus to add the suggested text...
>    NO FURTHER ACTION REQUIRED IN THIS DOCUMENT
>
> 5. Too many Opcodes is confusing or risks implementation stability.
>    While several requests to reduce the number of Opcodes have been
>    made, no strong argument was made as to how this would improve
>    implementations.
>    It was observed that two Opcodes (TBA1 and TBA2) could be combined
>    with the distinction being made by their positioning in Format B or
>    Format C LSEs, however this does not seem to significantly reduce
>    the implementation complexity.
>    NO FURTHER ACTION REQUIRED IN THIS DOCUMENT
>
> Therefore, I will complete the document write-up and ask the AD to
> advance the document.
>
> Regards,
> Adrian
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>