Re: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

"sebastian" <comscape@gmail.com> Sat, 03 June 2017 02:49 UTC

Return-Path: <comscape@gmail.com>
X-Original-To: netslices@ietfa.amsl.com
Delivered-To: netslices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7347312EAEA for <netslices@ietfa.amsl.com>; Fri, 2 Jun 2017 19:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 3ox3rQYWSzec for <netslices@ietfa.amsl.com>; Fri, 2 Jun 2017 19:49:37 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 F295112EAB0 for <NetSlices@ietf.org>; Fri, 2 Jun 2017 19:49:33 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id r63so35774912itc.1 for <NetSlices@ietf.org>; Fri, 02 Jun 2017 19:49:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=rGZn4bIdsV+VdUjqM5fH1I8G9vUNFxOIVbukqz59fws=; b=NgKSqo7H/da3No6Xkwch0CI0mRwHQ01F1dbM9tvpjWdNNzItKOXQs2OhwNVVMF7Cte 3iYUuorOtzolmAhdXLusuNFTC607LfTWowU7CsXsydJZGt2IiRDTR4ksiFQ+mEaxVFqe o0MkvpbHOjSmzE8rLSkooQDu3JANtCu2m5LDAwTCdfFHb28kEyPXGtwY1bg52Id0KD8A LTmfjLcZqzpvCQsCslgPjPmtZdSzFtPC/nqMAqwGOi8iB4nYq1koePgjZkZAQKID1Rt5 NA1kzqFCTKeCk7MNTR+7kSQ1lMDwnp7pD3Roeba8uzbAIEeN6Grq4P+onYxjLL6FY+0g tkFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:from:to:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=rGZn4bIdsV+VdUjqM5fH1I8G9vUNFxOIVbukqz59fws=; b=eDaZTTF9qHT+lOz7rfrhogA1ord0WV3lzVcr/VSX7Z/7vJ2AfP7LQxzNzgcmfLke+N hLlsJ/Zlolr/3L0WbEW8uoBQGqA5pnrtu3MWQds8IJun+Wd1ZCPdHmEAHl23kVE9KAdY H724156YSy9mJhMVFID2UPyew2QBeoaoEq2IwpgPu6fCODAKq6EY9Cu4WsL3JVrb9fh5 FpSIxLFE1wzBU/oneLpvrw8xzgWzyy8mHxQc/LVNV3HlO9jFCDc/qFw8ftdD4RVGsSQK kI6pVAzo+P/Y8siyAqueFhg+R4zcBbFAERT0rqZff7ZHKIaLMZlaO787oAQdrR+1kEdV JY3A==
X-Gm-Message-State: AODbwcCpekhDCzExMZYOHmPOVb7H2D9hOjSyuMBkDxSUvpZAmhjjwGez 8QYJLWW4tJBSXg==
X-Received: by 10.36.24.4 with SMTP id 4mr2702952itr.6.1496458173337; Fri, 02 Jun 2017 19:49:33 -0700 (PDT)
Received: from Vision (c-73-246-86-185.hsd1.il.comcast.net. [73.246.86.185]) by smtp.gmail.com with ESMTPSA id m2sm1876536iti.26.2017.06.02.19.49.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 19:49:32 -0700 (PDT)
Reply-To: sebastian.thalanany@ieee.org
From: sebastian <comscape@gmail.com>
To: 'GENG Liang' <liang.geng@hotmail.com>, "'sebastian.thalanany'" <sebastian.thalanany@ieee.org>, "'qiangli (D)'" <qiangli3@huawei.com>, NetSlices@ietf.org
References: <06C389826B926F48A557D5DB5A54C4ED29BB624F@SZXEMI507-MBS.china.huawei.com>, <007d01d2dba4$63c21930$2b464b90$@gmail.com> <HK2PR06MB0913CB13A7089DE72A48D2AE87F70@HK2PR06MB0913.apcprd06.prod.outlook.com>
In-Reply-To: <HK2PR06MB0913CB13A7089DE72A48D2AE87F70@HK2PR06MB0913.apcprd06.prod.outlook.com>
Date: Fri, 02 Jun 2017 21:49:33 -0500
Message-ID: <00e601d2dc14$084b60a0$18e221e0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01D2DBEA.1F799E60"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLI+JnnpH9Nd9PZdo4rUxa0bCXU+QGr5HATAnvlSPygBPU7YA==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/wXMzUAvMNrvLeXY0oLMRBeJUjzs>
Subject: Re: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded
X-BeenThere: netslices@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is intended for discussion and review of network slicing at IETF." <netslices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netslices>, <mailto:netslices-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netslices/>
List-Post: <mailto:netslices@ietf.org>
List-Help: <mailto:netslices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netslices>, <mailto:netslices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jun 2017 02:49:39 -0000

Hello, Liang,

 

Thanks for the reference draft.

The terminology with respect to the various aspects of a network slice and related abstractions, look good.

 

In several sections of the draft there are references to the term ‘operator’, in different contexts.

 

A generalized distinction, in terms of NSP and SP would be relevant in the draft, from a forward-looking perspective, where domain owners may either just be an NSP or an SP, or an SP that also behaves as an NSP.

NSP : Network Service Provider (instead of ‘operator’): This entity only provides ‘access’ type of services

SP: Service Provider: This entity provides any service above the network layer, but may also behave as an NSP

 

Happy to scrub the text, with tracked changes with generalized terminology that uses SP and NSP, instead of ‘operator’

 

Many thanks.

-Sebastian

 

 

From: GENG Liang [mailto:liang.geng@hotmail.com] 
Sent: Friday, June 2, 2017 3:59 PM
To: sebastian.thalanany <sebastian.thalanany@ieee.org>; 'qiangli (D)' <qiangli3@huawei.com>; NetSlices@ietf.org
Subject: Re: Re: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

 

Hi Sebastian,

 

We have defined term with similar generalization concernsin Architecture draft. All other rnetslices draft is referring to these terminologies. This document can be find here

 <https://tools.ietf.org/html/draft-geng-netslices-architecture-01> https://tools.ietf.org/html/draft-geng-netslices-architecture-01 





Best wishes

Liang

 

  _____  

Liang GENG 

China Mobile Research Institute

 

From: sebastian <mailto:comscape@gmail.com> 

Date: 2017-06-02 21:30

To: 'qiangli \(D\)' <mailto:qiangli3@huawei.com> ; NetSlices@ietf.org <mailto:NetSlices@ietf.org> 

Subject: Re: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Dear Colleagues,

 

Thanks for delineating the prominent aspects of network slicing.

 

Here are some thoughts on terminology.

 

With the diverse nature of services in the 5G realm, where XaaS (Anything as a Service) is an emerging paradigm, perhaps some of the legacy terminology may need to be generalized.

For example, the term ‘operator’ was typically used with reference to various types of ‘access’ modalities.

 

In NGMN, such terminology is being generalized.

NSP : Network Service Provider (instead of ‘operator’): This entity only provides ‘access’ type of services

SP: Service Provider: This entity provides any service above the network layer, but may also behave as an NSP

 

Best wishes.

-Sebastian

 

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Friday, June 2, 2017 4:36 AM
To: NetSlices@ietf.org <mailto:NetSlices@ietf.org> 
Subject: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

 

Dear All,

 

We have upload "Gap Analysis for Network Slicing" draft 00 on https://datatracker.ietf.org/doc/draft-qiang-netslices-gap-analysis/?include_text=1

Your comments and reviews are greatly appreciated.

 

Abstract:

   This document presents network slicing differentiation from the non-

   partition network or from simply partition of connectivity resources.

   It lists 15 standardization gaps related to 6 key requirements for

   network slicing.  It also presents an analysis of existing related

   work and other potential solutions on network slicing.

 

   This gap analysis document aims to provide a basis for future works

   in network slicing.

 

Best regards,

 

Co-authors