Subject: [Netslices] Preliminary charter text for discussion

From: Xavier de Foy <[email-masked]>
Date: Sat, 27 Jan 2018 12:51:10 -0500

Hi all, a group of COMS proponents prepared a preliminary charter text,
taking into account recommendations collected when discussing the BoF
request for IETF 100
<https://trac.tools.ietf.org/bof/trac/wiki/BofIETF100#OperationsandManagement>
.

The recommendations were for:
1. better account of the 4 key elements used in COMS: connectivity,
compute, storage resources + network & service functions;
2. better description of the functional blocks and their positions in COMS;
3. better FCAPS coverage;
4. better coverage of the management of the data plane.

Please share your comments on this list by Feb 1st. Other COMS proponents
are also invited to provide additional information to help with the
discussion.

Best Regards,
Xavier, on behalf of COMS proponents.

I. Context

The Common Operations and Management on Network Slices (COMS) WG
standardizes slice-level operations and management of the resources
associated with a network slice. These resources include both network
infrastructures and service functions. More specifically, network
infrastructures are normally comprised of physical/logical connections in
access, aggregation and backbone networks as well as computing and storage
elements. Meantime, service functions include network functions and network
function chains which are pre-defined using corresponding network
infrastructure elements. Such resources may be parts of different domains
enabled by different technologies.

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

---

From: Alex Galis <[email-masked]>
Date: Sat, 27 Jan 2018 22:23:17 +0000

Hi All

Re: Common Operations and Management on Network Slices (COMS) BoF

In addition to the comments to the preliminary COMS netslices charter you are kindly requested to enlist as proponents of the BoF in case that you are interested in supporting this BoF and /or contributing / participating in the future work.

As such please provide by 1st February 2018 your name, affiliation and an email address for inclusion in the list of COMS NetSlicing BoF proponents on the 2nd February BoF request to IETF.

Thank you in advance
Best Regards
Alex

> On 27 Jan 2018, at 17:51, Xavier de Foy <[email-masked]> wrote:
> 
> Hi all, a group of COMS proponents prepared a preliminary charter text, taking into account recommendations collected when discussing the BoF request for IETF 100 <https://trac.tools.ietf.org/bof/trac/wiki/BofIETF100#OperationsandManagement>.
> 
> 1. better account of the 4 key elements used in COMS: connectivity, compute, storage resources + network & service functions; 
> Please share your comments on this list by Feb 1st. Other COMS proponents are also invited to provide additional information to help with the discussion.
> 
> Best Regards,
> The Common Operations and Management on Network Slices (COMS) WG standardizes slice-level operations and management of the resources associated with a network slice. These resources include both network infrastructures and service functions. More specifically, network infrastructures are normally comprised of physical/logical connections in access, aggregation and backbone networks as well as computing and storage elements. Meantime, service functions include network functions and network function chains which are pre-defined using corresponding network infrastructure elements. Such resources may be parts of different domains enabled by different technologies.
> 
> 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:
> - Controller and/or control plane: ACTN, PCE and RSVP-TE (requiring LDP, BGP, OSPF awareness at level below) 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:
> - 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.
> 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.
> 3 Other FCAPS functions. An important task of NSP is to aggregate faults, performance, status information and performance guarantees for certain services.
> 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:
> - Information model(s) and operations for network slices on topics described above in the scope section.
> - 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]
> https://www.ietf.org/mailman/listinfo/netslices

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 28 Jan 2018 19:22:06 +0100

Hi Xavier,

One quick comment (apologies for being inactive, and for maybe asking
about something you have already discussed) from a first read:

I think the Conext part should start with a 2-line definition of
network slice. This should provide the context of is understood as
network slice by the COMS WG.

Thanks,

Carlos

On Sat, 2018-01-27 at 12:51 -0500, Xavier de Foy wrote:
> Hi all, a group of COMS proponents prepared a preliminary charter
> text, taking into account recommendations collected when discussing
> the BoF request for IETF 100.
> 
> Please share your comments on this list by Feb 1st. Other COMS
> proponents are also invited to provide additional information to help
> with the discussion.
> 
> Best Regards,
> infrastructures are normally comprised of physical/logical
> connections in access, aggregation and backbone networks as well as
> computing and storage elements. Meantime, service functions include
> network functions and network function chains which are pre-defined
> using corresponding network infrastructure elements. Such resources
> may be parts of different domains enabled by different technologies.
> 
> 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:
> - Controller and/or control plane: ACTN, PCE and RSVP-TE (requiring
> LDP, BGP, OSPF awareness at level below) 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:
> - 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.
> 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:
> high-level parameters for network infrastructures and service
> functions, together with their corresponding performance
> requirements.
> 3 Other FCAPS functions. An important task of NSP is to aggregate
> faults, performance, status information and performance guarantees
> for certain services.
> 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
>

---

From: Xavier de Foy <[email-masked]>
Date: Mon, 29 Jan 2018 13:50:24 -0500

Thanks Carlos, do you think rewording the first paragraph like this helps?
(Re-using text from other proponents)

A network slice is a combination of infrastructure resources and service
functions constructed according to customized requirements. Such a network
slice may cross multiple domains using different infrastructure
technologies. The goal of this group is to produce a technology-independent
and resource-centric management plane for network slices. Infrastructure
resources associated with a network slice are normally comprised of
physical/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.

Regards,
Xavier.

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Tue, 30 Jan 2018 13:33:52 +0900

Dear Xavier et al.,

I have rephrased the charter to make it more concise and clear:

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.

Please consider using this text or part of it. Thank you very much.

Regards,
Pedro

-- 
Pedro Martinez-Julia
Network Science and Convergence Device Technology Laboratory
Network System Research Institute
National Institute of Information and Communications Technology (NICT)
4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan
Email: [email-masked]
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 30 Jan 2018 11:25:27 +0100

Hi Pedro, Xavier,

I like your proposal, thanks. I think now it is more clear.

Thanks,

Carlos

On Tue, 2018-01-30 at 13:33 +0900, Pedro Martinez-Julia wrote:
> > > > 2. better description of the functional blocks and their
> > > > positions in
> > > > COMS;
> > > > - Data plane: DetNet, TE-Tunnels, MPLS, Segment Routing VPNs,
> > > > NVO3
> > > > etc.
> > > > - Enabling composition of slices within a single or over
> > > > multiple
> > > > domains.
> > > > March 2020   SDI and CSI interface specifications and relevant
> > > > YANG
> > > > models
> > > >

---

From: Shunsuke Homma <[email-masked]>
Date: Tue, 30 Jan 2018 19:44:47 +0900

Hi Xavier, authors,

Thanks a lot for your greatly effort. IMO, as I mentioned in the 
notifying mail of slice gateway draft, defining requirements and 
fanctionalities of data plane are also important to clarifying whole 
architecture of network slicing, and thus I think the current charter 
text is in good shape.

Also, I have a small question about milestones. As far as I know, 
recently, several SDOs (e.g., 3GPP, TMF and ZSM) are studying network 
slicing framework. Do you have any plans or assumptions to cooperate 
with them? Also, are these milestones established depending on schedule 
of other SDOs?

Regards,

Shunsuke

On 2018/01/28 2:51, Xavier de Foy wrote:
> <https://trac.tools.ietf.org/bof/trac/wiki/BofIETF100#OperationsandManagement>.
> 
> infrastructures are normally comprised of physical/logical connections 
> in access, aggregation and backbone networks as well as computing and 
> storage elements. Meantime, service functions include network functions 
> and network function chains which are pre-defined using corresponding 
> network infrastructure elements. Such resources may be parts of 
> different domains enabled by different 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:
> 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:
> 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 
> functionalities on network slicing interfaces SDI and/or CSI including:
> faults, performance, status information and performance guarantees for 
> certain services.
> 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, 

-- 
----------------------------------
Shunsuke Homma
<[email-masked]>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------

---

From: Xavier de Foy <[email-masked]>
Date: Tue, 30 Jan 2018 10:20:50 -0500

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.

II. Scope

III. Deliverables

IV. Milestones

---

From: Kiran.Makhijani <[email-masked]>
Date: Tue, 30 Jan 2018 18:45:54 +0000

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.

II. Scope

III. Deliverables

IV. Milestones

---

From: Xavier de Foy <[email-masked]>
Date: Tue, 30 Jan 2018 15:44:04 -0500

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:

> “Study the mappings of technology independent network equipment
> 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
>
>
>
> manage network slices in a technology-independent manner, the network slice
> entities as needed to enable the management of network slices. For example,
> this may include abstractions of policy control and enforcement, or gateway

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 30 Jan 2018 16:09:25 -0500

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,

-Kiran

Regards,

Xavier.

I. Context

II. Scope

III. Deliverables

IV. Milestones

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

---

From: "qiangli (D)" <[email-masked]>
Date: Wed, 31 Jan 2018 07:53:21 +0000

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]>; 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,

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

On Tue, Jan 30, 2018 at 1:45 PM, Kiran.Makhijani <[email-masked]<mailto:[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.”

-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

I. Context

II. Scope

III. Deliverables

IV. Milestones

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

---

From: Alex Galis <[email-masked]>
Date: Wed, 31 Jan 2018 09:53:09 +0000

Hi Jeff and All

Thank you Jeff for your detailed observation.

I am with Jeff on the issue of device models which are outside the scope of COMS area as COMS (Common Operations and Management on Network Slices) focuses exclusively on slice-level operations and management of the network resources (i.e. not device resources) associated with a network slice.

We will review this item and would edit/ finalise accordingly the charter at today’s COMS proponents meeting.

Best Cheers and Regards 

Alex     

> On 31 Jan 2018, at 07:53, qiangli (D) <[email-masked]> wrote:
> 
> Hi Jeff,
>  
> From: Netslices [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Jeff Tantsura
> 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]>
> From: Netslices <[email-masked] <mailto:[email-masked]>> on behalf of Xavier de Foy <[email-masked] <mailto:[email-masked]>>
> 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]>>
> 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. <>
> On Tue, Jan 30, 2018 at 1:45 PM, Kiran.Makhijani <[email-masked] <mailto:[email-masked]>> wrote:
> Xavier,
> From: Netslices <[email-masked] <mailto:[email-masked]>> on behalf of Xavier de Foy <[email-masked] <mailto:[email-masked]>>
> 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]>>
> 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
> 
> _______________________________________________ Netslices mailing list [email-masked] <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>_______________________________________________
> Netslices mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 31 Jan 2018 09:48:09 -0500

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

Hi,

Cheers,

Jeff

Best Regards,

Xavier.

Xavier,

-Kiran

Regards,

Xavier.

I. Context

II. Scope

III. Deliverables

IV. Milestones

---

From: Liang GENG <[email-masked]>
Date: Wed, 31 Jan 2018 15:53:42 +0000

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,

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: Xavier de Foy <[email-masked]>
Date: Wed, 31 Jan 2018 11:46:29 -0500

Hi Jeff, thanks for pointing this out.

The focus of the group is really service delivery and customer service
models/interfaces, and activities that help defining those. The text needs
to be more clear. We propose to add text specifically saying that device
models are not within the scope of the group. Along this we tried to
clarify the last paragraph of the scope and the last deliverable (now split
in 2 topics).

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

*- 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.*
(...)

Best Regards,
Xavier

On Wed, Jan 31, 2018 at 10:53 AM, Liang GENG <[email-masked]> wrote:

> 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]] *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,
>
>
>
> *Date: *Tuesday, January 30, 2018 at 15:44
> *To: *"Kiran.Makhijani" <[email-masked]>
> [email-masked]>, Carlos Jesús Bernardos Cano <[email-masked]>
> _______________________________________________ Netslices mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/netslices
>

---

From: Leeyoung <[email-masked]>
Date: Wed, 31 Jan 2018 17:17:23 +0000

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,

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,

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

Best Regards,

Xavier.

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

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

---

From: Leeyoung <[email-masked]>
Date: Wed, 31 Jan 2018 17:24:36 +0000

Hi Xavier,

I agree with you on the SBI comment.

Thanks.
Young

From: Netslices [mailto:[email-masked]] On Behalf Of Xavier de Foy
Sent: Wednesday, January 31, 2018 10:46 AM
To: Liang GENG <[email-masked]>; Jeff Tantsura <[email-masked]>
Cc: Kiran.Makhijani <[email-masked]>; Pedro Martinez-Julia <[email-masked]>; Carlos Jesús Bernardos Cano <[email-masked]>; [email-masked]; qiangli (D) <[email-masked]>
Subject: Re: [Netslices] Preliminary charter text for discussion

The focus of the group is really service delivery and customer service models/interfaces, and activities that help defining those. The text needs to be more clear. We propose to add text specifically saying that device models are not within the scope of the group. Along this we tried to clarify the last paragraph of the scope and the last deliverable (now split in 2 topics).

(...)
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.
(...)
Best Regards,
Xavier

On Wed, Jan 31, 2018 at 10:53 AM, Liang GENG <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeff and all,

Best wishes

Liang

Hi Christina,

Cheers,

Jeff

Hi Jeff,

Best regards,

Cristina QIANG

From: Netslices [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jeff Tantsura

Hi,

Cheers,

Jeff

Best Regards,

Xavier.

Xavier,

-Kiran

Regards,

Xavier.

I. Context

II. Scope

III. Deliverables

IV. Milestones

---

From: Liang GENG <[email-masked]>
Date: Thu, 1 Feb 2018 06:23:13 +0000

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,

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