Re: [Netslices] Preliminary charter text for discussion

Xavier de Foy <x.defoy.ietf@gmail.com> Tue, 30 January 2018 20:44 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 6502B12EA9D for <netslices@ietfa.amsl.com>; Tue, 30 Jan 2018 12:44:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 0Xagy_yDIhcf for <netslices@ietfa.amsl.com>; Tue, 30 Jan 2018 12:44:06 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 DAC2A12D838 for <NetSlices@ietf.org>; Tue, 30 Jan 2018 12:44:05 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id d54so19047347qtd.4 for <NetSlices@ietf.org>; Tue, 30 Jan 2018 12:44:05 -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=yIsZgJNyDKJr3pXAYjG/ne8kFLEehRv/a1FwZ3VxFYI=; b=VvRrQBWsusekVG9XUoI9XRvn2GywNkSQLOHsB2ort9ZrSzD+daFhXecsoSnCkSE9gS Vnh5O73M85v6EXdaoFnfYBwx+xf1OZQy3nmPTNLWCwVGhD3DYpPr7IB6OdbwMVo1kIP7 lu6rAjXJNMV1xWTYB2KYz+yAXB5FBVzlo3FVRmqtZ8b1QpuLV/1iD1kpuVV1QoNuzX3n 3G/kOE0bW8zuHtRFrLSLAxa9cExrf/Ih3euR0K3H/bzINaUNfH6bToYrYl2+7N6mSvqt LW8mm38tRyOIxtt6NnRrsPdQutfaIbnaHEK6UsWQS4vKT1F2GvcI9m/AXXLBmDOF9exb Lu/g==
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=yIsZgJNyDKJr3pXAYjG/ne8kFLEehRv/a1FwZ3VxFYI=; b=pfuB0YzCA5afJuebYKfkpWIC5RXqPNCY4w7DdIVOR+2rn3gooyWqiT+d8E5TSIaTJE AVFyZuiUDH9vmVWQ3M4kdSUNEQt65GJyKlUavTEcji8XwydsFUMV7R4cYdwbmEfxqoKi bNewodzfO+cFU+ho6pz0KL/bKKTHJs1j0kSct86WXS5VHmWwNLCnYae2njMGI3FdsHwB OcRd54WFwm3fw37khEeZ698SS+NUTQ64Qv6tQpsg4qN1h49wyJKf7IxmgDS5YD1Zrkyl yqJU8uU7wj6+U6tuVQPajZnXn2Byd1wEE8WsvzKXHknyXbOiszWWn2DV/da+4eJY2qoU COOg==
X-Gm-Message-State: AKwxytftO7utjsC3G2zykp72+OjNvO//JG+5/CyvZPkImZ23ZyL0SOJh 5s3OhlJDamMPTRRUBAQCXBnri8wYVuaQqJ770PU=
X-Google-Smtp-Source: AH8x227xz3fLGSFeNnf+5jC4x4XJFuXdN+1smh2uBTI7RcYzaR2oKH+BQnITb4l53tTdAEN8wQm4IcnGkHkOkJwuZSc=
X-Received: by 10.200.46.139 with SMTP id h11mr45178818qta.111.1517345045013; Tue, 30 Jan 2018 12:44:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.60.194 with HTTP; Tue, 30 Jan 2018 12:44:04 -0800 (PST)
In-Reply-To: <49297C39-EF21-4D3E-898B-4728B61221BB@huawei.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>
From: Xavier de Foy <x.defoy.ietf@gmail.com>
Date: Tue, 30 Jan 2018 15:44:04 -0500
Message-ID: <CAHYjOTbLHTFWgPS6k94ecykvW9CYY8=b9EUVuauZ-J0gO38BVg@mail.gmail.com>
To: "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>
Cc: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>, Pedro Martinez-Julia <pedro@nict.go.jp>, "NetSlices@ietf.org" <NetSlices@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c10f9068e8580564046c81"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/UJilANBaLtPEWRf8uJhXEs6MtCg>
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: Tue, 30 Jan 2018 20:44:09 -0000

Thanks Kiran, yes, I think one example is draft-homma-coms-slice-gateway,
which looks at the technology-independent requirements on some data plane
equipment. One interest of this is to help determine the appropriate
abstractions and attributes to use in the models.
Your wording looks good but I guess we can wait a bit longer for other
comments (here on the list and during tomorrow's COMS proponents meeting).
Best Regards,
Xavier.

On Tue, Jan 30, 2018 at 1:45 PM, Kiran.Makhijani <Kiran.Makhijani@huawei.com
> wrote:

> Xavier,
>
> This statement may need some additional clarity.
>
> “Study the mappings of technology independent network equipment
> configurations derived from the information model towards specific
> technologies and coordination with relevant WGs as needed.”
>
>
>
> I think what you are trying to say is that equipment configurations may
> need some work to provide slices related capabilities and support. Am I
> correct?
>
> If yes, then instead of use of “study”, we could say something to the
> effect “Identify and derive technology-independent network equipment
> configurations from the Information model in coordination with relevant WGs
> as needed”. This shows a clear deliverable.
>
>
>
> -Kiran
>
> *From: *Netslices <netslices-bounces@ietf.org> on behalf of Xavier de Foy
> <x.defoy.ietf@gmail.com>
> *Date: *Tuesday, January 30, 2018 at 7:22 AM
> *To: *Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
> *Cc: *Pedro Martinez-Julia <pedro@nict.go.jp>, "NetSlices@ietf.org" <
> NetSlices@ietf.org>
> *Subject: *Re: [Netslices] Preliminary charter text for discussion
>
>
>
> Thanks for clarifying the text Pedro. For reference and as base for future
> comments, here is a fixed version of the full text with your wording.
>
> Regards,
>
> Xavier.
>
>
> I. Context
>
> A network slice is a set of related infrastructure resources and service
> functions with qualities that respond to specific requirements, being able
> to cross multiple domains and 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 such as:
> - Data plane: DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc.
> - Controller and/or control plane: ACTN, PCE and RSVP-TE (requiring LDP,
> BGP, OSPF awareness at level below) etc.
> - Management plane: YANG, OAM etc.
>
> 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 requirements and functionalities of data plane
> entities as needed to enable the management 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 data plane
> technologies including DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3
> etc.
>
> 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.
> - Study the mappings of technology independent network equipment
> configurations derived from the information model towards specific
> 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
>