Re: [Netslices] Preliminary charter text for discussion

[Kiran.Makhijani <[e-mail]>]

+1, that was my original feedback.
agree with Jeff's feedback and follow up changes (although not necessarily information or data models,  they may simply be requirements to identified WGs).



--------------------------------------------------
Regards
Kiran
From:Xavier de Foy
To:Jeff Tantsura,
Cc:Daniele Ceccarelli,Leeyoung,Liang GENG,qiangli (D),Kiran.Makhijani,Pedro Martinez-Julia,[e-mail],Carlos Jesús Bernardos Cano,
Date:2018-02-02 03:55:00
Subject:Re: [Netslices] Preliminary charter text for discussion

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 <[e-mail]<mailto:[e-mail]>> 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