Re: [Teas] More Discussion//RE: Re:Re: New term for the underlay construct used for slice realization

Adrian Farrel <> Mon, 27 September 2021 07:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E1933A08BE; Mon, 27 Sep 2021 00:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.797
X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MAY_BE_FORGED=1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F8at3wSyugRF; Mon, 27 Sep 2021 00:52:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F33F13A08C0; Mon, 27 Sep 2021 00:52:32 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 18R7qCk9016947; Mon, 27 Sep 2021 08:52:12 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id BF7854604E; Mon, 27 Sep 2021 08:52:11 +0100 (BST)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id A506E4604B; Mon, 27 Sep 2021 08:52:11 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS; Mon, 27 Sep 2021 08:52:11 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 18R7q8jJ011652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Sep 2021 08:52:09 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Krzysztof Szarkowicz'" <>, "'John E Drake'" <>
Cc: "'Lizhenbin'" <>, "'TEAS WG'" <>, "'Dongjie \(Jimmy\)'" <>, <>, <>, =?utf-8?B?J+m+mueri+iJsyc=?= <>, "'draft-filsfils-sprin'" <>, "'draft-ali-teas-sprin'" <>, <>, "'Tarek Saad'" <>, "'draft-decraene-mpls-'" <>
References: <> <> <>
In-Reply-To: <>
Date: Mon, 27 Sep 2021 08:52:07 +0100
Organization: Old Dog Consulting
Message-ID: <041b01d7b374$93058630$b9109290$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_041C_01D7B37C.F4D11A20"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIi566bQHcHFaFZ+XsvhiBi/n/UhgIJfQOmAlgEreyq/gw9sA==
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--11.125-10.0-31-10
X-imss-scan-details: No--11.125-10.0-31-10
X-TMASE-Result: 10--11.124700-10.000000
X-TMASE-MatchedRID: JQSF04SbSlRIZ/0Pt1D9ExGJru+O7KxNo4LMRUiBwZalmQXE120jTmXD 5i3g0CqOqusedOuRwGadIDUGmRnk0oHL770UjjjiguwtqyXlE6HURn+XOe/hRUtssRkSqfpNX/F dXQdFwlARLrszzc5CIldpb2H6zKjW9Ib/6w+1lWQCC8zqHvcG2reW2B07O0PwyVhaMnMnOpn+qq XfNwpdAS+1+k84A6xHgMsT7/7q+Mvaize54oCwVKVjgXyvS9c/3unRG7yMq8W14ARIgaeOl+JzZ jKavucdkfogCiAqT00Wv8GJveaIWwI6GksNBIxVTmb4S36qG9/czjWtUbKcd2c6FiBin4Ldy9/F mt0QTwwTVZAR6YkV3hWHMmWB85c1yhPaAPXFzs1PeAvBAsfKB+QydRUvl3QT4kVs3+nVI4TOrf5 TzZFi8Qtxnn69ENR1CnC5rp2SVZWu/BEw2+vZg7Q/y8fi37xLuSti1BoHqPZZeMX00rN0KVeC6t n30IvqtfBE7110Y0qaYlNpIKBgC/ZvT2zYoYOw9+PHtghP8GLB8fZdmGC6EAVNn1wxbwqEshO8L 8MIhSZWTblO8HESzDj7+2rbSDLFwCGU3q1ZqNNL9x4FCuBLUSJ8zskw0dbrpZkFxNdtI04KO0eM 7yB2CdiNiugj3+xlpR+4qzHEjQeEeJva4+0wXa74AKu3V75aDO+DX+rUwfZ95EepdMBiBnE07QE qpv+ThupvHYW4S4WPRwLh/Lx0QEaMPBFKXyAUxBgaBynd2vms/t8iuh5J8yIPvMapUGsMqMFop9 OsZ6vMQN2xWFtdUtA3eYCeEax0ngIgpj8eDcDSR6EqVsrUqT5gTn7BF99aYxeu+Iqmk8ErN8z0H ohG3v558CedkGIvHl89tzhQNcOd8FpadjJpT8qAMkqQ5+Pww79quCY/fetdsnb3ed0XZSQHmVa3 75wMJZdkJRo6GjjPpITthqwV2MeeuuhN2oDuD5/xW0BdEvE=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Teas] More Discussion//RE: Re:Re: New term for the underlay construct used for slice realization
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Sep 2021 07:52:43 -0000

I have this topic on my slides for the interim later today.

It is certainly my contention that having a common term is preferable – one that can be used or referred to by all protocol solution work.


Let me note that “group” is a good word, but perhaps indicates that a resource is either in a group or not in a group. This makes sharing a resource between groups problematic, although a resource could be in both groups.


The alternative word here might be “partition” (as in “network resource partition”).


In situations like this, where there are plenty of words to choose from, it is common to find disagreement on exactly which term to use. In order to break the deadlock, a useful approach can be not to ask “what is your favourite word?” (which leads to a beauty contest, a vote, and bad feelings – all of which we try to avoid in the IETF), but instead to ask “which terms could you live with?” That is, think about which terms would be uncomfortable, but acceptable. Everyone may have to give a little in order to get agreement, but surely everyone’s third favourite word is better than half the people’s least favourite.






From: Krzysztof Szarkowicz <> 
Sent: 27 September 2021 08:10
To: John E Drake <>
Cc: Lizhenbin <>om>; TEAS WG <>rg>; Dongjie (Jimmy) <>om>;;; 龚立艳 <>om>; draft-filsfils-sprin <>rg>; draft-ali-teas-sprin <>rg>; <>om>; Adrian Farrel <>uk>; Tarek Saad <>om>; draft-decraene-mpls- <>
Subject: Re: [Teas] More Discussion//RE: Re:Re: New term for the underlay construct used for slice realization


Hi John,


The term “network resource group” was proposed by Tarek back in August, if I am not mistaken (


Nevertheless, I still believe that the neutral term not strictly referenced to ‘resource’, like for example ‘underlay slice’ (mentioned as well earlier in this thread) is much more appropriate, given the fact that many deployments for 5G slicing will use resource partitioning at transport edge only, but not use any specific resource partitioning in transit.






On 2021 -Sep-26, at 19:13, John E Drake < <> > wrote:


This is the first time I have seen this term so I don’t completely understand your assertion that the mailing list discussion supported it, and as I have previously noted, judging rough consensus is not within your remit.


I think the term is neither meaningful nor resonant.


Yours Irrespectively,





Juniper Business Use Only

From: spring < <> > On Behalf Of Lizhenbin
Sent: Friday, September 24, 2021 9:26 PM
To: TEAS WG < <> >
Cc: Dongjie (Jimmy) < <> >; <> ; <> ; 龚立艳 < <> >; draft-filsfils-sprin < <> >; draft-ali-teas-sprin < <> >; <>  < <> >; Adrian Farrel < <> >; Tarek Saad < <> >; draft-decraene-mpls- < <> >
Subject: Re: [spring] More Discussion//RE: Re:Re: [Teas] New term for the underlay construct used for slice realization


[External Email. Be cautious of content]


Hi Folks,


Thanks for the feedbacks and discussion about the further considerations of the new term.


According to both the mail list discussion and the offline discussion between the co-authors of draft-dong-teas-enhanced-vpn-vtn-scalability and draft-bestbar-teas-ns-packet, our current preference is to choose “network resource group” as the new term.


The definition of this new term could be based on the text proposed by Adrian:

Network resource group: a collection of nodes, links, and network resources that are allocated within the network for use by a set of network service traffic flows.


As for the relationship between network resource group and TE, perhaps it could be discussed further along with the progress and discussion of draft-3272bis.


Please let us know if you have any thoughts about this, many thanks.



Best regards,





From: Lizhenbin 
Sent: Friday, August 20, 2021 1:05 AM
To: 'TEAS WG' < <> >
Cc: Dongjie (Jimmy) < <> >; ' <> ' < <> >; ' <> ' < <> >; 'EXT-vishnupavan@gmai' < <> >; 'Adrian Farrel' < <> >; 'Tarek Saad' < <> >; '龚立艳' < <> >; 'draft-ali-teas-sprin' < <> >; 'draft-filsfils-sprin' < <> >; 'draft-decraene-mpls-' < <> >
Subject: More Discussion//RE: Re:Re: [Teas] New term for the underlay construct used for slice realization


Hi Folks,


The “new term” discussion has been lasted for a while, thanks to all who participated in the discussion.


So far it seems there are some rough consensus about this “new term” (maybe I am wrong) :

1. It is better to have a neutral term, which allows this underlay construct to be used for both network slice services and other types of services.

2. It seems “resource group” receives more support than other candidates.


Here I’d also like to share some considerations and doubts about the underlay construct used for slice realization:

1. Before this discussion happens, it seems many network slicing related drafts use “slice” in their terms which refer to this underlay construct. However, through this new term discussion, it seems most people indicate they prefer a neutral term than a slice specific term. Thus I expect the authors of the related drafts to provide more feedback about this point and indicate whether they agree with the choice of a neutral term.


2. As mentioned several times during the discussion, this underlay construct has both the topology and resource attributes. With the term “resource group”, it is clear that it is a set of network resources, then how about the topology attribute? Is the topology attribute also included in the “resource group”?


3. What is the intended scope of resource group? More specifically, is a point-to-point path or a P2MP path with a set of reserved network resource a resource group? In history, RSVP-TE was used to set up resource reserved point-to-point TE paths and P2MP TE paths. More recently, there is effort in DetNet WG on the mechanisms to set up deterministic data paths. Can these paths be considered as resource groups?  Can we further classify them into different P2P resource group, P2MP resource group, or MP2MP resource group?


4. A more subtle question is, what is the relationship between resource group and TE? Is resource group a construct under the TE architecture, or is there some overlap between them?


Wish to learn your thoughts on these considerations and doubts.




Best Regards,








From: Lizhenbin 
Sent: Tuesday, August 17, 2021 10:29 PM
To: '龚立艳' < <> >; draft-ali-teas-sprin < <> >; draft-filsfils-sprin < <> >; draft-decraene-mpls- < <> >
Cc: Dongjie (Jimmy) < <> >; <> ; <> ; TEAS WG < <> >; EXT-vishnupavan@gmai < <> >; Adrian Farrel < <> >; Tarek Saad < <> >
Subject: RE: Re:Re: [Teas] New term for the underlay construct used for slicerealization


Hi Liyan,

Sorry that I missed your new draft. Thanks for your feedback. It is helpful for us to have a common terminology.


Best Regards,





From: 龚立艳 [] 
Sent: Tuesday, August 17, 2021 4:48 PM
To: Lizhenbin < <> >; draft-ali-teas-sprin < <> >; draft-filsfils-sprin < <> >; draft-decraene-mpls- < <> >
Cc: Dongjie (Jimmy) < <> >; <> ; <> ; TEAS WG < <> >; EXT-vishnupavan@gmai < <> >; Adrian Farrel < <> >; Tarek Saad < <> >
Subject: Re:Re: [Teas] New term for the underlay construct used for slicerealization


Hi All,

The draft-cheng-spring-srv6-encoding-network-sliceid[1] also provided a slice ID encoding solution.

And about the discussion, we are fine to follow the final decision of the WG, no special requirements.


[1] <;!!NEt6yMaO-gk!TIkfI-loKpf1zVOsyQ46WJ4_6c1XFBAuOBH2eKqbXGK6hQun73rE29CL3ED752M$> 


Best Regards,

Liyan Gong


发件人:Lizhenbin  < <> >
收件人:" <> " < <> >," <> " < <> >," <> " < <> >
抄 送: "Dongjie \\(Jimmy\\) <file://(jimmy/)> " < <> >," <> " < <> >," <> " < <> >,TEAS WG  < <> >,John E Drake  < <> >," <> " < <> >,Adrian Farrel  < <> >,Tarek Saad  < <> >
发送时间:2021-08-17 00:04:32
主题:Re: [Teas] New term for the underlay construct used for slicerealization


Hi authors of draft-ali-teas-spring-ns-building-blocks/draft-filsfils-spring-srv6-stateless-slice-id/draft-decraene-mpls-slid-encoded-entropy-label-id,


It is known that your drafts are also related with the underlay construct used for slice realization. It also seems that you use the term with “slice”  for the underlay construct. In the discussion of TEAS WG, there is some consensus to define a neutral new term without “slice”.  Wish to learn your opinions on the new term definition and there would be a convergence on the new term after your participating  in the discussion.



Best Regards,





From: Teas [] On Behalf Of John E Drake
Sent: Monday, August 16, 2021 8:53 PM
To: Dongjie (Jimmy) < <> >; <>  < <> >; Adrian Farrel < <> >
Cc: Tarek Saad < <> >; TEAS WG < <> >
Subject: Re: [Teas] New term for the underlay construct used for slice realization




It sounds like slice aggregates, or more generally overlay network service aggregates, are the things which use resource partitions.


Yours Irrespectively,





Juniper Business Use Only

From: Teas < <> > On Behalf Of Dongjie (Jimmy)
Sent: Friday, August 13, 2021 9:20 AM
To: <>  < <> >; Adrian Farrel < <> >
Cc: Tarek Saad < <> >; TEAS WG < <> >
Subject: Re: [Teas] New term for the underlay construct used for slice realization


[External Email. Be cautious of content]


Hi Pavan,


Sorry for chiming in, please see some comments inline:


From: Teas [] On Behalf Of Vishnu Pavan Beeram
Sent: Friday, August 13, 2021 1:32 AM
To: Adrian Farrel < <> >
Cc: Tarek Saad < <> >; TEAS WG < <> >
Subject: Re: [Teas] New term for the underlay construct used for slice realization


** As a WG participant.. **

Adrian, Hi!

Thanks for your earlier emails in this thread that have helped drill down the discussion to the specific item that needs a fresh term!
Please see inline (prefixed VPB).

-Pavan (as a WG participant)


On Thu, Aug 12, 2021 at 10:05 AM Adrian Farrel < <> > wrote:

Thanks for your useful opinion, Tarek.


I have no objection to the use of the word “aggregate”. It is generally used to express grouping together to treat as a single entity or to be treated in the same way.


But I do like “foo aggregate” to mean that a number of foo have been aggregated.


[VPB] But, that isn’t necessarily how IETF has been using the term “aggregate”.  “Behavior Aggregate” (as defined in IETF) doesn’t mean aggregating behaviors. The same goes for “Treatment Aggregate”. Behavior Aggregate (the way we read/interpret it) is an aggregate with a specific behavior. 


[Jie] I just checked the definition of the “aggregate” related terms in the RFCs:


Behavior Aggregate (defined in RFC 2474): a collection of packets with the same codepoint crossing a  link in a particular direction.”


Traffic Aggregate (defined in RFC 3086): a collection of packets with a codepoint that maps to the same  PHB, usually in a DS domain or some subset of a DS domain.


Treatment Aggregate (defined in RFC 5127): This term is defined as the aggregate of Diffserv service  classes.  A treatment aggregate is concerned only with the forwarding treatment of the aggregated traffic,  which may be marked with multiple DSCPs.


My reading of these definitions is that “aggregate” here means either aggregated packets or aggregated service classes which are treated in the same  way on a particular node or link.


While what we want to describe with the new term IMO is “a group of network resources allocated on a set of network nodes and links”. Such group  of resources can be provisioned in different places of the network and are organized together to provide a specific network-level behavior.


Thus the key information to be delivered with the new term is “a group of organized resources in the network”, rather than “aggregated behavior at  a particular point”.


Best regards,



So “slice aggregate” would be an aggregation of slices. Your use in I-D.draft-bestbar-teas-ns-packet is, therefore, confusing. If the slices are *not* separated out into different flows (or traffic streams) then, yes, you are aggregating slices. But if the slices are separated out, as you describe,  then what you have is “IETF network slice traffic stream aggregation”.



[VPB] Yes. The definition of the slice aggregate (as defined in draft-bestbar-teas-ns-packet) does state that the slice aggregate comprises of one or more IETF network slice traffic streams.  We could have chosen a longer  descriptive name, but opted to keep it short.



“Network resource aggregate” would imply that resources have been collected together to be used as a single entity.


[VPB] Not necessarily. "Network Resource Aggregate" isn't meant to imply "aggregating network resources". The intent behind the proposal is to say that it is an aggregate that has specific network resources. 


You might do that, for example, with a set of parallel links that can be aggregated (or bundled) and treated as a single link.


I don’t think we are aggregating resources in this case. We are grouping, profiling, partitioning, collecting, or even filtering.




From: Tarek Saad < <> > 
Sent: 12 August 2021 15:41
To: <> ; 'Kiran Makhijani' < <> >; 'John E Drake' < <> >;  'Dongjie (Jimmy)' < <> >; 'Lizhenbin' < <> >; <> 
Subject: Re: [Teas] New term for the underlay construct used for slice realization


Hi Adrian/all,


As described in I-D.ietf-teas-ietf-network-slice-definition, an IETF Network Slice service may include multiple connections that associate sets of endpoints -  each having a set of SLOs/SLEs.

In I-D.draft-bestbar-teas-ns-packet, we defined a Slice Aggregate as a construct that comprises of one or more IETF network slice traffic streams that share the  same set of SLOs/SLEs.

The Slice Aggregate construct allows aggregating streams from multiple IETF Network Slice connections that share common SLOs/SLEs so that the provider network  can offer the same aggregate treatment to them. The Slice Aggregate resources are instantiated on specific network elements as dictated by the Slice Aggregate topology.


Since the scope of I-D.draft-bestbar-teas-ns-packet was the realization of IETF Network Slice service in a provider network, we had constrained the aggregate  construct to slices.


We understand that the aggregate construct can be generalized to support other services. Let us offer another option to consider for representing the generic  construct: “Network Resource Aggregate”. There are multiple IETF documents that use the term Aggregate whenever grouping multiple service classes (Behavior Aggregate, Treatment Aggregate, Traffic Aggregate,  etc.) - refer to rfc5127 and rfc2474 for more examples.






From: Teas < <> > on behalf of Adrian  Farrel < <> >
Date: Wednesday, August 11, 2021 at 3:38 PM
To: 'Kiran Makhijani' < <> >, 'John E Drake' < <> >,  'Dongjie (Jimmy)' < <> >, 'Lizhenbin' < <> >, <>  < <> >
Subject: Re: [Teas] New term for the underlay construct used for slice realization

I wonder whether we can pick this apart and put it back together in a way
that makes sense.

The customer's view of all this is an "IETF network slice service". I think
(hope) we are all agreed on this. The customer may ask (in shorthand) for a
"network slice", but:
- they are talking about IETF technology, so they asking for an "IETF
network slice"
- they actually want behavioural characteristics and have no right to tell
the operator
  how to manage the network, so they are asking for an "IETF network slice

The operator has a bigger set of things to worry about. 

1. At the top of the operator's view is the "IETF network slice service" as
    requested by the customer. We have this defined already, so nothing more
    to say.

2. The operator maps the request for a slice service into the "IETF network
    slice" which is the expression of the service in terms of network
    in the context of the operator's network. The relationship here is like
    relationship between the L3SM and L3NM.

3. At the bottom of their view is an underlying network. The technology of
   network depends, of course, on the operator's offering, but this is the
   technology being sliced. It may be an IP network, and MPLS network, an
   or whatever. I would call this the "Underlay Network." This network may,
   turn, be built upon an underlay network of the same or a different
   and it may be facilitated through network slicing - but this need not
   us here. 

4. That leaves the glue in the middle: the bit that enables the scaling and
   the network slice to the network. And I think it is this bit that is
causing the
   most debate about terminology. There are some points to consider:

   a. The term "network resources" applies to the bandwidth, queues,
       etc. available on the links and nodes in the network. That may be 
       extended to refer to whole links and nodes.

   b. The number of IETF network slice services is potentially large and the
       operator needs a mechanism to scale the mapping of services to 
       network resources.

   c. The IETF network slices may be grouped for identical treatment to
       achieve scaling, where the grouping collects IETF network slices with
       similar SLAs.

   d. It may be that different traffic flows within a single IETF network
        have different characteristics. In this case, it may be beneficial
to group
        together some of the traffic flows from different slices.

   e. The grouped slices/flows are enabled in the network using network
        resources assigned for that purpose. The assignment may be anything
        from a fully-fledged virtual network (such as in ACTN or VPN+),
        network reserved resources (such as in MPLS-TE), and centrally
        accounted resources (such as SDN or possible SR), to statistically
        shared resources.

There seems to be various points for and against 4d. But, it would appear
that this is an implementation or deployment issue that doesn't change what
the protocols need to do. So we should probably allow it architecturally, or
at least, not disallow it.

Of course, as Kiran points out, 4c/d/e may be a pass-through. That is, it is
not necessary to implement such groupings either because there are only a
few slices (which has been the view of some operators) or because the
network systems can handle the number of slices. And it is in the nature of
architectures of this sort that all functions can be nulled out without loss
of generality, and we have to recall that the internals of provisioning
systems may appear as functional blocks in our architectures, but we don't
compel implementations to adhere to that type of architecture. So I don't
think we have to worry on that account.

And that brings the question of how we name the resources that are gathered
in 4e. 

I can't decide whether it is helpful to spend time saying why I don't like
each of the proposed terms. I certainly have things I don't like about (for
example) "slice aggregate" (because of 4d, which means it is really a "slice
sub-flow aggregate"), and I am not a fan of "VTN" (because of "transport"
and maybe it is not really a network). But maybe it is better for me to say
what I think we should call things? I think we have...

-       IETF network slice service (customer view)
-       IETF network slice (operator view)
-       Resource partition (delivery mechanism)
-       Underlay network (network used to support the slice)

Why "resource partition"? Well it is a collection of "nodes, links, and
network resources that are marked within the network for use by a set of
network slice traffic flows".
It is possible that the word "partition" is too strong because it may imply
to some people that resources in a partition cannot be shared, but I don't
feel that.
Softer words than "partition" would be "group", "bundle", "pool", and I
could live with any of them.


-----Original Message-----
From: Teas < <> > On Behalf Of Kiran Makhijani
Sent: 11 August 2021 16:00
To: John E Drake < <> >; Dongjie (Jimmy)
< <> >; Lizhenbin < <> >; <> 
Subject: Re: [Teas] New term for the underlay construct used for slice

Hi John, (and all),

Two very basic clarification questions:
1. How do we differentiate between  the slice-segments that are 
resource-aware vs those that are not? I had assumed that since a slice 
has an SLO, it will need network resource allocations in some form.

2. Is it ok to assume that the customer view of slice is an 'IETF 
network slice service' and the 'IETF slice realization' of that service 
in a provider network is raises the question of underlay and overlay 
constructs. Am I right?
(a) if so, then we are acknowledging  the presence of another layer of 
abstraction (for realization). It could be underlay/overlay or 
aggregate/??. Then the term 'slice aggregate' is better and my 
preference, it is easier to see that different slice-services are 
aggregated into a single construct  in a provider network. Use of 
underlay/overlay are confusing.
(b) for a leaner provisioning, I would also prefer to see it documented 
that the aggregate is optional and it should be possible to directly map 
a slice-service to physical or real resources in the network. 
specifically useful when a single domain is carving out slices for 
different purposes.


------ Original Message ------
From: "John E Drake" < <> >
To: "Dongjie (Jimmy)" < <> >; "Lizhenbin" 
< <> >; " <> " < <> >
Sent: 8/11/2021 5:38:05 AM
Subject: Re: [Teas] New term for the underlay construct used for slice 

>Snipped, comments inline.
>Yours Irrespectively,
>Juniper Business Use Only
>>  -----Original Message-----
>>  From: Dongjie (Jimmy) < <> >
>>  Sent: Tuesday, August 10, 2021 11:03 PM
>>  To: John E Drake < <> >; Lizhenbin < <> >;
>> <> 
>>  Subject: RE: New term for the underlay construct used for slice
>>  [External Email. Be cautious of content]
>underlay construct for network slice realization bound to
>>  > > network slice services? That is, is the underlay construct only for
>>  > > use in network slicing, or should it be generalized for more
possible uses?
>>  >
>>  > [JD] Absolutely yes
>>  [Jie] I guess you mean "Yes" to the latter case, which is "it should be
>>  for more possible uses", is my understanding correct?
>[JD]  Yes to the latter
>>  >
>>  > >
>>  > > 2.      If the answer to question 1 is YES, should it reflect the
>>  > > characteristics?
>>  > >
>>  > > a.      It is about the underlay
>>  > > b.      It is about the partitioned resources used to deliver the
network slice
>>  > > services
>>  > > c.      It allows the 1:1, N:1, and 1:N mapping models between the
>>  > slice
>>  > > services and the underlay construct. The 1:1 and N:1 mapping may be
>>  > > straightforward. Does it also make sense to divide the elements or
>>  > > traffic flows in a single network slice service to carry them in
>>  > > different
>>  > underlay constructs?
>>  >
>>  > [JD]  Yes to all of the above.  Please see:
>>  > <> 
>>  > t-drake-bess-enhanced-vpn-06__;!!NEt6yMaO-
>>  gk!TCiJHCZCwFgwpuFoujxVlZ4r9
>>  > F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNaR2ImI4$
>>  > >
>>  > > Lastly, here are some candidates of the "new term":
>>  > >
>>  > > Option 1: The network slice service is called "overlay slice", then
>>  > > the underlay construct is called "underlay slice".
>>  > >
>>  > > Option 2: The network slice service is called "service slice", then
>>  > > the underlay construct is called "resource slice".
>>  >
>>  > [JD]  I don't think we need another term for what we are already
>>  > calling an 'IETF Network Slice Service'.  Adrian and I are considering
>>  > the term 'resource partition' to describe the partitioning of underlay
>>  > network resources in support of various overlay services such as IETF
>>  Slice Services.
>>  > This is congruent with the ideas expressed in:
>>  > <> 
>>  > t-ietf-spring-resource-aware-segmen__;!!NEt6yMaO-
>>  gk!TCiJHCZCwFgwpuFouj
>>  > xVlZ4r9F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNxEfwaXg$
>>  > ts-03.  What this allows one to build is an 'partitioned underlay
>>  > network topology'.
>>  [Jie] Agree that here we are talking about the term for the underlay
>>  "Resource partition" captures one of its key characteristics, while IMO
>>  thing the term needs to reflect is that the resource partition is needed
on a
>>  subset of the links and nodes (rather than on a single node or link) in
the physical
>>  network, which together builds a logical network topology.
>[JD]  In my initial email, above, I was proposing 'partitioned underlay
network topology'
>>  Best regards,
>>  Jie
>>  >
>>  > >
>>  > > Your opinion about these candidates are much appreciated. You may
>>  > > also propose other new term if it complies with the above two
>>  >
>>  > [JD]  I think you have exceeded your remit.
>>  >
>>  > >
>>  > >
>>  > >
>>  > > Best Regards,
>>  > > Robin
>>  > >
>>  > > _______________________________________________
>>  > > Teas mailing list
>>  > > <> 
>>  > > <> 
>>  > > as
>>  > > __;!!N
>>  > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
>>  > > O08HqD31TGJciNjuxL2A$
>>  >
>>  > _______________________________________________
>>  > Teas mailing list
>>  > <> 
>>  > <> 
>>  > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
>>  ROxL4C2
>>  > _xNDCrPaNQ$
>Teas mailing list
> <> 
> <;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$> 

Teas mailing list <> <;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$> 

Teas mailing list <> <;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$> 

Teas mailing list <> <;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$> 

Teas mailing list <>