Re: [Teas-ns-dt] Availability

[Greg Mirsky <[e-mail]>]

Hi Jeff,
if we define availability as the ratio of the period all requested in the
SLO metrics are within an acceptable range to the time since the service
was handed to the customer (I propose to refer to this metric as
"availability ratio"), then I think it can be expressed as
[image: \bigcap _{i=1}^{n}A_{i}], where Ai is the time period the
particular metric remained within its acceptable boundary.

Regards,
Greg

On Mon, Jun 1, 2020 at 1:35 PM Jeff Tantsura <[e-mail]>
wrote:

> Mostly agree with Eric/Kiran
>
> It should not be removed, but further clarified.
> Network/service availability is a measurable metric, availability =
> uptime/total_time(uptime+downtime)
> Rule of thumb - a service is deemed available when all the SLO’s
> associated with it are met(TRUE).
> In a complex/multidimensional service, different objects might have
> different availability metrics .
> For simplicity sake - total_availability(normalized metric) =
> Σ(subservice-1..subservice-n), so both, per SLO as well as composite
> metrics can be used.
>
> Cheers,
> Jeff
> On Jun 1, 2020, 10:08 AM -0700, Kiran Makhijani <[e-mail]>om>,
> wrote:
>
> Thanks! I support not removing it.
>
> Sticking with individual SLO seems to be a right decision but can be
> deferred to NBI document. we need not state that here.
>
> -Kiran
>
>
>
> *From:* Teas-ns-dt <[e-mail]> *On Behalf Of* Eric Gray
> *Sent:* Monday, June 1, 2020 7:35 AM
> *To:* [e-mail]
> *Subject:* [Teas-ns-dt] Availability
>
>
>
> I agree that the definition needs to be cleaned up, but I disagree that it
> should be omitted.
>
>
>
> A part of what probably should be cleaned up is the part that talks about
> service degradation.  In general, this is an important factor in
> determining availability, but it is a bit vague for the purpose of
> definition.
>
>
>
> I also disagree that availability is not measurable.
>
>
>
> As a proof of concept for measuring , if there are any mandatory
> measurable objectives, then failing to meet any of those objectives makes
> the service measurably unavailable.  That is, if you can determine if
> specific mandatory objectives are being met, then you can determine if they
> are not being met and therefore determine if the service is unavailable.
>
>
>
> Availability is an important aspect of any service, because it is
> understood that the higher the required availability, the more difficult
> (and thus expensive) it is to provide that service.
>
>
>
> Defining availability as a fraction as we have done in the draft, allows
> for services that may experience a certain amount of outages over a service
> period.  A service request may ask for as high an availability as the
> provider and requester have agreed to (under the terms they agreed to) in
> advance.
>
>
>
> Note that this elevates the importance of having (at least mostly)
> measurable objectives, simply because you cannot determine if a
> non-measurable objective is being met – hence you cannot (necessarily)
> determine the availability of any service that depends on that objective.
>
>
>
> It is further interesting to note that the notion of a service depending
> on objectives that it cannot determine are not being met is a non-sequitur.
>
>
>
> Measuring availability in terms of mandatory objectives – as a whole – is
> the simplest approach; one could group one or more mandatory objectives and
> define an availability separately for the group – thus allowing for a
> higher degree of acceptance for failing to meet one set of service
> objectives compared to others.
>
>
>
> If we were going to do that, it would probably be better to define
> availability as a parameter that applies individually to service objectives.
>
>
>
> In my opinion we should at least initially stick to the simple case, where
> availability is defined as a service objective, rather than as a parameter
> of every service objective – but I am willing to go either way.
>
>
>
> --
>
> Eric
> --
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>
> --
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>