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

From: Xufeng Liu <[email-masked]>
Date: Thu, 7 Oct 2021 15:19:45 -0400

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 <[email-masked]> 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:
>       - 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.
>
>
>
>    - 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.
>
>
>
>    - 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 <[email-masked]> on behalf of Adrian Farrel <
> [email-masked]>
> *Date: *Monday, September 27, 2021 at 12:29 PM
> *To: *'TEAS WG' <[email-masked]>
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Oct 2021 15:27:47 -0400

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:
> On Tue, Sep 28, 2021 at 1:17 PM Adrian Farrel <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Tarek, ____
> 
>     __ __
> 
>     You’ve called out some good cases for consideration.____
> 
>     __ __
> 
>     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.____
> 
>     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). ____
> 
>     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).
> 
> 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.
> 
>     ____
> 
>     __ __
> 
>     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 <[email-masked] <mailto:[email-masked]>>
>     on behalf of Adrian Farrel <[email-masked]
>     <mailto:[email-masked]>>
>     *To: *'TEAS WG' <[email-masked] <mailto:[email-masked]>>
>     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.
> 
>     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.
> 
>     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:
>     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
>     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.
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>____
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
>

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Oct 2021 20:01:54 +0000

Hi,

Massively snipped, comments inline.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Xufeng Liu
Sent: Thursday, October 7, 2021 3:20 PM
To: Adrian Farrel <[email-masked]>
Cc: Tarek Saad <[email-masked]>; TEAS WG <[email-masked]>
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:

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.

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 7 Oct 2021 16:42:39 -0400

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,
- Xufeng

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Oct 2021 20:56:11 +0000

Hi,

Comment inline

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Xufeng Liu
Sent: Thursday, October 7, 2021 4:43 PM
To: Joel M. Halpern <[email-masked]>
Cc: TEAS WG <[email-masked]>
Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

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

On Thu, Oct 7, 2021 at 3:27 PM Joel M. Halpern <[email-masked]<mailto:[email-masked]>> 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?

Yours,
Joel

On 10/7/2021 3:19 PM, Xufeng Liu wrote:
> On Tue, Sep 28, 2021 at 1:17 PM Adrian Farrel <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hi Tarek, ____
>
>     __ __
>
>     *From: *Teas <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     on behalf of Adrian Farrel <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     *To: *'TEAS WG' <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     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$>>____
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     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$>>
>
>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$>
>

---

From: "jmh.direct" <[email-masked]>
Date: Thu, 07 Oct 2021 16:56:59 -0400

We do not have any provision in the current design for directly nested slices.   You can get there conceptually, since we do allow consumer to offer their own slices.  But doing that seems harder than recognizing that a slice may have several kinds of traffic.Yours,JoelSent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
-------- Original message --------From: Xufeng Liu <[email-masked]> Date: 10/7/21  4:43 PM  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]> Cc: TEAS WG <[email-masked]> Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice? 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,- XufengOn Thu, Oct 7, 2021 at 3:27 PM Joel M. Halpern <[email-masked]> 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?

Yours,
Joel

On 10/7/2021 3:19 PM, Xufeng Liu wrote:
>     >> For example, a consumer may want a slice that is ultra-low latency,

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 7 Oct 2021 17:17:04 -0400

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 <[email-masked]> wrote:

> *From:* Teas <[email-masked]> *On Behalf Of * Xufeng Liu
> *Sent:* Thursday, October 7, 2021 4:43 PM
> *To:* Joel M. Halpern <[email-masked]>
> *Cc:* TEAS WG <[email-masked]>
> *Subject:* Re: [Teas] Network slicing framework : Issue #2 : How many
> *[External Email. Be cautious of content]*
>
>
>
> *[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.

> <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$>
> >____
> >
> <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$>
> >
> >
> >
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$>
> >
>
>

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 7 Oct 2021 17:26:09 -0400

Hi Joel,

Thanks for the comments. More thoughts below in-line.
Regards,
- Xufeng

On Thu, Oct 7, 2021 at 4:57 PM jmh.direct <[email-masked]>
wrote:

> We do not have any provision in the current design for directly nested
> slices.   You can get there conceptually, since we do allow consumer to
> offer their own slices.
>
[Xufeng]: This is the point. We have the capability already.

But doing that seems harder than recognizing that a slice may have several
> kinds of traffic.
[Xufeng]: The trade-off is that there is no need to introduce the
connectivity-matrix-id to the end-user. Event if multiple connectivity
matrices are allowed, because they are not structured hierarchically, the
nested slices offer more capabilities.

>
> Yours,
> Joel
>
>
>
> Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
>
>
> -------- Original message --------
> From: Xufeng Liu <[email-masked]>
> Date: 10/7/21 4:43 PM (GMT-05:00)
> To: "Joel M. Halpern" <[email-masked]>

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Oct 2021 21:38:29 +0000

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 <[email-masked]>
Sent: Thursday, October 7, 2021 5:17 PM
To: John E Drake <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Comment inline

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Xufeng Liu
Sent: Thursday, October 7, 2021 4:43 PM
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

[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

Yours,
Joel

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 7 Oct 2021 17:54:22 -0400

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 <[email-masked]> wrote:

> *From:* Xufeng Liu <[email-masked]>
> *Sent:* Thursday, October 7, 2021 5:17 PM
> *To:* John E Drake <[email-masked]>
> *Cc:* Joel M. Halpern <[email-masked]>; TEAS WG <[email-masked]>
> *From:* Teas <[email-masked]> *On Behalf Of *Xufeng Liu

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 7 Oct 2021 17:57:30 -0400

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 <[email-masked]> wrote:

>> 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,
>>
>>
>>

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Oct 2021 22:54:31 +0000

Hi,

Regardless of whether you allow one or more than one connectivity matrix per IETF network slice, you will have to deal with a connectivity matrix ID.

Yours Irrespectively,

John

Sent: Thursday, October 7, 2021 5:54 PM

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 7, 2021 5:17 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Hi John,

Comment inline

Yours Irrespectively,

John

- Xufeng

Yours,
Joel

---

From: t petch <[email-masked]>
Date: Wed, 13 Oct 2021 10:06:56 +0100

> is not something that we must have.

Mmmm, assuming that matrix, being the singular of matrices, is intended, 
then I see that used widely in the IETF as in RFC7448, RFC7579 and in 
most of the current I-D in the TEAS or CCAMP WG that include a YANG 
module.  I would agree that it is usually accompanied by 'MatrixID' 
rather than being written as 'matrix id' but would assume that the 
meaning of those two phrases is the same.

Tom Petch