Re: [Netslices] Preliminary charter text for discussion

Xavier de Foy <x.defoy.ietf@gmail.com> Thu, 01 February 2018 22:24 UTC

Return-Path: <x.defoy.ietf@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 3F00B12F092 for <netslices@ietfa.amsl.com>; Thu, 1 Feb 2018 14:24:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-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 rU3dscBavV49 for <netslices@ietfa.amsl.com>; Thu, 1 Feb 2018 14:24:46 -0800 (PST)
Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (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 2CD7012EE45 for <NetSlices@ietf.org>; Thu, 1 Feb 2018 14:24:46 -0800 (PST)
Received: by mail-qt0-x241.google.com with SMTP id d54so28555904qtd.4 for <NetSlices@ietf.org>; Thu, 01 Feb 2018 14:24:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YqZcKofaMyDrfNKgJJJL35ZBcZXFrcrn9dpCfuVxOyM=; b=mlExWZIO0xqWFZaYsiL2/JgnFdOLWjQlAGKh+bkbGjZ59/rt/deoL9a7WYSkfXE2g4 WVzqNL0hN8czpiBDR+0YYyxvP4kkZFhevJrwZQPAurszDEZHiNxnQxyHx068VKrlpW8Q qQobv0IzpjQKVoM+mclyb7Tf4FqXCs1dgjq6567+/DdgEOHBe74iSsmYK3K3Ylk3obBA C3hRCKwsY6kFAYxSvXaZxW15Y/Q77iBNiTcGY88Du9CroHxGC72D2TlTWnbrL+GTeP2t L9JASCbPeXfCXPRVMPlNtXUB7ydnW5U17xaXL17broMOU8hj855hAMKOQtPACJxfIr5C 1OWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YqZcKofaMyDrfNKgJJJL35ZBcZXFrcrn9dpCfuVxOyM=; b=cr0WjD4yXWP0LhQFiQTYjwxx9j1KiaFp/MmL/+P8TRpN7JHue3Fu86Nw2RRpgCbFfA PgGm2SBxF1oEPqhFUCM6YhbAyyyjXhB3nnMHmLFAc290Hnxcy4KtO7BGXG1rujQG0fWN 7Uc1vjatyTgdvBFNZXSbE4IjmN2UNAR2IlOOzFVhtd7WaP38t17MPUm3/vgVvUzkhzr/ vwBARJJJ1mHglg6AycnisPPUKk46OoejMRT9mfvWgeylKkgqQNtQzXihlvAzekb69A6t jEOHAv/vneg7qST1ytEH8DK6+0LM+7hQbM8K/u2h9m/xVVbq28f2hZ4xWIZESmAi57Ms 1Dug==
X-Gm-Message-State: AKwxytdXR5EMcPuHht6hpT17oyV9RT9AzPIzzzTFVaBgqvLhrNUVjpBg vtTkUg0ewoqtv9Z9ARx+f4uuGhJwwv8ccGKqPBo=
X-Google-Smtp-Source: AH8x2273vcdDKRdYr0nnr0Q+atAfgTmNHgPXBqviJ1tCDHUAH9udXJ9xWkwUfXb+Log2Dluz/6rTcObvfa85YmhnwJw=
X-Received: by 10.237.53.253 with SMTP id d58mr51144888qte.276.1517523885097; Thu, 01 Feb 2018 14:24:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.27.20 with HTTP; Thu, 1 Feb 2018 14:24:44 -0800 (PST)
In-Reply-To: <088B437B-E9AC-43FD-B911-6A077F5000E0@gmail.com>
References: <CAHYjOTbKq5SGx2dUt5citBq=21dRYS4nK_Sebdq0nyPX9T7bLg@mail.gmail.com> <1517163726.4051.23.camel@it.uc3m.es> <CAHYjOTbgfBMywDYoG5oDEBMHORWvG_qoKJun8NawVsgDObFOsQ@mail.gmail.com> <20180130043352.GB15400@spectre> <1517307927.3201.7.camel@it.uc3m.es> <CAHYjOTaMP=ZuvaPLdrJgLkcG6cggf8_zBVm-aUZssR7-TyuENg@mail.gmail.com> <49297C39-EF21-4D3E-898B-4728B61221BB@huawei.com> <CAHYjOTbLHTFWgPS6k94ecykvW9CYY8=b9EUVuauZ-J0gO38BVg@mail.gmail.com> <CDD02D35-78B0-4252-96E8-D973FFB37FD2@gmail.com> <06C389826B926F48A557D5DB5A54C4ED2A5F8047@dggemi509-mbx.china.huawei.com> <96DCDC2D-6F10-4C7E-A82E-3B868F55E23D@gmail.com> <PS1PR0601MB14830C48CA6595709AA60BFB87FB0@PS1PR0601MB1483.apcprd06.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E173CF94DF4@sjceml521-mbs.china.huawei.com> <PS1PR0601MB14830BDB3242BE7F5FEA9A0C87FA0@PS1PR0601MB1483.apcprd06.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E173CF961AB@sjceml521-mbs.china.huawei.com> <HE1PR0701MB271459213C062281074D54EDF0FA0@HE1PR0701MB2714.eurprd07.prod.outlook.com> <088B437B-E9AC-43FD-B911-6A077F5000E0@gmail.com>
From: Xavier de Foy <x.defoy.ietf@gmail.com>
Date: Thu, 1 Feb 2018 17:24:44 -0500
Message-ID: <CAHYjOTZa8UzhHFJi5VJe6EoqC4uCee_UO9iCHEFwi8joFkU4ug@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Leeyoung <leeyoung@huawei.com>, Liang GENG <liang.geng@hotmail.com>, "qiangli (D)" <qiangli3@huawei.com>, "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>, Pedro Martinez-Julia <pedro@nict.go.jp>, "NetSlices@ietf.org" <NetSlices@ietf.org>, =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= <cjbc@it.uc3m.es>
Content-Type: multipart/alternative; boundary="001a11c013261c07b905642e10e3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/-UeKDF3rPsBOsya1m6ytINKi4v4>
Subject: Re: [Netslices] Preliminary charter text for discussion
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: Thu, 01 Feb 2018 22:24:49 -0000

Thanks Jeff, here is an updated text to address some of your points
(removing the lists of technologies and the "study" entry).
For the last deliverable I followed your suggestion to replace "study".
Others may want to discuss/reword this later, but we need a version for the
BoF proposal.
Best Regards,
Xavier.


I. Context

A network slice is a set of infrastructure resources and service functions
that has attributes specifically designed to meet the needs of an industry
vertical or a service. Network slices may be instantiated in a single
domain or across multiple domains, and they may use heterogeneous
technologies. The goal of this group is to produce and promote a
technology-independent and resource-centric management plane for network
slices. Resources associated with a network slice are normally comprised of
physical and logical connections in access, aggregation and backbone
networks as well as computing and storage elements. Service functions
associated with a network slice include network functions and network
function chains pre-defined using corresponding network infrastructure
elements.

A "Network Slice" is realized using a collection of technologies spanning
across data, control and management planes. Many of them rely on existing
IETF technologies including both concluded and in-progress works in data,
control and management planes.

The foundation of COMS is a technology-independent and resource-centric
management plane. In reality, the network slice provider may have diverse
technology choices in different domains due to geographical and commercial
reasons. Therefore, COMS makes no assumption on which technology is used
for specific domains. The goal of COMS is to define a common and
inter-operative management mechanism, which is essential for the concept of
network slicing being adopted in a system with heterogeneous network
infrastructures and services functions. Major characteristics include:

- Enabling composition of slices within a single or over multiple domains.
- Allowing the operation and management of a network slice in a uniform
manner, even when this network slice span multiple technology and/or
administrative domains.
- Enabling deployment of services over individual slices.

II. Scope

The WG will describe an overall architecture for network slicing. To manage
network slices in a technology-independent manner, the network slice
provider (NSP) will need to communicate with a network slice orchestrator
(NSO) over a COMS Service Delivery Interface (SDI). The COMS SDI can also
be used between network slice orchestrators, enabling hierarchical
management through the notion of network slice subnets. Network slices will
be leased to tenants, which will be able to use Customer Service Interface
(CSI) exposed by the NS provider to run management tasks (e.g., on-demand
measurement) within their slice instance under certain policies.

The WG will describe an information model representing a network slice,
accounting for the key elements used in network slices: connectivity,
compute, storage resources, network and service functions — this
information model includes the representation of managed objects and
corresponding management and operations, will guide the design of data
models on SDI and CSI and also will enable orchestrators interworking.

The WG will specify requirements, operations and management functionalities
on network slicing interfaces SDI and/or CSI including:
1 Network slice service profile, e.g. set by NSP over SDI, including
high-level parameters for network infrastructures and service functions,
together with their corresponding performance requirements.
2 Lifecycle management of network slice.
3 Other FCAPS functions. An important task of NSP is to aggregate faults,
performance, status information and performance guarantees for certain
services.
4 Slice composition or stitching in multi-domain environment.
5 Slice management by the tenant under the control of NSP, including
deploying network services over a slice.

The WG will specify management requirements and functionalities of data
plane entities as needed to enable the operation of network slices. For
example, this may include abstractions of policy control and enforcement,
or gateway functionalities. The WG will also study the mapping between the
abstract information model and managed entities, and will liaise with other
IETF WGs as needed. However, the WG will not attempt to replicate existing
device models and data plane technologies.

III. Deliverables

WG deliverables are listed below and may be split in any number of
documents as determined by the WG:
- Problem statement and use cases for management of network slices.
- Architecture of network slices.
- Information model(s) and operations for network slices on topics
described above in the scope section.
- SDI and CSI interface specifications and relevant YANG models.
- Specify management requirements and functionalities of data plane
entities as needed to enable the operation of network slices.
- Information and corresponding data models related to the mappings towards
specific data plane technologies and coordination with relevant WGs as
needed.

IV. Milestones

Dec 2018     Problem Statement, use cases and architecture
Dec 2018     Common information model and related YANG model
June 2019    Network slices composition and interworking
October 2019 FCAPS management functions and operations on network
             slices including abstractions of policy control and
             enforcement, or gateway functionalities.
March 2020   SDI and CSI interface specifications and relevant YANG models



On Thu, Feb 1, 2018 at 1:11 PM, Jeff Tantsura <jefftant.ietf@gmail.com>;
wrote:

> Hi,
>
>
>
> /IAB shepherd hat on
>
>
>
> First of all – thank you for continues work and improvements!
>
>
>
> Please keep the scope narrow and concise (aka don’t boil the ocean or even
> a lake)
>
> There’s no need to address every technology by its name, someone will be
> forgotten, someone be mentioned mistakenly  (e.g. there’s no “SR VPN’s”,
> neither SR data plane – it is either MPLS or IPv6), control/data/management
> planes would suffice.
>
> “etc” - doesn’t belong in a charter in any form.
>
> “
>
> Please be precise in Deliverables:
>
>
>
> “Study” – can’t be one, obliviously, it is part of the process, but not
> the result
>
> I think, informational and corresponding data models would be a better
> description?
>
>
>
> Thanks!
>
>
>
> Cheers,
>
> Jeff
>