Subject: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Sep 2021 17:37:06 +0100

Hi,

Currently we say that SLOs/SLEs are specified for each sender on each
connectivity matrix. Thus, if we have A-B, A-C and A-{B, C, D} we would
configure 3 sets of SLOs/SLEs describing the required behaviour and
performance of the three connectivity matrices in terms of the traffic
presented at A.

Luis asks that we also consider configuring SLOs/SLE for the receivers on
those connectivity matrices.

I would like Luis to comment more on this requirement as (form my
perspective) the SLOs/SLEs describe how traffic should be serviced by the
network, not the performance of the receiver. But the expected traffic
arriving at the receiver can be deduce from the traffic at the senders.

If, on the other hand, the receiver knows that it must receive traffic with
no more than a certain jitter, this is (presumably) a feature of the
application/service being run over the slice so it is equally configurable
at the sender.

Thanks,
Adrian

---

From: John E Drake <[email-masked]>
Date: Mon, 27 Sep 2021 17:59:50 +0000

Adrian,

The current definition is that the for a given sending CE/connectivity matrix the set of SLOs and SLEs apply to all receiving CEs for that connectivity matrix.  Sending CEs are independent, so for a given receiving CE for that connectivity matrix the set of SLOs and SLEs is effectively the sum of the set of SLOs and SLEs for each sending CE

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: Teas <[email-masked]> On Behalf Of Adrian Farrel
> Sent: Monday, September 27, 2021 12:37 PM
> To: 'LUIS MIGUEL CONTRERAS MURILLO'
> <[email-masked]>; 'TEAS WG' <[email-masked]>
> Subject: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver
> 
> [External Email. Be cautious of content]
> 
> 
> Hi,
> 
> performance of the three connectivity matrices in terms of the traffic presented
> at A.
> 
> Luis asks that we also consider configuring SLOs/SLE for the receivers on those
> connectivity matrices.
> 
> network, not the performance of the receiver. But the expected traffic arriving
> at the receiver can be deduce from the traffic at the senders.
> 
> If, on the other hand, the receiver knows that it must receive traffic with no
> more than a certain jitter, this is (presumably) a feature of the
> application/service being run over the slice so it is equally configurable at the
> sender.
> 
> Thanks,
> Adrian
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!WHlUOHwVHgCbTvsslIOUbtuzc_c53VJCxP2Q25d3y-
> JnoPmU4ovtQ6bRJWriFrE$

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Sep 2021 13:56:03 -0700

Hi Adrian,
thank you for highlighting the question of the SLO/SLE relationship to NS
edges. I think of a model, where the SLO is specified for the ordered set
of edges of the given network slice. I think that how the receiver may
aggregate these SLOs is outside of the scope of this document. Does
that make sense?

Regards,
Greg

On Mon, Sep 27, 2021 at 9:37 AM Adrian Farrel <[email-masked]> wrote:

> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Sep 2021 22:01:20 +0100

Thanks Greg, I just want to dig a bit. I don’t think I understand what you said. I’m seeking clarity, not disagreeing with you.

Do you mean that all edges in the slice have the same SLOs? What if you want different SLOs on different connectivity matrices in the same slice?

What does “ordered set of edges” mean here? In what sense ordered?

Does edge, mean “edge node” rather than “graph edge”?

Is the receiver counted as one of the edges in the set?

Thanks,

Adrian

From: Greg Mirsky <[email-masked]> 
Sent: 27 September 2021 21:56
To: Adrian Farrel <[email-masked]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi Adrian,

thank you for highlighting the question of the SLO/SLE relationship to NS edges. I think of a model, where the SLO is specified for the ordered set of edges of the given network slice. I think that how the receiver may aggregate these SLOs is outside of the scope of this document. Does that make sense?

Regards,

Greg

On Mon, Sep 27, 2021 at 9:37 AM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

Thanks,
Adrian

_______________________________________________
Teas mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/teas

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Sep 2021 14:17:55 -0700

Hi Adrian,
thank you for so quickly responding with your questions that are helping me
to clarify my model. Please find my notes in-line below under the GIM>> tag.

Regards,
Greg

On Mon, Sep 27, 2021 at 2:01 PM Adrian Farrel <[email-masked]> wrote:

> Thanks Greg, I just want to dig a bit. I don’t think I understand what you
> said. I’m seeking clarity, not disagreeing with you.
>
>
>
> Do you mean that all edges in the slice have the same SLOs?
>
GIM>> I first wrote "ordered pair of edges" but that may not include the
p2mp case. No, I imagine that there could be different SLOs for the same
performance parameters specified for different ordered sets within the same
network slice.

> What if you want different SLOs on different connectivity matrices in the
> same slice?
>
GIM>> I agree, that is a valid scenario that must be supported.

> What does “ordered set of edges” mean here? In what sense ordered?
GIM>> In the manner you've presented in the initial email - A-B, A-C, and
A-(B, C, D}. For example, A-B is a different ordered set from B-A and each
may have a different set of SLOs.

> Does edge, mean “edge node” rather than “graph edge”?
GIM>> If we can present a network slice as a directed graph, then what I am
referring to is the edge, i.e., the ordered pair of nodes in the graph.

> Is the receiver counted as one of the edges in the set?
GIM>> Yes, it is.

>
>
> Thanks,
>
> Adrian
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* 27 September 2021 21:56
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* LUIS MIGUEL CONTRERAS MURILLO <
> [email-masked]>; TEAS WG <[email-masked]>
> *Subject:* Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per
> receiver
>
>
>
> Hi Adrian,
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Sep 2021 14:20:49 -0700

Hi John,
I suspect that not all SLOs at the receiving CE of the particular network
slice can be presented as the sum of the corresponding SLOs defined for all
senders to that CE. For example, BW SLO can be summarized. But I don't see
that interpacket delay variation can be summarized to be useful for the
receiver at the NSE.

Regards,
Greg

On Mon, Sep 27, 2021 at 11:00 AM John E Drake <jdrake=
[email-masked]> wrote:

> Adrian,
>
> The current definition is that the for a given sending CE/connectivity
> matrix the set of SLOs and SLEs apply to all receiving CEs for that
> connectivity matrix.  Sending CEs are independent, so for a given receiving
> CE for that connectivity matrix the set of SLOs and SLEs is effectively the
> sum of the set of SLOs and SLEs for each sending CE
>
> Yours Irrespectively,
>
> John
>
>
> presented
> arriving

---

From: John E Drake <[email-masked]>
Date: Mon, 27 Sep 2021 21:33:00 +0000

Greg,

As soon as I sent the email I realized 'sum' was an incorrect term.  However, for a given connectivity matrix the SLO/SLE between a given sender and the receivers for that connectivity matrix is as I described.

Yours Irrespectively,

John

Juniper Business Use Only
From: Greg Mirsky <[email-masked]>
Sent: Monday, September 27, 2021 5:21 PM
To: John E Drake <[email-masked]>
Cc: [email-masked]; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi John,
I suspect that not all SLOs at the receiving CE of the particular network slice can be presented as the sum of the corresponding SLOs defined for all senders to that CE. For example, BW SLO can be summarized. But I don't see that interpacket delay variation can be summarized to be useful for the receiver at the NSE.

Regards,
Greg

On Mon, Sep 27, 2021 at 11:00 AM John E Drake <jdrake=[email-masked]<mailto:[email-masked]>> wrote:
Adrian,

Yours Irrespectively,

John

> From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel
> <[email-masked]<mailto:[email-masked]>>; 'TEAS WG' <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>

_______________________________________________
Teas mailing list
[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!WHzpAonetXRJM0J7e-iPRxFZ4v-ylsUBV3-AVseNCUhy_6Ya-DaWtCryd2vX3q4$>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Sep 2021 17:38:16 -0400

It seems true that aggregating the sender SLOs inter-packet spacing will 
not tell you what inter-packet spacing the receiver can expect / require 
/ ...

But so what?  Unless we are talking about egress traffic shapers, the 
network is not going to enforce receiver-visible effects.  And so far, 
we have not included traffic shapers of any kind in our analysis 
(because they tend to be a mess, significantly worse than policers.

If Luis' request for receiver based SLOs was intended to bring egress 
shapers into the IETF network slice, I think it is a bad idea.  And if 
it is not intended to do that, I do not know what it is intended to do.

Yours,
Joel

On 9/27/2021 5:20 PM, Greg Mirsky wrote:
> Hi John,
> I suspect that not all SLOs at the receiving CE of the particular 
> network slice can be presented as the sum of the corresponding SLOs 
> defined for all senders to that CE. For example, BW SLO can be 
> summarized. But I don't see that interpacket delay variation can be 
> summarized to be useful for the receiver at the NSE.
> 
> Regards,
> Greg
> 
> On Mon, Sep 27, 2021 at 11:00 AM John E Drake 
> <jdrake=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Adrian,
> 
>     The current definition is that the for a given sending
>     CE/connectivity matrix the set of SLOs and SLEs apply to all
>     receiving CEs for that connectivity matrix.  Sending CEs are
>     independent, so for a given receiving CE for that connectivity
>     matrix the set of SLOs and SLEs is effectively the sum of the set of
>     SLOs and SLEs for each sending CE
> 
>     Yours Irrespectively,
> 
>     John
> 
> 
>      > From: Teas <[email-masked] <mailto:[email-masked]>>
>     On Behalf Of Adrian Farrel
>      > <[email-masked]
>     <mailto:[email-masked]>>; 'TEAS WG'
>     <[email-masked] <mailto:[email-masked]>>
>     <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N>
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Sep 2021 15:02:03 -0700

Hi Joel,
I agree with you that IPDV SLO at the egress seems only useful as the
threshold value, not as a target that the egress may enforce. Further
extending the distributed model, in some realization of a network slice,
SLOs can be used at the egress edge to monitor the conformance of the
network slice.

Regards,
Greg

On Mon, Sep 27, 2021 at 2:38 PM Joel M. Halpern <[email-masked]> wrote:

> >     <

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 28 Sep 2021 09:02:26 +0000

Hi all,

Expressing the SLOs for both transmitters and receivers is necessary for a proper mapping and realization of slice requests by the IETF NSC. Let me give an example referring to two basic SLOs, bandwidth and latency.

Let’s consider a p2mp communication A -> {B, C, D} where each destination will receive from source A a flow of equal capacity Cap.

-          Bandwidth: If we only specify the SLO of the sender, which is 3*Cap, when mapping and realizing the slice for B, C and D, this way of proceeding would imply that a capacity of 3*Cap should be allocated for all of them (B, C and D). This clearly is a wastage of resources. It can be argued that an alternative way of expressing the need is to create 3 different matrices A -> B, A ->C and A ->D each of them specifying simply Cap. I think this is not the best way of expressing the connectivity matrix of a slice, since it implies further processing (i.e., the aggregation of needs on A for realizing that the total need is 3*Cap) and because it loses the nature of the service (p2mp), apart of probably requiring some extra information to handle the association of those “individual” matrices as part of an overarching connectivity matrix in the slice. It is much more simpler to add the receiver SLO for later mapping and realization.

-          Latency: by expressing the different latency requirements in B, C or D, it can be possible to assist on the realization of the slice, for instance by selecting “Technology Y” instead of “Technology X” to guarantee the delay limits of the receiver. Such a latency at B, C or D essentially could reflect the fact that part of the overall latency budget is spent on that endpoints for a given service, so it can assist on the decisions of the IETF NSC for determining the best slice realization solution to be within the limits of the overall latency budget and ensure proper service delivery.

Best regards

Luis

De: Greg Mirsky <[email-masked]>
Enviado el: martes, 28 de septiembre de 2021 0:02
Para: Joel M. Halpern <[email-masked]>
CC: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]; TEAS WG <[email-masked]>
Asunto: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi Joel,
I agree with you that IPDV SLO at the egress seems only useful as the threshold value, not as a target that the egress may enforce. Further extending the distributed model, in some realization of a network slice, SLOs can be used at the egress edge to monitor the conformance of the network slice.

Regards,
Greg

On Mon, Sep 27, 2021 at 2:38 PM Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
It seems true that aggregating the sender SLOs inter-packet spacing will
not tell you what inter-packet spacing the receiver can expect / require
/ ...

Yours,
Joel

On 9/27/2021 5:20 PM, Greg Mirsky wrote:
> <jdrake=[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Adrian,
>
>      > From: Teas <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      > <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; '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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 28 Sep 2021 09:34:42 +0000

Hi Joel,

What you commented here about egress traffic shapers resonates on my head. With traditional VPNs we look for a logically dedicated service with certain guarantees. I think that the point for slicing goes (or can go) beyond that, by looking for logically dedicated service with *strict* guarantees, for advance services with very stringent requirements. In that respect it will probably require to have enforcement points not only at the service ingress but also in other parts of the network, being the egress or some middle points. For sure, this is very much complex and messy, but maybe the only way of guaranteeing such strict requirements when using certain technology alternatives.

Best regards,

Luis

-----Mensaje original-----
De: Joel M. Halpern <[email-masked]>
Enviado el: lunes, 27 de septiembre de 2021 23:38
Para: Greg Mirsky <[email-masked]>
CC: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]; TEAS WG <[email-masked]>
Asunto: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

It seems true that aggregating the sender SLOs inter-packet spacing will not tell you what inter-packet spacing the receiver can expect / require / ...

But so what?  Unless we are talking about egress traffic shapers, the network is not going to enforce receiver-visible effects.  And so far, we have not included traffic shapers of any kind in our analysis (because they tend to be a mess, significantly worse than policers.

If Luis' request for receiver based SLOs was intended to bring egress shapers into the IETF network slice, I think it is a bad idea.  And if it is not intended to do that, I do not know what it is intended to do.

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 28 Sep 2021 06:50:38 -0400

I presume I am misreading your description below.

If the constraint is that A can send no more than "CAP" to A, CAP to B, 
and CAP to C, but is not worried about the total being sent, then the 
SLO needs to say that separately as explicit sender constraints.  We 
need to make sure that the the connectivity matrix can express that (I 
think it can).  Trying to express that as receiver constraints is 
misleading.  It is not that A can send 3*CAP to B, but B will only 
receive CAP.  It is that A is constrained in what they send.

Yours,
Joel

On 9/28/2021 5:02 AM, LUIS MIGUEL CONTRERAS MURILLO wrote:
> Hi all,
> 
> Expressing the SLOs for both transmitters and receivers is necessary for 
> a proper mapping and realization of slice requests by the IETF NSC. Let 
> me give an example referring to two basic SLOs, bandwidth and latency.
> 
> Let’s consider a p2mp communication A -> {B, C, D} where each 
> destination will receive from source A a flow of equal capacity Cap.
> 
> -Bandwidth: If we only specify the SLO of the sender, which is 3*Cap, 
> when mapping and realizing the slice for B, C and D, this way of 
> proceeding would imply that a capacity of 3*Cap should be allocated for 
> all of them (B, C and D). This clearly is a wastage of resources. It can 
> be argued that an alternative way of expressing the need is to create 3 
> different matrices A -> B, A ->C and A ->D each of them specifying 
> simply Cap. I think this is not the best way of expressing the 
> connectivity matrix of a slice, since it implies further processing 
> (i.e., the aggregation of needs on A for realizing that the total need 
> is 3*Cap) and because it loses the nature of the service (p2mp), apart 
> of probably requiring some extra information to handle the association 
> of those “individual” matrices as part of an overarching connectivity 
> matrix in the slice. It is much more simpler to add the receiver SLO for 
> later mapping and realization.
> 
> -Latency: by expressing the different latency requirements in B, C or D, 
> it can be possible to assist on the realization of the slice, for 
> instance by selecting “Technology Y” instead of “Technology X” to 
> guarantee the delay limits of the receiver. Such a latency at B, C or D 
> essentially could reflect the fact that part of the overall latency 
> budget is spent on that endpoints for a given service, so it can assist 
> on the decisions of the IETF NSC for determining the best slice 
> realization solution to be within the limits of the overall latency 
> budget and ensure proper service delivery.
> 
> Best regards
> 
> Luis
> 
> *De:*Greg Mirsky <[email-masked]>
> *Enviado el:* martes, 28 de septiembre de 2021 0:02
> *Para:* Joel M. Halpern <[email-masked]>
> *CC:* LUIS MIGUEL CONTRERAS MURILLO 
> <[email-masked]>; [email-masked]; TEAS 
> WG <[email-masked]>
> *Asunto:* Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per 
> receiver
> 
> Hi Joel,
> 
>     <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     Adrian,
>      >
>      >      > -----Original Message-----
>      >      > From: Teas <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      > Sent: Monday, September 27, 2021 12:37 PM
>      >      > To: 'LUIS MIGUEL CONTRERAS MURILLO'
>      >      > <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>; 'TEAS WG'
>      >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      > Subject: [Teas] Network slicing framework : Issue #3:
>     SLOs/SLEs
>      >     per receiver
>      >      >
>      >      > [External Email. Be cautious of content]
>      >      >
>      >      >
>      >      > Hi,
>      >      >
>      >      > Currently we say that SLOs/SLEs are specified for each
>     sender on each
>      >      > connectivity matrix. Thus, if we have A-B, A-C and A-{B,
>     C, D} we
>      >     would
>      >      > configure 3 sets of SLOs/SLEs describing the required
>     behaviour and
>      >      > performance of the three connectivity matrices in terms of the
>      >     traffic presented
>      >      > at A.
>      >      >
>      >      > Luis asks that we also consider configuring SLOs/SLE for the
>      >     receivers on those
>      >      > connectivity matrices.
>      >      >
>      >      > I would like Luis to comment more on this requirement as
>     (form my
>      >      > perspective) the SLOs/SLEs describe how traffic should be
>      >     serviced by the
>      >      > network, not the performance of the receiver. But the expected
>      >     traffic arriving
>      >      > at the receiver can be deduce from the traffic at the senders.
>      >      >
>      >      > If, on the other hand, the receiver knows that it must receive
>      >     traffic with no
>      >      > more than a certain jitter, this is (presumably) a feature
>     of the
>      >      > application/service being run over the slice so it is equally
>      >     configurable at the
>      >      > sender.
>      >      >
>      >      > Thanks,
>      >      > Adrian
>      >      >
>      >      > _______________________________________________
>      >      > Teas mailing list
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >
>      >
>     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
>      >   
>       <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>>
>      >      > Et6yMaO-gk!WHlUOHwVHgCbTvsslIOUbtuzc_c53VJCxP2Q25d3y-
>      >      > JnoPmU4ovtQ6bRJWriFrE$
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <https://www.ietf.org/mailman/listinfo/teas
>     <https://www.ietf.org/mailman/listinfo/teas>>
>      >
>      >
> ------------------------------------------------------------------------
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, 
> puede contener información privilegiada o confidencial y es para uso 
> exclusivo de la persona o entidad de destino. Si no es usted. el 
> destinatario indicado, queda notificado de que la lectura, utilización, 
> divulgación y/o copia sin autorización puede estar prohibida en virtud 
> de la legislación vigente. Si ha recibido este mensaje por error, le 
> rogamos que nos lo comunique inmediatamente por esta misma vía y proceda 
> a su destrucción.
> 
> The information contained in this transmission is privileged and 
> confidential information intended only for the use of the individual or 
> entity named above. If the reader of this message is not the intended 
> recipient, you are hereby notified that any dissemination, distribution 
> or copying of this communication is strictly prohibited. If you have 
> received this transmission in error, do not read it. Please immediately 
> reply to the sender that you have received this communication in error 
> and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
> destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
> senhoria o destinatário indicado, fica notificado de que a leitura, 
> utilização, divulgação e/ou cópia sem autorização pode estar proibida em 
> virtude da legislação vigente. Se recebeu esta mensagem por erro, 
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
> proceda a sua destruição

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 14:47:32 +0200

Hi,

Let me include following use case in this e-mail thread as well, related to SLO per receiver (egress shaping):

Imaging following use case. Vendor-X produces Ethernet switch (or IP router) with 48 x 1G ports, and SLO provided by this switch/router is:

- Guaranteed 1G ingress BW on each port
- Guaranteed 1G egress BW on each port
- Maximum latency between any two ports: ‘X’ microseconds.

As you see, there is no connectivity matrix in above SLO definitions. Does it mean, can I send 1G from each of 47 ports to remaining 48th port - absolutely not! 48th port has only 1G ingress/egress guarantee, not 47G.

Now, instead of having physical switch (or router) I would like to implement above as some sort of ‘virtual switch/router’ - as network slice service, with 48 end-points, each end-point having guaranteed 1G uplink/downlink capacity, and max latency between any two EPs ‘X’ milliseconds. Again, SLO is not defined here as connectivity matrix.

Above is very common in fact - many business VPN services use above approach in SLO definitions.

Best regards,
Krzysztof

> On 2021 -Sep-28, at 12:50, Joel Halpern Direct <[email-masked]> wrote:
> 
> If the constraint is that A can send no more than "CAP" to A, CAP to B, and CAP to C, but is not worried about the total being sent, then the SLO needs to say that separately as explicit sender constraints.  We need to make sure that the the connectivity matrix can express that (I think it can).  Trying to express that as receiver constraints is misleading.  It is not that A can send 3*CAP to B, but B will only receive CAP.  It is that A is constrained in what they send.
> 
> Yours,
> Joel
> 
>> -Bandwidth: If we only specify the SLO of the sender, which is 3*Cap, when mapping and realizing the slice for B, C and D, this way of proceeding would imply that a capacity of 3*Cap should be allocated for all of them (B, C and D). This clearly is a wastage of resources. It can be argued that an alternative way of expressing the need is to create 3 different matrices A -> B, A ->C and A ->D each of them specifying simply Cap. I think this is not the best way of expressing the connectivity matrix of a slice, since it implies further processing (i.e., the aggregation of needs on A for realizing that the total need is 3*Cap) and because it loses the nature of the service (p2mp), apart of probably requiring some extra information to handle the association of those “individual” matrices as part of an overarching connectivity matrix in the slice. It is much more simpler to add the receiver SLO for later mapping and realization.
>> -Latency: by expressing the different latency requirements in B, C or D, it can be possible to assist on the realization of the slice, for instance by selecting “Technology Y” instead of “Technology X” to guarantee the delay limits of the receiver. Such a latency at B, C or D essentially could reflect the fact that part of the overall latency budget is spent on that endpoints for a given service, so it can assist on the decisions of the IETF NSC for determining the best slice realization solution to be within the limits of the overall latency budget and ensure proper service delivery.
>> Best regards
>> Luis
>> *CC:* LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]; TEAS WG <[email-masked]>
>> *Asunto:* Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver
>> Hi Joel,
>> On Mon, Sep 27, 2021 at 2:38 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>>     >      > From: Teas <[email-masked]
>>     >      > Subject: [Teas] Network slicing framework : Issue #3:
>>    SLOs/SLEs
>>     >     per receiver
>>     >      >
>>     >      > connectivity matrix. Thus, if we have A-B, A-C and A-{B,
>>    C, D} we
>>     >     would

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Sep 2021 08:51:16 -0400

I think that this mixes several things.

1) Separate from the connectivity matrix, there are port definitions 
associated with the IETF Network Slice.  Those are a separate aspect of 
the service definition.

2) It is unclear from a sservice definition what it means to say that an 
egress guarantees a certain amount of egress bandwidth for a certain 
part of the service.

3) Conversely, I do not want to get into shaping traffic that is trying 
to leave the system to match an egress bandwidth limit.  Port handling 
and queue handling may drop traffic.   But shapers at egress produce 
really bad effects, and are not a normal part of routers.

Yours,
Joel

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 14:54:14 +0200

Hi Joel,

Not sure, what you mean by "shapers at egress produce really bad effects, and are not a normal part of routers”.

Typical business VPN deployments today use egress shapers at PE, and are in production at maaaaany operators.

Best regards,
Krzysztof

> On 2021 -Sep-28, at 14:51, Joel M. Halpern <[email-masked]> wrote:
> 
> 1) Separate from the connectivity matrix, there are port definitions associated with the IETF Network Slice.  Those are a separate aspect of the service definition.
> 
> 2) It is unclear from a sservice definition what it means to say that an egress guarantees a certain amount of egress bandwidth for a certain part of the service.
> 
> 3) Conversely, I do not want to get into shaping traffic that is trying to leave the system to match an egress bandwidth limit.  Port handling and queue handling may drop traffic.   But shapers at egress produce really bad effects, and are not a normal part of routers.
> 
> Yours,
> Joel
>

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 28 Sep 2021 13:35:05 +0000

Hi Joel,

Regarding the bandwidth example. If it was necessary to express the connectivity one by one (e.g., A -> B, A -> C, A -> D) instead of aggregated (i.e., A -> {B,C,D}) is precisely because of the receiver constraints, even they don't become expressed. Going in the aggregate form is simpler in my personal opinion. And for that, adding the receiver SLO facilitates the simplification.

Let me list the options for connectivity matrix in this example according to my understanding of the discussion:

1/ starting point in the draft today -- Connectivity matrix expressed in the form A (SLO_s=3*CAP) -> {B,C,D}, specifying only A SLO (in case of bandwidth example, it would be 3*CAP)
2/ per-connection view (in order to accommodate sender+receiver constraints) -- Connectivity matrix expressed in the form A (SLO_s=CAP) -> B, then A (SLO_s=CAP) -> C, then A (SLO_s=CAP) -> D.
3/ aggregated view (specifying SLOs per endpoint) -- A (SLO_s=3*CAP) -> {B(SLO_r=CAP), C(SLO_r=CAP), D(SLO_r=CAP)}

While 1 does not provide enough information (can motivate overprovisioning), 2 requires of further processing to link all the three per-connection matrices together for the slice realization (note that the same kind of service is considered for all the three connections). In my view 3 is a more efficient and comprehensive way of expressing the slice service need in this example.

By the way, being 3 richer in terms of information, I think that moving from 3 to 2 for those that could prefer that connectivity matrix model is always possible. But not the other way around.

Best regards

Luis

-----Mensaje original-----
De: Joel Halpern Direct <[email-masked]>
Enviado el: martes, 28 de septiembre de 2021 12:51
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
CC: [email-masked]; TEAS WG <[email-masked]>
Asunto: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Yours,
Joel

On 9/28/2021 5:02 AM, LUIS MIGUEL CONTRERAS MURILLO wrote:
> Hi all,
>
> Expressing the SLOs for both transmitters and receivers is necessary
> for a proper mapping and realization of slice requests by the IETF
> NSC. Let me give an example referring to two basic SLOs, bandwidth and latency.
>
> proceeding would imply that a capacity of 3*Cap should be allocated
> for all of them (B, C and D). This clearly is a wastage of resources.
> It can be argued that an alternative way of expressing the need is to
> create 3 different matrices A -> B, A ->C and A ->D each of them
> specifying simply Cap. I think this is not the best way of expressing
> the connectivity matrix of a slice, since it implies further
> processing (i.e., the aggregation of needs on A for realizing that the
> total need is 3*Cap) and because it loses the nature of the service
> (p2mp), apart of probably requiring some extra information to handle
> the association of those “individual” matrices as part of an
> overarching connectivity matrix in the slice. It is much more simpler
> to add the receiver SLO for later mapping and realization.
>
> -Latency: by expressing the different latency requirements in B, C or
> D, it can be possible to assist on the realization of the slice, for
> guarantee the delay limits of the receiver. Such a latency at B, C or
> D essentially could reflect the fact that part of the overall latency
> budget is spent on that endpoints for a given service, so it can
> assist on the decisions of the IETF NSC for determining the best slice
> *De:*Greg Mirsky <[email-masked]> *Enviado el:* martes, 28 de
> septiembre de 2021 0:02
> <[email-masked]>; [email-masked];
> TEAS WG <[email-masked]>
> extending the distributed model, in some realization of a network
> slice, SLOs can be used at the egress edge to monitor the conformance
> of the network slice.
>
> Regards,
>
> Greg
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su
> destinatario, puede contener información privilegiada o confidencial y
> es para uso exclusivo de la persona o entidad de destino. Si no es
> usted. el destinatario indicado, queda notificado de que la lectura,
> utilización, divulgación y/o copia sin autorización puede estar
> prohibida en virtud de la legislación vigente. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por
> esta misma vía y proceda a su destrucción.
>
> confidential information intended only for the use of the individual
> or entity named above. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited.
> If you have received this transmission in error, do not read it.
> Please immediately reply to the sender that you have received this
> communication in error and then delete it.
>
> utilização, divulgação e/ou cópia sem autorização pode estar proibida
> em virtude da legislação vigente. Se recebeu esta mensagem por erro,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Sep 2021 10:06:59 -0400

As I read it, the constraint you are trying to express is:
A can send up to CAP*3 total traffic.
A can send up to CAP traffic to each of B, C, and D.

While that can be expressed as a receiver constraint, that would merely 
require it to be translated to a sender traffic.  After all, if the 
traffic is going to be dropped at egress, we don't want to send it if we 
can help it.  And in this case the behavior is understandable and 
processable at ingress.
You can argue that the ingress specification is an implementation 
technique.  But from where I sit, it is actually the more natural 
specification.  And it is exactly as much information as the receiver 
specification.

Krzysztof has at least pointed to a real receiver limit, of the form 
"total egress traffic less than X".  I tend to see that as a port limit, 
rather than a connectivity matrix property.  I am concerned that putting 
egress traffic dropping into subsets of traffic (where this leads), 
creates the situation where we (the network) has done all the work of 
hauling the traffic, only to drop it for no reason.

Yours,
Joel

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Sep 2021 14:09:40 +0000

Hi,

Comment inline below.

As Joel correctly pointed out in one of his emails, the bandwidth of the attachment circuit between a CE and a PE serves as the rate limiter for traffic between that CE and PE, and that is completely independent of the connectivity matrices, although specifying a bandwidth greater than the attachment circuit bandwidth isn't particularly useful. 

Yours Irrespectively,

John

> From: Teas <[email-masked]> On Behalf Of LUIS MIGUEL CONTRERAS
> MURILLO
> Sent: Tuesday, September 28, 2021 9:35 AM
> To: Joel Halpern Direct <[email-masked]>
> Cc: [email-masked]; TEAS WG <[email-masked]>
> Regarding the bandwidth example. If it was necessary to express the
> connectivity one by one (e.g., A -> B, A -> C, A -> D) instead of aggregated (i.e.,
> A -> {B,C,D}) is precisely because of the receiver constraints, even they don't
> become expressed. Going in the aggregate form is simpler in my personal
> opinion. And for that, adding the receiver SLO facilitates the simplification.
> 
> 1/ starting point in the draft today -- Connectivity matrix expressed in the form A
> (SLO_s=3*CAP) -> {B,C,D}, specifying only A SLO (in case of bandwidth example,
> it would be 3*CAP) 
2/ per-connection view (in order to accommodate
> sender+receiver constraints) -- Connectivity matrix expressed in the form A
> (SLO_s=CAP) -> B, then A (SLO_s=CAP) -> C, then A (SLO_s=CAP) -> D.
> 3/ aggregated view (specifying SLOs per endpoint) -- A (SLO_s=3*CAP) ->
> {B(SLO_r=CAP), C(SLO_r=CAP), D(SLO_r=CAP)}
 
[JD]  This is incorrect.  For the connectivity matrix A->{B, C, D}, A has an SLO with a bandwidth X, which means that A sends X to the network and the network delivers X to {B, C, D}.   If
you had three connectivity matrices A->B, A->C, and A->D, and A has an SLO with a bandwidth X for each of them, then A sends 3X to the network and the network delivers X to B, C, and D.   

> 
> While 1 does not provide enough information (can motivate overprovisioning), 2
> requires of further processing to link all the three per-connection matrices
> together for the slice realization (note that the same kind of service is
> considered for all the three connections). In my view 3 is a more efficient and
> comprehensive way of expressing the slice service need in this example.
> 
> By the way, being 3 richer in terms of information, I think that moving from 3 to
> 2 for those that could prefer that connectivity matrix model is always possible.
> But not the other way around.
> 
> Best regards
> 
> Luis
> 
> 
> De: Joel Halpern Direct <[email-masked]> Enviado el: martes, 28 de
> septiembre de 2021 12:51
> Para: LUIS MIGUEL CONTRERAS MURILLO
> <[email-masked]>
> If the constraint is that A can send no more than "CAP" to A, CAP to B, and CAP
> to C, but is not worried about the total being sent, then the SLO needs to say
> that separately as explicit sender constraints.  We need to make sure that the
> the connectivity matrix can express that (I think it can).  Trying to express that as
> receiver constraints is misleading.  It is not that A can send 3*CAP to B, but B will
> only receive CAP.  It is that A is constrained in what they send.
> 
> Yours,
> Joel
> 
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N
> >
> >      >
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!
> N
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N
> >>
> Et6yMaO-
> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4
> $
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!
> NEt6yMaO-
> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4
> $ >
> >      >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!
> NEt6yMaO-
> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4
> $
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!
> NEt6yMaO-
> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4
> $ >>
> >      >
> >      >
> Et6yMaO-
> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4
> $
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!
> NEt6yMaO-
> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4
> $ >
> >      >
> >
> >
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede
> contener información privilegiada o confidencial y es para uso exclusivo de la
> persona o entidad de destino. Si no es usted. el destinatario indicado, queda
> notificado de que la lectura, utilización, divulgación y/o copia sin autorización
> puede estar prohibida en virtud de la legislación vigente. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por esta
> misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and confidential
> information intended only for the use of the individual or entity named above. If
> the reader of this message is not the intended recipient, you are hereby notified
> that any dissemination, distribution or copying of this communication is strictly
> prohibited. If you have received this transmission in error, do not read it. Please
> immediately reply to the sender that you have received this communication in
> error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo da
> pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado,
> fica notificado de que a leitura, utilização, divulgação e/ou cópia sem
> autorização pode estar proibida em virtude da legislação vigente. Se recebeu
> esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por
> esta mesma via e proceda a sua destruição
> Et6yMaO-
> gk!Qchhd6Bgc5h7Twxl_EfcCZP161oX_59FsYBAuTgJNnate22fcCi80yeVVVkzZW4
> $

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Sep 2021 14:24:37 +0000

Hi,

Comment inline below.

Yours Irrespectively,

John

> From: Teas <[email-masked]> On Behalf Of Krzysztof Szarkowicz
> Sent: Tuesday, September 28, 2021 8:54 AM
> To: Joel M. Halpern <[email-masked]>
> Cc: Luis Miguel Contreras Murillo
> <[email-masked]>; [email-masked]; TEAS WG
> <[email-masked]>

[JD]  I think to what you are referring is the attachment circuit bandwidth between a CE and a PE, which is completely independent of the connectivity matrices.   

> > 1) Separate from the connectivity matrix, there are port definitions associated
> with the IETF Network Slice.  Those are a separate aspect of the service
> definition.
> >
> > 2) It is unclear from a sservice definition what it means to say that an egress
> guarantees a certain amount of egress bandwidth for a certain part of the
> service.
> >
> > 3) Conversely, I do not want to get into shaping traffic that is trying to leave
> the system to match an egress bandwidth limit.  Port handling and queue
> handling may drop traffic.   But shapers at egress produce really bad effects, and
> are not a normal part of routers.
> >
> > Yours,
> > Joel
> >
> >> Imaging following use case. Vendor-X produces Ethernet switch (or IP router)
> with 48 x 1G ports, and SLO provided by this switch/router is:
> >> As you see, there is no connectivity matrix in above SLO definitions. Does it
> mean, can I send 1G from each of 47 ports to remaining 48th port - absolutely
> not! 48th port has only 1G ingress/egress guarantee, not 47G.
> >> Now, instead of having physical switch (or router) I would like to implement
> above as some sort of ‘virtual switch/router’ - as network slice service, with 48
> end-points, each end-point having guaranteed 1G uplink/downlink capacity, and
> max latency between any two EPs ‘X’ milliseconds. Again, SLO is not defined
> here as connectivity matrix.
> >>> If the constraint is that A can send no more than "CAP" to A, CAP to B, and
> CAP to C, but is not worried about the total being sent, then the SLO needs to
> say that separately as explicit sender constraints.  We need to make sure that
> the the connectivity matrix can express that (I think it can).  Trying to express
> that as receiver constraints is misleading.  It is not that A can send 3*CAP to B,
> but B will only receive CAP.  It is that A is constrained in what they send.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>>> Expressing the SLOs for both transmitters and receivers is necessary for a
> proper mapping and realization of slice requests by the IETF NSC. Let me give an
> example referring to two basic SLOs, bandwidth and latency.
> >>>> -Bandwidth: If we only specify the SLO of the sender, which is 3*Cap, when
> mapping and realizing the slice for B, C and D, this way of proceeding would
> imply that a capacity of 3*Cap should be allocated for all of them (B, C and D).
> This clearly is a wastage of resources. It can be argued that an alternative way
> of expressing the need is to create 3 different matrices A -> B, A ->C and A ->D
> each of them specifying simply Cap. I think this is not the best way of expressing
> the connectivity matrix of a slice, since it implies further processing (i.e., the
> aggregation of needs on A for realizing that the total need is 3*Cap) and
> because it loses the nature of the service (p2mp), apart of probably requiring
> some extra information to handle the association of those “individual” matrices
> as part of an overarching connectivity matrix in the slice. It is much more simpler
> >>>> -Latency: by expressing the different latency requirements in B, C or D, it
> can be possible to assist on the realization of the slice, for instance by selecting
> “Technology Y” instead of “Technology X” to guarantee the delay limits of the
> receiver. Such a latency at B, C or D essentially could reflect the fact that part of
> the overall latency budget is spent on that endpoints for a given service, so it
> can assist on the decisions of the IETF NSC for determining the best slice
> realization solution to be within the limits of the overall latency budget and
> ensure proper service delivery.
> >>>> Best regards
> >>>> Luis
> >>>> *De:*Greg Mirsky <[email-masked]> *Enviado el:* martes, 28
> >>>> de septiembre de 2021 0:02
> >>>> *Asunto:* Re: [Teas] Network slicing framework : Issue #3:
> >>>> SLOs/SLEs per receiver Hi Joel, I agree with you that IPDV SLO at
> >>>> the egress seems only useful as the threshold value, not as a target that
> the egress may enforce. Further extending the distributed model, in some
> realization of a network slice, SLOs can be used at the egress edge to monitor
> the conformance of the network slice.
> >>>> Regards,
> >>>> Greg
> Et6yMaO-gk!S5BsvTmWDq6TXqIT2-
> t7p5uL4SQsDFgGKB0jZynUIEKIyFddnra2GzNzb1tpkys$
> >>>>
> NEt6yMaO-gk!S5BsvTmWDq6TXqIT2-
> t7p5uL4SQsDFgGKB0jZynUIEKIyFddnra2GzNzb1tpkys$ >
> >>>>     >
> NEt6yMaO-gk!S5BsvTmWDq6TXqIT2-
> t7p5uL4SQsDFgGKB0jZynUIEKIyFddnra2GzNzb1tpkys$
> >>>>
> NEt6yMaO-gk!S5BsvTmWDq6TXqIT2-
> t7p5uL4SQsDFgGKB0jZynUIEKIyFddnra2GzNzb1tpkys$ >>
> >>>>     >
> >>>>     >
> Et6yMaO-gk!S5BsvTmWDq6TXqIT2-
> t7p5uL4SQsDFgGKB0jZynUIEKIyFddnra2GzNzb1tpkys$
> >>>>
> NEt6yMaO-gk!S5BsvTmWDq6TXqIT2-
> t7p5uL4SQsDFgGKB0jZynUIEKIyFddnra2GzNzb1tpkys$ >
> >>>>     >
> >>>> -------------------------------------------------------------------
> >>>> ----- Este mensaje y sus adjuntos se dirigen exclusivamente a su
> >>>> destinatario, puede contener información privilegiada o confidencial y es
> para uso exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización, divulgación
> y/o copia sin autorización puede estar prohibida en virtud de la legislación
> vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique
> inmediatamente por esta misma vía y proceda a su destrucción.
> confidential information intended only for the use of the individual or entity
> named above. If the reader of this message is not the intended recipient, you
> are hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this transmission in
> error, do not read it. Please immediately reply to the sender that you have
> received this communication in error and then delete it.
> >>>> destinatário, pode conter informação privilegiada ou confidencial e
> >>>> é para uso exclusivo da pessoa ou entidade de destino. Se não é
> >>>> vossa senhoria o destinatário indicado, fica notificado de que a
> >>>> leitura, utilização, divulgação e/ou cópia sem autorização pode
> >>>> estar proibida em virtude da legislação vigente. Se recebeu esta
> >>>> mensagem por erro, rogamos-lhe que nos o comunique imediatamente
> >>>> por esta mesma via e proceda a sua destruição
> >>>
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
> >>> as__;!!NEt6yMaO-gk!S5BsvTmWDq6TXqIT2-
> t7p5uL4SQsDFgGKB0jZynUIEKIyFddn
> >>> ra2GzNzb1tpkys$
> 
> Et6yMaO-gk!S5BsvTmWDq6TXqIT2-
> t7p5uL4SQsDFgGKB0jZynUIEKIyFddnra2GzNzb1tpkys$

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 28 Sep 2021 15:02:02 +0000

Hi John,

8< --
[JD]  This is incorrect.  For the connectivity matrix A->{B, C, D}, A has an SLO with a bandwidth X, which means that A sends X to the network and the network delivers X to {B, C, D}.
8< --

Do you mean that the network can deliver *up to* X for each of the three B, C, D, but summing up a total of X among the three? Or do you mean that the network replicates the X traffic generated by A to deliver X to B, to C and to D (=3X) in a sort of multicast?

If you refer to the first case, in case whatever of the other endpoints, e.g. B, can only support a fraction of X, we are in the same situation as I commented before. If you refer to the multicast case, that statement can be valid, but does not represent what I commented before.

Best regards

Luis

-----Mensaje original-----
De: John E Drake <[email-masked]>
Enviado el: martes, 28 de septiembre de 2021 16:10
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Joel Halpern Direct <[email-masked]>
CC: [email-masked]; TEAS WG <[email-masked]>
Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi,

Comment inline below.

Yours Irrespectively,

John

> connectivity one by one (e.g., A -> B, A -> C, A -> D) instead of
> aggregated (i.e., A -> {B,C,D}) is precisely because of the receiver
> constraints, even they don't become expressed. Going in the aggregate
> form is simpler in my personal opinion. And for that, adding the receiver SLO facilitates the simplification.
>
> Let me list the options for connectivity matrix in this example
> according to my understanding of the discussion:
>
> (SLO_s=3*CAP) -> {B,C,D}, specifying only A SLO (in case of bandwidth
> example, it would be 3*CAP)
> sender+receiver constraints) -- Connectivity matrix expressed in the
> sender+form A
> 3/ aggregated view (specifying SLOs per endpoint) -- A (SLO_s=3*CAP)
> -> {B(SLO_r=CAP), C(SLO_r=CAP), D(SLO_r=CAP)}

>
> While 1 does not provide enough information (can motivate
> overprovisioning), 2 requires of further processing to link all the
> three per-connection matrices together for the slice realization (note
> that the same kind of service is considered for all the three
> connections). In my view 3 is a more efficient and comprehensive way of expressing the slice service need in this example.
>
> De: Joel Halpern Direct <[email-masked]> Enviado el:
> martes, 28 de septiembre de 2021 12:51
> If the constraint is that A can send no more than "CAP" to A, CAP to
> B, and CAP to C, but is not worried about the total being sent, then
> the SLO needs to say that separately as explicit sender constraints.
> We need to make sure that the the connectivity matrix can express that
> (I think it can).  Trying to express that as receiver constraints is
> misleading.  It is not that A can send 3*CAP to B, but B will only receive CAP.  It is that A is constrained in what they send.
>
> Yours,
> Joel
>
> > NSC. Let me give an example referring to two basic SLOs, bandwidth
> > and
> latency.
> >
> > -Bandwidth: If we only specify the SLO of the sender, which is
> > 3*Cap, when mapping and realizing the slice for B, C and D, this way
> > of proceeding would imply that a capacity of 3*Cap should be
> > allocated for all of them (B, C and D). This clearly is a wastage of resources.
> > It can be argued that an alternative way of expressing the need is
> > to create 3 different matrices A -> B, A ->C and A ->D each of them
> > specifying simply Cap. I think this is not the best way of
> > expressing the connectivity matrix of a slice, since it implies
> > further processing (i.e., the aggregation of needs on A for
> > realizing that the total need is 3*Cap) and because it loses the
> > nature of the service (p2mp), apart of probably requiring some extra
> > information to handle the association of those “individual” matrices
> > as part of an overarching connectivity matrix in the slice. It is
> > much more simpler to add the receiver SLO for later mapping and realization.
> >
> > -Latency: by expressing the different latency requirements in B, C
> > or D, it can be possible to assist on the realization of the slice,
> > for instance by selecting “Technology Y” instead of “Technology X”
> > to guarantee the delay limits of the receiver. Such a latency at B,
> > C or D essentially could reflect the fact that part of the overall
> > latency budget is spent on that endpoints for a given service, so it
> > can assist on the decisions of the IETF NSC for determining the best
> > slice realization solution to be within the limits of the overall
> > latency budget and ensure proper service delivery.
> >
> > Best regards
> >
> > Luis
> >
> > I agree with you that IPDV SLO at the egress seems only useful as
> > the threshold value, not as a target that the egress may enforce.
> > Further extending the distributed model, in some realization of a
> > network slice, SLOs can be used at the egress edge to monitor the
> > conformance of the network slice.
> >
> > Regards,
> >
> > Greg
> >
> > --------------------------------------------------------------------
> > --
> > --
> >
> > destinatario, puede contener información privilegiada o confidencial
> > y es para uso exclusivo de la persona o entidad de destino. Si no es
> > mensaje por error, le rogamos que nos lo comunique inmediatamente
> > por esta misma vía y proceda a su destrucción.
> >
> > mensagem por erro, rogamos-lhe que nos o comunique imediatamente por
> mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
> Please immediately reply to the sender that you have received this communication in error and then delete it.
>

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Sep 2021 15:31:29 +0000

Hi,

Comments inline

Yours Irrespectively,

John

> From: LUIS MIGUEL CONTRERAS MURILLO
> Sent: Tuesday, September 28, 2021 11:02 AM
> To: John E Drake <[email-masked]>; Joel Halpern Direct
> <[email-masked]>
> Subject: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver
> 
> [JD]  This is incorrect.  For the connectivity matrix A->{B, C, D}, A has an SLO with
> a bandwidth X, which means that A sends X to the network and the network
> delivers X to {B, C, D}.
> 8< --
> 
> Do you mean that the network can deliver *up to* X for each of the three B, C,
> D, but summing up a total of X among the three? Or do you mean that the
> network replicates the X traffic generated by A to deliver X to B, to C and to D
> (=3X) in a sort of multicast?

[JD]  The latter 

> 
> If you refer to the first case, in case whatever of the other endpoints, e.g. B, can
> only support a fraction of X, we are in the same situation as I commented
> before. If you refer to the multicast case, that statement can be valid, but does
> not represent what I commented before.

[JD]  You described a connectivity matrix A->{B, C, D}.  This is a PT2MP connectivity matrix with a single sender, A, and single SLO, X, for it.  This is completely different than the
case of three PT2PT connectivity matrices, A->B, A->C, and A->D.      

> <[email-masked]>; Joel Halpern Direct
> <[email-masked]>
> As Joel correctly pointed out in one of his emails, the bandwidth of the
> attachment circuit between a CE and a PE serves as the rate limiter for traffic
> between that CE and PE, and that is completely independent of the connectivity
> matrices, although specifying a bandwidth greater than the attachment circuit
> bandwidth isn't particularly useful.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> [JD]  This is incorrect.  For the connectivity matrix A->{B, C, D}, A has an SLO with
> a bandwidth X, which means that A sends X to the network and the network
> delivers X to {B, C, D}.   If
> you had three connectivity matrices A->B, A->C, and A->D, and A has an SLO
> with a bandwidth X for each of them, then A sends 3X to the network and the
> network delivers X to B, C, and D.
> 
> >
> > connections). In my view 3 is a more efficient and comprehensive way of
> expressing the slice service need in this example.
> >
> > misleading.  It is not that A can send 3*CAP to B, but B will only receive CAP.  It
> is that A is constrained in what they send.
> >
> > Yours,
> > Joel
> >

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 28 Sep 2021 16:23:12 +0000

Hi John,

8< --

A p2mp connectivity matrix represents a hub and spoke architecture that do not necessarily implies the same content (a replica) should be received by all the spoke endpoints. At least this was my understanding. Thus you can have the same SLO (i.e., X) for all the endpoints or different ones (let's say X_b, X_c, etc) per endpoint.

If a p2mp matrix implies a multicast-like delivery then whatever which is not a multicast slice should be expressed as a collection of p2p matrices.

Best regards

Luis

-----Mensaje original-----
De: John E Drake <[email-masked]>
Enviado el: martes, 28 de septiembre de 2021 17:31
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Joel Halpern Direct <[email-masked]>
CC: [email-masked]; TEAS WG <[email-masked]>
Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi,

Comments inline

Yours Irrespectively,

John

> [JD]  This is incorrect.  For the connectivity matrix A->{B, C, D}, A
> has an SLO with a bandwidth X, which means that A sends X to the
> network and the network delivers X to {B, C, D}.
> 8< --
>
> Do you mean that the network can deliver *up to* X for each of the
> three B, C, D, but summing up a total of X among the three? Or do you
> mean that the network replicates the X traffic generated by A to
> deliver X to B, to C and to D

[JD]  The latter

>
> If you refer to the first case, in case whatever of the other
> endpoints, e.g. B, can only support a fraction of X, we are in the
> same situation as I commented before. If you refer to the multicast
> case, that statement can be valid, but does not represent what I commented before.

> As Joel correctly pointed out in one of his emails, the bandwidth of
> the attachment circuit between a CE and a PE serves as the rate
> limiter for traffic between that CE and PE, and that is completely
> independent of the connectivity matrices, although specifying a
> bandwidth greater than the attachment circuit bandwidth isn't particularly useful.
>
> Yours Irrespectively,
>
> John
>
>
> > From: Teas <[email-masked]> On Behalf Of LUIS MIGUEL
> > CONTRERAS MURILLO
> > constraints, even they don't become expressed. Going in the
> > aggregate form is simpler in my personal opinion. And for that,
> > adding the receiver SLO
> facilitates the simplification.
> >
> > (SLO_s=3*CAP) -> {B,C,D}, specifying only A SLO (in case of
> > bandwidth example, it would be 3*CAP)
> [JD]  This is incorrect.  For the connectivity matrix A->{B, C, D}, A
> has an SLO with a bandwidth X, which means that A sends X to the network and the network
> you had three connectivity matrices A->B, A->C, and A->D, and A has an
> SLO with a bandwidth X for each of them, then A sends 3X to the
> network and the network delivers X to B, C, and D.
>
> >
> > three per-connection matrices together for the slice realization
> > (note that the same kind of service is considered for all the three
> > We need to make sure that the the connectivity matrix can express
> > that (I think it can).  Trying to express that as receiver
> > constraints is misleading.  It is not that A can send 3*CAP to B,
> > but B will only receive CAP.  It
> > > Expressing the SLOs for both transmitters and receivers is
> > > necessary for a proper mapping and realization of slice requests
> > > by the IETF NSC. Let me give an example referring to two basic
> > > SLOs, bandwidth and
> > latency.
> > >
> > > 3*Cap, when mapping and realizing the slice for B, C and D, this
> > > way of proceeding would imply that a capacity of 3*Cap should be
> > > to create 3 different matrices A -> B, A ->C and A ->D each of
> > > them specifying simply Cap. I think this is not the best way of
> > > nature of the service (p2mp), apart of probably requiring some
> > > extra information to handle the association of those “individual”
> > > matrices as part of an overarching connectivity matrix in the
> > > slice. It is much more simpler to add the receiver SLO for later mapping and realization.
> > >
> > > or D, it can be possible to assist on the realization of the
> > > slice, for instance by selecting “Technology Y” instead of “Technology X”
> > > to guarantee the delay limits of the receiver. Such a latency at
> > > B, C or D essentially could reflect the fact that part of the
> > > overall latency budget is spent on that endpoints for a given
> > > service, so it can assist on the decisions of the IETF NSC for
> > > determining the best slice realization solution to be within the
> > > limits of the overall latency budget and ensure proper service delivery.
> > >
> > > Best regards
> > >
> > > Luis
> > >
> > > SLOs/SLEs per receiver
> > > On Mon, Sep 27, 2021 at 2:38 PM Joel M. Halpern
> > > <[email-masked] <mailto:[email-masked]>> wrote:
> > >
> > as
> > __;!!N
> > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te
> > as
> > __;!!N
> > >
> > >      >
> > >
> >
> > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te
> > as
> > __;!!N
> > >>
> > as
> > __;!!N
> > as
> > __;!!N
> > > destinatario, puede contener información privilegiada o
> > > confidencial y es para uso exclusivo de la persona o entidad de
> > > destino. Si no es usted. el destinatario indicado, queda
> > > notificado de que la lectura, utilización, divulgación y/o copia
> > > sin autorización puede estar prohibida en virtud de la legislación
> > > vigente. Si ha recibido este mensaje por error, le rogamos que nos
> > > lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
> > >
> > > confidential information intended only for the use of the
> > > individual or entity named above. If the reader of this message is
> > > not the intended recipient, you are hereby notified that any
> > > dissemination, distribution or copying of this communication is strictly prohibited.
> > > destinatário, pode conter informação privilegiada ou confidencial
> > > e é para uso exclusivo da pessoa ou entidade de destino. Se não é
> > as
> > __;!!N

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 28 Sep 2021 17:14:39 +0000 (UTC)

Hi Luis and All,
I think we need a clearer definition of connectivity matrix. IMHO it is neither a connection nor a cconnectivity between access points A and B. It is a matrix describing actual or potential connectivity between an access point A from a subset of access points to any other access point from the subset in a p2p or p2mp or mp2mp  manner. Homogeneous CM  has identical SLOs for all CM entries, while heterogeneous CM has different SLOs for some or all entries. Overlapping CMs describe overlapping subsets of access points
I have a problem with a topological node (e.g. VN) or network slice having multiple overlapping heterogeneous CMs.I do not have a problem with multiple non-overlappibg CMs or  with multiple homogeneous CMs with universal SLOs  per network slice.
Cheers,Igor

Sent from Yahoo Mail on Android 
 
  On Tue, Sep 28, 2021 at 12:23 PM, LUIS MIGUEL CONTRERAS MURILLO<[email-masked]> wrote:   Hi John,

8< --

Best regards

Luis

-----Mensaje original-----
De: John E Drake <[email-masked]>
Enviado el: martes, 28 de septiembre de 2021 17:31
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Joel Halpern Direct <[email-masked]>
CC: [email-masked]; TEAS WG <[email-masked]>
Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi,

Comments inline

Yours Irrespectively,

John

[JD]  The latter

> > >      > Hi John,
> > >      > I suspect that not all SLOs at the receiving CE of the particular
> > >      > network slice can be presented as the sum of the corresponding SLOs
> > >      > defined for all senders to that CE. For example, BW SLO can be
> > >      > summarized. But I don't see that interpacket delay variation can be
> > >      > summarized to be useful for the receiver at the NSE.
> > >      >
> > >      > Regards,
> > >      > Greg
> > >      >
> > >      > On Mon, Sep 27, 2021 at 11:00 AM John E Drake
> > >      > <jdrake=[email-masked]
> > >      > <mailto:[email-masked]
> > >      >    Adrian,
> > >      >    The current definition is that the for a given sending
> > >      >    CE/connectivity matrix the set of SLOs and SLEs apply to all
> > >      >    receiving CEs for that connectivity matrix.  Sending CEs are
> > >      >    independent, so for a given receiving CE for that connectivity
> > >      >    matrix the set of SLOs and SLEs is effectively the sum of the
> > >    set of
> > >      >    SLOs and SLEs for each sending CE
> > >      >
> > >      >    Yours Irrespectively,
> > >      >
> > >      >    John
> > >      >
> > >      >
> > >      >    Juniper Business Use Only
> > >      >
> > >      >      > -----Original Message-----
> > >      >      > From: Teas <[email-masked]
> > >      >    On Behalf Of Adrian Farrel
> > >      >      > Sent: Monday, September 27, 2021 12:37 PM
> > >      >      > To: 'LUIS MIGUEL CONTRERAS MURILLO'
> > >      >      > <[email-masked]
> > >      >    <mailto:[email-masked]
> > >      >    <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> > >    <mailto:[email-masked]>>>
> > >      >      > Subject: [Teas] Network slicing framework : Issue #3:
> > >    SLOs/SLEs
> > >      >    per receiver
> > >      >      >
> > >      >      > [External Email. Be cautious of content]
> > >      >      >
> > >      >      >
> > >      >      > Hi,
> > >      >      >
> > >      >      > Currently we say that SLOs/SLEs are specified for each
> > >    sender on each
> > >      >      > connectivity matrix. Thus, if we have A-B, A-C and A-{B,
> > >    C, D} we
> > >      >    would
> > >      >      > configure 3 sets of SLOs/SLEs describing the required
> > >    behaviour and
> > >      >      > performance of the three connectivity matrices in terms of the
> > >      >    traffic presented
> > >      >      > at A.
> > >      >      >
> > >      >      > Luis asks that we also consider configuring SLOs/SLE for the
> > >      >    receivers on those
> > >      >      > connectivity matrices.
> > >      >      >
> > >      >      > I would like Luis to comment more on this requirement as
> > >    (form my
> > >      >      > perspective) the SLOs/SLEs describe how traffic should be
> > >      >    serviced by the
> > >      >      > network, not the performance of the receiver. But the expected
> > >      >    traffic arriving
> > >      >      > at the receiver can be deduce from the traffic at the senders.
> > >      >      >
> > >      >      > If, on the other hand, the receiver knows that it must receive
> > >      >    traffic with no
> > >      >      > more than a certain jitter, this is (presumably) a feature
> > >    of the
> > >      >      > application/service being run over the slice so it is equally
> > >      >    configurable at the
> > >      >      > sender.
> > >      >      >
> > >      >      > Thanks,
> > >      >      > Adrian
> > >      >      >
> > >      >      > _______________________________________________
> > >      >      > Teas mailing list
> > >      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> > >    <mailto:[email-masked]>>
> > >      >      >
> > >      >
> > >
> > >      >      > Et6yMaO-gk!WHlUOHwVHgCbTvsslIOUbtuzc_c53VJCxP2Q25d3y-
> > >      >      > JnoPmU4ovtQ6bRJWriFrE$
> > >      >
> > >      > [email-masked] <mailto:[email-masked]>
> > >      >

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 19:22:16 +0200

Hi John,

I am referring to following use case, which cannot be modeled as connectivity matrix, with SLOs associated with each connectivity within the matrix.

Best regards,
Krzysztof

++++++++++++++++++

> On 2021 -Sep-28, at 16:24, John E Drake <[email-masked]> wrote:
> 
> Hi,
> 
> Comment inline below.
> 
> Yours Irrespectively,
> 
> John
> 
>

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Sep 2021 18:05:14 +0000

Krzysztof,

You have a set of 48 CEs each with a 1G attachment circuit.  You can define whatever connectivity matrices you want between these CEs.

Yours Irrespectively,

John

> From: Krzysztof Szarkowicz <[email-masked]>
> Sent: Tuesday, September 28, 2021 1:22 PM
> Cc: Joel M. Halpern <[email-masked]>; Luis Miguel Contreras Murillo
> I am referring to following use case, which cannot be modeled as connectivity
> matrix, with SLOs associated with each connectivity within the matrix.
> 
> Best regards,
> Krzysztof
> 
> 
> ++++++++++++++++++
> 
> >> Not sure, what you mean by "shapers at egress produce really bad
> >> effects, and are not a normal part of routers”.
> >>
> > [JD]  I think to what you are referring is the attachment circuit bandwidth
> between a CE and a PE, which is completely independent of the connectivity
> matrices.
> >
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >>> associated
> >> with the IETF Network Slice.  Those are a separate aspect of the
> >> service definition.
> >>>
> >> guarantees a certain amount of egress bandwidth for a certain part of
> >> the service.
> >>>
> >>>> Let me include following use case in this e-mail thread as well,
> >>>> related to SLO
> >> per receiver (egress shaping):
> >> mean, can I send 1G from each of 47 ports to remaining 48th port -
> >> absolutely not! 48th port has only 1G ingress/egress guarantee, not 47G.
> >> above as some sort of ‘virtual switch/router’ - as network slice
> >> service, with 48 end-points, each end-point having guaranteed 1G
> >> uplink/downlink capacity, and max latency between any two EPs ‘X’
> >> milliseconds. Again, SLO is not defined here as connectivity matrix.
> >> CAP to C, but is not worried about the total being sent, then the SLO
> >> needs to say that separately as explicit sender constraints.  We need
> >> to make sure that the the connectivity matrix can express that (I
> >> misleading.  It is not that A can send 3*CAP to B, but B will only receive CAP.
> It is that A is constrained in what they send.
> >>>>>
> >>>>> Yours,
> >>>>> Joel
> >>>>>
> >>>>>> necessary for a
> >> proper mapping and realization of slice requests by the IETF NSC. Let
> >>>>>> 3*Cap, when
> >> mapping and realizing the slice for B, C and D, this way of
> >> proceeding would imply that a capacity of 3*Cap should be allocated for all
> of them (B, C and D).
> >> This clearly is a wastage of resources. It can be argued that an
> >> alternative way of expressing the need is to create 3 different
> >> matrices A -> B, A ->C and A ->D each of them specifying simply Cap.
> >> I think this is not the best way of expressing the connectivity
> >> matrix of a slice, since it implies further processing (i.e., the
> >> aggregation of needs on A for realizing that the total need is 3*Cap)
> >> and because it loses the nature of the service (p2mp), apart of
> >> probably requiring some extra information to handle the association
> >> of those “individual” matrices as part of an overarching connectivity matrix in
> the slice. It is much more simpler to add the receiver SLO for later mapping and
> realization.
> >> can be possible to assist on the realization of the slice, for
> >> assist on the decisions of the IETF NSC for determining the best
> >> slice realization solution to be within the limits of the overall latency budget
> and ensure proper service delivery.
> >>>>>> Best regards
> >>>>>> Luis
> >>>>>> <[email-masked]>;
> >>>>>> [email-masked]; TEAS WG <[email-masked]>
> >> the egress may enforce. Further extending the distributed model, in
> >> some realization of a network slice, SLOs can be used at the egress
> >> edge to monitor the conformance of the network slice.
> >>>>>> Regards,
> >>>>>> Greg
> >>>>>>> I suspect that not all SLOs at the receiving CE of the
> >>>>>>> particular network slice can be presented as the sum of the
> >>>>>>> corresponding SLOs defined for all senders to that CE. For
> >>>>>>> example, BW SLO can be summarized. But I don't see that
> >>>>>>> interpacket delay variation can be summarized to be useful for the
> receiver at the NSE.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Greg
> >>>>>>>
> >>>>>> confidencial y es
> >> para uso exclusivo de la persona o entidad de destino. Si no es

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 28 Sep 2021 20:08:45 +0200

John,

Sorry, I couldn’t understand. Could you provide a concrete example (limiting to four CEs for simplicity).

Regards,
Krzysztof

> On 2021 -Sep-28, at 20:05, John E Drake <[email-masked]> wrote:
> 
> Krzysztof,
>

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Sep 2021 18:09:26 +0000

Comment inline

Yours Irrespectively,

John

> Sent: Tuesday, September 28, 2021 12:23 PM
> [JD]  You described a connectivity matrix A->{B, C, D}.  This is a PT2MP
> connectivity matrix with a single sender, A, and single SLO, X, for it.  This is
> completely different than the case of three PT2PT connectivity matrices, A->B,
> A->C, and A->D.
> 8< --
> 
> A p2mp connectivity matrix represents a hub and spoke architecture that do not
> necessarily implies the same content (a replica) should be received by all the
> spoke endpoints. At least this was my understanding. Thus you can have the
> same SLO (i.e., X) for all the endpoints or different ones (let's say X_b, X_c, etc)
> per endpoint.
> 
> If a p2mp matrix implies a multicast-like delivery then whatever which is not a
> multicast slice should be expressed as a collection of p2p matrices.

[JD]  Either N**2  P2P or N MP2P.

> [JD]  You described a connectivity matrix A->{B, C, D}.  This is a PT2MP
> connectivity matrix with a single sender, A, and single SLO, X, for it.  This is
> completely different than the case of three PT2PT connectivity matrices, A->B,
> A->C, and A->D.
> 
> >
> > Best regards
> >
> > Luis
> >
> >

---

From: <[email-masked]>
Date: Wed, 29 Sep 2021 06:30:49 +0000

Hi Adrian, all,

> arriving at the receiver can be deduce from the traffic at the senders.

Putting aside the control traffic, a connectivity slice service can be basically classified into: send-receive, send-only, receive-only. With such categorization, the modeling should allow for expressing receive-only without any reference to any (sending) CEs. 

There are of courses cases where the identity of the sending CE can be involved when describing a send-receive service.

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[email-masked]> De la part de Adrian Farrel
> Envoyé : lundi 27 septembre 2021 18:37
> À : 'LUIS MIGUEL CONTRERAS MURILLO'
> Objet : [Teas] Network slicing framework : Issue #3: SLOs/SLEs per
> receiver
> 
> Hi,
> 
> If, on the other hand, the receiver knows that it must receive traffic
> with no more than a certain jitter, this is (presumably) a feature of the

_________________________________________________________________________________________________________________________

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.

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 29 Sep 2021 07:51:01 +0000

Hi John,

Then it should be clearly stated in the draft that p2mp implies multicast-like delivery (i.e., replication, not addition of the different contributions to the receiving parties).

Best regards

Luis

-----Mensaje original-----
De: John E Drake <[email-masked]>
Enviado el: martes, 28 de septiembre de 2021 20:09
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Joel Halpern Direct <[email-masked]>
CC: [email-masked]; TEAS WG <[email-masked]>
Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Comment inline

Yours Irrespectively,

John

> [JD]  You described a connectivity matrix A->{B, C, D}.  This is a
> PT2MP connectivity matrix with a single sender, A, and single SLO, X,
> for it.  This is completely different than the case of three PT2PT
> connectivity matrices, A->B,
> A->C, and A->D.
> 8< --
>
> A p2mp connectivity matrix represents a hub and spoke architecture
> that do not necessarily implies the same content (a replica) should be
> received by all the spoke endpoints. At least this was my
> understanding. Thus you can have the same SLO (i.e., X) for all the
> endpoints or different ones (let's say X_b, X_c, etc) per endpoint.
>
> If a p2mp matrix implies a multicast-like delivery then whatever which
> is not a multicast slice should be expressed as a collection of p2p matrices.

> > [JD]  This is incorrect.  For the connectivity matrix A->{B, C, D},
> > A has an SLO with a bandwidth X, which means that A sends X to the
> > three B, C, D, but summing up a total of X among the three? Or do
> > you mean that the network replicates the X traffic generated by A to
> > case, that statement can be valid, but does not represent what I
> > commented
> before.
>
> [JD]  You described a connectivity matrix A->{B, C, D}.  This is a
> PT2MP connectivity matrix with a single sender, A, and single SLO, X,
> for it.  This is completely different than the case of three PT2PT
> connectivity matrices, A->B,
> A->C, and A->D.
>
> >
> > Best regards
> >
> > Luis
> >
> >
> > De: John E Drake <[email-masked]> Enviado el: martes, 28 de
> > septiembre de 2021 16:10
> > bandwidth greater than the attachment circuit bandwidth isn't
> > particularly
> useful.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > > Regarding the bandwidth example. If it was necessary to express
> > > the connectivity one by one (e.g., A -> B, A -> C, A -> D) instead
> > > of aggregated (i.e., A -> {B,C,D}) is precisely because of the
> > > receiver constraints, even they don't become expressed. Going in
> > > the aggregate form is simpler in my personal opinion. And for
> > > that, adding the receiver SLO
> > > sender+receiver constraints) -- Connectivity matrix expressed in
> > > sender+the form A
> > [JD]  This is incorrect.  For the connectivity matrix A->{B, C, D},
> > A has an SLO with a bandwidth X, which means that A sends X to the
> > network
> and the network
> > you had three connectivity matrices A->B, A->C, and A->D, and A has
> > an SLO with a bandwidth X for each of them, then A sends 3X to the
> > > overprovisioning), 2 requires of further processing to link all
> > > the three per-connection matrices together for the slice
> > > realization (note that the same kind of service is considered for
> > > all the three connections). In my view 3 is a more efficient and
> > > comprehensive way of
> > > 2 for those that could prefer that connectivity matrix model is
> > > always
> possible.
> > > If the constraint is that A can send no more than "CAP" to A, CAP
> > > to B, and CAP to C, but is not worried about the total being sent,
> > > then the SLO needs to say that separately as explicit sender constraints.
> > > > allocated for all of them (B, C and D). This clearly is a
> > > > wastage of
> resources.
> > > > It can be argued that an alternative way of expressing the need
> > > > is to create 3 different matrices A -> B, A ->C and A ->D each
> > > > of them specifying simply Cap. I think this is not the best way
> > > > of expressing the connectivity matrix of a slice, since it
> > > > implies further processing (i.e., the aggregation of needs on A
> > > > for realizing that the total need is 3*Cap) and because it loses
> > > > the nature of the service (p2mp), apart of probably requiring
> > > > some extra information to handle the association of those “individual”
> > > > slice. It is much more simpler to add the receiver SLO for later
> > > > mapping and
> realization.
> > > >
> > > > -Latency: by expressing the different latency requirements in B,
> > > > C or D, it can be possible to assist on the realization of the
> > > > *De:*Greg Mirsky <[email-masked]> *Enviado el:* martes,
> > > > 28 de septiembre de 2021 0:02
> > > > I agree with you that IPDV SLO at the egress seems only useful
> > > > as the threshold value, not as a target that the egress may enforce.
> > > > Further extending the distributed model, in some realization of
> > > > a network slice, SLOs can be used at the egress edge to monitor
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > --
> > > > --
> > > >
> > > > sin autorización puede estar prohibida en virtud de la
> > > > legislación vigente. Si ha recibido este mensaje por error, le
> > > > rogamos que nos lo comunique inmediatamente por esta misma vía y
> > > > proceda a su
> destrucción.
> > > >
> > > > individual or entity named above. If the reader of this message
> > > > is not the intended recipient, you are hereby notified that any
> > > > dissemination, distribution or copying of this communication is
> > > > strictly
> prohibited.
> > > > Please immediately reply to the sender that you have received
> > > > this communication in error and then delete it.
> > > >
> > > > destinatário, pode conter informação privilegiada ou
> > > > confidencial e é para uso exclusivo da pessoa ou entidade de
> > > > destino. Se não é vossa senhoria o destinatário indicado, fica
> > > > notificado de que a leitura, utilização, divulgação e/ou cópia
> > > > sem autorização pode estar proibida em virtude da legislação
> > > > vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos
> > > > o comunique imediatamente por esta mesma via e proceda a sua
> > > > destruição
> > >

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 29 Sep 2021 07:56:08 +0000

Hi Igor,

I agree we need more clarification on the connectivity matrix definition and interpretation to be processed by the NSC for proper mapping and realization.

Best regards

Luis

De: Igor Bryskin <[email-masked]>
Enviado el: martes, 28 de septiembre de 2021 19:15
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; John E Drake <[email-masked]>; Joel Halpern Direct <[email-masked]>
CC: [email-masked]; TEAS WG <[email-masked]>
Asunto: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi Luis and All,

I have a problem with a topological node (e.g. VN) or network slice having multiple overlapping heterogeneous CMs.
I do not have a problem with multiple non-overlappibg CMs or  with multiple homogeneous CMs with universal SLOs  per network slice.

Cheers,
Igor

Sent from Yahoo Mail on Android<https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>

On Tue, Sep 28, 2021 at 12:23 PM, LUIS MIGUEL CONTRERAS MURILLO
<[email-masked]<mailto:[email-masked]>> wrote:
Hi John,

8< --

Best regards

Luis

-----Mensaje original-----
De: John E Drake <[email-masked]<mailto:[email-masked]>>
Enviado el: martes, 28 de septiembre de 2021 17:31
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
CC: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi,

Comments inline

Yours Irrespectively,

John

> <[email-masked]<mailto:[email-masked]>>
> To: John E Drake <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct
> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>

[JD]  The latter

> De: John E Drake <[email-masked]<mailto:[email-masked]>>
> <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct
> <[email-masked]<mailto:[email-masked]>>
> CC: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
> > From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of LUIS MIGUEL
> > CONTRERAS MURILLO
> > To: Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
> > Cc: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
> > De: Joel Halpern Direct <[email-masked]<mailto:[email-masked]>> Enviado el:
> > <[email-masked]<mailto:[email-masked]>>
> > CC: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
> > > *De:*Greg Mirsky <[email-masked]<mailto:[email-masked]>> *Enviado el:* martes, 28
> > > *Para:* Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> > > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> > > TEAS WG <[email-masked]<mailto:[email-masked]>>
> > > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> > >
> > >    <mailto:[email-masked]<mailto:[email-masked]>>
> > >      > <mailto:[email-masked]<mailto:[email-masked]>
> > >    <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
> > >      >
> > >      >    Adrian,
> > >      >
> > >      >      > From: Teas <[email-masked]<mailto:[email-masked]>
> > >    <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> > >    <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >    <mailto:[email-masked]<mailto:[email-masked]>>
> > >      >    <mailto:[email-masked]<mailto:[email-masked]>
> > >    <mailto:[email-masked]<mailto:[email-masked]>>>>; 'TEAS WG'
> > >      >    <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> > >    <mailto:[email-masked]<mailto:[email-masked]>>>>
> > >      >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> > >    <mailto:[email-masked]<mailto:[email-masked]>>>
> > >      >      >
> > >      >
> > >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te>
> > as
> > __;!!N
> > >
> > >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> > >    <mailto:[email-masked]<mailto:[email-masked]>>>
> > >      >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te>
> > as
> > __;!!N
> > Et6yMaO-
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te>
> > as
> > __;!!N
> > Et6yMaO-
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te>
> > as
> > __;!!N
> > Et6yMaO-
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Sep 2021 12:11:05 +0100

Hi Luis,

Replying on this thread branch, but equally applicable to the exchange you're having with Igor.

Yes, our aim should be to get wording that is clear and captures our intent.

I deliberately started my cluster of issues with "Issue #1: What is a connectivity matrix?" because getting that definition clear (and right!) is fundamental to a lot of the other discussion. I think you and Igor are proving that this is correct - we have to tighten our definitions here.

In that thread I wrote

> Note that a p2mp connectivity matrix means that traffic placed on the matrix

> will be delivered to all the destination endpoints.

And then I asked

> Does the text in the draft need more clarity on this point?

Perhaps we should go back to what -04 currently says in Section 3.2

   A service provider instantiates an IETF network slice service for a

   customer.  The IETF network slice service is specified in terms of a

   set of the customer's endpoints (CEs), a set of one or more

   connectivity matrices (point-to-point (P2P), point-to-multipoint

   (P2MP), multipoint-to-point (MP2P), or multipoint- to-multipoint

   (MP2MP)) between subsets of these CEs, and a set of SLOs and SLEs for

   each CE sending to each connectivity matrix.  That is, in a given

   IETF Network Slice Service there may be one or more connectivity

   matrices of the same or different type, each connectivity matrix may

   be between a different subset of CEs, and for a given connectivity

   matrix each sending CE has its own set of SLOs and SLEs, and the SLOs

   and SLEs in each set may be different.  However, it is a free choice

   for a service provider to decide whether to implement a single

   connectivity matrix per IETF Network Slice Service, or to allow

   multiple matrices per slice.

   Note that in this context a "connectivity matrix" is a connection

   between a set of senders and a set of receivers.  Traffic sent by any

   sender in the matrix is delivered to all receivers (except back to

   itself).  Thus, a connectivity matrix may be treated in the manner of

   a virtual wire.

   It is also the case that a given sending CE may be part of multiple

   connectivity matrices within a single IETF network slice service, and

   the CE may have different SLOs and SLEs for each connectivity matrix

   to which it is sending.  Note that a given sending CE's SLOs and SLEs

   for a given connectivity matrix apply between it and each of the

   receiving CEs for that connectivity matrix.

   This approach results in the following possible connectivity

   matrices:

   o  For an MP2MP connectivity matrix with N CEs, each of the N sending

      CEs has its own set of SLOs and SLEs and they may all be

      different.

   o  For a P2MP connectivity matrix, there is only one sending CE, and

      there is only one set of SLOs and SLEs.

   o  For an MP2P connectivity matrix with N CEs, there is one receiving

      CE and (N - 1) sending CEs.  Each sending CE has its own set of

      SLOs and SLEs and they may all be different.

   o  For a P2P unidirectional connectivity matrix, there is only one

      sending CE and there is only one set of SLOs and SLEs.

   o  For a P2P bidirectional connectivity matrix, there are two sending

      CEs, there are two sets of SLOs and SLEs which may be different.

It would be excellent if you and Igor could indicate, in the light of what we have learnt in the current discussion, what changes to this text would be appropriate.

Thanks,

Adrian

-----Original Message-----
From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> 
Sent: 29 September 2021 08:51
To: John E Drake <[email-masked]>; Joel Halpern Direct <[email-masked]>
Cc: [email-masked]; TEAS WG <[email-masked]>
Subject: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi John,

Best regards

Luis

-----Mensaje original-----

Comment inline

Yours Irrespectively,

John

> Subject: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs

> Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per

> > Subject: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs

> > Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs

> > > Subject: Re: [Teas] Network slicing framework : Issue #3:

> > > 1/ starting point in the draft today -- Connectivity matrix

> > > expressed in the form A

> > > 3/ aggregated view (specifying SLOs per endpoint) -- A

> > > (SLO_s=3*CAP)

> > > By the way, being 3 richer in terms of information, I think that

> > > moving from 3 to

> > > Asunto: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs

> > > >     It seems true that aggregating the sender SLOs inter-packet spacing

> > > >     will

> > > >     not tell you what inter-packet spacing the receiver can expect /

> > > >     require

> > > >      >     matrix the set of SLOs and SLEs is effectively the sum of the

> > > >      >      > Currently we say that SLOs/SLEs are specified for each

> > > >      >      > configure 3 sets of SLOs/SLEs describing the required

> > > >      >      > performance of the three connectivity matrices in terms of the

> > > >      >      > Luis asks that we also consider configuring SLOs/SLE for the

> > > >      >      > I would like Luis to comment more on this requirement as

> > > >      >      > perspective) the SLOs/SLEs describe how traffic should be

> > > >      >      > network, not the performance of the receiver. But the expected

> > > >      >      > If, on the other hand, the receiver knows that it must receive

> > > >      >      > more than a certain jitter, this is (presumably) a feature

> > > >      >      > application/service being run over the slice so it is equally

> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/

> > > te

> > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/

> > > te

> > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/

> > > te

> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/

> > > te

> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/

> > > te

> > > lo comunique inmediatamente por esta

> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/

> > > te

> > por esta

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 29 Sep 2021 09:21:51 -0400

I am not sure I follow what youa re asking for Med.  You ask for a 
receive-only network slice service.

Clearly, there has to be some set of senders in the service.  (One can 
imagine limits on how traffic one receives from the Internet is 
delviered, but I do think that is part of an IETF Network Slice.

On the other hand, I do agree that even if there are a set of senders, 
there are meaningful use cases that specify properties of the egress 
delivery of the traffic at an endpoint independent of those endpoints.
I would expect to describe those as endpoint properties rather than as 
part of the connectivity matrix.  I do agree we need to include that.

Yours,
Joel

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Wed, 29 Sep 2021 16:01:33 +0200

Hi Adrian,

My 2 cents.

> On 2021 -Sep-29, at 13:11, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Luis,
>  

[Krzysztof] In above paragraph, I am missing SLO associated with the attachment circuit, i.e. in terms of uplink BW (guaranteed, maximum) and downlink BW (guaranteed, maximum), as only SLOs associated with connectivity matrixes are mentioned. For example, I don’t see, how following slice service can be implemented with above wording:

- Four CEs: A, B, C, D, connected via 1GE links to four PEs
- ingress/egress BW PE-CE attachment circuits: guaranteed: 100 Mbps, maximum: 200 Mbps (i.e. -> 900 Mbps on the attachment circuit might be used for other slice services)
- connectivity matrix MP2MP SLO: delay: 100 ms (note: no BW specified on connectivity matrix).

>    itself).  Thus, a connectivity matrix may be treated in the manner of

[Krzysztof] Above wording implies, within the slice connectivity matrix we have multicast/broadcast delivery. I am not sure, if this is intention of above paragraph. Shouldn't this paragraph say (or something similar):

   Note that in this context a "connectivity matrix" is a connection
   between a set of senders and a set of receivers.  Traffic sent by any
   sender in the matrix might be delivered - based on the routing/forwarding within the network slice service - to any receiver (except back to
   itself).  

> From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked] <mailto:[email-masked]>> 
> To: John E Drake <[email-masked] <mailto:[email-masked]>>; Joel Halpern Direct <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> De: John E Drake <[email-masked] <mailto:[email-masked]>>
> Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked] <mailto:[email-masked]>>; Joel Halpern Direct <[email-masked] <mailto:[email-masked]>>
> CC: [email-masked] <mailto:[email-masked]>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> > <[email-masked] <mailto:[email-masked]>>
> > To: John E Drake <[email-masked] <mailto:[email-masked]>>; Joel Halpern Direct
> > <[email-masked] <mailto:[email-masked]>>
> > Cc: [email-masked] <mailto:[email-masked]>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> > De: John E Drake <[email-masked] <mailto:[email-masked]>>
> > <[email-masked] <mailto:[email-masked]>>; Joel Halpern Direct
> > <[email-masked] <mailto:[email-masked]>>
> > CC: [email-masked] <mailto:[email-masked]>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> > > <[email-masked] <mailto:[email-masked]>>
> > > To: John E Drake <[email-masked] <mailto:[email-masked]>>; Joel Halpern Direct
> > > <[email-masked] <mailto:[email-masked]>>
> > > Cc: [email-masked] <mailto:[email-masked]>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> > > De: John E Drake <[email-masked] <mailto:[email-masked]>> Enviado el: martes, 28 de
> > > septiembre de 2021 16:10
> > > <[email-masked] <mailto:[email-masked]>>; Joel Halpern Direct
> > > <[email-masked] <mailto:[email-masked]>>
> > > CC: [email-masked] <mailto:[email-masked]>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> > > > From: Teas <[email-masked] <mailto:[email-masked]>> On Behalf Of LUIS MIGUEL
> > > > CONTRERAS MURILLO
> > > > To: Joel Halpern Direct <[email-masked] <mailto:[email-masked]>>
> > > > Cc: [email-masked] <mailto:[email-masked]>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> > > > De: Joel Halpern Direct <[email-masked] <mailto:[email-masked]>> Enviado el:
> > > > <[email-masked] <mailto:[email-masked]>>
> > > > CC: [email-masked] <mailto:[email-masked]>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> > > > > *De:*Greg Mirsky <[email-masked] <mailto:[email-masked]>> *Enviado el:* martes,
> > > > > *Para:* Joel M. Halpern <[email-masked] <mailto:[email-masked]>>
> > > > > <[email-masked] <mailto:[email-masked]>>;
> > > > > [email-masked] <mailto:[email-masked]>; TEAS WG <[email-masked] <mailto:[email-masked]>>
> > > > > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> > > > >
> > > > >      > <jdrake=[email-masked] <mailto:jdrake=[email-masked]>
> > > > >     <mailto:[email-masked] <mailto:[email-masked]>>
> > > > >      > <mailto:[email-masked] <mailto:[email-masked]>
> > > > >     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
> > > > >      >
> > > > >      >     Adrian,
> > > > >      >
> > > > >      >      > From: Teas <[email-masked] <mailto:[email-masked]>
> > > > >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> > > > >     <mailto:[email-masked] <mailto:[email-masked]>>>>
> > > > >      >      > <[email-masked] <mailto:[email-masked]>
> > > > >     <mailto:[email-masked] <mailto:[email-masked]>>
> > > > >      >     <mailto:[email-masked] <mailto:[email-masked]>
> > > > >     <mailto:[email-masked] <mailto:[email-masked]>>>>; 'TEAS WG'
> > > > >      >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> > > > >     <mailto:[email-masked] <mailto:[email-masked]>>>>
> > > > >      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> > > > >     <mailto:[email-masked] <mailto:[email-masked]>>>
> > > > >      >      >
> > > > >      >
> > > > >
> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/>
> > > > te
> > > > as
> > > > __;!!N
> > > > >
> > > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>
> > > > te
> > > > as
> > > > __;!!N
> > > > >
> > > > >      >
> > > > >
> > > >
> > >
> > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__>;!!
> > > > N
> > > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>
> > > > te
> > > > as
> > > > __;!!N
> > > > >>
> > > > >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> > > > >     <mailto:[email-masked] <mailto:[email-masked]>>>
> > > > >      >
> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/>
> > > > te
> > > > as
> > > > __;!!N
> > > > Et6yMaO-
> > > >
> > >
> > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__>;!!
> > > > NEt6yMaO-
> > > >
> > >
> > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__>;!!
> > > > NEt6yMaO-
> > > >
> > >
> > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__>;!!
> > > > NEt6yMaO-
> > > >
> > >
> > > > >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> > > > >      >
> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/>
> > > > te
> > > > as
> > > > __;!!N
> > > > Et6yMaO-
> > > >
> > >
> > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__>;!!
> > > > NEt6yMaO-
> > > >
> > >
> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/>
> > > > te
> > > > as
> > > > __;!!N
> > > > Et6yMaO-
> > > >
> > >
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>

---

From: Tarek Saad <[email-masked]>
Date: Wed, 29 Sep 2021 14:50:00 +0000

Hi Krzystof/all,

We have discussed a usecase of imposing a simulataneous rate-limit on a set of connections (e.g. emanating from same NSE) – such that they cannot simultaneously exceed a certain send rate. From NBI, I’ve discussed with co-authors at addressing this by creating a connection group and imposing such simulatenous SLOs on the set/group.

One way to model/address the usecase you’ve described below is by creating an  “any-to-any” network connectivity type – does not require to explicitly define connections between endpoints. To restrict all senders NSE from simultaneously overflowing any AC egress rate (1G in your example), one can define a connection group/set (in this case an all connections) and impose a simultaneous send rate limit (1G).

Regards,
Tarek

From: Teas <[email-masked]> on behalf of Krzysztof Szarkowicz <[email-masked]>
Date: Tuesday, September 28, 2021 at 8:47 AM
To: Joel Halpern Direct <[email-masked]>
Cc: Luis Miguel Contreras Murillo <[email-masked]>, [email-masked] <[email-masked]>, TEAS WG <[email-masked]>
Subject: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver
Hi,

Best regards,
Krzysztof

---

From: <[email-masked]>
Date: Wed, 29 Sep 2021 15:08:03 +0000

Hi Joel,

Please see inline. 

Cheers,
Med

Orange Restricted

> De : Joel M. Halpern <[email-masked]>
> Envoyé : mercredi 29 septembre 2021 15:22
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; 'TEAS WG'
> <[email-masked]>
> Objet : Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per
> receiver
> 

[Med] Yes

> 
> Clearly, there has to be some set of senders in the service. 

[Med] Sure, but the identity of the sender may not be known in advance ... and it may even be determined based on the requested connectivity guarantees. Consider the example of head-ends to serve content from a network. Based on the requested performance guarantees, a near-by or a more centralized head-end may be selected. I also provided the example of delay-sensitive slices where strict performance guarantees are required for the DNS traffic.

 (One can
> imagine limits on how traffic one receives from the Internet is delviered,
> but I do think that is part of an IETF Network Slice.
> 

[Med] Thanks.

> >> perspective) the SLOs/SLEs describe how traffic should be serviced by
> >> the network, not the performance of the receiver. But the expected
> >> traffic arriving at the receiver can be deduce from the traffic at the
> senders.
> >
> > Putting aside the control traffic, a connectivity slice service can be
> basically classified into: send-receive, send-only, receive-only. With
> such categorization, the modeling should allow for expressing receive-only
> without any reference to any (sending) CEs.
> >
> > There are of courses cases where the identity of the sending CE can be
> involved when describing a send-receive service.
> >
> > Cheers,
> > Med
> >
> >> De : Teas <[email-masked]> De la part de Adrian Farrel Envoyé
> >> : lundi 27 septembre 2021 18:37 À : 'LUIS MIGUEL CONTRERAS MURILLO'
> >> <[email-masked]>; 'TEAS WG'
> >> <[email-masked]> Objet : [Teas] Network slicing framework : Issue #3:
> >> SLOs/SLEs per receiver
> >>
> >> Hi,
> >>
> >> connectivity matrix. Thus, if we have A-B, A-C and A-{B, C, D} we
> >> would configure 3 sets of SLOs/SLEs describing the required behaviour
> >> and performance of the three connectivity matrices in terms of the
> >> traffic presented at A.
> >>
> >> receivers on those connectivity matrices.
> >>
> >> perspective) the SLOs/SLEs describe how traffic should be serviced by
> >> the network, not the performance of the receiver. But the expected
> >> traffic arriving at the receiver can be deduce from the traffic at the
> senders.
> >>
> >> traffic with no more than a certain jitter, this is (presumably) a
> >> feature of the application/service being run over the slice so it is
> >> equally configurable at the sender.
> >>
> >> Thanks,
> >> Adrian
> >>
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > 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.

---

From: John E Drake <[email-masked]>
Date: Wed, 29 Sep 2021 15:30:27 +0000

Krzysztof,

Connectivity matrices sit on top of attachment circuits and are ultimately bound by the their characteristics.  Adrian asked Joel and me to propose some text indicating this and its implications.  Before posting it, we will run it by you.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Krzysztof Szarkowicz
Sent: Wednesday, September 29, 2021 10:02 AM
To: Adrian Farrel <[email-masked]>
Cc: Luis Miguel Contreras Murillo <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi Adrian,

My 2 cents.

On 2021 -Sep-29, at 13:11, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Hi Luis,

In that thread I wrote

And then I asked

[Krzysztof] In above paragraph, I am missing SLO associated with the attachment circuit, i.e. in terms of uplink BW (guaranteed, maximum) and downlink BW (guaranteed, maximum), as only SLOs associated with connectivity matrixes are mentioned. For example, I don't see, how following slice service can be implemented with above wording:

Thanks,
Adrian

-----Original Message-----
From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>
Sent: 29 September 2021 08:51
To: John E Drake <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Hi John,

Best regards

Luis

-----Mensaje original-----
De: John E Drake <[email-masked]<mailto:[email-masked]>>
Enviado el: martes, 28 de septiembre de 2021 20:09
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
CC: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Asunto: RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per receiver

Comment inline

Yours Irrespectively,

John

> > De: John E Drake <[email-masked]<mailto:[email-masked]>> Enviado el: martes, 28 de
> > septiembre de 2021 16:10
> > > > Let's consider a p2mp communication A -> {B, C, D} where each
> > > > some extra information to handle the association of those "individual"
> > > > slice, for instance by selecting "Technology Y" instead of "Technology X"
> > > > *De:*Greg Mirsky <[email-masked]<mailto:[email-masked]>> *Enviado el:* martes,
> > > > <[email-masked]<mailto:[email-masked]>>;
> > > > [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
> > > > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
> > > >
> > > >      > <jdrake=[email-masked]<mailto:jdrake=[email-masked]>
> > > >      >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]
> > > >     <mailto:[email-masked]>>>
> > > >      >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]
> > > >     <mailto:[email-masked]>>
> > > >      >      >
> > > >      >
> > > >
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>
> > > te
> > > as
> > > __;!!N
> > > >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__>;!!
> > > N
> > > >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]
> > > >     <mailto:[email-masked]>>
> > > >      >
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>
> > > te
> > > as
> > > __;!!N
> > > Et6yMaO-
> > >
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__>;!!
> > > NEt6yMaO-
> > >
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__>;!!
> > > NEt6yMaO-
> > >
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__>;!!
> > > NEt6yMaO-
> > >
> >
> > > >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> > > >      >
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>
> > > te
> > > as
> > > __;!!N
> > > Et6yMaO-
> > >
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__>;!!
> > > NEt6yMaO-
> > >
> >
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>
> > > te
> > > as
> > > __;!!N
> > > Et6yMaO-
> > >
> >

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________
Teas mailing list
[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!R_LG1DFZqUm710uYLA9YNSIy8PGKPbgQKzi6Qj9YUhfQ71pzPN7nUQdV0YiEtRI$>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 29 Sep 2021 11:34:41 -0400

All the external definitions of neetwork slice we are trying to support, 
like our definitiosn of VPN, VTN, and similar, assume that the set of 
endpoints at any given time is known.  It may change.  If so, you 
re-provision / re-configure / re-specify.  But leaving the endpoints 
unspecified is not consistent with the models we have been discussing. 
I do not think that is a model we want to support.

As I said, I am happy to include egress SLO properties.   This might 
well include total bandwidth limits, bandwidth per traffic type limits, 
traffic prioritization rules, etc.  That does not lead to an IETF 
network slice service with unspecified endpoints.

Yours,
Joel

---

From: John E Drake <[email-masked]>
Date: Wed, 29 Sep 2021 15:46:19 +0000

Med,

There are two cases:

1)  Senders, e.g., an IPTV server either within the provider's network or attached to it, or receivers, e.g., the Internet, that are not in the set of the customer's  CEs.  This will be modelled as a set of ancillary CEs which supplement the set of the customer's CEs.  

2)  Traffic between CEs which transits an SFC within the provider's network.  This can be modelled by supplementing the set of SLOs and SLEs for a given sending CE to a given connectivity matrix with the definition of an SFC through which the sending CE's traffic needs to pass.  However, we haven't yet seen any detailed requirements for service function chaining.  

Yours Irrespectively,

John

> From: Teas <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Wednesday, September 29, 2021 11:08 AM
> To: Joel M. Halpern <[email-masked]>; 'TEAS WG' <[email-masked]>
> > De : Joel M. Halpern <[email-masked]> Envoyé : mercredi 29
> > septembre 2021 15:22 À : BOUCADAIR Mohamed INNOV/NET
> > <[email-masked]>; 'TEAS WG'
> > <[email-masked]>
> [Med] Sure, but the identity of the sender may not be known in advance ... and it
> may even be determined based on the requested connectivity guarantees.
> Consider the example of head-ends to serve content from a network. Based on
> the requested performance guarantees, a near-by or a more centralized head-
> end may be selected. I also provided the example of delay-sensitive slices where
> strict performance guarantees are required for the DNS traffic.
> 
>  (One can
> > >> perspective) the SLOs/SLEs describe how traffic should be serviced
> > >> by the network, not the performance of the receiver. But the
> > >> expected traffic arriving at the receiver can be deduce from the
> > >> traffic at the
> > senders.
> > >
> > such categorization, the modeling should allow for expressing
> > receive-only without any reference to any (sending) CEs.
> > >
> > >> Envoyé
> > >> Currently we say that SLOs/SLEs are specified for each sender on
> > >> each connectivity matrix. Thus, if we have A-B, A-C and A-{B, C, D}
> > >> we would configure 3 sets of SLOs/SLEs describing the required
> > >> behaviour and performance of the three connectivity matrices in
> > >> terms of the traffic presented at A.
> > >>
> > >> perspective) the SLOs/SLEs describe how traffic should be serviced
> > >> by the network, not the performance of the receiver. But the
> > >> expected traffic arriving at the receiver can be deduce from the
> > >> traffic at the
> > senders.
> > >>
> > >> feature of the application/service being run over the slice so it
> > >> is equally configurable at the sender.
> > >>
> > >> Thanks,
> > >> Adrian
> > >>
> > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/t
> > >> eas__;!!NEt6yMaO-gk!WA1LIlWpNTJWF9eU4IaU-
> rJqio63JheQxy7vmEllP6KK_wa
> > >> QPtvy5hMenSC9pTw$
> > >
> > >
> _________________________________________________________________
> ___
> > > __ ___________________________________________________
> > >
> > > 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
> > > 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.
> > >
> > > as__;!!NEt6yMaO-gk!WA1LIlWpNTJWF9eU4IaU-
> rJqio63JheQxy7vmEllP6KK_waQP
> > > tvy5hMenSC9pTw$
> > >
> 
> _________________________________________________________________
> ________________________________________________________
> 
> 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.
> Et6yMaO-gk!WA1LIlWpNTJWF9eU4IaU-
> rJqio63JheQxy7vmEllP6KK_waQPtvy5hMenSC9pTw$

---

From: <[email-masked]>
Date: Thu, 30 Sep 2021 04:57:15 +0000

Hi Joel, 

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 29 septembre 2021 17:35
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Joel M.
> Halpern <[email-masked]>; 'TEAS WG' <[email-masked]>
> endpoints at any given time is known.

[Med] but still, I don't see how we can associate ** global reachability ** to these services with a known endpoint. Even for the case of the VPN service we have the ability to indicate such support. For example, the L3NM which can be used as one of the candidate to implement a network slice supports the following:

   'external-connectivity-identifier':  This identifier refers to a
      profile that defines the external connectivity provided to a VPN
      service (or a subset of VPN sites).  An external connectivity may
      be an access to the Internet or a restricted connectivity such as
      access to a public/private cloud.

I do still think that we need not only restricted connectivity between a limited set of endpoints, but allow for wildcard (endpoint_set to/from ANY) to express connectivity requirements of some slices. 

  It may change.  If so, you re-
> provision / re-configure / re-specify.  But leaving the endpoints
> traffic prioritization rules, etc.

[Med] Great. Thanks.

  That does not lead to an IETF network
> slice service with unspecified endpoints.
> 
> Yours,
> Joel
> 
> >> Objet : Re: [Teas] Network slicing framework : Issue #3: SLOs/SLEs
> >> per receiver
> >>
> > [Med] Sure, but the identity of the sender may not be known in advance
> ... and it may even be determined based on the requested connectivity
> guarantees. Consider the example of head-ends to serve content from a
> network. Based on the requested performance guarantees, a near-by or a
> more centralized head-end may be selected. I also provided the example of
> delay-sensitive slices where strict performance guarantees are required
> for the DNS traffic.
> >
> >   (One can
> >> On the other hand, I do agree that even if there are a set of
> >> senders, there are meaningful use cases that specify properties of
> >> the egress delivery of the traffic at an endpoint independent of those
> endpoints.
> >> I would expect to describe those as endpoint properties rather than
> >> as part of the connectivity matrix.  I do agree we need to include
> that.
> >
> > [Med] Thanks.
> >
> >>
> >> Yours,
> >> Joel
> >>
> >> basically classified into: send-receive, send-only, receive-only.
> >> With such categorization, the modeling should allow for expressing

---

From: <[email-masked]>
Date: Thu, 30 Sep 2021 07:23:39 +0000

Hi John,

Please see inline. 

Cheers,
Med

> De : John E Drake <[email-masked]>
> Envoyé : mercredi 29 septembre 2021 17:46
> Cc : Adrian Farrel <[email-masked]>
> Objet : RE: [Teas] Network slicing framework : Issue #3: SLOs/SLEs per
> receiver
> 
> Med,
> 
> There are two cases:
> 
> 1)  Senders, e.g., an IPTV server either within the provider's network or
> attached to it, or receivers, e.g., the Internet, that are not in the set
> of the customer's  CEs.  This will be modelled as a set of ancillary CEs
> which supplement the set of the customer's CEs.

[Med] Sure. I had also that in mind but this assumes that that specific sources are explicated in the slice service request. The case I'm concerned about is when the source is not known in advance (but the content is) and that the selection of the source(s) will be a function of the requested performance characteristics. 

> 
> 2)  Traffic between CEs which transits an SFC within the provider's
> network.  This can be modelled by supplementing the set of SLOs and SLEs
> for a given sending CE to a given connectivity matrix with the definition
> of an SFC through which the sending CE's traffic needs to pass.  However,
> we haven't yet seen any detailed requirements for service function
> chaining.

[Med] Fully agree for the SFC part, but I don't think is relevant here. A flow can be terminated or serviced from the network slice WITHOUT having to TRANSIT the slice. Such a case does make an assumption that SFC is in use. Please consider a network slice that is designed for MEC-like services. The DNS part, in particular, should be optimized because otherwise the overall latency requirements won't be met if you have a server that is responsive with more than one 1s. Allowing for expressing {ENDPOINT_SET to/from ANY, DNS-classification-identification-rules, performance metrics} would just be straightforward to express such connectivity requirements.  

> guarantees.
> > Consider the example of head-ends to serve content from a network.
> > Based on the requested performance guarantees, a near-by or a more
> > centralized head- end may be selected. I also provided the example of
> > > >> serviced by the network, not the performance of the receiver. But
> > > >> the expected traffic arriving at the receiver can be deduce from
> > > >> the traffic at the
> > > senders.
> > > >
> > > >> each connectivity matrix. Thus, if we have A-B, A-C and A-{B, C,
> > > >> D} we would configure 3 sets of SLOs/SLEs describing the required
> > > >> serviced by the network, not the performance of the receiver. But
> > > >> the expected traffic arriving at the receiver can be deduce from
> > > >> the traffic at the
> > > senders.
> > > >>
> > > >> traffic with no more than a certain jitter, this is (presumably)
> > > >> a feature of the application/service being run over the slice so
> > > >> it is equally configurable at the sender.
> > > >>
> > > >> Thanks,
> > > >> Adrian
> > > >>
> > > d'alteration, Orange decline toute responsabilite si ce message a
> > > ete altere, deforme ou falsifie. Merci.
> > > >
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.

---

From: <[email-masked]>
Date: Thu, 30 Sep 2021 07:30:23 +0000

Re-,

> [Med] Fully agree for the SFC part, but I don't think is relevant here. A
> flow can be terminated or serviced from the network slice WITHOUT having
> to TRANSIT the slice. Such a case does make an assumption that SFC is in
> use. 

Apologies, but I wanted to say: "Such a case does NOT make an assumption that SFC is..."

Cheers,
Med

> De : Teas <[email-masked]> De la part de
> Envoyé : jeudi 30 septembre 2021 09:24
> À : John E Drake <[email-masked]>; Joel M. Halpern
> <[email-masked]>; 'TEAS WG' <[email-masked]>
> > De : John E Drake <[email-masked]> Envoyé : mercredi 29 septembre
> > 2021 17:46 À : BOUCADAIR Mohamed INNOV/NET
> > <[email-masked]>; Joel M.
> > Halpern <[email-masked]>; 'TEAS WG' <[email-masked]> Cc : Adrian
> > Farrel <[email-masked]> Objet : RE: [Teas] Network slicing
> > framework : Issue #3: SLOs/SLEs per receiver
> >
> > Med,
> >
> > There are two cases:
> >
> > 1)  Senders, e.g., an IPTV server either within the provider's network
> > or attached to it, or receivers, e.g., the Internet, that are not in
> > the set of the customer's  CEs.  This will be modelled as a set of
> > ancillary CEs which supplement the set of the customer's CEs.
> 
> [Med] Sure. I had also that in mind but this assumes that that specific
> sources are explicated in the slice service request. The case I'm
> concerned about is when the source is not known in advance (but the
> content is) and that the selection of the source(s) will be a function of
> the requested performance characteristics.
> 
> >
> > network.  This can be modelled by supplementing the set of SLOs and
> > SLEs for a given sending CE to a given connectivity matrix with the
> > definition of an SFC through which the sending CE's traffic needs to
> > pass.  However, we haven't yet seen any detailed requirements for
> > service function chaining.
> 
> [Med] Fully agree for the SFC part, but I don't think is relevant here. A
> flow can be terminated or serviced from the network slice WITHOUT having
> to TRANSIT the slice. Such a case does make an assumption that SFC is in
> use. Please consider a network slice that is designed for MEC-like
> services. The DNS part, in particular, should be optimized because
> otherwise the overall latency requirements won't be met if you have a
> server that is responsive with more than one 1s. Allowing for expressing
> {ENDPOINT_SET to/from ANY, DNS-classification-identification-rules,
> performance metrics} would just be straightforward to express such
> connectivity requirements.
> 
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > > [Med] Sure, but the identity of the sender may not be known in
> > > advance ... and it may even be determined based on the requested
> > > connectivity
> > guarantees.
> > > centralized head- end may be selected. I also provided the example
> > > of delay-sensitive slices where strict performance guarantees are
> > > required
> > for the DNS traffic.
> > >
> > >  (One can
> > > > I would expect to describe those as endpoint properties rather
> > > > than as part of the connectivity matrix.  I do agree we need to
> > > > include
> > that.
> > >
> > > [Med] Thanks.
> > >
> > > >
> > > > Yours,
> > > > Joel
> > > >
> > > > >> serviced by the network, not the performance of the receiver.
> > > > >> But the expected traffic arriving at the receiver can be deduce
> > > > >> from the traffic at the
> > > > senders.
> > > > >
> > > > >> <[email-masked]> Objet : [Teas] Network slicing framework :
> > > > >> Issue
> > #3:
> > > > >> SLOs/SLEs per receiver
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> Currently we say that SLOs/SLEs are specified for each sender
> > > > >> on each connectivity matrix. Thus, if we have A-B, A-C and
> > > > >> A-{B, C, D} we would configure 3 sets of SLOs/SLEs describing
> > > > >> the required behaviour and performance of the three
> > > > >> connectivity matrices in terms of the traffic presented at A.
> > > > >>
> > > > >> serviced by the network, not the performance of the receiver.
> > > > >> But the expected traffic arriving at the receiver can be deduce
> > > > >> from the traffic at the
> > > > senders.
> > > > >>
> > > > >> traffic with no more than a certain jitter, this is
> > > > >> (presumably) a feature of the application/service being run
> > > > >> over the slice so it is equally configurable at the sender.
> > > > >>
> > > > >> Thanks,
> > > > >> Adrian
> > > > >>
> > > > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin
> > > > >> fo
> > > > >> /t
> > > > > 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
> > > > > If you have received this email in error, please notify the
> > > > > sender and
> > > detruire ainsi que les pieces jointes. Les messages electroniques
> > > etant susceptibles d'alteration, Orange decline toute responsabilite
> > > si ce message a ete
> > > and delete this message and its attachments.
> > > have been modified, changed or falsified.
> > > Thank you.
> > >
> __________________________________________________________________________
> 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
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.

---

From: John E Drake <[email-masked]>
Date: Thu, 30 Sep 2021 12:38:11 +0000

Med,

Comments inline.

Yours Irrespectively,

John

> From: [email-masked] <[email-masked]>
> Sent: Thursday, September 30, 2021 3:24 AM
> To: John E Drake <[email-masked]>; Joel M. Halpern
> Cc: Adrian Farrel <[email-masked]>
> [Med] Sure. I had also that in mind but this assumes that that specific sources
> are explicated in the slice service request. The case I'm concerned about is when
> the source is not known in advance (but the content is) and that the selection of
> the source(s) will be a function of the requested performance characteristics.

[JD]  I'm sorry I wasn't clearer.  I was fully expecting that the ancillary CEs could or would be placeholders 

> [Med] Fully agree for the SFC part, but I don't think is relevant here. A flow can
> be terminated or serviced from the network slice WITHOUT having to TRANSIT
> the slice. Such a case does make an assumption that SFC is in use. Please
> consider a network slice that is designed for MEC-like services. The DNS part, in
> particular, should be optimized because otherwise the overall latency
> requirements won't be met if you have a server that is responsive with more
> than one 1s. Allowing for expressing {ENDPOINT_SET to/from ANY, DNS-
> classification-identification-rules, performance metrics} would just be
> straightforward to express such connectivity requirements.

[JD]  I think this would just be another connectivity matrix with its own SLOs and SLEs

---

From: <[email-masked]>
Date: Thu, 30 Sep 2021 12:44:22 +0000

Re-,

Seems that we are in agreement, John. 

Looking forward to seeing this reflected in the I-D :-)

Thank you. 

Cheers,
Med

> Envoyé : jeudi 30 septembre 2021 14:38
> > > 1)  Senders, e.g., an IPTV server either within the provider's
> > > network or attached to it, or receivers, e.g., the Internet, that
> > > are not in the set of the customer's  CEs.  This will be modelled as
> > > a set of ancillary CEs which supplement the set of the customer's CEs.
> >
> > [Med] Sure. I had also that in mind but this assumes that that
> > specific sources are explicated in the slice service request. The case
> > I'm concerned about is when the source is not known in advance (but
> > the content is) and that the selection of the source(s) will be a
> function of the requested performance characteristics.
> 
> [JD]  I'm sorry I wasn't clearer.  I was fully expecting that the
> ancillary CEs could or would be placeholders
> 
> >
> > >
> > [Med] Fully agree for the SFC part, but I don't think is relevant
> > here. A flow can be terminated or serviced from the network slice
> > WITHOUT having to TRANSIT the slice. Such a case does make an
> > assumption that SFC is in use. Please consider a network slice that is
> > designed for MEC-like services. The DNS part, in particular, should be
> > optimized because otherwise the overall latency requirements won't be
> > met if you have a server that is responsive with more than one 1s.
> > Allowing for expressing {ENDPOINT_SET to/from ANY, DNS-
> > > > > Objet : Re: [Teas] Network slicing framework : Issue #3:
> > > > > SLOs/SLEs per receiver
> > > > >
> > > > > I am not sure I follow what youa re asking for Med.  You ask for
> > > > > a receive-only network slice service.
> > > >
> > > > [Med] Yes
> > > >
> > > > >
> > > > > senders, there are meaningful use cases that specify properties
> > > > > of the egress delivery of the traffic at an endpoint independent
> > > > > of those
> > > endpoints.
> > > > > >> But the expected traffic arriving at the receiver can be
> > > > > >> deduce from the traffic at the
> > > > > senders.
> > > > > >
> > > > > With such categorization, the modeling should allow for
> > > > > expressing receive-only without any reference to any (sending)
> CEs.
> > > > > >
> > > > > >> But the expected traffic arriving at the receiver can be
> > > > > >> deduce from the traffic at the
> > > > > senders.
> > > > > >>
> > > > > >> If, on the other hand, the receiver knows that it must
> > > > > >> receive traffic with no more than a certain jitter, this is
> > > > > > 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.
> > > > > >
> > > > > > As emails may be altered, Orange is not liable for messages
> > > > > > that have
> > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi
> > > > > > nf
> > > > > > o/
> > > > > > te
> > > > etant susceptibles d'alteration, Orange decline toute
> > > > privileged information that may be protected by law; they should
> > > > not be distributed, used or copied without authorisation.

---

From: John E Drake <[email-masked]>
Date: Thu, 30 Sep 2021 12:55:39 +0000

You're most welcome.  We'll probably cover these points in a separate section in order to highlight them.  

Yours Irrespectively,

John

> Sent: Thursday, September 30, 2021 8:44 AM
> > De : John E Drake <[email-masked]> Envoyé : jeudi 30 septembre
> > 2021 14:38 À : BOUCADAIR Mohamed INNOV/NET
> > > > Halpern <[email-masked]>; 'TEAS WG' <[email-masked]> Cc :
> > > > Adrian Farrel <[email-masked]> Objet : RE: [Teas] Network
> > > > slicing framework : Issue #3: SLOs/SLEs per receiver
> > > >
> > > > Med,
> > > >
> > > > There are two cases:
> > > >
> > > > are not in the set of the customer's  CEs.  This will be modelled
> > > > as a set of ancillary CEs which supplement the set of the customer's CEs.
> > >
> > > specific sources are explicated in the slice service request. The
> > > case I'm concerned about is when the source is not known in advance
> > > (but the content is) and that the selection of the source(s) will be
> > > a
> > > > 2)  Traffic between CEs which transits an SFC within the
> > > > provider's network.  This can be modelled by supplementing the set
> > > > of SLOs and SLEs for a given sending CE to a given connectivity
> > > > matrix with the definition of an SFC through which the sending
> > > > CE's traffic needs to pass.  However, we haven't yet seen any
> > > > detailed requirements for service function chaining.
> > >
> > > assumption that SFC is in use. Please consider a network slice that
> > > is designed for MEC-like services. The DNS part, in particular,
> > > should be optimized because otherwise the overall latency
> than one 1s.
> > > > > > De : Joel M. Halpern <[email-masked]> Envoyé : mercredi
> > > > > > 29 septembre 2021 15:22 À : BOUCADAIR Mohamed INNOV/NET
> > > > > > I am not sure I follow what youa re asking for Med.  You ask
> > > > > > for a receive-only network slice service.
> > > > >
> > > > > [Med] Yes
> > > > >
> > > > > >
> > > > > Based on the requested performance guarantees, a near-by or a
> > > > > more centralized head- end may be selected. I also provided the
> > > > > example of delay-sensitive slices where strict performance
> > > > > guarantees are required
> > > > for the DNS traffic.
> > > > >
> > > > >  (One can
> > > > > > imagine limits on how traffic one receives from the Internet
> > > > > > is delviered, but I do think that is part of an IETF Network Slice.
> > > > > >
> > > > > > senders, there are meaningful use cases that specify
> > > > > > properties of the egress delivery of the traffic at an
> > > > > > endpoint independent of those
> > > > endpoints.
> > > > > > than as part of the connectivity matrix.  I do agree we need
> > > > > > to include
> > > > that.
> > > > >
> > > > > [Med] Thanks.
> > > > >
> > > > > >
> > > > > > Yours,
> > > > > > Joel
> > > > > >
> > > > > > >> -----Message d'origine----- De : Teas
> > > > > > >> <[email-masked]> De la part de Adrian Farrel Envoyé
> > > > > > >> sender on each connectivity matrix. Thus, if we have A-B,
> > > > > > >> A-C and A-{B, C, D} we would configure 3 sets of SLOs/SLEs
> > > > > > >> describing the required behaviour and performance of the
> > > > > > >> three connectivity matrices in terms of the traffic presented at A.
> > > > > > >>
> > > > > > >> Luis asks that we also consider configuring SLOs/SLE for
> > > > > > >> the receivers on those connectivity matrices.
> > > > > > >>
> > > > > > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/li
> > > > > > >> st
> > > > > > >> in
> > > > > > >> fo
> > > > > > >> /t
> > > > > > > Si vous avez recu ce message par erreur, veuillez le
> > > > > > > signaler a l'expediteur et le detruire ainsi que
> > > > > 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
> > > > > sender and delete this message and its attachments.