[Teas] Re: Revisiting NRP Selector

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

Hi Pavan and all,

Thanks for raising this on the list.  It is reasonable to reach consensus on the terminology and the general designs in TEAS, and leave the data plane encoding specifics to the respective WGs.

One thing I would like to add is, when we reach consensus on these points, perhaps they can be documented in a TEAS document (e.g. draft-ietf-teas-nrp-scalability) as guidelines.

My replies to the questions are as below:


  *   What do we call this dedicated identifier field?
     *   “NRP Selector ID” and “NRP Data Plane ID” have been proposed so far.

[Jie] I would prefer to call it “Data Plane NRP ID”. This way it can be aligned and also differentiated from the NRP ID used in management/control plane, and it allows (optional) mapping between the NRP ID used in management/control plane and in data plane.

As for “NRP Selector ID”, it sounds to me that “selector” and “ID” are a little bit duplicated. And in my view NRP selector as a general term can refer to both the derived IDs and the dedicated IDs which are used for associating the packet with an NRP.


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

[Jie] Now that the length of the basic IDs in different data plane types are different, IMO it is not mandatory to have fixed NRP ID length in different data plane, and its 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).

[Jie] Based on the discussion with people and on the 6man list, it has shown that the “Strict” match indicator is useful for providing flexible and fine-granular control to the forwarding behavior of packets which cannot be mapped to an NRP on a transit node.

Similar to my answer to the 2nd question, the encoding of the Strict match indicator is part of the specifics to be discussed in the respective WGs.

Best regards,
Jie

From: Vishnu Pavan Beeram [mailto:[e-mail]]
Sent: Thursday, October 10, 2024 3:45 AM
To: TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
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.