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

[Xufeng Liu <[e-mail]>]

Besides, using one type of IDs is simpler than using two types of IDs. The
hierarchical structure of the slices is needed anyway.
Thanks,
- Xufeng

On Thu, Oct 7, 2021 at 5:54 PM Xufeng Liu <[e-mail]> wrote:

> Hi John,
>
> To me, "connectivity matric ID" is a term and concept that I have not seen
> before, inside IETF and outside of IETF. My preference is to avoid it if it
> is not something that we must have.
>
> Thanks,
> - Xufeng
>
>
> On Thu, Oct 7, 2021 at 5:38 PM John E Drake <[e-mail]> wrote:
>
>> What is the difference between having N connectivity matrix IDs and
>> having N IETF network slice IDs?
>>
>>
>>
>> Yours Irrespectively,
>>
>>
>>
>> John
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From:* Xufeng Liu <[e-mail]>
>> *Sent:* Thursday, October 7, 2021 5:17 PM
>> *To:* John E Drake <[e-mail]>
>> *Cc:* Joel M. Halpern <[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]*
>>
>>
>>
>> Hi John,
>>
>> The equivalence is right, except that there is a need to have the
>> connectivity-metrix-id if multiple connectivity matrices are allowed. More
>> comments in-line below.
>>
>> Thanks,
>>
>> - Xufeng
>>
>>
>>
>> On Thu, Oct 7, 2021 at 4:56 PM John E Drake <[e-mail]> wrote:
>>
>> Hi,
>>
>>
>>
>> Comment inline
>>
>>
>>
>> Yours Irrespectively,
>>
>>
>>
>> John
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From:* Teas <[e-mail]> *On Behalf Of *Xufeng Liu
>> *Sent:* Thursday, October 7, 2021 4:43 PM
>> *To:* Joel M. Halpern <[e-mail]>
>> *Cc:* 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]*
>>
>>
>>
>> In this case, there is slice-a for traffic class A with slo-A, and
>> slice-b for traffic class B with slo-B. There is another base slice-c under
>> both slice-a and slice-b. The slo-C on slice-c limits the total traffic.
>>
>> Thanks,
>>
>>
>>
>> *[JD]  If you replace ‘slice-a’ with ‘connectivity matrix a’,  ‘slice-b’
>> with ‘connectivity matrix b’, and ‘slice-c’ with ‘IETF network slice c’,
>> you have the current architecture. *
>>
>> [Xufeng] This is an exact equivalence. There is still a need for nested
>> slice hierarchy since the connectivity matrices are not hierarchically
>> structured.
>>
>>
>>
>> - Xufeng
>>
>>
>>
>> On Thu, Oct 7, 2021 at 3:27 PM Joel M. Halpern <[e-mail]>
>> wrote:
>>
>> Do you consider the use case where there is a ingress limit on the total
>> traffic thata a consumer can send across a set of traffic classes, and
>> there are separate SLOs for those separate classes, to be a case we need
>> to address?
>>
>> It seems legitimate to me.  And multiple connectivity matrices in a
>> slice seems the natural way to address it.
>>
>> Yours,
>> Joel
>>
>> On 10/7/2021 3:19 PM, Xufeng Liu wrote:
>> > 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.
>> >
>> > Thanks,
>> > - Xufeng
>> >
>> > On Tue, Sep 28, 2021 at 1:17 PM Adrian Farrel <[e-mail]
>> > <mailto:[e-mail]>> wrote:
>> >
>> >     Hi Tarek, ____
>> >
>> >     __ __
>> >
>> >     You’ve called out some good cases for consideration.____
>> >
>> >     __ __
>> >
>> >     >> 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).____
>> >
>> >     [AF] There are two points to consider:____
>> >
>> >       * How the customer specifies the connectivity supported by the
>> >         slice____
>> >       * How the implementation identifies the connectivity matrix and
>> >         places traffic on the matrix____
>> >
>> >     So, in this case, there is no traffic flow anticipated from A to D
>> >     or from B to C, etc. Thus, it is not good enough to specify the set
>> >     of endpoints, it is also important to specify the connectivity
>> >     between those endpoints so that the provider knows that there is no
>> >     need to provision resources for connectivity that will not be
>> used.____
>> >
>> >     How the connectivity is actually implemented in the network (and
>> >     even how traffic is policed, and how SLIs are measured) is up to the
>> >     provider/implementer. If (this may be a big if) the traffic is
>> >     simply routed, then it would not be necessary for the provider to
>> >     match traffic to a connectivity matrix – they would simply route it,
>> >     and in this case the provider’s network is unaware of the
>> >     connectivity matrix. On the other hand, if some form of
>> >     connection-oriented approach is taken then while the traffic is
>> >     simply routed/classified at the ingress endpoint, there is some
>> >     relationship between connection matrix and reserved resources (think
>> >     of MPLS-TE). ____
>> >
>> >     If, in all this, there is no policing at the ingress endpoint, then
>> >     admission control or use of resources in the transit network may
>> >     need to be more carefully associated with the “flow” i.e. 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:____
>> >           o If the two parallel connections (between A and B) have same
>> >             SLOs, then why not aggregate into 1 connection/connectivity
>> >             matrix?____
>> >
>> >     [AF] I think that if they have the same SLOs and the same
>> >     connectivity, then you would probably have them as a single matrix
>> >     (summing the bandwidth, but keeping the latency constant, for
>> >     example). But you would not be required to do that. Again, it might
>> >     depend on policing and how you want to manage the SLOs. For example,
>> >     two parallel connectivity matrices from A to B each with a required
>> >     throughput of X Mbps is not the same as one matrix from A to B with
>> >     throughput 2X – this is because A is not the traffic source: traffic
>> >     comes from upstream of the slice endpoint and may originate at
>> >     different applications, hosts, or sites.____
>> >
>> >     __ __
>> >
>> >     Again consider MPLS-TE LSPs. You might, for convenience and
>> >     scalability tunnel two parallel LSPs down one hierarchical LSP. The
>> >     capacity of the H-LSP is the sum of the children, but the children
>> >     have their own rights!____
>> >
>> >     __ __
>> >
>> >     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.____
>> >
>> >     __ __
>> >
>> >           o 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.
>> >
>> >     ____
>> >
>> >     __ __
>> >
>> >     A part of this debate is: suppose two connectivity matrices have 98%
>> >     agreement on their SLOs, but one SLO is fractionally different. Does
>> >     that require two slices?____
>> >
>> >     __ __
>> >
>> >     But please be aware that describing the architecture is not
>> >     engineering the YANG model! With the current proposal, I would
>> >     probably still write a YANG model that had default SLOs per
>> >     customer, with variations per slice, with additional variations per
>> >     matrix.____
>> >
>> >     __ __
>> >
>> >     And also recall that how the network protocol implementations choose
>> >     to implement adherence to SLOs is open for discussion. If they need
>> >     some form of indicator/index to tell them what to do, this value
>> >     will be “mapped” from {customer, slice, matrix} and it is not
>> >     important (to the architecture) how that mapping is performed.____
>> >
>> >     __ __
>> >
>> >           o it is not clear in such case what creating two matrices “of
>> >             same type” is solving? Is it loadbalance, redundancy, ?____
>> >
>> >     [AF] It is not clear to me that anyone (except for you :-) has
>> >     raised the case of two parallel matrices with identical SLOs.  I am
>> >     not convinced that they would be used (although my throughput
>> >     example, above) is a possible case. But equally important to me is
>> >     the question: why would we prevent this when it comes for free?____
>> >
>> >     __ __
>> >
>> >     Cheers,____
>> >
>> >     Adrian____
>> >
>> >     __ __
>> >
>> >     *From: *Teas <[e-mail] <mailto:[e-mail]>>
>> >     on behalf of Adrian Farrel <[e-mail]
>> >     <mailto:[e-mail]>>
>> >     *Date: *Monday, September 27, 2021 at 12:29 PM
>> >     *To: *'TEAS WG' <[e-mail] <mailto:[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] <mailto:[e-mail]>
>> >     https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$>
>> >     <https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$>
>> >____
>> >
>> >     _______________________________________________
>> >     Teas mailing list
>> >     [e-mail] <mailto:[e-mail]>
>> >     https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$>
>> >     <https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$>
>> >
>> >
>> >
>> > _______________________________________________
>> > Teas mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$>
>> >
>>
>>