[Teas] Re: Revisiting NRP Selector

[Ketan Talaulikar <[e-mail]>]

Hi Pavan,

Please check inline below.


On Wed, Jan 22, 2025 at 1:52 AM Vishnu Pavan Beeram <[e-mail]>
wrote:

> The chairs would like to draw a consensus based on the responses to the
> questions posed in this thread. Thanks to everyone who sent in their
> responses. We will leave this thread open till Jan 27th to see if there are
> more responses.
>
> We had a couple of opinions expressed at the mike during the last TEAS WG
> session on this topic (
> https://datatracker.ietf.org/doc/minutes-121-teas/#08-1410-10-min-title-realizing-network-slices-in-ipmpls-networks)
> Please do bring that discussion to the list.
>
> Regards,
> -Pavan and Oscar
>
> 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.
>>
>>
KT> I prefer "NRP Selector ID". This comes from
https://www.ietf.org/archive/id/draft-ietf-teas-ns-ip-mpls-04.html#section-5.1.1
where
NRP Selector is defined and then we said that we need a new specific
purpose ID in the packet and so perhaps we call it NRP Selector ID.


>
>>    - Length of the dedicated identifier field
>>       - Is it okay for this to be different for different data-plane
>>       types?
>>
>>
KT> Yes


>
>>    - 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.
>>
>>
KT> The point was that an NRP which goes across domains with different data
planes - e.g., SRv6 and MPLS. Having a consistent NRP Selector ID just
makes things simpler without the need for mapping between these domains.
Now, a NRP Selector ID that is 8-bit size will fit into a field that is
32-bit size - so this becomes more of an operational/deployment option that
I really want us to retain for simplicity of deployment. Based on all the
feedback that I've received from multiple operators and colleagues from
across vendors, most do not foresee the number of NRPs that exceed 8-bit
space. So, why not keep a 8-bit consistent size as an option in the various
data planes - specifically MPLS (MNA) and SRv6 to start with? Especially,
if it is easily possible to extend if/when the need truly arises.


>
>>    - “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
>>
>>
KT> I believe it should always be a strict match check. The raison d'etre
for NRP is to guarantee dedicated network resources partitioning. If the
routing is not ensuring that forwarding of designated service flows is
within that NRP OR if there is an issue in provisioning of the NRP
(something is missed), then that seems like an error condition to me. Now,
it is entirely possible that implementations want to provide policy/config
knobs for fallback in some deployments, but I am not sure if we want this
as an indication to be carried per-packet. The "fallback" could also be
done at the slice or the service level?


>
>>    - 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).
>>
>>
KT> Agree. However, I believe the TEAS WG should cover the requirement and
functional aspects in our documents based on which the other WGs can design
the actual encodings.

Thanks,
Ketan


>
>>
>> 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]
>