Re: [Netslices] Comments on COMS BoF

Kiran.Makhijani <Kiran.Makhijani@huawei.com> Wed, 11 April 2018 13:39 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 14C7F126D74 for <netslices@ietfa.amsl.com>; Wed, 11 Apr 2018 06:39:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 QMJBgiKwFahf for <netslices@ietfa.amsl.com>; Wed, 11 Apr 2018 06:39:06 -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 209491241F5 for <NetSlices@ietf.org>; Wed, 11 Apr 2018 06:39:06 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D76D1DE42B6A9 for <NetSlices@ietf.org>; Wed, 11 Apr 2018 14:39:02 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 11 Apr 2018 14:39:03 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML702-CHM.china.huawei.com ([169.254.4.179]) with mapi id 14.03.0382.000; Wed, 11 Apr 2018 06:38:58 -0700
From: Kiran.Makhijani <Kiran.Makhijani@huawei.com>
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "NetSlices@ietf.org" <NetSlices@ietf.org>
Thread-Topic: [Netslices] Comments on COMS BoF
Thread-Index: AdPRe+4GGzyzevn/R6aZ8aXOyX1UcAAaefeA
Date: Wed, 11 Apr 2018 13:38:58 +0000
Message-ID: <EF049B3E-156E-44B3-9BE6-923012CB6525@huawei.com>
References: <b40d2ebd78a2491bb87d33b58e3ff3f1@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <b40d2ebd78a2491bb87d33b58e3ff3f1@rew09926dag03b.domain1.systemhost.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.67.57]
Content-Type: multipart/alternative; boundary="_000_EF049B3E156E44B39BE6923012CB6525huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/LNu72cLx0QwIINbQW4adDZYenGY>
Subject: Re: [Netslices] Comments on COMS BoF
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: Wed, 11 Apr 2018 13:39:09 -0000

Hi Philip,
Please see inline.
-Kiran
From: Netslices <netslices-bounces@ietf.org>; on behalf of "philip.eardley@bt.com"; <philip.eardley@bt.com>;
Date: Wednesday, April 11, 2018 at 12:01 PM
To: "NetSlices@ietf.org"; <NetSlices@ietf.org>;
Subject: [Netslices] Comments on COMS BoF

Hi,
I thought the presentations and discussion at the COMS BoF was interesting. Thanks also to the proponents for reacting to previous feedback, personally I think this is getting quite close to a sensible set of work. Here are some comments.
I think it would be useful to work on a common information model to include connectivity, compute and storage resources. I’d exclude functionality (VNFs) from the information model – as VNFs seem orthogonal to resources and also an information model for even one VNF is hard.

[KM] VNFs or NFs should be part of information model because I think it will allow you to “instantiate” a NF instance integrated with the request for allocating resources. Think of CORD or edge computing, it could help with proper/proximal placement of NFs on-demand. Otherwise, would they become 2 separate requests and as a tenant you will need to find out where to spawn an NF. The complete specification of an NF is challenging, we are considering only minimal resource related information.
I’m unclear if COMS should work on “the related YANG model”. I don’t think we should work on specific data models, but ok if Yang is the way of recording the information model. (In RFC3444 terms, we should “model managed objects at a conceptual level, independent of any specific implementations or protocols used to transport the data” and not on something “intended for implementors and include protocol-specific constructs”)
I think the CSI & SDI interfaces should be the same. I couldn’t find a clear description of them – but as I understand it, the high-level architecture has two interfaces, a Service Delivery Interface (SDI) and Customer Service Interface (CSI). The SDI is between the network provider and orchestrator, and also between hierarchical orchestrators. The CDI is between the customer (‘tenant’) and provider. For me these interfaces are the same – in the same way that the network provider wants to request resources from an orchestrator (or understand what resources are available),similarly the tenant wants to request resources (or understand what’s available) from the network provider.

[KM] Think of them being separated by as-a-consumer and as-a-provider type roles. Actually, for a homogenous hierarchy example you have in mind of service providers, it could work, but think of it in terms of a service. What if you want to create different type of services and tenant will have different operations/information for each type of service. In addition, I think aggregation of telemetry/ stats and disaggregation for resource mappings will be simpler to understand in terms of SDI and CSI roles. If we combine them, it will be one bloated interface.

Thanks

Kiran
An objective for us (BT) is to enable hierarchical service providers (ie a service provider can devolve part, or even all, of its network & compute to another provider). This should be much simpler to achieve if the interface is recursive, therefore I’d have this as a specific objective.
As well as COMS defining the interface and information model, I think a preliminary step is to agree the high-level description for these (ie something equivalent to a protocol model https://tools.ietf.org/html/rfc4101).
A comment was made, I think by Ignas, that ‘one universal interface is a nice vision, but isn’t practical’. I think that in practice existing domains will have their existing orchestrators, so an adaptor is needed to ‘match’ to the standardised SDI - but it is still valuable to have that single, standardised interface. (The high-level architecture should show these adaptors.)
I also note that the scope is no longer specific to slicing (this is good) – but how to coordinate orchestrators, so that aspects of a deployment can be devolved to other providers. Devolution is easiest if there is a common interface with a common understanding of what types of resource there are and how to describe them.
Whilst there are several standards bodies with an interest in this topic (of information model & interface), personally I think the IETF could play a useful role.
Best wishes,
Phil/