Re: [Teas-ns-dt] definitions section 4 improvement discussion

[Eric Gray <[e-mail]>]

Kiran,

#1

              There are some possible SLO parameters that are effectively 100%.

              One that comes up is the requirement not to allow traffic from one VPN (being used as a "transport slice") to "leak" to another VPN.

              This can happen, of course, but only as a result of a misconfiguration error, or equipment failure.  Not much of anything can prevent these from happening (there are cases where this can be demonstrated to occur with TDM, for example, if a misconfiguration occurs at an Add-Drop Multiplexer.

              These risks can be (and usually are) mitigated by (for example) service activation testing, OAM, etc.

              It can be argued that any SLO parameter can be said to be 100%, if any departure from this would result in an immediate termination of the service.  This is essentially the case with your 1st example under #1.

              The issue that comes up in that is whether a failure to meet the SLO can be immediately detected by a service (which might - for instance - require that there is at least one OAM PDU for every service PDU).  This seems like a lot of overhead, at least to anyone not familiar with the payload envelope format used in TDM.

              As you can imagine, meeting these criteria could make the service very costly.

              But, the definition draft does not need to delve into this at that level of detail.  It should be sufficient to say that a specific parameter may have a "confidence level" in a range of from a minimum (10% was suggested, but it could be any arbitrary value less than 100%) and a maximum (possibly as high as 100%, depending on the parameter).

              To keep things simple at this point, we should allow that the range includes 100%, even when that is not achievable.

              As I mentioned (during today's meeting), there are a lot of possible failures that the customer would not be able to distinguish from congestion (such as weather in microwave, over heating in equipment, etc.) so a guarantee that a customer will never see behavior that looks as if it is caused by congestion effects from other traffic is not guaranteed to be determinable.

#2

              Once again, we're conflating "what" a customer asks for with "how" the provider  will meet the request.  A customer will not ask that the provider "poisons" other traffic in order to meet their committed objectives for that customer; what they will ask for is some level of assurance that their (presumed higher priority) traffic is not perceptibly impacted by other (presumed lower priority) traffic.

              Your assertion that "it must be avoided by ..." is clearly a "how" statement - hence out of scope (even as an example/assumption).  This is a good example of why it is that customers do not get to define what priority the customer's traffic gets in the provider's network.

#3

              The input that a customer (or subscriber) has in requesting monitoring of a service may indeed ask for notification when the service is nearing a threshold value that might impact the service.  How the provider does the monitoring to support this notification is not up to the customer - as long as the customer receives the notification.  Once again, this falls into the "how to do it" realm, rather than in the "what it is that the customer actually needs" realm.

              Also, we are not saying (in the framework draft) that the thresholds that may be established are tripped as a result of direct monitoring of each service.  The TSC has the responsibility to do this and may actually do it in any number of ways - depending on (for instance) the details of the underlay deployment.

              I do find that - while the framework draft explicitly states that the details of the NBI (of which monitoring is one example) are not in scope  - you seem to be arguing that these same details may be in scope for the definitions draft.

              I strongly suspect that we could make a statement in the definitions draft along the lines of "monitoring transport slice performance against some subset of specific SLO might be necessary, depending on a customer having the ability to ask for this via the NBI and the provider being able to provide it."

              The thing that may need to be re-emphasized in this context is that a transport slice service provider (via a TSC) may not be able to provide some services that a customer may request.  In an environment where the transport network and the customer network are both in the same administrative domain, there is always the option for the "provider" to expand the infrastructure to meet increasing "customer" demand.  In the real world, this doesn't happen in real-time.

--
Eric

From: Teas-ns-dt <[e-mail]> On Behalf Of Kiran Makhijani
Sent: Monday, May 4, 2020 12:07 PM
To: [e-mail]
Subject: [Teas-ns-dt] definitions section 4 improvement discussion

Hello,
Thanks for converging on improvement on most of the text. A little more discussion is necessary:

  1.  Can an SLO confidence be 100%?

I was bit confused with this discussion. Most comments were that there is no such thing as 100% confidence but I am not convinced. Is it possible to specify a slice by saying SLO1: guarantees of resource such as bandwidth (Say X mbps) with 100% confidence and SLO2: availability 99.999%? - I hope the answer is Yes. Right?

Another context for 100% confidence context is (Luis also raised this) when NF or SF resources are asked for, they should be seen as virtual but allocated (100%) resource with the guarantee of compute or memory requirements - i.e. without having to contend with another traffic. (confidence sounds bit odd here, but that's what we are using to replace resolution or isolation).

  1.  Dealing with failures:

I am little worried about how we are mixing up the avoidable, recoverable and non-recoverable failures. I did not agree that fan-failure faults are same as congestion. In case of congestion - it must be avoided by minimizing or penalizing other less-critical traffic - because a transport slice asked for this. In case of recoverable HA or failover should kick in. finally non-recoverable are multiple faults:- both active and failover links saw problems and it is impossible to send any traffic. In transport slices, we can specify enough to prevent avoidable and recoverable failures. For example, consider a critical-service transport slice and what must be done to provide disruption free and always-on, and reliable service?

  1.  Monitoring in the context of measurable SLOs:

Jie raised an interesting comment on directly measurable attributes. Many SLOs will require different means of monitoring.  We have not discussed this as a characteristic of a transport slice. Should customer specify any monitoring as part of the transport slice? Perhaps not, but then there is a mention of "monitoring thresholds" in framework document in 3.3. We should have corresponding text in the definition.

Regards
Kiran