Re: [Teas-ns-dt] New Version Notification for draft-nsdt-teas-transport-slice-definition-00.txt

[Eric Gray <[e-mail]>]

On reflection, following the meeting of the other day, I don’t dislike Jeff’s suggestion to use “SLO.”

It seems that the “level” part comes from the fact that the term is meant to include the measurable performance parameters part of an SLA (in other words, not the part of an SLA that I was arguing is irrelevant to the work we might do in the IETF).

SLO is tied to SLA.  I think a number of people were looking for that.

I don’t exactly love it either, because there is no requirement that a transport slice must actually be a discrete business agreement, rather than a set of service parameters required of the transport slice to meet the end to end SLO.

Which makes using SLO a reasonable compromise.  😊

From: Teas-ns-dt <[e-mail]> On Behalf Of Eric Gray
Sent: Monday, November 18, 2019 6:02 AM
To: Jari Arkko <jari.arkko=[e-mail]>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Cc: [e-mail]
Subject: Re: [Teas-ns-dt] New Version Notification for draft-nsdt-teas-transport-slice-definition-00.txt

The biggest issue I have with the use of SLA is that – from my understanding of the work in the IETF to date – the concept of a “service level agreement” is quite foreign.  It represents a contract for a service between a service provider and a service consumer (or subscriber).

We could spend quite a lot of time – time better used in other (more IETF-relevant) pursuits – on the finer details of this sort of contractual arrangement.

From the perspective of the folks who are defining both the technology, and its control, what we are more likely to be concerned with is the parameters that make up the relevant service details – not the instrument that gives both a subscriber and a provider legal recourse to recover perceived damages as a result of a failure to provide working technology and controls.

From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Jari Arkko
Sent: Sunday, November 17, 2019 3:07 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Teas-ns-dt] New Version Notification for draft-nsdt-teas-transport-slice-definition-00.txt


Thanks for the discussion.



I reviewed the definition again today, and have some comments/suggestions.



First off, there’s overall quite a bit of material in the draft overall. Sometimes it is useful to nail down a concept in few words familiar to networking geeks even outside the mobile network space, and leave examples and use cases and mapping to interesting other things (such as 5G) to other documents. That might benefit understanding from others… we can talk about how we want to convey the final definitions once we’re done.



Secondly, I’d still love to polish the compactness of the definition a bit, to base it on fundamental concept. How about this:



OLD:

A Transport Slice is an abstract network topology connecting different network functions (NFs) with appropriate isolation and a specific Service Level Agreement (SLA) described in terms of shared or dedicated network resources. In other words, a transport slice is a group of connections that connect various NFs in the network to achieve some specific SLA for a customer as shown in Figure-2.

NEW:

A Transport Slice is an abstract network topology connecting different network functions (NFs) with a specific Service Level Agreement (SLA) described in terms of expected network service. The SLA can include characteristics such as guaranteed bandwidth or latency, requirements on the use of physically separate equipment, etc.

Jari