Re: [Teas] terminology discussion network slicing

Leeyoung <leeyoung@huawei.com> Mon, 15 May 2017 15:57 UTC

Return-Path: <leeyoung@huawei.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 F1C14129BBB for <teas@ietfa.amsl.com>; Mon, 15 May 2017 08:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 FK6HyJ5C_WKt for <teas@ietfa.amsl.com>; Mon, 15 May 2017 08:57:36 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDDA412EB0A for <teas@ietf.org>; Mon, 15 May 2017 08:49:00 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMZ05715; Mon, 15 May 2017 15:48:59 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 15 May 2017 16:48:57 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.117]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0235.001; Mon, 15 May 2017 08:48:49 -0700
From: Leeyoung <leeyoung@huawei.com>
To: Ricard Vilalta <ricard.vilalta@cttc.es>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] terminology discussion network slicing
Thread-Index: AQHSzZFihPahr8yd00abLSgTzP604qH1icEA
Date: Mon, 15 May 2017 15:48:48 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B2CA693@SJCEML702-CHM.china.huawei.com>
References: <7AEB3D6833318045B4AE71C2C87E8E172B2CA60E@SJCEML702-CHM.china.huawei.com> <389455e3-8a3d-cea6-9a77-518f6366dadf@cttc.es>
In-Reply-To: <389455e3-8a3d-cea6-9a77-518f6366dadf@cttc.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.155.66]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5919CDEB.0138, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a8e862c4a4c1b7ce9f7764083bca5e8f
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/SANFDFxTU5-WPVH-YGYu0o6mVzE>
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: Mon, 15 May 2017 15:57:38 -0000

Hi Ricard,

Thanks for your pointer. I just wanted to clarify that the network slicing definition we are proposing is from the TE network stand point (L0-L3 TE networks). 

Best regards,
Young

-----Original Message-----
From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Ricard Vilalta
Sent: Monday, May 15, 2017 10:37 AM
To: teas@ietf.org
Subject: Re: [Teas] terminology discussion network slicing

Dear Young, all,

If we refer to network slice, we need to cite 3GPP TR 28.801 V1.0.0 (2017-03).
It defines a network slice instance as: 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.

I see this definition fully aligned with yours.
BR,
Ricard

El 15/05/2017 a les 16:44, Leeyoung ha escrit:
> 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-0
> 5
>
> 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