Re: [Teas] [Netslices] terminology discussion network slicing

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Sat, 20 May 2017 00:32 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 40E60129476; Fri, 19 May 2017 17:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 i46Avim3zHBJ; Fri, 19 May 2017 17:32:57 -0700 (PDT)
Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595CE126CB6; Fri, 19 May 2017 17:32:57 -0700 (PDT)
Received: by mail-yb0-x22e.google.com with SMTP id 187so14659956ybg.0; Fri, 19 May 2017 17:32:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gZrMLGIkFz55TYskcwBETRifOIPUWbRm0wwUs72DBaE=; b=laoL5Ds/NA8pFQ8GqZlJwAE+FALnXmUmFjFcZlsEImhCfv1exUGtxjhuEwo+YEjqY9 EmRXyHmEmBw4vJHhVDQNrgrfV73mYUObd7ARXjQcEeUmQQ4dnGhUcV17yglbSmB8ZvHb ckhbRhMw/0aTWRjwfc1X4d4mCZJhsbkDBXcbnKj/fNUQPxn9FzlRxs/VidfW5bGm5hPk z9EMOLGZn4oRx9bo4UDLHW98tIEf0LKS1cpAug0KBztTPAAUoex23zoLmueHKRH64nG0 W7MU1FhNqCB9giIVmSR8k2ya1g8Q66oNjcWENH6Dstm63Zhd1A9tX+XMJ2gMSWsy+Iy/ 8g+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gZrMLGIkFz55TYskcwBETRifOIPUWbRm0wwUs72DBaE=; b=iTqAIaGAxuFx8hLET8XNvMDxk1LwnJUlJPavQY0d2k7Y3BgNWzKdcn+JDl/MhhKtbs 9nIY60aFPbNTB5Imi9+w0gLpo6bfnW8LumXVmaaco6sbmnMViHEfsK34wn9cZJheFsx7 J9YM0h1Y5Iapr120jgR94GAaUjSEaNi20YScCQBKEnxhqegFgHfXioxNdSeN0Mbktdt6 QTXqpjaT1WdS+AsBJV/mk3vKDQOTckbF6BIqwHU9g5KW7IObuYL4raksQ55GRcV17tQH LVC9uf2WPTFKTITTpfX/6blxjDfwzla95CWrI8Rl0YR7iNJhZtZMEbqacTFrWwAUnmPp PG1g==
X-Gm-Message-State: AODbwcDbCJ5Rb8c4Baf/Eto1GfFWb7Vn74vCH2xEqHsE7BBZmRn/cWSG LIEZDhrgPLp90ir9g4otDScq6E0FpA==
X-Received: by 10.37.44.138 with SMTP id s132mr10289982ybs.84.1495240376692; Fri, 19 May 2017 17:32:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.161.198 with HTTP; Fri, 19 May 2017 17:32:56 -0700 (PDT)
Received: by 10.37.161.198 with HTTP; Fri, 19 May 2017 17:32:56 -0700 (PDT)
In-Reply-To: <AM2PR07MB099483A94CDDD068D0F86CD5F0E50@AM2PR07MB0994.eurprd07.prod.outlook.com>
References: <7AEB3D6833318045B4AE71C2C87E8E172B2CA60E@SJCEML702-CHM.china.huawei.com> <97EE7243-CB44-40AD-B02D-98E07D9C79F2@juniper.net> <DB3PR07MB0588EA2B00C389E762D8C59F91E60@DB3PR07MB0588.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD00786390993DBF8@SJCEML702-CHM.china.huawei.com> <15c1177e0c0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172B2CC48E@SJCEML702-CHM.china.huawei.com> <AM2PR07MB099483A94CDDD068D0F86CD5F0E50@AM2PR07MB0994.eurprd07.prod.outlook.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Fri, 19 May 2017 20:32:56 -0400
Message-ID: <CAKKJt-cHiBLMuYGznnKmO8QRVSJpePfWfNr7eanLzOK945qVGQ@mail.gmail.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Cc: "NetSlices@ietf.org" <NetSlices@ietf.org>, Leeyoung <leeyoung@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="001a1143196681bc24054fe9c792"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/dsrJPSB3E8V3iEkR7FdwnGBelJk>
Subject: Re: [Teas] [Netslices] terminology discussion network slicing
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 20 May 2017 00:32:59 -0000

On May 19, 2017 16:56, "Daniele Ceccarelli" <daniele.ceccarelli@ericsson.com>
wrote:

Hi Young, all,

i agree with your conclusion but would like to clarify one thing that IMO
got lost in the discussion since its beginning.

The 3GPP definition says:
"A set of network functions and the resources for these network functions
which are arranged and configured, forming a complete logical network to
meet certain network characteristics."

This means that a network slice IS NOT a VPN or a TE Tunnel.
A network slice is "something" (netslices and 3GPP will define what this
something is) that is composed by a "piece" in the RADIO domain, a "piece"
in the CLOUD domain, a "piece" in the TRANSPORT domain, plus possible other
pieces in possible other domains.

The word "transport" can be misleading here since one could think of
transport technologies (e.g. WDM, OTN), but what I'm referring to as
TRANSPORT DOMAIN is that part of the network that is used to carry a packet
between two other domains.
In order to have a slice, that portion of the transport domain needs to be
engineered, hence it is all about building a TE entity and stitching
services to such entity. This is what is in the ACTN scope.

My very personal opinion is that whatever belongs to the transport domain
belongs to IETF (and is already being addressed), while the rest is a
dangerous duplication of concepts standardized is other SDOs...but this is
another discussion that doesn't fit here.


Given that "transport" has two completely orthogonal meanings in our
community now, and is already a source of confusion, if this term is not
already etched in stone, if you could think of another label, that would be
awesome.

Just from your description, I thought you're describing a transit operator.
I'm not saying that's the right term, but I think it would confuse fewer
people.

If you can think of a better term, please use it, of course.

Spencer, as *Transport* AD, but not the kind of Transport you're looking
for ...