Subject: [Teas-ns-dt] Today's meeting

From: Eric Gray <[email-masked]>
Date: Mon, 28 Oct 2019 11:04:31 +0000

A Note from the meeting two weeks ago, when I had to leave early.  Thought I had sent this but apparently it sat in my Drafts forlder.

What I was trying to say is that we need to have a separate discussion about the meaning of an SLA.

Reza gave an example of a request for an SLA of X Mbit/s, with certain additional latency and loss requirements, etc.

Any discussion of an SLA that is strictly limited to bandwidth is based on an exceptionally naïve point of view of what an SLA is and what it can include.

Many of today's Service Level Agreements include all that we want to see included in any transport connection that might be used to support network slicing - for any application I am aware of.  And I expect the concept of an SLA to expand as needed to include anything else that might be needed.

Essentially, an SLA can (and frequently does) include any level of detail in packet processing (i.e. - on a per-packet basis, how it is handled, what can be done to it [DPI, filtering, etc.], whether or not it is admissible, what priority, what maximum latency, what maximum loss, allocation of bandwidth share, sharing, etc.).

The issue with any SLA - regardless of its simplicity or complexity - is that the current way in which an SLA is established is (as I'm sure many of you have also heard) that it's done "at the speed of lawyers."

One of the most interesting aspects of network slicing is that one can define a relatively small number of "slice types" and associate a common SLA covering all of the relevant SLA characteristics, associated handling costs, etc. - that need to be worked out "at the speed of lawyers" a priori and dynamically add and remove individual service clients as needed based on a presumed common understanding of what each slice includes.

My understanding is that this level of "a priori" negotiation is already being done for VPNs, etc.  So this should be something