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

[Adrian Farrel <[e-mail]>]

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] <mailto:[e-mail]> > On Behalf
Of Adrian Farrel
Sent: Thursday, September 22, 2022 6:19 AM
To: [e-mail] <mailto:[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]
<mailto:[e-mail]> > 
Sent: 22 September 2022 06:34
To: [e-mail] <mailto:[e-mail]> 
Cc: Krzysztof Szarkowicz <[e-mail]
<mailto:[e-mail]> >; Joel Halpern <[e-mail]
<mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; John
E Drake <jdrake=[e-mail]
<mailto: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]
<mailto:[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