Re: [Netslices] Open Issue I: SouthBound/Mapping Interface

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

Hi Adrian,

Thanks a lot for your explanation, it's very useful to us. 

As you suggested, we regard the information model as an internal data structure which could be used to describe what a network slice looks like, of course also could be used to inform the design of data models on external interfaces. And what we really want to do is the resource-centric common management plane of network slices, include OAM, data models of interfaces, etc. 

Speaking of data models, I have some confusions about the NBI of Network Orchestrator and the Service (delivery) model. I understand their relation as during the ns requirement initialization phase, NBI data model and service (delivery) model are the same/similar thing. NBI data models has broader meaning in other phases, such as capacity exposure, monitored result report, etc. I am not sure if my understanding is correct or not.


Best regards,

Cristina QIANG

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Wednesday, January 10, 2018 5:29 AM
To: 'Liang GENG' <[e-mail]>om>; 'Daniele Ceccarelli' <[e-mail]>om>; qiangli (D) <[e-mail]>om>; 'Lei Wang' <[e-mail]>om>; 'NetSlices' <[e-mail]>
Subject: RE: [Netslices] Open Issue I: SouthBound/Mapping Interface

Sorry to jump in as a lurker, but co-author of draft-ietf-opsawg-service-model-explained that is about to be published as RFC
8309 I needed to comment.

Liang said:

> For Service Model, I am not sure - how much difference is there as to 
> Servic
Delivery Model. Might they be converged to one level in some cases?

You may converge components. For example, you could decide to build one component that provides the function of Service Orchestrator and Network Orchestrator. This a functional architecture, and no one is obliged to implement it as drawn.

When you converge components, the external interface between those components is no longer visible and so (of course?) does not need to be implemented. You
*could* continue to use the interface internal to your implementation but you might replace it with a function call, or not have it at all. It's a private implementation issue.

BUT, the conflation of Service Model and Service Delivery Model is, in general, an unwise thing to do. Of course, it may depend on the nature of the service being discussed. Some services could be so very, very simple that the two models are nested as Young suggests: "Service delivery model can be a subset of service model". For example, the customer details might be left out of the Service Delivery Model, and the service expectations in the Service Model might be narrowed down to explicit requirements present in the Service Delivery Model.

But for other services, it is quite likely that the Service Delivery Model contains more detail and specifics based on knowledge of the capabilities of the underlying network (without specifying the device configuration).

I think you would be wise to keep the distinction in terminology, and if it is valuable, you can inherit or share common YANG definitions.

Cheers,
Adrian

PS Cristina's figure shows "information model" in two places. In my opinion, an information model exists only on paper. It may be used to inform the design of a data model (for use on an external interface). And some implementations might choose to construct their internal data structures to follow the information model (or at least make sure that all of the information is present), but this is an implementation option- in practice (with a functional architecture, you can explain what the interfaces look like, but you do not need to (should not!) attempt to specify how the inside of one of your boxes behaves.