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

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

Hi,

Massively snipped, comments inline.

Yours Irrespectively,

John



Juniper Business Use Only
From: Teas <[e-mail]> On Behalf Of Xufeng Liu
Sent: Thursday, October 7, 2021 3:20 PM
To: Adrian Farrel <[e-mail]>
Cc: Tarek Saad <[e-mail]>; TEAS WG <[e-mail]>
Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

[External Email. Be cautious of content]

I would like to have:
- Support of one connectivity matrix per slice is mandatory

But not have:
- Support of more than one connectivity matrix per slice is in the architecture
  but is optional to implement

Allowing the second option would unnecessarily complicate the user experience, without providing any additional capabilities, as commented below in-line.

[JD]  If an operator decides to support *only* a single connectivity matrix per IETF network slice while the architecture allows more than one,
how exactly is the customer experience unnecessarily complicated?

Or to put it another way, if the customer requires N connectivity matrices, then they will need either N IETF network slices each with one connectivity
matrix or 1 IETF network slice with N connectivity matrices.  The architecture supports both options and I don't see how the latter option unnecessarily
complicates the customer experience.  I would assert that some customers would prefer the latter, I know I would.

Thanks,
- Xufeng

Of course, in this case, the SLOs might only be identical today. They might be available to change tomorrow, and in that case it is a lot easier to have two separate ("parallel") matrices.


     *   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?
[AF] This is the nub of the question. It is a multi-dimensional problem (because of the many SLOs) with a hierarchy of ownership. Customer --> slice --> matrix. You end up with the same number of leaves in the tree, but the branches are at different places. And, further, you could hang the SLOs at any point in the tree (for example at the matrix as currently proposed, or at the slice).
[Xufeng]: If the slices can be organized hierarchically, the original desired behavior can be achieved:  in addition to the three separate slices described earlier, we can have a base (underlay) slice that supports all these three slices. The base slice can serve as a construct containing all three connectivity matrices, without introducing additional connectivity-matrix-id.

[JD]  The requirement is to have various types of connectivity between various subsets of the customer's CEs.  Given that the membership of every one of these subsets can change, it is necessary to identify each of these subsets in the definition of the IETF network slice service.  Your proposal, above, would still need to individually identify each of the three connectivity matrices that you mention, so your proposal doesn't simplify anything.