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

From: Gyan Mishra <[email-masked]>
Date: Sat, 4 Sep 2021 02:14:06 -0400

Hi Tarek, John & Jie

I would like to chime in, comments in-line.

In defining the resource in the underlay and how to discretely identify the
nomenclature for NSC in provisioning underlay for a network slice.

Also a key point mentioned in this thread and this relates to TE ACTN
network slice and SR network slice which we have compared and contrasted,
that any technology even Flex Algo or any other can be used in the underlay
for the NSC provisioning of the network slice.

Resource Partition = subset of underlay network links resources
instantiation of the underlay data plane cross section layer of the network.

Partitioned Underlay Network Topology = Combination of multiple resource
partitions to instantiate an underlay topology for the NSC provisioning of
the network slice - JD

Network Resource Partition = Tarek
More explicitly defining resources for a network and not just a link

Resource Partition Network = Jie

To me putting network in the front or at the end has the intent to try to
qualify the resource Partition so it’s not just for a set of links but for
the fine grain data plane network topology.

>From a grammatical perspective the adjective proceeds the nouns they are
describing so I think “network resource partition” would be grammatically
correct.

Kind Regards

Gyan

On Wed, Aug 25, 2021 at 11:16 AM Tarek Saad <[email-masked]> wrote:

> Hi Jie,
>
>
>
> See Inline, [TS2]..
>
>
>
> *From: *Dongjie (Jimmy) <[email-masked]>
> *Date: *Tuesday, August 24, 2021 at 11:16 AM
> *To: *Tarek Saad <[email-masked]>, John E Drake <[email-masked]>,
> Lizhenbin <[email-masked]>, TEAS WG <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>,
> 龚立艳 <[email-masked]>, draft-filsfils-sprin <
> [email-masked]>,
> draft-ali-teas-sprin <[email-masked]>,
> [email-masked] <[email-masked]>, Adrian Farrel <
> [email-masked]>, draft-decraene-mpls- <
> [email-masked]>
> *Subject: *RE: [Teas] More Discussion//RE: Re:Re: New term for the
> underlay construct used for slice realization
>
> Hi,
>
>
>
> Please see comments inline with [Jie]:
>
>
>
> *From:* Tarek Saad [mailto:[email-masked]]
> *Sent:* Saturday, August 21, 2021 1:05 AM
> *To:* John E Drake <[email-masked]>; Lizhenbin <[email-masked]>;
> TEAS WG <[email-masked]>
> *Cc:* Dongjie (Jimmy) <[email-masked]>; [email-masked];
> [email-masked]; 龚立艳 <[email-masked]>; draft-filsfils-sprin <
> [email-masked]>;
> draft-ali-teas-sprin <[email-masked]>;
> [email-masked] <[email-masked]>; Adrian Farrel <
> [email-masked]>; draft-decraene-mpls- <
> [email-masked]>
> *Subject:* Re: [Teas] More Discussion//RE: Re:Re: New term for the
> underlay construct used for slice realization
>
>
>
> Hi,
>
>
>
> Comments inline..
>
>
>
> *From: *John E Drake <[email-masked]>
> *Date: *Friday, August 20, 2021 at 9:33 AM
> *To: *Lizhenbin <[email-masked]>, TEAS WG <[email-masked]>
> *Cc: *Dongjie (Jimmy) <[email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <[email-masked]>, 龚立艳 <
> [email-masked]>, draft-filsfils-sprin <
> [email-masked]>,
> draft-ali-teas-sprin <[email-masked]>,
> [email-masked] <[email-masked]>, Adrian Farrel <
> [email-masked]>, Tarek Saad <[email-masked]>,
> draft-decraene-mpls- <
> [email-masked]>
> *Subject: *RE: [Teas] More Discussion//RE: Re:Re: New term for the
> underlay construct used for slice realization
>
> Hi,
>
>
>
> Comments inline.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Teas <[email-masked]> *On Behalf Of *Lizhenbin
> *Sent:* Thursday, August 19, 2021 1:05 PM
> *To:* TEAS WG <[email-masked]>
> *Cc:* Dongjie (Jimmy) <[email-masked]>; [email-masked];
> [email-masked]; 龚立艳 <[email-masked]>; draft-filsfils-sprin <
> [email-masked]>;
> draft-ali-teas-sprin <[email-masked]>;
> [email-masked] <[email-masked]>; Adrian Farrel <
> [email-masked]>; Tarek Saad <[email-masked]>;
> draft-decraene-mpls- <
> [email-masked]>
> *Subject:* [Teas] More Discussion//RE: Re:Re: New term for the underlay
> construct used for slice realization
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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.
>
>
>
> *[JD]  Making these conclusions is the co-chairs’ job.*
>
>
>
> [TS]: +1
>
>
>
> 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”?
>
>
>
> *[JD]  There are two separate concepts:*
>
>
>
> *1)      **Resource Partition - a subset of an underlay network link's
> buffer/queuing/scheduling resources used to enable the underlay network to
> have finer grained control of its data plane.*
>
> * Gyan> Agreed *
>
> *2)      **Combining these resource partitions into a topology in the
> underlay network, for which I was using the term 'partitioned underlay
> network topology'.*
>
> * Gyan> Agreed *
>
>
>
> [TS]: I suggested appending network – i.e. “network resource partition” as
> more suitable to indicate resources are over an underlay “network” vs. a
> resource partition over a single link.
>
> Gyan> +1    I think John’s term “partitioned underlay network topology”
> can be better defined as “network resource partition”.  As we are defining
> the partition of the underlay we don’t need to use the word “underlay”  or
> “topology” as that is what is being instantiated.
>
> [Jie] While I understand the intent here is to indicate that the resource
> partitions are spread over the network, however “network resource
> partition” could be interpreted as “partition of network resources (e.g.
> buffer/queue/scheduling resources)”, which does not convey the information
> we need.
>
>
> Perhaps a more explicit approach is to put network in the end: resource
> partitioned network (or sub-network), so that it is clear that the resource
> partitions are spread over the network with a sub-topology.
>
>  Gyan>  I think the goal putting  network at the end trying to better
> define the partitioned resource set from a grammatical perspective the
> adjective here “network” should proceed the noun “resource”
>
> *[TS2]: The “network” here is to define the “scope” of the resource group
> (or partition) and not connectivity. Hence, I favor “network” being as a
> prefix.*
>
>
>
>
>
> 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?
>
>
>
> *[JD]  The connectivity constructs of a given IETF network slice service
> can be implemented in the underlay network using whatever technologies the
> provider wishes to use.  A given resource partition can support multiple
> connectivity constructs of any type.*
>
>
>
> [TS]: I agree here. Different connectivity types can be realized over the
> same network resource partition
>
>  Gyan> +1
>
> [Jie] Then my understanding is this underlay construct always provide
> any-to-any connectivity between the edge nodes, which can be used to
> deliver services with any connectivity type. Is this correct?
>
>
>
> *[TS2]: The resources may be connected (in different ways) to provide any
> type of connectivity.*
>
>  Gyan> +1
>
> 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?
>
>
>
> *[JD]  Resource partitions just provide an enhanced underlay network
> topology to which a provider can apply TE if they so desire.*
>
> * Gyan>  Agreed *
>
> [TS]: TE can be done over the resources that a network resource partition
> can offer – for example, to optimally place paths over the remaining
> resources of network resource partition.
>
> Gyan> Agreed
>
> [Jie] This may be related to the definition of TE. Is resource partition
> or reservation one of the components of TE? I hope we can get some answer
> from 3272bis.
>
>  Gyan> I think the point that John snd Tarek are making is that the set
> resources we are describing can apply to any technology TE, SR, Flex Algo
> or other, and so the technology is orthogonal as we are not taking about
> the technology being used in the underlay.
>
> We used to define the TE-LSP as something with which we can specify the
> path and the set of resources reserved along the path. Following this, the
> underlay construct we are discussing can be used to specify the topology
> and the set of resources reserved in the topology.  If we call the TE-LSP a
> “TE path”, maybe we can call this underlay construct a “TE network” or
> “virtual TE network”. Then TE paths can be provisioned in the virtual TE
> network, just like how the TE paths are provisioned in the physical
> network.
>
>
>
> *[TS2]: AFAICS, the term we’re defining describes a set of resources in a
> network and, hence, it is orthogonal to the TE discussion.*
>
> *Gyan> Agreed *
>
> *Regards,*
>
> *Tarek*
>
>
>
> Best regards,
>
> Jie
>
>
>
> Regards,
>
> Tarek
>
>
>
> Wish to learn your thoughts on these considerations and doubts.
>
>
>
>
>
>
>
> Best Regards,
>
> Robin
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Lizhenbin
> *Sent:* Tuesday, August 17, 2021 10:29 PM
> *To:* '龚立艳' <[email-masked]>; draft-ali-teas-sprin <
> [email-masked]>; draft-filsfils-sprin <
> [email-masked]>;
> draft-decraene-mpls- <
> [email-masked]>
> *Cc:* Dongjie (Jimmy) <[email-masked]>; [email-masked];
> [email-masked]; TEAS WG <[email-masked]>; EXT-vishnupavan@gmai <
> [email-masked]>; Adrian Farrel <[email-masked]>; Tarek Saad <
> [email-masked]>
> *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,
>
> Robin
>
>
>
>
>
>
>
> *From:* 龚立艳 [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Tuesday, August 17, 2021 4:48 PM
> *To:* Lizhenbin <[email-masked]>; draft-ali-teas-sprin <
> [email-masked]>; draft-filsfils-sprin <
> [email-masked]>;
> draft-decraene-mpls- <
> [email-masked]>
> *Cc:* Dongjie (Jimmy) <[email-masked]>; [email-masked];
> [email-masked]; TEAS WG <[email-masked]>; EXT-vishnupavan@gmai <
> [email-masked]>; Adrian Farrel <[email-masked]>; Tarek Saad <
> [email-masked]>
> *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]
> https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-encoding-network-sliceid/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cheng-spring-srv6-encoding-network-sliceid/__;!!NEt6yMaO-gk!UEzcMT5c8gj3IM4YTjtt3_cAKLDIdvWjVnDnaMVJtcpFKSjgsNrS6x9I2VZ2kRs$>
>
>
>
> Best Regards,
>
> Liyan Gong
>
>
>
> ----邮件原文----
> *发件人：*Lizhenbin  <[email-masked]>
> *收件人：*"[email-masked]" <
> [email-masked]>,"
> [email-masked]" <
> [email-masked]>,"
> [email-masked]" <
> [email-masked]>
> *抄 送**: *"Dongjie \\(Jimmy\\)" <[email-masked]>,"[email-masked]" <
> [email-masked]>,"[email-masked]" <[email-masked]>,TEAS WG  <[email-masked]
> >,John E Drake  <jdrake=[email-masked]>,"
> [email-masked]" <[email-masked]>,Adrian Farrel  <
> [email-masked]>,Tarek Saad  <[email-masked]>
> *发送时间：*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,
>
> Robin
>
>
>
>
>
>
>
> *From:* Teas [mailto:[email-masked] <[email-masked]>] * On
> Behalf Of *John E Drake
> *Sent:* Monday, August 16, 2021 8:53 PM
> *To:* Dongjie (Jimmy) <[email-masked]>; [email-masked] <
> [email-masked]>; Adrian Farrel <[email-masked]>
> *Cc:* Tarek Saad <[email-masked]>; TEAS WG <[email-masked]>
> *Subject:* Re: [Teas] New term for the underlay construct used for slice
> realization
>
>
>
> Hi,
>
>
>
> It sounds like slice aggregates, or more generally overlay network service
> aggregates, are the things which use resource partitions.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Teas <[email-masked]> * On Behalf Of *Dongjie (Jimmy)
> *Sent:* Friday, August 13, 2021 9:20 AM
> *To:* [email-masked] <[email-masked]>; Adrian Farrel <
> [email-masked]>
> *Cc:* Tarek Saad <[email-masked]>; TEAS WG <[email-masked]>
> *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 [mailto:[email-masked] <[email-masked]>] * On
> Behalf Of *Vishnu Pavan Beeram
> *Sent:* Friday, August 13, 2021 1:32 AM
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* Tarek Saad <[email-masked]>; TEAS WG <[email-masked]>
> *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 <[email-masked]>
> 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,
>
> Jie
>
>
>
> 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.
>
>
>
> Adrian
>
>
>
> *From:* Tarek Saad <[email-masked]>
> *Sent:* 12 August 2021 15:41
> *To:* [email-masked]; 'Kiran Makhijani' <[email-masked]>;
> 'John E Drake' <jdrake=[email-masked]>;  'Dongjie (Jimmy)' <
> [email-masked]>; 'Lizhenbin' <[email-masked]>; [email-masked]
> *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.
>
>
>
> Regards,
>
> Tarek
>
>
>
>
>
> *From: *Teas <[email-masked]> on behalf of Adrian  Farrel <
> [email-masked]>
> *Date: *Wednesday, August 11, 2021 at 3:38 PM
> *To: *'Kiran Makhijani' <[email-masked]>, 'John E Drake' <
> jdrake=[email-masked]>,  'Dongjie (Jimmy)' <
> [email-masked]>, 'Lizhenbin' <[email-masked]>, [email-masked] <
> [email-masked]>
> *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
> service."
>
> 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
> connectivity
>     in the context of the operator's network. The relationship here is like
> the
>     relationship between the L3SM and L3NM.
>
> 3. At the bottom of their view is an underlying network. The technology of
> this
>    network depends, of course, on the operator's offering, but this is the
> network
>    technology being sliced. It may be an IP network, and MPLS network, an
> OTN,
>    or whatever. I would call this the "Underlay Network." This network may,
> in
>    turn, be built upon an underlay network of the same or a different
> technology,
>    and it may be facilitated through network slicing - but this need not
> concern
>    us here.
>
> 4. That leaves the glue in the middle: the bit that enables the scaling and
> maps
>    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,
> buffers,
>        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
> slice
>         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+),
> through
>         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.
>
> Best,
> Adrian
>
>
> -----Original Message-----
> From: Teas <[email-masked]> On Behalf Of Kiran Makhijani
> Sent: 11 August 2021 16:00
> To: John E Drake <jdrake=[email-masked]>; Dongjie (Jimmy)
> <[email-masked]>; Lizhenbin <[email-masked]>; [email-masked]
> Subject: Re: [Teas] New term for the underlay construct used for slice
> realization
>
> 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.
>
> Thanks
> Kiran
>
>
> ------ Original Message ------
> From: "John E Drake" <jdrake=[email-masked]>
> To: "Dongjie (Jimmy)" <[email-masked]>; "Lizhenbin"
> <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: 8/11/2021 5:38:05 AM
> Subject: Re: [Teas] New term for the underlay construct used for slice
> realization
>
> >Jimmy,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >
> >Juniper Business Use Only
> >
> >>  -----Original Message-----
> >>  From: Dongjie (Jimmy) <[email-masked]>
> >>  Sent: Tuesday, August 10, 2021 11:03 PM
> >>  To: John E Drake <[email-masked]>; Lizhenbin <[email-masked]
> >;
> >>[email-masked]
> >>  Subject: RE: New term for the underlay construct used for slice
> realization
> >>
> >>  [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
> generalized
> >>  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
> following
> >>  > > 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
> network
> >>  > 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:
> >>  >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf>
> >>  > 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
> Network
> >>  Slice Services.
> >>  > This is congruent with the ideas expressed in:
> >>  >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf>
> >>  > 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
> construct.
> >>  "Resource partition" captures one of its key characteristics, while IMO
> another
> >>  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
> points.
> >>  >
> >>  > [JD]  I think you have exceeded your remit.
> >>  >
> >>  > >
> >>  > >
> >>  > >
> >>  > > Best Regards,
> >>  > > Robin
> >>  > >
> >>  > > _______________________________________________
> >>  > > Teas mailing list
> >>  > > [email-masked]
> >>  > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te>
> >>  > > as
> >>  > > __;!!N
> >>  > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
> >>  > > O08HqD31TGJciNjuxL2A$
> >>  >
> >>  > _______________________________________________
> >>  > Teas mailing list
> >>  > [email-masked]
> >>  >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas>
> >>  > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
> >>  ROxL4C2
> >>  > _xNDCrPaNQ$
> >
> >_______________________________________________
> >Teas mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/teas
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$>
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$>
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$>
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 10 Sep 2021 04:20:08 +0000

Hi Gyan,

Thanks for providing your thoughts on this. Please see some replies inline with [Jie]:

From: Gyan Mishra [mailto:[email-masked]]
Sent: Saturday, September 4, 2021 2:14 PM
To: Tarek Saad <[email-masked]>
Cc: Adrian Farrel <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; [email-masked] <[email-masked]>; John E Drake <[email-masked]>; Lizhenbin <[email-masked]>; TEAS WG <[email-masked]>; draft-ali-teas-sprin <[email-masked]>; draft-decraene-mpls- <[email-masked]>; draft-filsfils-sprin <[email-masked]>; [email-masked]; [email-masked]; 龚立艳 <[email-masked]>
Subject: Re: [spring] [Teas] More Discussion//RE: Re:Re: New term for the underlay construct used for slice realization

Hi Tarek, John & Jie

In defining the resource in the underlay and how to discretely identify the nomenclature for NSC in provisioning underlay for a network slice.

Also a key point mentioned in this thread and this relates to TE ACTN network slice and SR network slice which we have compared and contrasted, that any technology even Flex Algo or any other can be used in the underlay for the NSC provisioning of the network slice.

[Jie] Yes, there can be different approaches (both in data plane and control plane) for the instantiation of this underlay construct, and the term needs to be generic enough to cover all of them.

Resource Partition = subset of underlay network links resources instantiation of the underlay data plane cross section layer of the network.

Partitioned Underlay Network Topology = Combination of multiple resource partitions to instantiate an underlay topology for the NSC provisioning of the network slice - JD

[Jie] My proposal was “Resource Partitioned (sub-) Network” or “Virtual TE Network”, where the “network” indicates that it is a set nodes and links on which the resources are partitioned.

To me putting network in the front or at the end has the intent to try to qualify the resource Partition so it’s not just for a set of links but for the fine grain data plane network topology.

[Jie] It seems all the above proposals aim to cover both the resource and topology attributes of this underlay construct. It is good if we have reached some consensus on this.

From a grammatical perspective the adjective proceeds the nouns they are describing so I think “network resource partition” would be grammatically correct.

[Jie] I’m not a native English speaker, so will let other people to comment on the grammar part. My concern was since the resources we referred to are always “network resources”, then “network resource partition” may be considered the same as “resource partition”, which does not explicitly reflect that it is about the resources partitions on a set of nodes and links.

Snipped the further discussion:

…
> Perhaps a more explicit approach is to put network in the end: resource partitioned network (or sub-network), so that it is clear that the resource partitions are spread over the network with a sub-topology.
 Gyan>  I think the goal putting  network at the end trying to better define the partitioned resource set from a grammatical perspective the adjective here “network” should proceed the noun “resource”
[Jie] Since we agreed that the resource and topology are the two basic attributes of this underlay construct, it is actually a network (essentially, a network is a graph with attributes). Thus my opinion is it is more reasonable to use “network” as a noun, and resource partition is the key characteristic.

…
[TS]: TE can be done over the resources that a network resource partition can offer – for example, to optimally place paths over the remaining resources of network resource partition.
Gyan> Agreed
[Jie] This may be related to the definition of TE. Is resource partition or reservation one of the components of TE? I hope we can get some answer from 3272bis.
 Gyan> I think the point that John snd Tarek are making is that the set resources we are describing can apply to any technology TE, SR, Flex Algo or other, and so the technology is orthogonal as we are not taking about the technology being used in the underlay.
[Jie] To me the concept of TE has a much broader scope than TE-LSP. And RSVP-TE, SR, Flex-Algo or other can be seen as the technologies to provide all or part of the TE functionality. Since this WG is also working on a bis of RFC 3272, it may be helpful to align our understanding about TE, and the relationship between TE and resource partition (or allocation).

> We used to define the TE-LSP as something with which we can specify the path and the set of resources reserved along the path. Following this, the underlay construct we are discussing can be used to specify the topology and the set of resources reserved in the
> topology.  If we call the TE-LSP a “TE path”, maybe we can call this underlay construct a “TE network” or “virtual TE network”. Then TE paths can be provisioned in the virtual TE network, just like how the TE paths are provisioned in the physical network.

[TS2]: AFAICS, the term we’re defining describes a set of resources in a network and, hence, it is orthogonal to the TE discussion.

[Jie] Before we have a consistent understanding of TE, I’m not that convinced that TE and resource partition are orthogonal.

Best regards,
Jie

Best Regards,
Robin

From: Lizhenbin
Sent: Tuesday, August 17, 2021 10:29 PM
To: '龚立艳' <[email-masked]<mailto:[email-masked]>>; draft-ali-teas-sprin <[email-masked]<mailto:[email-masked]>>; draft-filsfils-sprin <[email-masked]<mailto:[email-masked]>>; draft-decraene-mpls- <[email-masked]<mailto:[email-masked]>>
Cc: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>; EXT-vishnupavan@gmai <[email-masked]<mailto:[email-masked]>>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
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,
Robin

From: 龚立艳 [mailto:[email-masked]]
Sent: Tuesday, August 17, 2021 4:48 PM
To: Lizhenbin <[email-masked]<mailto:[email-masked]>>; draft-ali-teas-sprin <[email-masked]<mailto:[email-masked]>>; draft-filsfils-sprin <[email-masked]<mailto:[email-masked]>>; draft-decraene-mpls- <[email-masked]<mailto:[email-masked]>>
Cc: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>; EXT-vishnupavan@gmai <[email-masked]<mailto:[email-masked]>>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
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] https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-encoding-network-sliceid/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cheng-spring-srv6-encoding-network-sliceid/__;!!NEt6yMaO-gk!UEzcMT5c8gj3IM4YTjtt3_cAKLDIdvWjVnDnaMVJtcpFKSjgsNrS6x9I2VZ2kRs$>

Best Regards,

Liyan Gong

----邮件原文----
发件人：Lizhenbin  <[email-masked]<mailto:[email-masked]>>
收件人："[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
抄　送: "Dongjie \\(Jimmy\\)" <[email-masked]<mailto:[email-masked]>>,"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,TEAS WG  <[email-masked]<mailto:[email-masked]>>,John E Drake  <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>,"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,Adrian Farrel  <[email-masked]<mailto:[email-masked]>>,Tarek Saad  <[email-masked]<mailto:[email-masked]>>
发送时间：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,
Robin

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

Hi,

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

Yours Irrespectively,

John

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

Hi Pavan,

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

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).

On Thu, Aug 12, 2021 at 10:05 AM Adrian Farrel <[email-masked]<mailto:[email-masked]>> 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,
Jie

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.

Adrian

From: Tarek Saad <[email-masked]<mailto:[email-masked]>>
Sent: 12 August 2021 15:41
To: [email-masked]<mailto:[email-masked]>; 'Kiran Makhijani' <[email-masked]<mailto:[email-masked]>>; 'John E Drake' <jdrake=[email-masked]<mailto:[email-masked]>>;  'Dongjie (Jimmy)' <[email-masked]<mailto:[email-masked]>>; 'Lizhenbin' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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.

Regards,
Tarek

From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Adrian  Farrel <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 11, 2021 at 3:38 PM
To: 'Kiran Makhijani' <[email-masked]<mailto:[email-masked]>>, 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>,  'Dongjie (Jimmy)' <[email-masked]<mailto:[email-masked]>>, 'Lizhenbin' <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
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.

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.

   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.

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.

example) "slice aggregate" (because of 4d, which means it is really a "slice

Best,
Adrian

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

Hi John, (and all),

Thanks
Kiran

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

>>  From: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
>>  To: John E Drake <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>;
>>[email-masked]<mailto:[email-masked]>
realization
possible uses?
generalized
following
network slice
network
>>  > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf>
>>  > calling an 'IETF Network Slice Service'.  Adrian and I are considering
>>  > the term 'resource partition' to describe the partitioning of underlay
Network
>>  > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf>
construct.
another
>>  thing the term needs to reflect is that the resource partition is needed
on a
the physical
network topology'
points.
>>  > > [email-masked]<mailto:[email-masked]>
>>  > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te>
>>  > > as
>>  > > __;!!N
>>  > [email-masked]<mailto:[email-masked]>
>>  > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas>
>[email-masked]<mailto:[email-masked]>
>https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$>

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$>

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TKJch2dwsJUTEeFWCMLasf9_GayAVTsgrkNK6Ve48YTTS1iD_HNe2dms30OL80Q$>
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 10 Sep 2021 01:37:32 -0400

Hi Jimmy

Very welcome.  I think we are very close if not at consensus on this topic,
and it’s just a matter of realization of the consensus. 🙏😁

Let me try to break this down.

“Network” defines the underlay topology that is an instantiated super set a
collection of resource partitions.

“Network Resource Partition” = “Network” is describing the “Resource
Partition” and the culmination of resource partitions is what makes up the
network.  The “resource partitions” are the building blocks that make up
the network.

“Resource partitioned sub-network” or “Virtual TE network” = Resource
partitioned sub-network, here the resource partition is what is describing
the sub network which is a virtualization or sliver of nodes and links made
up of a partitioning of discrete resources, which is a subset of all
underlay resources that make up the physical network ( aka network slice)

I think it’s a close call and both are saying the same thing,  just
differently, so in that respect we are in theory at consensus.

Thinking about it a bit further after breaking it down,  I think Jimmy’s
“Resource Partitioned sub-network” is better aligned with the NS definition.

Responses in-line.

Kind Regards

Gyan

On Fri, Sep 10, 2021 at 12:20 AM Dongjie (Jimmy) <[email-masked]>
wrote:

> *From:* Gyan Mishra [mailto:[email-masked]]
> *Sent:* Saturday, September 4, 2021 2:14 PM
> *To:* Tarek Saad <[email-masked]>
> *Cc:* Adrian Farrel <[email-masked]>; Dongjie (Jimmy) <
> [email-masked]>; [email-masked] <[email-masked]>;
> John E Drake <[email-masked]>; Lizhenbin <[email-masked]>; TEAS
> WG <[email-masked]>; draft-ali-teas-sprin <
> [email-masked]>; draft-decraene-mpls- <
> [email-masked]>;
> draft-filsfils-sprin <
> [email-masked]>; [email-masked];
> [email-masked]; 龚立艳 <[email-masked]>
> *Subject:* Re: [spring] [Teas] More Discussion//RE: Re:Re: New term for
> the underlay construct used for slice realization
>
>
>
>
>
> Hi Tarek, John & Jie
>
>
>
> In defining the resource in the underlay and how to discretely identify
> the nomenclature for NSC in provisioning underlay for a network slice.
>
>
>
>
>
> [Jie] Yes, there can be different approaches (both in data plane and
> control plane) for the instantiation of this underlay construct, and the
> term needs to be generic enough to cover all of them.
>
>  Gyan> Agreed
>
> [Jie] My proposal was “Resource Partitioned (sub-) Network” or “Virtual TE
> Network”, where the “network” indicates that it is a set nodes and links on
> which the resources are partitioned.
>
>  Gyan> Understood
>
> [Jie] It seems all the above proposals aim to cover both the resource and
> topology attributes of this underlay construct. It is good if we have
> reached some consensus on this.
>
>  Gyan> Yes, Agreed
>
> [Jie] I’m not a native English speaker, so will let other people to
> comment on the grammar part. My concern was since the resources we referred
> to are always “network resources”, then “network resource partition” may be
> considered the same as “resource partition”, which does not explicitly
> reflect that it is about the resources partitions on a set of nodes and
> links.
>
> Gyan> Your point is very well taken and I agree with the ambiguity with
> the meaning of “network resource partition”.
>
>
>
> [Jie] Since we agreed that the resource and topology are the two basic
> attributes of this underlay construct, it is actually a network
> (essentially, a network is a graph with attributes). Thus my opinion is it
> is more reasonable to use “network” as a noun, and resource partition is
> the key characteristic.
>
> Gyan>  Agreed
>
> …
>
> [Jie] To me the concept of TE has a much broader scope than TE-LSP. And
> RSVP-TE, SR, Flex-Algo or other can be seen as the technologies to provide
> all or part of the TE functionality. Since this WG is also working on a bis
> of RFC 3272, it may be helpful to align our understanding about TE, and the
> relationship between TE and resource partition (or allocation).
>
>  Gyan>  Agreed on RFC 3272bis. 👍😃
>
The concept of resource reservations and allocations of resources  for path
> steering being a component of TE,  I think we all agree to that fact.  The
> idea behind resource partition as to why we are saying it’s orthogonal is
> that we are treating it as an absolute concept , thus generalizing it’s
>  context, so it can be applied to any steering mechanism used by the NSC to
> provision the network slice.
>
> and the set of resources reserved in the
>
> > topology.  If we call the TE-LSP a “TE path”, maybe we can call this
> underlay construct a “TE network” or “virtual TE network”. Then TE paths
> can be provisioned in the virtual TE network, just like how the TE paths
> are provisioned in the physical network.
>
>
>
> [Jie] Before we have a consistent understanding of TE, I’m not that
> convinced that TE and resource partition are orthogonal.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Teas [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *John E Drake
> *From:* Teas <[email-masked]> *On Behalf Of *Dongjie (Jimmy)
> *From:* Teas [mailto:[email-masked] <[email-masked]>] *On
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*