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

[Joel Halpern Direct <[e-mail]>]

Trimmed to one part I want to comment on.  Reply bracketted by 
<jmh></jmh> for quoting clarity.

Yours,
Joel

On 5/4/2020 3:56 PM, LUIS MIGUEL CONTRERAS MURILLO wrote:
> 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
...
>  2. 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./*

I had assumed that things with high reliability needs would specify that 
they need 99.99% (or 5-9s, or even 6-9s) for the relevant SLO 
parameters.  And pay the price the operator needs to get to have that be 
offerable.  I would not expect the customer to express this kind of high 
reliability requirement as an isolation requirement, as isolation does 
not actually equate to reliability.  (I can have an isolated fiber.  If 
it is cut, I am out of luck.  And I got no benefit from having the 
isolated fiber.)

At the same time, if we really wanted to get into isolation, we would 
have to get into the difference among dedicate conduit, dedicate fiber, 
dedicate lambda, dedicate time slice, ...).   None of those are degrees. 
  They are different ways of delivering a service.  With different 
effects.  Note that this is quite separate from a requirement that two 
different access points from a customer must have no failure point in 
common.  That is a complex thing to express in an SLO, and hard to 
monitor.   But it is Very different from what has been described as 
isolation.

> 
>  3. 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./*

The biggest risk is that if we geet too specific about how these things 
will be measured, we can end up with volumes of text.  I agree with the 
description Luis used.  But if we start trying to define (as contracts 
have to) the exact start and end of measurement intervals, the exact 
clock skew allowed by the measurement tools, and the exact technique to 
be used to measure these things, we will create a never-ending nightmare 
for ourselves.

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