Re: [Netslices] draft-arkko-arch-virtualization-01

Kiran.Makhijani <Kiran.Makhijani@huawei.com> Tue, 13 March 2018 02:54 UTC

Return-Path: <Kiran.Makhijani@huawei.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 08B0A127909 for <netslices@ietfa.amsl.com>; Mon, 12 Mar 2018 19:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 ufl3pHb27lOk for <netslices@ietfa.amsl.com>; Mon, 12 Mar 2018 19:54:02 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 0831A124E15 for <netslices@ietf.org>; Mon, 12 Mar 2018 19:54:02 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id BF69F8BA8D498 for <netslices@ietf.org>; Tue, 13 Mar 2018 02:53:57 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 13 Mar 2018 02:53:58 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML701-CHM.china.huawei.com ([169.254.3.93]) with mapi id 14.03.0382.000; Mon, 12 Mar 2018 19:53:55 -0700
From: "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>
To: Jari Arkko <jari.arkko@piuha.net>, "netslices@ietf.org" <netslices@ietf.org>
Thread-Topic: [Netslices] draft-arkko-arch-virtualization-01
Thread-Index: AQHTtTEgiYAywsp4bk2gljtABxJzlqPNgqiA
Date: Tue, 13 Mar 2018 02:53:54 +0000
Message-ID: <ED3F27B9-B6D5-4D55-B575-194E7E7A8E11@huawei.com>
References: <2638F192-DDC1-45A2-B816-BA577038E335@piuha.net>
In-Reply-To: <2638F192-DDC1-45A2-B816-BA577038E335@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.245.140]
Content-Type: text/plain; charset="utf-8"
Content-ID: <523ED5FBDA7C684FBCF3A1F9680F4738@huawei.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/cyy9XCtF3DB6dTc386oGk9q3FoQ>
Subject: Re: [Netslices] draft-arkko-arch-virtualization-01
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: Tue, 13 Mar 2018 02:54:04 -0000

Dear Authors,
Thank you for posting this document. It is a good summarization of what everyone has talked about slices.

Apologies for lengthy comments. I just wanted to get better understanding of the motivation.
Regards
Kiran


As one of the initial contributor to netslices, some of my comments may be biased, here they are in any case:

1.  "In particular, whether one calls a particular piece of technology "virtualization", "slicing", "separation", or "network selection" does not matter at the level of a system".
^^^^
IMO, it should matter. virtualization is an old 'concept'. And what you call a particular piece of technology is important for clear differentiation. They may seem conceptually same at the top and may use common tools at the bottom but in-between techniques, usecases and methods would differ. Or perhaps you are alluding that all virtualization methods/technologies be uniformly done?

2. For section 2, few things that raise curiosity is a) what is the purpose of many different definitions without inclination to a particular one or conclusive remark? b) to me discussion on NFV seems unnecessary here.

3. The discussion 5.2 to 5.5 were covered well in the problem statement-gap-analysis (https://tools.ietf.org/html/draft-qiang-netslices-gap-analysis-01). only the narrative is different.

4. https://tools.ietf.org/html/draft-netslices-usecases-02 also has 2 items that you touched upon (1) 3GPP-usecase (section 4.1), (2) role of virtualization (section 5). On the other hand, you do not talk about 5GEX type of usecases. Basically, are you saying that slices are only relevant for 5G?

5. I think 5.5 is a very important discussion we need to have. As you say service models should just define characteristics, NSaas should be like that - important for IETF work.

6. In architectural principles - Data model layering,
this is a very good observation; To me it means E2E integration which is a challenge in data models today; but the way you suggest, it sounds like a 'network design' problem. Should we tackle it here? Wouldn't a simpler way to connect different existing DMs together be sufficient (I think YANG allows to reference one DM from other - maybe develop this further)? maybe consider using a term other than 'layering'.

7. The ability to specify "statistical" rather than hard performance parameters.
I don't understand the motivation here. The hard performance has been cited as a differentiator for slices (think URLLC type services), so it may not be a correct thing. Also think about if I want to map my parameters to DETNET YANG model, will I use statistical info? Although I agree on principle that TE models should have configs changes for different timescales.

8. Mapping from high abstraction level specifications to concrete network configurations.
I think this is not specific to slices area and should be applicable to any service related work in data modeling space. It is an independent effort in itself that slices would directly benefit from.

9. cross-domain: quite an important aspect - if this is the only outcome from the slice activity, it would have served the purpose.

Overall the focus in the document is too much on modeling. It is ok to acknowledge that solutions are available at disposal but we should not completely eliminate/exclude work that may be needed in control and data plane (even though as extensions to existing protocol).

========

From: Netslices <netslices-bounces@ietf.org> on behalf of Jari Arkko <jari.arkko@piuha.net>
Date: Tuesday, March 6, 2018 at 1:54 AM
To: "netslices@ietf.org" <netslices@ietf.org>
Subject: [Netslices] draft-arkko-arch-virtualization-01

We wrote a new version of this draft, with more discussion of various technologies and issues that we think are related also to slicing. 

https://tools.ietf.org/html/draft-arkko-arch-virtualization-01

Comments and discussion appreciated!

Jari