Subject: Re: [Teas] New Version Notification for draft-bestbar-teas-ns-packet-04.txt

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 5 Nov 2021 15:43:07 +0000

Hi Tarek,

Thanks for the update.

I am glad to see this version is much improved. However, it is not quite clear to me whether the term "slice aggregate" is still needed or not.

In previous versions, it was described as the underlay network construct which the IETF network slice service are mapped to. With the introduction of the generic term "Network Resource Partition", it seems now slice aggregate is only used to refers to "a collection of packets", and "comprises of one or more IETF network slice traffic streams".

To my understanding, this is no more than a collection of packets which will be mapped to a particular network resource partition. In that case, we could simply call it "slice traffic" or "slice traffic flows".

Both traffic and flow are generic and could express the notion of aggregate. For example, as described in RFC7011,

"A Flow is defined as a set of packets or frames passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties."

Do you see anything missing if we simply use "slice traffic" or "slice traffic flows"?

Best regards,
Jie

From: Teas [mailto:[email-masked]] On Behalf Of Tarek Saad
Sent: Monday, October 25, 2021 10:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-04.txt

Hi WG,

This update includes the following:
*       Several nit edits
*       Use of the generic term "Network Resource Partition" to indication the resources on specific link(s)/node(s) that will be traversed by a slice-aggregate
*       New section 3 for "IETF Network Slice Realization"
Regards,
Tarek (for co-authors)

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 25, 2021 at 9:53 AM
To: Luis M. Contreras <[email-masked]<mailto:[email-masked]>>, EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>, Joel Halpern <[email-masked]<mailto:[email-masked]>>, Luis Contreras <[email-masked]<mailto:[email-masked]>>, Ran Chen <[email-masked]<mailto:[email-masked]>>, Reza Rokui <[email-masked]<mailto:[email-masked]>>, Shaofu Peng <[email-masked]<mailto:[email-masked]>>, Tarek Saad <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bestbar-teas-ns-packet-04.txt
[External Email. Be cautious of content]

A new version of I-D, draft-bestbar-teas-ns-packet-04.txt
has been successfully submitted by Tarek Saad and posted to the
IETF repository.

Name:           draft-bestbar-teas-ns-packet
Revision:       04
Title:          Realizing Network Slices in IP/MPLS Networks
Document date:  2021-10-22
Group:          Individual Submission
Pages:          32
URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bestbar-teas-ns-packet-04.txt__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KStmd-Lrg$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-bestbar-teas-ns-packet-04.txt__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KStmd-Lrg$>
Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KQU8M3gMQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KQU8M3gMQ$>
Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTdDUsYPg$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTdDUsYPg$>
Diff:           https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-04__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTPNaxS1w$<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-04__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTPNaxS1w$>

Abstract:
   Network slicing provides the ability to partition a physical network
   into multiple logical networks of varying sizes, structures, and
   functions so that each slice can be dedicated to specific services or
   customers.  Network slices need to operate in parallel while
   providing slice elasticity in terms of network resource allocation.
   The Differentiated Service (Diffserv) model allows for carrying
   multiple services on top of a single physical network by relying on
   compliant nodes to apply specific forwarding treatment (scheduling
   and drop policy) on to packets that carry the respective Diffserv
   code point.  This document adopts the Diffserv principles and
   proposes a scalable approach to realize network slicing in IP/MPLS
   networks.  The solution does not mandate Diffserv to be enabled in
   the network to provide a specific forwarding treatment, but can co-
   exist with and complement it when enabled.

The IETF Secretariat

Juniper Business Use Only

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 5 Nov 2021 13:34:01 -0400

Neither "slice traffic" nor "slice traffic flow" captures that the 
resources and queueing being managed by this 
(draft-bestbar-tease-ns-packet) are expected to be used to support 
multiple slices.

One possibility is that slice aggregate may correspond to network 
resource partition".  I am not sure that works, but it is an avenue 
worth looking at.

Yours,
Joel

On 11/5/2021 11:43 AM, Dongjie (Jimmy) wrote:
> Hi Tarek,
> 
> Thanks for the update.
> 
> I am glad to see this version is much improved. However, it is not quite 
> clear to me whether the term "slice aggregate" is still needed or not.
> 
> In previous versions, it was described as the underlay network construct 
> which the IETF network slice service are mapped to. With the 
> introduction of the generic term “Network Resource Partition”, it seems 
> now slice aggregate is only used to refers to “a collection of packets”, 
> and “comprises of one or more IETF network slice traffic streams”.
> 
> To my understanding, this is no more than a collection of packets which 
> will be mapped to a particular network resource partition. In that case, 
> we could simply call it “slice traffic” or “slice traffic flows”.
> 
> Both traffic and flow are generic and could express the notion of 
> aggregate. For example, as described in RFC7011,
> 
> "A Flow is defined as a set of packets or frames passing an Observation 
> Point in the network during a certain time interval. All packets 
> belonging to a particular Flow have a set of common properties."
> 
> Do you see anything missing if we simply use “slice traffic” or “slice 
> traffic flows”?
> 
> Best regards,
> 
> Jie
> 
> *From:*Teas [mailto:[email-masked]] *On Behalf Of *Tarek Saad
> *Sent:* Monday, October 25, 2021 10:28 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [Teas] FW: New Version Notification for 
> draft-bestbar-teas-ns-packet-04.txt
> 
> Hi WG,
> 
> ·Several nit edits
> ·Use of the generic term “Network Resource Partition” to indication the 
> resources on specific link(s)/node(s) that will be traversed by a 
> slice-aggregate
> 
> ·New section 3 for “IETF Network Slice Realization”
> 
> Regards,
> 
> Tarek (for co-authors)
> 
> *From: [email-masked] <mailto:[email-masked]> 
> <[email-masked] <mailto:[email-masked]>>
> *Date: *Monday, October 25, 2021 at 9:53 AM
> *To: *Luis M. Contreras <[email-masked] 
> <mailto:[email-masked]>>, EXT - 
> [email-masked] <mailto:[email-masked]> 
> <[email-masked] <mailto:[email-masked]>>, Daniele 
> Ceccarelli <[email-masked] 
> <mailto:[email-masked]>>, Joel Halpern 
> <[email-masked] <mailto:[email-masked]>>, Luis 
> Contreras <[email-masked] 
> <mailto:[email-masked]>>, Ran Chen 
> <[email-masked] <mailto:[email-masked]>>, Reza Rokui 
> <[email-masked] <mailto:[email-masked]>>, Shaofu Peng 
> <[email-masked] <mailto:[email-masked]>>, Tarek Saad 
> <[email-masked] <mailto:[email-masked]>>, Vishnu Pavan Beeram 
> <[email-masked] <mailto:[email-masked]>>, Vishnu Pavan Beeram 
> <[email-masked] <mailto:[email-masked]>>, Xufeng Liu 
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *New Version Notification for draft-bestbar-teas-ns-packet-04.txt
> 
> URL: 
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bestbar-teas-ns-packet-04.txt__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KStmd-Lrg$ 
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-bestbar-teas-ns-packet-04.txt__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KStmd-Lrg$>
> Status: 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KQU8M3gMQ$ 
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KQU8M3gMQ$>
> Htmlized: 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTdDUsYPg$ 
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTdDUsYPg$>
> Diff: 
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-04__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTPNaxS1w$ 
> <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-04__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfcHWiz0fJsjai2v-lSVl3xaQ9KTPNaxS1w$>
> 
> Abstract:
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 5 Nov 2021 14:13:25 -0500

Jie, Hi!

Thanks for reviewing the latest version!

The narrative in draft-bestbar-teas-ns-packet uses slice aggregate to mean
“one or more IETF network slice traffic streams that are given the same
forwarding treatment based on some selection criteria”. A slice aggregate
is associated with a collection of resources that are used to support it
and this collection of resources is referred to as the “Network Resource
Partition”.

IMHO, “Slice traffic” or “Slice traffic flows” doesn’t capture the above
meaning. Please note that there is no change to the semantics of slice
aggregate from previous versions of the draft – the only thing that has
been added to the narrative is a term (network resource partition) for the
collection of resources used to support this aggregate.

Regards,

-Pavan

On Fri, Nov 5, 2021 at 10:43 AM Dongjie (Jimmy) <[email-masked]> wrote:

> In previous versions, it was described as the underlay network construct which the IETF network slice service are mapped to. With the introduction of the generic term “Network Resource Partition”, it seems now slice aggregate is only used to refers to “a collection of packets”, and “comprises of one or more IETF network slice traffic streams”.
>
>
>
> will be mapped to a particular network resource partition. In that case, we
> could simply call it “slice traffic” or “slice traffic flows”.
>
>
>
> Point in the network during a certain time interval. All packets belonging
> to a particular Flow have a set of common properties."
>
>
>
> *From:* Teas [mailto:[email-masked]] *On Behalf Of *Tarek Saad
> ·       Several nit edits
> ·       Use of the generic term “Network Resource Partition” to
> indication the resources on specific link(s)/node(s) that will be traversed
> by a slice-aggregate
>
> ·       New section 3 for “IETF Network Slice Realization”
>
> Regards,
>
> Tarek (for co-authors)
>
>
>
> *From: [email-masked] <[email-masked]>
> *To: *Luis M. Contreras <[email-masked]>, EXT
> - [email-masked] <[email-masked]>, Daniele
> Ceccarelli <[email-masked]>, Joel Halpern <
> [email-masked]>, Luis Contreras <
> [email-masked]>, Ran Chen <[email-masked]>,
> Reza Rokui <[email-masked]>, Shaofu Peng <[email-masked]>,
> Tarek Saad <[email-masked]>, Vishnu Pavan Beeram <[email-masked]>,
> Vishnu Pavan Beeram <[email-masked]>, Xufeng Liu <
> [email-masked]>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 6 Nov 2021 07:14:24 +0000

Hi Joel,

The resources and queuing related information are the attribute of the underlay network construct, which is now referred to as "network resource partition". 

I can understand that in previous versions (before network resource partition is introduced) slice aggregate was also used to refer to the underlay network construct, thus the confusions caused.

While in this version the slice aggregate is just "a collection of packets", which IMO does not reflect the resources and queuing information in the network.

You mentioned that "one possibility is that slice aggregate may correspond to network resource partition", then as the network resource partition is already introduced, do you think it suffices to describe the resource used for processing the network slice traffic?

Best regards,
Jie

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Saturday, November 6, 2021 1:34 AM
> To: Dongjie (Jimmy) <[email-masked]>; Tarek Saad
> <tsaad=[email-masked]>; [email-masked]
> Subject: Re: [Teas] New Version Notification for
> Neither "slice traffic" nor "slice traffic flow" captures that the resources and
> queueing being managed by this
> (draft-bestbar-tease-ns-packet) are expected to be used to support multiple
> slices.
> 
> One possibility is that slice aggregate may correspond to network resource
> partition".  I am not sure that works, but it is an avenue worth looking at.
> 
> Yours,
> Joel
> 
> > I am glad to see this version is much improved. However, it is not
> > quite clear to me whether the term "slice aggregate" is still needed or not.
> >
> > In previous versions, it was described as the underlay network
> > construct which the IETF network slice service are mapped to. With the
> > introduction of the generic term “Network Resource Partition”, it
> > seems now slice aggregate is only used to refers to “a collection of
> > packets”, and “comprises of one or more IETF network slice traffic streams”.
> >
> > To my understanding, this is no more than a collection of packets
> > which will be mapped to a particular network resource partition. In
> > that case, we could simply call it “slice traffic” or “slice traffic flows”.
> >
> > "A Flow is defined as a set of packets or frames passing an
> > Observation Point in the network during a certain time interval. All
> > packets belonging to a particular Flow have a set of common properties."
> >
> > ·Use of the generic term “Network Resource Partition” to indication
> > the resources on specific link(s)/node(s) that will be traversed by a
> > slice-aggregate
> >
> > <[email-masked] <mailto:[email-masked]>>,
> > Daniele Ceccarelli <[email-masked]
> > <[email-masked] <mailto:[email-masked]>>, Vishnu Pavan
> > Beeram <[email-masked] <mailto:[email-masked]>>, Xufeng Liu
> > has been successfully submitted by Tarek Saad and posted to the IETF
> > repository.
> >
> > Title:          Realizing Network Slices in IP/MPLS Networks Document
> > date:  2021-10-22
> > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-best
> >
> bar-teas-ns-packet-04.txt__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuz
> jP
> > fcHWiz0fJsjai2v-lSVl3xaQ9KStmd-Lrg$
> > <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-best
> >
> bar-teas-ns-packet-04.txt__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuz
> jP
> > fcHWiz0fJsjai2v-lSVl3xaQ9KStmd-Lrg$>
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bes
> >
> tbar-teas-ns-packet/__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfc
> HWi
> > z0fJsjai2v-lSVl3xaQ9KQU8M3gMQ$
> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bes
> >
> tbar-teas-ns-packet/__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzjPfc
> HWi
> > z0fJsjai2v-lSVl3xaQ9KQU8M3gMQ$>
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> >
> t-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzj
> Pf
> > cHWiz0fJsjai2v-lSVl3xaQ9KTdDUsYPg$
> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf
> >
> t-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzj
> Pf
> > cHWiz0fJsjai2v-lSVl3xaQ9KTdDUsYPg$>
> > Diff:
> > https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-be
> >
> stbar-teas-ns-packet-04__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzj
> Pfc
> > HWiz0fJsjai2v-lSVl3xaQ9KTPNaxS1w$
> > <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-be
> >
> stbar-teas-ns-packet-04__;!!NEt6yMaO-gk!RecCLrvG0MzUHLe947Wp0VNPuzj
> Pfc
> > HWiz0fJsjai2v-lSVl3xaQ9KTPNaxS1w$>
> >
> > Abstract:

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 6 Nov 2021 10:32:49 +0000

Hi Pavan,

Thanks for your reply. Please see some further inline:

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Saturday, November 6, 2021 3:13 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Tarek Saad <tsaad=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] New Version Notification for draft-bestbar-teas-ns-packet-04.txt

Jie, Hi!

The narrative in draft-bestbar-teas-ns-packet uses slice aggregate to mean “one or more IETF network slice traffic streams that are given the same forwarding treatment based on some selection criteria”.

[Jie] Thanks for providing further descriptions about slice aggregate, and confirm that it is “one or more IETF network slice traffic streams”. While packets of a flow are also given the same forwarding treatment, and the flow is classified based on some criteria. From this I don’t see the difference between slice flow and slice aggregate.

A slice aggregate is associated with a collection of resources that are used to support it and this collection of resources is referred to as the “Network Resource Partition”.

[Jie] It seems this indicates a 1:1 mapping between slice aggregate and network resource partition. As discussed the mapping between network slice services and the network resource partition can be flexible, it is not quite clear whether the slice aggregate is necessary or helpful in the procedure of mapping network slice services to the network resource partition:

With slice aggregate: the network controller determines the mapping of the network slice service streams to the slice aggregate (1:1, N:1, M:N), then map the slice aggregate to the network resource partition (1:1).

Without slice aggregate: the network controller determines the mapping of the network slice service flows to the network resource partition (1:1, N:1, M:N).

IMHO, “Slice traffic” or “Slice traffic flows” doesn’t capture the above meaning. Please note that there is no change to the semantics of slice aggregate from previous versions of the draft – the only thing that has been added to the narrative is a term (network resource partition) for the collection of resources used to support this aggregate.

[Jie] I agree the definition of slice aggregate in the terminology section is not changed. While there are several places where the slice aggregate is now replaced by network resource partition. For example:

The definition of slice policy in -03 was:

Slice policy:
      a policy construct that enables instantiation of mechanisms in
      support of IETF network slice specific control and data plane
      behaviors on select topological elements; the enforcement of a
      slice policy results in the creation of a slice aggregate.

And the definition of slice policy in -04 is:

Slice Policy:
      a policy construct that enables instantiation of mechanisms in
      support of IETF network slice specific control and data plane
      behaviors on select topological elements; the enforcement of a
      slice policy results in the creation of a Network Resource
      Partition.

This may have caused some confusion about the meaning change of slice aggregate and deserve some clarification. Thanks.

Best regards,
Jie

Regards,
-Pavan

On Fri, Nov 5, 2021 at 10:43 AM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tarek,

Thanks for the update.

To my understanding, this is no more than a collection of packets which will be mapped to a particular network resource partition. In that case, we could simply call it “slice traffic” or “slice traffic flows”.

Do you see anything missing if we simply use “slice traffic” or “slice traffic flows”?

Best regards,
Jie

From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tarek Saad
Sent: Monday, October 25, 2021 10:28 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-04.txt

Hi WG,

This update includes the following:
•       Several nit edits
•       Use of the generic term “Network Resource Partition” to indication the resources on specific link(s)/node(s) that will be traversed by a slice-aggregate
•       New section 3 for “IETF Network Slice Realization”
Regards,
Tarek (for co-authors)

Abstract:

The IETF Secretariat

Juniper Business Use Only
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Tarek Saad <[email-masked]>
Date: Mon, 8 Nov 2021 04:11:34 +0000

Hi Jie,

See below.

>> In previous versions, it was described as the underlay network construct which the IETF network slice service are mapped to. With the introduction of the generic term “Network Resource Partition”,…
[TS]: the “Network Resource Partition” is used to describe the set of resources that are instantiated of specific link/nodes in the network to support the slice aggregate. The slice aggregate definition has not changed and identifies the collection of slice streams/flows (that can share common SLOs and aggregated together) and that traverse the Network Resource Partition. The two terms are distinct, and describe different things and I don’t think removing one will help in any way.

>> Do you see anything missing if we simply use “slice traffic” or “slice traffic flows”?
[TS]: slice aggregate designates a special relation between the select slice traffic flows (as per the definition set in the draft). As you see, we have chosen to refer to the set of select ‘slice traffic flows’ as slice aggregate to distinguish it from any general collection of slice traffic flows.

Regards,
Tarek

From: Teas <[email-masked]> on behalf of Dongjie (Jimmy) <[email-masked]>
Date: Friday, November 5, 2021 at 11:43 AM
To: Tarek Saad <tsaad=[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Teas] New Version Notification for draft-bestbar-teas-ns-packet-04.txt
Hi Tarek,

Thanks for the update.

Best regards,
Jie

Hi WG,

  *   Several nit edits
  *   Use of the generic term “Network Resource Partition” to indication the resources on specific link(s)/node(s) that will be traversed by a slice-aggregate
  *   New section 3 for “IETF Network Slice Realization”
Regards,
Tarek (for co-authors)

Abstract:

The IETF Secretariat