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

[Krzysztof Szarkowicz <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 <[e-mail] <mailto:[e-mail]>> on behalf of Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, September 28, 2021 at 7:39 AM
> To: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Cc: Ogaki, Kenichi <[e-mail] <mailto:[e-mail]>>, John E Drake <jdrake=[e-mail] <mailto:jdrake=[e-mail]>>, TEAS WG <[e-mail] <mailto:[e-mail]>>
> 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>