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

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi Kiran,

Some comments from my side in-line (adding also Joel who is not in the TEAS NS DT list - I think- but was part of the discussion today)

Best regards

Luis

De: Teas-ns-dt <[e-mail]> En nombre de Kiran Makhijani
Enviado el: lunes, 4 de mayo de 2020 18:07
Para: [e-mail]
Asunto: [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?

[Luis>>] At least for the contracts I know (mostly related to interconnection matters) there is no absolute 100% of guarantee for SLOs. Each SLO committed is stated in according to its nature; two examples:

.- latency - usually (in the context of interconnection) an average value is committed for reaching destinations in different geographical areas.

.- packet loss - usually a max value is committed.

Those values are committed to not being exceeded X% of some period of time (e.g. days in a month, minutes a day, etc). So absolute 100% cannot be guaranteed because there are circumstances which are not controllable at all.

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).

[Luis>>] My comment above is about performance. Here I was trying to introduce the analogy with what happens in the compute multi-tenancy approach. A customer can simply (1) request for resources or (2) can even ask for a dedicated host with a number of resources, where the customer actually doesn't care if it is hostA or hostE. Here, the analogy I see, according to what we discussed today, is a customer asking (1) some resources (e.g. 10 G bandwidth) or (2) some dedicated transport capabilities with a number of resources (e.g., a 10 G lambda). The important thing is that the customer doesn't care which specific lambda is, is up to the provider to allocate lambda1 or lambda8, as long as it is dedicated for the customer.

Both cases, (1) and (2) can be satisfied from the operator side simply allocating a dedicated lambda. But the operator has additional flexibility in case (1) since if no explicit dedication is requested, the customer request can be groomed with other signals from other customers (for sure guaranteeing the committed SLO of 10 G).

  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?

[Luis>>] I also see them as different kind of events. In order to deal with infrastructure failures, operators typically design the network architecture to avoid the kind of problems as the example of the fan failure. IN case of happening something like that (which implies that the node goes down), an alternative path in the network will take care of the traffic, avoiding impact on customers. Networks can be designed to deal with single or multiple failures. More protection more cost.

However a network design like before could have events of congestion (flash crowd events, exceptional situations -e.g. COVID-19-, failures in parts of the network, etc). In this situations isolation, understood as the way of dedicating resources to customers, could guarantee that the resources allocated to a given customer are respected and not used for others. Examples of situations like thos could be the same lambda example as before, some calendar slots in FlexEthernet, some queues allocated for a specific customer (at least in ingress), etc. Statistical multiplexing mechanisms cannot guarantee that, is clear, bit there are other mechanisms as the ones mentioned before, which are also part of the overall transport network.

This does not mean that the cost of such dedication of resources will be equivalent to non-dedicated resources, for sure not. But there could be situation where such kind of guarantees are needed: emergency services, banks, stock markets, etc. Such kind of specialized services will be the ones demanding such kind of special solutions with the expectation of being more economic than building and running their own network (as happened in the computing world by the way).

So maybe this will not be the common norm, but there are a number of use cases that will have such needs, and because of that we need to define a solution being comprehensive, not partial.

  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.

[Luis>>] In the examples I have mentioned in the point number 1, apart from defining the SLO and the threshold, also the way of measuring it and the time window are specified. So, I think we can go in that direction and I think there are a number of RFCs we could leverage on in this respect.

Regards
Kiran


________________________________

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