Re: [Teas] terminology discussion network slicing

Lou Berger <lberger@labn.net> Tue, 16 May 2017 13:38 UTC

Return-Path: <lberger@labn.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 6BF0E129BE8 for <teas@ietfa.amsl.com>; Tue, 16 May 2017 06:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 TuzPLn9Q0q1x for <teas@ietfa.amsl.com>; Tue, 16 May 2017 06:38:14 -0700 (PDT)
Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 4A5F7129B39 for <teas@ietf.org>; Tue, 16 May 2017 06:34:57 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id CB1E01E079F for <teas@ietf.org>; Tue, 16 May 2017 07:34:53 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id M1aq1v00G2SSUrH011atn5; Tue, 16 May 2017 07:34:53 -0600
X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=tJ8p9aeEuA8A:10 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=AEDFM0qtAAAA:8 a=gpJgY_SdGf4xdYu3BCIA:9 a=FGEGLg4zO5e89Qer:21 a=RiS__4qesGjJ7zOk:21 a=CjuIK1q_8ugA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=NCq4FBG6EvGFEERSFaZp:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=uHXqsSKXTsPLDMVjSO46HwcSfdzG5qeIzYkyM6ZJho0=; b=wtXFlj4A7yzue6Cv3mWkU5VMzs 5DUJ93ou2O/A+dVPukMD0qPiy/yaxzUQT8brnIXpYybkNcpU6/MYuQ3d+qhx3KNnq6G1UfTACYqkb xEUpghoTwIm3g9zi5ZEe5g8pL;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:37332 helo=[11.4.0.6]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1dAcck-0002t5-0t; Tue, 16 May 2017 07:34:50 -0600
From: Lou Berger <lberger@labn.net>
To: Igor Bryskin <igor.bryskin@huawei.com>, "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>, Gert Grammel <ggrammel@juniper.net>, Leeyoung <leeyoung@huawei.com>, teas@ietf.org, adrian@olddog.co.uk
Date: Tue, 16 May 2017 09:34:48 -0400
Message-ID: <15c1177e0c0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD00786390993DBF8@SJCEML702-CHM.china.huawei.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>
User-Agent: AquaMail/1.9.1-360 (build: 100900101)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dAcck-0002t5-0t
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([11.4.0.6]) [100.15.84.20]:37332
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/B2UQYpQxbthFSYrQe3wXJ5qfH_A>
Subject: Re: [Teas] 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: Tue, 16 May 2017 13:38:16 -0000

Perhaps it's time to bring the discussion to the slicing list and report 
back their reaponse....

Lou


On May 16, 2017 8:31:19 AM Igor Bryskin <Igor.Bryskin@huawei.com> wrote:

> Hi Sergio,
>
> I would also like to hear more from network slicing experts.
>
> My understanding is that the difference in the separation (in terms of 
> control and data planes, security, etc.). For example, traditional BGP 
> based L3 VPNs (that use provider's common control plane for their 
> management and IP/MPLS TE tunnels to inter-connect their PEs) will probably 
> not be able guarantee for the clients msec range connectivity setup times 
> required by 5g, while provided by the same provider fully 
> separated/genuinely private IP/MPLS networks (that do not share IP/MPLS 
> control plane and infrastructure, whose network topology is supported by 
> separate L0/L1 connections) hopefully will be able to provide such 
> guarantees. Therefore, I define layer network slices as dynamically managed 
> fully isolated in control and data planes private TE layer networks, which 
> may share one or more underlying server layer networks.
>
>
> Cheers,
> Igor
>
>
>
>
> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Belotti, Sergio 
> (Nokia - IT/Vimercate)
> Sent: Tuesday, May 16, 2017 6:08 AM
> To: Gert Grammel; Leeyoung; teas@ietf.org; adrian@olddog.co.uk
> Subject: Re: [Teas] terminology discussion network slicing
>
> Hi Gert,
>
> "Thinking a bit about it I came to the point where "VPN" and "network 
> slices" seem to describe the same entity or at least a "network slice" 
> being a VPN of VPNs?"
>
> I share completely your conclusion , I'd like if someone can explain if a 
> difference really exists .
>
> Thanks
> Sergio
>
>
> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Gert Grammel
> Sent: Monday, May 15, 2017 7:02 PM
> To: Leeyoung <leeyoung@huawei.com>; teas@ietf.org; adrian@olddog.co.uk
> Subject: Re: [Teas] terminology discussion network slicing
>
> Leeyoung,
>
> Thank you for taking a stab on this. Usually when getting to a definition, 
> I try to establish what kind of existing constructs would fall under the 
> definition. If my understanding is correct, the following list of 
> constructs would all satisfy the definition somehow.
> - A TDM network with a p2p TDM connection
> - A PSC capable network carrying a p2p circuit (such as EPL/EVPL)
> - An MPLS LSP using a traffic engineered IP network
> - A L2VPN using a traffic engineered MPLS network
> - A L3VPN using a traffic engineered IP network
> - A TCP connection using a traffic engineered IP network
> - Different QoS classes in an IP network
>
> Thinking a bit about it I came to the point where "VPN" and "network 
> slices" seem to describe the same entity or at least a "network slice" 
> being a VPN of VPNs?
>
> Gert
>
>
> On 2017-05-17, 16:44, "Teas on behalf of Leeyoung" <teas-bounces@ietf.org 
> on behalf of leeyoung@huawei.com> wrote:
>
>     Hi Adrian and others,
>
>     We'd like cross check with you on some terminology we introduced newly. Any 
>     comment on these terms will be greatly appreciated.
>
>     We introduced 'network slicing' as follows:
>
>             Network slicing is a collection of resources
>             that are used to establish logically dedicated virtual networks
>             over TE networks. It allows a network provider to provide
>             dedicated virtual networks for application/customer over a
>             common network infrastructure. The logically dedicated
>             resources are a part of the larger common network
>             infrastructures that are shared among various network slice
>             instances which are the end-to-end realization of network
>             slicing, consisting of the combination of physically or
>             logically dedicated resources.
>
>
>     Thanks.
>     Young and Daniele
>     -----Original Message-----
>     From: Leeyoung
>     Sent: Friday, May 05, 2017 1:41 PM
>     To: teas@ietf.org
>     Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-05.txt
>
>     Hi,
>
>     This update is intended to incorporate the comments from the last WG 
>     meeting and any pending issues. We also have taken the global editorial 
>     changes to make it consistent through the document. Major changes are:
>
>     - Inclusion of "network slicing" definition from ACTN perspective (in the 
>     terminology section)
>     - Added virtual network service (VNS) section (Section 3) to define types 
>     of VNS.
>     - Incorporated "orchestration" (service/network) mapping to ACTN 
>     architecture (See Section 5.2)
>     - Created a new section 6 (Topology Abstraction Method) where we imported 
>     some texts from ACTN abstraction method  
>     https://tools.ietf.org/html/draft-lee-teas-actn-abstraction-01
>     - Added Appendices A & B to discuss example deployment scenarios such as 
>     example of MDSC and PNC functions integrated in Service/Network 
>     Orchestrator (Appendix A) and example of IP + Optical network with L3VPN 
>     service (Appendix B)
>
>     In regard to ACTN abstraction method draft, we are going to keep it as a 
>     separate draft and use this document to elaborate other aspects not 
>     imported to the framework document.
>
>     The following diff pointer will help you see the changes with this revision:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-05
>
>     The co-authors believe that the document is ready for WG LC. Any 
>     changes/comments will be appreciated.
>
>     Thanks & Best regards,
>     Young & Daniele (on behalf of other co-authors/contributors)
>
>     -----Original Message-----
>     From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
>     Sent: Friday, May 05, 2017 10:41 AM
>     To: i-d-announce@ietf.org
>     Cc: teas@ietf.org
>     Subject: [Teas] I-D Action: draft-ietf-teas-actn-framework-05.txt
>
>
>     A New Internet-Draft is available from the on-line Internet-Drafts directories.
>     This draft is a work item of the Traffic Engineering Architecture and 
>     Signaling of the IETF.
>
>             Title           : Framework for Abstraction and Control of Traffic 
>             Engineered Networks
>             Authors         : Daniele Ceccarelli
>                               Young Lee
>     	Filename        : draft-ietf-teas-actn-framework-05.txt
>     	Pages           : 41
>     	Date            : 2017-05-05
>
>     Abstract:
>        Traffic Engineered networks have a variety of mechanisms to
>        facilitate the separation of the data plane and control plane. They
>        also have a range of management and provisioning protocols to
>        configure and activate network resources.  These mechanisms
>        represent key technologies for enabling flexible and dynamic
>        networking.
>
>        Abstraction of network resources is a technique that can be applied
>        to a single network domain or across multiple domains to create a
>        single virtualized network that is under the control of a network
>        operator or the customer of the operator that actually owns
>        the network resources.
>
>        This document provides a framework for Abstraction and Control of
>        Traffic Engineered Networks (ACTN).
>
>
>
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/
>
>     There are also htmlized versions available at:
>     https://tools.ietf.org/html/draft-ietf-teas-actn-framework-05
>     https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework-05
>
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-05
>
>
>     Please note that it may take a couple of minutes from the time of 
>     submission until the htmlized version and diff are available at tools.ietf.org.
>
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
>
>     _______________________________________________
>     Teas mailing list
>     Teas@ietf.org
>     https://www.ietf.org/mailman/listinfo/teas
>
>     _______________________________________________
>     Teas mailing list
>     Teas@ietf.org
>     https://www.ietf.org/mailman/listinfo/teas
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>