[Teas] Re: Revisiting NRP Selector

[Chongfeng Xie <[e-mail]>]

Hi Teas Chairs,

Below are my feedback to your questions,

What do we call this dedicated identifier field?  
“NRP Selector ID” and “NRP Data Plane ID” have been proposed so far.
[Chongfeng] I’d prefer to use “Data Plane NRP ID”. NRP Selector is the general term to refer to all the data plane mechanisms to select/identify the NRP a packet mapped to.
 
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. 
[Chongfeng] Considering that there are many differences in the encoding of different data plane, and their applicability could also be different, it is OK to have different length for this ID. And I agree specific encoding belongs to the respective WGs.
 
“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).
[Chongfeng] As an operator I see the strict match indicator very useful and can avoid complex configurations in some use cases. Same as my response to the previous question, its encoding in different data plane belongs to the respective WGs.

Best regards
Chongfeng

From: Vishnu Pavan Beeram
Date: 2024-10-10 03:45
To: TEAS WG
CC: TEAS WG Chairs
Subject: [Teas] Revisiting NRP Selector
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.