From nobody Thu Feb 1 06:52:17 2018 Return-Path: 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 8DF6E12AF83 for ; Thu, 1 Feb 2018 06:52:16 -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 GAoXyWfeADn8 for ; Thu, 1 Feb 2018 06:52:11 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 4FBE9129511 for ; Thu, 1 Feb 2018 06:52:11 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id x27so26686641qtm.12 for ; Thu, 01 Feb 2018 06:52:11 -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=RsVP+RMI/6DCCckYviMqmQpxa6ja3Mk7fERNk+t1hz0=; b=hSXj9w9t8qZ3NVEXe3n8CBHmiJs628sp0woM9WSkzdfU8nxknM6ChLjCXCLwSFkGIK rvBd30lj36fqs/suxj7m/3Xtw+uzmVvzYTAoDQQfUOmocDnus/hRcj6PISDSihDt7jVl vKP5jLuyG7egHO9mjOJCT1SPLantHg+mDS9MSmNUwnmjgCuhxbsQguCEyRxiJ0swZ5Qn VRLgZUZwrE1EQ3PWvO54kb6wK2a9DN1Sd1dn8LBZCeduH1IsLMae7wOqft3r/XwIfd/W c1NPZebA8kgoQsuqom3cTdjoX7ujqtwjymV6bY+prZMIE7XxbcNoN9+8SHWfer65MxVo hHnQ== 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=RsVP+RMI/6DCCckYviMqmQpxa6ja3Mk7fERNk+t1hz0=; b=b8Na7F+fdcJ7f1ln0/Kycx+DljfUw9cSwJtW3UUmtmXKbh1JFWI5pPoeIbwc9MnPkK 3PnWK1wrmaOMy1vPsPS/r28uX+E1cy2v2bPWTVVT6aapQ+Uosv8oCApgqbTBBTaxMbNF co4P9djdvXoWsWGfvUY4f2Oj9Y+DXqkdpQA7nuPvstA1cxw/5txu3t3aWE9YH5hF6GJY 1uguOeKKVAH3fBXxTB+UQwFeqR9gyv1/lHm4eVtyShtqO0Epxq6iB0AQ7BUFJaH6jrS5 zStZZQ7AovIHNfPUFc8TnffBflap9fUPjIv0DTht5CK+73cZS38TtGxoo+6mGJTxZd1s XWQA== X-Gm-Message-State: AKwxytdFOmlmSgMbqGld1JW4NjYTZalCVaxHSrIaKd8Br3WHgs4K7FEB 6pFTxREwNWQNYpHxtm+99YIrKVlZq1jxxyBgZKw68A== X-Google-Smtp-Source: AH8x227E/CzIDHegDNe53YCDW+AmKQ9QfIHprfvR/f/a3P4xxtAhUCFByhRpdpIFKyXoQ+OtukrLfspkPGPqN4ezIHs= X-Received: by 10.237.63.252 with SMTP id w57mr56752139qth.251.1517496730117; Thu, 01 Feb 2018 06:52:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.27.20 with HTTP; Thu, 1 Feb 2018 06:52:09 -0800 (PST) In-Reply-To: References: <1517163726.4051.23.camel@it.uc3m.es> <20180130043352.GB15400@spectre> <1517307927.3201.7.camel@it.uc3m.es> <49297C39-EF21-4D3E-898B-4728B61221BB@huawei.com> <06C389826B926F48A557D5DB5A54C4ED2A5F8047@dggemi509-mbx.china.huawei.com> <96DCDC2D-6F10-4C7E-A82E-3B868F55E23D@gmail.com> <7AEB3D6833318045B4AE71C2C87E8E173CF94DF4@sjceml521-mbs.china.huawei.com> From: Xavier de Foy Date: Thu, 1 Feb 2018 09:52:09 -0500 Message-ID: To: "NetSlices@ietf.org" Cc: Leeyoung , Jeff Tantsura , "qiangli (D)" , "Kiran.Makhijani" , Pedro Martinez-Julia , =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , Liang GENG Content-Type: multipart/alternative; boundary="001a1146f36e8beb66056427bd7b" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 14:52:17 -0000 --001a1146f36e8beb66056427bd7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, here is the latest version of the charter text prepared by COMS proponents, including changes discussed in this thread and some minor rewording in the first paragraph of the context section. 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 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 =E2=80=94 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 device models and 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. - Specify management requirements and functionalities of data plane entities as needed to enable the operation of network slices. - Study mappings 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 On Thu, Feb 1, 2018 at 1:23 AM, Liang GENG wrote: > Hi Young, > > > I believe that our discussion has different reference points for SBI. > > > I might be wrong but I understand that by saying SBI you mean device > configuration model. At this point we are aligned, as Jeff and Xavier als= o > pointed out, that COMS will not duplicate these device model works. > > > Best wishes > > Liang > > > ------------------------------ > *From:* Leeyoung > *Sent:* 01 February 2018 01:17:23 > *To:* Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; > Kiran.Makhijani > *Cc:* Pedro Martinez-Julia; Carlos Jes=C3=BAs Bernardos Cano; > NetSlices@ietf.org > > *Subject:* RE: [Netslices] Preliminary charter text for discussion > > > Hi Liang, > > > > The SBI work in TEAS has IP/MPLS, Segment Routing, OTN, WDM (with CCAMP) > in scope. What is technology-independent, generic data plane on SBI? We > cannot really separate data plane technology from the model on SBI. > > > > Thanks. > > Young > > > > *From:* Netslices [mailto:netslices-bounces@ietf.org] *On Behalf Of *Lian= g > GENG > *Sent:* Wednesday, January 31, 2018 9:54 AM > *To:* Jeff Tantsura ; qiangli (D) < > qiangli3@huawei.com>; Xavier de Foy ; > Kiran.Makhijani > *Cc:* Pedro Martinez-Julia ; Carlos Jes=C3=BAs Bernardo= s > Cano ; NetSlices@ietf.org > *Subject:* Re: [Netslices] Preliminary charter text for discussion > > > > Hi Jeff and all, > > > > I think what COMS is dealing with in terms of SBI is more relevant to > network configuration models. > > > > Technology-dependent ones may be done in existing WGs (i.e. TEAS-ACTN) > whilst COMS may endeavor to examine generic ones. > > > > Best wishes > > Liang > > > > > ------------------------------ > > *From:* Netslices on behalf of Jeff Tantsura > > *Sent:* 31 January 2018 22:48:09 > *To:* qiangli (D); Xavier de Foy; Kiran.Makhijani > *Cc:* Pedro Martinez-Julia; NetSlices@ietf.org; Carlos Jes=C3=BAs Bernard= os > Cano > *Subject:* Re: [Netslices] Preliminary charter text for discussion > > > > Hi Christina, > > > > My point =E2=80=93 you should never be dealing with device models directl= y, > irrespectively of where they were developed. > > > > Cheers, > > Jeff > > *From: *"qiangli (D)" > *Date: *Wednesday, January 31, 2018 at 02:53 > *To: *Jeff Tantsura , Xavier de Foy < > x.defoy.ietf@gmail.com>, "Kiran.Makhijani" > *Cc: *Pedro Martinez-Julia , Carlos Jes=C3=BAs Bernardo= s > Cano , "NetSlices@ietf.org" > *Subject: *RE: [Netslices] Preliminary charter text for discussion > > > > Hi Jeff, > > > > I think we may understand this sentence from another perspective. As you > said, there are a number of network/device configuration models, and thei= r > extension/mapping work is better to be done in corresponding WGs. For tho= se > technologies that are not chartered by relevant WGs, the mapping/extensio= n > work could be done in COMS if needed. What do you think? > > > > Best regards, > > Cristina QIANG > > > > *From:* Netslices [mailto:netslices-bounces@ietf.org > ] *On Behalf Of *Jeff Tantsura > *Sent:* Wednesday, January 31, 2018 5:09 AM > *To:* Xavier de Foy ; Kiran.Makhijani < > Kiran.Makhijani@huawei.com> > *Cc:* Pedro Martinez-Julia ; Carlos Jes=C3=BAs Bernardo= s > Cano ; NetSlices@ietf.org > *Subject:* Re: [Netslices] Preliminary charter text for discussion > > > > Hi, > > > > I don=E2=80=99t think this is right thing to do, device models would be n= umber of > layers below where you=E2=80=99d be operating. > > You might use draft-ietf-opsawg-service-model-explained as a reference. > > > > Cheers, > > Jeff > > *From: *Netslices on behalf of Xavier de Foy > > *Date: *Tuesday, January 30, 2018 at 15:44 > *To: *"Kiran.Makhijani" > *Cc: *Pedro Martinez-Julia , "NetSlices@ietf.org" < > NetSlices@ietf.org>, Carlos Jes=C3=BAs Bernardos Cano > *Subject: *Re: [Netslices] Preliminary charter text for discussion > > > > 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. > > =E2=80=9CStudy the mappings of technology independent network equipment > configurations derived from the information model towards specific > technologies and coordination with relevant WGs as needed.=E2=80=9D > > > > 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 =E2=80=9Cstudy=E2=80=9D, we could say some= thing to the > effect =E2=80=9CIdentify and derive technology-independent network equipm= ent > configurations from the Information model in coordination with relevant W= Gs > as needed=E2=80=9D. This shows a clear deliverable. > > > > -Kiran > > *From: *Netslices on behalf of Xavier de Foy > > *Date: *Tuesday, January 30, 2018 at 7:22 AM > *To: *Carlos Jes=C3=BAs Bernardos Cano > *Cc: *Pedro Martinez-Julia , "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 futur= e > 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 abl= e > 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 associate= d > 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 netwo= rk > 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 commercia= l > 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 sli= ce > 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 wi= ll > be leased to tenants, which will be able to use Customer Service Interfac= e > (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 =E2=80=94 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 exampl= e, > this may include abstractions of policy control and enforcement, or gatew= ay > functionalities. The WG will also study the mapping between the abstract > information model and managed entities, and will liaise with other IETF W= Gs > as needed. However, the WG will not attempt to replicate data plane > technologies including DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NV= O3 > 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 model= s > > > > _______________________________________________ Netslices mailing list > Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices > --001a1146f36e8beb66056427bd7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all, here is the latest version of the charte= r text prepared by COMS proponents, including changes discussed in this thr= ead and some minor rewording in the first paragraph of the context section.=
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 doma= in 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 associa= ted with a network slice are normally comprised of physical and logical con= nections in access, aggregation and backbone networks as well as computing = and storage elements. Service functions associated with a network slice inc= lude network functions and network function chains pre-defined using corres= ponding network infrastructure elements.

A "Network Slice"= is realized using a collection of technologies spanning across data, contr= ol and management planes. Many of them rely on existing IETF technologies i= ncluding both concluded and in-progress works such as:
- Data plane: Det= Net, 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 foun= dation of COMS is a technology-independent and resource-centric management = plane. In reality, the network slice provider may have diverse technology c= hoices in different domains due to geographical and commercial reasons. The= refore, COMS makes no assumption on which technology is used for specific d= omains. The goal of COMS is to define a common and inter-operative manageme= nt mechanism, which is essential for the concept of network slicing being a= dopted 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 operatio= n and management of a network slice in a uniform manner, even when this net= work slice span multiple technology and/or administrative domains.
- Ena= bling deployment of services over individual slices.

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

The WG will desc= ribe an information model representing a network slice, accounting for the = key elements used in network slices: connectivity, compute, storage resourc= es, network and service functions =E2=80=94 this information model includes= the representation of managed objects and corresponding management and ope= rations, 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 SD= I 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 requiremen= ts.
2 Lifecycle management of network slice.
3 Other FCAPS functions.= An important task of NSP is to aggregate faults, performance, status infor= mation and performance guarantees for certain services.
4 Slice composit= ion 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 functionali= ties of data plane entities as needed to enable the operation=C2=A0 of netw= ork slices. For example, this may include abstractions of policy control an= d enforcement, or gateway functionalities. The WG will also study the mappi= ng between the abstract information model and managed entities, and will li= aise with other IETF WGs as needed. However, the WG will not attempt to rep= licate device models and data plane technologies including DetNet, TE-Tunne= ls, MPLS, Segment Routing VPNs, NVO3 etc.

III. Deliverables

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

IV. Milestones

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


On Thu, Feb 1, 2018 at 1:23 AM, Liang GENG <li= ang.geng@hotmail.com> wrote:

Hi Young,


I believe that our discussion=C2=A0has different reference points for SBI.


I might be wrong but I understand= that=C2=A0by saying SBI you mean device configuration model. At this point= we are aligned, as Jeff and Xavier also pointed out, that COMS will not du= plicate these device model=C2=A0works.


Best wishes

Liang


From:= Leeyoung <leey= oung@huawei.com>
Sent: 01 February 2018 01:17:23
To: Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.Mak= hijani
Cc: Pedro Martinez-Julia; Carlos Jes=C3=BAs Bernardos Cano; NetSlices@ietf.org

Subject: RE: [Netslices] Preliminary charter text for discussion
=C2=A0

Hi Liang,

=C2=A0=

The SBI work = in TEAS has IP/MPLS, Segment Routing, OTN, WDM (with CCAMP) in scope. What = is technology-independent, generic data plane on SBI? We cannot really separate data plane technology from the model on SBI.

=C2=A0=

Thanks.

Young<= /p>

=C2=A0=

From: Netsli= ces [mailto:netslices-bounces@ietf.org] On Behalf Of Liang GENG
Sent: Wednesday, January 31, 2018 9:54 AM
To: Jeff Tantsura <jefftant.ietf@gmail.com>; qiangli (D) <qiangli3@huawei.com>; = Xavier de Foy <x.defoy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Makhijani@huawei.com&= gt;
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>; Carlos Jes=C3=BAs Bernardos Cano &= lt;cjbc@it.uc3m.es= >; NetSlices@iet= f.org
Subject: Re: [Netslices] Preliminary charter text for discussion

=C2=A0

H= i Jeff and all,

= =C2=A0

I= think what COMS is dealing with in terms of SBI is more relevant to networ= k configuration models.=C2=A0

= =C2=A0

T= echnology-dependent ones may be done in existing WGs=C2=A0(i.e. TEAS-ACTN) = whilst COMS may endeavor to examine generic ones.

= =C2=A0

B= est wishes

L= iang

= =C2=A0

= =C2=A0

From:= Netslices <netslices-bounces@ietf.org> on behalf of Jeff Tantsura <jefftant.ietf@gmail.com>
Sent: 31 January 2018 22:48:09
To: qiangli (D); Xavier de Foy; Kiran.Makhijani
Cc: Pedro Martinez-Julia; NetSlices@ietf.org; Carlos Jes=C3=BAs Bernardos Cano
Subject: Re: [Netslices] Preliminary charter text for discussion

=C2=A0

Hi Christina,

=C2=A0

My point =E2=80=93 you shou= ld never be dealing with device models directly, irrespectively of where th= ey were developed.

=C2=A0

Cheers,

Jeff

From: "qiangli (D)" &l= t;qiangli3@huawei.= com>
Date: Wednesday, January 31, 2018 at 02:53
To: Jeff Tantsura <jefftant.ietf@gmail.com>, Xavier de Foy <x.defoy.ietf@gmail.com= >, "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>, Carlos Jes=C3=BAs Bernardos Cano &= lt;cjbc@it.uc3m.es= >, "NetSlic= es@ietf.org" <NetSlices@ietf.org>
Subject: RE: [Netslices] Preliminary charter text for discussion

=C2=A0

Hi Jeff,

=C2=A0

I think we may understand this sentence from another pe= rspective. As you said, there are a number of network/device configuration = models, and their extension/mapping work is better to be done in corresponding WGs. For those technologies that are not chartered b= y relevant WGs, the mapping/extension work could be done in COMS if needed.= What do you think?

=C2=A0

Best regards,

Cristina QIANG

=C2=A0

From: Netslices [mailto:netslic= es-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, January 31, 2018 5:09 AM
To: Xavier de Foy <x.defoy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Makhijani@hu= awei.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>; Carlos Jes=C3=BAs Bernardos Cano &= lt;cjbc@it.uc3m.es= >; NetSlices@ietf.org<= /a>
Subject: Re: [Netslices] Preliminary charter text for discussion

=C2=A0

Hi,

=C2=A0

I don=E2=80=99t think this = is right thing to do, device models would be number of layers below where y= ou=E2=80=99d be operating.

You might use draft-ietf-op= sawg-service-model-explained as a reference.

=C2=A0

Cheers,

Jeff

From: Netslices <netslices-bounces@ietf.org> on behalf of Xavier de Foy <x.defoy.ietf@gmail.com>
Date: Tuesday, January 30, 2018 at 15:44
To: "Kiran.Makhijani" <Kir= an.Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>, "NetSlices@ietf.org" <NetSlices@ietf.org>, Carlos Jes=C3=BAs Bernardos Cano <= cjbc@it.uc3m.es>
Subject: Re: [Netslices] Preliminary charter text for discussion

=C2=A0

=C2=A0

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

Xavier,

This statement may need= some additional clarity.

=E2=80=9CSt= udy the mappings of technology independent network equipment configurations= derived from the information model towards specific technologies and coord= ination with relevant WGs as needed.=E2=80=9D

=C2=A0

I think what you are tr= ying 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 =E2=80=9Cstudy=E2=80=9D, we could say something to the effect =E2= =80=9CIdentify and derive technology-independent network equipment configur= ations from the Information model in coordination with relevant WGs as needed=E2=80=9D. This shows a c= lear deliverable.

=C2=A0

-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=C3=BAs Bernardos Cano <cjbc@it.u= c3m.es>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>, "NetSlices@ietf.org" <NetSlices@ietf.org>
Subject: Re: [Netslices] Preliminary charter text for discussion

= =C2=A0

= Xavier.


I. Context

A network slice is a set of related infrastructure resources and service fu= nctions with qualities that respond to specific requirements, being able to= cross multiple domains and use heterogeneous technologies. The goal of thi= s 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 o= f physical and logica= l connections in access, aggregation and backbone networks as well as compu= ting and storage elements. Service functions associated with a network slic= e 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 e= xisting IETF technologies including both concluded and in-progress works su= ch as:
- Data plane: DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc.
- Controller and/or control plane: ACTN, PCE and RSVP-TE (requiring LDP, BG= P, OSPF awareness at level below) etc.
- Management plane: YANG, OAM etc.

The foundation of COMS is a technology-independent and resource-centric man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for specific domains. The goal of COMS is to d= efine a common and inter-operative management mechanism, which is essential= for the concept of network slicing being adopted in a system with heteroge= neous network infrastructures and services functions. Major characteristics include:
- Enabling composition of slices within a single or over multiple domains.<= br> - Allowing the operation and management of a network slice in a uniform man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 subnet= s. Network slices will be leased to tenants, which will be able to use Cust= omer Service Interface (CSI) exposed by the NS provider to run management tasks (e.g., on-demand measurement) w= ithin their slice instance under certain policies.

The WG will describe an information model representing a network slice, acc= ounting for the key elements used in network slices: connectivity, compute,= storage resources, network and service functions =E2=80=94 this informatio= n 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 interwork= ing.

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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces.
4 Slice composition or stitching in multi-domain environment.
5 Slice management by the tenant under the control of NSP, including deploy= ing 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 ma= y include abstractions of policy control and enforcement, or gateway functi= onalities. The WG will also study the mapping between the abstract information model and managed entities, a= nd will liaise with other IETF WGs as needed. However, the WG will not atte= mpt 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 document= s 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 describe= d above in the scope section.
- SDI and CSI interface specifications and relevant YANG models.
- Study the mappings of technology independent network equipment configurat= ions derived from the information model towards specific technologies and c= oordination with relevant WGs as needed.

IV. Milestones

Dec 2018=C2=A0=C2=A0=C2=A0=C2=A0 Problem Statement, use cases and architect= ure
Dec 2018=C2=A0=C2=A0=C2=A0=C2=A0 Common information model and related YANG = model
June 2019=C2=A0=C2=A0=C2=A0 Network slices composition and interworking
October 2019 FCAPS management functions and operations on network
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sl= ices including abstractions of policy control and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 en= forcement, or gateway functionalities.
March 2020=C2=A0=C2=A0 SDI and CSI interface specifications and relevant YA= NG models

=C2=A0

___________________________= ____________________ Netslices mailing list Netslices@ietf.org<= /a> https://www.ietf.org/mailman/listinfo/netslices


--001a1146f36e8beb66056427bd7b-- From nobody Thu Feb 1 08:12:02 2018 Return-Path: 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 9111B12E04B for ; Thu, 1 Feb 2018 08:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.228 X-Spam-Level: X-Spam-Status: No, score=-4.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 oRJiF56GkN_L for ; Thu, 1 Feb 2018 08:11:56 -0800 (PST) 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 3CC6612D85E for ; Thu, 1 Feb 2018 08:11:55 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C739DB9A9272 for ; Thu, 1 Feb 2018 16:11:51 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 1 Feb 2018 16:11:52 +0000 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; Thu, 1 Feb 2018 08:11:44 -0800 From: Leeyoung To: Liang GENG , Jeff Tantsura , "qiangli (D)" , Xavier de Foy , Kiran.Makhijani CC: Pedro Martinez-Julia , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , "NetSlices@ietf.org" Thread-Topic: [Netslices] Preliminary charter text for discussion Thread-Index: AQHTl5eHHxrSxL2LX02p2vK4T3hqBqOKILoAgAGaPQCAAKMFAIAAYjuAgABSiACAADlLAIAAIQQAgAAHFYCAALPqgIAAc+WAgAASUAD//5BcsIABYpWAgAAcdvA= Date: Thu, 1 Feb 2018 16:11:43 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173CF961AB@sjceml521-mbs.china.huawei.com> References: <1517163726.4051.23.camel@it.uc3m.es> <20180130043352.GB15400@spectre> <1517307927.3201.7.camel@it.uc3m.es> <49297C39-EF21-4D3E-898B-4728B61221BB@huawei.com> <06C389826B926F48A557D5DB5A54C4ED2A5F8047@dggemi509-mbx.china.huawei.com>, <96DCDC2D-6F10-4C7E-A82E-3B868F55E23D@gmail.com> , <7AEB3D6833318045B4AE71C2C87E8E173CF94DF4@sjceml521-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.185] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E173CF961ABsjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 16:12:02 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E173CF961ABsjceml521mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Liang, Yes when I said SBI, I meant device configuration model. So I think there i= s no issue around this that COMS would not duplicate this model. But I think you talked about the network configuration model to be generic.= Is this part of the scope of COMS? I heard COMS would focus on customer se= rvice model and service delivery model, correct? Then network configuration= model is not the scope of COMS? By the way generic network configuration m= odel has been one of the foci of MPI of ACTN work in TEAS WG. Thanks. Young From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Thursday, February 01, 2018 12:23 AM To: Leeyoung ; Jeff Tantsura = ; qiangli (D) ; Xavier de Foy = ; Kiran.Makhijani Cc: Pedro Martinez-Julia ; Carlos Jes=FAs Bernardos Cano = ; NetSlices@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion Hi Young, I believe that our discussion has different reference points for SBI. I might be wrong but I understand that by saying SBI you mean device config= uration model. At this point we are aligned, as Jeff and Xavier also pointe= d out, that COMS will not duplicate these device model works. Best wishes Liang ________________________________ From: Leeyoung > Sent: 01 February 2018 01:17:23 To: Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.Makhijani Cc: Pedro Martinez-Julia; Carlos Jes=FAs Bernardos Cano; NetSlices@ietf.org= Subject: RE: [Netslices] Preliminary charter text for discussion Hi Liang, The SBI work in TEAS has IP/MPLS, Segment Routing, OTN, WDM (with CCAMP) in= scope. What is technology-independent, generic data plane on SBI? We canno= t really separate data plane technology from the model on SBI. Thanks. Young From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Liang GENG Sent: Wednesday, January 31, 2018 9:54 AM To: Jeff Tantsura >= ; qiangli (D) >; Xavier de = Foy >; Kiran.Makhijan= i > Cc: Pedro Martinez-Julia >; Carlo= s Jes=FAs Bernardos Cano >; NetSlic= es@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion Hi Jeff and all, I think what COMS is dealing with in terms of SBI is more relevant to netwo= rk configuration models. Technology-dependent ones may be done in existing WGs (i.e. TEAS-ACTN) whil= st COMS may endeavor to examine generic ones. Best wishes Liang ________________________________ From: Netslices > on behalf of Jeff Tantsura > Sent: 31 January 2018 22:48:09 To: qiangli (D); Xavier de Foy; Kiran.Makhijani Cc: Pedro Martinez-Julia; NetSlices@ietf.org; Ca= rlos Jes=FAs Bernardos Cano Subject: Re: [Netslices] Preliminary charter text for discussion Hi Christina, My point - you should never be dealing with device models directly, irrespe= ctively of where they were developed. Cheers, Jeff From: "qiangli (D)" > Date: Wednesday, January 31, 2018 at 02:53 To: Jeff Tantsura >= , Xavier de Foy >, "K= iran.Makhijani" > Cc: Pedro Martinez-Julia >, Carlo= s Jes=FAs Bernardos Cano >, "NetSli= ces@ietf.org" > Subject: RE: [Netslices] Preliminary charter text for discussion Hi Jeff, I think we may understand this sentence from another perspective. As you sa= id, there are a number of network/device configuration models, and their ex= tension/mapping work is better to be done in corresponding WGs. For those t= echnologies that are not chartered by relevant WGs, the mapping/extension w= ork could be done in COMS if needed. What do you think? Best regards, Cristina QIANG From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Jeff Tants= ura Sent: Wednesday, January 31, 2018 5:09 AM To: Xavier de Foy >; = Kiran.Makhijani > Cc: Pedro Martinez-Julia >; Carlo= s Jes=FAs Bernardos Cano >; NetSlic= es@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion Hi, I don't think this is right thing to do, device models would be number of l= ayers below where you'd be operating. You might use draft-ietf-opsawg-service-model-explained as a reference. Cheers, Jeff From: Netslices > on behalf of Xavier de Foy > Date: Tuesday, January 30, 2018 at 15:44 To: "Kiran.Makhijani" > Cc: Pedro Martinez-Julia >, "NetS= lices@ietf.org" >, Carlos Jes=FAs Bernardos Cano > Subject: Re: [Netslices] Preliminary charter text for discussion Thanks Kiran, yes, I think one example is draft-homma-coms-slice-gateway, w= hich looks at the technology-independent requirements on some data plane eq= uipment. One interest of this is to help determine the appropriate abstract= ions and attributes to use in the models. Your wording looks good but I guess we can wait a bit longer for other comm= ents (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 > wrote: Xavier, This statement may need some additional clarity. "Study the mappings of technology independent network equipment configurati= ons derived from the information model towards specific technologies and co= ordination with relevant WGs as needed." I think what you are trying to say is that equipment configurations may nee= d some work to provide slices related capabilities and support. Am I correc= t? If yes, then instead of use of "study", we could say something to the effec= t "Identify and derive technology-independent network equipment configurati= ons from the Information model in coordination with relevant WGs as needed"= . This shows a clear deliverable. -Kiran From: Netslices > on behalf of Xavier de Foy > Date: Tuesday, January 30, 2018 at 7:22 AM To: Carlos Jes=FAs Bernardos Cano > Cc: Pedro Martinez-Julia >, "NetS= lices@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 fu= nctions with qualities that respond to specific requirements, being able to= cross multiple domains and use heterogeneous technologies. The goal of thi= s group is to produce and promote a technology-independent and resource-cen= tric management plane for network slices. Resources associated with a netwo= rk slice are normally comprised of physical and logical connections in acce= ss, aggregation and backbone networks as well as computing and storage elem= ents. Service functions associated with a network slice include network fun= ctions and network function chains pre-defined using corresponding network = infrastructure elements. A "Network Slice" is realized using a collection of technologies spanning a= cross data, control and management planes. Many of them rely on existing IE= TF 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, BG= P, OSPF awareness at level below) etc. - Management plane: YANG, OAM etc. The foundation of COMS is a technology-independent and resource-centric man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for sp= ecific 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 s= ervices 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 man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 thro= ugh the notion of network slice subnets. Network slices will be leased to t= enants, which will be able to use Customer Service Interface (CSI) exposed = by the NS provider to run management tasks (e.g., on-demand measurement) wi= thin their slice instance under certain policies. The WG will describe an information model representing a network slice, acc= ounting 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 al= so 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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces. 4 Slice composition or stitching in multi-domain environment. 5 Slice management by the tenant under the control of NSP, including deploy= ing 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 ma= y include abstractions of policy control and enforcement, or gateway functi= onalities. The WG will also study the mapping between the abstract informat= ion model and managed entities, and will liaise with other IETF WGs as need= ed. However, the WG will not attempt to replicate data plane technologies i= ncluding DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc. III. Deliverables WG deliverables are listed below and may be split in any number of document= s 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 describe= d above in the scope section. - SDI and CSI interface specifications and relevant YANG models. - Study the mappings of technology independent network equipment configurat= ions derived from the information model towards specific technologies and c= oordination 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 _______________________________________________ Netslices mailing list Nets= lices@ietf.org https://www.ietf.org/mailman/list= info/netslices --_000_7AEB3D6833318045B4AE71C2C87E8E173CF961ABsjceml521mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Liang,

 

Yes when I said SBI, I meant device c= onfiguration model. So I think there is no issue around this that COMS woul= d not duplicate this model.

 

But I think you talked about the netw= ork configuration model to be generic. Is this part of the scope of COMS? I= heard COMS would focus on customer service model and service delivery model, correct? Then network configuration model is n= ot the scope of COMS? By the way generic network configuration model has be= en one of the foci of MPI of ACTN work in TEAS WG.

 

Thanks.

Young

 

From: Liang GENG [mailto:liang.geng@= hotmail.com]
Sent: Thursday, February 01, 2018 12:23 AM
To: Leeyoung <leeyoung@huawei.com>; Jeff Tantsura <jefftant= .ietf@gmail.com>; qiangli (D) <qiangli3@huawei.com>; Xavier de Foy= <x.defoy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Makhijani@huawei= .com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>; Carlos Jes=FAs Be= rnardos Cano <cjbc@it.uc3m.es>; NetSlices@ietf.org
Subject: Re: [Netslices] Preliminary charter text for discussion

 

H= i Young,

<= o:p> 

I= believe that our discussion has different reference points for SBI.

<= o:p> 

I= might be wrong but I understand that by saying SBI you mean device co= nfiguration model. At this point we are aligned, as Jeff and Xavier also po= inted out, that COMS will not duplicate these device model works.

<= o:p> 

B= est wishes

L= iang

<= o:p> 

From: Leeyou= ng <leeyoung@huawei.com> Sent: 01 February 2018 01:17:23
To: Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.Mak= hijani
Cc: Pedro Martinez-Julia; Carlos Jes=FAs Bernardos Cano; NetSlices@ietf.org
Subject: RE: [Netslices] Preliminary charter text for discussion

 

Hi Liang,

 

The SBI work in TEAS has IP/MPLS, Se= gment Routing, OTN, WDM (with CCAMP) in scope. What is technology-independe= nt, generic data plane on SBI? We cannot really separate data plane technology from the model on SBI.

 

Thanks.

Young

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Liang GENG
Sent: Wednesday, January 31, 2018 9:54 AM
To: Jeff Tantsura <jef= ftant.ietf@gmail.com>; qiangli (D) <qiangli3@huawei.com>; Xavier de Foy <x.defoy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Ma= khijani@huawei.com>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>; Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>; NetSlices@ietf.org
Subject: Re: [Netslices] Preliminary charter text for discussion

 

H= i Jeff and all,

&= nbsp;

I= think what COMS is dealing with in terms of SBI is more relevant to networ= k configuration models. 

&= nbsp;

T= echnology-dependent ones may be done in existing WGs (i.e. TEAS-ACTN) = whilst COMS may endeavor to examine generic ones.

&= nbsp;

B= est wishes

L= iang

&= nbsp;

&= nbsp;

From: Netsl= ices <netslices-bounces@ie= tf.org> on behalf of Jeff Tantsura <= jefftant.ietf@gmail.com>
Sent: 31 January 2018 22:48:09
To: qiangli (D); Xavier de Foy; Kiran.Makhijani
Cc: Pedro Martinez-Julia; NetS= lices@ietf.org; Carlos Jes=FAs Bernardos Cano
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi Christina,

 

My point – you should never be dealing with = device models directly, irrespectively of where they were developed.

 

Cheers,

Jeff=

Fr= om: "qiangli (D)" &l= t;qiangli3@huawei.com>
Date: Wednesday, January 31, 2018 at 02:53
To: Jeff Tantsura <jef= ftant.ietf@gmail.com>, Xavier de Foy <x.defoy.ietf@gmail.com>, "Kiran.Makhijani" = <Kiran.Makhijani@huawei.co= m>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>, Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>, "NetSlices@ietf.org" <NetSlices@ietf.org>
Subject: RE: [Netslices] Preliminary charter text for discussion

 

Hi = Jeff,

&nb= sp;

I t= hink we may understand this sentence from another perspective. As you said,= there are a number of network/device configuration models, and their exten= sion/mapping work is better to be done in corresponding WGs. For those technologies that are not chartered by rel= evant WGs, the mapping/extension work could be done in COMS if needed. What= do you think?

&nb= sp;

Bes= t regards,

Cri= stina QIANG

&nb= sp;

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, January 31, 2018 5:09 AM
To: Xavier de Foy <x.de= foy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>; Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>; NetSlices@ietf.org
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi,

 

I don’t think this is right thing to do, dev= ice models would be number of layers below where you’d be operating.<= o:p>

You might use draft-ietf-opsawg-service-model-expl= ained as a reference.

 

Cheers,

Jeff=

Fr= om: Netslices <n= etslices-bounces@ietf.org> on behalf of Xavier de Foy <x.defoy.ietf@gmail.com>
Date: Tuesday, January 30, 2018 at 15:44
To: "Kiran.Makhijani" <Kiran.Makhijani@huawe= i.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>, "NetSlices@ietf.org<= /a>" <NetSlices@ietf.org>, Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>
Subject: Re: [Netslices] Preliminary charter text for discussion

 

 

On Tue, Jan 30, 2018 at 1:45 PM, Kiran.Makhijani &= lt;Kiran.Ma= khijani@huawei.com> wrote:

Xavier,

This statement may need some additional clarit= y.

“Study the mappings of techn= ology independent network equipment configurations derived from the informa= tion model towards specific technologies and coordination with relevant WGs as needed.”

 

I think what you are trying to say is that equ= ipment configurations may need some work to provide slices related capabili= ties and support. Am I correct?

If yes, then instead of use of “study= 221;, we could say something to the effect “Identify and derive techn= ology-independent network equipment configurations from the Information model in coordination with relevant WGs as needed”. This shows a cle= ar deliverable.

 

-Kiran

From: Netslices <netslices-bounces@ietf.org> on behalf of Xavier de Foy <x.defoy.ietf@gmail.com<= /a>>
Date: Tuesday, January 30, 2018 at 7:22 AM
To: Carlos Jes=FAs 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

 

Xavier.


I. Context

A network slice is a set of related infrastructure resources and service fu= nctions with qualities that respond to specific requirements, being able to= cross multiple domains and use heterogeneous technologies. The goal of thi= s 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 o= f physical and logical connections in access= , aggregation and backbone networks as well as computing and storage elemen= ts. Service functions associated with a network slice include network funct= ions 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 e= xisting IETF technologies including both concluded and in-progress works su= ch as:
- Data plane: DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc.
- Controller and/or control plane: ACTN, PCE and RSVP-TE (requiring LDP, BG= P, OSPF awareness at level below) etc.
- Management plane: YANG, OAM etc.

The foundation of COMS is a technology-independent and resource-centric man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for specific domains. The goal of COMS is to d= efine a common and inter-operative management mechanism, which is essential= for the concept of network slicing being adopted in a system with heteroge= neous network infrastructures and services functions. Major characteristics include:
- Enabling composition of slices within a single or over multiple domains.<= br> - Allowing the operation and management of a network slice in a uniform man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 subnet= s. Network slices will be leased to tenants, which will be able to use Cust= omer Service Interface (CSI) exposed by the NS provider to run management tasks (e.g., on-demand measurement) w= ithin their slice instance under certain policies.

The WG will describe an information model representing a network slice, acc= ounting 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 interwork= ing.

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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces.
4 Slice composition or stitching in multi-domain environment.
5 Slice management by the tenant under the control of NSP, including deploy= ing 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 ma= y include abstractions of policy control and enforcement, or gateway functi= onalities. The WG will also study the mapping between the abstract information model and managed entities, a= nd will liaise with other IETF WGs as needed. However, the WG will not atte= mpt 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 document= s 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 describe= d above in the scope section.
- SDI and CSI interface specifications and relevant YANG models.
- Study the mappings of technology independent network equipment configurat= ions derived from the information model towards specific technologies and c= oordination with relevant WGs as needed.

IV. Milestones

Dec 2018     Problem Statement, use cases and architect= ure
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
             sl= ices including abstractions of policy control and
             en= forcement, or gateway functionalities.
March 2020   SDI and CSI interface specifications and relevant YA= NG models

 

_______________________________________________ Ne= tslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices

--_000_7AEB3D6833318045B4AE71C2C87E8E173CF961ABsjceml521mbschi_-- From nobody Thu Feb 1 08:14:08 2018 Return-Path: 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 BB92312E8A2 for ; Thu, 1 Feb 2018 08:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ScMQhN0q; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ITQiZf0S 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 v7EzDRfhY38J for ; Thu, 1 Feb 2018 08:13:58 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 4925E12EB7C for ; Thu, 1 Feb 2018 08:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517501634; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SFUSyQu3hssiI8IzQwxwmqV1ioR0cKEz0NIxPFc8HEs=; b=ScMQhN0qA36l1G/pRCiZn0AnbfOW1abZq3I0HWE456WJv+jQOsp9XEjQOmu01WPl cJSNr5UceLsXkCtTXdjRY2Fcp/nu+k8QIYIWOL3G0+IYqbQ6amis5weDem1iw3WY AUHIjyjmQk96YEiMd1BTffyoR1TW9+8uze02/0l4gmQ=; X-AuditID: c1b4fb25-48bff7000000341b-7e-5a733cc29395 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F8.45.13339.2CC337A5; Thu, 1 Feb 2018 17:13:54 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 1 Feb 2018 17:13:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UEn4rU1kBnHnwjOXryfAhgPMOwwvcv6gFFWSgAzECLo=; b=ITQiZf0SM7Sfw4ocFddlIdkJfYXs2E1GVCbnI/i77gEUmvZwQBRzWjbK1ajBBFFloX/67ZVd/Rda1Wg5KcHO7kPn4fYBpvra1SEAPuh3q3mvJOMuLIra4bewq+dYwd1M1J/VQjtDuwEIoqge8NouSggfkTMognm1p3mJMUfev3U= Received: from HE1PR0701MB2714.eurprd07.prod.outlook.com (10.168.188.21) by HE1PR0701MB3049.eurprd07.prod.outlook.com (10.168.93.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Thu, 1 Feb 2018 16:13:52 +0000 Received: from HE1PR0701MB2714.eurprd07.prod.outlook.com ([fe80::2533:9086:fd5f:b5c3]) by HE1PR0701MB2714.eurprd07.prod.outlook.com ([fe80::2533:9086:fd5f:b5c3%18]) with mapi id 15.20.0464.012; Thu, 1 Feb 2018 16:13:52 +0000 From: Daniele Ceccarelli To: Leeyoung , Liang GENG , "Jeff Tantsura" , "qiangli (D)" , Xavier de Foy , Kiran.Makhijani CC: Pedro Martinez-Julia , "NetSlices@ietf.org" , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= Thread-Topic: [Netslices] Preliminary charter text for discussion Thread-Index: AQHTl5eHwO5uQYFJW0COlDVxpyQhaKOJmp4AgAGaPQCAAKMFAIAAYjuAgABShwCAADlMAIAAIQQAgAAHFYCAALPqgIAAc+WAgAASUACAABdigIAA24+AgACkbYCAAABxwA== Date: Thu, 1 Feb 2018 16:13:52 +0000 Message-ID: References: <1517163726.4051.23.camel@it.uc3m.es> <20180130043352.GB15400@spectre> <1517307927.3201.7.camel@it.uc3m.es> <49297C39-EF21-4D3E-898B-4728B61221BB@huawei.com> <06C389826B926F48A557D5DB5A54C4ED2A5F8047@dggemi509-mbx.china.huawei.com>, <96DCDC2D-6F10-4C7E-A82E-3B868F55E23D@gmail.com> , <7AEB3D6833318045B4AE71C2C87E8E173CF94DF4@sjceml521-mbs.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E173CF961AB@sjceml521-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E173CF961AB@sjceml521-mbs.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.38.67.165] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB3049; 7:yfUMlCzgNXPSyULqIlGLlAsv9PF4+ozJS9OR9OjdUsQzzGupbck9kY6yUsZVysBibjNLmUMnuQOyW5TGqDXkVUesofy+nDEGVM0HUou1hgE1GEOn/p2ND5jvKEHXhgutcBDOm0UmhNjDsM7snqVV5qvvoe5g2Bek3HPA6pMnwYPfm/4dgRMB4mfHuLEYzjACRrTjDroph/C3xY8Lp7O1bp3jYO1V/vieqQes+a7iWkQYEOUgTcphttGpi642Yk4U x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 079a224d-f93d-44da-e53a-08d5698ec927 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0701MB3049; x-ms-traffictypediagnostic: HE1PR0701MB3049: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(131327999870524)(50582790962513)(85827821059158)(130873036417446)(194151415913766)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(93006095)(93001095)(3002001)(10201501046)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR0701MB3049; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3049; x-forefront-prvs: 0570F1F193 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(39380400002)(366004)(396003)(376002)(189003)(76104003)(199004)(37854004)(66066001)(186003)(2900100001)(81156014)(93886005)(97736004)(8676002)(8936002)(99286004)(106356001)(81166006)(3846002)(790700001)(229853002)(6116002)(6246003)(86362001)(25786009)(606006)(2906002)(39060400002)(9686003)(59450400001)(6306002)(54896002)(53936002)(7696005)(74316002)(236005)(316002)(102836004)(7736002)(3280700002)(14454004)(53946003)(110136005)(6436002)(53546011)(55016002)(26005)(4326008)(45080400002)(6506007)(54906003)(68736007)(76176011)(3660700001)(5660300001)(105586002)(478600001)(966005)(5250100002)(2950100002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB3049; H:HE1PR0701MB2714.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: s3LBEecJCFBDJFLw3iOVGsa8y//UvZEJq9e2teDM2aVWXRYX8JDHVQmxR1tuUpQtM11o7DngA65iws3dC544+g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB271459213C062281074D54EDF0FA0HE1PR0701MB2714_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 079a224d-f93d-44da-e53a-08d5698ec927 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 16:13:52.2338 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3049 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+c5lOzMXn0vxxRzF6AKV62LEIUxUKBZo1h+VTMuOdTLLpu2Y pEQapJgWaZk10Wm1LhiWWnmhmLgUyYzK7KIklY7yFpETbYmax8/A/37v+7zv+zx8fByt6WX9 uARTimg2CYk6hQdjiaoLDHAEScZ1zXYtn1VfQ/GDOW6K7/7SpeSLrFv59+5pmj97yYb4wpYm xA90LedftVtQiMrQUNyjNPRdaFcYzjX/ZA02m5syjH2sZg39LXXKnQqjR9AhMTEhVTSvDT7g cWToe6EiefAWfSrLWUpnIruLykUcB3gj3K5dkIs8OA1+jmC07xtFilYE47X9swWDRygYG8lk iWKhYPLNbwUpviNwdvbT8i0F3gxOR7jc98YuBEXDhTNDKo7GJQjujUfIvAiHwOVr1yiZvXEo dE4MsGThMoI/1lusfIjBy8De4CnPqPEBGKqqoOcCKiGvrZORBRXeA0M/sliZEdZC/tObiJj5 QrezbNYAMAbbs9c0YR8Y6JtiCS+FJx2tDGEtdJTlIdkAcC0FFe1WBRH08KTgJyIcAY1l3SwZ akMwlelWEmENVLraKJIiDh5m1c85J8F4QSVNFkoRXLR1zNmV0OB+t42wP0ze+YXykb54XnLC SfCjsYQtnn0CL3hhcTKkr4dPVwsVhFfDnRtDNOEAuD7lYOb3y5GyAvlIohR3PH5DoF40JxyU pCST3iSm1KCZn9f0eGJ5PXo3HOpAmEM6T3WzVjJqWCFVSjvuQMDROm/1sN1s1KgPCWnpojkp 1nwyUZQcaDHH6HzVL7arjRocL6SIx0QxWTT/VylO5ZeJPLvOfzZ4vu29d3dl1ZnRJQvDv57w /Rr7QEg3RHpF7orJKH/Zl1PN1lbG3vw7Em+yH45wrZ4IiA6uyd2095Hyl6Cybbm/dr12k9dK rqlnX8v0/tHeorSYD7+zLbuDtNZwztcZlj244qHraIlXz6ue5owrKQHRO4Sol1E5A7cbw+pO ++sY6YiwfhVtloR/arhnbXUDAAA= Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 16:14:07 -0000 --_000_HE1PR0701MB271459213C062281074D54EDF0FA0HE1PR0701MB2714_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1, this is exactly my comment of some days ago. BR Daniele From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Leeyoung Sent: gioved=EC 1 febbraio 2018 17:12 To: Liang GENG ; Jeff Tantsura ; qiangli (D) ; Xavier de Foy ; Kiran.Makhijani Cc: Pedro Martinez-Julia ; NetSlices@ietf.org; Carlos Jes= =FAs Bernardos Cano Subject: Re: [Netslices] Preliminary charter text for discussion Hi Liang, Yes when I said SBI, I meant device configuration model. So I think there i= s no issue around this that COMS would not duplicate this model. But I think you talked about the network configuration model to be generic.= Is this part of the scope of COMS? I heard COMS would focus on customer se= rvice model and service delivery model, correct? Then network configuration= model is not the scope of COMS? By the way generic network configuration m= odel has been one of the foci of MPI of ACTN work in TEAS WG. Thanks. Young From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Thursday, February 01, 2018 12:23 AM To: Leeyoung >; Jeff Tantsu= ra >; qiangli (D) <= qiangli3@huawei.com>; Xavier de Foy >; Kiran.Makhijani > Cc: Pedro Martinez-Julia >; Carlo= s Jes=FAs Bernardos Cano >; NetSlic= es@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion Hi Young, I believe that our discussion has different reference points for SBI. I might be wrong but I understand that by saying SBI you mean device config= uration model. At this point we are aligned, as Jeff and Xavier also pointe= d out, that COMS will not duplicate these device model works. Best wishes Liang ________________________________ From: Leeyoung > Sent: 01 February 2018 01:17:23 To: Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.Makhijani Cc: Pedro Martinez-Julia; Carlos Jes=FAs Bernardos Cano; NetSlices@ietf.org= Subject: RE: [Netslices] Preliminary charter text for discussion Hi Liang, The SBI work in TEAS has IP/MPLS, Segment Routing, OTN, WDM (with CCAMP) in= scope. What is technology-independent, generic data plane on SBI? We canno= t really separate data plane technology from the model on SBI. Thanks. Young From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Liang GENG Sent: Wednesday, January 31, 2018 9:54 AM To: Jeff Tantsura >= ; qiangli (D) >; Xavier de = Foy >; Kiran.Makhijan= i > Cc: Pedro Martinez-Julia >; Carlo= s Jes=FAs Bernardos Cano >; NetSlic= es@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion Hi Jeff and all, I think what COMS is dealing with in terms of SBI is more relevant to netwo= rk configuration models. Technology-dependent ones may be done in existing WGs (i.e. TEAS-ACTN) whil= st COMS may endeavor to examine generic ones. Best wishes Liang ________________________________ From: Netslices > on behalf of Jeff Tantsura > Sent: 31 January 2018 22:48:09 To: qiangli (D); Xavier de Foy; Kiran.Makhijani Cc: Pedro Martinez-Julia; NetSlices@ietf.org; Ca= rlos Jes=FAs Bernardos Cano Subject: Re: [Netslices] Preliminary charter text for discussion Hi Christina, My point - you should never be dealing with device models directly, irrespe= ctively of where they were developed. Cheers, Jeff From: "qiangli (D)" > Date: Wednesday, January 31, 2018 at 02:53 To: Jeff Tantsura >= , Xavier de Foy >, "K= iran.Makhijani" > Cc: Pedro Martinez-Julia >, Carlo= s Jes=FAs Bernardos Cano >, "NetSli= ces@ietf.org" > Subject: RE: [Netslices] Preliminary charter text for discussion Hi Jeff, I think we may understand this sentence from another perspective. As you sa= id, there are a number of network/device configuration models, and their ex= tension/mapping work is better to be done in corresponding WGs. For those t= echnologies that are not chartered by relevant WGs, the mapping/extension w= ork could be done in COMS if needed. What do you think? Best regards, Cristina QIANG From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Jeff Tants= ura Sent: Wednesday, January 31, 2018 5:09 AM To: Xavier de Foy >; = Kiran.Makhijani > Cc: Pedro Martinez-Julia >; Carlo= s Jes=FAs Bernardos Cano >; NetSlic= es@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion Hi, I don't think this is right thing to do, device models would be number of l= ayers below where you'd be operating. You might use draft-ietf-opsawg-service-model-explained as a reference. Cheers, Jeff From: Netslices > on behalf of Xavier de Foy > Date: Tuesday, January 30, 2018 at 15:44 To: "Kiran.Makhijani" > Cc: Pedro Martinez-Julia >, "NetS= lices@ietf.org" >, Carlos Jes=FAs Bernardos Cano > Subject: Re: [Netslices] Preliminary charter text for discussion Thanks Kiran, yes, I think one example is draft-homma-coms-slice-gateway, w= hich looks at the technology-independent requirements on some data plane eq= uipment. One interest of this is to help determine the appropriate abstract= ions and attributes to use in the models. Your wording looks good but I guess we can wait a bit longer for other comm= ents (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 > wrote: Xavier, This statement may need some additional clarity. "Study the mappings of technology independent network equipment configurati= ons derived from the information model towards specific technologies and co= ordination with relevant WGs as needed." I think what you are trying to say is that equipment configurations may nee= d some work to provide slices related capabilities and support. Am I correc= t? If yes, then instead of use of "study", we could say something to the effec= t "Identify and derive technology-independent network equipment configurati= ons from the Information model in coordination with relevant WGs as needed"= . This shows a clear deliverable. -Kiran From: Netslices > on behalf of Xavier de Foy > Date: Tuesday, January 30, 2018 at 7:22 AM To: Carlos Jes=FAs Bernardos Cano > Cc: Pedro Martinez-Julia >, "NetS= lices@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 fu= nctions with qualities that respond to specific requirements, being able to= cross multiple domains and use heterogeneous technologies. The goal of thi= s group is to produce and promote a technology-independent and resource-cen= tric management plane for network slices. Resources associated with a netwo= rk slice are normally comprised of physical and logical connections in acce= ss, aggregation and backbone networks as well as computing and storage elem= ents. Service functions associated with a network slice include network fun= ctions and network function chains pre-defined using corresponding network = infrastructure elements. A "Network Slice" is realized using a collection of technologies spanning a= cross data, control and management planes. Many of them rely on existing IE= TF 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, BG= P, OSPF awareness at level below) etc. - Management plane: YANG, OAM etc. The foundation of COMS is a technology-independent and resource-centric man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for sp= ecific 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 s= ervices 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 man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 thro= ugh the notion of network slice subnets. Network slices will be leased to t= enants, which will be able to use Customer Service Interface (CSI) exposed = by the NS provider to run management tasks (e.g., on-demand measurement) wi= thin their slice instance under certain policies. The WG will describe an information model representing a network slice, acc= ounting 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 al= so 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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces. 4 Slice composition or stitching in multi-domain environment. 5 Slice management by the tenant under the control of NSP, including deploy= ing 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 ma= y include abstractions of policy control and enforcement, or gateway functi= onalities. The WG will also study the mapping between the abstract informat= ion model and managed entities, and will liaise with other IETF WGs as need= ed. However, the WG will not attempt to replicate data plane technologies i= ncluding DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc. III. Deliverables WG deliverables are listed below and may be split in any number of document= s 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 describe= d above in the scope section. - SDI and CSI interface specifications and relevant YANG models. - Study the mappings of technology independent network equipment configurat= ions derived from the information model towards specific technologies and c= oordination 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 _______________________________________________ Netslices mailing list Nets= lices@ietf.org https://www.ietf.org/mailman/list= info/netslices --_000_HE1PR0701MB271459213C062281074D54EDF0FA0HE1PR0701MB2714_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1,

 =

this is e= xactly my comment of some days ago.

&nbs= p;

BR
Daniele 

&nbs= p;

From: = Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Leeyoung
Sent: gioved=EC 1 febbraio 2018 17:12
To: Liang GENG <liang.geng@hotmail.com>; Jeff Tantsura <jef= ftant.ietf@gmail.com>; qiangli (D) <qiangli3@huawei.com>; Xavier d= e Foy <x.defoy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Makhijani@h= uawei.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>; NetSlices@ietf.or= g; Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi Liang,

 

Yes when I said SBI, I= meant device configuration model. So I think there is no issue around this= that COMS would not duplicate this model.=

 

But I think you talked= about the network configuration model to be generic. Is this part of the s= cope of COMS? I heard COMS would focus on customer service model and service delivery model, correct? Then network configurat= ion model is not the scope of COMS? By the way generic network configuratio= n model has been one of the foci of MPI of ACTN work in TEAS WG.

 

Thanks.

Young

 

From: = Liang GENG [mailto:liang.geng@hot= mail.com]
Sent: Thursday, February 01, 2018 12:23 AM
To: Leeyoung <leeyoung@hua= wei.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; qiangli (D) <qiangli3@huawei.com>; Xavier de Foy <x.defoy.ietf@gmail.com&g= t;; Kiran.Makhijani <Kiran= .Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>; Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>; NetSlices@ietf.org
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi Young,

 

I believe that our discussion has different reference po= ints for SBI.

 

I might be wrong but I understand that by saying SBI you= mean device configuration model. At this point we are aligned, as Jeff and= Xavier also pointed out, that COMS will not duplicate these device model works.

 

Best wishes

Liang

 

From: Leeyoung <leeyoung@huawei.com>
Sent: 01 February 2018 01:17:23
To: Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.Mak= hijani
Cc: Pedro Martinez-Julia; Carlos Jes=FAs Bernardos Cano; NetSlices@ietf.org
Subject: RE: [Netslices] Preliminary charter text for discussion

 

Hi Liang,

 

The SBI work in TEAS = has IP/MPLS, Segment Routing, OTN, WDM (with CCAMP) in scope. What is techn= ology-independent, generic data plane on SBI? We cannot really separate data plane technology from the model on SBI.

 

Thanks.

Young

 

From:= Netslices [mailto:netslices-= bounces@ietf.org] On Behalf Of Liang GENG
Sent: Wednesday, January 31, 2018 9:54 AM
To: Jeff Tantsura <jef= ftant.ietf@gmail.com>; qiangli (D) <qiangli3@huawei.com>; Xavier de Foy <x.defoy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Ma= khijani@huawei.com>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>; Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>; NetSlices@ietf.org
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi Jeff and all,

 

I think what COMS is dealing with in terms of SBI is more rel= evant to network configuration models. 

 

Technology-dependent ones may be done in existing WGs (i= .e. TEAS-ACTN) whilst COMS may endeavor to examine generic ones.

 

Best wishes

Liang

 

 

From: Netslices <netslices-bounces@ietf.org> on behalf of Jeff Tantsura <= jefftant.ietf@gmail.com>
Sent: 31 January 2018 22:48:09
To: qiangli (D); Xavier de Foy; Kiran.Makhijani
Cc: Pedro Martinez-Julia; NetS= lices@ietf.org; Carlos Jes=FAs Bernardos Cano
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi Christina,

 

My point – you should n= ever be dealing with device models directly, irrespectively of where they w= ere developed.

 

Cheers,=

Jeff

From: &quo= t;qiangli (D)" <qiangli3@hua= wei.com>
Date: Wednesday, January 31, 2018 at 02:53
To: Jeff Tantsura <jef= ftant.ietf@gmail.com>, Xavier de Foy <x.defoy.ietf@gmail.com>, "Kiran.Makhijani" = <Kiran.Makhijani@huawei.co= m>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>, Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>, "NetSlices@ietf.org" <NetSlices@ietf.org>
Subject: RE: [Netslices] Preliminary charter text for discussion

 

Hi Jeff,

 

I think we may understand this sentence from another perspectiv= e. As you said, there are a number of network/device configuration models, = and their extension/mapping work is better to be done in corresponding WGs. For those technologies that are not chart= ered by relevant WGs, the mapping/extension work could be done in COMS if n= eeded. What do you think?

 

Best regards,

Cristina QIANG

 

From: Netslices [mailto= :netslices-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, January 31, 2018 5:09 AM
To: Xavier de Foy <x.de= foy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>; Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>; NetSlices@ietf.org
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi,

 

I don’t think this is r= ight thing to do, device models would be number of layers below where you&#= 8217;d be operating.

You might use draft-ietf-opsa= wg-service-model-explained as a reference.

 

Cheers,=

Jeff

From: Nets= lices <netslices-bounces@ietf.org= > on behalf of Xavier de Foy <x.defoy.ietf@gm= ail.com>
Date: Tuesday, January 30, 2018 at 15:44
To: "Kiran.Makhijani" <= Kiran.Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp<= /span>>, "NetSlices@ietf.org<= span lang=3D"EN-US" style=3D"font-size:12.0pt;color:black">" <NetSlices@ietf.org>, Carlos Jes=FAs Bern= ardos Cano <cjbc@it.uc3m.es>
Subject: Re: [Netslices] Preliminary charter text for discussion

 

 

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

Xavier,

This statement may need some ad= ditional clarity.

“Study the ma= ppings of technology independent network equipment configurations derived f= rom 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 r= elated capabilities and support. Am I correct?<= o:p>

If yes, then instead of use of = “study”, we could say something to the effect “Identify a= nd derive technology-independent network equipment configurations from the Information model in coordination with relevant WGs as neededR= 21;. This shows a clear deliverable.=

 

-Kiran<= /span>

From: Nets= lices <netslices-bounc= es@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=FAs Bernardos Cano <cjbc@it.uc3m.es>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>, "N= etSlices@ietf.org" <NetSlices@ietf.org> Subject: Re: [Netslices] Preliminary charter text for discussion

=  

= Xavier.


I. Context

A network slice is a set of related infrastructure resources and service fu= nctions with qualities that respond to specific requirements, being able to= cross multiple domains and use heterogeneous technologies. The goal of thi= s 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 o= f physical and logical connections in access= , aggregation and backbone networks as well as computing and storage elemen= ts. Service functions associated with a network slice include network funct= ions 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 e= xisting IETF technologies including both concluded and in-progress works su= ch as:
- Data plane: DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc.
- Controller and/or control plane: ACTN, PCE and RSVP-TE (requiring LDP, BG= P, OSPF awareness at level below) etc.
- Management plane: YANG, OAM etc.

The foundation of COMS is a technology-independent and resource-centric man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for specific domains. The goal of COMS is to d= efine a common and inter-operative management mechanism, which is essential= for the concept of network slicing being adopted in a system with heteroge= neous network infrastructures and services functions. Major characteristics include:
- Enabling composition of slices within a single or over multiple domains.<= br> - Allowing the operation and management of a network slice in a uniform man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 subnet= s. Network slices will be leased to tenants, which will be able to use Cust= omer Service Interface (CSI) exposed by the NS provider to run management tasks (e.g., on-demand measurement) w= ithin their slice instance under certain policies.

The WG will describe an information model representing a network slice, acc= ounting 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 interwork= ing.

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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces.
4 Slice composition or stitching in multi-domain environment.
5 Slice management by the tenant under the control of NSP, including deploy= ing 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 ma= y include abstractions of policy control and enforcement, or gateway functi= onalities. The WG will also study the mapping between the abstract information model and managed entities, a= nd will liaise with other IETF WGs as needed. However, the WG will not atte= mpt 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 document= s 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 describe= d above in the scope section.
- SDI and CSI interface specifications and relevant YANG models.
- Study the mappings of technology independent network equipment configurat= ions derived from the information model towards specific technologies and c= oordination with relevant WGs as needed.

IV. Milestones

Dec 2018     Problem Statement, use cases and architect= ure
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
             sl= ices including abstractions of policy control and
             en= forcement, or gateway functionalities.
March 2020   SDI and CSI interface specifications and relevant YA= NG models

 

_____________________________= __________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices

--_000_HE1PR0701MB271459213C062281074D54EDF0FA0HE1PR0701MB2714_-- From nobody Thu Feb 1 09:18:19 2018 Return-Path: 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 3810E12DA22 for ; Thu, 1 Feb 2018 09:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 g5a5Fxlq0Mzg for ; Thu, 1 Feb 2018 09:18:16 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255037.outbound.protection.outlook.com [40.92.255.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203B612DA6C for ; Thu, 1 Feb 2018 09:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uGiXZdBrN0mfmCYLWBWS1q+Uy7bBTrUMMVu9bHULJmQ=; b=hnGthz3mRKZettG24RCOMNJ13bzBFo0b/YDNb+3WDiRIKmAAe14s2Wcb8kG/8Val1xECyAUrxA0jOHIxFYt+M/mU1lJSKF9G/8i0Kj/HOcrwLWhQACDhQUK3ecizN2E/jXMuvm1Gi4KBU81WWEw37PHCevrrlyaRW+HPO166HgE8YgH/l8G1WL7RWaYY5YlqCtEpz9C9UXjaI1SnpqPULK51vTbbwb7I6jGC14ILQ3R8QZT1l2ekuSX+HIUC3dcbkqrPvrYmLGsR9StN/3xsi+2njfelpsXuT0zvhGgxQsnJIRTXllOMRfuVsAMO1+ueWaYlI5rExmJLCRtutglp3g== Received: from HK2APC01FT063.eop-APC01.prod.protection.outlook.com (10.152.248.57) by HK2APC01HT143.eop-APC01.prod.protection.outlook.com (10.152.249.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.13; Thu, 1 Feb 2018 17:18:12 +0000 Received: from PS1PR0601MB1483.apcprd06.prod.outlook.com (10.152.248.53) by HK2APC01FT063.mail.protection.outlook.com (10.152.249.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.444.13 via Frontend Transport; Thu, 1 Feb 2018 17:18:12 +0000 Received: from PS1PR0601MB1483.apcprd06.prod.outlook.com ([fe80::68cc:a0e7:d60f:f6a2]) by PS1PR0601MB1483.apcprd06.prod.outlook.com ([fe80::68cc:a0e7:d60f:f6a2%14]) with mapi id 15.20.0444.021; Thu, 1 Feb 2018 17:18:12 +0000 From: Liang GENG To: "netslices@ietf.org" Thread-Topic: New Version Notification for draft-qiang-coms-use-cases-00.txt Thread-Index: AdObf2YZ6XRVFtBpQyC1MAfN9H5HrwAALnFgAAAE0Cs= Date: Thu, 1 Feb 2018 17:18:12 +0000 Message-ID: References: <006201d39b80$2a97ffc0$7fc7ff40$@com> In-Reply-To: <006201d39b80$2a97ffc0$7fc7ff40$@com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:21581F18ACBD53729980C52FB839A4FE1FA015D62AF2A777B7A575689F3384DC; UpperCasedChecksum:65DB507FB8A2E16BD717DA3EC64C8C181AC6A29E56E9C76D389C18AB7E2B99B9; SizeAsReceived:7017; Count:45 x-tmn: [jBA0maCNA0aQjOMpRDqDoJdcd3OA4UT8sMQY9cNIW7Q=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK2APC01HT143; 6:JLY8CVTSuQsGM3eFiP6SBVHlOjifhpWIrbsadQLd1WyLYGbZq9fdPY0SHS246c67OtipynT1uL/KbcD/qh+9RqDiCG8sksFMG86U47x8rjA2Cte0NtqHlRKcNN2XLqyRepqIVCRNwAwIMsTvN3FEJkDFJeUYBH7N2OD3KOJgqkRW/L4uhgBHtxMrT/IIbY1qDrGENkQshXWI14bJU1puK+EVWICPAT5JMeX+6Vx+LfPebYudlXJOSwhUufUfhqjM2JNPYUy5TFpdsVfX+BpSdvXfi29WQhlKl/8jDOoS7/VJ29x/Yz5f7apV3CejRixXy0NIX6Odq6mDvTli1PPEkQ6oGQjUK585/oIkhHybA5Q=; 5:EG97jtpamD0rH4gEzm8lL5N9yxSoAQAFpFcR9W/DdEPse1OzzH9xjljXGdMdmEjLFXNBu4wnk1BY15j44BCd9JhFzoHIsgdK0XU0fS7LRrKlyFzE3VstCCg4IOxyBb6xWZ20ojeDPtTuQvclOGJ5vFXUpHfGUPbtr2zejXVq9EY=; 24:23qSAk7A/5Ea5jP8y46jfE/fxNgft0ypBFAwhZun1RNLYoURVioUWmvdu44EAAwDCWQuf5k7k8xAydxGbNhb8DFNCd5MYsDIUPrMvyNGnGI=; 7:KEtei1dX/axwkyneOHOIvKhUlW7eTTQlTh3NizMu7M7U94E8nJudC10y1+KyCT7HOKF1kZhytZ3uLTIaYuxcwgxgFs2D18CtYZ/YC3ZQguK9hlS4v4Q+J7ZWC02tdVHMalYyLDrWNnAznenHwcpCuRCQykUxq6ZxBo0m6GK8dAAcpwu7/eiy4xhVtk7OJ6TyOM9DtTgWjycGEQ/rHzVCbdLTuj9zoECr52GthqH8TwILAS46jRO70SjTQu++UBZd x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:HK2APC01HT143; x-ms-traffictypediagnostic: HK2APC01HT143: x-ms-office365-filtering-correlation-id: 792f3755-ae27-4cfc-cbdc-08d56997c5f7 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HK2APC01HT143; BCL:0; PCL:0; RULEID:; SRVR:HK2APC01HT143; x-forefront-prvs: 0570F1F193 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT143; H:PS1PR0601MB1483.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_PS1PR0601MB1483C5040DE6515A939F685687FA0PS1PR0601MB1483_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 792f3755-ae27-4cfc-cbdc-08d56997c5f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 17:18:12.4810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT143 Archived-At: Subject: [Netslices] New Version Notification for draft-qiang-coms-use-cases-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 17:18:18 -0000 --_000_PS1PR0601MB1483C5040DE6515A939F685687FA0PS1PR0601MB1483_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, A new use cases draft exclusively on the aspects of COMS is submitted by CO= MS proponents on https://datatracker.ietf.org/doc/draft-qiang-coms-use-cas= es/ Comments are extremely welcome. Many thanks! Best wishes Liang A new version of I-D, draft-qiang-coms-use-cases-00.txt has been successful= ly submitted by Liang Geng and posted to the IETF repository. Name: draft-qiang-coms-use-cases Revision: 00 Title: The Use Cases of Common Operation and Management of Network= Slicing Document date: 2018-02-02 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-qiang-coms-use-c= ases-00.txt Status: https://datatracker.ietf.org/doc/draft-qiang-coms-use-cases= / Htmlized: https://tools.ietf.org/html/draft-qiang-coms-use-cases-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-qiang-coms-use-= cases-00 Abstract: The Common Operation and Management of network Slicing (COMS) intends to provide a comprehensive approach for the overall operation and management of network slicing in the scope if IETF. The system is designed in a hierarchical and inter-operative manner. COMS is capable of recursive adaption in a hierarchical network management system. It is also independent of data plane technologies used in different administrative domains. Both network slice operator and network slice tenant may benefit for COMS for the purpose of slice management and maitenance.The purpose of this document is to discuss the use cases of COMS in different views. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_PS1PR0601MB1483C5040DE6515A939F685687FA0PS1PR0601MB1483_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Hi all,

A new use cases draft exclusively on the aspects o= f COMS is submitted by COMS proponents on  <= a href=3D"https://datatracker.ietf.org/doc/draft-qiang-coms-use-cases/" id= =3D"LPlnk788740" previewremoved=3D"true" style=3D"font-family: Calibri, Hel= vetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe U= I Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android E= moji", EmojiSymbols; font-size: 14.6667px;">https://datatracker.ietf.o= rg/doc/draft-qiang-coms-use-cases/

Comments are extremely welcome. Many thanks!

Best wishes
Liang

A new version of I-D, draft-qiang-coms-use-cases-00.txt has been successful= ly submitted by Liang Geng and posted to the IETF repository.

Name:           draft-qia= ng-coms-use-cases
Revision:       00
Title:          The Use Cases = of Common Operation and Management of Network Slicing
Document date:  2018-02-02
Group:          Individual Sub= mission
Pages:          12
URL:            https://www.ietf.org/internet-drafts/draft-qiang-coms-use-cases-00.txt<= br> Status:         https://datatracker.ietf.org/doc/draft-qiang-coms-use-cases/
Htmlized:       https://tools.ietf.org/html/draft-qiang-coms-use-cases-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-qiang-coms-use-cases-00


Abstract:
   The Common Operation and Management of network Slicing (COMS) = intends
   to provide a comprehensive approach for the overall operation = and
   management of network slicing in the scope if IETF.  The = system is
   designed in a hierarchical and inter-operative manner.  C= OMS is
   capable of recursive adaption in a hierarchical network manage= ment
   system.  It is also independent of data plane technologie= s used in
   different administrative domains.  Both network slice ope= rator and
   network slice tenant may benefit for COMS for the purpose of s= lice
   management and maitenance.The purpose of this document is to d= iscuss
   the use cases of COMS in different views.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--_000_PS1PR0601MB1483C5040DE6515A939F685687FA0PS1PR0601MB1483_-- From nobody Thu Feb 1 10:11:50 2018 Return-Path: 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 5A24512DA46 for ; Thu, 1 Feb 2018 10:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IhlgnZ64Fr2H for ; Thu, 1 Feb 2018 10:11:45 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 C9D5312EB7D for ; Thu, 1 Feb 2018 10:11:44 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id p188so20130923ioe.12 for ; Thu, 01 Feb 2018 10:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=sKywKHbiEDgIbumRp0FfYbeQ1RDzMEeQKUUetpDXyLQ=; b=oC/8wg0QlQD/ytTSylwwpAhC5PMOK81enNg1rBK9SUZ8A5o7Fe/oXrMHXEeACWwKHX gJfMO/yK/MCPBTj+BZBV3gXsZhAevWZxFy3mlbmcbUxWOAZd3EYR/adg6Yzs/UigrK43 M7xw+vD3Kqla+Rx1uDojxWSKVA3/82JULltAMHD7cmTyBHv6G/Ppwr/YVi3yVUr2K5AI C4nVYyC1nCE7phKMlT5Lreg2yjMARmWCF07z81RmmcQQKtV/7MDAC1CAGbgmIQ/QGdgU zB1QP/2HHRF8ONPPNm3Yck6cWgQjZMhkQQLaZ+KCXTwRgyW4mAZrZs7E6o9ob8QpRiIq HSGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=sKywKHbiEDgIbumRp0FfYbeQ1RDzMEeQKUUetpDXyLQ=; b=t1m/vZj+efkQiVoazti42Z6H6UfwDWWMVKLBY3S/RzRJ0iUOLYmDwUeBmjWB8d4AyX tPd7tPM3W5xbcPdnnH9hK5HwC/63n+6yHUB+QoymH5OC37MZOl5jh8DQ6MOsRmqro6b4 GJ03HBV51oDQgOLLfhJzC8Da0OoooI9gNbXakSNRGaF61Icrjr1SNxeJ5XmvbgYgc6Uj UdHHUJYyWYsKZmv4IGW1S0AmbCDP0POeRsL3gYiqRiv4SHlVeYA60QTu7xREmGfHGMrU orgC44wFMxPZ/Asl1YPhn/rmWroq5/Kbe9m6k8T3t9I0ju6o+iMgkfRvdQaORKD1qvxV a7ng== X-Gm-Message-State: AKwxytdTD0TjS9SsHV6w8H27jpjyW6RLEWbdgSq+BvxNwlCTyDya4THc dJmFCx/9wGvnafkg+mQfGpc= X-Google-Smtp-Source: AH8x225NZB4Ks7CKA25XpZ8J8aiX3TemCfRCeSDmbj8fnaHjV8xu2MGdVQ30CW3c9RMrSel2RNn+9A== X-Received: by 10.107.178.70 with SMTP id b67mr38616430iof.139.1517508704073; Thu, 01 Feb 2018 10:11:44 -0800 (PST) Received: from [128.203.211.142] ([128.203.211.142]) by smtp.gmail.com with ESMTPSA id m100sm72159iod.52.2018.02.01.10.11.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 10:11:43 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.9.0.180116 Date: Thu, 01 Feb 2018 13:11:35 -0500 From: Jeff Tantsura To: Daniele Ceccarelli , Leeyoung , Liang GENG , "qiangli (D)" , Xavier de Foy , "Kiran.Makhijani" CC: Pedro Martinez-Julia , "NetSlices@ietf.org" , Carlos =?UTF-8?B?SmVzw7pz?= Bernardos Cano Message-ID: <088B437B-E9AC-43FD-B911-6A077F5000E0@gmail.com> Thread-Topic: [Netslices] Preliminary charter text for discussion References: <1517163726.4051.23.camel@it.uc3m.es> <20180130043352.GB15400@spectre> <1517307927.3201.7.camel@it.uc3m.es> <49297C39-EF21-4D3E-898B-4728B61221BB@huawei.com> <06C389826B926F48A557D5DB5A54C4ED2A5F8047@dggemi509-mbx.china.huawei.com> <96DCDC2D-6F10-4C7E-A82E-3B868F55E23D@gmail.com> <7AEB3D6833318045B4AE71C2C87E8E173CF94DF4@sjceml521-mbs.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E173CF961AB@sjceml521-mbs.china.huawei.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3600335501_752849738" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:11:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3600335501_752849738 Content-type: multipart/alternative; boundary="B_3600335501_1713773691" --B_3600335501_1713773691 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi, =20 /IAB shepherd hat on =20 First of all =E2=80=93 thank you for continues work and improvements!=20 =20 Please keep the scope narrow and concise (aka don=E2=80=99t boil the ocean or eve= n a lake) There=E2=80=99s no need to address every technology by its name, someone will be = forgotten, someone be mentioned mistakenly =C2=A0(e.g. there=E2=80=99s no =E2=80=9CSR VPN=E2=80=99= s=E2=80=9D, neither SR data plane =E2=80=93 it is either MPLS or IPv6), control/data/man= agement planes would suffice.=20 =E2=80=9Cetc=E2=80=9D - doesn=E2=80=99t belong in a charter in any form. =E2=80=9C Please be precise in Deliverables: =20 =E2=80=9CStudy=E2=80=9D =E2=80=93 can=E2=80=99t be one, obliviously, it is part of the process, but= not the result I think, informational and corresponding data models would be a better desc= ription? =20 Thanks! =20 Cheers, Jeff From: Daniele Ceccarelli Date: Thursday, February 1, 2018 at 11:13 To: Leeyoung , Liang GENG , Je= ff Tantsura , "qiangli (D)" , = Xavier de Foy , "Kiran.Makhijani" Cc: Pedro Martinez-Julia , "NetSlices@ietf.org" , Carlos Jes=C3=BAs Bernardos Cano Subject: RE: [Netslices] Preliminary charter text for discussion =20 +1, =20 this is exactly my comment of some days ago.=20 =20 BR Daniele =20 =20 From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Leeyoung Sent: gioved=C3=AC 1 febbraio 2018 17:12 To: Liang GENG ; Jeff Tantsura ; qiangli (D) ; Xavier de Foy ; Kiran.Makhijani Cc: Pedro Martinez-Julia ; NetSlices@ietf.org; Carlos Jes= =C3=BAs Bernardos Cano Subject: Re: [Netslices] Preliminary charter text for discussion =20 Hi Liang, =20 Yes when I said SBI, I meant device configuration model. So I think there i= s no issue around this that COMS would not duplicate this model. =20 But I think you talked about the network configuration model to be generic.= Is this part of the scope of COMS? I heard COMS would focus on customer ser= vice model and service delivery model, correct? Then network configuration m= odel is not the scope of COMS? By the way generic network configuration mode= l has been one of the foci of MPI of ACTN work in TEAS WG.=20 =20 Thanks. Young =20 From: Liang GENG [mailto:liang.geng@hotmail.com]=20 Sent: Thursday, February 01, 2018 12:23 AM To: Leeyoung ; Jeff Tantsura = ; qiangli (D) ; Xavier de Foy ;= Kiran.Makhijani Cc: Pedro Martinez-Julia ; Carlos Jes=C3=BAs Bernardos Cano <= cjbc@it.uc3m.es>; NetSlices@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion =20 Hi Young, =20 I believe that our discussion has different reference points for SBI. =20 I might be wrong but I understand that by saying SBI you mean device config= uration model. At this point we are aligned, as Jeff and Xavier also pointed= out, that COMS will not duplicate these device model works. =20 Best wishes Liang =20 From: Leeyoung Sent: 01 February 2018 01:17:23 To: Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.Makhijani Cc: Pedro Martinez-Julia; Carlos Jes=C3=BAs Bernardos Cano; NetSlices@ietf.org Subject: RE: [Netslices] Preliminary charter text for discussion=20 =20 Hi Liang, =20 The SBI work in TEAS has IP/MPLS, Segment Routing, OTN, WDM (with CCAMP) in= scope. What is technology-independent, generic data plane on SBI? We cannot= really separate data plane technology from the model on SBI.=20 =20 Thanks. Young =20 From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Liang GENG Sent: Wednesday, January 31, 2018 9:54 AM To: Jeff Tantsura ; qiangli (D) ; Xavier de Foy ; Kiran.Makhijani Cc: Pedro Martinez-Julia ; Carlos Jes=C3=BAs Bernardos Cano <= cjbc@it.uc3m.es>; NetSlices@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion =20 Hi Jeff and all, =20 I think what COMS is dealing with in terms of SBI is more relevant to netwo= rk configuration models.=20 =20 Technology-dependent ones may be done in existing WGs (i.e. TEAS-ACTN) whil= st COMS may endeavor to examine generic ones. =20 Best wishes Liang =20 =20 From: Netslices on behalf of Jeff Tantsura Sent: 31 January 2018 22:48:09 To: qiangli (D); Xavier de Foy; Kiran.Makhijani Cc: Pedro Martinez-Julia; NetSlices@ietf.org; Carlos Jes=C3=BAs Bernardos Cano Subject: Re: [Netslices] Preliminary charter text for discussion=20 =20 Hi Christina, =20 My point =E2=80=93 you should never be dealing with device models directly, irres= pectively of where they were developed.=20 =20 Cheers, Jeff From: "qiangli (D)" Date: Wednesday, January 31, 2018 at 02:53 To: Jeff Tantsura , Xavier de Foy , "Kiran.Makhijani" Cc: Pedro Martinez-Julia , Carlos Jes=C3=BAs Bernardos Cano <= cjbc@it.uc3m.es>, "NetSlices@ietf.org" Subject: RE: [Netslices] Preliminary charter text for discussion =20 Hi Jeff, =20 I think we may understand this sentence from another perspective. As you sa= id, there are a number of network/device configuration models, and their ext= ension/mapping work is better to be done in corresponding WGs. For those tec= hnologies that are not chartered by relevant WGs, the mapping/extension work= could be done in COMS if needed. What do you think? =20 Best regards, Cristina QIANG =20 From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Jeff Tants= ura Sent: Wednesday, January 31, 2018 5:09 AM To: Xavier de Foy ; Kiran.Makhijani Cc: Pedro Martinez-Julia ; Carlos Jes=C3=BAs Bernardos Cano <= cjbc@it.uc3m.es>; NetSlices@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion =20 Hi, =20 I don=E2=80=99t think this is right thing to do, device models would be number of= layers below where you=E2=80=99d be operating. You might use draft-ietf-opsawg-service-model-explained as a reference. =20 Cheers, Jeff From: Netslices on behalf of Xavier de Foy Date: Tuesday, January 30, 2018 at 15:44 To: "Kiran.Makhijani" Cc: Pedro Martinez-Julia , "NetSlices@ietf.org" , Carlos Jes=C3=BAs Bernardos Cano Subject: Re: [Netslices] Preliminary charter text for discussion =20 Thanks Kiran, yes, I think one example is draft-homma-coms-slice-gateway, w= hich looks at the technology-independent requirements on some data plane equ= ipment. One interest of this is to help determine the appropriate abstractio= ns and attributes to use in the models. Your wording looks good but I guess we can wait a bit longer for other comm= ents (here on the list and during tomorrow's COMS proponents meeting). Best Regards, Xavier. =20 On Tue, Jan 30, 2018 at 1:45 PM, Kiran.Makhijani wrote: Xavier, This statement may need some additional clarity. =E2=80=9CStudy the mappings of technology independent network equipment configura= tions derived from the information model towards specific technologies and c= oordination with relevant WGs as needed.=E2=80=9D =20 I think what you are trying to say is that equipment configurations may nee= d some work to provide slices related capabilities and support. Am I correct= ? If yes, then instead of use of =E2=80=9Cstudy=E2=80=9D, we could say something to the e= ffect =E2=80=9CIdentify and derive technology-independent network equipment config= urations from the Information model in coordination with relevant WGs as nee= ded=E2=80=9D. This shows a clear deliverable. =20 -Kiran From: Netslices on behalf of Xavier de Foy Date: Tuesday, January 30, 2018 at 7:22 AM To: Carlos Jes=C3=BAs Bernardos Cano Cc: Pedro Martinez-Julia , "NetSlices@ietf.org" Subject: Re: [Netslices] Preliminary charter text for discussion =20 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 fu= nctions 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-centri= c management plane for network slices. Resources associated with a network s= lice are normally comprised of physical and logical connections in access, a= ggregation 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 infrastr= ucture elements. A "Network Slice" is realized using a collection of technologies spanning a= cross data, control and management planes. Many of them rely on existing IET= F 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, BG= P, OSPF awareness at level below) etc. - Management plane: YANG, OAM etc. The foundation of COMS is a technology-independent and resource-centric man= agement plane. In reality, the network slice provider may have diverse techn= ology choices in different domains due to geographical and commercial reason= s. Therefore, COMS makes no assumption on which technology is used for speci= fic domains. The goal of COMS is to define a common and inter-operative mana= gement mechanism, which is essential for the concept of network slicing bein= g adopted in a system with heterogeneous network infrastructures and service= s 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 man= ner, even when this network slice span multiple technology and/or administra= tive 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 provid= er (NSP) will need to communicate with a network slice orchestrator (NSO) ov= er a COMS Service Delivery Interface (SDI). The COMS SDI can also be used be= tween network slice orchestrators, enabling hierarchical management through = the notion of network slice subnets. Network slices will be leased to tenant= s, 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 th= eir slice instance under certain policies. The WG will describe an information model representing a network slice, acc= ounting for the key elements used in network slices: connectivity, compute, = storage resources, network and service functions =E2=80=94 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-l= evel 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, p= erformance, status information and performance guarantees for certain servic= es. 4 Slice composition or stitching in multi-domain environment. 5 Slice management by the tenant under the control of NSP, including deploy= ing 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 function= alities. 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 includ= ing DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc. III. Deliverables WG deliverables are listed below and may be split in any number of document= s 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 describe= d above in the scope section. - SDI and CSI interface specifications and relevant YANG models. - Study the mappings of technology independent network equipment configurat= ions derived from the information model towards specific technologies and co= ordination 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=20 slices including abstractions of policy control and=20 enforcement, or gateway functionalities. March 2020 SDI and CSI interface specifications and relevant YANG models=20 =20 _______________________________________________ Netslices mailing list Nets= lices@ietf.org https://www.ietf.org/mailman/listinfo/netslices=20 --B_3600335501_1713773691 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi,

 

/IAB shepherd hat on

 

First of all =E2=80=93 thank you for continues work and improvements!=

 

Please keep= the scope narrow and concise (aka don=E2=80=99t boil the ocean or even a lake)

There=E2=80=99s no need to address every technology by i= ts name, someone will be forgotten, someone be mentioned mistakenly =C2=A0(e.g. = there=E2=80=99s no =E2=80=9CSR VPN=E2=80=99s=E2=80=9D, neither SR data plane =E2=80=93 it is either MPLS o= r IPv6), control/data/management planes would suffice.

=E2=80=9Cetc=E2=80=9D - doesn=E2=80=99t belong in a charter in any form.

=E2=80=9C

Please be precise in Delivera= bles:

 

=E2=80=9CStud= y=E2=80=9D =E2=80=93 can=E2=80=99t 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!

&nbs= p;

Cheers,

Jeff

From: Daniele Cecca= relli <daniele.ceccarelli@ericsson.com>
Date: Thursday, Febr= uary 1, 2018 at 11:13
To: Leeyoung <leeyoung@huawei.com>, Li= ang GENG <liang.geng@hotmail.com>, Jeff Tantsura <jefftant.ietf@gma= il.com>, "qiangli (D)" <qiangli3@huawei.com>, Xavier de F= oy <x.defoy.ietf@gmail.com>, "Kiran.Makhijani" <Kiran.Mak= hijani@huawei.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.j= p>, "NetSlices@ietf.org" <NetSlices@ietf.org>, Carlos Jes= =C3=BAs Bernardos Cano <cjbc@it.uc3m.es>
Subject: RE: [Netslices= ] Preliminary charter text for discussion

 

=

+1,

 

this is exactly my = comment of some days ago.

 

BR
Daniele 

 

From:= Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Leeyoung<= br>Sent: gioved=C3=AC 1 febbraio 2018 17:12
To: Liang GENG <= liang.geng@hotmail.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; q= iangli (D) <qiangli3@huawei.com>; Xavier de Foy <x.defoy.ietf@gmail= .com>; Kiran.Makhijani <Kiran.Makhijani@huawei.com>
Cc: P= edro Martinez-Julia <pedro@nict.go.jp>; NetSlices@ietf.org; Carlos Jes= =C3=BAs Bernardos Cano <cjbc@it.uc3m.es>
Subject: Re: [Netslices= ] Preliminary charter text for discussion

=

 =

Hi Liang,

 

<= p class=3DMsoNormal>Yes when I = said SBI, I meant device configuration model. So I think there is no issue a= round this that COMS would not duplicate this model.

 = ;

But I think you talked about the network configuration m= odel to be generic. Is this part of the scope of COMS? I heard COMS would fo= cus on customer service model and service delivery model, correct? Then netw= ork configuration model is not the scope of COMS? By the way generic network= configuration model has been one of the foci of MPI of ACTN work in TEAS WG= .

 

<= span style=3D'mso-bookmark:_MailOriginalBody'>Thanks.

Youn= g

 

From: Liang GENG [mailto:liang.geng@hotmail.c= om]
Sent: Thursday, February 01, 2018 = 12:23 AM
To: Leeyoung <leeyoung@huawei.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; qiangli (D) <qiangli3@huawei.com>; Xavier de Foy <x.defoy.ietf@gmai= l.com<= span style=3D'mso-bookmark:_MailOriginalBody'>>; Kiran.Makhijani <Kir= an.Makhijani@huawei.com>
Cc: Pedro M= artinez-Julia <pedro@nict.go.jp>; Carl= os Jes=C3=BAs Bernardos Cano <= cjbc@it.uc3m.es&= gt;; NetSlices@ietf.org
Subject:= Re: [Netslices] Preliminary charter text for discussion

 

Hi Young,

 

I believe that our = discussion has different reference points for SBI.

 

I might be wrong but I understand tha= t by saying SBI you mean device configuration model. At this point we a= re aligned, as Jeff and Xavier also pointed out, that COMS will not duplicat= e these device model works.

 

Best wishes

Liang

 

From:= = Leeyoung <leeyoung@huawei.com>
Sent: 01 February 2018 01:17:23
To: Liang GENG;= Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.Makhijani
Cc: Pe= dro Martinez-Julia; Carlos Jes=C3=BAs Bernardos Cano; NetSlices@ietf.org<= /span>
Subject: RE: [Netslices] Pr= eliminary charter text for discussion

 

Hi Liang,

 

The SBI work in TEAS has IP/MPLS, Segment Routing, OTN, WDM (with CCAMP)= in scope. What is technology-independent, generic data plane on SBI? We can= not really separate data plane technology from the model on SBI.

 

Thanks.

Young

 

From: Netslices [mailto:netslices-bounces@ietf.or= g] On Behalf Of Liang GENG
Sent:= Wednesday, January 31, 2018 9:54 AM
To: Jeff Tantsura <= jefftant.ietf@gmail.com>; qiangli (D) <= ;qiangli3@huawei.com>; Xavier de Foy &= lt;x.defoy.ietf@gmail.com<= span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>>; Kiran.M= akhijani <Kiran.Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>; Carlos Jes=C3=BAs Bernardos Cano <= cjbc@it.uc3m= .es>; NetSlices@ietf.org<= span style=3D'mso-bookmark:_MailOriginalBody'>
Subject: Re: [Netslices] Preliminary charter text for= discussion

 

Hi Jeff and all,

 

I think what COMS is dealing with in terms of SBI is= more relevant to network configuration models. 

 

Technology-dependent ones may be done i= n existing WGs (i.e. TEAS-ACTN) whilst COMS may endeavor to examine gen= eric ones.

 

<= span style=3D'mso-bookmark:_MailOriginalBody'>Best w= ishes

Liang

 

 

From:<= span style=3D'mso-bookmark:_MailOriginalBody'> Netslices <ne= tslices-bounces@ietf.org> on behal= f of Jeff Tantsura <jefftant.ietf@gmail.com>
Sent: 31 January 2018 22:48:09
To:= qiangli (D); Xavier de Foy; Kiran.Makhijani
Cc: Pedro Martine= z-Julia; NetSlices@ietf.org; C= arlos Jes=C3=BAs Bernardos Cano
Subject: Re: [Netslices] Preliminary c= harter text for discussion

 

Hi Christina,

 

My point =E2=80=93 you sh= ould never be dealing with device models directly, irrespectively of where t= hey were developed.

 

Cheers,

Jeff

From: <= /b>"qiangli (D)" <qiangli3@huawei.com>
Date: Wedne= sday, January 31, 2018 at 02:53
To: Jeff Tantsura <jefftant.ietf@gmail.com>= , Xavier de Foy <x.= defoy.ietf@gmail.com>, "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>, Carlos Jes=C3=BAs Bernardos Cano &= lt;cjbc@it.uc3m.es>,= "NetSlices@ietf.org<= /span>" <NetSlices@= ietf.org>
Subject: RE: [Netslices] Preliminary charter te= xt for discussion

 

<= /div>

Hi Jeff,

 

I think we may understand this sentence from a= nother perspective. As you said, there are a number of network/device config= uration models, and their extension/mapping work is better to be done in cor= responding WGs. For those technologies that are not chartered by relevant WG= s, the mapping/extension work could be done in COMS if needed. What do you t= hink?

 <= /span>

Best regards,=

Cristina QIA= NG

 

From: Netslices [mailto= :netslices-bounces@ietf.org] On Behalf Of= Jeff Tantsura
Sent: Wednesday, January 31, 2018 5:09 AM
To: Xavier de Foy <x.defoy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Mak= hijani@huawei.com= >
Cc: Pedro Ma= rtinez-Julia <pedro@nict.go.jp&= gt;; Carlos Jes=C3=BAs Bernardos Cano <cjbc@it.uc3m.es>; NetSlices@ietf.org
Subject: Re: [Netslices] Preliminary charter text for d= iscussion

 

Hi,

=

 

I don=E2=80=99t think this is right thing to do, device models would be nu= mber of layers below where you=E2=80=99d be operating.

You might use dr= aft-ietf-opsawg-service-model-explained as a reference.

 

Cheers,

=

Jeff

From: Netslices <netslices-bounces@ietf.= org> on behalf of Xavier de Foy <x.defoy.ietf@gmail.com>
Date: Tues= day, January 30, 2018 at 15:44
To: "Kiran.Makhijani" <= ;Kiran.Makhijani@h= uawei.com<= /a>>
Cc: Pedro Martinez-Julia <= pedro@nict.go.jp>, "NetSlices@ietf.org" <NetSlices@ietf.org>= , Carlos Jes=C3=BAs Bernardos Cano <cjbc@it.uc3m.es>
Subject: Re: [Netslices] Prelimina= ry charter text for discussion

 

<= span style=3D'mso-bookmark:_MailOriginalBody'>Your wording looks good but I gu= ess 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 3= 0, 2018 at 1:45 PM, Kiran.Makhijani <= Kiran.Makhijani@huawei.com> wrote:

Xavier,

This statement may need some additional cla= rity.

=E2=80=9CStudy the mappings of technology independent n= etwork equipment configurations derived from the information model towards s= pecific technologies and coordination with relevant WGs as needed.=E2=80=9D=

 

I think what you are trying to say is that equipment conf= igurations may need some work to provide slices related capabilities and sup= port. Am I correct?

If yes, then instead of use of =E2=80=9Cstudy=E2=80=9D, we = could say something to the effect =E2=80=9CIdentify and derive technology-independ= ent network equipment configurations from the Information model in coordinat= ion with relevant WGs as needed=E2=80=9D. This shows a clear deliverable.

 

-Kiran=

From: Netslices <netslices-bounces@ietf.org= > on behalf of Xavier de Foy <x.defoy.ietf@gmail.com>
D= ate: Tuesday, January 30, 2018 at 7:22 AM
To: Carlos Jes=C3=BAs Be= rnardos Cano <cjbc@it.uc3m.es>
Cc: Pedro Martinez-Julia <= pedro@nict.go.jp>, "NetSlices@ietf.org" <<= span style=3D'font-size:12.0pt'>NetSlices@ietf.org>
Subject: Re: [Netslices] Preliminary charter text for discussion<= /span>

 

Xavier.


I. Context=

A network slice is a set of related infrastructure resources and ser= vice functions with qualities that respond to specific requirements, being a= ble to cross multiple domains and use heterogeneous technologies. The goal o= f this group is to produce and promote a technology-independent and resource= -centric management plane for network slices. Resources associated with a ne= twork slice are normally comprised of physical and logical connections in access, aggregation and backbone net= works as well as computing and storage elements. Service functions associate= d 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 technologi= es spanning across data, control and management planes. Many of them rely on= existing IETF technologies including both concluded and in-progress works s= uch as:
- Data plane: DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO= 3 etc.
- Controller and/or control plane: ACTN, PCE and RSVP-TE (requirin= g LDP, BGP, OSPF awareness at level below) etc.
- Management plane: YANG,= OAM etc.

The foundation of COMS is a technology-independent and reso= urce-centric management plane. In reality, the network slice provider may ha= ve diverse technology choices in different domains due to geographical and c= ommercial reasons. Therefore, COMS makes no assumption on which technology i= s used for specific domains. The goal of COMS is to define a common and inte= r-operative management mechanism, which is essential for the concept of netw= ork slicing being adopted in a system with heterogeneous network infrastruct= ures and services functions. Major characteristics include:
- Enabling co= mposition of slices within a single or over multiple domains.
- Allowing = the operation and management of a network slice in a uniform manner, even wh= en this network slice span multiple technology and/or administrative domains= .
- Enabling deployment of services over individual slices.

II. Sc= ope

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

The WG will desc= ribe an information model representing a network slice, accounting for the k= ey elements used in network slices: connectivity, compute, storage resources= , network and service functions =E2=80=94 this information model includes the repr= esentation of managed objects and corresponding management and operations, w= ill guide the design of data models on SDI and CSI and also will enable orch= estrators 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, inc= luding high-level parameters for network infrastructures and service functio= ns, together with their corresponding performance requirements.
2 Lifecyc= le management of network slice.
3 Other FCAPS functions. An important tas= k of NSP is to aggregate faults, performance, status information and perform= ance guarantees for certain services.
4 Slice composition or stitching in= multi-domain environment.
5 Slice management by the tenant under the con= trol of NSP, including deploying network services over a slice.

The W= G will specify requirements and functionalities of data plane entities as ne= eded to enable the management of network slices. For example, this may inclu= de abstractions of policy control and enforcement, or gateway functionalitie= s. The WG will also study the mapping between the abstract information model= and managed entities, and will liaise with other IETF WGs as needed. Howeve= r, the WG will not attempt to replicate data plane technologies including De= tNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc.

III. Delivera= bles

WG deliverables are listed below and may be split in any number = of documents as determined by the WG:
- Problem statement and use cases f= or management of network slices.
- Architecture of network slices.
- I= nformation model(s) and operations for network slices on topics described ab= ove in the scope section.
- SDI and CSI interface specifications and rele= vant 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. Miles= tones

Dec 2018     Problem Statement, use cases a= nd architecture
Dec 2018     Common information model= and related YANG model
June 2019    Network slices compos= ition and interworking
October 2019 FCAPS management functions and operat= ions on network
         &n= bsp;   slices including abstractions of policy control and
&nb= sp;            enforc= ement, or gateway functionalities.
March 2020   SDI and CSI int= erface specifications and relevant YANG models

<= /div>

<= span style=3D'mso-bookmark:_MailOriginalBody'> 

________= _______________________________________ Netslices mailing list N= etslices@ietf.org= https://www.ietf.org/mailman/listinfo/netslices

--B_3600335501_1713773691-- --B_3600335501_752849738 Content-type: image/png; name="image001.png"; x-mac-creator="4F50494D"; x-mac-type="504E4766" Content-ID: Content-disposition: inline; filename="image001.png" Content-transfer-encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA2kAAAAECAYAAAAUCne/AAAAAXNSR0IArs4c6QAAAAlwSFlz AAAOxAAADsQBlSsOGwAAAcRJREFUaAXtWlGygjAMbNFvLsCh3z384RgehHMUXrYlOi4jkZnH z3PjSFrTJG1JNqjN4zguS1pSJbBs77XbPnx/zTmnxbTBQd4GB0Xyh6+m3vzu+A/tVa/PC49/ SloL68720vp1/2tEKP6V/zv4w/jB+CL8a7VA+K/6h1yJ8kP13zbJaw42zNstfPDJC4X7+TJ6 u/8krs89ev7R85+ef9eEC/KP8yfKx0j+Kf5dh2EAmP7Y+86T+Ot+SSVd7AUO8jb4N5DWr/vv Ma/4V/57LAj/hP+qf/9/B1T/Vf8d81X/Vf89Fvbq/zzPt2vf9/UXr67rUimWRBf7EmX8E/Kx 4CDWZznb5PH1uxpcrzWbF8HjD9unCbA+26fhm26kz3I2sPGHdWv9uv+K/5oqyv/2g5aDOOPF YXwhAGJ9tk/DN91In+VsYONP+Cf8V/1T/VP9q1Cp+qf6V+aS8jRNb/5c55Ia9/n4oP+VDg6K 5OwhPD5kFt0HdL3t/tje2f1ofZGc56f1B8endP8fMY/YUfy3oyvKfz8/zohybj/Ct0jOsxP+ Cf/8yBBiw9vgoKPxVJVOvETzieQ8NcW/4t9jHrHhbcX/d+X/L7PHR5LQIiO9AAAAAElFTkSu QmCC --B_3600335501_752849738-- From nobody Thu Feb 1 14:24:51 2018 Return-Path: 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 ; 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 ; 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 ; Thu, 1 Feb 2018 14:24:46 -0800 (PST) Received: by mail-qt0-x241.google.com with SMTP id d54so28555904qtd.4 for ; 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: <1517163726.4051.23.camel@it.uc3m.es> <20180130043352.GB15400@spectre> <1517307927.3201.7.camel@it.uc3m.es> <49297C39-EF21-4D3E-898B-4728B61221BB@huawei.com> <06C389826B926F48A557D5DB5A54C4ED2A5F8047@dggemi509-mbx.china.huawei.com> <96DCDC2D-6F10-4C7E-A82E-3B868F55E23D@gmail.com> <7AEB3D6833318045B4AE71C2C87E8E173CF94DF4@sjceml521-mbs.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E173CF961AB@sjceml521-mbs.china.huawei.com> <088B437B-E9AC-43FD-B911-6A077F5000E0@gmail.com> From: Xavier de Foy Date: Thu, 1 Feb 2018 17:24:44 -0500 Message-ID: To: Jeff Tantsura Cc: Daniele Ceccarelli , Leeyoung , Liang GENG , "qiangli (D)" , "Kiran.Makhijani" , Pedro Martinez-Julia , "NetSlices@ietf.org" , =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= Content-Type: multipart/alternative; boundary="001a11c013261c07b905642e10e3" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 22:24:49 -0000 --001a11c013261c07b905642e10e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =E2=80=94 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 wrote: > Hi, > > > > /IAB shepherd hat on > > > > First of all =E2=80=93 thank you for continues work and improvements! > > > > Please keep the scope narrow and concise (aka don=E2=80=99t boil the ocea= n or even > a lake) > > There=E2=80=99s no need to address every technology by its name, someone = will be > forgotten, someone be mentioned mistakenly (e.g. there=E2=80=99s no =E2= =80=9CSR VPN=E2=80=99s=E2=80=9D, > neither SR data plane =E2=80=93 it is either MPLS or IPv6), control/data/= management > planes would suffice. > > =E2=80=9Cetc=E2=80=9D - doesn=E2=80=99t belong in a charter in any form. > > =E2=80=9C > > Please be precise in Deliverables: > > > > =E2=80=9CStudy=E2=80=9D =E2=80=93 can=E2=80=99t be one, obliviously, it i= s part of the process, but not > the result > > I think, informational and corresponding data models would be a better > description? > > > > Thanks! > > > > Cheers, > > Jeff > --001a11c013261c07b905642e10e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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, bu= t 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 domai= n or across multiple domains, and they may use heterogeneous technologies. = The goal of this group is to produce and promote a technology-independent a= nd resource-centric management plane for network slices. Resources associat= ed with a network slice are normally comprised of physical and logical conn= ections in access, aggregation and backbone networks as well as computing a= nd storage elements. Service functions associated with a network slice incl= ude network functions and network function chains pre-defined using corresp= onding network infrastructure elements.

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

The foundation of COMS is a technology-independent and res= ource-centric management plane. In reality, the network slice provider may = have diverse technology choices in different domains due to geographical an= d commercial reasons. Therefore, COMS makes no assumption on which technolo= gy 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 o= f network slicing being adopted in a system with heterogeneous network infr= astructures 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 m= anner, even when this network slice span multiple technology and/or adminis= trative domains.
- Enabling deployment of services over individual slice= s.

II. Scope

The WG will describe an overall architecture for= network slicing. To manage network slices in a technology-independent mann= er, the network slice provider (NSP) will need to communicate with a networ= k slice orchestrator (NSO) over a COMS Service Delivery Interface (SDI). Th= e COMS SDI can also be used between network slice orchestrators, enabling h= ierarchical management through the notion of network slice subnets. Network= slices will be leased to tenants, which will be able to use Customer Servi= ce 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 s= lice, accounting for the key elements used in network slices: connectivity,= compute, storage resources, network and service functions =E2=80=94 this i= nformation model includes the representation of managed objects and corresp= onding management and operations, will guide the design of data models on S= DI and CSI and also will enable orchestrators interworking.

The WG w= ill specify requirements, operations and management functionalities on netw= ork slicing interfaces SDI and/or CSI including:
1 Network slice service= profile, e.g. set by NSP over SDI, including high-level parameters for net= work infrastructures and service functions, together with their correspondi= ng 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 serv= ices.
4 Slice composition or stitching in multi-domain environment.
5= Slice management by the tenant under the control of NSP, including deployi= ng network services over a slice.

The WG will specify management req= uirements and functionalities of data plane entities as needed to enable th= e operation of network slices. For example, this may include abstractions o= f policy control and enforcement, or gateway functionalities. The WG will a= lso study the mapping between the abstract information model and managed en= tities, and will liaise with other IETF WGs as needed. However, the WG will= not attempt to replicate existing device models and data plane technologie= s.

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 sl= ices on topics described above in the scope section.
- SDI and CSI inter= face specifications and relevant YANG models.
- Specify management requi= rements 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 coord= ination with relevant WGs as needed.

IV. Milestones

Dec 2018= =C2=A0=C2=A0=C2=A0=C2=A0 Problem Statement, use cases and architecture
D= ec 2018=C2=A0=C2=A0=C2=A0=C2=A0 Common information model and related YANG m= odel
June 2019=C2=A0=C2=A0=C2=A0 Network slices composition and interwor= king
October 2019 FCAPS management functions and operations on network=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = slices including abstractions of policy control and
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enforcement, or gate= way functionalities.
March 2020=C2=A0=C2=A0 SDI and CSI interface specif= ications and relevant YANG models


<= div class=3D"gmail_extra">
On Thu, Feb 1, 201= 8 at 1:11 PM, Jeff Tantsura <jefftant.ietf@gmail.com> = wrote:

Hi,

=C2=A0

/IAB shepherd hat o= n

=C2=A0=

First of all =E2=80=93 thank you for continues wo= rk and improvements!

= =C2=A0

Please keep the scope narrow = and concise (aka don=E2=80=99t boil the ocean or even a lake)=

There=E2=80=99s no need to address every t= echnology by its name, someone will be forgotten, someone be mentioned mist= akenly =C2=A0(e.g. there=E2=80=99s no =E2=80=9CSR VPN=E2=80=99s=E2=80=9D, n= either SR data plane =E2=80=93 it is either MPLS or IPv6), control/data/man= agement planes would suffice.

=E2=80=9Cetc=E2=80=9D - doesn=E2=80=99t belong in a charter in any form.<= u>

=E2=80=9C

Please be precise in Deliverables:=

=C2=A0

=E2=80=9CStudy=E2=80=9D =E2=80=93 can=E2=80=99t be one, obliviou= sly, it is part of the process, but not the result

=

I think, informational and corresponding data models = would be a better description?

=C2=A0

Thanks!

=C2=A0

Cheers,

Jeff


--001a11c013261c07b905642e10e3-- From nobody Thu Feb 1 18:11:56 2018 Return-Path: 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 785F0126DEE for ; Thu, 1 Feb 2018 18:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cxHbxg6GLFAo for ; Thu, 1 Feb 2018 18:11:52 -0800 (PST) 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 C57E4126DC2 for ; Thu, 1 Feb 2018 18:11:51 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A52461AFD159F; Fri, 2 Feb 2018 02:11:28 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 2 Feb 2018 02:11:29 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML701-CHM.china.huawei.com ([169.254.3.93]) with mapi id 14.03.0382.000; Thu, 1 Feb 2018 18:11:16 -0800 From: Kiran.Makhijani To: Xavier de Foy , Jeff Tantsura CC: Daniele Ceccarelli , Leeyoung , Liang GENG , "qiangli (D)" , Pedro Martinez-Julia , "NetSlices@ietf.org" , =?Windows-1252?Q?Carlos_Jes=FAs_Bernardos_Cano?= Thread-Topic: [Netslices] Preliminary charter text for discussion Thread-Index: AQHTl5eHxJufwPsjxEmxm7smGTOn+6OKILoAgAGaPQCAAKMFAIAAYjuAgABSiAD//7MrgIAApyQAgAAHFYCAALPqgIAAc+WAgAASUACAABdigIAA24+AgACkbYCAAACaAIAAIOOAgABGuwD//7kuhw== Date: Fri, 2 Feb 2018 02:11:15 +0000 Message-ID: EE5B4EAE-6A87-4BF3-A96C-332A83144FBA References: <1517163726.4051.23.camel@it.uc3m.es> <20180130043352.GB15400@spectre> <1517307927.3201.7.camel@it.uc3m.es> <49297C39-EF21-4D3E-898B-4728B61221BB@huawei.com> <06C389826B926F48A557D5DB5A54C4ED2A5F8047@dggemi509-mbx.china.huawei.com> <96DCDC2D-6F10-4C7E-A82E-3B868F55E23D@gmail.com> <7AEB3D6833318045B4AE71C2C87E8E173CF94DF4@sjceml521-mbs.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E173CF961AB@sjceml521-mbs.china.huawei.com> <088B437B-E9AC-43FD-B911-6A077F5000E0@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EE5B4EAE6A874BF3A96C332A83144FBA_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 02:11:54 -0000 --_000_EE5B4EAE6A874BF3A96C332A83144FBA_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +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,NetSlices@ietf.org,Carlos Jes=FAs 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 (removi= ng the lists of technologies and the "study" entry). For the last deliverable I followed your suggestion to replace "study". Oth= ers may want to discuss/reword this later, but we need a version for the Bo= F 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 domai= n or across multiple domains, and they may use heterogeneous technologies. = The goal of this group is to produce and promote a technology-independent a= nd resource-centric management plane for network slices. Resources associat= ed with a network slice are normally comprised of physical and logical conn= ections in access, aggregation and backbone networks as well as computing a= nd storage elements. Service functions associated with a network slice incl= ude network functions and network function chains pre-defined using corresp= onding network infrastructure elements. A "Network Slice" is realized using a collection of technologies spanning a= cross data, control and management planes. Many of them rely on existing IE= TF technologies including both concluded and in-progress works in data, con= trol and management planes. The foundation of COMS is a technology-independent and resource-centric man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for sp= ecific 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 s= ervices 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 man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 thro= ugh the notion of network slice subnets. Network slices will be leased to t= enants, which will be able to use Customer Service Interface (CSI) exposed = by the NS provider to run management tasks (e.g., on-demand measurement) wi= thin their slice instance under certain policies. The WG will describe an information model representing a network slice, acc= ounting for the key elements used in network slices: connectivity, compute,= storage resources, network and service functions =97 this information mode= l includes the representation of managed objects and corresponding manageme= nt 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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces. 4 Slice composition or stitching in multi-domain environment. 5 Slice management by the tenant under the control of NSP, including deploy= ing network services over a slice. The WG will specify management requirements and functionalities of data pla= ne entities as needed to enable the operation of network slices. For exampl= e, this may include abstractions of policy control and enforcement, or gate= way functionalities. The WG will also study the mapping between the abstrac= t information model and managed entities, and will liaise with other IETF W= Gs 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 document= s 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 describe= d above in the scope section. - SDI and CSI interface specifications and relevant YANG models. - Specify management requirements and functionalities of data plane entitie= s 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 nee= ded. 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 > wrote: Hi, /IAB shepherd hat on First of all =96 thank you for continues work and improvements! Please keep the scope narrow and concise (aka don=92t boil the ocean or eve= n a lake) There=92s no need to address every technology by its name, someone will be = forgotten, someone be mentioned mistakenly (e.g. there=92s no =93SR VPN=92= s=94, neither SR data plane =96 it is either MPLS or IPv6), control/data/ma= nagement planes would suffice. =93etc=94 - doesn=92t belong in a charter in any form. =93 Please be precise in Deliverables: =93Study=94 =96 can=92t be one, obliviously, it is part of the process, but= not the result I think, informational and corresponding data models would be a better desc= ription? Thanks! Cheers, Jeff --_000_EE5B4EAE6A874BF3A96C332A83144FBA_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+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 identi= fied WGs).



--------------------------------------------------
Regards
Kiran
From:Xavier de Foy
To:Jeff Tantsura,
Cc:Daniele Ceccarelli,Leeyoung,L= iang GENG,qiangli (D),Kiran.Makhijani,Pedro Martinez-Julia,NetSlices@ietf.o= rg,Carlos Jes=FAs Bernardos Cano,
Date:2018-02-02 03:55:00
Subject:Re: [Netslices] Prelimin= ary charter text for discussion

Thanks Jeff, here is an updated text to address some of your points (r= emoving the lists of technologies and the "study" entry).
For the last deliverable I followed your suggestion to replace "s= tudy". Others may want to discuss/reword this later, but we need a ver= sion 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 domai= n or across multiple domains, and they may use heterogeneous technologies. The goal of this group is to prod= uce and promote a technology-independent and resource-centric management pl= ane for network slices. Resources associated with a network slice are norma= lly comprised of physical and logical connections in access, aggregation and backbone networks as well as comput= ing and storage elements. Service functions associated with a network slice= include network functions and network function chains pre-defined using co= rresponding 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 e= xisting 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 man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for specific domains. The goal of COMS is to d= efine a common and inter-operative management mechanism, which is essential= for the concept of network slicing being adopted in a system with heteroge= neous network infrastructures and services functions. Major characteristics include:

- Enabling composition of slices within a single or over multiple domains.<= br> - Allowing the operation and management of a network slice in a uniform man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 subnet= s. Network slices will be leased to tenants, which will be able to use Cust= omer Service Interface (CSI) exposed by the NS provider to run management tasks (e.g., on-demand measurement) w= ithin their slice instance under certain policies.

The WG will describe an information model representing a network slice, acc= ounting for the key elements used in network slices: connectivity, compute,= storage resources, network and service functions =97 this information mode= l 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 interwork= ing.

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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces.
4 Slice composition or stitching in multi-domain environment.
5 Slice management by the tenant under the control of NSP, including deploy= ing network services over a slice.

The WG will specify management requirements and functionalities of data pla= ne entities as needed to enable the operation of network slices. For exampl= e, this may include abstractions of policy control and enforcement, or gate= way 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 wi= ll not attempt to replicate existing device models and data plane technolog= ies.

III. Deliverables

WG deliverables are listed below and may be split in any number of document= s 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 describe= d above in the scope section.
- SDI and CSI interface specifications and relevant YANG models.
- Specify management requirements and functionalities of data plane entitie= s 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 nee= ded.

IV. Milestones

Dec 2018     Problem Statement, use cases and architect= ure
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
             sl= ices including abstractions of policy control and
             en= forcement, or gateway functionalities.
March 2020   SDI and CSI interface specifications and relevant YA= NG models



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

Hi,

 

/IAB shepherd hat on

 

First of all =96 thank you for continues work and im= provements!

 

Please keep the scope narrow and concise (aka don=92= t boil the ocean or even a lake)

There=92s no need to address every technology by its= name, someone will be forgotten, someone be mentioned mistakenly  (e.= g. there=92s no =93SR VPN=92s=94, neither SR data plane =96 it is either MPLS or IPv6), control/data/management planes would suffice. =

=93etc=94 - doesn=92t belong in a charter in any for= m.

=93

Please be precise in Deliverables:

 

=93Study=94 =96 can=92t be one, obliviously, it is p= art of the process, but not the result

I think, informational and corresponding data models= would be a better description?

 

Thanks!

 

Cheers,

Jeff


--_000_EE5B4EAE6A874BF3A96C332A83144FBA_-- From nobody Thu Feb 1 18:14:41 2018 Return-Path: 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 170AE12706D for ; Thu, 1 Feb 2018 18:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 OpPOpuDvhNJW for ; Thu, 1 Feb 2018 18:14:34 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001077.outbound.protection.outlook.com [40.92.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8632B12E88E for ; Thu, 1 Feb 2018 18:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hfBkFwGTdrVvx0vRH2xaDSgEA7lAJYdj4V5VOVJbUzE=; b=EeEKdxXazGEWDaYnCB3L5i2Tq/VkcsWkRViaaCg3wPsVE9gFfv689P/eSoIpNMqbhNzVz/QOBeJtHE4boGKZDDUUjb6yyeHAjaYugm7SfSkzr0FoG4YqyZUC9ucl85l6aMGmXx7Z7J3xFVIHLnbNXLgX0ocnNJOy4TWUkjYNiiJ4lU23+0Fkz7HqrjaoujfTkKjhB+RDSqvNZisuf9P8nC4p9nVzy5lKCfNiMhfWv1cPcTnY7EL08ylzFA3HbP6WXpIDbV6iT5b7LLGNV/OCj6CqVcwkGa1EYMcOxRlq99g2q2qGCcZqa29mtQFU0Qp8PcOWZfVtrAMMrLrW778u9Q== Received: from BN3NAM01FT006.eop-nam01.prod.protection.outlook.com (10.152.66.54) by BN3NAM01HT207.eop-nam01.prod.protection.outlook.com (10.152.67.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.444.13; Fri, 2 Feb 2018 02:14:33 +0000 Received: from BN6PR22MB0771.namprd22.prod.outlook.com (10.152.66.51) by BN3NAM01FT006.mail.protection.outlook.com (10.152.66.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.444.13 via Frontend Transport; Fri, 2 Feb 2018 02:14:33 +0000 Received: from BN6PR22MB0771.namprd22.prod.outlook.com ([10.171.180.14]) by BN6PR22MB0771.namprd22.prod.outlook.com ([10.171.180.14]) with mapi id 15.20.0444.021; Fri, 2 Feb 2018 02:14:33 +0000 From: Liang GENG To: Daniele Ceccarelli , Leeyoung , Jeff Tantsura , "qiangli (D)" , Xavier de Foy , Kiran.Makhijani CC: Pedro Martinez-Julia , "NetSlices@ietf.org" , =?Windows-1252?Q?Carlos_Jes=FAs_Bernardos_Cano?= Thread-Topic: [Netslices] Preliminary charter text for discussion Thread-Index: AQHTl5dwRK5lbxJtU0qysalSblgs0KOJmp4AgAGaPQCAAKMFAIAAYjuAgABSiACAADlLAIAAIQQAgAAHFYCAALPqgIAAc+WAgAAN1M2AABvegIAA2oTJgACleICAAACaAIAAnvBN Date: Fri, 2 Feb 2018 02:14:33 +0000 Message-ID: References: <1517163726.4051.23.camel@it.uc3m.es> <20180130043352.GB15400@spectre> <1517307927.3201.7.camel@it.uc3m.es> <49297C39-EF21-4D3E-898B-4728B61221BB@huawei.com> <06C389826B926F48A557D5DB5A54C4ED2A5F8047@dggemi509-mbx.china.huawei.com>, <96DCDC2D-6F10-4C7E-A82E-3B868F55E23D@gmail.com> , <7AEB3D6833318045B4AE71C2C87E8E173CF94DF4@sjceml521-mbs.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E173CF961AB@sjceml521-mbs.china.huawei.com>, In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:E2223C80CBE7774FD63E15E06C5BF9CEE718E30B5FEC721ECA0685883CA36B43; UpperCasedChecksum:1F6C2139B579D1F21870AD3D9F3F95A39D6352114C4289AFA226D081AC5417D9; SizeAsReceived:8470; Count:46 x-tmn: [nfzMrOO8dpUGT9bvJkoNyiwlxFM4Z6h/jee0yus2JQE=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT207; 6:/19hNkuxy8qhLK6fn1U/JZeWBqShzYHLqrrlWHcS0RNoRGGUthwzzNdu8FRwJ1Bpa5WrTR0IA7jBquFb6KfQBD5Ai9l5w1PSRKzO2KFE/CCb6HVAcWvGQFpDSLTuAvGLGqvc/6Ntw2jKIE79yqOCtBfkmFhSwrmimvMZKMrh3vo5RpzXn4sfIUrXuFthyxcp+3TwP93U550rd2nLYaWrWsv/B5UElqxeTNtX6QTDeO4qmFbpnLH/divCUPL3L5UcHhuSKEA8vu0VjcX9B5mI1+98a9/wpbwpQ9vYHP1eC0EPpKN6ps6LWtsAK8fhItJkx46Ocg5M4AHLBW3SCQPTeY3EosFxG7bhbxeXKSOebh4=; 5:o+RIjxIrftOy3DiTGoLZYvkiN4zAWIlBvwXx0x9CaY3iDkOSAM9Qa9vo09NSOlFVdgXy3VIIf4/P5LvbeIFIEgo77pmAlVpEii7crvPVl2oToqV66Juay23SW+QYq6tZHr8CY5GzgBB0MENjGxSvDEiolEL92Rbq/n83n13W6r0=; 24:okaanC6sNkyXGBw0tbVW24eYpJeUb3iA1/rgPNrHq5/WuyT7edSHbMwBqVKhFxneAu4PUwhobG8JA2nRsbeQXspSLf8p9+IvV7u0X28aXz4=; 7:evHH5tndAtxFYRjpHAduJz468Ovi39yJDr087kcJ2ZC9F5cChIjJt7hXEPX+upz7FjPTsFrMn8BCHp1N/CZLhyKxiSsVx0ykhilAWYLP7R9b8sz6/H648LhWGtgi4wSUKp1Ck2ZfjyRC+EgkeUDF5YwvGIqYKaVJ/kqVnv9DSp0VnY+sTRSz9kz71MjIzzm5uCw4CDrQ9A29AANY6ubKqoOXvlL3hb85cIdxCgB6u0s//sUhxj35620NE3Ht0ZF8 x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:BN3NAM01HT207; x-ms-traffictypediagnostic: BN3NAM01HT207: x-ms-office365-filtering-correlation-id: c77e28ad-b02c-4fa5-0941-08d569e2b33f x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BN3NAM01HT207; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT207; x-forefront-prvs: 05715BE7FD x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT207; H:BN6PR22MB0771.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR22MB077141239076CEB54C0C685687F90BN6PR22MB0771namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: c77e28ad-b02c-4fa5-0941-08d569e2b33f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2018 02:14:33.3102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT207 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 02:14:39 -0000 --_000_BN6PR22MB077141239076CEB54C0C685687F90BN6PR22MB0771namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Young and Daniele, Thanks for your comments. This is a extremely good topic to discuss which could help COMS to have mor= e clearer and concise problem space In COMS, we endeavor to avoid any duplicated work also on network configura= tion model. We also encourage this been done preferably in individual exist= ing WGs, in which the underlay dataplane is willing to be considered as res= ource components of a network slice. The generic network configuration model was discussed under an assumption t= hat there is a need to coordinate independent administrative domains. We le= ave an open space for such domains to either use specific models (likely to= be defined within the domain and can be used solely without the awareness = of network slice. i.e. ACTN MPI),, or use the generic ones provided by COMS= (likely to be general and simple exclusively designed for mapping of slice= -level requirements to network configurations, and only serve for COMS-enab= led systems). This thought was base on the concerns similar to ETSI VNFM architecture whi= ch can be find here http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/009= /01.01.01_60/gs_NFV-IFA009v010101p.pdf. VNFM can be seen as a orchestrator = for services and it shares many design methodology with the network slice o= rchestrator in COMS. The vendor-specific VNFMs are more flexible, where the generic VNFM provide= compulsory functionalities. It may be beneficial for COMS to look at gener= ic models for most basic OAMs for the use at the convenience of individual = administrative domains. But personal I use "may" in the context since this could be a open topic fo= r future study and discussion as COMS proceeds. Best wishes Liang ________________________________ From: Daniele Ceccarelli Sent: 02 February 2018 00:13:52 To: Leeyoung; Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.= Makhijani Cc: Pedro Martinez-Julia; NetSlices@ietf.org; Carlos Jes=FAs Bernardos Cano Subject: RE: [Netslices] Preliminary charter text for discussion +1, this is exactly my comment of some days ago. BR Daniele From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Leeyoung Sent: gioved=EC 1 febbraio 2018 17:12 To: Liang GENG ; Jeff Tantsura ; qiangli (D) ; Xavier de Foy ; Kiran.Makhijani Cc: Pedro Martinez-Julia ; NetSlices@ietf.org; Carlos Jes= =FAs Bernardos Cano Subject: Re: [Netslices] Preliminary charter text for discussion Hi Liang, Yes when I said SBI, I meant device configuration model. So I think there i= s no issue around this that COMS would not duplicate this model. But I think you talked about the network configuration model to be generic.= Is this part of the scope of COMS? I heard COMS would focus on customer se= rvice model and service delivery model, correct? Then network configuration= model is not the scope of COMS? By the way generic network configuration m= odel has been one of the foci of MPI of ACTN work in TEAS WG. Thanks. Young From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Thursday, February 01, 2018 12:23 AM To: Leeyoung >; Jeff Tantsu= ra >; qiangli (D) <= qiangli3@huawei.com>; Xavier de Foy >; Kiran.Makhijani > Cc: Pedro Martinez-Julia >; Carlo= s Jes=FAs Bernardos Cano >; NetSlic= es@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion Hi Young, I believe that our discussion has different reference points for SBI. I might be wrong but I understand that by saying SBI you mean device config= uration model. At this point we are aligned, as Jeff and Xavier also pointe= d out, that COMS will not duplicate these device model works. Best wishes Liang ________________________________ From: Leeyoung > Sent: 01 February 2018 01:17:23 To: Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.Makhijani Cc: Pedro Martinez-Julia; Carlos Jes=FAs Bernardos Cano; NetSlices@ietf.org= Subject: RE: [Netslices] Preliminary charter text for discussion Hi Liang, The SBI work in TEAS has IP/MPLS, Segment Routing, OTN, WDM (with CCAMP) in= scope. What is technology-independent, generic data plane on SBI? We canno= t really separate data plane technology from the model on SBI. Thanks. Young From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Liang GENG Sent: Wednesday, January 31, 2018 9:54 AM To: Jeff Tantsura >= ; qiangli (D) >; Xavier de = Foy >; Kiran.Makhijan= i > Cc: Pedro Martinez-Julia >; Carlo= s Jes=FAs Bernardos Cano >; NetSlic= es@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion Hi Jeff and all, I think what COMS is dealing with in terms of SBI is more relevant to netwo= rk configuration models. Technology-dependent ones may be done in existing WGs (i.e. TEAS-ACTN) whil= st COMS may endeavor to examine generic ones. Best wishes Liang ________________________________ From: Netslices > on behalf of Jeff Tantsura > Sent: 31 January 2018 22:48:09 To: qiangli (D); Xavier de Foy; Kiran.Makhijani Cc: Pedro Martinez-Julia; NetSlices@ietf.org; Ca= rlos Jes=FAs Bernardos Cano Subject: Re: [Netslices] Preliminary charter text for discussion Hi Christina, My point =96 you should never be dealing with device models directly, irres= pectively of where they were developed. Cheers, Jeff From: "qiangli (D)" > Date: Wednesday, January 31, 2018 at 02:53 To: Jeff Tantsura >= , Xavier de Foy >, "K= iran.Makhijani" > Cc: Pedro Martinez-Julia >, Carlo= s Jes=FAs Bernardos Cano >, "NetSli= ces@ietf.org" > Subject: RE: [Netslices] Preliminary charter text for discussion Hi Jeff, I think we may understand this sentence from another perspective. As you sa= id, there are a number of network/device configuration models, and their ex= tension/mapping work is better to be done in corresponding WGs. For those t= echnologies that are not chartered by relevant WGs, the mapping/extension w= ork could be done in COMS if needed. What do you think? Best regards, Cristina QIANG From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Jeff Tants= ura Sent: Wednesday, January 31, 2018 5:09 AM To: Xavier de Foy >; = Kiran.Makhijani > Cc: Pedro Martinez-Julia >; Carlo= s Jes=FAs Bernardos Cano >; NetSlic= es@ietf.org Subject: Re: [Netslices] Preliminary charter text for discussion Hi, I don=92t think this is right thing to do, device models would be number of= layers below where you=92d be operating. You might use draft-ietf-opsawg-service-model-explained as a reference. Cheers, Jeff From: Netslices > on behalf of Xavier de Foy > Date: Tuesday, January 30, 2018 at 15:44 To: "Kiran.Makhijani" > Cc: Pedro Martinez-Julia >, "NetS= lices@ietf.org" >, Carlos Jes=FAs Bernardos Cano > Subject: Re: [Netslices] Preliminary charter text for discussion Thanks Kiran, yes, I think one example is draft-homma-coms-slice-gateway, w= hich looks at the technology-independent requirements on some data plane eq= uipment. One interest of this is to help determine the appropriate abstract= ions and attributes to use in the models. Your wording looks good but I guess we can wait a bit longer for other comm= ents (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 > wrote: Xavier, This statement may need some additional clarity. =93Study the mappings of technology independent network equipment configura= tions derived from the information model towards specific technologies and = coordination with relevant WGs as needed.=94 I think what you are trying to say is that equipment configurations may nee= d some work to provide slices related capabilities and support. Am I correc= t? If yes, then instead of use of =93study=94, we could say something to the e= ffect =93Identify and derive technology-independent network equipment confi= gurations from the Information model in coordination with relevant WGs as n= eeded=94. This shows a clear deliverable. -Kiran From: Netslices > on behalf of Xavier de Foy > Date: Tuesday, January 30, 2018 at 7:22 AM To: Carlos Jes=FAs Bernardos Cano > Cc: Pedro Martinez-Julia >, "NetS= lices@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 fu= nctions with qualities that respond to specific requirements, being able to= cross multiple domains and use heterogeneous technologies. The goal of thi= s group is to produce and promote a technology-independent and resource-cen= tric management plane for network slices. Resources associated with a netwo= rk slice are normally comprised of physical and logical connections in acce= ss, aggregation and backbone networks as well as computing and storage elem= ents. Service functions associated with a network slice include network fun= ctions and network function chains pre-defined using corresponding network = infrastructure elements. A "Network Slice" is realized using a collection of technologies spanning a= cross data, control and management planes. Many of them rely on existing IE= TF 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, BG= P, OSPF awareness at level below) etc. - Management plane: YANG, OAM etc. The foundation of COMS is a technology-independent and resource-centric man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for sp= ecific 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 s= ervices 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 man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 thro= ugh the notion of network slice subnets. Network slices will be leased to t= enants, which will be able to use Customer Service Interface (CSI) exposed = by the NS provider to run management tasks (e.g., on-demand measurement) wi= thin their slice instance under certain policies. The WG will describe an information model representing a network slice, acc= ounting for the key elements used in network slices: connectivity, compute,= storage resources, network and service functions =97 this information mode= l includes the representation of managed objects and corresponding manageme= nt 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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces. 4 Slice composition or stitching in multi-domain environment. 5 Slice management by the tenant under the control of NSP, including deploy= ing 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 ma= y include abstractions of policy control and enforcement, or gateway functi= onalities. The WG will also study the mapping between the abstract informat= ion model and managed entities, and will liaise with other IETF WGs as need= ed. However, the WG will not attempt to replicate data plane technologies i= ncluding DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc. III. Deliverables WG deliverables are listed below and may be split in any number of document= s 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 describe= d above in the scope section. - SDI and CSI interface specifications and relevant YANG models. - Study the mappings of technology independent network equipment configurat= ions derived from the information model towards specific technologies and c= oordination 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 _______________________________________________ Netslices mailing list Nets= lices@ietf.org https://www.ietf.org/mailman/list= info/netslices --_000_BN6PR22MB077141239076CEB54C0C685687F90BN6PR22MB0771namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Young and Daniele,


Thanks for your comments. 


This is a extremely good topic to= discuss which could help COMS to have more clearer and concise problem spa= ce


In COMS, we endeavor to avoid any= duplicated work also on network configuration model. We also encourag= e this been done preferably in individual existing WGs, in which the u= nderlay dataplane is willing to be considered as resource components of a network slice.


The generic network configuration= model was discussed under an assumption that there is a need to coordinate= independent administrative domains. We leave an open space for such domain= s to either use specific models (likely to be defined within the domain and can be used solely without the awarene= ss of network slice. i.e. ACTN MPI),, or use the generic ones provided by C= OMS (likely to be general and simple exclusively designed for mapping of sl= ice-level requirements to network configurations, and only serve for COMS-enabled systems). 


This thought was base on the conc= erns similar to ETSI VNFM architecture which can be find here http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/009/01.01= .01_60/gs_NFV-IFA009v010101p.pdf. VNFM can be seen as a orchestrator for services and it shares many design = methodology with the network slice orchestrator in COMS.

The vendor-specific VNFMs are more flexible, where the generic VNFM pr= ovide compulsory functionalities. It may be beneficial for COMS to look at = generic models for most basic OAMs for the use at the convenience of indivi= dual administrative domains.

But personal I use "may" in the context since this could be = a open topic for future study and discussion as COMS proceeds.

Best wishes
Liang




From: Daniele Ceccarelli &l= t;daniele.ceccarelli@ericsson.com>
Sent: 02 February 2018 00:13:52
To: Leeyoung; Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy;= Kiran.Makhijani
Cc: Pedro Martinez-Julia; NetSlices@ietf.org; Carlos Jes=FAs Bernard= os Cano
Subject: RE: [Netslices] Preliminary charter text for discussion
 

+1,

 

this is exactly my comment of som= e days ago.

 

BR
Daniele 

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Leeyoung
Sent: gioved=EC 1 febbraio 2018 17:12
To: Liang GENG <liang.geng@hotmail.com>; Jeff Tantsura <jef= ftant.ietf@gmail.com>; qiangli (D) <qiangli3@huawei.com>; Xavier d= e Foy <x.defoy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Makhijani@h= uawei.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp>; NetSlices@ietf.or= g; Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi Liang,

 

Yes when I said SB= I, I meant device configuration model. So I think there is no issue around = this that COMS would not duplicate this model.<= /span>

 

But I think you ta= lked about the network configuration model to be generic. Is this part of t= he scope of COMS? I heard COMS would focus on customer service model and service delivery model, correct? Then network configurat= ion model is not the scope of COMS? By the way generic network configuratio= n model has been one of the foci of MPI of ACTN work in TEAS WG.

 

Thanks.

Young

 

From: Liang GENG [mailto:liang.geng= @hotmail.com]
Sent: Thursday, February 01, 2018 12:23 AM
To: Leeyoung <leeyoung@hua= wei.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; qiangli (D) <qiangli3@huawei.com>; Xavier de Foy <x.defoy.ietf@gmail.com&g= t;; Kiran.Makhijani <Kiran= .Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>; Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>; NetSlices@ietf.org
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi Young,

 

I believe that our discussion has different reference p= oints for SBI.

 

I might be wrong but I understand that by saying SBI yo= u mean device configuration model. At this point we are aligned, as Jeff an= d Xavier also pointed out, that COMS will not duplicate these device model works.

 

Best wishes

Liang

 

From:<= span lang=3D"EN-US" style=3D"font-size:11.0pt; font-family:"Calibri&qu= ot;,sans-serif; color:black"> Leeyoung <leeyoung@huawei.com>
Sent: 01 February 2018 01:17:23
To: Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.Mak= hijani
Cc: Pedro Martinez-Julia; Carlos Jes=FAs Bernardos Cano; NetSlices@ietf.org
Subject: RE: [Netslices] Preliminary charter text for discussion

 

Hi Liang,<= span lang=3D"EN-US">

 

The SBI work in T= EAS has IP/MPLS, Segment Routing, OTN, WDM (with CCAMP) in scope. What is t= echnology-independent, generic data plane on SBI? We cannot really separate data plane technology from the model on SBI.

 

Thanks.

Young

 

From: Netslices [mailto:netsli= ces-bounces@ietf.org] On Behalf Of Liang GENG
Sent: Wednesday, January 31, 2018 9:54 AM
To: Jeff Tantsura <jef= ftant.ietf@gmail.com>; qiangli (D) <qiangli3@huawei.com>; Xavier de Foy <x.defoy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Ma= khijani@huawei.com>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>; Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>; NetSlices@ietf.org
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi Jeff and all,

 

I think what COMS is dealing with in terms of SBI is more re= levant to network configuration models. 

 

Technology-dependent ones may be done in existing WGs (= i.e. TEAS-ACTN) whilst COMS may endeavor to examine generic ones.

 

Best wishes

Liang

 

 

From:= Netslices <netslices-bounces@ietf.org> on behalf of Jeff Tantsura <= jefftant.ietf@gmail.com>
Sent: 31 January 2018 22:48:09
To: qiangli (D); Xavier de Foy; Kiran.Makhijani
Cc: Pedro Martinez-Julia; NetS= lices@ietf.org; Carlos Jes=FAs Bernardos Cano
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi Christina,

 

My point =96 you should nev= er be dealing with device models directly, irrespectively of where they wer= e developed.

 

Cheer= s,

Jeff<= /span>

From: &qu= ot;qiangli (D)" <qiangli3@hu= awei.com>
Date: Wednesday, January 31, 2018 at 02:53
To: Jeff Tantsura <jef= ftant.ietf@gmail.com>, Xavier de Foy <x.defoy.ietf@gmail.com>, "Kiran.Makhijani" = <Kiran.Makhijani@huawei.co= m>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>, Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>, "NetSlices@ietf.org" <NetSlices@ietf.org>
Subject: RE: [Netslices] Preliminary charter text for discussion

 

Hi Jeff,

 

I think we may understand this sentence from another perspec= tive. As you said, there are a number of network/device configuration model= s, and their extension/mapping work is better to be done in corresponding WGs. For those technologies that are no= t chartered by relevant WGs, the mapping/extension work could be done in CO= MS if needed. What do you think?

 

Best regards,

Cristina QIANG

 

From: Netslices [mail= to:netslices-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, January 31, 2018 5:09 AM
To: Xavier de Foy <x.de= foy.ietf@gmail.com>; Kiran.Makhijani <Kiran.Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <ped= ro@nict.go.jp>; Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>; NetSlices@ietf.org
Subject: Re: [Netslices] Preliminary charter text for discussion

 

Hi,

 

I don=92t think this is rig= ht thing to do, device models would be number of layers below where you=92d= be operating.

You might use draft-ietf-op= sawg-service-model-explained as a reference.

 

Cheer= s,

Jeff<= /span>

From: Net= slices <netslices-bounces@ietf.org&g= t; on behalf of Xavier de Foy <x.defoy.ietf@gm= ail.com>
Date: Tuesday, January 30, 2018 at 15:44
To: "Kiran.Makhijani" <= Kiran.Makhijani@huawei.com>
Cc: Pedro Martinez-Julia <pedro@nict.go.jp<= /span>>, "NetSlices@ietf.org= " <NetSlices@ietf.org>, Carlos Jes=FAs Ber= nardos Cano <cjbc@it.uc3m.es>
Subject: Re: [Netslices] Preliminary charter text for discussion

 

 

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

Xavier,

This statement may need some= additional clarity.

=93Study the ma= ppings of technology independent network equipment configurations derived f= rom the information model towards specific technologies and coordination with relevant WGs as needed.=94

 

I think what you are trying = to say is that equipment configurations may need some work to provide slice= s related capabilities and support. Am I correct?

If yes, then instead of use = of =93study=94, we could say something to the effect =93Identify and derive= technology-independent network equipment configurations from the Information model in coordination with relevant WGs as needed=94.= This shows a clear deliverable.

 

-Kira= n

From: Net= slices <netslices-boun= ces@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=FAs 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

 

Xavier.


I. Context

A network slice is a set of related infrastructure resources and service fu= nctions with qualities that respond to specific requirements, being able to= cross multiple domains and use heterogeneous technologies. The goal of thi= s 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 o= f physical and logical connections in acce= ss, aggregation and backbone networks as well as computing and storage elem= ents. Service functions associated with a network slice include network fun= ctions 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 e= xisting IETF technologies including both concluded and in-progress works su= ch as:
- Data plane: DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc.
- Controller and/or control plane: ACTN, PCE and RSVP-TE (requiring LDP, BG= P, OSPF awareness at level below) etc.
- Management plane: YANG, OAM etc.

The foundation of COMS is a technology-independent and resource-centric man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for specific domains. The goal of COMS is to d= efine a common and inter-operative management mechanism, which is essential= for the concept of network slicing being adopted in a system with heteroge= neous network infrastructures and services functions. Major characteristics include:
- Enabling composition of slices within a single or over multiple domains.<= br> - Allowing the operation and management of a network slice in a uniform man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 subnet= s. Network slices will be leased to tenants, which will be able to use Cust= omer Service Interface (CSI) exposed by the NS provider to run management tasks (e.g., on-demand measurement) w= ithin their slice instance under certain policies.

The WG will describe an information model representing a network slice, acc= ounting for the key elements used in network slices: connectivity, compute,= storage resources, network and service functions =97 this information mode= l 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 interwork= ing.

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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces.
4 Slice composition or stitching in multi-domain environment.
5 Slice management by the tenant under the control of NSP, including deploy= ing 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 ma= y include abstractions of policy control and enforcement, or gateway functi= onalities. The WG will also study the mapping between the abstract information model and managed entities, a= nd will liaise with other IETF WGs as needed. However, the WG will not atte= mpt 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 document= s 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 describe= d above in the scope section.
- SDI and CSI interface specifications and relevant YANG models.
- Study the mappings of technology independent network equipment configurat= ions derived from the information model towards specific technologies and c= oordination with relevant WGs as needed.

IV. Milestones

Dec 2018     Problem Statement, use cases and architect= ure
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
             sl= ices including abstractions of policy control and
             en= forcement, or gateway functionalities.
March 2020   SDI and CSI interface specifications and relevant YA= NG models

 

___________________________= ____________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices

--_000_BN6PR22MB077141239076CEB54C0C685687F90BN6PR22MB0771namp_-- From nobody Thu Feb 1 18:27:23 2018 Return-Path: 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 001B01201FA for ; Thu, 1 Feb 2018 18:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 gw4Ba8IxAqaY for ; Thu, 1 Feb 2018 18:27:17 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03olkn081c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::81c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06932126CB6 for ; Thu, 1 Feb 2018 18:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UaICogcmnL94Rn6tIBbjh6YELKgypIaHVYxw9YAIjf8=; b=QwOUBitpp9JaDOoownlMweUZ94NzlzfFRtI4gPpN5LCHDgVpgvYGqM+tcTWZ5Ari5Be1e/r3VhguaAFQbztebqtPuW8WA1MMnF4yXyx56jzQ3PISFuWMl5v07Nzovqa/S2wKcvz5jQ+rfMxo1/YT2v5nvFMbEizHPagZz6KSpTNZj0bgt3nKD9qnZcGyK9uumObtbPHsTAdG7Wv2JOCd0WI2d740/v+FuOcemCanaLJH/aJwR29ISi2pFajMmMAZuxf1HlcG2ZKB6DlZjCEtBoac9J+pKWKsc+OoLoPBN4crZipsrzWRjijRnfnoTHc62Sh3NOmfayK/DFolOFT2Ug== Received: from CO1NAM03FT058.eop-NAM03.prod.protection.outlook.com (10.152.80.60) by CO1NAM03HT145.eop-NAM03.prod.protection.outlook.com (10.152.81.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.464.13; Fri, 2 Feb 2018 02:27:13 +0000 Received: from BN6PR22MB0771.namprd22.prod.outlook.com (10.152.80.54) by CO1NAM03FT058.mail.protection.outlook.com (10.152.81.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.464.13 via Frontend Transport; Fri, 2 Feb 2018 02:27:13 +0000 Received: from BN6PR22MB0771.namprd22.prod.outlook.com ([10.171.180.14]) by BN6PR22MB0771.namprd22.prod.outlook.com ([10.171.180.14]) with mapi id 15.20.0444.021; Fri, 2 Feb 2018 02:27:12 +0000 From: Liang GENG To: Xavier de Foy , Jeff Tantsura CC: Daniele Ceccarelli , Leeyoung , "qiangli (D)" , Kiran.Makhijani , Pedro Martinez-Julia , "netslices@ietf.org" , =?Windows-1252?Q?Carlos_Jes=FAs_Bernardos_Cano?= Thread-Topic: [Netslices] Preliminary charter text for discussion Thread-Index: AQHTl5dwRK5lbxJtU0qysalSblgs0KOJmp4AgAGaPQCAAKMFAIAAYjuAgABSiACAADlLAIAAIQQAgAAHFYCAALPqgIAAc+WAgAAN1M2AABvegIAA2oTJgACleICAAACaAIAAIOOAgABGuwCAAEKbNQ== Date: Fri, 2 Feb 2018 02:27:12 +0000 Message-ID: References: <1517163726.4051.23.camel@it.uc3m.es> <20180130043352.GB15400@spectre> <1517307927.3201.7.camel@it.uc3m.es> <49297C39-EF21-4D3E-898B-4728B61221BB@huawei.com> <06C389826B926F48A557D5DB5A54C4ED2A5F8047@dggemi509-mbx.china.huawei.com> <96DCDC2D-6F10-4C7E-A82E-3B868F55E23D@gmail.com> <7AEB3D6833318045B4AE71C2C87E8E173CF94DF4@sjceml521-mbs.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E173CF961AB@sjceml521-mbs.china.huawei.com> <088B437B-E9AC-43FD-B911-6A077F5000E0@gmail.com>, In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:8D199905E8C9DC377180430BCE5B4689DD186D7B78B79E9FFD0810F862CC08E3; UpperCasedChecksum:D51FB6C1A18F92D16FF7D80F7E4ED854AF2540FE8334FF62138EB06BBC34B00C; SizeAsReceived:8613; Count:46 x-tmn: [IvFVd5nkEc+HI+v2EPf/XH9wiHXrUQ8mmpbfDHrW19o=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM03HT145; 6:5b0JpcI6uE79HHpOmUO/+IfKj44zC9keOFH6q4ZXveHVSt7KFxL562ftyVxraX9ZqinClIKT6SlHzvG0bn2/aJZ/2vaFsgvzyYlhRGLpokTr3xaQGHOsKxwnjrRxsNTYFoMvYKMdfDn1c2Wj7AyVduL9rIWjQ9L/ZXQE2wYjysSESsl3/Sdfuh1l8zAf58jPHGSnV9Z/R2guAjr78PgcWdhIBmOHOLje0RNU0XnFqAc5yp9lwnS85A2uyc/iEHLiGdx+wsOhuPaIj9Q6bnyum9ViM5Y/ieWWMdBHIAKdJVPndNVTIeAvsR21F+GtKLTwgwCu8q0rU/Fu/niJRypO3+WqqU/yRgfFyvLp/bVwZis=; 5:+f7fxhbQlEoxupBaB5GYssBduZ+TC9Kf32sD/imjpuxjd7ZPZo0uFVqrXvlmupnff3zVJnE6u2YPuNh/ljgI+mZjNwmyRrkxwI1MTUfqfyizkboUOQf0rU+PFrxGrTFZdt4uXBJXDCsvhpN5in1qmEtVdUpPVwIQ3Opbs0YtW3U=; 24:QiKYcEbFTJceS1c4IF40fg1OWpa7vX+QSS55/xT9FlNgQeleyox/jO0bWvwpgl0hnit2RVA1yPda1gdDvyEQjzSXXPyHclO+vxAVYNw9n90=; 7:vGYdqXZMFWPOYVd26uxLDfQWFrhGAFJieAWCdVQFYTV87HOxuKVJjSJ9i6CLYWvBNoXRxIKpBaPRV9U92snxf1SAsfLAN0hr59ihwKqL0m5chX2c4Zhu8PvL82Nx5eKmQsp6VT4dPOJCpqmNkmcUWtguoA1BUVp7alU5a4fQchPLq+OmEBoJ/bEB0lZ1tzFi9e0RrKkM1D/UQO9tG3mqeuHOY94woHB9rCX+SCn5KP3nhW3UhHrNB01a3uTIIsqN x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:CO1NAM03HT145; x-ms-traffictypediagnostic: CO1NAM03HT145: x-ms-office365-filtering-correlation-id: 607039af-496e-4ff3-7cbc-08d569e477d4 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CO1NAM03HT145; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM03HT145; x-forefront-prvs: 05715BE7FD x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM03HT145; H:BN6PR22MB0771.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR22MB0771322101FE516104BFFD6B87F90BN6PR22MB0771namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 607039af-496e-4ff3-7cbc-08d569e477d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2018 02:27:12.5826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT145 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 02:27:20 -0000 --_000_BN6PR22MB0771322101FE516104BFFD6B87F90BN6PR22MB0771namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 agree with Jeff and Kiran. The last deliverable may result in identifying new work in other WGs as COM= S proceeds, or possibly informational/data model work in COMS for generic m= apping if needed. ________________________________ From: Xavier de Foy Sent: 02 February 2018 06:24:44 To: Jeff Tantsura Cc: Daniele Ceccarelli; Leeyoung; Liang GENG; qiangli (D); Kiran.Makhijani;= Pedro Martinez-Julia; NetSlices@ietf.org; Carlos Jes=FAs Bernardos Cano Subject: Re: [Netslices] Preliminary charter text for discussion Thanks Jeff, here is an updated text to address some of your points (removi= ng the lists of technologies and the "study" entry). For the last deliverable I followed your suggestion to replace "study". Oth= ers may want to discuss/reword this later, but we need a version for the Bo= F 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 domai= n or across multiple domains, and they may use heterogeneous technologies. = The goal of this group is to produce and promote a technology-independent a= nd resource-centric management plane for network slices. Resources associat= ed with a network slice are normally comprised of physical and logical conn= ections in access, aggregation and backbone networks as well as computing a= nd storage elements. Service functions associated with a network slice incl= ude network functions and network function chains pre-defined using corresp= onding network infrastructure elements. A "Network Slice" is realized using a collection of technologies spanning a= cross data, control and management planes. Many of them rely on existing IE= TF technologies including both concluded and in-progress works in data, con= trol and management planes. The foundation of COMS is a technology-independent and resource-centric man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for sp= ecific 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 s= ervices 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 man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 thro= ugh the notion of network slice subnets. Network slices will be leased to t= enants, which will be able to use Customer Service Interface (CSI) exposed = by the NS provider to run management tasks (e.g., on-demand measurement) wi= thin their slice instance under certain policies. The WG will describe an information model representing a network slice, acc= ounting for the key elements used in network slices: connectivity, compute,= storage resources, network and service functions =97 this information mode= l includes the representation of managed objects and corresponding manageme= nt 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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces. 4 Slice composition or stitching in multi-domain environment. 5 Slice management by the tenant under the control of NSP, including deploy= ing network services over a slice. The WG will specify management requirements and functionalities of data pla= ne entities as needed to enable the operation of network slices. For exampl= e, this may include abstractions of policy control and enforcement, or gate= way functionalities. The WG will also study the mapping between the abstrac= t information model and managed entities, and will liaise with other IETF W= Gs 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 document= s 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 describe= d above in the scope section. - SDI and CSI interface specifications and relevant YANG models. - Specify management requirements and functionalities of data plane entitie= s 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 nee= ded. 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 > wrote: Hi, /IAB shepherd hat on First of all =96 thank you for continues work and improvements! Please keep the scope narrow and concise (aka don=92t boil the ocean or eve= n a lake) There=92s no need to address every technology by its name, someone will be = forgotten, someone be mentioned mistakenly (e.g. there=92s no =93SR VPN=92= s=94, neither SR data plane =96 it is either MPLS or IPv6), control/data/ma= nagement planes would suffice. =93etc=94 - doesn=92t belong in a charter in any form. =93 Please be precise in Deliverables: =93Study=94 =96 can=92t be one, obliviously, it is part of the process, but= not the result I think, informational and corresponding data models would be a better desc= ription? Thanks! Cheers, Jeff --_000_BN6PR22MB0771322101FE516104BFFD6B87F90BN6PR22MB0771namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

+1  agree with Jeff and = Kiran. 


The last deliverable may result i= n identifying new work in other WGs as COMS proceeds, or possibly info= rmational/data model work in COMS for generic mapping if needed.

From: Xavier de Foy <x.d= efoy.ietf@gmail.com>
Sent: 02 February 2018 06:24:44
To: Jeff Tantsura
Cc: Daniele Ceccarelli; Leeyoung; Liang GENG; qiangli (D); Kiran.Mak= hijani; Pedro Martinez-Julia; NetSlices@ietf.org; Carlos Jes=FAs Bernardos = Cano
Subject: Re: [Netslices] Preliminary charter text for discussion
 
Thanks Jeff, here is an updated text to address some of your points (r= emoving the lists of technologies and the "study" entry).
For the last deliverable I followed your suggestion to replace "s= tudy". Others may want to discuss/reword this later, but we need a ver= sion 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 domai= n or across multiple domains, and they may use heterogeneous technologies. The goal of this group is to prod= uce and promote a technology-independent and resource-centric management pl= ane for network slices. Resources associated with a network slice are norma= lly comprised of physical and logical connections in access, aggregation and backbone networks as well as comput= ing and storage elements. Service functions associated with a network slice= include network functions and network function chains pre-defined using co= rresponding 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 e= xisting 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 man= agement plane. In reality, the network slice provider may have diverse tech= nology choices in different domains due to geographical and commercial reas= ons. Therefore, COMS makes no assumption on which technology is used for specific domains. The goal of COMS is to d= efine a common and inter-operative management mechanism, which is essential= for the concept of network slicing being adopted in a system with heteroge= neous network infrastructures and services functions. Major characteristics include:

- Enabling composition of slices within a single or over multiple domains.<= br> - Allowing the operation and management of a network slice in a uniform man= ner, even when this network slice span multiple technology and/or administr= ative 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 provi= der (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 subnet= s. Network slices will be leased to tenants, which will be able to use Cust= omer Service Interface (CSI) exposed by the NS provider to run management tasks (e.g., on-demand measurement) w= ithin their slice instance under certain policies.

The WG will describe an information model representing a network slice, acc= ounting for the key elements used in network slices: connectivity, compute,= storage resources, network and service functions =97 this information mode= l 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 interwork= ing.

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-l= evel 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, p= erformance, status information and performance guarantees for certain servi= ces.
4 Slice composition or stitching in multi-domain environment.
5 Slice management by the tenant under the control of NSP, including deploy= ing network services over a slice.

The WG will specify management requirements and functionalities of data pla= ne entities as needed to enable the operation of network slices. For exampl= e, this may include abstractions of policy control and enforcement, or gate= way 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 wi= ll not attempt to replicate existing device models and data plane technolog= ies.

III. Deliverables

WG deliverables are listed below and may be split in any number of document= s 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 describe= d above in the scope section.
- SDI and CSI interface specifications and relevant YANG models.
- Specify management requirements and functionalities of data plane entitie= s 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 nee= ded.

IV. Milestones

Dec 2018     Problem Statement, use cases and architect= ure
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
             sl= ices including abstractions of policy control and
             en= forcement, or gateway functionalities.
March 2020   SDI and CSI interface specifications and relevant YA= NG models



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

Hi,

 

/IAB shepherd hat on

 

First of all =96 thank you for continues work and = improvements!

 

Please keep the scope narrow and concise (aka don= =92t boil the ocean or even a lake)

There=92s no need to address every technology by i= ts name, someone will be forgotten, someone be mentioned mistakenly  (= e.g. there=92s no =93SR VPN=92s=94, neither SR data plane =96 it is either MPLS or IPv6), control/data/management planes would suffice. =

=93etc=94 - doesn=92t belong in a charter in any f= orm.

=93

Please be precise in Deliverables:

 

=93Study=94 =96 can=92t be one, obliviously, it is= part of the process, but not the result

I think, informational and corresponding data mode= ls would be a better description?

 

Thanks!

 

Cheers,

Jeff


--_000_BN6PR22MB0771322101FE516104BFFD6B87F90BN6PR22MB0771namp_-- From nobody Fri Feb 2 07:55:45 2018 Return-Path: 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 2B16312D956 for ; Fri, 2 Feb 2018 07:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 Um2M7gc_-92x for ; Fri, 2 Feb 2018 07:55:41 -0800 (PST) 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 3A23E120713 for ; Fri, 2 Feb 2018 07:55:41 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B0E6154F3281E for ; Fri, 2 Feb 2018 15:55:36 +0000 (GMT) Received: from DGGEMI403-HUB.china.huawei.com (10.3.17.136) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 2 Feb 2018 15:55:38 +0000 Received: from DGGEMI509-MBX.china.huawei.com ([169.254.1.109]) by dggemi403-hub.china.huawei.com ([10.3.17.136]) with mapi id 14.03.0361.001; Fri, 2 Feb 2018 23:55:34 +0800 From: "qiangli (D)" To: "netslices@ietf.org" CC: Benoit Claise Thread-Topic: COMS BoF proposal for IETF101 is uploaded Thread-Index: AdOcPO8i7E08um56S0ih6yAVcaLzVgAAQvhQ Date: Fri, 2 Feb 2018 15:55:34 +0000 Message-ID: <06C389826B926F48A557D5DB5A54C4ED2A5FC337@dggemi509-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.139.146] Content-Type: multipart/alternative; boundary="_000_06C389826B926F48A557D5DB5A54C4ED2A5FC337dggemi509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Netslices] COMS BoF proposal for IETF101 is uploaded 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 15:55:44 -0000 --_000_06C389826B926F48A557D5DB5A54C4ED2A5FC337dggemi509mbxchi_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Dear all netslices, The stable version of COMS BoF proposal has been uploaded onto the IETF BoF= WiKi page https://trac.tools.ietf.org/bof/trac/. Six associated documents = are linked. No further modification would be made unless the responsible AD= s explicitly ask or made by themselves directly. Many thanks and best regards, COMS BoF Proponents: Liang Geng - China Mobile >; Lei Wang - China Mobile >; Luis Miguel Contreras Muri= llo - Telefonica >; S=B3awomir Kukli=F1ski - Orange >; Diego L= opes - Telefonica >; Shunsuke Homma - NTT >; Giuseppe Fioccola - Telecom Italia >; Xavier = de Foy - InterDigital >; Akbar Rahman - InterDigital >; Daniele Ceccarelli - Ericsson >; Delei Yu - Huawei >; Ravi Rvindran - Huawei >; Kiran Makhijani= - Huawei >; = Guangpeng Li - Huawei >; Cristina Qiang - Huawei >; Sheng Jiang - Huawei >; Pedro Martinez Julia - NICT = >; Taesang Choi - ETRI >; Vishn= u Ram - Independent Consultant >; Seil Jeon - Sungkyunkwan University >; Pablo Ameigeiras - University of Granada >; Oscar Adamuz Hinojosa - University of G= ranada >; Jose Ordonez Lucena - Unive= rsity of Granada >; Carlos Jesus Be= rnados Cano - University Carlos III >; Alex Galis - University College London > --_000_06C389826B926F48A557D5DB5A54C4ED2A5FC337dggemi509mbxchi_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Dear all netslices,<= /span>

 

The stable version of COMS BoF = proposal has been uploaded onto the IETF BoF WiKi page https://trac.tools.ietf.o= rg/bof/trac/. Six associated documents are linked. No further modificat= ion would be made unless the responsible ADs explicitly ask or made by them= selves directly.

 

Many thanks and best regards,

 

COMS BoF Proponents: Liang Geng= - China Mobile <gengliang@= chinamobile.com>; Lei Wang - China Mobile <wangleiyjy@chinamobile.com>; Luis Miguel Contreras Murillo - Telefonica <luismiguel.contrerasmurillo@telefonica.com>; S=B3awomir Kukli=F1ski  - Orange <slawomir.kuklinski@orange.com>; Diego Lopes - Telefonica <diego.r.lopez@telefonica.com>; Shunsuke Homma - NTT <homma.shunsuke@lab.ntt.co.jp>; Giuseppe Fioccola - Telecom Italia <giuseppe.fioccola@telecomitalia.it>; X= avier de Foy - InterDigital <x.defo= y.ietf@gmail.com>; Akbar Rahman - InterDigital <Akbar.Rahman@interdigital.com>; = ;Daniele Ceccarelli - Ericsson <daniele.ceccarelli@ericsson.com>; Delei= Yu - Huawei <yudelei@huawei.c= o>; Ravi Rvindran - Huawei <ravi.ravindran@huawei.com>;  Kiran Makhijani - Huawei&nb= sp;<Kiran.Makhijani@huawei= .com>; Guangpeng Li - Huawei <liguangpeng@huawei.com>; Cristina Qiang - Huawei <qiangli3@huawei.com&= gt;; Sheng Jiang - Huawei <jiangsheng@huawei.com>; Pedro Martinez Julia - NICT <pedro@nict.go.jp>; T= aesang Choi - ETRI <choits@etri.re.= kr>; Vishnu Ram - Independent Consultant <vishnubright@gmail.com>; Seil Jeon - Sungkyunkwan University <se= iljeon@skku.edu>; Pablo Ameigeiras - University of Granada = ;<pameigeiras@ugr.es>; = ;Oscar Adamuz Hinojosa - University of Granada <oadamuz@ugr.es>; Jose Ordonez Lucena - University of Granada <jordonez@ugr.es>; Carlos Jesus Bernados Cano - University C= arlos III  <cjbc@it.uc3m.es&= gt;; Alex Galis - University College London <a.galis@ucl.ac.uk>

--_000_06C389826B926F48A557D5DB5A54C4ED2A5FC337dggemi509mbxchi_-- From nobody Fri Feb 2 08:31:31 2018 Return-Path: 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 6E248128959 for ; Fri, 2 Feb 2018 08:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 vlnombZB_lNs for ; Fri, 2 Feb 2018 08:31:26 -0800 (PST) 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 5707F12711B for ; Fri, 2 Feb 2018 08:31:26 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id BD2E29155B6DB for ; Fri, 2 Feb 2018 15:46:57 +0000 (GMT) Received: from DGGEMI423-HUB.china.huawei.com (10.1.199.152) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 2 Feb 2018 15:46:55 +0000 Received: from DGGEMI509-MBX.china.huawei.com ([169.254.1.109]) by dggemi423-hub.china.huawei.com ([10.1.199.152]) with mapi id 14.03.0361.001; Fri, 2 Feb 2018 23:46:50 +0800 From: "qiangli (D)" To: "NetSlices@ietf.org" CC: Benoit Claise Thread-Topic: COMS BoF proposal for IETF101 is uploaded Thread-Index: AdOcPO8i7E08um56S0ih6yAVcaLzVg== Date: Fri, 2 Feb 2018 15:46:49 +0000 Message-ID: <06C389826B926F48A557D5DB5A54C4ED2A5FC319@dggemi509-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.139.146] Content-Type: multipart/alternative; boundary="_000_06C389826B926F48A557D5DB5A54C4ED2A5FC319dggemi509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Netslices] COMS BoF proposal for IETF101 is uploaded 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 16:31:29 -0000 --_000_06C389826B926F48A557D5DB5A54C4ED2A5FC319dggemi509mbxchi_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Dear all netslices, The stable version of COMS BoF proposal has been uploaded onto the IETF BoF= WiKi page https://trac.tools.ietf.org/bof/trac/. Six associated documents = are linked. No further modification would be made unless the responsible AD= s explicitly ask or made by themselves directly. Many thanks and best regards, COMS BoF Proponents: Liang Geng - China Mobile >; Lei Wang - China Mobile >; Luis Miguel Contreras Muri= llo - Telefonica >; S=B3awomir Kukli=F1ski - Orange >; Diego L= opes - Telefonica >; Shunsuke Homma - NTT >; Giuseppe Fioccola - Telecom Italia >; Xavier = de Foy - InterDigital >; Akbar Rahman - InterDigital >; Daniele Ceccarelli - Ericsson >; Delei Yu - Huawei >; Ravi Rvindran - Huawei >; Kiran Makhijani= - Huawei >; = Guangpeng Li - Huawei >; Cristina Qiang - Huawei >; Sheng Jiang - Huawei >; Pedro Martinez Julia - NICT = >; Taesang Choi - ETRI >; Vishn= u Ram - Independent Consultant >; Seil Jeon - Sungkyunkwan University >; Pablo Ameigeiras - University of Granada >; Oscar Adamuz Hinojosa - University of G= ranada >; Jose Ordonez Lucena - Unive= rsity of Granada >; Carlos Jesus Be= rnados Cano - University Carlos III >; Alex Galis - University College London > --_000_06C389826B926F48A557D5DB5A54C4ED2A5FC319dggemi509mbxchi_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Dear all netslices,<= /span>

 

The stable version of COMS BoF = proposal has been uploaded onto the IETF BoF WiKi page https://trac.tools.ietf.o= rg/bof/trac/. Six associated documents are linked. No further modificat= ion would be made unless the responsible ADs explicitly ask or made by them= selves directly.

 

Many thanks and best regards,

 

COMS BoF Proponents: Liang Geng= - China Mobile <gengliang@chinamobile.com>; Lei Wang - China Mobil= e <wangleiyjy@chinamobile.= com>; Luis Miguel Contreras Murillo - Telefonica <luismiguel.contrerasmurillo@telefonica.com>; S=B3awomir Kukli=F1ski  - Orange <slawomir.kuklinski@orange.com>; Diego Lopes - Telefonica <diego.r.lopez@telefonica.com>; Shunsuke Homma - NTT <homma.shunsuke@lab.ntt.co.jp>; Giuseppe Fioccola - Telecom Italia <giuseppe.fioccola@telecomitalia.it>; X= avier de Foy - InterDigital <x.defo= y.ietf@gmail.com>; Akbar Rahman - InterDigital <Akbar.Rahman@interdigital.com>; = ;Daniele Ceccarelli - Ericsson <daniele.ceccarelli@ericsson.com>; Delei= Yu - Huawei <yudelei@huawei.c= o>; Ravi Rvindran - Huawei <ravi.ravindran@huawei.com>;  Kiran Makhijani - Huawei&nb= sp;<Kiran.Makhijani@huawei= .com>; Guangpeng Li - Huawei <liguangpeng@huawei.com>; Cristina Qiang - Huawei <qiangli3@huawei.com>; Sheng Jiang - Huawei= <jiangsheng@huawei.com>= ; Pedro Martinez Julia - NICT <= pedro@nict.go.jp>; Taesang Choi - ETRI <choits@etri.r= e.kr>; Vishnu Ram - Independent Consultant <vishnubright@gmail.com>; Seil Jeon - Sungkyunkw= an University <seiljeon@skku.edu>; Pablo Ameigeiras - University of Granada <pameigeiras@ugr.es>; Oscar Adamuz Hinojosa -= University of Granada <oadamuz@ugr.es= >; Jose Ordonez Lucena - University of Granada <jordonez@ugr.es>; Carlos Jesus Bernados Cano - University Carlos III  <cjbc@it.uc3m.es>; Alex Galis - University Coll= ege London <a.galis@ucl.ac.uk&g= t;

--_000_06C389826B926F48A557D5DB5A54C4ED2A5FC319dggemi509mbxchi_-- From nobody Tue Feb 6 14:11:24 2018 Return-Path: X-Original-To: netslices@ietf.org Delivered-To: netslices@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B8F12711E; Tue, 6 Feb 2018 14:11:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: bclaise@cisco.com, coms-chairs@ietf.org, lflynn@amsl.com, netslices@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151795508236.25814.6964894970565795113.idtracker@ietfa.amsl.com> Date: Tue, 06 Feb 2018 14:11:22 -0800 Archived-At: Subject: [Netslices] coms - New Meeting Session Request for IETF 101 X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 22:11:22 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the coms working group. --------------------------------------------------------- Working Group Name: Common Operations and Management on network Slices Area Name: Operations and Management Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: teas, detnet, sfc, nvo3, opsarea People who must be present: Benoit Claise Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 9 08:52:20 2018 Return-Path: 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 10D19127698 for ; Fri, 9 Feb 2018 08:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 676ftdRINlfA for ; Fri, 9 Feb 2018 08:52:17 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699FF1200FC for ; Fri, 9 Feb 2018 08:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=373; q=dns/txt; s=iport; t=1518195137; x=1519404737; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=9wWos/Y4CIMoKaGdBOOico3Oi98uZRZ+n2KB0VdjGKg=; b=AlRmPnVT0sEvHHTKRh6cBr4WUGopqEyccMdhGkZgtZAWnGD0+CC2Pdp3 KtouMKDJ4N7jX8cY3dzvSTK9GABpE92NAOG9GrJIRLWcUlaPMAhDaBTak ylOapU5si0OOOzrusvKB2pigQAGP5pdlbeZa0O8WqNK7RDFXjyEmj57Fi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQBn0H1a/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMkggOEDYsYpx+CAwqFMgmDFBQBAgEBAQEBAQJrKIVNFUE1AiY?= =?us-ascii?q?CbAgBAYoxryiCJ4UBg3eCCgEBCAEBAQEkgQ+DbYNsgWgph2+BBIJLgmUFpCwJl?= =?us-ascii?q?gGCBQGKM4gGj3uIGIE8NiKBUDMaCBsVgwSDegEIdECNLQEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,483,1511827200"; d="scan'208";a="1919626" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2018 16:52:15 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w19GqF1O029298; Fri, 9 Feb 2018 16:52:15 GMT To: NetSlices@ietf.org Cc: Ignas Bagdonas From: Benoit Claise Message-ID: Date: Fri, 9 Feb 2018 17:52:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Netslices] COMS BoF approved 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 16:52:19 -0000 Dear all, A quick note to let you know that the COMS BoF has been approved, as a non WG forming. We believe that the questions to be answered are: - clarify the problem space - find out whether IETF is the right place for this type of top down approach - how would that top down approach meet bottom up (being worked on in different WGs) Regards, Benoit From nobody Sun Feb 11 13:01:49 2018 Return-Path: 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 0F20B127078 for ; Sun, 11 Feb 2018 13:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01] 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 41OT5aAEs03T for ; Sun, 11 Feb 2018 13:01:42 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20128.outbound.protection.outlook.com [40.107.2.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109851271DF for ; Sun, 11 Feb 2018 13:01:41 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=a.galis@ucl.ac.uk; Received: from alex-galiss-mbp.connect (90.255.55.229) by DB6PR0101MB2344.eurprd01.prod.exchangelabs.com (2603:10a6:4:2e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Sun, 11 Feb 2018 21:01:39 +0000 From: Alex Galis Message-Id: <54871902-0D30-401E-B492-4253FE680CEF@ucl.ac.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_D442891C-61C4-4C1B-842A-1AF7B78CC420" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 11 Feb 2018 21:01:37 +0000 In-Reply-To: Cc: Ignas Bagdonas , Jari Arkko , Jeff Tantsura , Network Slices To: Benoit Claise References: X-Mailer: Apple Mail (2.3445.5.20) X-Originating-IP: [90.255.55.229] X-ClientProxiedBy: CWLP265CA0009.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:10::21) To DB6PR0101MB2344.eurprd01.prod.exchangelabs.com (2603:10a6:4:2e::14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d18ada58-0cf6-427a-2f05-08d57192a525 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:DB6PR0101MB2344; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2344; 3:NyuDXv9dDHp0qx1D2IOOyGUHZ0N9Kfubl52gHU684H/cdnxebWhFyQlishrUokzvJUAWn0Q8zvIjemqgDr2YEqbwhMqUX0at8GYWNeFnCfb2QYF9Cpcpy5wxkpTWNgezylL7kNn7j9n0hUdRTIdkylGdn+IggPBSNF7Me9OgO3rXNtsuv7UKp33TjPnE8+f1b/RreQ/M7rwsnMIndW8IupBhDkTKrDi6mIunTb8gd3bf1D6iWYn4FSiBP9+YX4Xt; 25:mZemJqXiXSLKjRyQJyv/ZdiQoRQ+B/8V80QNx4UcEnjReAicrKg+W++1EFpbwYSVECTZcP3DAnnXxdHldwL0LUvVqlsoI6wZYV7Up7JLPwnFEvpXlIOqXpqwMBBnDWMcul8LojI0XXvr+ORE+aPLRtUHp58LntXmC7aULK05QTmvrKakmSSn/vZvXl3qNy2SY4RK3sqYzzAgAv7oSOgD2NJkbqqo24EMTESAVjNt8kMmRKPFD9+Esaw0Wp2bdTZ+YkEeicHddC38RpwF0ib79hobUV/9nBDovxvJkUz8XqTWVP9OkdhebBz8QGkoWiQ3blCYBdszdwdV8Of7imaR1w==; 31:1mPjXzPOh9s0wkotcJ5JFk4thJxcd+P6VkBTUKi7wsJCxe/qUr+QnIM+cRQBT1JTqadhUEIKlyM5ynoJATeMAskW+EFIr+TaxHWTIs8mI6zjkTldsZ9kxbSzAcs77WTqCj8JlZwzral7LW8z0fGz3V9a+S8VfLSFJdhQHv0bfnkg94v9J7lxJDMPnBkjX+Xd0vEQtw+Nm8MIVKmaEMYy/EtwLoTP9REPhppqCVg7KwM= X-MS-TrafficTypeDiagnostic: DB6PR0101MB2344: X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2344; 20:wjxPMJktiLiboG0tDr/EgCwyMQh/RI/mbCa46dhABtncsWkl7QpbwwcO2k4PeEEIzFoPB2/P03dIb9bRcd2yjT9i7fsWWQfORdQXfooIKa+LNlxBHG8SmrfL+HJUZ1l5RT47AVuLVivSfmTbs0Ck8dG6juD8LT7gbAxxFVvuhBvugE+T9bbuGchRDl6+rrsV0LcBatEBgBehICPVO/635AVhu8hyZ7wiROcIr6B445oFNrbU9dTn420smKQavh4Er7eVLZ3qjiZd09q8jJGcEc0rREeNcAuUZTXYDn33Wj4FB/cg/aNX688T7ONdR9PpnT7j7FeVdC3cqBPpHZOI+un7zPYc190psbx6N3yJQa8h3W7/vYxI2SntVi5UHQR6Ri86KW2Prcl1R4rprOzt2bvDi15I0F3yJ1dEZfyg6TEs4hhi9cBt7b5Gubi43ueX5NlpqhF72CgpVO95dNhIZQJMX4sksmct0fILSnLCSbzwXjbvRzUWpuoLDfkrcXLu; 4:ydtcO3ayEUVwlwD9owJ0jnTb8ssK1/Do9Ue23HX6Ym7XM32dFgv8BTwqcRSl+0F6Bh8gVyisdKPLpWdP1ACmIKCtNQwdM1BMNY96Ih1AQ9tnUDSDf6lB3xmVgXbRGApb1IHOxU6DVmT2tJO4e8b6da+5k69KbJNmZ/laFOCF7wL9aY6ONMUQG0ujXhXL4jaxM8ROVWQ/eG7qVWz6gz6rzGQLQnk5ovx8bK3FQCPTdJMur30WxQ0MPjXMU7olVM805SoVL74XO5plBFYAnpG0yrhRv1VO6r+JxkFR7FdJ2EKPKmYLgULeu49K8PYNv1f16EphSiO1InyGOW8r0Lrn88+7fnDZVxXIfH/ZjgPz/ls3CbwKrp6MmTkms3bFVnLu X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(95692535739014)(21532816269658); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(6041288)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB6PR0101MB2344; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0101MB2344; X-Forefront-PRVS: 058043A388 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39380400002)(39860400002)(366004)(504964003)(189003)(199004)(25786009)(6916009)(5660300001)(36756003)(16586007)(74826001)(345774005)(97736004)(54906003)(105586002)(786003)(16526019)(316002)(186003)(52116002)(7736002)(42882006)(966005)(68736007)(59450400001)(76176011)(26005)(33964004)(53546011)(39060400002)(478600001)(6506007)(386003)(33656002)(4326008)(2950100002)(2906002)(106356001)(229853002)(606006)(53936002)(74482002)(50226002)(81166006)(81156014)(8676002)(8936002)(3846002)(6116002)(6246003)(83716003)(66066001)(6486002)(69556001)(53946003)(6512007)(54896002)(6306002)(236005)(86362001)(16200700003)(57306001)(82746002)(84326002)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0101MB2344; H:alex-galiss-mbp.connect; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ucl.ac.uk does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB6PR0101MB2344; 23:4Y/7R3sFlKuR9BU8zJ+tWxljT+7p5q+gDmID3iC?= =?us-ascii?Q?nZDJJd6UPGrzydgWXguIs2UTsAj9/IGGH2HavB7xWASa2/DQ1UOK2QnDkhaD?= =?us-ascii?Q?Q1d/fj7ZBa8/hCvjwZJjKsWk5cAmtXm+b+fMoD3onBSDlYChrB79V4C21tZM?= =?us-ascii?Q?PZti0TGvpous0GtSYQ2kVUBgwTligaY5w0QEnyIi1gEZo1STVMbKO2hYCODk?= =?us-ascii?Q?3QJfZXFDCe5fn563VUVzYuC5rs7qI4J+MFli2pZ0IG1VP/RL9MKaWNb2om+m?= =?us-ascii?Q?8HQanTNi+BhJJ3EQxgAJ0zQ7S8tNksOqNUN41xVWqPCJJxM2A3OBN/emXuWw?= =?us-ascii?Q?HxOwDHFS0ErmNIjmo2zbW/kZdlgHpCYb8DWSHQ/4l7A2oBGZBP7qMSSt1iTk?= =?us-ascii?Q?YcmxWc1fe0SYC6uEkbH4JTiNSB5f3+Ghk17lrvh5NYN7PfGOFDF3WAnpWldn?= =?us-ascii?Q?StPNvUumLXatAp+tjOdgRx0NhucRV/kmPS70B2J9kYlWGVG1WbC+s466/utk?= =?us-ascii?Q?Dhjy+/YnFReysw1yDkMQvnVho3kORaELjU/ghfttnNRc7Q3K5ApU2R/bPuQK?= =?us-ascii?Q?CcxGzT62BrwfwLyGU+k05m0rvudSO94+/Lu8y1DOlr2WkSWgbS84nqwromec?= =?us-ascii?Q?MJN9sFciKTtmz5QTfFT66+W5DOcYQazgKhK6YusMLfTpZZpl6l/KvUN+xvkC?= =?us-ascii?Q?EPHr9uHkZlhGsC0d1IqKLCHh+P4R6mR0fi65hRgJkI5RV/qURzzKs7+/Qxiz?= =?us-ascii?Q?8+qDjenMHRKXkYQqPFkxt/fweaEGmGkWlDQVOx0c5p7wgbqX4OjSIvaL8lAp?= =?us-ascii?Q?0RgvrQEixgUkMT0/qt3uYOEMd8PEDS8howEzv0jbjlrDQDfHnVB88oiJ8ZWk?= =?us-ascii?Q?JcdElmUkMBAfkGTYBT//TWx2wxtzWVeQ5i3Qzfr0JDgE4PlGxXpjZnYPEfDv?= =?us-ascii?Q?rRbOuN1lWZfX3EqoOCjBCh2IhYiv4M3StX6+BIN3CrKAL6cg3zOYtZoaM5N/?= =?us-ascii?Q?taFcoFlPCF814GX5s3YWJq3kbr5A1WVfBc1Bws7RE6m04xb7V61fEUx4ymeQ?= =?us-ascii?Q?IW7r1kUob1HrgKDMOZ5L1KElrTPCtB41Y9LvhAPCdLm+Y5ZNbJTx+sm/FNW6?= =?us-ascii?Q?lR3d2bixohGP0U4amS/bje1rv5HbY7+C8f2i01FX8vhfQEJph1ujYoTr/0Jw?= =?us-ascii?Q?vrUkiT4IqabHkazQYJXQNi5Nj3LHIQEknOmsLXITwt7lW9RPIhBW9bjsn8T+?= =?us-ascii?Q?DhAVIWa5R2Pe3YM3AMEoZTPnOWNa80S06csFf3RbCzMYvXbz9DbA0gjzJYzl?= =?us-ascii?Q?tvYV4QAbR5CuUFc0A14zbQ2G0Qyrx7sb//TJGfHeVt05IJy05NQtE5cdkoDe?= =?us-ascii?Q?UmLgCendRoWphqu16aRdVN8AKyM4/6IdxzHvMnefwe1wNM1FjaGHJIA0AjK9?= =?us-ascii?Q?XhHisU6EayCyVklpC19tQtyWxklEMDekyOAR214R6Q9+Zzq8xCg9YropFj6k?= =?us-ascii?Q?iVOBjXLw+erIB/iGDVeJCUGJtKrHX5zxJ7gc1Cl7mKVpVs4NcMaGcnyXxskC?= =?us-ascii?Q?bNtfzZMJYS/GYfgZGMA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2344; 6:26kQuQQPsNCRhCxe44RflZ0gvqq2Zegi+lDCtB1FeHun6WQDA9vofodBzsVyKTbAE+TFBmtrA1zpFB3/s/i5/mw9EHCqBMVj9yOMMMZpdFLXfVuwj30L2R6+U7/eack8zWZu9/qsXpyEhK2cjoqjgKZVmwoUMfTxiRBjFU+5eFsFK41JWNvqPlg7A2qETxn0FyapghSM5y9QNt9SMa0V9KrKaF4ZThCdVQcnFj4ppgk4Zggd9F0U5ipDQD0xEZmXvpavFGjXVlhPh0wDRuJjofuw0FlmMLRWTXdywjLJUJHX4dopMv/0MwIcBuIf+pMX4z5a9r1WkRCgYUXDAFVF+Tnrr+YRl5RP5xf76MvxAfU=; 5:benI44/kGDAp/vwA2xUlGKYBHUsEDCgPJAwhN4mWItWKoYt2L/fUljg4AJMtIGdf6Hs6JU7ZLMAxgjOS6Qoa8HsSOv//Lj5Nev0JQCBXyj7nTg/RrUpLhHSWz1ALrmkxCEcK8j9IgnozjTJ0jc5honqiS9GFWaJsdHg7l+6G5IY=; 24:x9f5zw6cgFv0/L5ZZwJ64hSLxcuFhpliYf9x2isCCChuaBBTtxOvesvWLtq3U5o+GzQtocY8j9ZsjVF/06RSRuqEzw32Uz5Exlxj6MU4PnU=; 7:opSUCocbjVs9qWBKzcoZoV4oKnqxHH52hePCcN2Wgw7oV892kHfcPbYfdlRdHO/4NrSH7X8I4VV1Jrw62MazaqKefUyhLTno4xFXjr+jSiVlvTxqMJdTdReUZqPOyHtgPQcJWBV94JziWRiWXyrUqcKuIrM8dbt27LwcOAEo0ic/0S1L+FXnZQvccyH7m8LnkL93Bh6Y0fh2BEh7dO9Q6EEzyaMlKtJa/0BNGR5OJxnsY/+d7Mu6GGrT08iBeHiw SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ucl.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2018 21:01:39.0290 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d18ada58-0cf6-427a-2f05-08d57192a525 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 1faf88fe-a998-4c5b-93c9-210a11d9a5c2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0101MB2344 Archived-At: Subject: Re: [Netslices] COMS BoF approved 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Feb 2018 21:01:46 -0000 --Apple-Mail=_D442891C-61C4-4C1B-842A-1AF7B78CC420 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 11th February 2018, Dear Benoit and All Thank you for your message and for the opportunity to present and = support the need for the COMS work scope at IETF101. Already in the last 3 weeks the proponents of the BoF have reviewed the = scope of our planed presentations with the focus on answering the 3 main = questions: - clarity on the COMS problem space - clarity on the need at IETF of the COMS top down approach (i.e. = designing COMS components and their interworking interfaces) with links = to the bottom-up issues. -clarity on the link of the COMS top down approach with the other = relevant bottom up work (being worked on in different WGs)=20 We as BoF proponents are planning to present our views on the above = questions at the next IETF101 BoF provided that the agenda would permit = it. I have 2 additional important issues, which I would like to bring to = your attention: 1. At the last IETF100 an excellent presentation was made by Jari Arkko = & Jeff Tantsura & Joel Halpern & Bal=C3=A1zs Varga (i.e. = =E2=80=9CConsiderations on Network Virtualization and Slicing=E2=80=9D- = https://datatracker.ietf.org/meeting/100/materials/agenda-100-rtgwg). = This presentation proposed a number of IETF work items related to = network slicing including the need to "Connect the top-down and = bottom-up approaches to thinking about virtualization and slicing=E2=80=9D= which I fully agree with. As such I strongly support and kindly suggest that Jari make an updated = presentation at the next IETF101 BoF provided that the agenda would = permit it and also provided that Jari is willing and available to do so.=20= 2. In line with RFC 5434 we as COMS promoters are kindly asking you and = the selected BoF chairs for the lion share of the presentation time = budget at the next IETF101 COMS BoF.=20 This would allow us to properly answer to your focus questions and also = initiate an understanding on what the real, underlying high & low levels = problems are that the tenants, operators and deployers of a network = slicing technology have and that the COMS work needs to address at IETF. = As such in line with RFC 5434 guidelines the presentations that are not = directly related to the COMS area should be limited and they should not = open up ratholes that are a distraction to the more basic purpose of the = BOF. I hope that the above would be of help and also meeting with your = approval. Please advise Thank you in advance Best Regards Alex (as one of the COMS proponent) =20 =20 > On 9 Feb 2018, at 16:52, Benoit Claise wrote: >=20 > Dear all, >=20 > A quick note to let you know that the COMS BoF has been approved, as a = non WG forming. >=20 > We believe that the questions to be answered are: > - clarify the problem space > - find out whether IETF is the right place for this type of top down = approach > - how would that top down approach meet bottom up (being worked on in = different WGs) >=20 > Regards, Benoit >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices --Apple-Mail=_D442891C-61C4-4C1B-842A-1AF7B78CC420 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

11th February 2018,


Dear Benoit and = All


Thank you for your message and for the opportunity to present and support the need for the COMS work scope at = IETF101.

Already= in the last 3 weeks the proponents of the BoF have reviewed the scope of our planed presentations with the = focus on answering the 3 main questions:

- clarity on the = COMS problem space

- clarity on the = need at IETF of the COMS top down approach (i.e. designing COMS components and their interworking interfaces)  with links to the bottom-up issues.

 -clarity on the link of the COMS top = down approach with the other relevant  bottom up work  (being worked on in different WGs) 

We as BoF proponents are planning to present our views on the above questions at the next IETF101 BoF provided that = the agenda would permit it.


I have 2 additional important issues, which I would like to bring to your attention:

1. At the last = IETF100 an excellent presentation was made by Jari Arkko & Jeff Tantsura & Joel = Halpern & Bal=C3=A1zs Varga (i.e. =E2=80=9CConsiderations on Network = Virtualization and Slicing=E2=80=9D- https://datatracker.ietf.org/meeting/100/materials/agenda-100-r= tgwg). This presentation proposed a number of IETF work items related to = network slicing including the need to "Connect the top-down and bottom-up approaches to thinking about virtualization and slicing=E2=80=9D which I = fully agree with.

As such I strongly support and kindly suggest that Jari make an updated presentation at the next IETF101 BoF = provided that the agenda would permit it and also provided that Jari is willing = and available to do so. 

2. In line with RFC 5434 we as COMS promoters are kindly asking you and the selected BoF chairs for the lion = share of the presentation time budget at the next IETF101 COMS = BoF. 

This would allow us to properly answer to your focus questions and also initiate an understanding on what the = real, underlying high & low levels problems are that the tenants, = operators and deployers of a network slicing technology have and that the COMS work = needs to address at IETF.  As such in line with RFC 5434 guidelines the presentations that are not directly related to = the COMS area should be limited and they should not open up ratholes that = are a distraction to the more basic purpose of the BOF.

I hope that the above would be of help and also meeting with your approval.

Please advise

Thank you in advance

Best Regards

Alex

(as one of the COMS proponent)

 

 






On 9 Feb 2018, at 16:52, Benoit Claise <bclaise@cisco.com> = wrote:

Dear all,

A quick note to let = you know that the COMS BoF has been approved, as a non WG forming.

We believe that the questions to be answered = are:
- clarify the problem space
- find out = whether IETF is the right place for this type of top down approach
- how would that top down approach meet bottom up (being = worked on in different WGs)

Regards, = Benoit

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

= --Apple-Mail=_D442891C-61C4-4C1B-842A-1AF7B78CC420-- From nobody Mon Feb 26 12:10:12 2018 Return-Path: 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 3CC6A1271DF; Mon, 26 Feb 2018 12:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 8YOXX7etmnpk; Mon, 26 Feb 2018 12:10:10 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37391242EA; Mon, 26 Feb 2018 12:10:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=234; q=dns/txt; s=iport; t=1519675810; x=1520885410; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=MhXl7hbls6bGy/MgGnDQ2KXKiunpUjLlOdN9RWE5ctI=; b=GghKeGTfwRpW6wVPxR0nZosmPVsp+cfJCb2BsLkgB9TFnSoabcfM13oV fibObMEvh2fKR5Y4dSerkZbgEzBU5qgnbWzYhpRI6RS7tBKyYc4qLEccw 9H/d2bbTW8gX1PWtwCVd5hn8TsHBo/h53H+0M6UGqJv+Rw/165pdTuRUK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgC1aJRa/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUlKINUixaOWguBPY0piHCCAgqIUhQBAgEBAQEBAQJrKEIQAYR?= =?us-ascii?q?6FXYCJgJgDAYCAQGFDKwtgieEdIN7ghQygQ+ICoFmKQyHYYNFgmUFoWEJlCACg?= =?us-ascii?q?XABiTiHNY5RhySBLzUhgVEzGggbFYJ9hFs/N4V5hl0BAQE?= X-IronPort-AV: E=Sophos;i="5.47,397,1515456000"; d="scan'208";a="2303295" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 20:10:08 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1QKA7Nv015171; Mon, 26 Feb 2018 20:10:08 GMT To: NetSlices@ietf.org, netslicing-chairs@ietf.org From: Benoit Claise Message-ID: <97785343-bacb-1cb5-181f-1c3ad18d3b52@cisco.com> Date: Mon, 26 Feb 2018 21:10:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Netslices] COMS BoF co-chairs selection 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 20:10:11 -0000 Dear all, Exactly like for the first BoF two IETF meetings ago, Adrian Farrel and Gonzalo Camarillo have accepted the invitation to serve as COMS co-chairs. They can be reached at netslicing-chairs@ietf.org Regards, Benoit From nobody Mon Feb 26 13:02:11 2018 Return-Path: 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 D153B1241F8 for ; Mon, 26 Feb 2018 13:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 zDhuzGhgoDGJ for ; Mon, 26 Feb 2018 13:02:06 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 39B9012711A for ; Mon, 26 Feb 2018 13:02:06 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1QL22l1017302; Mon, 26 Feb 2018 21:02:02 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93C182203B; Mon, 26 Feb 2018 21:02:02 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 7E9AF2203A; Mon, 26 Feb 2018 21:02:02 +0000 (GMT) Received: from 950129200 ([193.57.120.23]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1QL20sW026340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Feb 2018 21:02:01 GMT Reply-To: From: "Adrian Farrel" To: "'NetSlices'" Cc: Date: Mon, 26 Feb 2018 21:02:00 -0000 Message-ID: <020d01d3af45$0cb9e530$262daf90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOvRN8/i8i9cTxsQ0mF/eYT2jD0jA== Content-Language: en-gb X-Originating-IP: 193.57.120.23 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23688.003 X-TM-AS-Result: No--15.029-10.0-31-10 X-imss-scan-details: No--15.029-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23688.003 X-TMASE-Result: 10--15.029000-10.000000 X-TMASE-MatchedRID: RCsvJ8LHv2kIbamlYuC6xPDrFod3YoIK0w14HFJQjaObUktpKVcKHQGa WqFPvEel7s149o3d/dwsaEi65axGR6VDPSjL3ziRVLLSJen1JCcLce5ZyDJAJpUQzHWBKOFAK93 7aFdF5XO0RWzCxfH8GxoUqX3CkGAU5VtV90uxxtfFlCgYxEaGE9ZKsq3DGpalRJWmeOMHa+Rhej p7pwzKTPK2UTIXij9b6PqqItKfJWDgpCfL46wSl6Skqjfmd3aeX6IRwqkp2m7b6Y+fnTZUL/bUh Pv66jYYMwE0P2gaX7VumbNFAFJX+9TO9w9KisCUBQo00KRXInG5pw2tsxj4tPgnJH5vm2+gBpNq UzwLvvf7VLhu60jHpptdZQUgGr+pTX7PJ/OU3vL+xOhjarOnHt0H8LFZNFG7JQhrLH5KSJ0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Netslices] COMS BoF Objectives 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 21:02:10 -0000 All, Gonzalo and I have just been chatting with the (three) OPS ADs about how to handle this BoF. The first thing to note is that it is a non-WG-forming BoF. That means that discussions of "What the WG will do" or "What the WG charter will look like" need not trouble us. We can focus on what the problem space is and what work the IETF might do without worrying about how that work might be split up or packaged for specific WGs. Second thing to note is that we have 2 hours. You can achieve a lot in 2 hours, but you have to focus. You have to know what it is you want to say and why. You can't spend time on peripherals or waffle. In trying to work out what would constitute a "successful BoF" we decided that the answer is clarity of understanding. If, at the end of the BoF the people in the room (and especially the OPS ADs) have a good, clear, and shared understanding of the following points, we will have succeeded. The ideal would be that, after the BoF, anyone from the room could explain these points to a newcomer. - What is the problem space? This is not just what is in scope, but also what is out of scope. In particular, it is the focus of the problem: *the* thing that you want to achieve in an operational network. - What is your proposed solution architecture? - What interfaces (precisely!) are you proposing should be worked on? - What deliverables do you envision and (since no one can have everything they want immediately) how would you prioritize the deliverables and where would you draw the line between "must have" and "can live without for now"? - How does this proposed work relate to other IETF work? Building a relationship with other work can help people see the bigger picture. How does other IETF work interface to this solution? - Is this "top-down" approach consistent with the way the IETF works? Should some or all of the work be located in another body or within OpenSource? Why? I suggest not leaping in at once with responses to these points: you don't need to convince your chairs, you need to work out how to convince your audience. You need to be working on the list to plan how to tackle this question. I also suggest you hold back on agenda requests or proposals. That will all become clear when you know what/how you want to explain. Instead, spend some time getting clear in your heads what it is that people commonly misunderstand about this work and how it could be explained better. What is the core essence that has to be got over to the audience, and what is marginal or add-on that could be left out of explanations? Where do you need to use new/different words to convey meaning that is (overly) familiar to you? Where would a picture serve better than words? Our job as BoF chairs will be to help you achieve these things, but also to be hard in our friendship! Expect us to stir things up a bit to make you all (and your audience) think. Expect us to insist on you injecting a good dose of reality into what you say. Expect hard questions. Best, Adrian (per pro Gonzalo) From nobody Tue Feb 27 15:15:17 2018 Return-Path: X-Original-To: netslices@ietf.org Delivered-To: netslices@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7120D12EAD1; Tue, 27 Feb 2018 15:11:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: bclaise@cisco.com, netslices@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307446.5200.15055124889285229275.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:14 -0800 Archived-At: Subject: [Netslices] coms - Requested session has been scheduled for IETF 101 X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:14 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. coms Session 1 (2:00:00) Thursday, Morning Session I 0930-1200 Room Name: Balmoral size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Common Operations and Management on network Slices Area Name: Operations and Management Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: teas detnet sfc nvo3 opsarea People who must be present: Benoit Claise Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Feb 28 02:25:24 2018 Return-Path: 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 4B06B12EAEE for ; Wed, 28 Feb 2018 02:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 oeCBx5Dyon4W for ; Wed, 28 Feb 2018 02:25:20 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-oln040092005104.outbound.protection.outlook.com [40.92.5.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253AF127909 for ; Wed, 28 Feb 2018 02:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lxvFzXm56vfiM79CXMHMpB7Ng7AZx+deFmSNufDhMNU=; b=kRtqN3CnwLKRzs0/32H6TQc5qRgVar7Bkiq3n/l5YT1Jvc7G2t23nomrardEbv2rHb1GofhtqyKlZOGIdQU41ko8QjUV2uuW6lgMx0HOtQFkkDoU/o6dKXqC9HHVxi2S7K8cEjnMWdd6Ex9i4Qq0DOanrHVHjRX9Vea8o+Zyk7oKySsxkXiDQdxM9sr6zfOmckYduQqdR5DCAEhWkTlZfmfV99jDmDFxBjV7yYU+Ta0qbIYx5r9FnNcHe/rPWt/z5YQBdJwHpecX6/YI5Tg4l9mEuw+7qeiuQpJWFLdxAHujxo2VoKVjJU064cnmzea6nnuBo9Oa5h5nTrk+w/3v/Q== Received: from SN1NAM02FT028.eop-nam02.prod.protection.outlook.com (10.152.72.60) by SN1NAM02HT034.eop-nam02.prod.protection.outlook.com (10.152.73.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.527.18; Wed, 28 Feb 2018 10:25:18 +0000 Received: from BN6PR22MB0771.namprd22.prod.outlook.com (10.152.72.60) by SN1NAM02FT028.mail.protection.outlook.com (10.152.72.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.527.18 via Frontend Transport; Wed, 28 Feb 2018 10:25:18 +0000 Received: from BN6PR22MB0771.namprd22.prod.outlook.com ([10.171.180.14]) by BN6PR22MB0771.namprd22.prod.outlook.com ([10.171.180.14]) with mapi id 15.20.0548.013; Wed, 28 Feb 2018 10:25:18 +0000 From: Liang GENG To: "netslices@ietf.org" CC: Benoit Claise , Warren Kumari , "ibagdona@gmail.com" , Adrian Farrel , "Gonzalo.Camarillo@ericsson.com" , Jeff Tantsura Thread-Topic: BoF thinking flow Thread-Index: AQHTsHwyfTIn12LuFEW53URCV+jTw6O5l3ndgAADnS8= Date: Wed, 28 Feb 2018 10:25:18 +0000 Message-ID: References: <30E4F04E-C641-4176-B184-28A2DFE3E7C5@ucl.ac.uk> <65A72755-93E9-407F-8252-12D6C75702D8@ucl.ac.uk> , <009001d3b07c$2b4ce7d0$81e6b770$@com>, In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:A9576311CA2EB8558844478361E3B59F6115838CBD4A76D909A0AFC4C97FED9D; UpperCasedChecksum:F7BBF9AA16A8B157320341CBC3DC10FB7E5DC1F45CC316AA2BF2D9B650D764D9; SizeAsReceived:7422; Count:46 x-tmn: [CBi1Id8MVUaxAh+Ad0FE3st5CB5ya7ZP] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM02HT034; 6:cFT9abCDxZGHfbIUtFKYNA6nKeZyHjFoT3ZO/5tefFTMu6TOMWDLRbs4Q1357HuEqQdhrdWKgq1HUUESfMlOv7rbRWI5dV1PZ+GbBWVB7QgOoXcd8Wl7hjnJUM5LggywXVgrgNCyACwqW7BEkptB982Em8EIcB2pn3VpRmr0NYVcFNH0+w+CfliN/lQVhXlulYNc5o+LuB3dLCRU3qsfq6KBC78ODHuruxHx3TKUkTbH8/sRNDwP6sjWSAj45CoTWlbtPWhw12uQ3iAF1Nqs2Xh9CboRxN3ZSvjmKOLJTaYvO31aaBbqVI3Xv8p6oOvAA5cv+lHR7I0oO0hWnWKBRGzADNoBf9rzED04S2nF0tI=; 5:IQV1bGiA4SIZSobVTqWbKE32ii+ib/5+vtcpy4yzJxlap6pT9jTp+4bhhlj5h7U/nqGaPn70QkAb3/x1aRdXrnCNDCD5ww7AiwwsWxz2whztQR5/LTtp6UUuh6ok49adHc+Fd0i2CzsXTf0nyphb8g6A5a4IcJorMs0JVgE9/uw=; 24:bpYY5l2UB/salxnkT91e+hpaUPEw0uhPhFBoLHYS2CTPc1qONMVnTxLq6sCXItQulVnlqer7Cj94Sd8s9oNGdEEXUcKJ6gqb2lrpOuC0ETM=; 7:oRgKbpsYV1HqqHqyRu5uELFMHyToUcvtKuHhfIXDZVnQLMyDwuvJQHdNf+Z+fdzFSKf54prcz3SjvQyrn9jCYJNunynssKxTroV63P4uznvt/8HtmREi4ACbq5cJzpmejcVc8XyLNbtTiVNWGhEahCUNPuMdG11FMtjUGStcY5XoUFnXa3QzoiiTewG9T21CTCBrJdc3eGiaGYCSJK4WK18JezKETuQq42NmqQreRDgSAriUYrKhxEplUCflH9Nb x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:SN1NAM02HT034; x-ms-traffictypediagnostic: SN1NAM02HT034: x-ms-office365-filtering-correlation-id: e2b9d4af-72f5-4e02-144f-08d57e9590b4 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM02HT034; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT034; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM02HT034; H:BN6PR22MB0771.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR22MB0771E96A09995D58148FBE5387C70BN6PR22MB0771namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2b9d4af-72f5-4e02-144f-08d57e9590b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 10:25:18.5115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT034 Archived-At: Subject: [Netslices] BoF thinking flow 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 10:25:22 -0000 --_000_BN6PR22MB0771E96A09995D58148FBE5387C70BN6PR22MB0771namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear All, According to ADs and chairs=92 suggestion and our previous discussion, I su= ggest we present COMS proposal during the BoF referring to the following th= inking flow based on the 3 main questions asked by Benoit. Q1 Clarifying the problem space First, introduce typical use cases of COMS -Use case 1: Combination of networking and computing resources -Use case 2: Technology diversity of network infrastructure The uses cases will help to derive the required problem space of COMS, i.e.= unified slice management in heterogeneous environment. Then a simple architecture view is presented to clarify the scope. The inte= rfaces/models COMS will work on should be precisely highlighted. -In scope: Service Model, Service Delivery Model, Information Mode= l -Out of scope: New forwarding technology, New device configuration= model, New network configuration model. Q2 Find out whether IETF is the right place for this type of top down appro= ach This question could be justified from two aspects. -External aspect (Top down): network slicing is indeed a top-down requireme= nt triggered by new vertical industry services. However, within IETF, it do= es not necessarily ask for new forwarding technology. Nevertheless, a slice= -level management must be provided by IETF to enable slicing capability amo= ng existing IETF forwarding technologies. -Internal aspect (Bottom up): Nowadays, existing IETF technologies either e= volves (e.g. DETNET) or naturally support (e.g. VPN) certain resource dedic= ation mechanism. This is in line with the concept of network slicing. Howev= er, A big problem is that IETF has little tools for cross-domain management= (draft-arkko-arch-virtualization-00). These two aspects meet a common convergence. Hence, COMS response to the co= nverged requirement, which is not a result from a solely top-down approach. Q3 How would that top down approach meet bottom up (being worked on in diff= erent WGs) The information model of COMS serves as the key element for the convergence= . It provides guidance for the design of service (deliver) model. And it al= so provides slice-level abstraction reference for existing IETF forwarding = technologies. This information model should be a comprehensive set of abstr= action. Each single technology typically refer to a subset of this informat= ion model towards slice-level abstraction process. During the BoF, this sho= uld be carefully explained. Based on the methodology above, we suggest the following organization of th= e presentation materials from the proponents. 1 presentation to answer Q1. Materials are derived from Use Case, Architect= ure and Problem statement drafts. 1 presentation to answer both Q2 and Q3. Materials are derived from Archite= cture and Information model drafts. I suggest that the above 2 presentations jointly ask for about 60 mins =96 = however the time arrangement is up to the Chairs to coordinate. No discussion on technical solution details are suggested during this BoF. Comments are extremely welcome! Best wishes, Liang --_000_BN6PR22MB0771E96A09995D58148FBE5387C70BN6PR22MB0771namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Dear All,

 

Accordin= g to ADs and chairs=92 suggestion and our previous discussion, I suggest we= present COMS proposal during the BoF referring to the following thinking flow based on the 3 main questions asked by Benoit.

 

Q1= Clarifying the problem space

 = ;

First= , introduce typical use cases of COMS

 = ;        -Use case 1: Combination of net= working and computing resources

 = ;        -Use case 2: Technology diversi= ty of network infrastructure

 = ;

The u= ses cases will help to derive the required problem space of COMS, i.e. unified slice management in heterogeneou= s environment.

 = ;

Then = a simple architecture view is presented to clarify the scope. The interface= s/models COMS will work on should be precisely highlighted.

 = ;        -In scope: Service Model, Servi= ce Delivery Model, Information Model

 = ;        -Out of scope: New forwarding t= echnology, New device configuration model, New network configuration model.=

 = ;

 = ;

Q2= Find out whether IETF is the right place for this type of top down approac= h

 = ;

This = question could be justified from two aspects.

 = ;

-Exte= rnal aspect (Top down): network slicing is indeed a top-down requirement tr= iggered by new vertical industry services. However, within IETF, it does not necessarily ask for new forwarding technology. Neverthel= ess, a slice-level management must be provided by IETF to enable slicing ca= pability among existing IETF forwarding technologies.

 = ;

-Inte= rnal aspect (Bottom up): Nowadays, existing IETF technologies either evolve= s (e.g. DETNET) or naturally support (e.g. VPN) certain resource dedication mechanism. This is in line with the concept of network slicing.= However, A big problem is that IETF has little tools for cross-domain mana= gement (draft-arkko-arch-virtualizatio= n-00).

 = ;

These= two aspects meet a common convergence. Hence, COMS response to the converg= ed requirement, which is not a result from a solely top-down approach.

 = ;

 = ;

Q3= How would that top down approach meet bottom up (being worked on in differ= ent WGs)

 

The info= rmation model of COMS serves as the key element for the convergence. It pro= vides guidance for the design of service (deliver) model. And it also provides slice-level abstraction reference for existing IETF f= orwarding technologies. This information model should be a comprehensive se= t of abstraction. Each single technology typically refer to a subset of thi= s information model towards slice-level abstraction process. During the BoF, this should be carefully explained.

 

Based on= the methodology above, we suggest the following organization of the presen= tation materials from the proponents.

 

1 = presentation to answer Q1. Materials are derived from Use Case, Architecture and Problem statement dr= afts.

 

1 = presentation to answer both Q2 and Q3. Materials are derived from Architecture and Information model drafts.

 

I sugges= t that the above 2 presentations jointly ask for about 60 mins =96 however = the time arrangement is up to the Chairs to coordinate.

 

No discu= ssion on technical solution details are suggested during this BoF.

 

Comments= are extremely welcome!

 

Best wis= hes,

Liang

 

--_000_BN6PR22MB0771E96A09995D58148FBE5387C70BN6PR22MB0771namp_--