[Teas] Re: Revisiting NRP Selector

[Gyan Mishra <[e-mail]>]

Hi Pavan & Teas WG

I think we should call the dedicated identifier field “NRP Data Plane ID”.

The NRP Selector ID  is more like a classifier so the “ID” can  be dropped
and just call it NRP Selector.  I agree with having flexibility of
overloading existing fields or having dedicated field  and the overloading
as a good short term choice makes sense and dedicated field for long term.

I agree the actual data plane encodings and length of the dedicated
identifier should be handled by respective WG.

I agree there has been discussion of avoiding adding state to control plane
in LSR and IDR and that the same applies here in TEAS.

On the strict match indicator I agree with having an explicit indicator to
drop or map the packet that cannot be mapped to NRP.  Actual encoding of
strict match indicator should  be handled by respective WG.

Kind Regards

Gyan


On Wed, Oct 9, 2024 at 3: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.
>    - 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.
>       - “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).
>
>
>
> 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]
>