Re: [Teas] Network Slicing Design Team definitions

[Greg Mirsky <[e-mail]>]

Hi Joel,
thank you for starting this discussion. I agree, defining availability in a
packet-switched network is challenging, and, despite several efforts, I
cannot name any good we can use. I may have a proposal that might be the
start for another attempt, but first I'd like to point to the definition of
availability for constant bit-rate paths (e.g., DS, SONET/SDH, etc.). I
apologize for the lengthy post as it will include extensive quotes from
G.826 that are necessary to present the definition.
Firstly, G.826 defines necessary elements that are further used in the
definition: Severely Errored Seconds (SES), Errored Seconds, Defect.
Secondly, an unavailability time is defined as an onset of ten consecutive
SES or Defect periods. Then, the available time is defined as the onset of
ten consecutive non-SES and without a Defect. These definitions can be
applied to unidirectional and bi-directional paths (bi-directional
deemed unavailable if one direction is unavailable). From these
definitions, Availability ratio can be defined as
Availability ratio = (Availability time) / (Up time - Scheduled maintenance
time) * 100.
We can note, that these definitions work for the constant rate network
because a receiver has an expectation of the guaranteed bit-rate, something
that is absent in the PSN case. But if a consumer of a transport slice is
interested in its availability metric, then the controller is expected to
provide necessary instrumentation to enable monitoring on
availability/unavailability. I think that a mechanism that transmits
periodic packets, e.g., BFD in Asynchronous mode, can be used to create the
flow that will be used to measure availability/unavailability time. The
scale might be different from the one used in G.826, and we will need to
define SES considering the difference between PSN and constant bit-rate
technologies.
Do you think that will work?

Regards,
Greg

On Thu, Apr 23, 2020 at 5:39 PM Joel M. Halpern <[e-mail]> wrote:

> This message contains two relatively minor points I noted while reading
> the draft.  I think they need to be considered, but want to keep them
> separate from the discussion of the Isolation and Resolution text.
>
> Oddity:
>      The definition of Endpoint has the oddity that it seems to leave
> the original packet source and the intended packet destination as not
> being Endpoints?  They can not be attached directly to the transport slice?
>
> Minor issues:
>      The definition of availability says it is about the time to recover
> from failure.  But then it includes the mean time between failure, which
> while I can understand having an impact on availability is not about the
> time to recover.  The combination of mtbf and mttr give the expect
> portion of the time the service is running / available.
>
>      It is also worth noting that the MEF ended up going to a lot of
> trouble to more precisely define availability due to real-world problems
> with the informal definition.  Maybe we should point to their definition
> instead of trying to craft our own?
>
> Yours,
> Joel
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>