[Teas] Re: Revisiting NRP Selector

[Ketan Talaulikar <[e-mail]>]

Hi Loa,

Please check inline below with KT2 for a clarification.


On Fri, Jan 31, 2025 at 3:59 AM Loa Andersson <[e-mail]> wrote:

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

KT2> I hope not. If this is the same NRP that is spanning across parts of
the network with different data planes in use, then we should be able to
use the same NRP Selector ID. This is what I meant in my initial response
below about the sizes of the field for different data planes.

Thanks,
Ketan


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