Re: [Netslices] Summary of Open Issues

[Xavier de Foy <[e-mail]>]

Thanks for the explanations Cristina and Kiran, sorry for this late
response. Basically I agree with your points, and plan to contribute to the
progress of the existing drafts, in particular the 2 existing drafts on
NBI/COMS model (draft-qiang-coms-netslicing-information-model and
draft-defoy-coms-subnet-interconnection). I agree the NSaaS model (is it a
customer service model?) discussed earlier in the thread may provide a use
case for NBI/COMS.

Best Regards,
Xavier.

On Mon, Jan 1, 2018 at 10:04 PM, qiangli (D) <[e-mail]> wrote:

> 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.
>
>
>
>
>
> 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/>
> ]
>
> 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/>
> ]
>
> 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]
>
> 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]
>
> 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/>
> ]
>
> l  D*evice 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/>
> ]
>
>
>
> 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]> 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]]
> *Sent:* Friday, December 22, 2017 1:30 AM
> *To:* qiangli (D) <[e-mail]>
> *Cc:* [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]> 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]
> https://www.ietf.org/mailman/listinfo/netslices
>
>
>
>
>