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

[Krzysztof Szarkowicz <[e-mail]>]

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