Subject: [Teas] New term for the underlay construct used for slice realization

From: Lizhenbin <[email-masked]>
Date: Tue, 10 Aug 2021 15:21:22 +0000

Hi Folks, 

On the TEAS meeting in IETF 111, it was discussed that a common "new term" will need to be proposed for the underlay construct used for slice realization. 

There have been several related terminologies: 

1.	VTN (Virtual Transport Network)

In the early days of network slicing discussion in IETF, it was suggested that the technology in IETF should be neutral and not bound to network slicing only. Following this approach, the term VTN is defined in the enhanced VPN draft already adopted and progressing in TEAS. It is expected that the VTNs with guaranteed resources can also be applicable to services other than network slices. The VPN+ architecture allows flexible mapping (including 1:1, N:1 and 1:N mapping) between the overlay VPN services and the underlay VTNs. Since VTN is a generic term, in the context of network slicing we may still need a specialized term.

2.	Slice Aggregate

It is claimed that the scope of Slice Aggregate is tied to the scope of IETF network slices. This term implies an aggregation of one or more IETF network slices into an aggregate construct, so that only a 1:1 and N:1 mapping of network slice service to underlay construct can be achieved. However, if this is a mapping of network slice traffic streams to underlay constructs, then it may be possible to map network slice services to the underlay construct as 1:1, N:1 and 1:N, but the name may be confusing because it is not the slices that are aggregated. 

With this background in mind, now we can discuss how to define the new term. Here are some points for the WG to consider:

1.	Should the 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?

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?

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

Your opinion about these candidates are much appreciated. You may also propose other new term if it complies with the above two points.

Best Regards,
Robin

---

From: John E Drake <[email-masked]>
Date: Tue, 10 Aug 2021 19:11:33 +0000

Hi,

Comments inline.

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: Teas <[email-masked]> On Behalf Of Lizhenbin
> Sent: Tuesday, August 10, 2021 11:21 AM
> To: [email-masked]
> Subject: [Teas] New term for the underlay construct used for slice realization
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Folks,
> 
> On the TEAS meeting in IETF 111, it was discussed that a common "new term"
> will need to be proposed for the underlay construct used for slice realization.
> 
> In the early days of network slicing discussion in IETF, it was suggested that the
> technology in IETF should be neutral and not bound to network slicing only.
> Following this approach, the term VTN is defined in the enhanced VPN draft
> already adopted and progressing in TEAS. It is expected that the VTNs with
> guaranteed resources can also be applicable to services other than network
> slices. The VPN+ architecture allows flexible mapping (including 1:1, N:1 and 1:N
> mapping) between the overlay VPN services and the underlay VTNs. Since VTN is
> a generic term, in the context of network slicing we may still need a specialized
> term.

[JD]  I never liked this term because what it is describing is real not virtual and because the IETF does not build transport networks.  I.e., what it is describing is a subset of the underlay network topology with partitioned resources. 

> 
> 2.      Slice Aggregate
> 
> It is claimed that the scope of Slice Aggregate is tied to the scope of IETF
> network slices. This term implies an aggregation of one or more IETF network
> slices into an aggregate construct, so that only a 1:1 and N:1 mapping of
> network slice service to underlay construct can be achieved. However, if this is a
> mapping of network slice traffic streams to underlay constructs, then it may be
> possible to map network slice services to the underlay construct as 1:1, N:1 and
> 1:N, but the name may be confusing because it is not the slices that are
> aggregated.

[JD]  This term never resonated with me because it is slice specific and because, as Adrian pointed out, it's actually used to describe multiple, incompatible ideas.  

> 
> With this background in mind, now we can discuss how to define the new term.
> Here are some points for the WG to consider:
> 
> 1.      Should the 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 

> 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://datatracker.ietf.org/doc/html/draft-drake-bess-enhanced-vpn-06
> 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://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-03.  What this allows
one to build is an 'partitioned underlay network topology'.  

> 
> 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/teas__;!!N
> Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
> O08HqD31TGJciNjuxL2A$

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Aug 2021 15:19:58 -0400

While I mostly agree with John's descriptions below, I am a bit 
concerned by the suggestion of "partition".  While some of the use cases 
seem to be describable as partitions, not all of them are.  In general, 
what I have observed when combining statistical multiplexing with 
traffic engineering we rarely want true partitioning.

Yours,
Joel

On 8/10/2021 3:11 PM, John E Drake wrote:
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: John E Drake <[email-masked]>
Date: Tue, 10 Aug 2021 19:45:00 +0000

Joel,

I had envisioned that a node would be configured to create a *small* number of partitions, i.e.,  a subset of buffer/queuing/scheduling resources, either for each of its links or for specific subsets of its links.  The former would be for adjacency SIDs and the latter would be for loopback SIDs, and it is done in support of enhanced DiffServ support for a multiplicity of overlay services.

I had researched terms and 'partition' is used in the sense of "divide into parts", but I would amenable another term.

Yours Irrespectively,

John

> From: Joel M. Halpern <[email-masked]>
> Sent: Tuesday, August 10, 2021 3:20 PM
> To: John E Drake <[email-masked]>; Lizhenbin <[email-masked]>;
> [email-masked]
> Subject: Re: [Teas] New term for the underlay construct used for slice realization
> 
> While I mostly agree with John's descriptions below, I am a bit concerned by the
> suggestion of "partition".  While some of the use cases seem to be describable
> as partitions, not all of them are.  In general, what I have observed when
> combining statistical multiplexing with traffic engineering we rarely want true
> partitioning.
> 
> Yours,
> Joel
> 
> >> In the early days of network slicing discussion in IETF, it was
> >> suggested that the technology in IETF should be neutral and not bound to
> network slicing only.
> >> Following this approach, the term VTN is defined in the enhanced VPN
> >> draft already adopted and progressing in TEAS. It is expected that
> >> the VTNs with guaranteed resources can also be applicable to services
> >> other than network slices. The VPN+ architecture allows flexible
> >> mapping (including 1:1, N:1 and 1:N
> >> mapping) between the overlay VPN services and the underlay VTNs.
> >> Since VTN is a generic term, in the context of network slicing we may
> >> still need a specialized term.
> >
> > [JD]  I never liked this term because what it is describing is real not virtual and
> because the IETF does not build transport networks.  I.e., what it is describing is
> a subset of the underlay network topology with partitioned resources.
> >
> >>
> >> 2.      Slice Aggregate
> >>
> >> It is claimed that the scope of Slice Aggregate is tied to the scope
> >> of IETF network slices. This term implies an aggregation of one or
> >> more IETF network slices into an aggregate construct, so that only a
> >> 1:1 and N:1 mapping of network slice service to underlay construct
> >> can be achieved. However, if this is a mapping of network slice
> >> traffic streams to underlay constructs, then it may be possible to
> >> map network slice services to the underlay construct as 1:1, N:1 and
> > [JD]  This term never resonated with me because it is slice specific and
> because, as Adrian pointed out, it's actually used to describe multiple,
> incompatible ideas.
> >
> >>
> >> 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
> >
> >>
> >> 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/draft-
> drake-bess-enhanced-vpn-06__;!!NEt6yMaO-
> gk!Ubt8CeRLiBJyysk0y3SWyeTmPLOdiveVP3mNYpK9om7TGjgCYKItQNRec87D8y
> M$
> >>
> >> 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/draft-ietf-
> spring-resource-aware-segments-03__;!!NEt6yMaO-
> gk!Ubt8CeRLiBJyysk0y3SWyeTmPLOdiveVP3mNYpK9om7TGjgCYKItQNReINcGLl
> Q$ .  What this allows one to build is an 'partitioned underlay network topology'.
> >
> >>
> >> Your opinion about these candidates are much appreciated. You may
> >> also propose other new term if it complies with the above two points.
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-
> gk!Ubt8CeRLiBJyysk0y3SWyeTmPLOdiveVP3mNYpK9om7TGjgCYKItQNReQwgX
> MbU$
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Aug 2021 15:48:56 -0400

I tend to be bad at naming things....
Could we use "allocation"  or "utilization"?  I agree that we want to 
talk about providing small sets of resources to meet needs.

Yours,
Joel

---

From: <[email-masked]>
Date: Wed, 11 Aug 2021 05:12:52 +0800 (CST)

Hi Robin,

thank you for starting the discussion. Please find my notes in-lined below under the GIM>> tag.

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: Lizhenbin
To: [email-masked];
Date: 2021/08/10 08:21

Hi Folks,  

 

GIM>> I think that when at IETF we refer to a network as transport, that implies that the one of defined at IETF transport protocols, e.g., TCP, UDP, SCTP, or DCCP, is used. As I understand the VPN+ proposal, that is not the case. If that is correct, then before using VTN, need to define what is the interpretation of "transport".

2.    Slice Aggregate

GIM>> I think that it is beneficial not to use "slice" in the term that identifies an object in the underlay network that provides service to a slice. See more on that below.

    Should the 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?

GIM>> Yes to the latter (that is why calling it "Slice Aggregate" might be confusing)

GIM>> Strictly speaking, I don't see how an answer to one of questions listed in #1 can be "No". But that's OK.

 GIM>> Yes to all.

 

GIM>> I think that the term used for underlay resources delegated to a particular slice should not refer to "slice".

 
 
Best Regards,
Robin

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 11 Aug 2021 02:43:59 +0000

Hi Robin, 

Thanks for the summary of the background and the analysis about the characteristics of the underlay construct for slice realization, please see my comments inline:

> From: Teas [mailto:[email-masked]] On Behalf Of Lizhenbin
> Sent: Tuesday, August 10, 2021 11:21 PM
> To: [email-masked]

[Jie] I'm OK with defining a new term specialized for the context of network slice realization, as we already have a neutral term for generic purpose. 

> in a single network slice service to carry them in different underlay constructs?

Yes to all. For the 1:N mapping in c, some further analysis about the use cases could be helpful. 

> propose other new term if it complies with the above two points.

[Jie] For slice specific new terms, here are some other candidates: 

Option 3: The network slice service is called "network slice", the underlay construct is called "SUN (Slice Underlay Network)"

Option 4: The network slice service is called "network slice", the underlay construct is called "SRN (Slice Resource Network)"

Option 5: The network slice service is called "network slice", the underlay construct is called "STN (Slice Transport Network or Slice TE Network)"

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 11 Aug 2021 03:03:22 +0000

Hi John, 

Please see inline:

> From: Teas [mailto:[email-masked]] On Behalf Of John E Drake
> Sent: Wednesday, August 11, 2021 3:12 AM
> To: Lizhenbin <[email-masked]>; [email-masked]
> > draft already adopted and progressing in TEAS. It is expected that the
> > VTNs with guaranteed resources can also be applicable to services
> > mapping) between the overlay VPN services and the underlay VTNs. Since
> > VTN is a generic term, in the context of network slicing we may still
> > need a specialized term.
> 
> because the IETF does not build transport networks.  I.e., what it is describing
> is a subset of the underlay network topology with partitioned resources.

Since a VTN comprises a subset of the underlay network topology and a set of partitioned resources allocated from the physical network, my understanding is that itself is not a physical network. And since multiple VTNs can be created based on the same physical network, this can be considered as some level of virtualization of the network infrastructure. This is analogous to the VM (Virtual Machine) which is allocated with a subset of the resources from the physical server. 

I agree the term "transport" has always been controversial, our intent was to find a key word to refer to the underlay network and distinguish it from the overlay virtual networks. 

Alternatively, the letter "T" in VTN may be interpreted as "TE".

> > 1:1 and N:1 mapping of network slice service to underlay construct can
> > be achieved. However, if this is a mapping of network slice traffic
> > streams to underlay constructs, then it may be possible to map network
> > slice services to the underlay construct as 1:1, N:1 and 1:N, but the
> > name may be confusing because it is not the slices that are aggregated.
> 
> [JD]  This term never resonated with me because it is slice specific and because,
> as Adrian pointed out, it's actually used to describe multiple, incompatible ideas.
> 
> >

[Jie] I guess you mean "Yes" to the latter case, which is "it should be generalized for more possible uses", is my understanding correct?

> https://datatracker.ietf.org/doc/html/draft-drake-bess-enhanced-vpn-06
> >
> [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.
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segmen
> 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. 

Best regards,
Jie

> > __;!!N

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 11 Aug 2021 04:04:14 +0000

Hi Greg,

Please see some replies inline:

From: Teas [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, August 11, 2021 5:13 AM
To: Lizhenbin <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas] New term for the underlay construct used for slice realization

Hi Robin,

Regards,

Greg Mirsky

E: [email-masked]<mailto:[email-masked]>
www.zte.com.cn<http://www.zte.com.cn/>

Original Mail
Sender: Lizhenbin
To: [email-masked]<mailto:[email-masked]>;
Date: 2021/08/10 08:21
Subject: [Teas] New term for the underlay construct used for slice realization
Hi Folks,

[Jie] Please see my replies to John about the term VTN. Here “transport” was used to refer to the underlay network in contrast to the overlay virtual networks. Another possible interpretation of VTN could be “Virtual TE Network”.

Best regards,

Jie

2.    Slice Aggregate

GIM>> Yes to all.

Best Regards,
Robin

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

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Aug 2021 12:38:05 +0000

Jimmy,

Snipped, comments inline.

Yours Irrespectively,

John

> From: Dongjie (Jimmy) <[email-masked]>
> Sent: Tuesday, August 10, 2021 11:03 PM
> Subject: RE: New term for the underlay construct used for slice realization
> 
underlay construct for network slice realization bound to
> [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 

> > 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$
> > >
> > 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.
> > 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'

> > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
> ROxL4C2
> > _xNDCrPaNQ$

---

From: "Kiran Makhijani" <[email-masked]>
Date: Wed, 11 Aug 2021 14:59:47 +0000

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

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Aug 2021 15:33:06 +0000

Hi,

comments inline.

Yours Irrespectively,

John

> From: Kiran Makhijani <[email-masked]>

> Sent: Wednesday, August 11, 2021 11:00 AM

> To: John E Drake <[email-masked]>; Dongjie (Jimmy)

> <[email-masked]>; Lizhenbin <[email-masked]>; [email-masked]

> Subject: Re[2]: [Teas] New term for the underlay construct used for slice

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

[JD]  If you are referring to an IETF Network Slice Service, by definition it has no underlay network resource awareness.

> 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?

[JD]  We provide overlay services, including but not limited to, IETF Network Slice Services over a common underlay network.

> abstraction (for realization). It could be underlay/overlay or aggregate/??.

[JD]  This has been integral to the IETF network slice work from its inception.

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

[JD]  There is a set of IETF Network Slice Services which are mapped to a set of partitioned underlay network topologies (or whatever term on which we decide), as are other overlay network services.

> Use of underlay/overlay are confusing.

[JD] I'm sorry.  This has been  IETF and industry standard terminology for years.

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

[JD]  As I noted to Joel,  resource partitions are an optional tool that enables enhanced DiffServ support for a multiplicity of overlay services.  I.e., it is not IETF Network Slice Service-specific.

> 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]>>

> >>  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]>

> >>  Subject: RE: New term for the underlay construct used for slice

> >>  > > network slice services? That is, is the underlay construct only

> >> for  > > use in network slicing, or should it be generalized for more possible

> uses?

> >>  [Jie] I guess you mean "Yes" to the latter case, which is "it should

> >> be generalized  for more possible uses", is my understanding correct?

> >>  > > 2.      If the answer to question 1 is YES, should it reflect the following

> >>  > > characteristics?

> >>  > > 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?

> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/dra>

> >> f  > t-drake-bess-enhanced-vpn-06__;!!NEt6yMaO-

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

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

> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/dra>

> >> f  > t-ietf-spring-resource-aware-segmen__;!!NEt6yMaO-

> >>  [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'

> >>  > > Your opinion about these candidates are much appreciated. You

> >> may  > > also propose other new term if it complies with the above two

> points.

> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te>

> >>  > > as

> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/tea>

> >> s  > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-

> >https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas_<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas_>

> >_;!!NEt6yMaO-

> gk!SCERgAZ566ZJbmstSAXS9FCSjdfU15Z795qJU4cO3Z4kXx8JLdcPEdSp4VsBkqM$

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 Aug 2021 20:37:49 +0100

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)

Hi John, (and all),

Thanks
Kiran

------ Original Message ------
From: "John E Drake" <jdrake=[email-masked]>
To: "Dongjie (Jimmy)" <[email-masked]>; "Lizhenbin" 

realization
>>  > > b.      It is about the partitioned resources used to deliver the
network slice
network
construct.

---

From: <[email-masked]>
Date: Thu, 12 Aug 2021 05:44:33 +0800 (CST)

Hi Adrian,

I think you've done a brilliant analysis making it all so clear. I fully agree with it and also had a minor discomfort with "partition". I like "group" or "grouping", but will be merry with any other.

Regards,

Greg Mirsky

Original Mail

Sender: AdrianFarrel
To: 'Kiran Makhijani';'John E Drake';'Dongjie (Jimmy)';'Lizhenbin';[email-masked];
Date: 2021/08/11 12:38
Subject: Re: [Teas] New term for the underlay construct used for slice realization

 

 

 

 

 

 
 
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)
 
Hi John, (and all),

 
Thanks
Kiran

------ Original Message ------
From: "John E Drake" <jdrake=[email-masked]> 
To: "Dongjie (Jimmy)" <[email-masked]>; "Lizhenbin"  
 
realization
network slice
network
construct.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Aug 2021 19:41:12 -0400

+1

On Wed, Aug 11, 2021 at 5:44 PM <[email-masked]> wrote:

> Hi Adrian,
>
> I think you've done a brilliant analysis making it all so clear. I fully
> agree with it and also had a minor discomfort with "partition". I like
> "group" or "grouping", but will be merry with any other.
>
>
> Regards,
>
> Greg Mirsky
>
>
> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
> Institute/Wireline Product Operation Division
>
>
>
> *Sender: *AdrianFarrel
> *To: *'Kiran Makhijani';'John E Drake';'Dongjie (Jimmy)';'Lizhenbin';
> [email-masked];
> *Date: *2021/08/11 12:38
> *Subject: **Re: [Teas] New term for the underlay construct used for slice
> realization*
> >>  To: John E Drake <[email-masked]>; Lizhenbin <[email-masked]
> >;
> >>[email-masked]
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: "Kiran M" <[email-masked]>
Date: Thu, 12 Aug 2021 00:28:20 +0000

Hi Adrian,
Thank you for breaking it down clearly. It helped me see the delta due 
to use of term 'IETF network slice service’ instead of just slice.

In this 4-tier architecture (for the sake of convenience), few things 
could be documented after clarification:

1) is it mandatory that operator must have an 'IETF Network slice 
instance' to realize an IETF network slice service?
   - One of the things we discussed early on was that it should be 
possible to map a customer’s network slice request even when the 
operator does not have slice-infrastructure. This is why Southbound 
interface had lot of discussions on using existing data models. Should 
we  now redefine what a SBI would be? Is it between 2nd and 3rd tier? 
Should architecture allow 1st to 3rd? Since resource-partitioning is an 
important part of slices should we name the interface between 3rd to 4th 
tier?

2) in order to scale the slices, hierarchical slices were defined. The 
stitching could be done horizontally or vertically over the 
resource-partitions. are they still needed in this architecture.

In my mind, what you call a resource partition is nothing but an 
abstraction of connected network resources (vaguely resembles the 
definition of slice, isn’t it?). What happens above that is an 
orchestration on different slice segments to produce the desired 
effects.

So I think, with this architecture we would need to clean up/edit the 
text on 3 items in the document - SBI, optionality of 2nd tier (if you 
agree - related to your 4c/d/e), section on hierarchical structure.

Thanks
Kiran

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Aug 2021 20:59:42 -0400

Hi Adrian

Excellent job breaking this down and making it clear to all of us!!

The term partition is strong as I agree it implies underlay resources that
are not shared, however group sounds like a perfect.

Pool goes to far in the other direction as if all resources are shared.

Bundle I think is at about the same as far as right context in line with
group implying shared resources.

However I think from a nomenclature perspective I like group better.

Kind Regards

Gyan

On Wed, Aug 11, 2021 at 8:28 PM Kiran M <[email-masked]> wrote:

> for
> be
> >generalized
> be
> then
> then
> considering
> >>>   > network resources in support of various overlay services such as
> IETF
> >Network
> >>>   Slice Services.
> 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
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Aug 2021 11:10:15 +0100

Hi Kiran,

You make an important observation about functional architectures. I recall having a similar discussion back in around 2004 in Geneva as we worked on G.7712 and associated Recommendations.

The points are:
- Functional components do not need to be implemented as separate
   software components.
- Where functional components are bundled together in software, they
   do not need to implement the formal functional interfaces between
   the functional components.
- Where a function is "not needed" in an implementation or deployment
   it may be present as a "null" or "pass-through" function, but it actually
   doesn't need to be present at all.

Thus, while it is possible to treat a functional architecture as a high level design for a software implementation, it may not necessarily be the best approach.

Now, to your specific points...

> instance' to realize an IETF network slice service?

As above, no it is not mandatory. Just as in L3VPN, an operator could map direct from a VPN service request at the NBI (using L3SM) to programming of the forwarding plane.

>   important part of slices should we name the interface between 3rd to
>   4th tier?

Well, let's be really careful about the term "SBI". Southbound to what?
An Orchestrator may have an SBI to a Network Slice Controller.
A Network Slice Controller may an SBI to a Network Controller.
And a Network Controller may have an SBI to the devices.
draft-contreras-teas-slice-controller-models may give some good context for this.

I'm setting aside "even when the operator does not have slice-infrastructure" since I don't know what it means. But I will say that it entirely possible for an operator to map direct from an IETF Network Slice Service request to "programming" the data plane. I believe that is possible with this 4-layer functional model. Furthermore, I believe the functional model allows any or all forms of "pass-through". That is, to repeat myself, it is a functional model not a mandatory implementation guide (notwithstanding RFC 8962, there is no Protocol Police!).

>   resource-partitions. are they still needed in this architecture.

Architectures are recursive. That recursion may be transparent or visible. Hierarchical slicing "comes for free".

Lateral stitching of slices is, of course, more complicated because it requires coordination between adjacent "domains". But the architecture should easily allow this.

> orchestration on different slice segments to produce the desired 

"Orchestration" is a key word.

I think "vaguely resembles the definition of a slice" is not completely a surprise because what is going on is a marshalling of resources to support a slice.

Is it an abstraction? No! It is actually the identification of specific resources. I think the network slice, itself, (the 2nd layer down) is the abstraction.

> agree - related to your 4c/d/e), section on hierarchical structure.

I agree that cleaning of text is what this is all about. A lot of the text is still in its inherited form and needs work.
Currently the document mainly uses "SBI" to mean the device-facing interface. But it also talks about the "NSC SBI", I find the term SBI over-used, and I think we can tidy that up.
Yes, it should be clear about the fact that this is a functional architecture and that you don't have to implement it like that.
Yes we should have some text (although probably not a lot) on the fact that you can recurse the architecture and that you can orchestrate and stitch across adjacent domains/networks.

Cheers,
Adrian

---

From: "Luis M. Contreras" <[email-masked]>
Date: Thu, 12 Aug 2021 13:30:14 +0200

Hi all,

as pointed out by Adrian, draft-contreras-teas-slice-controller-models
already contain some details in line with this 4 layering proposal. In
figure 2 of the draft it is proposed the following functional architecture.

                                    Higher Level System
                                             |
                                             |
                                ---------------------------
                                | NSC        | (a)        |
                                |            v            |
                                |   -------------------   |
                                |   |                 |   |
                                |   |    NS Mapper    |   |
                                |   |                 |   |
                                |   -------------------   |
                                |            | (b)        |
                                |            v            |
                                |   -------------------   |
                                |   |                 |   |
                                |   |    NS Realizer  |   |
                                |   |                 |   |
                                |   -------------------   |
                                |            | (c)        |
                                ---------------------------
                                             |
                                             v
                                    Network Controllers

In my view, this is the relation with the 4 layering:

IETF network slice service (customer view) --> (a) in the figure, as NBI of
the IETF NSC and input to the NS Mapper

IETF network slice (operator view) --> (b) in the figure, as input to the
NS Realizer

Resource partition (delivery mechanism) --> (c) in the figure, as NBI to
the different Network Controllers involved in the realization of an IETF
Network Slice

Underlay network (network used to support the slice) --> not represented in
the figure, being the networks under control of the Network Controllers
mentioned before

I think this is a consistent view.

Best regards

Luis

El jue, 12 ago 2021 a las 12:10, Adrian Farrel (<[email-masked]>)
escribió:

> Hi Kiran,
>
> You make an important observation about functional architectures. I recall
> having a similar discussion back in around 2004 in Geneva as we worked on
> G.7712 and associated Recommendations.
>
> The points are:
> Thus, while it is possible to treat a functional architecture as a high
> level design for a software implementation, it may not necessarily be the
> best approach.
>
> As above, no it is not mandatory. Just as in L3VPN, an operator could map
> direct from a VPN service request at the NBI (using L3SM) to programming of
> the forwarding plane.
>
> I'm setting aside "even when the operator does not have
> slice-infrastructure" since I don't know what it means. But I will say that
> it entirely possible for an operator to map direct from an IETF Network
> Slice Service request to "programming" the data plane. I believe that is
> possible with this 4-layer functional model. Furthermore, I believe the
> functional model allows any or all forms of "pass-through". That is, to
> repeat myself, it is a functional model not a mandatory implementation
> guide (notwithstanding RFC 8962, there is no Protocol Police!).
>
> Lateral stitching of slices is, of course, more complicated because it
> requires coordination between adjacent "domains". But the architecture
> should easily allow this.
>
> I think "vaguely resembles the definition of a slice" is not completely a
> surprise because what is going on is a marshalling of resources to support
> a slice.
>
> Is it an abstraction? No! It is actually the identification of specific
> resources. I think the network slice, itself, (the 2nd layer down) is the
> abstraction.
>
> I agree that cleaning of text is what this is all about. A lot of the text
> is still in its inherited form and needs work.
> Currently the document mainly uses "SBI" to mean the device-facing
> interface. But it also talks about the "NSC SBI", I find the term SBI
> over-used, and I think we can tidy that up.
> Yes, it should be clear about the fact that this is a functional
> architecture and that you don't have to implement it like that.
> Yes we should have some text (although probably not a lot) on the fact
> that you can recurse the architecture and that you can orchestrate and
> stitch across adjacent domains/networks.
>
> Cheers,
> Adrian
>
>

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: Tarek Saad <[email-masked]>
Date: Thu, 12 Aug 2021 14:41:01 +0000

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.

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)

Hi John, (and all),

Thanks
Kiran

------ Original Message ------
From: "John E Drake" <jdrake=[email-masked]>
To: "Dongjie (Jimmy)" <[email-masked]>; "Lizhenbin"

realization
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>
>>  > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf>
construct.
>>  > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Aug 2021 16:04:39 +0100

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.

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

"Network resource aggregate" would imply that resources have been collected
together to be used as a single entity. 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] <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

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
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> 
>>  > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf> 
construct.
>>  > > [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> 
>>  > [email-masked] <mailto:[email-masked]> 
<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas> 
>[email-masked] <mailto:[email-masked]> 

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

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

---

From: "Kiran M" <[email-masked]>
Date: Thu, 12 Aug 2021 15:57:44 +0000

Great, look forward to the revised text.

The reason for ‘vaguely resembles slice’ is to influence a different 
kind of thinking that this is the lowest level of a slice, everything is 
built using those - either recursively or hierarchically. I still prefer 
hierarchical over recursion since slices have specific outcomes and 
over-generalization is not necessary, but it is not as important and I 
wouldn’t care either way.

Thanks again,
Kiran

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 12 Aug 2021 12:32:04 -0500

** 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:

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

>
>
> 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,
> *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.
>
> 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.
>
>
>
> 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
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 13 Aug 2021 12:11:28 +0000

Hi John, 

Thanks for your clarification. I think we are mostly aligned. 

My hope is the new term could reflect the two basic attributes of the underlay construct: partitioned resource and a (sub-)topology.

Best regards,
Jie

> Sent: Wednesday, August 11, 2021 8:38 PM
> To: Dongjie (Jimmy) <[email-masked]>; Lizhenbin
> <[email-masked]>; [email-masked]
> > To: John E Drake <[email-masked]>; Lizhenbin
> > <[email-masked]>; [email-masked]
> > > > for use in network slicing, or should it be generalized for more possible
> uses?
> > >
> > > [JD] Absolutely yes
> >
> > > > 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?
> > >
> > > > then the underlay construct is called "underlay slice".
> > > >
> > > > then the underlay construct is called "resource slice".
> > >
> > > considering the term 'resource partition' to describe the
> > > partitioning of underlay network resources in support of various
> > 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.
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 13 Aug 2021 13:20:15 +0000

Hi Pavan,

Sorry for chiming in, please see some comments inline:

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,

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.

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"

>>  To: John E Drake <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>;
>>[email-masked]<mailto:[email-masked]>
realization
network slice
network
construct.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Aug 2021 09:29:51 -0400

If, as per the bestbar draft and the discussion of VTN-ID on 6man, this 
construct is NOT a forwarding construct, then I do not see how it 
identifies a sub-topology.   It needs to be tied to a topology where it 
is supported.  But since it is not the forwarding construct, it doesn't 
need to identify that topology as far as I can tell.

Yours,
Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 13 Aug 2021 15:52:41 +0000

Hi Joel,

Since usually the set of resources are allocated on a subset of the nodes and links in the underlay network, there is a need to specify the sub-topology on which the resources are allocated. That's why we say "VTN is associated with a logical topology", and it aligns with what you said "it needs to be tied to a topology where it is supported". So, I hope we agree that it is "a set of resources provisioned in a sub-topology". 

And I agree we don't need to introduce a new topology identifier. There are well-defined mechanisms (e.g. MT, Flex-Algo) to specify the sub-topology, and it just need to refer to an existing "topology identifier".

As for "it is not a forwarding construct", may I know your definition of "forwarding construct"? To me the resources are allocated in the forwarding plane, thus it should be considered as a "forwarding construct". Please note this is a general discussion about the functionality of this construct, which can be applicable to different data plane encapsulations.

Best regards,
Jie

> From: Teas [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Friday, August 13, 2021 9:30 PM
> To: Dongjie (Jimmy) <[email-masked]>; [email-masked]
> is supported.  But since it is not the forwarding construct, it doesn't need to
> identify that topology as far as I can tell.
> 
> Yours,
> Joel
> 
> > My hope is the new term could reflect the two basic attributes of the
> underlay construct: partitioned resource and a (sub-)topology.
> >
> > Best regards,
> > Jie
> >
> >>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/d
> >>>> r
> >>>> af
> >>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/d
> >>>> r
> >>>> af
> >>> on a single node or link) in the physical network, which together
> >>> builds a logical
> >> network topology.
> >>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Aug 2021 12:01:32 -0400

I was using "forwarding construct" in the sense of "the information that 
determines where to send the packet."  (I will grant it is a bit fuzzy. 
  The Forwarding construct can select a group, adn non-forwarding 
information may be used within that, such as the 5-tuple.)

The point I am concerned with, that I believe you have confirmed below, 
is that the resource information does not determine the forwarding path 
(although there needs to be a suitable relationship as you say).  It, 
like the five-tuple and the DSCP, is concerned with what resources are 
sued to forward once the path is selected.

Yours,
Joel

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 13 Aug 2021 17:43:29 +0000 (UTC)

I agree with Tarek and Pavan. For example, if a TE LSP carries N services, a transit nodec N of said LSP  interprets the top label in the stack as said services aggregate. The number and identity of the services is not important. What is important is the forwarding treatment of so labeled packets .
Cheers,Igor

Sent from Yahoo Mail on Android 
 
  On Fri, Aug 13, 2021 at 12:01 PM, Joel M. Halpern<[email-masked]> wrote:   I was using "forwarding construct" in the sense of "the information that 
determines where to send the packet."  (I will grant it is a bit fuzzy. 
  The Forwarding construct can select a group, adn non-forwarding 
information may be used within that, such as the 5-tuple.)

Yours,
Joel

---

From: <[email-masked]>
Date: Sat, 14 Aug 2021 11:38:23 +0800 (CST)

Hi Joel,

IMO, the traditional five-tuple and DSCP may be not enough for more refined traffic identification, the reason has been described in section 3.1 of https://www.ietf.org/archive/id/draft-peng-teas-network-slicing-04.txt

If a slice-realted identifier is neccessary introduced in the management/control/forwarding plane, then I think SA-ID defined in https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/  contains all concepts that VTN-ID want to express, see below:
1) SA-ID defined the concept of multple slice streams mapping to a single slice-aggregate, multiple slice-aggregates mapping to a single IGP MT/Flex-algo, while VTN-ID just defined the concept of one slice mapping to one VTN-ID, and multiple VTN-ID mapping to a single IGP MT/Flex-algo. 
2) SA-ID defined the concept of customized topology and referrenced topology, for customized mode  it can use affinity rules or SA-ID directly (so that it is nature to support inter-domian case and other limited scenerias that referrence mode is impossible), for referrenced mode it can referr to IGP MT/Flex-algo and TE topology, while VTN-ID just defined the concept of VTN-ID refferring to IGP MT/Flex-algo. 
3) SA-ID defined the concept of SA-ID related flow distinciton, such as SA-ID related SIDs allocation,  GISS carried in packets, while VTN-ID just defined the concept of VTN-ID carried in packets.

Perhaps, for the above gap, the drafts related to VTN has been updated or is being updated, but we SHOULD respect the originality, such as the discussion in https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/

Regards
PSF

------------------原始邮件------------------
发件人：JoelM.Halpern
收件人：Dongjie (Jimmy);[email-masked];
日 期 ：2021年08月14日 00:02
主 题 ：Re: [Teas] New term for the underlay construct used for slice realization
I was using "forwarding construct" in the sense of "the information that
determines where to send the packet."  (I will grant it is a bit fuzzy.
The Forwarding construct can select a group, adn non-forwarding
information may be used within that, such as the 5-tuple.)

Yours,
Joel

---

From: John E Drake <[email-masked]>
Date: Mon, 16 Aug 2021 12:53:25 +0000

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

Hi Pavan,

Adrian, Hi!

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

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

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

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

Adrian

Hi Adrian/all,

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

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)

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"

realization
network slice
network
construct.
>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$>

---

From: Lizhenbin <[email-masked]>
Date: Mon, 16 Aug 2021 16:04:32 +0000

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]>; [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,

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,

Adrian, Hi!

Best regards,
Jie

Adrian

Hi Adrian/all,

Regards,
Tarek

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)

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"

realization
network slice
network
construct.

---

From: John E Drake <[email-masked]>
Date: Mon, 16 Aug 2021 16:41:32 +0000

Greg,

In our definition of resource partition we were planning to stipulate that resource partitions are work conserving (https://en.wikipedia.org/wiki/Work-conserving_scheduler).

Yours Irrespectively,

John

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Wednesday, August 11, 2021 5:45 PM
To: [email-masked]
Cc: [email-masked]; John E Drake <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re:[Teas] New term for the underlay construct used for slice realization

Hi Adrian,

Regards,

Greg Mirsky

www.zte.com.cn<https://urldefense.com/v3/__http:/www.zte.com.cn/__;!!NEt6yMaO-gk!T3onPdUlXAGP4OCEvOR2Tpm_062N_bbqWOGGQCmyaZ4nbi7snLs1KESA1sA4He4$>

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)

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"

realization
network slice
network
construct.

---

From: 龚立艳 <[email-masked]>
Date: Tue, 17 Aug 2021 16:48:00 +0800 (CST)

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/

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

 

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]> [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,

 

Yours Irrespectively,

John

 

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

 

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]> Cc: Tarek Saad <[email-masked]> TEAS WG <[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).

 

 

 

 

 

 

 

 

 

 

 

 

Best regards,

Jie

 

 

 

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

 

 

Adrian

From: Tarek Saad <[email-masked]> Sent: 12 August 2021 15:41 To: [email-masked] 39Kiran Makhijani39 <[email-masked]> 39John E Drake39 <jdrake=[email-masked]>  39Dongjie (Jimmy)39 <[email-masked]> 39Lizhenbin39 <[email-masked]> [email-masked] Subject: Re: [Teas] New term for the underlay construct used for slice realization

Hi Adrian/all,

 

 

 

Regards,

Tarek

 

From: Teas <[email-masked]> on behalf of Adrian  Farrel <[email-masked]> Date: Wednesday, August 11, 2021 at 3:38 PM To: 39Kiran Makhijani39 <[email-masked]>, 39John E Drake39 <jdrake=[email-masked]>,  39Dongjie (Jimmy)39 <[email-masked]>, 39Lizhenbin39 <[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 customer39s 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 operator39s 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 operator39s 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 operator39s 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 doesn39t 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 don39t compel implementations to adhere to that type of architecture. So I don39t 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 can39t decide whether it is helpful to spend time saying why I don39t like each of the proposed terms. I certainly have things I don39t 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 don39t 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 39IETF network slice service39 and the 39IETF slice realization39 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 39slice aggregate39 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 >>  > 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 don39t think we need another term for what we are already >>  > calling an 39IETF Network Slice Service39.  Adrian and I are considering >>  > the term 39resource partition39 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 >>  > t-ietf-spring-resource-aware-segmen__!!NEt6yMaO- >>  gk!TCiJHCZCwFgwpuFouj >>  > xVlZ4r9F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNxEfwaXg$ >>  > ts-03.  What this allows one to build is an 39partitioned underlay >>  > network topology39. >> >>  [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 39partitioned underlay network topology39 > >> >>  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 >>  > > as >>  > > __!!N >>  > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI- >>  > > O08HqD31TGJciNjuxL2A$ >>  > >>  > _______________________________________________ >>  > Teas mailing list >>  > [email-masked] >>  > 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 _______________________________________________ Teas mailing list [email-masked] https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list [email-masked] https://www.ietf.org/mailman/listinfo/teas

_______________________________________________ Teas mailing list [email-masked] https://www.ietf.org/mailman/listinfo/teas

---

From: Lizhenbin <[email-masked]>
Date: Tue, 17 Aug 2021 14:28:55 +0000

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]>; 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，

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\\)<file:///\\(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

Best Regards,
Robin

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]>>

Hi,

Yours Irrespectively,

John

Hi Pavan,

Adrian, Hi!

Best regards,
Jie

Adrian

Hi Adrian/all,

Regards,
Tarek

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)

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"

realization
network slice
network
construct.

---

From: Tarek Saad <[email-masked]>
Date: Tue, 17 Aug 2021 11:37:18 -0400

Hi all,

Indeed, this is inline to my previous email (and definition of slice aggregate in bestbar draft). The aggregate is for the collection of network streams (e.g. network slice connection streams) that can use the network resources allotted for this aggregate. In this sense there are two things:

1) the group of streams of similar SLA requirements that are grouped together (aggregate)
2) the network resources that are allotted to be used by aggregates

For grouping (2), the term identifies the resources on multiple network elements for use by this group. For this, I favour “network resource group” but can live with “network resource partition”. 

Regards,
Tarek

> On Aug 16, 2021, at 8:53 AM, John E Drake <[email-masked]> wrote:
> 
> 
> Hi,
>  
> To: Adrian Farrel <[email-masked]>
> To: [email-masked]; 'Kiran Makhijani' <[email-masked]>; 'John E Drake' <jdrake=[email-masked]>; 'Dongjie (Jimmy)' <[email-masked]>; 'Lizhenbin' <[email-masked]>; [email-masked]

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 17 Aug 2021 11:11:08 -0500

Adrian, Hi!

In the definition above, Is “resource partition” a collection of “items”
that are marked within the network for “exclusive” use by a set of network
slice traffic flows (slice aggregate)? Or can multiple slice aggregates use
the same resource partition?

Regards,

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Aug 2021 17:57:32 +0100

Hi Pavan,

> ** As a WG participant.. **

** As a humble servant of the WG and pen-holder for the document **

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

> In the definition above, Is “resource partition” a collection of “items” that are

> marked within the network for “exclusive” use by a set of network slice traffic

> flows (slice aggregate)? Or can multiple slice aggregates use the same resource

> partition?

I see that you have determined to introduce a separation between the concept you call a “slice aggregate” and the resources used by that thing.

I, on the other hand, had considered that the “resource partition” is the set of resources available for / used by the collection of slice flows, and that there is no need to introduce a separate construct. That is, in one hand you have a set of slices each comprised of one or more traffic flows, and in the other hand you have a network. You map one to the other by associating slice flows with the resources they can use. 

There could be a debate about “resource sharing”. That is, when resources in one partition are not being used, can they be “borrowed” by another partition? I suppose the answer is yes, but I wonder how both slices can guarantee the service SLAs if the resources they use are not guaranteed to be available. This is considerably different from borrowing resources for best effort traffic, which can happen in any resource reservation scheme.

Regards,

Adrian (as a humble WG participant and pen-holder for the document)

> -Pavan (as a WG participant)

On Wed, Aug 11, 2021 at 2:38 PM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

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:[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:[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]> >;
realization
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> 
>>  > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf> 
construct.
>>  > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te> 
>>  > > as
>>  > > __;!!N
>>  > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 17 Aug 2021 13:51:28 -0500

Thanks for the humble clarification! :)

I understand that you don't want to put a name to the "collection of slice
flows" that are mapped to (and use) a specific network resource partition
(or group or pool).

But I do want to ensure that the scope of the network resource partition is
clearly articulated. I interpreted your response as there being a
one-to-one mapping between the "network resource partition" and the
"collection of slice flows" using it.

Thanks,
-Pavan (WG participant)

On Tue, Aug 17, 2021 at 11:57 AM Adrian Farrel <[email-masked]> wrote:

> that are
> I see that you have determined to introduce a separation between the
> concept you call a “slice aggregate” and the resources used by that thing.
>
>
>
> I, on the other hand, had considered that the “resource partition” is the
> set of resources available for / used by the collection of slice flows, and
> that there is no need to introduce a separate construct. That is, in one
> hand you have a set of slices each comprised of one or more traffic flows,
> and in the other hand you have a network. You map one to the other by
> associating slice flows with the resources they can use.
>
>
>
> There could be a debate about “resource sharing”. That is, when resources
> in one partition are not being used, can they be “borrowed” by another
> partition? I suppose the answer is yes, but I wonder how both slices can
> guarantee the service SLAs if the resources they use are not guaranteed to
> be available. This is considerably different from borrowing resources for
> best effort traffic, which can happen in any resource reservation scheme.
>
>
>
> Regards,
>