Re: [Netslices] Summary of Open Issues

["qiangli (D)" <[e-mail]>]

Hi Xavier,

Sorry for the late response just back from vacation. I have checked some materials and hope the following figure and text could answer your question.

[cid:image001.png@01D383B3.43545020]


l  (Customer) Service Model describes a service as offered or delivered to a customer by a network operator [https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained<https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/>/<https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/>]

l  Service Delivery Model is used by a network operator to define and manage how a service is engineered in the network [https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained<https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/>/<https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/>]

l  Information Model is an abstraction and representation of the entities in a  managed environment, their properties, attributes and operations, and the way that they relate to each other [https<https://tools.ietf.org/html/rfc3444>://<https://tools.ietf.org/html/rfc3444>tools.ietf.org/html/rfc3444<https://tools.ietf.org/html/rfc3444>]

l  Data model is defined at a lower level of abstraction and include many details, include implementation and protocol specific constructs. There is a gray area where information models and data models overlap. The data model could be further divided into network configuration model and device configuration model [https://<https://tools.ietf.org/html/rfc3198>tools.ietf.org/html/rfc3198<https://tools.ietf.org/html/rfc3198>]

l  Network Configuration Model is used by a network orchestrator to instruct controllers (that may each be responsible for multiple network elements) how to configure parts of a network [https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained<https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/>/<https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/>]

l  Device Configuration Model is used by a controller to set parameters on an individual network element [https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained<https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/>/<https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/>]

The above figure illustrates how these models are used to initialize a network slice service request,  the service delivery model is really similar to the northbound interface at this time. However apart from the request initialization process, northbound interface has a broader meaning in such as capability exposure, monitoring result reporting, SLR/SLA negotiation, multi-domain cooperation, etc. IMHO.

Moreover, you may find there are two “information model” in the figure. I think COMS information model could be corresponded to the network orchestrator information model. As for the controller information model, a simple example would be ACTN information model.


Best regards,

Cristina QIANG

From: Xavier de Foy [mailto:[e-mail]]
Sent: Saturday, December 23, 2017 1:16 AM
To: qiangli (D) <[e-mail]>
Cc: [e-mail]
Subject: Re: [Netslices] Summary of Open Issues

Thanks Cristina, to answer some of your questions, I am interested to work with you and others on this, especially on #3 items. In particular the work we started on the COMS model (model and interconnection drafts) may be a starting point for some of the work there.

One thing I would like to understand better is the difference between service model and northbound interface data model. Is it fair to say that the service model would include for example the template (or blueprint) of a network slice, which would be used in a instantiation request, while the northbound data model would include the description of the actual instance of a network slice? If we foresee strong interrelations between those models, it could be useful to work jointly on them. In any case, it could be useful to provide more information to clarify their role and the relation between them in the charter text.

Best Regards,
Xavier.

On Fri, Dec 22, 2017 at 8:41 AM, qiangli (D) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Xavier and others,



Thank you for your comments. According to your suggestions, I have re-organized the potential work items as follows. Since the BoF proposal cut-off date is on early February, I guess it’s time to carry out action ASAP on some items without too many disagreements:



1.      The COMS Problem Statement - clearly provides the requirements from management work item, and the architecture of COMS.

2.      The COMS Use Cases - provides the motivating use cases as a basis for the work. [need a COMS focused use case draft? Any volunteers for new draft?  Has discussed under thread entitled “Open Issue III” ]

3.      Model(s) describing a slice or slice subnet instance and operations on a slice instance. [Any volunteers for new Service Model draft?—discussed under thread entitled “Open Issue II”; Any volunteers for new northbound interface data model draft?]

4.      The COMS mapping operation/interface to underlying technologies. [Has discussed under thread entitled “Open Issue I”]





Best regards,



Cristina QIANG



From: Xavier de Foy [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Friday, December 22, 2017 1:30 AM
To: qiangli (D) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Netslices] Summary of Open Issues



Hi Cristina,

  Thanks for bringing this to the list. I agree with this narrowed down approach, and would only have suggestions to simplify and shorten the work item list. For example 4-5-6 could be limited to 2: (4) model(s) describing a slice or slice subnet instance and operations on a slice instance; (5) mapping operation to underlying technologies. Also, I would suggest limiting the architecture effort as much as possible before IETF101, maybe even using the problem statement document for this effort for now.

  Best Regards,

Xavier



On Wed, Dec 13, 2017 at 3:25 AM, qiangli (D) <[e-mail]<mailto:[e-mail]>> wrote:

Hi All,



Before we carry out the next stage work, we would like to hear your opinion on future possible directions. We have preliminarily listed the following 6 potential work items for discussion, is there anything missing or inappropriate?



COMS (Common Operation and Management on network Slices) – a concrete topic narrowed down from NetSlicing, focuses on resource-oriented (including connectivity, computing, storage and other potential resources) common management plane, be able to shield the differences of multiple implementation techniques.



1.       The COMS Architecture - provides common terminology, basic architecture elements, resource abstractions and the inter-actions.

2.       The COMS Use Cases - provides the motivating use cases as a basis for the work.

3.       The COMS Problem Statement - clearly provides the requirements from management work item.

4.       The COMS Information Model/Template - Identifies managed objects needed to implement a network slice instance in a network slice aware system.

5.       The COMS Data Model - date models of northbound and southbound/mapping interfaces of a network slice aware system.

6.       The COMS Service Model – a service model mapping to an instance of a slice and its management.



Best regards,



Cristina QIANG





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