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

[John E Drake <[e-mail]>]

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$