Re: [Teas] Network Slicing design team definitions - isolation and resolution

Jari Arkko <jari.arkko@piuha.net> Thu, 30 April 2020 14:46 UTC

Return-Path: <jari.arkko@piuha.net>
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 D86713A0A13 for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 07:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 SF3vluwimHjc for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 07:46:43 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id D619D3A0A08 for <teas@ietf.org>; Thu, 30 Apr 2020 07:46:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 352EE6601A6; Thu, 30 Apr 2020 17:46:42 +0300 (EEST)
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU0akc19f8Q5; Thu, 30 Apr 2020 17:46:41 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id EE56866017E; Thu, 30 Apr 2020 17:46:40 +0300 (EEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <7bfd8a09-c166-3e19-9097-360398b8cb5f@joelhalpern.com>
Date: Thu, 30 Apr 2020 17:46:40 +0300
Cc: "teas@ietf.org" <teas@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E027C9ED-4CEA-4A82-B4C1-1259BBC1B2D5@piuha.net>
References: <7bfd8a09-c166-3e19-9097-360398b8cb5f@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/t0ty3nP8yxNdOvj7A80W-Z806bA>
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution
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: Thu, 30 Apr 2020 14:46:46 -0000

Joel,

Just a sort of a high-level response from my side as well. Without getting to the details I wanted to say:

1/ Thank you for this feedback!

2/ In the design team’s deliberations we actually did find agreement that we need to describe slices in terms of observable requirements rather than implementation details (such as whether you use TDM or something else to implement a guarantee of some sort).

3/ We also agreed on the fact that things can go wrong, and as John points out, there are many things that can go wrong and some of those aren’t really easily separable (like power or particular type of software).

4/ Upon re-reading the text in our draft I’m not entirely sure that points 2 and 3 are as fully reflected there as they should be. This is just my opinion but I think we could improve on that front :-) Again, if we specify things using observable, fundamental characteristics then we should be fine. I realise there are other things in the world, and sometimes people want to use labels that are a bit more imprecise, but I think we should strive to avoid such labels as much as we can.

Jari