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

["Ogaki, Kenichi" <[e-mail]>]

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]> On Behalf Of John E Drake
Sent: Tuesday, September 28, 2021 3:17 AM
To: [e-mail]; 'TEAS WG' <[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]> On Behalf Of Adrian Farrel
> Sent: Monday, September 27, 2021 12:29 PM
> To: 'TEAS WG' <[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]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> __;!!N
> Et6yMaO-
> gk!WDr1qyYuWTVcNfdWACFDBhpuWB09hOnRKbD4lEp5p3xxVzN2mQcQ2Ioh45
> z7At0$
_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas