Re: [Teas-ns-dt] Availability

[Greg Mirsky <[e-mail]>]

Hi Jeff,
in my reading of the definition, it is the intersection of metrics already
listed in the SLO. If that is the case, how useful is another metric that
is only a reflection of other metrics?

Regards,
Greg

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

> Greg,
>
> I thought the definition provided was pretty clear and comprehendible, why
> do we need to rephrase it?
>
> Cheers,
> Jeff
> On Jun 1, 2020, 2:00 PM -0700, Greg Mirsky <[e-mail]>om>, wrote:
>
> 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
>>
>