[Teas] Re: Revisiting NRP Selector

[Loa Andersson <[e-mail]>]

Pavan, Ketan,

Inline plz.

Den 29/01/2025 kl. 18:07, skrev Ketan Talaulikar:
> 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 <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 29^th  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
>             <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?
>               o “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 <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.

I agree with Ketan.
> 
>           * Length of the dedicated identifier field
>               o Is it okay for this to be different for different data-
>                 plane types?
> 
> 
> KT> Yes

I agree.

However a question Maybe hypothetical). If two data plane have an NRP 
Selector ID of the same length do we need to define two different NRP 
Selector IDs?

/Loa
> 
>               o 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
>               o 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?
> 
>               o 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] <mailto:[e-mail]>
>     To unsubscribe send an email to [e-mail] <mailto:teas-
>     [e-mail]>
> 
> 
> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]