Re: [Teas] Default NRP definition [Was: Repeated call for last call on draft-ietf-teas-ietf-network-slices]

[Daniele Ceccarelli <[e-mail]>]

Hi John,

I completely agree with you. That's why i'm saying that if nothing is
configured it would be more appropriate to say that there is no NRP rather
saying that there is a default or single NRP :)

Cheers,
Daniele

On Tue, Sep 27, 2022 at 2:40 PM John E Drake <[e-mail]> wrote:

> Daniele,
>
>
>
> It’s not our job to tell service providers how to deploy or manage their
> underlay networks.  The Framework draft introduces the concept of NRP and
> notes that in the limit you can have a single NRP – nothing more.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Teas <[e-mail]> *On Behalf Of * Daniele Ceccarelli
> *Sent:* Tuesday, September 27, 2022 5:30 AM
> *To:* Dongjie (Jimmy) <jie.dong=[e-mail]>
> *Cc:* John E Drake <jdrake=[e-mail]>; [e-mail]
> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for last
> call on draft-ietf-teas-ietf-network-slices]
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi everyone,
>
>
>
> i tried to read all of the replies not to say something already stated but
> there were so many, so apologies if i'm repeating someone's suggestions.
>
> What about saying that in the network there is NO NRP and as soon as an
> NRP is created all the resources not used by that NRP fall into the
> default NRP?
>
> In the end an operator might not care at all about NRPs and it only makes
> sense to speak about them as soons as the first is created.
>
> Would this make sense?
>
>
>
> Cheers,
>
> Daniele
>
>
>
> On Tue, Sep 27, 2022 at 4:09 AM Dongjie (Jimmy) <jie.dong=
> [e-mail]> wrote:
>
> Hi John,
>
>
>
> In this context, I agree with your analysis, it is about different tunnels
> in the same NRP.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Teas [mailto:[e-mail]] *On Behalf Of *John E Drake
> *Sent:* Monday, September 26, 2022 8:27 PM
> *To:* Joel Halpern <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for last
> call on draft-ietf-teas-ietf-network-slices]
>
>
>
> Joel,
>
>
>
> The context was:  “these two sets of tunnels use exactly the same
> resources: entire topology, i.e. all links and nodes in the network, and
> the PHB is exactly the same (i.e., packet with QoS marking ‘X’ get
> exactly the same treatment in terms of buffering/scheduling, regardless if
> forwarded over tunnel from 1st tunnel set, or tunnel from 2nd tunnel set)
> are we talking about one NRP or two NRPs?”
>
>
>
> I.e., the operator had decided to operate its underlay network as a single
> NRP.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Joel Halpern <[e-mail]>
> *Sent:* Sunday, September 25, 2022 10:36 PM
> *To:* John E Drake <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for last
> call on draft-ietf-teas-ietf-network-slices]
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> John, you said "*I don’t think we are changing the framework text.  I
> don’t see how anyone could infer from the current framework text that this
> situation involves two NRPs."  *Under the interpretation you have stated
> of an NRP being any arbitrary set of resources, then whether the two
> situations are one or two NRPs is reportedly up to the operator?
>
> Yours,
>
> Joel
>
> On 9/25/2022 2:52 PM, John E Drake wrote:
>
> Hi,
>
>
>
> Comments inline below.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Krzysztof Szarkowicz <[e-mail]>
> <[e-mail]>
> *Sent:* Sunday, September 25, 2022 11:07 AM
> *To:* John E Drake <[e-mail]> <[e-mail]>
> *Cc:* Adrian Farrel <[e-mail]> <[e-mail]>;
> [e-mail]
> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for last
> call on draft-ietf-teas-ietf-network-slices]
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Thanks John,
>
>
>
> Please see inline.
>
>
>
> //Krzysztof
>
>
>
> On 2022 -Sep-25, at 16:51, John E Drake <[e-mail]> wrote:
>
>
>
> Hi,
>
>
>
> Comments inline below
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Krzysztof Szarkowicz <[e-mail]>
> *Sent:* Sunday, September 25, 2022 10:36 AM
> *To:* Adrian Farrel <[e-mail]>
> *Cc:* John E Drake <[e-mail]>; [e-mail]
> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for last
> call on draft-ietf-teas-ietf-network-slices]
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Adrian,
>
>
>
> I have couple of questions here:
>
>
>
>
>
> 1. Taking into consideration typical SP network today, where we have:
>
>
>
> a) differentiated services realized via mapping of DCSP and/or MPLS TC
> values to buffers, and deploying some differentiated scheduling
>
> b) running services (L3VPN, L2VPN, ...) over such network
>
> c) possibly (but not necessarily) deploying some TE
>
>
>
> Do we refere to typical current SP deployment as using ’single NRP’ or
> not using NRP at all?
>
>
>
> *[JD]  A single NRP*
>
>
>
> [Krzysztof] So, isn’t it wise to call this single NRP as ‘default’ NRP,
> as it is not explicitly defined? Adrian mentioned: "NRPs should be
> explicit. Sure, you can have a single one that includes all resources on
> all links, but that is still an active choice." I can assure you, that
> these operators have no idea, they operate the network using single NRP.
> Wording proposed by Adrian (and commented by Jie) for default NRP looks
> good to me.
>
>
>
> *[JD]  No, the term is unnecessary and confusing.  If they have no idea
> they are operating a single NRP, why would telling them that they are
> operating a default NRP make any difference? *
>
>
>
>
>
> 2. If I have in my network two set of tunnels between PE nodes, using
> different link metric types (e.g. one set of tunnels uses IGP link metric
> to determine the path through the network, another set of tunnels using TE
> link metric to determine the path through the network), and these two sets
> of tunnels use exactly the same resources: entire topology, i.e. all links
> and nodes in the network, and the PHB is exactly the same (i.e., packet
> with QoS marking ‘X’ get exactly the same treatment in terms of
> buffering/scheduling, regardless if forwarded over tunnel from 1st tunnel
> set, or tunnel from 2nd tunnel set) are we talking about one NRP or two
> NRPs?
>
>
>
> *[JD]  A single NRP.  You are using different path computations on the
> same NRP*
>
>
>
> [Krzysztof] If we are changing the framework text, might be some
> clarification wording for this point would be needed, as I heard opinions
> that this constitute two NRPs.
>
>
>
> *[JD]  I don’t think we are changing the framework text.  I don’t see how
> anyone could infer from the current framework text that this situation
> involves two NRPs.*
>
>
>
> //Krzysztof
>
>
>
> On 2022 -Sep-22, at 18:30, Adrian Farrel <[e-mail]> wrote:
>
>
>
> John makes some good points.
>
>
>
>    1. Adding a definition of a term that is only used in parentheses in
>    one (early) individual draft where one of the authors says it was a mistake
>    to use it, seems excessive. Perhaps we should all just stop using the term?
>    2. The idea of “default” seems wrong in any case. NRPs should be
>    explicit. Sure, you can have a single one that includes all resources on
>    all links, but that is still an active choice.
>
>
>
> Adrian
>
>
>
> *From:* Teas <[e-mail]> *On Behalf Of *John E Drake
> *Sent:* 22 September 2022 14:55
> *To:* John E Drake <jdrake=[e-mail]>;
> [e-mail]; [e-mail]
> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for last
> call on draft-ietf-teas-ietf-network-slices]
>
>
>
> Adrian,
>
>
>
> Upon reflection, the revised wording changes the meaning.  We start by
> observing that “The connected set of links can be the entire set of links
> in the underlay network” and then continue with “ **and in this case
> there*
> *can be a single NRP** and it has all of the buffer/queuing/scheduling
> resources for each of the links in the underlay network”.  I.e.,  We can
> define one or more NRPs that use the entire underlay network topology but
> we can also define, in this case, a single NRP that uses all of the
> underlay network resources – the underlay network has a topology and it
> has resources.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Teas <[e-mail]> *On Behalf Of *John E Drake
> *Sent:* Thursday, September 22, 2022 9:01 AM
> *To:* [e-mail]; [e-mail]
> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for last
> call on draft-ietf-teas-ietf-network-slices]
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Adrian,
>
>
>
> I am okay with your revised wording for single NRP, but I don’t agree
> that we need to define a ‘default NRP’ because it is attempting to detail
> how a given service provider **might** operate its underlay network.
> I.e., it is pure speculation.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Teas <[e-mail]> *On Behalf Of *Adrian Farrel
> *Sent:* Thursday, September 22, 2022 6:19 AM
> *To:* [e-mail]
> *Subject:* [Teas] Default NRP definition [Was: Repeated call for last
> call on draft-ietf-teas-ietf-network-slices]
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi all, again.
>
>
>
> Jumping in at the top of the thread, yet again, to try to dig into two
> pieces of terminology. Picking up particularly on Greg, Jie, and Pavan’s
> points.
>
>
>
> “Single” does, indeed, mean “just one”. But it’s usage is very
> deterministic, meaning “one of (potentially) many” in some cases, and
> meaning “there is exactly one” in other cases. Perhaps it would help if:
>
> OLD
>
>    The connected set of links can be the
>    entire set of links in the underlay network and in this case there
>    can be a single NRP and it has all of the buffer/queuing/scheduling
>    resources for each of the links in the underlay network.
>
> NEW
>
>    The connected set of links can be the
>    entire set of links in the underlay network and in this case there
>    can be precisely one NRP supported in the underlay network where
>
>    that NRP has all of the buffer/queuing/scheduling resources for
>
>    each of the links in the underlay network.
>
> END
>
>
>
> “Default” has, of course, a clear meaning in English (although there are
> several different meanings). As engineers, we should be careful not to
> introduce terms without also writing a clear definition. If we want to use
> the term “default NRP” then we should define it and, in that case, this
> document seems like a fine place to include it. But we are definitely
> fishing around for what “we” mean by the term. I think we are getting to…
>
>
>
> Default NRP:
>
>    The default NRP is constructed from all of the buffer/queuing/scheduling
>
>    resources on all of the links in the underlay network that have not been
>
>    assigned for use by any other NRP.  That is, it consists of the residue
>
>
>    resources.  If no other NRP has been defined, the default NRP comprises
>
>    all of the buffer/queuing/scheduling resources of the underlay network.
>
>    If a further NRP is subsequently defined, the default NRP will be
> reduced
>
>    by the resources assigned to the new NRP.  If an NRP is deleted, its
>
>    resources are released back into the default NRP.
>
>
>
> Commensurate with that, the text quoted above could can become…
>
>    In the case where there is just the default NRP and no other NRPs
>
>    have been defined, the connected set of links can be the entire set
>
>    of links in the underlay network, and in this case there is precisely
>
>    one NRP (the default NRP) supported in the underlay network where
>
>    that NRP has all of the buffer/queuing/scheduling resources for
>
>    each of the links in the underlay network.
>
>
>
> Thoughts?
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Vishnu Pavan Beeram <[e-mail]>
> *Sent:* 22 September 2022 06:34
> *To:* [e-mail]
> *Cc:* Krzysztof Szarkowicz <[e-mail]>; Joel Halpern <
> [e-mail]>; [e-mail]; John E Drake <
> jdrake=[e-mail]>
> *Subject:* Re: [Teas] Repeated call for last call on
> draft-ietf-teas-ietf-network-slices
>
>
>
> Adrian, Hi!
>
>
>
> Thanks for the top-post. Please see inline (prefixed VPB).
>
>
>
> Regards,
>
> -Pavan
>
>
>
>
>
> On Thu, Sep 22, 2022 at 3:46 AM Adrian Farrel <[e-mail]> wrote:
>
> Hi,
>
> Sort of top-posting on the thread, and speaking as editor.
>
> Krzysztof >>
> > I see that the current text is clear and precisely describes the
> > intent of single (default) NRP, so it doesn’t need any
> change/correction.
>
> Well, it was certainly the intent that the text would be clear, but if
> some people are confused or unclear, we should seek to make things clearer.
>
> Note well that the term "default NRP" is not one that is used in the
> document, and any lack of clarity about the term must be laid at the feet
> of the people using the term!
> I *think* the term is being used to describe the limiting case where there
> is just one NRP that is all of the resources in the network.
>
> Joel >>
>  > Does that single NRP admit multiple diffserv code points / queueing
> behaviors?
> [JD]  That is at the discretion of the underlay network operator
>
> I think John and Joel may be at cross-purposes with the same conclusion.
> To Joel: Yes, the single NRP admits the possibility of multiple diffserv
> code points / queueing behaviors.
> To John: Yes, the underlay network operator is free to make the default
> NRP have multiple or fewer codepoints / queueing behaviors.
>
> Joel >>
> > If so, then the notion of NRP is itself purely an arbitrary collection of
> > behaviors, and thus not helpful or particularly meaningful.
>
> "Arbitrary" and "helpful" are possibly a bit loaded.
> Recall that the NRP is an internal mechanism for the underlay network
> operator. It is not exposed to the customer, but is a tool for the operator.
> It allows the operator to partition their network in a way that they find
> useful for the rapid construction of network slices.
> What that amounts to is that the operator may profile the resources of the
> network into collections (NRPs) to enable the support of particular types
> of network slice service.
> The way that an operator does this is entirely up to them (it's a policy),
> so it could be arbitrary or highly logical.
>
> But some people think that it won't be necessary to build NRPs and so we
> have the concept of "the default NRP" which is essentially all of the
> resources of the network.
> It's a null-op in the process, but we keep it there to have a consistent
> picture.
>
> Joel >>
> > One way out is to declare that relative to any given device, the
> collection of behaviors in
> > an NRP may be different diffserv code points but may not be further
> differentiated.
> > Another way out is to declare that the collection referred to in the
> definition refers to
> > the collection across devices, but within a device an NRP has only one
> queueing
> > behavior / resource.
>
> But I wonder if there is a confusion between resources and behaviors? The
> text in the draft is clear that it is describing resources. How the
> resources are used is surely a different matter, or is it?
>
> As a quick reference, the text we're talking about is...
>
>    A Network Resource Partition (NRP) is a collection of resources
>    (bufferage, queuing, scheduling, etc.) in the underlay network.  The
>    amount and granularity of resources allocated in an NRP is flexible
>    and depends on the operator's policy.  Some NRP realizations may
>    build NRPs with dedicated topologies, while some other realizations
>    may use a shared topology for multiple NRPs; one possible realization
>    is of a single NRP using all of the resources of the entire underlay
>    network topology.  Thus, an NRP consists of a subset of the
>    buffer/queuing/scheduling resources on each of a connected set of
>    links in the underlay network.  The connected set of links can be the
>    entire set of links in the underlay network and in this case there
>    can be a single NRP and it has all of the buffer/queuing/scheduling
>    resources for each of the links in the underlay network.
>
> Pavan and Lou >>
> > This thread does seem to suggest there are some loose ends with
> > respect to the notion of a default NRP that need to be tied before
> > publication. There are some open questions on how resources in
> > the default NRP get impacted when you start adding resource
> > partitions in the underlay network.
>
> We do have to return to ask, "What is this default NRP that you are
> talking about?" If it is, as I assume, the "single NRP" that "has all of
> the buffer/queuing/scheduling resources for each of the links in the
> underlay network" then it should be fairly obvious that adding other NRPs
> does change the definition of the "default NRP." This happens because the
> default NRP stops being the only NRP and so stops being the default NRP.
>
> I believe you have yourself wrapped around the definition of a term that
> doesn't exist.
>
>
>
> [VPB] You are right -- draft-ietf-teas-ietf-network-slices does not use
> the term "default NRP".  draft-ietf-teas-ns-ip-mpls, which extensively
> discusses the notion of one or more network resource partitions, also does
> not use this term (yet). But, we are starting to discuss slicing
> realization documents in the WG that are building on this notion of a
> "default/single/only NRP" as framed in draft-ietf-teas-ietf-network-slices
> (see draft-srld-teas-5g-slicing which does use this term) and for that
> purpose it may be useful to discuss what this entails (now rather than
> later).  As Jie has pointed out in this thread, there is an interpretation
> here that you may start with a default NRP (no explicit resource
> partitioning) to realize slicing, but you may end up having the default NRP
> co-exist with non-default NRPs as they get gradually added to the network.
> The default NRP in this interpretation may simply translate to the set of
> resources that don't meet the selection criteria of any explicit
> user-specified NRP (if there are no user-specified NRPs, then the default
> NRP includes all the resources in the underlay network). Another
> interpretation of the default NRP is (like you said) that it ceases to
> exist when the first resource partition is made (two explicit NRPs get
> created).
>
>
>
> [VPB] We (the WG) may end up saying that we don't need to discuss "default
> NRP" or its semantics in draft-ietf-teas-ietf-network-slices, but rather
> have it discussed in draft-ietf-teas-ns-ip-mpls (which does talk about
> slicing realization using one or more resource partitions) instead. But it
> is a loose end that needs to be tied at some point.
>
>
>
>
> Pavan and Lou >>
> > We are hoping that the WGLC (the process for which has just begun)
> > would be a forcing function for those of you (chairs included) who
> > intend to suggest text/edits to clear this up.
>
> It would be great if exactly that happened. That is, text suggestions.
>
> Cheers,
> Adrian
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!C0Cbp6e6wcOCIVeA1aT1n44Wf96-VKMA8tnK1DUNPN_0pNkp0OBouxUGsaaZCen03sfeMUmURWIB-wW6HCBj$>
>
>
>
>
>
> _______________________________________________
>
> Teas mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!GRHbqlhkpUVsFdvI-ADUlvXAWoj7_UMq31A79n5zYOqqvxgF53GjiXDPRfZvgDbAfzIliYInrpMf0OI$>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Gov_3G04iP9d718HVM8eb3M3gGxf09fDqXXjJLuwkLgPVPUTgwU3xglFXGFJEP8zlUaBEafVC-_hULus3N_elQ$>
>
>