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

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

Hi Joel,

Some comments to your points:

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

Isolation implies dedication of a number of resources. With those dedicated resources two situations could happen: (1) everything works fine, so no impacts on SLOs; (2) something works wrong, thus the operator can allocate different but equivalent resources in such a way that SLOs are not impacted.
This works for sure at certain levels. If we are talking of dedicated infrastructure (as in your example of the fiber) this could not be possible. However there are connectivity constructs that make it possible (the referred lambda, for instance, which could be provided through a different path).
I would say that the explicit implication of isolation is dedication of resources, while the implicit one is some service guarantees (apart from others such as maybe security, predictability, robustness, etc).

<jmh>
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.
</jmh>

What we could expect from a transport slice controller (TSC) is to work on programmable assets (via network controllers probably). Then I guess the focus should be on the programmable constructs providing isolation, not in the physical infrastructure which will not be addressable by the TSC. So I would concentrate on programmable capabilities, leaving the rest apart.
Maybe, as discussed, isolation cannot be expressed through a SLO, but it will be an attribute or characteristic of the service.
Regarding the description in the draft, yes, should be changed to avoid confusion.

<jmh>
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.
</jmh>
Probably it would be enough referring that some time window could be considered, describing in rough way, not exact details. Or just referring some of the existing RFCs dealing with the topic as examples/references for defining SLOs.

Thanks

Best regards

Luis

-----Mensaje original-----
De: Joel Halpern Direct <[e-mail]>
Enviado el: lunes, 4 de mayo de 2020 22:06
Para: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>om>; Kiran Makhijani <[e-mail]>om>; [e-mail]
Asunto: Re: definitions section 4 improvement discussion

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

________________________________

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