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

["Adrian Farrel" <[e-mail]>]

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