[Netslices] Comments on COMS BoF

<philip.eardley@bt.com> Wed, 11 April 2018 10:00 UTC

Return-Path: <philip.eardley@bt.com>
X-Original-To: netslices@ietfa.amsl.com
Delivered-To: netslices@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 19D281271DF for <netslices@ietfa.amsl.com>; Wed, 11 Apr 2018 03:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RKYMkxxhOrDW for <netslices@ietfa.amsl.com>; Wed, 11 Apr 2018 03:00:38 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE071242F7 for <NetSlices@ietf.org>; Wed, 11 Apr 2018 03:00:37 -0700 (PDT)
Received: from rew09926dag03b.domain1.systemhost.net ( by EVMED03-UKBR.bt.com ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 11 Apr 2018 11:00:33 +0100
Received: from rew09926dag03b.domain1.systemhost.net ( by rew09926dag03b.domain1.systemhost.net ( with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 11 Apr 2018 11:00:34 +0100
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Wed, 11 Apr 2018 11:00:34 +0100
From: <philip.eardley@bt.com>
To: <NetSlices@ietf.org>
Thread-Topic: Comments on COMS BoF
Thread-Index: AdPRe+4GGzyzevn/R6aZ8aXOyX1UcA==
Date: Wed, 11 Apr 2018 10:00:33 +0000
Message-ID: <b40d2ebd78a2491bb87d33b58e3ff3f1@rew09926dag03b.domain1.systemhost.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_b40d2ebd78a2491bb87d33b58e3ff3f1rew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/2AaqKD9cTH2Dm5DGkJFlQkGBVUU>
Subject: [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 10:00:42 -0000

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.
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.
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,