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

[Vishnu Pavan Beeram <[e-mail]>]

Greg,

Would adding the following text in draft-ietf-mpls-mna-nrp-selector address
your concern?
**
An NRP-capable node MUST drop a packet by default if the encoded NRPS
cannot be mapped to a known NRP. This requirement MAY be overridden by an
operator-specified policy, the specification of which is outside the scope
of this document.
**

Regards,
-Pavan

On Mon, Dec 22, 2025 at 5:38 PM Greg Mirsky <[e-mail]> wrote:

> Hi Tony and Pavan,
> thank you for the detailed explanation. I might have misunderstood the
> conclusion of the discussion
> <https://mailarchive.ietf.org/arch/msg/teas/hpvVY_De48SyMWVQ3YItEUSS-HA/> in
> the TEAS WG, in part related to the “Strict” match indicator in the TEAS
> WG. As I understood the Chairs' note:
>
> [Chairs] We received four responses supporting the "strict match indicator"
> encoding in the data packet. Two responses said this is unnecessary because
> it should always be a "Strict Match" (the operator can configure local
> policy to override this if needed). We believe that "strict match" is the
> default option and that having a local policy to override this behavior
> would cover most operational scenarios.
> However, encoding the "strict match indicator" in the data packet provides
> more granular control and can be deemed a "nice-to-have" feature. We don't
> see a strong reason not to allow this. The actual encoding of this
> “indicator” could differ for different data plane types and must be
> discussed in the respective WGs (outside the scope of TEAS).
>
> "strict match indicator": if a behavior other than the strict match is
> supported, it is expected to be part of the signaling NRPS in a data
> packet. As I noted during the TEAS WG discussion and earlier in this
> thread, I firmly believe that only the strict match policy is needed.
> Without revisiting the TEAS WG decision, the MPLS WG document can
> explicitly state that only the strict mode is allowed (unless I missed it
> in the current draft).
>
> Regards,
> Greg
>
> On Mon, Dec 22, 2025 at 5:08 PM Vishnu Pavan Beeram <[e-mail]>
> wrote:
>
>> Greg,
>>
>> For an NRP-capable node to map the NRPS to a known NRP, there must be a
>> corresponding NRP policy available on the node that specifies the
>> forwarding treatment to apply to matching packets. This NRP policy is
>> expected to be consistent across the NRP domain.
>>
>> In a similar vein, for unknown NRPs, if the desire is to override the
>> default "drop" action, the expectation is that the operator will configure
>> a consistent operator-specified policy on NRP-capable nodes. No
>> control-plane extensions are required for this.
>>
>> Regards,
>> -Pavan
>>
>> On Mon, Dec 22, 2025 at 3:08 PM Greg Mirsky <[e-mail]>
>> wrote:
>>
>>> Hi Pavan,
>>> thank you for your expedient response. If I understand correctly, the
>>> authors believe that NRPS encoding in MPLS doesn't require the Strict mode
>>> indicator. If that is the case then how an operator ensures consistency of
>>> NRPS handling in that regard? Through a combination of OAM and control
>>> plane extensions? It seems like some text in the draft on that matter could
>>> be helpful.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Mon, Dec 22, 2025 at 2:07 PM Vishnu Pavan Beeram <
>>> [e-mail]> wrote:
>>>
>>>> Greg,
>>>>
>>>> Thanks for bringing this up.
>>>>
>>>> When the authors discussed this earlier, we concluded that an
>>>> NRP-capable node MUST drop a packet if the encoded NRPS cannot be mapped to
>>>> a known NRP. This requirement can be overridden by a local policy, the
>>>> specification of which is outside the scope of this document.
>>>>
>>>> Apologies for not discussing this on the list earlier in the WG process.
>>>>
>>>> Regards,
>>>> -Pavan (on behalf of the authors)
>>>>
>>>> On Mon, Dec 22, 2025 at 12:00 PM Greg Mirsky <[e-mail]>
>>>> wrote:
>>>>
>>>>> 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]
>>>>>>
>>>>> _______________________________________________
>>>>> mpls mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>