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

[Gyan Mishra <[e-mail]>]

Greg  / All

I agree with your point on the “single NRP” being confusing as you stated
and maybe why this thread started.

Old txt

“one possible realization is of a single NRP using all of the resources of
the entire underlay
   network topology.”

New txt

“a possible realization is of an NRP using all of the resources of the
entire underlay
   network topology.”

If you have single or one  NRP but it’s used all the resources in the
underlay, then how could it be one of many, it has to be the one and only
one NRP.

Kind Regards

Gyan

On Wed, Sep 21, 2022 at 7:40 PM John E Drake <jdrake=
[e-mail]> wrote:

> Greg,
>
>
>
> Precisely.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Wednesday, September 21, 2022 7:14 PM
> *To:* John E Drake <[e-mail]>
> *Cc:* Adrian Farrel <[e-mail]>; Krzysztof Szarkowicz <
> [e-mail]>; Joel Halpern <[e-mail]>;
> [e-mail] <[e-mail]>; TEAS WG <[e-mail]>
> *Subject:* Re: [Teas] Repeated call for last call on
> draft-ietf-teas-ietf-network-slices
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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$>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*