[Teas] Network Slicing Design Team definitions

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 24 April 2020 00:39 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828813A0BCB for <teas@ietfa.amsl.com>; Thu, 23 Apr 2020 17:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdemE-to6j3j for <teas@ietfa.amsl.com>; Thu, 23 Apr 2020 17:39:03 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358EA3A0BC6 for <teas@ietf.org>; Thu, 23 Apr 2020 17:39:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 497Zzp5d08z6GDG1 for <teas@ietf.org>; Thu, 23 Apr 2020 17:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587688742; bh=uPBbymPDVZJJ7F8OcJT2Pp4SDxkQW302C287TLfkOuQ=; h=To:From:Subject:Date:From; b=OLj76BMHTx/7YzQrrIhfkx415RNAFJ+h4AOSOs492dSHjpYnjJo3pyCAmfX0k61ov /1bKnMQ0NpDr34tDu/rYGecmHT3ALtwSuZaVq9L1rnRztfCmU7mCv9OrcCCcwmXipq NCrimuUgipniKecjpkE1yAdunM/o+sNSXD6mdFUE=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 497Zzp2ffXz6GD8W for <teas@ietf.org>; Thu, 23 Apr 2020 17:39:02 -0700 (PDT)
To: "teas@ietf.org" <teas@ietf.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <f568ddd7-51bb-9b5c-56ca-e7126d5a590e@joelhalpern.com>
Date: Thu, 23 Apr 2020 20:39:01 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/R7vsV6GTM-EG-SsVtvNnRsF7x9o>
Subject: [Teas] Network Slicing Design Team definitions
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 00:39:05 -0000

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