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

["Dongjie (Jimmy)" <[e-mail]>]

Hi all, 

Indeed this is interesting discussion and makes me to think about what constitutes a connectivity matrix.

In my understanding, a connectivity matrix firstly represents the demand of traffic flows between one sender and one receiver, or one sender and multiple receivers. Another attribute of the connectivity matrix is the expected SLOs of the traffic flows. The SLOs can usually specified using a set of parameters (e.g. bandwidth, latency, etc.) 

Following this, if either the connectivity demand or the SLOs of two traffic flow demand are different, they should be described using different connectivity matrices. 

On the other hand, I think we've agreed that within a network slice there can be multiple traffic classes, this is similar to what we have in a traditional non-sliced network.

Then for traffic flows which have the same connectivity demand (e.g. from A to B) but are marked with different traffic classes, perhaps they could be described using the same connectivity matrix, as long as this traffic matrix can incorporate multiple traffic classes?

The question is can we have multiple set of SLOs in a network slice, or are we actually talking about allowing different traffic classes in a network slice?

Best regards,
Jie

> -----Original Message-----
> From: Teas [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Wednesday, September 29, 2021 9:42 PM
> To: [e-mail]; 'TEAS WG' <[e-mail]>
> Subject: Re: [Teas] Network slicing framework : Issue #2 : How many
> connectivity matrices in a slice?
> 
> Hi Adrian, all,
> 
> This is s good point.
> 
> If we consider that a slice service is some sort of PDB (per-domain behavior,
> RFC 3086), then it is likely that only one connectivity matrix will be assumed.
> However, a slice isn't just that. Some forwarding differentiation may be
> required as a part of a slice service request. Think about a slice service that is
> designed for IPTV and VoD. At least two connectivity matrices will be needed
> for this case.
> 
> What is important is to ensure that unambiguous flow identifications
> parameters are included for each requested connectivity (slice service).
> 
> I basically agree with Adrian's conclusions, but I would formulate the first two
> bullets as follows:
> * The architecture does not assume nor preclude that one or more
> connectivity matrices are requested in a network slice service.
> * Mapping a slice service with more than one connectivity matrices to one or
> more network slices is deployment-specific.
> 
> Cheers,
> Med
> 
> PS: FWIW, we used to have a similar concept in RFC 7297 (Section 4)
> 
> > -----Message d'origine-----
> > De : Teas <[e-mail]> De la part de Adrian Farrel Envoyé :
> > lundi 27 septembre 2021 18:29 À : 'TEAS WG' <[e-mail]> Objet :
> > [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
> 
> ___________________________________________________________________
> ______________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas