Subject: Re: [Netslices] Preliminary charter text for discussion

From: Xavier de Foy <[email-masked]>
Date: Thu, 1 Feb 2018 09:52:09 -0500

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 — 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 <[email-masked]> 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 also
> pointed out, that COMS will not duplicate these device model works.
>
>
> Best wishes
>
> Liang
>
>
> ------------------------------
> *From:* Leeyoung <[email-masked]>
> *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ús Bernardos Cano;
> [email-masked]
>
> *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:[email-masked]] *On Behalf Of *Liang
> GENG
> *Sent:* Wednesday, January 31, 2018 9:54 AM
> *To:* Jeff Tantsura <[email-masked]>; qiangli (D) <
> [email-masked]>; Xavier de Foy <[email-masked]>;
> Kiran.Makhijani <[email-masked]>
> *Cc:* Pedro Martinez-Julia <[email-masked]>; Carlos Jesús Bernardos
> Cano <[email-masked]>; [email-masked]
> *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 <[email-masked]> on behalf of Jeff Tantsura
> <[email-masked]>
> *Sent:* 31 January 2018 22:48:09
> *To:* qiangli (D); Xavier de Foy; Kiran.Makhijani
> *Cc:* Pedro Martinez-Julia; [email-masked]; Carlos Jesús 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
>
> *From: *"qiangli (D)" <[email-masked]>
> *Date: *Wednesday, January 31, 2018 at 02:53
> *To: *Jeff Tantsura <[email-masked]>, Xavier de Foy <
> [email-masked]>, "Kiran.Makhijani" <[email-masked]>
> *Cc: *Pedro Martinez-Julia <[email-masked]>, Carlos Jesús Bernardos
> Cano <[email-masked]>, "[email-masked]" <[email-masked]>
> *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 their
> extension/mapping work is better to be done in corresponding WGs. For those
> technologies that are not chartered by relevant WGs, the mapping/extension
> work could be done in COMS if needed. What do you think?
>
>
>
> Best regards,
>
> Cristina QIANG
>
>
>
> *From:* Netslices [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Jeff Tantsura
> *Sent:* Wednesday, January 31, 2018 5:09 AM
> *To:* Xavier de Foy <[email-masked]>; Kiran.Makhijani <
> [email-masked]>
> *Cc:* Pedro Martinez-Julia <[email-masked]>; Carlos Jesús Bernardos
> Cano <[email-masked]>; [email-masked]
> *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
> layers below where you’d be operating.
>
> You might use draft-ietf-opsawg-service-model-explained as a reference.
>
>
>
> Cheers,
>
> Jeff
>
> *From: *Netslices <[email-masked]> on behalf of Xavier de Foy
> <[email-masked]>
> *Date: *Tuesday, January 30, 2018 at 15:44
> *To: *"Kiran.Makhijani" <[email-masked]>
> *Cc: *Pedro Martinez-Julia <[email-masked]>, "[email-masked]" <
> [email-masked]>, Carlos Jesús Bernardos Cano <[email-masked]>
> *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 <
> [email-masked]> wrote:
>
> Xavier,
>
> This statement may need some additional clarity.
>
> “Study the mappings of technology independent network equipment
> configurations derived from the information model towards specific
> technologies and coordination with relevant WGs as needed.”
>
>
>
> I think what you are trying to say is that equipment configurations may
> need some work to provide slices related capabilities and support. Am I
> correct?
>
> If yes, then instead of use of “study”, we could say something to the
> effect “Identify and derive technology-independent network equipment
> configurations from the Information model in coordination with relevant WGs
> as needed”. This shows a clear deliverable.
>
>
>
> -Kiran
>
> *From: *Netslices <[email-masked]> on behalf of Xavier de Foy
> <[email-masked]>
> *Date: *Tuesday, January 30, 2018 at 7:22 AM
> *To: *Carlos Jesús Bernardos Cano <[email-masked]>
> *Cc: *Pedro Martinez-Julia <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Netslices] Preliminary charter text for discussion
>
>
>
> Thanks for clarifying the text Pedro. For reference and as base for future
> comments, here is a fixed version of the full text with your wording.
>
> Regards,
>
> Xavier.
>
>
> I. Context
>
> A network slice is a set of related infrastructure resources and service
> functions with qualities that respond to specific requirements, being able
> to cross multiple domains and use heterogeneous technologies. The goal of
> this group is to produce and promote a technology-independent and
> resource-centric management plane for network slices. Resources associated
> with a network slice are normally comprised of physical and logical
> connections in access, aggregation and backbone networks as well as
> computing and storage elements. Service functions associated with a network
> slice include network functions and network function chains pre-defined
> using corresponding network infrastructure elements.
>
> A "Network Slice" is realized using a collection of technologies spanning
> across data, control and management planes. Many of them rely on existing
> IETF technologies including both concluded and in-progress works such as:
> - Data plane: DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc.
> - Controller and/or control plane: ACTN, PCE and RSVP-TE (requiring LDP,
> BGP, OSPF awareness at level below) etc.
> - Management plane: YANG, OAM etc.
>
> The foundation of COMS is a technology-independent and resource-centric
> management plane. In reality, the network slice provider may have diverse
> technology choices in different domains due to geographical and commercial
> reasons. Therefore, COMS makes no assumption on which technology is used
> for specific domains. The goal of COMS is to define a common and
> inter-operative management mechanism, which is essential for the concept of
> network slicing being adopted in a system with heterogeneous network
> infrastructures and services functions. Major characteristics include:
> - Enabling composition of slices within a single or over multiple domains.
> - Allowing the operation and management of a network slice in a uniform
> manner, even when this network slice span multiple technology and/or
> administrative domains.
> - Enabling deployment of services over individual slices.
>
> II. Scope
>
> The WG will describe an overall architecture for network slicing. To
> manage network slices in a technology-independent manner, the network slice
> provider (NSP) will need to communicate with a network slice orchestrator
> (NSO) over a COMS Service Delivery Interface (SDI). The COMS SDI can also
> be used between network slice orchestrators, enabling hierarchical
> management through the notion of network slice subnets. Network slices will
> be leased to tenants, which will be able to use Customer Service Interface
> (CSI) exposed by the NS provider to run management tasks (e.g., on-demand
> measurement) within their slice instance under certain policies.
>
> The WG will describe an information model representing a network slice,
> accounting for the key elements used in network slices: connectivity,
> compute, storage resources, network and service functions — this
> information model includes the representation of managed objects and
> corresponding management and operations, will guide the design of data
> models on SDI and CSI and also will enable orchestrators interworking.
>
> The WG will specify requirements, operations and management
> functionalities on network slicing interfaces SDI and/or CSI including:
> 1 Network slice service profile, e.g. set by NSP over SDI, including
> high-level parameters for network infrastructures and service functions,
> together with their corresponding performance requirements.
> 2 Lifecycle management of network slice.
> 3 Other FCAPS functions. An important task of NSP is to aggregate faults,
> performance, status information and performance guarantees for certain
> services.
> 4 Slice composition or stitching in multi-domain environment.
> 5 Slice management by the tenant under the control of NSP, including
> deploying network services over a slice.
>
> The WG will specify requirements and functionalities of data plane
> entities as needed to enable the management of network slices. For example,
> this may include abstractions of policy control and enforcement, or gateway
> functionalities. The WG will also study the mapping between the abstract
> information model and managed entities, and will liaise with other IETF WGs
> as needed. However, the WG will not attempt to replicate data plane
> technologies including DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3
> etc.
>
> III. Deliverables
>
> WG deliverables are listed below and may be split in any number of
> documents as determined by the WG:
> - Problem statement and use cases for management of network slices.
> - Architecture of network slices.
> - Information model(s) and operations for network slices on topics
> described above in the scope section.
> - SDI and CSI interface specifications and relevant YANG models.
> - Study the mappings of technology independent network equipment
> configurations derived from the information model towards specific
> technologies and coordination with relevant WGs as needed.
>
> IV. Milestones
>
> Dec 2018     Problem Statement, use cases and architecture
> Dec 2018     Common information model and related YANG model
> June 2019    Network slices composition and interworking
> October 2019 FCAPS management functions and operations on network
>              slices including abstractions of policy control and
>              enforcement, or gateway functionalities.
> March 2020   SDI and CSI interface specifications and relevant YANG models
>
>
>
> _______________________________________________ Netslices mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/netslices
>

---

From: Leeyoung <[email-masked]>
Date: Thu, 1 Feb 2018 16:11:43 +0000

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 scope of COMS? I heard COMS would focus on customer service model and service delivery model, correct? Then network 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.

Thanks.
Young

From: Liang GENG [mailto:[email-masked]]
Sent: Thursday, February 01, 2018 12:23 AM
To: Leeyoung <[email-masked]>; Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Xavier de Foy <[email-masked]>; Kiran.Makhijani <[email-masked]>
Cc: Pedro Martinez-Julia <[email-masked]>; Carlos Jesús Bernardos Cano <[email-masked]>; [email-masked]
Subject: Re: [Netslices] Preliminary charter text for discussion

Hi Young,

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 <[email-masked]<mailto:[email-masked]>>
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ús Bernardos Cano; [email-masked]<mailto:[email-masked]>
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:[email-masked]] On Behalf Of Liang GENG
Sent: Wednesday, January 31, 2018 9:54 AM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; qiangli (D) <[email-masked]<mailto:[email-masked]>>; Xavier de Foy <[email-masked]<mailto:[email-masked]>>; Kiran.Makhijani <[email-masked]<mailto:[email-masked]>>
Cc: Pedro Martinez-Julia <[email-masked]<mailto:[email-masked]>>; Carlos Jesús Bernardos Cano <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> on behalf of Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Sent: 31 January 2018 22:48:09
To: qiangli (D); Xavier de Foy; Kiran.Makhijani
Cc: Pedro Martinez-Julia; [email-masked]<mailto:[email-masked]>; Carlos Jesús 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

From: "qiangli (D)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 31, 2018 at 02:53
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Xavier de Foy <[email-masked]<mailto:[email-masked]>>, "Kiran.Makhijani" <[email-masked]<mailto:[email-masked]>>
Cc: Pedro Martinez-Julia <[email-masked]<mailto:[email-masked]>>, Carlos Jesús Bernardos Cano <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 their extension/mapping work is better to be done in corresponding WGs. For those technologies that are not chartered by relevant WGs, the mapping/extension work could be done in COMS if needed. What do you think?

Best regards,

Cristina QIANG

From: Netslices [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Wednesday, January 31, 2018 5:09 AM
To: Xavier de Foy <[email-masked]<mailto:[email-masked]>>; Kiran.Makhijani <[email-masked]<mailto:[email-masked]>>
Cc: Pedro Martinez-Julia <[email-masked]<mailto:[email-masked]>>; Carlos Jesús Bernardos Cano <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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 layers below where you'd be operating.

Cheers,

Jeff

From: Netslices <[email-masked]<mailto:[email-masked]>> on behalf of Xavier de Foy <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 30, 2018 at 15:44
To: "Kiran.Makhijani" <[email-masked]<mailto:[email-masked]>>
Cc: Pedro Martinez-Julia <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Carlos Jesús Bernardos Cano <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Xavier,

"Study the mappings of technology independent network equipment configurations derived from the information model towards specific technologies and coordination with relevant WGs as needed."

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

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

-Kiran

From: Netslices <[email-masked]<mailto:[email-masked]>> on behalf of Xavier de Foy <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 30, 2018 at 7:22 AM
To: Carlos Jesús Bernardos Cano <[email-masked]<mailto:[email-masked]>>
Cc: Pedro Martinez-Julia <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netslices] Preliminary charter text for discussion

Thanks for clarifying the text Pedro. For reference and as base for future comments, here is a fixed version of the full text with your wording.

Regards,

Xavier.

I. Context

A network slice is a set of related infrastructure resources and service functions with qualities that respond to specific requirements, being able to cross multiple domains and use heterogeneous technologies. The goal of this group is to produce and promote a technology-independent and resource-centric management plane for network slices. Resources associated with a network slice are normally comprised of physical and logical connections in access, aggregation and backbone networks as well as computing and storage elements. Service functions associated with a network slice include network functions and network function chains pre-defined using corresponding network infrastructure elements.

A "Network Slice" is realized using a collection of technologies spanning across data, control and management planes. Many of them rely on existing IETF technologies including both concluded and in-progress works such as:
- Data plane: DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc.
- Controller and/or control plane: ACTN, PCE and RSVP-TE (requiring LDP, BGP, OSPF awareness at level below) etc.
- Management plane: YANG, OAM etc.

The foundation of COMS is a technology-independent and resource-centric management plane. In reality, the network slice provider may have diverse technology choices in different domains due to geographical and commercial reasons. Therefore, COMS makes no assumption on which technology is used for specific domains. The goal of COMS is to define a common and inter-operative management mechanism, which is essential for the concept of network slicing being adopted in a system with heterogeneous network infrastructures and services functions. Major characteristics include:
- Enabling composition of slices within a single or over multiple domains.
- Allowing the operation and management of a network slice in a uniform manner, even when this network slice span multiple technology and/or administrative domains.
- Enabling deployment of services over individual slices.

II. Scope

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

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

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

The WG will specify requirements and functionalities of data plane entities as needed to enable the management of network slices. For example, this may include abstractions of policy control and enforcement, or gateway functionalities. The WG will also study the mapping between the abstract information model and managed entities, and will liaise with other IETF WGs as needed. However, the WG will not attempt to replicate data plane technologies including DetNet, TE-Tunnels, MPLS, Segment Routing VPNs, NVO3 etc.

III. Deliverables

WG deliverables are listed below and may be split in any number of documents as determined by the WG:
- Problem statement and use cases for management of network slices.
- Architecture of network slices.
- Information model(s) and operations for network slices on topics described above in the scope section.
- SDI and CSI interface specifications and relevant YANG models.
- Study the mappings of technology independent network equipment configurations derived from the information model towards specific technologies and coordination with relevant WGs as needed.

IV. Milestones

_______________________________________________ Netslices mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/netslices

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 1 Feb 2018 16:13:52 +0000

+1,

this is exactly my comment of some days ago.

BR
Daniele

From: Netslices [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: giovedì 1 febbraio 2018 17:12
To: Liang GENG <[email-masked]>; Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Xavier de Foy <[email-masked]>; Kiran.Makhijani <[email-masked]>
Cc: Pedro Martinez-Julia <[email-masked]>; [email-masked]; Carlos Jesús Bernardos Cano <[email-masked]>
Subject: Re: [Netslices] Preliminary charter text for discussion

Hi Liang,

Thanks.
Young

To: Leeyoung <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; qiangli (D) <[email-masked]<mailto:[email-masked]>>; Xavier de Foy <[email-masked]<mailto:[email-masked]>>; Kiran.Makhijani <[email-masked]<mailto:[email-masked]>>

Hi Young,

Best wishes

Liang

Hi Liang,

Thanks.

Young

Hi Jeff and all,

Best wishes

Liang

Hi Christina,

Cheers,

Jeff

Hi Jeff,

Best regards,

Cristina QIANG

Hi,

Cheers,

Jeff

Best Regards,

Xavier.

Xavier,

-Kiran

Regards,

Xavier.

I. Context

II. Scope

III. Deliverables

IV. Milestones

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 01 Feb 2018 13:11:35 -0500

Hi,

/IAB shepherd hat on

First of all – thank you for continues work and improvements! 

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

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

“etc” - doesn’t belong in a charter in any form.

“

Please be precise in Deliverables:

“Study” – can’t be one, obliviously, it is part of the process, but not the result

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

Thanks!

Cheers,

Jeff

From: Daniele Ceccarelli <[email-masked]>
Date: Thursday, February 1, 2018 at 11:13
To: Leeyoung <[email-masked]>, Liang GENG <[email-masked]>, Jeff Tantsura <[email-masked]>, "qiangli (D)" <[email-masked]>, Xavier de Foy <[email-masked]>, "Kiran.Makhijani" <[email-masked]>
Cc: Pedro Martinez-Julia <[email-masked]>, "[email-masked]" <[email-masked]>, Carlos Jesús Bernardos Cano <[email-masked]>
Subject: RE: [Netslices] Preliminary charter text for discussion

+1,

BR
Daniele  

Hi Liang,

Thanks.

Young

Hi Young,

Best wishes

Liang

From: Leeyoung <[email-masked]>
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ús Bernardos Cano; [email-masked]
Subject: RE: [Netslices] Preliminary charter text for discussion 

Hi Liang,

Thanks.

Young

To: Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Xavier de Foy <[email-masked]>; Kiran.Makhijani <[email-masked]>

Hi Jeff and all,

Best wishes

Liang

From: Netslices <[email-masked]> on behalf of Jeff Tantsura <[email-masked]>
Sent: 31 January 2018 22:48:09
To: qiangli (D); Xavier de Foy; Kiran.Makhijani
Cc: Pedro Martinez-Julia; [email-masked]; Carlos Jesús 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

From: "qiangli (D)" <[email-masked]>
Date: Wednesday, January 31, 2018 at 02:53
To: Jeff Tantsura <[email-masked]>, Xavier de Foy <[email-masked]>, "Kiran.Makhijani" <[email-masked]>
Cc: Pedro Martinez-Julia <[email-masked]>, Carlos Jesús Bernardos Cano <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Netslices] Preliminary charter text for discussion

Hi Jeff,

Best regards,

Cristina QIANG

To: Xavier de Foy <[email-masked]>; Kiran.Makhijani <[email-masked]>

Hi,

I don’t think this is right thing to do, device models would be number of layers below where you’d be operating.

Cheers,

Jeff

From: Netslices <[email-masked]> on behalf of Xavier de Foy <[email-masked]>
Date: Tuesday, January 30, 2018 at 15:44
To: "Kiran.Makhijani" <[email-masked]>
Cc: Pedro Martinez-Julia <[email-masked]>, "[email-masked]" <[email-masked]>, Carlos Jesús Bernardos Cano <[email-masked]>
Subject: Re: [Netslices] Preliminary charter text for discussion

Best Regards,

Xavier.

On Tue, Jan 30, 2018 at 1:45 PM, Kiran.Makhijani <[email-masked]> wrote:

Xavier,

“Study the mappings of technology independent network equipment configurations derived from the information model towards specific technologies and coordination with relevant WGs as needed.”

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

-Kiran

From: Netslices <[email-masked]> on behalf of Xavier de Foy <[email-masked]>
Date: Tuesday, January 30, 2018 at 7:22 AM
To: Carlos Jesús Bernardos Cano <[email-masked]>
Cc: Pedro Martinez-Julia <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netslices] Preliminary charter text for discussion

Regards,

Xavier.

I. Context

II. Scope

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

III. Deliverables

IV. Milestones

_______________________________________________ Netslices mailing list [email-masked] https://www.ietf.org/mailman/listinfo/netslices

---

From: Xavier de Foy <[email-masked]>
Date: Thu, 1 Feb 2018 17:24:44 -0500

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

II. Scope

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

- Information and corresponding data models related to the mappings towards
specific data plane technologies and coordination with relevant WGs as
needed.

IV. Milestones

On Thu, Feb 1, 2018 at 1:11 PM, Jeff Tantsura <[email-masked]>
wrote:

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

---

From: Kiran.Makhijani <[email-masked]>
Date: Fri, 2 Feb 2018 02:11:15 +0000

+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,[email-masked],Carlos Jesús Bernardos Cano,
Date:2018-02-02 03:55:00
Subject:Re: [Netslices] Preliminary charter text for discussion

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

I. Context

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

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

II. Scope

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

On Thu, Feb 1, 2018 at 1:11 PM, Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

/IAB shepherd hat on

Thanks!

Cheers,
Jeff

---

From: Liang GENG <[email-masked]>
Date: Fri, 2 Feb 2018 02:14:33 +0000

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 space

In COMS, we endeavor to avoid any duplicated work also on network configuration model. We also encourage this been done preferably in individual existing WGs, in which the underlay 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 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-enabled systems).

This thought was base on the concerns 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 provide compulsory functionalities. It may be beneficial for COMS to look at generic 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 for future study and discussion as COMS proceeds.

Best wishes
Liang

________________________________
From: Daniele Ceccarelli <[email-masked]>
Sent: 02 February 2018 00:13:52
To: Leeyoung; Liang GENG; Jeff Tantsura; qiangli (D); Xavier de Foy; Kiran.Makhijani
Cc: Pedro Martinez-Julia; [email-masked]; Carlos Jesús Bernardos Cano
Subject: RE: [Netslices] Preliminary charter text for discussion

+1,

BR
Daniele

Hi Liang,

Thanks.

Young

Hi Young,

Best wishes

Liang

Hi Liang,

Thanks.

Young

Hi Jeff and all,

Best wishes

Liang

Hi Christina,

Cheers,

Jeff

Hi Jeff,

Best regards,

Cristina QIANG

Hi,

Cheers,

Jeff

Best Regards,

Xavier.

Xavier,

-Kiran

Regards,

Xavier.

I. Context

II. Scope

III. Deliverables

IV. Milestones

---

From: Liang GENG <[email-masked]>
Date: Fri, 2 Feb 2018 02:27:12 +0000

+1  agree with Jeff and Kiran.

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

________________________________
From: Xavier de Foy <[email-masked]>
Sent: 02 February 2018 06:24:44
To: Jeff Tantsura
Cc: Daniele Ceccarelli; Leeyoung; Liang GENG; qiangli (D); Kiran.Makhijani; Pedro Martinez-Julia; [email-masked]; Carlos Jesús Bernardos Cano
Subject: Re: [Netslices] Preliminary charter text for discussion

I. Context

II. Scope

III. Deliverables

IV. Milestones

Hi,

/IAB shepherd hat on

“

Thanks!

Cheers,

Jeff