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

[Kiran Makhijani <[e-mail]>]

Hi Tarek, Adrian, and all,
I find all the arguments compelling and valid, but they also confused me
a bit. Maybe it will help to clarify by whom (and how) will slice be
requested? Is it a customer (requester of a slice), aggregation for more
than one customer, or both.

(a)  The way Adrian explained above, to me it appeared that a customer
is requesting 'multiple services of different SLOs as a single slice'.
So it sounded like  
     "1 x customer = N-SLOs = N-conn.matrix = 1-slice.   
This case allows any arbitrary group of SLOs to form a slice. Is that correct?
Otherwise, is there any benefit in requesting another slice vs.
providing new connectivity matrix?  

(b) Tarek's explanation of HQoS says multiple service types. i.e. a
slice (which itself is a service) is a group of some-other types of services.
     "n x service-types = n x conn.matrix = 1-slice service.
I support aggregation with a narrow scope of HQoS, e.g. n-low-latency
matrices for n-customers (Although I dont know if we should bundle
different service types, and still call it a slice?).

(c) The simplest case is: a customer ask for a 'low-latency slice
service':  
    latency-SLO + (some policy) + other-SLO (say b/w) = 1 service = 1 slice.
In this case, 2 matrices are needed: 1-policy-matrix (or default as per
Adrian), and another for {latency-SLO, other-SLO}-matrix. In my mind
there is a homogeneity in a slice's SLO requests, and may be expressed
in one matrix.

I believe the intent maybe to allow all the 3 cases, we could document
them or otherwise clarify what does not apply.  

-Kiran

On Sep 28 2021, at 9:03 am, Tarek Saad <[e-mail]> wrote:

> Hi Adrian,
>  
>  
>  
> Thanks for summarizing this issue.
>  
>  
>  
>>> 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.
>  
> [TS]: I agree that creating multiple matrices (per service type) to
> address the above usecase makes sense and makes it simpler for the
> IETF slice service consumer to reference a single ultra-low latency slice.
>  
> In such case, wouldn’t the service type (unicast/multicast) be enough
> to differentiate what connectivity matrix the traffic would pick – as
> opposed to requiring an additional ID (one for identifying slice, and
> one for identifying the connectivity matrix).
> Does it make sense to have two “same type” connectivity matrices (for
> example, two p2p connectivity matrices for two connections between A
> and B)? I can see two cases:
> If the two parallel connections (between A and B) have same SLOs, then
> why not aggregate into 1 connection/connectivity matrix?
> If the two parallel connections (between A and B) have different SLOs,
> then are they still same slice? wouldn’t it be better to just have
> them in two different slices?
> it is not clear in such case what creating two matrices “of same type”
> is solving? Is it loadbalance, redundancy, ?
>  
>  
>  
>  
> Regards,
>  
> Tarek
>  
>  
>  
>  
>  
>  
>  
>  
>  
> From: Teas <[e-mail]> on behalf of Adrian Farrel <[e-mail]>
> Date: Monday, September 27, 2021 at 12:29 PM
> To: 'TEAS WG' <[e-mail]>
> Subject: [Teas] Network slicing framework : Issue #2 : How many
> connectivity matrices in a slice?
> 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://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
>  
> Teas mailing list
>  
> [e-mail]
>  
> https://www.ietf.org/mailman/listinfo/teas