Subject: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Sep 2021 17:28:43 +0100

Hi,

Igor raised this especially in the context of how traffic is identified for association with a connectivity matrix that belongs to a slice.

Consider the definition of connectivity matrix in the current draft and as discussed in issue #1.

A consumer may want multiple connectivity matrices in their "contract" with the provider. In the example with four edge nodes (A, B, C, D), their may be traffic that flows between some edges, but not between others.

For example, a consumer may want a slice that is ultra-low latency, and they may know that they want to send traffic from A to B, from A to C and multicast from D to A, B, and C. 

It is, of course, possible to express this as three separate slices. And this is perfectly acceptable. We must not make any definitions that prevent this from being the case.

However, it seems likely that the consumer (and the operator) would prefer to talk about "the consumer's low latency slice". That is, to bundle these three connections into one construct. However, they are distinctly different connections and must be understood as such. Indeed, they may have some different SLOs associated (for example, A-B may require more bandwidth than A-C).

By allowing (but not mandating) multiple connectivity matrices in a single slice service, we facilitate this administrative group. 

One could also imagine (but I do not pre-judge the network slice service YANG model definition) a default set of SLOs that apply to all connectivity matrices in a slice, and specific modified SLOs per connectivity matrix.

Now, to Igor's point. This is about how traffic arriving at an edge (say a PE) is mapped to the correct connection. I promised a Venn diagram, but words are easier 😊

If we take the model of a port-based VPN, then one approach might be to map the (virtual or physical) port number or VLAN ID to the network slice. But clearly (and this was Igor's point) this doesn't identify the connectivity matrix if there is more than one matric per slice.

A solution I offered is that the VLAN ID could identify {slice, connectivity matrix}. At that PE, for a given AC to a CE, it is necessary to expose with a separate VLAN ID for each {slice, connectivity matrix}. That does not mean:
- we need a global unique identifier for each connectivity matrix
- we need a per-PE unique identifier for each connectivity matrix

I am *very* cautious about discussing potential technology solutions because they are just that. It is not the business of a framework to direct solutions work. But I provide this example solution just to show that it is possible.

Consider also, how traffic is placed on LSPs or on SFCs. The answer is that there is some form of classification performed at the head end. In many cases, this is as simple as examination of the destination address (traffic is "routed" onto the LSP). In other cases there is deeper analysis of the 5-tuple and even other packet parameters. Often this will be enough, but when there are multiple "parallel" connections to the same destination, some form of choice must be made: how that choice is made can be configured in an implementation, and may include looking at additional information (such as a VLAN ID) passed from the consumer.

Note that the identity of the connectivity matrix is not needed anywhere except at the ingress edge node. It may be that the connectivity matrix is mapped to some internal network structure (such as an LSP) and that that provides an implicit identification of the connectivity matrix, and it may be that a solution technology chooses to keep an identifier of the connectivity matrix with each packet, but that is not a requirement of the architecture.

I think what I have said is:
- Support of one connectivity matrix per slice is mandatory
- Support of more than one connectivity matrix per slice is in the architecture
  but is optional to implement
- There are ways that a protocol solution could achieve this function
- I have heard some voices asking for the association of multiple connectivity
  matrices with a single slice
- I have not heard anyone providing examples of harm this would cause

Please discuss.

Adrian

---

From: John E Drake <[email-masked]>
Date: Mon, 27 Sep 2021 18:16:39 +0000

Adrian,

In the latest version of the to-be-published Framework draft, we have the following definition:

 Attachment Circuit (AC):  A channel connecting a CE and a PE over which packets are exchanged.  The
customer and provider agree on which values in which combination of L2 and L3 fields within a packet
identify a given connectivity matrix within a given IETF Network Slice Service.

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: Teas <[email-masked]> On Behalf Of Adrian Farrel
> Sent: Monday, September 27, 2021 12:29 PM
> To: 'TEAS WG' <[email-masked]>
> Subject: [Teas] Network slicing framework : Issue #2 : How many connectivity
> matrices in a slice?
> 
> [External Email. Be cautious of content]
> 
> 
> Hi,
> 
> Igor raised this especially in the context of how traffic is identified for
> association with a connectivity matrix that belongs to a slice.
> 
> A consumer may want multiple connectivity matrices in their "contract" with the
> provider. In the example with four edge nodes (A, B, C, D), their may be traffic
> that flows between some edges, but not between others.
> 
> For example, a consumer may want a slice that is ultra-low latency, and they
> may know that they want to send traffic from A to B, from A to C and multicast
> from D to A, B, and C.
> 
> It is, of course, possible to express this as three separate slices. And this is
> perfectly acceptable. We must not make any definitions that prevent this from
> being the case.
> 
> However, it seems likely that the consumer (and the operator) would prefer to
> talk about "the consumer's low latency slice". That is, to bundle these three
> connections into one construct. However, they are distinctly different
> connections and must be understood as such. Indeed, they may have some
> different SLOs associated (for example, A-B may require more bandwidth than
> A-C).
> 
> By allowing (but not mandating) multiple connectivity matrices in a single slice
> service, we facilitate this administrative group.
> 
> One could also imagine (but I do not pre-judge the network slice service YANG
> model definition) a default set of SLOs that apply to all connectivity matrices in a
> slice, and specific modified SLOs per connectivity matrix.
> 
> Now, to Igor's point. This is about how traffic arriving at an edge (say a PE) is
> mapped to the correct connection. I promised a Venn diagram, but words are
> easier 😊
> 
> If we take the model of a port-based VPN, then one approach might be to map
> the (virtual or physical) port number or VLAN ID to the network slice. But clearly
> (and this was Igor's point) this doesn't identify the connectivity matrix if there is
> more than one matric per slice.
> 
> A solution I offered is that the VLAN ID could identify {slice, connectivity matrix}.
> At that PE, for a given AC to a CE, it is necessary to expose with a separate VLAN
> ID for each {slice, connectivity matrix}. That does not mean:
> I am *very* cautious about discussing potential technology solutions because
> they are just that. It is not the business of a framework to direct solutions work.
> But I provide this example solution just to show that it is possible.
> 
> Consider also, how traffic is placed on LSPs or on SFCs. The answer is that there
> is some form of classification performed at the head end. In many cases, this is
> as simple as examination of the destination address (traffic is "routed" onto the
> LSP). In other cases there is deeper analysis of the 5-tuple and even other packet
> parameters. Often this will be enough, but when there are multiple "parallel"
> connections to the same destination, some form of choice must be made: how
> that choice is made can be configured in an implementation, and may include
> looking at additional information (such as a VLAN ID) passed from the consumer.
> 
> Note that the identity of the connectivity matrix is not needed anywhere except
> at the ingress edge node. It may be that the connectivity matrix is mapped to
> some internal network structure (such as an LSP) and that that provides an
> implicit identification of the connectivity matrix, and it may be that a solution
> technology chooses to keep an identifier of the connectivity matrix with each
> packet, but that is not a requirement of the architecture.
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-
> gk!WDr1qyYuWTVcNfdWACFDBhpuWB09hOnRKbD4lEp5p3xxVzN2mQcQ2Ioh45
> z7At0$

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 28 Sep 2021 08:47:50 +0000

Hi Adrian,

This is just how we define a slice. We are concerned that we should allow multiple SLO/SLEs inside a slice?
We prefer not doing so since other SDOs define that their slice is determined with a SLO/SLE in my understanding.
Inside a slice with a common SLO/SLE, we don't mind multiple connectivity matrices, but we're not sure the necessity.

Thanks,
Kenichi

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of John E Drake
Sent: Tuesday, September 28, 2021 3:17 AM
To: [email-masked]; 'TEAS WG' <[email-masked]>
Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Adrian,

 Attachment Circuit (AC):  A channel connecting a CE and a PE over which packets are exchanged.  The customer and provider agree on which values in which combination of L2 and L3 fields within a packet identify a given connectivity matrix within a given IETF Network Slice Service.

Yours Irrespectively,

John

> Subject: [Teas] Network slicing framework : Issue #2 : How many 
> connectivity matrices in a slice?
> 
> Igor raised this especially in the context of how traffic is 
> identified for association with a connectivity matrix that belongs to a slice.
> 
> A consumer may want multiple connectivity matrices in their "contract" 
> with the provider. In the example with four edge nodes (A, B, C, D), 
> their may be traffic that flows between some edges, but not between others.
> 
> For example, a consumer may want a slice that is ultra-low latency, 
> and they may know that they want to send traffic from A to B, from A 
> to C and multicast from D to A, B, and C.
> 
> It is, of course, possible to express this as three separate slices. 
> And this is perfectly acceptable. We must not make any definitions 
> that prevent this from being the case.
> 
> However, it seems likely that the consumer (and the operator) would 
> prefer to talk about "the consumer's low latency slice". That is, to 
> bundle these three connections into one construct. However, they are 
> distinctly different connections and must be understood as such. 
> Indeed, they may have some different SLOs associated (for example, A-B 
> may require more bandwidth than A-C).
> 
> By allowing (but not mandating) multiple connectivity matrices in a 
> single slice service, we facilitate this administrative group.
> 
> One could also imagine (but I do not pre-judge the network slice 
> service YANG model definition) a default set of SLOs that apply to all 
> connectivity matrices in a slice, and specific modified SLOs per connectivity matrix.
> 
> Now, to Igor's point. This is about how traffic arriving at an edge 
> (say a PE) is mapped to the correct connection. I promised a Venn 
> diagram, but words are easier 😊
> 
> If we take the model of a port-based VPN, then one approach might be 
> to map the (virtual or physical) port number or VLAN ID to the network 
> slice. But clearly (and this was Igor's point) this doesn't identify 
> the connectivity matrix if there is more than one matric per slice.
> 
> At that PE, for a given AC to a CE, it is necessary to expose with a 
> separate VLAN ID for each {slice, connectivity matrix}. That does not mean:
> I am *very* cautious about discussing potential technology solutions 
> because they are just that. It is not the business of a framework to direct solutions work.
> Consider also, how traffic is placed on LSPs or on SFCs. The answer is 
> that there is some form of classification performed at the head end. 
> In many cases, this is as simple as examination of the destination 
> address (traffic is "routed" onto the LSP). In other cases there is 
> deeper analysis of the 5-tuple and even other packet parameters. Often this will be enough, but when there are multiple "parallel"
> connections to the same destination, some form of choice must be made: 
> how that choice is made can be configured in an implementation, and 
> may include looking at additional information (such as a VLAN ID) passed from the consumer.
> 
> Note that the identity of the connectivity matrix is not needed 
> anywhere except at the ingress edge node. It may be that the 
> connectivity matrix is mapped to some internal network structure (such 
> as an LSP) and that that provides an implicit identification of the 
> connectivity matrix, and it may be that a solution technology chooses 
> to keep an identifier of the connectivity matrix with each packet, but that is not a requirement of the architecture.
> 
_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 13:39:09 +0200

My 2 cents:

Slice might have multiple QoS flows (i.e 3GPP TS 38.300, Section 16.3.1), and obviously these different QoS flows will have different SLO characteristics (even, if the set of end-points is the same for all QoS flows).

So, if the support for mapping 3GPP slices to IETF slices is desired, certainly allowing multiple connectivity matrixes per slice would be welcomed.

Best regards,
Krzysztof

> On 2021 -Sep-28, at 10:47, Ogaki, Kenichi <[email-masked]> wrote:
> 
> Hi Adrian,
>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 28 Sep 2021 12:03:15 +0000

Hi Krzysztof,

Yes. A 3GPP slice supports multiple QoS, but this doesn't mean each QoS is necessarily associated with an SLO in my understanding.
A 3GPP slice is characterized with a slice NRM defined in TS28.541 Clause 6. Especially 6.3.3, "ServiceProfile" is corresponded to a set of SLOs/SLEs in ietf network slice.
We can map each QoS flow to a "SeriviceProfile", but this is not necessary.

Thanks,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Krzysztof Szarkowicz <[email-masked]>
Sent: Tuesday, September 28, 2021 8:39 PM
To: [email-masked]
Cc: John E Drake; TEAS WG; 大垣 健一
Subject: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

My 2 cents:

Best regards,
Krzysztof

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 14:44:33 +0200

Hi Kenichi,

If the slice have flows from following three QCIs:

1: Conversational Voice, latency 100 ms, 10 Mbps
76: Live Uplink Streaming, latency 500 ms, 100 Mbps
80: Low latency eMBB applications (TCP/UDP-based); Augmented Reality, Latency 10 ms, 1 Gbps

What SLO would you request for this slice?

Thanks,
Krzysztof

> On 2021 -Sep-28, at 14:03, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Krzysztof,
> 
> Get Outlook for iOS <https://aka.ms/o0ukef>
> From: Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> > On 2021 -Sep-28, at 10:47, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi Adrian,
> > 
> > From: Teas <[email-masked] <mailto:[email-masked]>> On Behalf Of John E Drake
> > To: [email-masked] <mailto:[email-masked]>; 'TEAS WG' <[email-masked] <mailto:[email-masked]>>
> >> From: Teas <[email-masked] <mailto:[email-masked]>> On Behalf Of Adrian Farrel
> >> To: 'TEAS WG' <[email-masked] <mailto:[email-masked]>>
> >> [email-masked] <mailto:[email-masked]>
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas>
> >> __;!!N
> >> Et6yMaO-
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Sep 2021 13:46:10 +0100

It’s a good question, but in this case, why do you not have three slices?

A

From: Krzysztof Szarkowicz <[email-masked]> 
Sent: 28 September 2021 13:45
To: Ogaki, Kenichi <[email-masked]>
Cc: [email-masked]; John E Drake <jdrake=[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Hi Kenichi,

Thanks,

Krzysztof

On 2021 -Sep-28, at 14:03, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> > wrote:

Hi Krzysztof,

Thanks,

Kenichi

  _____  

From: Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]> >

My 2 cents:

Best regards,
Krzysztof

> On 2021 -Sep-28, at 10:47, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> > wrote:
> 
> Hi Adrian,
> 
> From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of John E Drake
> To: [email-masked] <mailto:[email-masked]> ; 'TEAS WG' <[email-masked] <mailto:[email-masked]> >
>> From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of Adrian Farrel
>> To: 'TEAS WG' <[email-masked] <mailto:[email-masked]> >
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas> 
>> __;!!N
>> Et6yMaO-

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 14:49:19 +0200

Hi Adrian,

You mean, you recommend to map single 3GPP slice, to multiple IETF slices, based on traffic class?

Thanks,
Krzysztof

> On 2021 -Sep-28, at 14:46, Adrian Farrel <[email-masked]> wrote:
> 
> To: Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]>>; TEAS WG <[email-masked] <mailto:[email-masked]>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Sep 2021 13:58:17 +0100

Just asking.

If your answer is “because the 3GPP slice has all these different SLOs and we want to maintain a strict n:1 mapping of e2e slice to transport slice” then that is a great answer.

A

From: Krzysztof Szarkowicz <[email-masked]> 
Sent: 28 September 2021 13:49
To: [email-masked]
Cc: Ogaki, Kenichi <[email-masked]>; John E Drake <jdrake=[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Hi Adrian,

Thanks,

Krzysztof

On 2021 -Sep-28, at 14:46, Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

A

From: Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]> > 
Sent: 28 September 2021 13:45
To: Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >; TEAS WG <[email-masked] <mailto:[email-masked]> >
Subject: Re: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Hi Kenichi,

Thanks,

Krzysztof

Hi Krzysztof,

Thanks,

Kenichi

  _____  

My 2 cents:

Best regards,
Krzysztof

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

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 28 Sep 2021 13:07:03 +0000

Hi Krzysztof,

>What SLO would you request for this slice?

In the 3GPP semantics, we ask NSMF, 3GPP Mgmt system, to create three slices with each "ServiceProfile".

Slice 1 with ServiceProfile 1:
latency 100ms
dlThptPerUE 10Mbps
ulThptPerUE 10Mbps

Slice 2 with ServiceProfile 76:
latency 500ms
ulThptPerUE 100Mbps

Slice 3 with ServiceProfile 80:
latency 10ms
dlThptPerUE 1Gbps
dlThptPerUE 1Gbps

Slice 1 and 2 may be merged into a Slice 4, but Slice 3 is definitely different characteristics. Then, we have to create different slices.

Thanks,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Adrian Farrel <[email-masked]>
Sent: Tuesday, September 28, 2021 9:58 PM
To: 'Krzysztof Szarkowicz'
Cc: 大垣 健一; 'John E Drake'; 'TEAS WG'
Subject: RE: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Just asking.

A

Hi Adrian,

Thanks,
Krzysztof

On 2021 -Sep-28, at 14:46, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

A

From: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Sent: 28 September 2021 13:45
To: Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Hi Kenichi,

Thanks,
Krzysztof

On 2021 -Sep-28, at 14:03, Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>> wrote:

Hi Krzysztof,

Thanks,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 28, 2021 8:39 PM
To: [email-masked]<mailto:[email-masked]>
Cc: John E Drake; TEAS WG; 大垣 健一
Subject: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

My 2 cents:

Best regards,
Krzysztof

> On 2021 -Sep-28, at 10:47, Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Adrian,
>
> From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
> To: [email-masked]<mailto:[email-masked]>; 'TEAS WG' <[email-masked]<mailto:[email-masked]>>
>> From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel
>> To: 'TEAS WG' <[email-masked]<mailto:[email-masked]>>
>> [email-masked]<mailto:[email-masked]>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas>
>> __;!!N
>> Et6yMaO-
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 15:25:24 +0200

Hi Adrian,

If the slice we need to map to transport has following:

Slice BW: 1G
  Conversational Voice, latency 100 ms, 10 Mbps
  Live Uplink Streaming, latency 500 ms, 100 Mbps
  Non-Mission-Critical user plane, Internet, latency 100 ms, remaining BW, up to the slice BW

How it would fit into the IETF slicing model, with 3 different IATF slices?

Thanks,
Krzysztof

> On 2021 -Sep-28, at 14:58, Adrian Farrel <[email-masked]> wrote:
> 
> Just asking.
>  
>> On 2021 -Sep-28, at 14:46, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 15:58:19 +0200

Hi Kenichi,

We might ask to create different 3GGP slices. At the same point, having multiple classes within single 3GPP slice is completely valid approach, too.

Further, slice (with multiple classes) might be requested by other consumers (not only 3GPP SMO), not related to mobile.

My main point is, IETF network slicing architecture must be prepared to handle slice requests with multiple traffic classes within the slice, and should not be restricted to support only slicing request with single traffic class per slice, as with this restriction many use cases will be limited.

Thanks,
Krzysztof

> On 2021 -Sep-28, at 15:07, Ogaki, Kenichi <[email-masked]> wrote:
> 
> Hi Krzysztof,
> 
> From: Adrian Farrel <[email-masked] <mailto:[email-masked]>>
> Cc: Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>>; John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]>>; TEAS WG <[email-masked] <mailto:[email-masked]>>

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Sep 2021 14:20:36 +0000

Hi,

Comment inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: Krzysztof Szarkowicz <[email-masked]>
Sent: Tuesday, September 28, 2021 9:58 AM
To: Ogaki, Kenichi <[email-masked]>
Cc: [email-masked]; John E Drake <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Hi Kenichi,

[JD]  I completely agree with this.  Further, as I noted yesterday:

Thanks,
Krzysztof

On 2021 -Sep-28, at 15:07, Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>> wrote:

Hi Krzysztof,

Get Outlook for iOS<https://urldefense.com/v3/__https:/aka.ms/o0ukef__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIhHesicc$>
________________________________
From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 28, 2021 9:58 PM
To: 'Krzysztof Szarkowicz'
Cc: 大垣 健一; 'John E Drake'; 'TEAS WG'
Subject: RE: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Just asking.

A

Cc: Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>

Hi Adrian,

Thanks,
Krzysztof

A

Hi Kenichi,

Thanks,
Krzysztof

Hi Krzysztof,

Thanks,
Kenichi

Get Outlook for iOS<https://urldefense.com/v3/__https:/aka.ms/o0ukef__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIhHesicc$>

My 2 cents:

Best regards,
Krzysztof

> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIWH5hXmA$>
> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIWH5hXmA$>

_______________________________________________
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!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIWH5hXmA$>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 28 Sep 2021 14:52:37 +0000

Hi Krzysztof,

It depends on what's class?
If the class is that of DSCP, and a single slice just prioritizes the traffic on the same topology, we don't mind.
But, the class includes the latency like your QCI examples. We have to create different underlying topology per class. It's complicated to manage the relationship of n topologies to 1 slice.
Again in 3GPP semantics, we have to definitely create a different Network Slice Instance for your 3rd QCI. The UPF must be placed near the UE location and its deployment costs more.
For providers like us, we have to charge for a slice service. It's simple that URLLC slice service charges xxx JPY per month, BE slice service charges yyy JPY per month. But, this is just terminology mapping issue.
So, what term should we use against an *Service* Level Objective? connectivity matrix or slice (service)?

Thanks,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: John E Drake <[email-masked]>
Sent: Tuesday, September 28, 2021 11:20 PM
To: Krzysztof Szarkowicz; 大垣 健一
Cc: [email-masked]; TEAS WG
Subject: RE: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Hi,

Comment inline below.

Yours Irrespectively,

John

Hi Kenichi,

Thanks,
Krzysztof

Hi Krzysztof,

Just asking.

A

Hi Adrian,

Thanks,
Krzysztof

A

Hi Kenichi,

Thanks,
Krzysztof

Hi Krzysztof,

Thanks,
Kenichi

My 2 cents:

Best regards,
Krzysztof

---

From: Tarek Saad <[email-masked]>
Date: Tue, 28 Sep 2021 16:03:45 +0000

Hi Adrian,

Thanks for summarizing this issue.

>> For example, a consumer may want a slice that is ultra-low latency, and they may know that they want to send traffic from A to B, from A to C and multicast from D to A, B, and C.
[TS]: I agree that creating multiple matrices (per service type) to address the above usecase makes sense and makes it simpler for the IETF slice service consumer to reference a single ultra-low latency slice.

  *   In such case, wouldn’t the service type (unicast/multicast) be enough to differentiate what connectivity matrix the traffic would pick – as opposed to requiring an additional ID (one for identifying slice, and one for identifying the connectivity matrix).
  *   Does it make sense to have two “same type” connectivity matrices (for example, two p2p connectivity matrices for two connections between A and B)? I can see two cases:
     *   If the two parallel connections (between A and B) have same SLOs, then why not aggregate into 1 connection/connectivity matrix?
     *   If the two parallel connections (between A and B) have different SLOs, then are they still same slice? wouldn’t it be better to just have them in two different slices?
     *   it is not clear in such case what creating two matrices “of same type” is solving? Is it loadbalance, redundancy, ?

Regards,
Tarek

From: Teas <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Date: Monday, September 27, 2021 at 12:29 PM
To: 'TEAS WG' <[email-masked]>
Subject: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
Hi,

Please discuss.

Adrian

---

From: Tarek Saad <[email-masked]>
Date: Tue, 28 Sep 2021 16:26:59 +0000

Hi Krzytsof/all,

As I mentioned in earlier email, for a slice that supports H-QoS, it may be useful to consider whether we want to model this as a single connectivity matrix that supports multiple traffic types or multiple connectivity matrices (one per traffic type) within the same slice.
From modeling perspective (both may be feasible), but:

  *   If single connectivity matrix, a single hierarchical SLO can depict the relationship between the different traffic types (e.g. and any sharing of resources between classes)
  *   If multiple connectivity matrices (one per class), then a new shared SLO may be needed to dictate sharing of resources,etc. between classes

Regards,
Tarek

From: Teas <[email-masked]> on behalf of Krzysztof Szarkowicz <[email-masked]>
Date: Tuesday, September 28, 2021 at 7:39 AM
To: [email-masked] <[email-masked]>
Cc: Ogaki, Kenichi <[email-masked]>, John E Drake <jdrake=[email-masked]>, TEAS WG <[email-masked]>
Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
My 2 cents:

Best regards,
Krzysztof

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Sep 2021 18:17:16 +0100

Hi Tarek, 

You’ve called out some good cases for consideration.

[AF] There are two points to consider:

*	How the customer specifies the connectivity supported by the slice
*	How the implementation identifies the connectivity matrix and places traffic on the matrix

So, in this case, there is no traffic flow anticipated from A to D or from B to C, etc. Thus, it is not good enough to specify the set of endpoints, it is also important to specify the connectivity between those endpoints so that the provider knows that there is no need to provision resources for connectivity that will not be used.

How the connectivity is actually implemented in the network (and even how traffic is policed, and how SLIs are measured) is up to the provider/implementer. If (this may be a big if) the traffic is simply routed, then it would not be necessary for the provider to match traffic to a connectivity matrix – they would simply route it, and in this case the provider’s network is unaware of the connectivity matrix. On the other hand, if some form of connection-oriented approach is taken then while the traffic is simply routed/classified at the ingress endpoint, there is some relationship between connection matrix and reserved resources (think of MPLS-TE). 

If, in all this, there is no policing at the ingress endpoint, then admission control or use of resources in the transit network may need to be more carefully associated with the “flow” i.e. the connectivity matrix.

[AF] I think that if they have the same SLOs and the same connectivity, then you would probably have them as a single matrix (summing the bandwidth, but keeping the latency constant, for example). But you would not be required to do that. Again, it might depend on policing and how you want to manage the SLOs. For example, two parallel connectivity matrices from A to B each with a required throughput of X Mbps is not the same as one matrix from A to B with throughput 2X – this is because A is not the traffic source: traffic comes from upstream of the slice endpoint and may originate at different applications, hosts, or sites.

Again consider MPLS-TE LSPs. You might, for convenience and scalability tunnel two parallel LSPs down one hierarchical LSP. The capacity of the H-LSP is the sum of the children, but the children have their own rights!

Of course, in this case, the SLOs might only be identical today. They might be available to change tomorrow, and in that case it is a lot easier to have two separate (“parallel”) matrices.

[AF] This is the nub of the question. It is a multi-dimensional problem (because of the many SLOs) with a hierarchy of ownership. Customer --> slice --> matrix. You end up with the same number of leaves in the tree, but the branches are at different places. And, further, you could hang the SLOs at any point in the tree (for example at the matrix as currently proposed, or at the slice).

A part of this debate is: suppose two connectivity matrices have 98% agreement on their SLOs, but one SLO is fractionally different. Does that require two slices?

But please be aware that describing the architecture is not engineering the YANG model! With the current proposal, I would probably still write a YANG model that had default SLOs per customer, with variations per slice, with additional variations per matrix.

And also recall that how the network protocol implementations choose to implement adherence to SLOs is open for discussion. If they need some form of indicator/index to tell them what to do, this value will be “mapped” from {customer, slice, matrix} and it is not important (to the architecture) how that mapping is performed.

[AF] It is not clear to me that anyone (except for you :-) has raised the case of two parallel matrices with identical SLOs.  I am not convinced that they would be used (although my throughput example, above) is a possible case. But equally important to me is the question: why would we prevent this when it comes for free?

Cheers,

Adrian

From: Teas <[email-masked] <mailto:[email-masked]> > on behalf of Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Date: Monday, September 27, 2021 at 12:29 PM
To: 'TEAS WG' <[email-masked] <mailto:[email-masked]> >
Subject: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Hi,

Please discuss.

Adrian

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 19:38:18 +0200

Hi Kenichi,

Please see inline,

Thanks,
Krzysztof

> On 2021 -Sep-28, at 16:52, Ogaki, Kenichi <[email-masked]> wrote:
> 
> Hi Krzysztof,
> 

[Krzysztof] Yes. But even if they are they are forwarded across the same path, they could have different capacity requirements -> how this capacity is requested via NBI? I.e. 1G for QCI ‘X’ + 1G for QCI ‘Y’, is not the same as 2G for aggregate of QCI ‘X’+’Y’.

> For providers like us, we have to charge for a slice service. It's simple that URLLC slice service charges xxx JPY per month, BE slice service charges yyy JPY per month. But, this is just terminolo…

[Krzysztof] Agreed.

> From: John E Drake <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; TEAS WG
> Cc: [email-masked] <mailto:[email-masked]>; John E Drake <[email-masked] <mailto:[email-masked]>>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> On 2021 -Sep-28, at 15:07, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Krzysztof,
>  
> Get Outlook for iOS <https://urldefense.com/v3/__https:/aka.ms/o0ukef__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIhHesicc$>
> Get Outlook for iOS <https://urldefense.com/v3/__https:/aka.ms/o0ukef__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIhHesicc$>
> > https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIWH5hXmA$>
> > https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIWH5hXmA$>
>  
> https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIWH5hXmA$>

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 19:40:40 +0200

Yep.

I like better the approach 2: multiple connectivity matrices (one per traffic type) within the same slice. It makes resource sharing between classes easier, and find it more intuitive.

Thanks,
Krzysztof

> On 2021 -Sep-28, at 18:26, Tarek Saad <[email-masked]> wrote:
> 
> Hi Krzytsof/all,
>  
> If single connectivity matrix, a single hierarchical SLO can depict the relationship between the different traffic types (e.g. and any sharing of resources between classes)
> If multiple connectivity matrices (one per class), then a new shared SLO may be needed to dictate sharing of resources,etc. between classes
>  
> Regards,
> Tarek
>  
> From: Teas <[email-masked] <mailto:[email-masked]>> on behalf of Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> Cc: Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>>, John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]>>, TEAS WG <[email-masked] <mailto:[email-masked]>>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 28 Sep 2021 18:33:41 +0000 (UTC)

Krzysztof,
But in this case the slice NBI  would have to specify the traffic type classification rules, right?Why is this better than to have the client to request separate slice per type?
Igor

Sent from Yahoo Mail on Android 
 
  On Tue, Sep 28, 2021 at 1:41 PM, Krzysztof Szarkowicz<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 20:53:18 +0200

Igor,

Traffic type classification is required in any case. Assuming simple case, where traffic class is identified by DSCP, if case separate slice per class, the identification of NSE would be:

Currently defined NSE identification + DSCP

In case of multiple classes per slice, the identification of the NSE would stay the same, and then within the slice DCSP is used for class identification. Similar is already covered int L3SM/L2SM models. And, this is what John added recently as well top the slice draft, in fact.

Krzysztof

> On 2021 -Sep-28, at 20:33, Igor Bryskin <[email-masked]> wrote:
> 
> Krzysztof,
> 
> But in this case the slice NBI  would have to specify the traffic type classification rules, right?
> Why is this better than to have the client to request separate slice per type?
> 
> Igor
> 
> Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
> On Tue, Sep 28, 2021 at 1:41 PM, Krzysztof Szarkowicz
> <[email-masked]> wrote:

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 28 Sep 2021 12:29:30 -0700

+1
Changes from QC(class)I to QF(flow)I decouple QoS settings from a bearer and are better expressed as multiple matrices per slice.

Cheers,
Jeff

> On Sep 28, 2021, at 11:53, Krzysztof Szarkowicz <[email-masked]> wrote:
> Igor,
>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 29 Sep 2021 01:18:00 +0000

Hi Krzysztof and All,

Let me explain what makes us feel strangeness, please.

I believe all your technology and solution related comments are correct.
This is just a terminology concern.

From an operator's service perspective, we have to charge to a customer for how much resource is assigned/used fundamentally.

How to assign the resources is a little bit different from IETF's basic existing solutions from the other SDO's slice solution.
When we assume a router network, IETF slice may be realized by Adrian's filtered topology that basically assigns bandwidth on top of an existing physical router network. Providing multiple QoS classification inside the bandwidth doesn't affect the assigned resource although the router processing resource is consumed, but this can be incorporated as an assigned resource.
The other SDO's slice solution, especially 3GPP, is a kind of SFC, but the node providing an SF may be newly created per slice, e.g. UPF for URLLC slice service. So, 3GPP defines an SFC-like instance as their Network Slice Instance in my understanding. In other words, they have a Network Slice Instance per a set of SLOs/SLEs, i.e. "ServiceProfile" which I wrote.

Again, from a service perspective, it's simple for providers that a service has 1:1 relationship with a set of SLOs/SLEs.
I agree it's possible to have multiple mappings of a connectivity matrix to a set of SLOs/SLEs under a slice (service).
We are concerned about the inconsistency of the hierarchical concept with the other SDOs and bringing a confusion to use ietf network slice as their transport network.
So, our main point is if a slice service should have multiple sets of SLOs/SLEs. Is that *a* service?

Here is IETF, then IETF network slice should be defined regardless of the other SDOs’ definition. I understand.

See reply inline[KO], please.

Thanks,
Kenichi

From: Krzysztof Szarkowicz <[email-masked]>
Sent: Wednesday, September 29, 2021 2:38 AM
To: 大垣 健一 <[email-masked]>
Cc: John E Drake <[email-masked]>; [email-masked]; TEAS WG <[email-masked]>
Subject: ***フリーメール*** Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Hi Kenichi,

Please see inline,

Thanks,
Krzysztof

On 2021 -Sep-28, at 16:52, Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>> wrote:

Hi Krzysztof,

[KO] Again in 3GPP semantics, there is two options where the underlying topology is same.
Option 1:
Creating two slices per capacity requirement.
Slice 1 with ServiceProfile X:
dlThptPerUE 1Gbps
ulThptPerUE 1Gbps

Slice 1 with ServiceProfile Y:
dlThptPerUE 1Gbps
ulThptPerUE 1Gbps

Option 2:
Creating a slice with the QoS profile
Slice 3 with ServiceProfile “X+Y” and EP Transport/qosProfile* “X+Y”
ServiceProfile “X+Y”
dlThptPerUE 2Gbps
ulThptPerUE 2Gbps
EP_Transport/qosProfile “X+Y”
QCI X 1Gbps
QCI Y 1Gbps

*See TS28.541 Rel.17 Clause 6.3.2.2 and 6.3.1.17, and “S5-203253 TD proposal to add transport endpoint in NRM.doc”
3GPP slice NRM, like an information model for the NBI, can have a QoS profile as an SLO. It depends on the implementation, but we can profile H-QoS? inside an assigned resource.

In this case, almost of all customers and providers does Option 2.

[Krzysztof] Agreed.

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: John E Drake <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 28, 2021 11:20 PM
To: Krzysztof Szarkowicz; 大垣 健一
Cc: [email-masked]<mailto:[email-masked]>; TEAS WG
Subject: RE: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Hi,

Comment inline below.

Yours Irrespectively,

John

Cc: [email-masked]<mailto:[email-masked]>; John E Drake <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>

Hi Kenichi,

Thanks,
Krzysztof

Hi Krzysztof,

Just asking.

A

Hi Adrian,

Thanks,
Krzysztof

A

Hi Kenichi,

Thanks,
Krzysztof

Hi Krzysztof,

Thanks,
Kenichi

My 2 cents:

Best regards,
Krzysztof

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Wed, 29 Sep 2021 13:46:54 +0200

Kenichi,

What me (and others) are saying is, that the architecture should be flexible enough to support uses cases with:

1) no class differentiation within the slice (this is the use case you are looking for)
2) as well as use cases with class differentiation within the slice.

Both use cases can coexist, so no one is hurt :-). For use case (1), SLO/SLE is per slice. For use case (2), SLO/SLE is per traffic class (group of flows).

Thanks,
Krzysztof

> On 2021 -Sep-29, at 03:18, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Krzysztof and All,
>  
> To: 大垣 健一 <[email-masked] <mailto:[email-masked]>>
> Cc: John E Drake <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> On 2021 -Sep-28, at 16:52, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Krzysztof,
>

---

From: <[email-masked]>
Date: Wed, 29 Sep 2021 13:41:58 +0000

Hi Adrian, all, 

This is s good point. 

If we consider that a slice service is some sort of PDB (per-domain behavior, RFC 3086), then it is likely that only one connectivity matrix will be assumed. However, a slice isn't just that. Some forwarding differentiation may be required as a part of a slice service request. Think about a slice service that is designed for IPTV and VoD. At least two connectivity matrices will be needed for this case. 

What is important is to ensure that unambiguous flow identifications parameters are included for each requested connectivity (slice service). 

I basically agree with Adrian's conclusions, but I would formulate the first two bullets as follows: 
* The architecture does not assume nor preclude that one or more connectivity matrices are requested in a network slice service.
* Mapping a slice service with more than one connectivity matrices to one or more network slices is deployment-specific. 

Cheers,
Med

PS: FWIW, we used to have a similar concept in RFC 7297 (Section 4)

> -----Message d'origine-----
> De : Teas <[email-masked]> De la part de Adrian Farrel
> Envoyé : lundi 27 septembre 2021 18:29
> À : 'TEAS WG' <[email-masked]>
> Objet : [Teas] Network slicing framework : Issue #2 : How many
> Igor raised this especially in the context of how traffic is identified
> for association with a connectivity matrix that belongs to a slice.
> 
> with the provider. In the example with four edge nodes (A, B, C, D), their
> may be traffic that flows between some edges, but not between others.
> 
> For example, a consumer may want a slice that is ultra-low latency, and
> they may know that they want to send traffic from A to B, from A to C and
> multicast from D to A, B, and C.
> 
> It is, of course, possible to express this as three separate slices. And
> this is perfectly acceptable. We must not make any definitions that
> prevent this from being the case.
> 
> However, it seems likely that the consumer (and the operator) would prefer
> to talk about "the consumer's low latency slice". That is, to bundle these
> three connections into one construct. However, they are distinctly
> different connections and must be understood as such. Indeed, they may
> have some different SLOs associated (for example, A-B may require more
> bandwidth than A-C).
> 
> By allowing (but not mandating) multiple connectivity matrices in a single
> slice service, we facilitate this administrative group.
> 
> One could also imagine (but I do not pre-judge the network slice service
> YANG model definition) a default set of SLOs that apply to all
> Now, to Igor's point. This is about how traffic arriving at an edge (say a
> PE) is mapped to the correct connection. I promised a Venn diagram, but
> words are easier 😊
> 
> If we take the model of a port-based VPN, then one approach might be to
> map the (virtual or physical) port number or VLAN ID to the network slice.
> But clearly (and this was Igor's point) this doesn't identify the
> connectivity matrix if there is more than one matric per slice.
> 
> A solution I offered is that the VLAN ID could identify {slice,
> connectivity matrix}. At that PE, for a given AC to a CE, it is necessary
> to expose with a separate VLAN ID for each {slice, connectivity matrix}.
> That does not mean:
> because they are just that. It is not the business of a framework to
> direct solutions work. But I provide this example solution just to show
> that it is possible.
> 
> that there is some form of classification performed at the head end. In
> many cases, this is as simple as examination of the destination address
> (traffic is "routed" onto the LSP). In other cases there is deeper
> analysis of the 5-tuple and even other packet parameters. Often this will
> be enough, but when there are multiple "parallel" connections to the same
> destination, some form of choice must be made: how that choice is made can
> be configured in an implementation, and may include looking at additional
> information (such as a VLAN ID) passed from the consumer.
> 
> Note that the identity of the connectivity matrix is not needed anywhere
> except at the ingress edge node. It may be that the connectivity matrix is
> mapped to some internal network structure (such as an LSP) and that that
> provides an implicit identification of the connectivity matrix, and it may
> be that a solution technology chooses to keep an identifier of the
> connectivity matrix with each packet, but that is not a requirement of the
> architecture.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 29 Sep 2021 16:35:25 +0000

Hi all, 

Indeed this is interesting discussion and makes me to think about what constitutes a connectivity matrix.

In my understanding, a connectivity matrix firstly represents the demand of traffic flows between one sender and one receiver, or one sender and multiple receivers. Another attribute of the connectivity matrix is the expected SLOs of the traffic flows. The SLOs can usually specified using a set of parameters (e.g. bandwidth, latency, etc.) 

Following this, if either the connectivity demand or the SLOs of two traffic flow demand are different, they should be described using different connectivity matrices. 

On the other hand, I think we've agreed that within a network slice there can be multiple traffic classes, this is similar to what we have in a traditional non-sliced network.

Then for traffic flows which have the same connectivity demand (e.g. from A to B) but are marked with different traffic classes, perhaps they could be described using the same connectivity matrix, as long as this traffic matrix can incorporate multiple traffic classes?

The question is can we have multiple set of SLOs in a network slice, or are we actually talking about allowing different traffic classes in a network slice?

Best regards,
Jie

> From: Teas [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, September 29, 2021 9:42 PM
> If we consider that a slice service is some sort of PDB (per-domain behavior,
> RFC 3086), then it is likely that only one connectivity matrix will be assumed.
> However, a slice isn't just that. Some forwarding differentiation may be
> required as a part of a slice service request. Think about a slice service that is
> designed for IPTV and VoD. At least two connectivity matrices will be needed
> for this case.
> 
> What is important is to ensure that unambiguous flow identifications
> parameters are included for each requested connectivity (slice service).
> 
> * The architecture does not assume nor preclude that one or more
> connectivity matrices are requested in a network slice service.
> * Mapping a slice service with more than one connectivity matrices to one or
> more network slices is deployment-specific.
> 
> Cheers,
> Med
> 
> > De : Teas <[email-masked]> De la part de Adrian Farrel Envoyé :
> > lundi 27 septembre 2021 18:29 À : 'TEAS WG' <[email-masked]> Objet :
> > [Teas] Network slicing framework : Issue #2 : How many connectivity
> > matrices in a slice?
> >
> > Hi,
> >
> > (say a
> > PE) is mapped to the correct connection. I promised a Venn diagram,
> > but words are easier 😊
> >
> > to map the (virtual or physical) port number or VLAN ID to the network slice.
> > connectivity matrix}. At that PE, for a given AC to a CE, it is
> > necessary to expose with a separate VLAN ID for each {slice, connectivity
> matrix}.
> > That does not mean:
> > direct solutions work. But I provide this example solution just to
> > show that it is possible.
> >
> > deeper analysis of the 5-tuple and even other packet parameters. Often
> > this will be enough, but when there are multiple "parallel"
> > to keep an identifier of the connectivity matrix with each packet, but
> > that is not a requirement of the architecture.
> >
> ___________________________________________________________________
> ______________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.

---

From: John E Drake <[email-masked]>
Date: Wed, 29 Sep 2021 18:31:52 +0000

Hi,

What the current definition says is the following:

"and a set of SLOs and SLEs for each CE sending to each connectivity matrix"

so we can have multiple traffic classes per connectivity matrix.  (We can also have multiple connectivity matrices each with a single SLO per sender.)

Per Luis and Krzysztof, we may want to define another connectivity matrix type of 'any-to-any' in which a given sending CE can send a unicast packet to any one of the defined receiving CEs.  It's a variation of MP2MP and the SLO would describe the total number of packets sent by the sending PE into the network. 

Yours Irrespectively,

John

> From: Teas <[email-masked]> On Behalf Of Dongjie (Jimmy)
> Sent: Wednesday, September 29, 2021 12:35 PM
> To: [email-masked]; [email-masked]; 'TEAS WG'
> <[email-masked]>
> In my understanding, a connectivity matrix firstly represents the demand of
> traffic flows between one sender and one receiver, or one sender and multiple
> receivers. Another attribute of the connectivity matrix is the expected SLOs of
> the traffic flows. The SLOs can usually specified using a set of parameters (e.g.
> bandwidth, latency, etc.)
> 
> Following this, if either the connectivity demand or the SLOs of two traffic flow
> demand are different, they should be described using different connectivity
> matrices.
> 
> On the other hand, I think we've agreed that within a network slice there can be
> multiple traffic classes, this is similar to what we have in a traditional non-sliced
> network.
> 
> Then for traffic flows which have the same connectivity demand (e.g. from A to
> B) but are marked with different traffic classes, perhaps they could be described
> using the same connectivity matrix, as long as this traffic matrix can incorporate
> multiple traffic classes?
> 
> The question is can we have multiple set of SLOs in a network slice, or are we
> actually talking about allowing different traffic classes in a network slice?
> 
> Best regards,
> Jie
> 
> > If we consider that a slice service is some sort of PDB (per-domain
> > behavior, RFC 3086), then it is likely that only one connectivity matrix will be
> assumed.
> > However, a slice isn't just that. Some forwarding differentiation may
> > be required as a part of a slice service request. Think about a slice
> > service that is designed for IPTV and VoD. At least two connectivity
> > matrices will be needed for this case.
> >
> > * Mapping a slice service with more than one connectivity matrices to
> > one or more network slices is deployment-specific.
> >
> > Cheers,
> > Med
> >
> > > Indeed, they may have some different SLOs associated (for example,
> > > A-B may require more bandwidth than A-C).
> > >
> > > service YANG model definition) a default set of SLOs that apply to
> > > all connectivity matrices in a slice, and specific modified SLOs per
> > > connectivity matrix.
> > >
> > > Consider also, how traffic is placed on LSPs or on SFCs. The answer
> > > is that there is some form of classification performed at the head end.
> > > deeper analysis of the 5-tuple and even other packet parameters.
> > > Often this will be enough, but when there are multiple "parallel"
> > > may include looking at additional information (such as a VLAN ID)
> > > passed
> > from the consumer.
> > >
> > > connectivity matrix is mapped to some internal network structure
> > > (such as an LSP) and that that provides an implicit identification
> > > of the connectivity matrix, and it may be that a solution technology
> > > chooses to keep an identifier of the connectivity matrix with each
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
> > > as__;!!NEt6yMaO-gk!XJLd_X0_-
> vjzReXlm2x31k1ZuCKMBCN7PRb3MV2FTNm44tkWX
> > > gY63K1z4ymwM10$
> >
> >
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!XJLd_X0_-
> vjzReXlm2x31k1ZuCKMBCN7PRb3MV2FTNm44tkWXgY63
> > K1z4ymwM10$
> Et6yMaO-gk!XJLd_X0_-
> vjzReXlm2x31k1ZuCKMBCN7PRb3MV2FTNm44tkWXgY63K1z4ymwM10$

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 29 Sep 2021 15:58:40 -0700

Hi Tarek, Adrian, and all,
I find all the arguments compelling and valid, but they also confused me
a bit. Maybe it will help to clarify by whom (and how) will slice be
requested? Is it a customer (requester of a slice), aggregation for more
than one customer, or both.

(a)  The way Adrian explained above, to me it appeared that a customer
is requesting 'multiple services of different SLOs as a single slice'.
So it sounded like  
     "1 x customer = N-SLOs = N-conn.matrix = 1-slice.   
This case allows any arbitrary group of SLOs to form a slice. Is that correct?
Otherwise, is there any benefit in requesting another slice vs.
providing new connectivity matrix?  

(b) Tarek's explanation of HQoS says multiple service types. i.e. a
slice (which itself is a service) is a group of some-other types of services.
     "n x service-types = n x conn.matrix = 1-slice service.
I support aggregation with a narrow scope of HQoS, e.g. n-low-latency
matrices for n-customers (Although I dont know if we should bundle
different service types, and still call it a slice?).

(c) The simplest case is: a customer ask for a 'low-latency slice
service':  
    latency-SLO + (some policy) + other-SLO (say b/w) = 1 service = 1 slice.
In this case, 2 matrices are needed: 1-policy-matrix (or default as per
Adrian), and another for {latency-SLO, other-SLO}-matrix. In my mind
there is a homogeneity in a slice's SLO requests, and may be expressed
in one matrix.

I believe the intent maybe to allow all the 3 cases, we could document
them or otherwise clarify what does not apply.  

-Kiran

On Sep 28 2021, at 9:03 am, Tarek Saad <[email-masked]> wrote:

> [TS]: I agree that creating multiple matrices (per service type) to
> address the above usecase makes sense and makes it simpler for the
> IETF slice service consumer to reference a single ultra-low latency slice.
>  
> In such case, wouldn’t the service type (unicast/multicast) be enough
> to differentiate what connectivity matrix the traffic would pick – as
> opposed to requiring an additional ID (one for identifying slice, and
> one for identifying the connectivity matrix).
> Does it make sense to have two “same type” connectivity matrices (for
> example, two p2p connectivity matrices for two connections between A
> and B)? I can see two cases:
> If the two parallel connections (between A and B) have same SLOs, then
> why not aggregate into 1 connection/connectivity matrix?
> If the two parallel connections (between A and B) have different SLOs,
> then are they still same slice? wouldn’t it be better to just have
> them in two different slices?
> it is not clear in such case what creating two matrices “of same type”
> is solving? Is it loadbalance, redundancy, ?
>  
>  
>  
>  
> Regards,
>  
> Tarek
>  
>  
>  
>  
>  
>  
>  
>  
>  
> necessary to expose with a separate VLAN ID for each {slice,
> connectivity matrix}. That does not mean:
> passed from the consumer.
>