[Teas] Re: Revisiting NRP Selector

["Dongjie (Jimmy)" <[e-mail]>]

Hi Ketan,

Thanks for sharing your opinion on this thread, please see some comments inline with [Jie]:



发件人：Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
收件人：Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>
抄 送：TEAS WG <[e-mail]<mailto:[e-mail]>>;TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
时 间：2025-01-30 01:09:29
主 题：[Teas] Re: Revisiting NRP Selector

Hi Pavan,

Please check inline below.


On Wed, Jan 22, 2025 at 1:52 AM Vishnu Pavan Beeram <[e-mail]<mailto:[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]<mailto:[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.

[Jie] draft-ietf-teas-ns-ip-mpls-04 introduces the term NRP Selector as a general concept for different ways of implementing NRP identification in data packet, including both overloading existing identifiers and introducing dedicated identifiers. Please refer to section 5.1.1 for some details of NRP selector implementation options. My concern with the term "NRP Selector ID" is that it covers multiple approaches discussed in the ns-ip-mpls draft (both overloaded id and dedicated id), while what we want here is a term only for the "dedicated id" approach.

[Jie] On the other hand,  the term NRP ID has been used for NRP identification in the management plane and control plane. By adding "data plane" as a determiner to "NRP ID", its usage can be extended to the data plane naturally.

[Jie] That said, I am not a big fan of nitpicking on the terms. As long as the WG can reach some comsensus, I will be OK with it.



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

KT> Yes

[Jie] Agree and it is reasonable to allow different ID length for different encodings.



     *   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 goesp 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.

[Jie] I fully understand your point on the ID mapping between different domains, and I agree some approach for carrying/mapping a small-sized ID into a large-sized ID is needed as deloyment considerations. We have this kind of mapping in existing scenarios, such as IPv4 to IPv6 address mapping.

[Jie] I understand the needed number of NRP in some early deployments may be relatively small, while in protocol design we always consider scalability for future needs. Another thing we may need to consider is the scope of the NRP. It may be used within a local domain (e.g. for MPLS), or it may have visibility across multiple domains (e.g. for IPv6). Thus my suggestion is IPv6 itself may need larger-sized ID, and it can accomodate the smaller-sized ID for mapping and interworking.



  *   “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?

[Jie] I agree with you that theoratically the NRP match should be strict, while in some cases the customer of an NRP may prefer better availabilty for some services when there is no matching of NRP resources so that the service can fallback to best effort forwarding. Actually in past discussion some people said they want "fallback" as the default behavior. It shows different match policy is required, and it can be at different granularities. The complexity to achieve the same with configuration has been shown with examples.


     *   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.

[Jie] Agreed. TEAS should give general design guidlines and leave the encoding details to the relevant WGs.

Best regards,
Jie

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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>