Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

[Krzysztof Szarkowicz <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 <[e-mail]> 
> Sent: 28 September 2021 13:49
> To: [e-mail]
> Cc: Ogaki, Kenichi <[e-mail]>; John E Drake <jdrake=[e-mail]>; TEAS WG <[e-mail]>
> Subject: Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
>  
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>>  
>> It’s a good question, but in this case, why do you not have three slices?
>>  
>> A
>>  
>> From: Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]>> 
>> Sent: 28 September 2021 13:45
>> To: Ogaki, Kenichi <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]>; John E Drake <jdrake=[e-mail] <mailto:jdrake=[e-mail]>>; TEAS WG <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
>>  
>> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>>>  
>>> 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 <[e-mail] <mailto:[e-mail]>>
>>> Sent: Tuesday, September 28, 2021 8:39 PM
>>> To: [e-mail] <mailto:[e-mail]>
>>> Cc: John E Drake; TEAS WG; 大垣 健一
>>> Subject: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
>>>  
>>> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>>> > 
>>> > 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 <[e-mail] <mailto:[e-mail]>> On Behalf Of John E Drake
>>> > Sent: Tuesday, September 28, 2021 3:17 AM
>>> > To: [e-mail] <mailto:[e-mail]>; 'TEAS WG' <[e-mail] <mailto:[e-mail]>>
>>> > Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
>>> > 
>>> > 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 <[e-mail] <mailto:[e-mail]>> On Behalf Of Adrian Farrel
>>> >> Sent: Monday, September 27, 2021 12:29 PM
>>> >> To: 'TEAS WG' <[e-mail] <mailto:[e-mail]>>
>>> >> 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.
>>> >> 
>>> >> 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
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >> _______________________________________________
>>> >> Teas mailing list
>>> >> [e-mail] <mailto:[e-mail]>
>>> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas>
>>> >> __;!!N
>>> >> Et6yMaO-
>>> >> gk!WDr1qyYuWTVcNfdWACFDBhpuWB09hOnRKbD4lEp5p3xxVzN2mQcQ2Ioh45
>>> >> z7At0$
>>> > _______________________________________________
>>> > Teas mailing list
>>> > [e-mail] <mailto:[e-mail]>
>>> > https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>
>>> > _______________________________________________
>>> > Teas mailing list
>>> > [e-mail] <mailto:[e-mail]>
>>> > https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>
>>  
>> _______________________________________________
>> Teas mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>