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

[Kiran Makhijani <[e-mail]>]

Hi Joel, 
Please see inline.

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

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.
[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
[e-mail]
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