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

[Greg Mirsky <[e-mail]>]

Hi Krzysztof,
I believe that there cannot be a situation when the NRP is randomly
created. Whether an operator is required to explicitly create the NRP or
one will be created by the system is, in my opinion, pre-determined and
hence is the explicit action.

Regards,
Greg

On Mon, Sep 26, 2022 at 12:51 PM Krzysztof Szarkowicz <[e-mail]>
wrote:

> Greg,
>
> If an NRP is not explicitly configured, then there are two options:
>
> a) there is no NRP
> b) there is an implicit NRP
>
> I am fine with either of above options, and can adjust my draft
> accordingly, whatever the conclusion is.
>
> Regards,
> Krzysztof
>
>
> On 2022 -Sep-26, at 21:39, Greg Mirsky <[e-mail]> wrote:
>
> Hi Krzysztof,
> I don't think that it is "implicit". In my opinion, it is the result of
> discussions about what that behavior should be. And, I expect it is
> properly documented.
>
> Regards,
> Greg
>
> On Mon, Sep 26, 2022 at 12:27 PM Krzysztof Szarkowicz <
> [e-mail]> wrote:
>
>> Greg,
>>
>> That is my opinions as well. And, as a consequence, it leads to an
>> implicit NRP.
>>
>> Regards,
>> Krzysztof
>>
>>
>> On 2022 -Sep-26, at 21:17, Greg Mirsky <[e-mail]> wrote:
>>
>> Hi Krzysztof,
>> in my opinion and based on my experience, even if an operator has not
>> explicitly configured the NRP in the underlay network, it is performed by
>> the SW according to the programmer's understanding of how networking should
>> be operated.
>>
>> Regards,
>> Greg
>>
>> On Mon, Sep 26, 2022 at 11:37 AM Krzysztof Szarkowicz <
>> [e-mail]> wrote:
>>
>>> Adrian,
>>>
>>> In today’s operator’s network, where services with SLOs are delivered,
>>> NRP is not (explicitly) defined.
>>>
>>> Are we saying, that today’s network are providing these services without
>>> NRP (a) at all, or with implicit (default) NRP (b) that uses all resources
>>> in the network.
>>>
>>> —
>>> Krzysztof
>>>
>>>
>>> On 2022 -Sep-26, at 18:48, Adrian Farrel <[e-mail]> wrote:
>>>
>>> I would add that Krzysztof’s default NRP **is** explicitly defined.
>>> That it, the system is operated with the simple instruction “all resources
>>> are in the single NRP”. That is, it is not default and this is a policy
>>> operational decision. It may be that the operational decision is made at
>>> purchase time (this equipment supports only having a single NRP that
>>> contains all of the resources of the underlay network), but it is still an
>>> active decision. I see know benefit in referring to it as “default” since
>>> (as was pointed out way up this thread) the concept of defaulting becomes
>>> unclear when a second NRP is defined.
>>>
>>> But shouldn’t we step back from the naming and talk about what function
>>> we need to achieve?
>>>
>>> Adrian
>>>
>>> *From:* John E Drake <[e-mail]>
>>> *Sent:* 26 September 2022 17:33
>>> *To:* Greg Mirsky <[e-mail]>
>>> *Cc:* Krzysztof Szarkowicz <[e-mail]>; Adrian Farrel <
>>> [e-mail]>; [e-mail]
>>> *Subject:* Re: [Teas] Default NRP definition [Was: Repeated call for
>>> last call on draft-ietf-teas-ietf-network-slices]
>>>
>>> Greg,
>>>
>>>
>>> A most excellent point.  All attempts to describe a transition from a
>>> single NRP to a default NRP have foundered on this distinction.
>>> Sent from my iPhone
>>>
>>>
>>> On Sep 26, 2022, at 12:29 PM, Greg Mirsky <[e-mail]> wrote:
>>>
>>> 
>>> *[External Email. Be cautious of content]*
>>>
>>> Hi Krzysztof,
>>> I would note that the meaning of "default", as defined in, for example, Merriam-Webster
>>> dictionary
>>> <https://urldefense.com/v3/__https:/www.merriam-webster.com/dictionary/default__;!!NEt6yMaO-gk!H1gH-SvWJAhAijZq1KDgW_aaVA0pN9BVcWY3L4Fti4wjpwvCpYxtvhBWeBCAWTUSowUsDZ2Ur17W1aoiW-wt$>,
>>> is not the same as "single":
>>>
>>> computers : a selection automatically used by a program in the absence
>>> of a choice made by the user
>>>
>>> As I understand it, "default" exists and might be used in the presence
>>> of other alternatives, NPRs, in our case. Hence, it appears that by
>>> equating "single NPR" with "default NPR" we'll limit the applicability of
>>> the latter. WDYT?
>>>
>>> Regards,
>>> Greg
>>>
>>>
>>> On Sun, Sep 25, 2022 at 8:07 AM Krzysztof Szarkowicz <
>>> [e-mail]> wrote:
>>>
>>> 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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> //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!H1gH-SvWJAhAijZq1KDgW_aaVA0pN9BVcWY3L4Fti4wjpwvCpYxtvhBWeBCAWTUSowUsDZ2Ur17W1QCegxMj$>
>>>
>>>
>>>
>>
>