Re: [Teas] Network Slicing Design Team definitions

Jari Arkko <jari.arkko@piuha.net> Thu, 30 April 2020 14:29 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 1FF683A092F for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 07:29:27 -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 sMZxT1RlYjwO for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 07:29:24 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3C63A08EF for <teas@ietf.org>; Thu, 30 Apr 2020 07:29:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 104566601A6; Thu, 30 Apr 2020 17:29:20 +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 idlkStGj6bBG; Thu, 30 Apr 2020 17:29:18 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id ABC2C66017E; Thu, 30 Apr 2020 17:29:18 +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: <f568ddd7-51bb-9b5c-56ca-e7126d5a590e@joelhalpern.com>
Date: Thu, 30 Apr 2020 17:29:17 +0300
Cc: "teas@ietf.org" <teas@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <565A2F8B-01C6-45D6-B358-240857B152B6@piuha.net>
References: <f568ddd7-51bb-9b5c-56ca-e7126d5a590e@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/SVLHGMHLqKb8imMiAaQQWkmzfnM>
Subject: Re: [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: Thu, 30 Apr 2020 14:29:33 -0000

Joel:

> 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?

I’d like to understand your comment better. What specific text are you referring to? The definition simply said:
 
"A transport slice is a logical network topology connecting a number
   of endpoints and a set of shared or dedicated network resources,
   which are used to satisfy specific Service Level Objectives (SLO)”.

At least in my mind this isn’t necessarily related to packet source and destination addresses; I may want a VPN between your network and mine, but that’s different from the addresses used in the traffic entering the VPN. For instance, my computer’s address is not the endpoint of the VPN, my VPN router is.

But maybe I misunderstood the comment. I agree that the sections that come after the definition and talk about e.g. specific characteristics may have confused something in some cases. E.g., not sure we’ve entirely covered directionality correctly in all the text.

Jari