Subject: [Teas] Network Slicing design team definitions - isolation and resolution

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Apr 2020 20:56:22 -0400

I have serious problems with these aspects of the document.

Let's start with the first discussion of isolation.  This occurs in the 
description of the security objective.  I have no problem with including 
observable security properties in objectives.  telling the customer 
"your traffic will be encrypted across this slice" seems a useful thing 
to say.  We could even discuss how the security properties of the 
encryption should be described, although we need to be careful about how 
we do so.  But isolation of flows in the network is not an external 
observable, not something a customer can even ask about.  Fundamentally, 
isolation is a way for an operator to meet a set of agreements around a 
set of objectives.  And this document says repeatedly that it is not 
about how, only what.

This gets worse when we get to the section on resolution of guarantees. 
The text begins by talking about hard vs soft guarantees.  And then 
explains that it means the difference between effects from interfering 
traffic and effects from hardware (or, presumably, software) failures. 
Except that from the perspective of the user of the slice, that is 
irrelevant.  If I have been given a commitment that I can send 95 
gigabits per second 95% of the month, and I discover that I was unable 
to do so for more than 5% of the time, I as a customer will expect to 
invoke whatever remedy my contract gives me.  If the contract had tried 
to draw a distinction bassd on cause, I would have said "no, I am paying 
for the service.  If you can't give it to me, I'll get it somewhere 
else."  The customer wants the commitment met,not excuses about which 
cause occurred.

The resolution then wanders over into the issue of tolerance.  As the 
section correctly observes, things break.  Agreements are generally 
written to allow a certain amount of that.  The classic 5-9s was exactly 
for this purpose.  It told you how well the service would be delivered. 
IP operators can and do make promises with commitments and frequencies.
But it is not expressed as a tolerance the way this describes it in my 
experience.  Rather, it is expressed by having several objectives and 
differing levels of commitment for them.  As a purely fictitional 
example to try to be clear, one might have a series of loss comitments:
    No more than 10% loss - 99.999% of the time
    No more than 1% loss - 99.99% of the time
    ...
That does not match the description of "Resolution of guarantee" in this 
definition document.

And then we get section 4.1.1 which is a discussion of isolation.  It is 
a discussion which assumes the previous two elements are correct.   My 
recommendation is, rather than debating whether it is correct, is to 
simply remove all of 4.1.1.  If some folks involved wanted it, which is 
what is said on the call, then those folks need to speak up and explain 
what value it adds.  Currently, it misleads and confuses the reader.

As a final note, I suspect that the usage of SLO and SLA in this 
document does not match industry usage.  Some effort to address the 
mismatch might help us avoid further disconnects such as the above.

Yours,
Joel M. Halpern

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 24 Apr 2020 19:40:56 +0000

Hi Joel, 
Please see inline.

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Thursday, April 23, 2020 5:56 PM
To: [email-masked]
Subject: [Teas] Network Slicing design team definitions - isolation and resolution

Let's start with the first discussion of isolation.  This occurs in the description of the security objective.  I have no problem with including observable security properties in objectives.  telling the customer "your traffic will be encrypted across this slice" seems a useful thing to say.  We could even discuss how the security properties of the encryption should be described, although we need to be careful about how we do so.  But isolation of flows in the network is not an external observable, not something a customer can even ask about.  Fundamentally, isolation is a way for an operator to meet a set of agreements around a set of objectives.  And this document says repeatedly that it is not about how, only what.
[KM] There's a particular challenge with this document. Our first goal is to define transport-network slices in an independent, standalone manner, at the same reuse or build on existing/progressing IETF work. It gets off-balanced easily. 
But yours's is a fair justification. Isolation can be removed from security. I wanted this explanation so that when we develop next level of details we have some idea on what should be considered. 

This gets worse when we get to the section on resolution of guarantees. 
The text begins by talking about hard vs soft guarantees.  And then explains that it means the difference between effects from interfering traffic and effects from hardware (or, presumably, software) failures. 
Except that from the perspective of the user of the slice, that is irrelevant.  If I have been given a commitment that I can send 95 gigabits per second 95% of the month, and I discover that I was unable to do so for more than 5% of the time, I as a customer will expect to invoke whatever remedy my contract gives me.  If the contract had tried to draw a distinction bassd on cause, I would have said "no, I am paying for the service.  If you can't give it to me, I'll get it somewhere else."  The customer wants the commitment met,not excuses about which cause occurred.
[KM] I do not see a transport slice as a "contract". The typical transport slice expresses the knowledge of how much of an SLO and what failures your service can endure. for the user of the transport slice (Who is offering a service) ability to describe this is not irrelevant. When network provider receives request, they know what kind of effort they should make to keep service running. (e.g. packet loss for AR/VR should be way lower than 4K media service).

The resolution then wanders over into the issue of tolerance.  As the section correctly observes, things break.  Agreements are generally written to allow a certain amount of that.  The classic 5-9s was exactly for this purpose.  It told you how well the service would be delivered. 
IP operators can and do make promises with commitments and frequencies.
But it is not expressed as a tolerance the way this describes it in my experience.  Rather, it is expressed by having several objectives and differing levels of commitment for them.  As a purely fictitional example to try to be clear, one might have a series of loss comitments:
    No more than 10% loss - 99.999% of the time
    No more than 1% loss - 99.99% of the time
    ...
That does not match the description of "Resolution of guarantee" in this definition document.
[KM] This may have been misunderstood. The text is "certain tolerance level of that objective", alternately can be read as 'range' for example: bounded latency (delivery time not to exceed 9 ms, or between 7-9ms, delay variation is in 0.5 to 1ms range and so on).

And then we get section 4.1.1 which is a discussion of isolation.  It is 
a discussion which assumes the previous two elements are correct.   My 
recommendation is, rather than debating whether it is correct, is to simply remove all of 4.1.1.  If some folks involved wanted it, which is what is said on the call, then those folks need to speak up and explain what value it adds.  Currently, it misleads and confuses the reader.

As a final note, I suspect that the usage of SLO and SLA in this document does not match industry usage.  Some effort to address the mismatch might help us avoid further disconnects such as the above.
[KM] I have always seen SLA at the business level but transport slice is something that can still be described in a tangible resource-requests. Therefore, 95gbps per month is not a description of a transport slice. A transport slice would ask: do not exceed 95gbps for max 9500 flows where each flow gets 1gbps from pt 'a' to 'b' or 'c' to 'd' for the lifetime of the service.
-Kiran

Yours,
Joel M. Halpern

_______________________________________________
Teas mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C3a14db2095eb4646145808d7e7ea6c9f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637232866346233496&amp;sdata=cFEYu%2BcEy3YEHTjFK7tqmaVZghv%2F4VLFDaoX07OZRXg%3D&amp;reserved=0

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 24 Apr 2020 15:54:57 -0400

Focusing first on your last comment, but retaining the rest for context.

As I understand a Transport slice, it is all about giving a well-defined 
traffic behavior to the set of traffic the user injects into the slice.

This has many dimensions in order for it to be deliverable.  It has to 
include the limits on what the user is allowed to inject.  It has to 
include how reliably / often / ... the given level will be met.
In common usage, the SLOs are the numbers used to fill these things in. 
Coupled with reliability / assurance levels, customer limits, and other 
things, to construct an SLA.  An SLO of 95 gigabits does not mean 
anything without the concomitant knowledge of how often it will be met. 
This gets even messier with things like availability, as you have to 
actually define what it means for the service to be available.  (E.g. an 
IP service that drops half the packets at random is probably not 
actually available.)

Saying 95 gigabits for 9500 flows (not sure that is even a meaningful 
parameter for packet service delivery) without a reliability is 
meaningless.  It can not be 100%.  Even the existing text notes that 
things break.  If it is 50%, it is not much of a commitment.  Which is 
why you tie the objectives to the other parameeters.  And thus need SLAs 
even if there is no money changing hands.

Your text on ranges also left me confused.
The typical case where one wants a delay range one actually wants a 
guarantee of a minimum delay, and a separate bound on delay variation. 
I do not know of a case where the customer asked the provider to slow 
down his traffic.  Nor do I know of a case where a customer said "do not 
give me more than the stated bandwidth."  the customer may want to 
control what rate he sends, but that is separate.

Hence, I am left very confused by your answers.

Yours,
Joel

PS: It is very well known, and frankly sensible, that operators when 
making these promises look at the cost of meeting the agreement, the 
operational complexity of delivering it often enough, and the price of 
failure.  And then choose different techniques to deliver the service 
based on those trade-offs.  Which, in practice, suggests that the 
orchestration likely needs visiblity to the other parameters such as how 
often it can fail.  (For example, you use FRR if you need to recover 
faster.  Based on your analysis of likely failures, non-FRR recovery 
times, ....)  We leave these kinds of things to the operators, as 
discussion of the business parameters themselves are clearly out of 
scope for the IETF.  But we have to recognize in our definitions that 
they are an intrinsic part of the task.

On 4/24/2020 3:40 PM, Kiran Makhijani wrote:
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Luis M. Contreras" <[email-masked]>
Date: Sun, 26 Apr 2020 13:26:47 +0200

Hi Joel,

one observation respect to: " But isolation of flows in the network is not
an external
observable, not something a customer can even ask about."

It is expected that consumers of slices in the transport, as 5G services,
will request isolation. Think for instance on mission critical services
(public safety, eHealth, services, etc). In fact isolation is one of the
characteristics that can be included in the actual specification of the
slice as stipulated in the slice templates considered by 3GPP (and
generally defined by the Generic Slice Template structure considered by
GSMA).

Thus isolation should be considered as potential requirement to be
satisfied also in the transport part, as potentially requested by slice
customers (as in the case referred above).

Acknowledging the fact that the text can be improved, I think it is
convenient to keep section 4.1.1.

Best regards

Luis

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 26 Apr 2020 12:11:22 -0400

I am sorry, I am not understanding your point.  A mission critical 
service will have very tight delay, delay variation, and loss 
parameters.  (Some have high bandwidth requirements, some do not.)
If those are met, the mission critical service works.  if they are not 
met, then it is not.

Whether those are met using diffserv EF, detnet, flex-ethernet, or 
dedicated fiber and routers is not relevant to the customer.  the 
operator's technology specific tools then meet those requirements.

Yours,
Joel

On 4/26/2020 7:26 AM, Luis M. Contreras wrote:
> Hi Joel,
> 
> one observation respect to: " But isolation of flows in the network is 
> not an external
> It is expected that consumers of slices in the transport, as 5G 
> services, will request isolation. Think for instance on mission critical 
> services (public safety, eHealth, services, etc). In fact isolation is 
> one of the characteristics that can be included in the actual 
> specification of the slice as stipulated in the slice templates 
> considered by 3GPP (and generally defined by the Generic Slice Template 
> structure considered by GSMA).
> 
> El vie., 24 abr. 2020 a las 2:56, Joel M. Halpern (<[email-masked] 
> <mailto:[email-masked]>>) escribió:
> 
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Sun, 26 Apr 2020 16:29:03 +0000

Hi Joel,

please, see in-line.

-----Mensaje original-----
De: Joel M. Halpern <[email-masked]>
Enviado el: domingo, 26 de abril de 2020 18:11
Para: Luis M. Contreras <[email-masked]>
CC: [email-masked]; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Asunto: Re: [Teas] Network Slicing design team definitions - isolation and resolution

I am sorry, I am not understanding your point.  A mission critical service will have very tight delay, delay variation, and loss parameters.  (Some have high bandwidth requirements, some do not.) If those are met, the mission critical service works.  if they are not met, then it is not.
[Luis>>] Certainly yes. The point is that the customer (e.g., public safety services like police or so) could require to have guarantees that this happen in whatever circumstance, including exceptional ones such as current COVID-19 issue (with large increments of traffic in general because confinement) or a terrorist attack (where massive people communications could create congestion). Through different degrees of isolation (according to the customer requests) this could be guaranteed even in those situations.

Whether those are met using diffserv EF, detnet, flex-ethernet, or dedicated fiber and routers is not relevant to the customer.  the operator's technology specific tools then meet those requirements.
[Luis>>] Correct. This has to do with the realization of the slice, and different options could be used as long as a given technology allows to accomplish the requested service.

Yours,
Joel

On 4/26/2020 7:26 AM, Luis M. Contreras wrote:
> not an external observable, not something a customer can even ask
> about."
>
> services, will request isolation. Think for instance on mission
> critical services (public safety, eHealth, services, etc). In fact
> isolation is one of the characteristics that can be included in the
> actual specification of the slice as stipulated in the slice templates
> considered by 3GPP (and generally defined by the Generic Slice
> Template structure considered by GSMA).
>
> satisfied also in the transport part, as potentially requested by
> slice customers (as in the case referred above).
>

________________________________

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: "Joel M. Halpern" <[email-masked]>
Date: Sun, 26 Apr 2020 12:38:40 -0400

Those are very reasonable points.  That is not what the document 
currently says.

Yours,
Joel

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Sun, 26 Apr 2020 16:50:32 +0000

Hi Joel,

Then we need to clarify the text. Thanks for pointing this out.

Best regards

Luis

-----Mensaje original-----
De: Joel M. Halpern <[email-masked]>
Enviado el: domingo, 26 de abril de 2020 18:39
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Luis M. Contreras <[email-masked]>
CC: [email-masked]
Asunto: Re: [Teas] Network Slicing design team definitions - isolation and resolution

Those are very reasonable points.  That is not what the document currently says.

Yours,
Joel

On 4/26/2020 12:29 PM, LUIS MIGUEL CONTRERAS MURILLO wrote:
> De: Joel M. Halpern <[email-masked]> Enviado el: domingo, 26 de
> abril de 2020 18:11
> CC: [email-masked]; LUIS MIGUEL CONTRERAS MURILLO
> <[email-masked]>
>> one observation respect to: " But isolation of flows in the network
>> is not an external observable, not something a customer can even ask
>> about."
>>
>> actual specification of the slice as stipulated in the slice
>> templates considered by 3GPP (and generally defined by the Generic
>> Slice Template structure considered by GSMA).
>>
> 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: Jari Arkko <[email-masked]>
Date: Thu, 30 Apr 2020 17:46:40 +0300

Joel,

Just a sort of a high-level response from my side as well. Without getting to the details I wanted to say:

1/ Thank you for this feedback!

2/ In the design team’s deliberations we actually did find agreement that we need to describe slices in terms of observable requirements rather than implementation details (such as whether you use TDM or something else to implement a guarantee of some sort).

3/ We also agreed on the fact that things can go wrong, and as John points out, there are many things that can go wrong and some of those aren’t really easily separable (like power or particular type of software).

4/ Upon re-reading the text in our draft I’m not entirely sure that points 2 and 3 are as fully reflected there as they should be. This is just my opinion but I think we could improve on that front :-) Again, if we specify things using observable, fundamental characteristics then we should be fine. I realise there are other things in the world, and sometimes people want to use labels that are a bit more imprecise, but I think we should strive to avoid such labels as much as we can.

Jari