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

[Greg Mirsky <[e-mail]>]

Hi John,
thank you for pointing that out. Personally, the term "single NRP" is a bit
confusing to me as it may be interpreted not as "the one and only NRP" but
as "one of several NRPs". As I understand Adrian's clarifications,
the intention is the former, not the latter interpretation. Right?

Regards,
Greg

On Wed, Sep 21, 2022 at 4:07 PM John E Drake <[e-mail]> wrote:

> Greg,
>
> As Adrian points out, the Framework draft does not use the term ‘default
> NRP’ so we are not responsible for any confusion regarding its usage.
> Rather, we use the term ‘single NRP’ to refer to the limiting case.
>
> Sent from my iPhone
>
> On Sep 21, 2022, at 7:02 PM, Greg Mirsky <[e-mail]> wrote:
>
> 
>
> [External Email. Be cautious of content]
>
> Hi Adrian,
> thank you for your clarification, very helpful to me.
> I have one question about the default NRP. As I understand it, the default
> NRP exists only when there are no other NRPs and it implicitly represents
> the collection of all the network's resources. Is that correct?
>
> Kind regards,
> Greg
>
> On Wed, Sep 21, 2022 at 3:16 PM 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.
>>
>> 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!HgxguMR_5zKLGSzV4fMSNPW5rmUILaS53LXL5hiS6fqRPZJloF9dVxoG6mhJrhcXw5Kdr6UFVolfKRcoYGVS$>
>>
>