Re: [Teas] Network Slicing Design Team definitions

Greg Mirsky <> Sat, 25 April 2020 21:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8E093A0999 for <>; Sat, 25 Apr 2020 14:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xct69OYxvTVO for <>; Sat, 25 Apr 2020 14:26:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFAFE3A0996 for <>; Sat, 25 Apr 2020 14:26:08 -0700 (PDT)
Received: by with SMTP id k28so10647275lfe.10 for <>; Sat, 25 Apr 2020 14:26:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xFIKsn23JCieI7STrE+8JBBMTg46oIfKCRskHhThkek=; b=YLyLuf0MsbR7q2Shbk1aP+1TNx4re9SEdIJJ3ajondTpKFl7vhigFlt2X/JKyU06At 4PiKqrBTRyoE5bjuPDz3Lr9fO4rzzzYR7/iTYDb3XyWknfguAb3gMW06/3iqWcbGCTjx Y6oeFb+IDjMcrlUsLc2vLzCUasEr5EIwQ7opr9gpOPBD32UbnB0dKaQc7vKIRVXqLcuI JurR555L/22B+Q4w0dl0z8HrATnqiuThM7g0+bOVRZ6uZj5BB22A0fJzUtB4Vux+C+5H X3poqSIcNZZmJpVB12ra1fQy7mHo7/KHpIFDUVwQR6PvAtpEDs1JBiF/3xFWIslKS2Ds DVBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xFIKsn23JCieI7STrE+8JBBMTg46oIfKCRskHhThkek=; b=bZUcvr4dd+vYDC3UMccXfcqJ1KviuJF7hxKHth2cBi3EHYndaCE13UL/Rbp4x72mzc 6N0pHCOsJEzNYkFD6KG+DzOGffwpyWTNXp24bMnTfFAlhXmf+KXp913y0CmWvq309Iyp VP8GDNkRICOYVBZX0pg7CLK6W7incCW0BIEni4iRtpSjuiFerp1SGNIpVDKcs86PFmnx EtVIMMln5+Ht1CYwU98ruJVNlPfLxwa1nj8pfgsZCcMYfM6r7wppf45pHiXFQtMVeT3L ikvBZu5bw9vR8zcl/qN487EjOZ40AMAr4zzL3c66tDhWn4SIq7XIJIZiWbc3GR7XvI4p GDvw==
X-Gm-Message-State: AGi0PuaZ6wqO+rIerGXrW+T3AAkF3H4oyI2g1urbshQUhAqYSDxaZ5M9 eeol8/X6M1mbk4W8crNSXnUtEp/VpXtVlfC4RmHsYlMF
X-Google-Smtp-Source: APiQypIOUjxe3RI9ykkYMEeOBS7m7YQCR0Oep+VRDlNtcTyhhaxC1rl5EEDynsyL+ERF/UQdi9yFtcWUX7CQTllqv9U=
X-Received: by 2002:ac2:4836:: with SMTP id 22mr10262765lft.52.1587849966705; Sat, 25 Apr 2020 14:26:06 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Sat, 25 Apr 2020 14:25:57 -0700
Message-ID: <>
To: "Joel M. Halpern" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000038e05805a424212f"
Archived-At: <>
Subject: Re: [Teas] Network Slicing Design Team definitions
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Apr 2020 21:26:11 -0000

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
Do you think that will work?


On Thu, Apr 23, 2020 at 5:39 PM Joel M. Halpern <> 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