[Teas] Re: Revisiting NRP Selector

[Greg Mirsky <[e-mail]>]

Hi Pavan,
thank you for summarazing the discussion and clear formulation of
questions. Please find my responses below tagged GIM.

Regards,
Greg

On Wed, Oct 9, 2024 at 12:45 PM Vishnu Pavan Beeram <[e-mail]>
wrote:

> We had a virtual interim meeting on May 29th 2024 to discuss the
> following NRP Selector specific items:
>
>    - Generic requirements and options for carrying NRP Selector in IP and
>    MPLS packets
>    - The relevant modeling aspects
>    - The data plane specific extensions that come into play when a
>    dedicated identifier is used as the NRP selector.
>
>
>
> The meeting minutes are captured at:
>
>    -
>    https://datatracker.ietf.org/meeting/interim-2024-teas-01/materials/minutes-interim-2024-teas-01-202405291400-00
>
>
>
> We (the chairs) are starting a thread to close on some of the items
> specific to having a dedicated identifier that is used as NRP selector
> (note that NRP selector refers to the marking in the packet’s network layer
> header that is used to associate the packet with an NRP).
>
>    - What do we call this dedicated identifier field?
>       - “NRP Selector ID” and “NRP Data Plane ID” have been proposed so
>       far.
>
> GIM>> The former, "NRP Selector ID", is clearer and preferrable.

>
>    - Length of the dedicated identifier field
>       - Is it okay for this to be different for different data-plane
>       types?
>       - A 32-bit field has been proposed for the IPv6 Data-Plane; A
>       couple of options – 8 bits and 13 bits – have been proposed for the MPLS
>       data plane
>          - Please note that the actual data-plane specific encodings are
>          outside the scope of the TEAS WG.
>
> GIM>> The idea that the length of the dedicated field can be different for
different data planes is pragmatic and reasonable. I would expected that
the interworking between domains with the different length of the dedicated
indicator field be addressed in respective WGs that define data plane-
specific encodings.

>
>    - “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).
>
> GIM>> I believe that the dedicated indicator must be used only on exact
match, i.e., "strict" match.

>
>
> Please chime in with your thoughts on these items.
>
> - Pavan and Oscar
>
> ps: @Jie – Thanks for the offline prod. Please feel free to add other open
> items specific to NRP selector (that we may have missed) to the above list.
> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>