Re: [netmod] Question on draft-ietf-netmod-yang-model-classification

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

Hi Dean,

I've been processing your response and the continuing thread with you and Tianran.

> > We've been trying to ensure that draft-wu-opsawg-service-model-explained is
> > consistent with the latest version of
> > draft-ietf-netmod-yang-model-classification. In discussions with Tianran a
> > question has come up.
> >
> > In section 2 you have a nice definition of Network Service YANG Modules and
> > this definition maps nicely to our definition of "service delivery models".
> > Furthermore, your figure 1 shows Network Service YANG Modules on the
> > interface between OSS/BSS and the various network services.
> >
> > We have further defined "customer service models" at a higher layer still. That
> > is, on the interface to the customer. This (of course?) assumes that the
> > OSS/BSS is not customer code :-)
> >
> > However, your discussion of Network Service YANG Modules in section 2.1
> > seems slightly at odds, although this may be just ambiguity.
> >
> > For example, when you say, "Network Service YANG Modules describe the
> > characteristics of a service, as agreed upon with consumers of that service,"
> > this is not the same as, "This model is used in the discussion between a
> > customer and a service provide to describe the characteristics of a service."
> > That is, the former case could be arrived at after processing based on the
> > latter case - processing that we have called "service orchestration" but might
> > (of course) be what leads to the operator poking the OSS/BSS.
> 
> Adrian, I can see the ambiguity. The point of service module is to be consumed by
> the customer and there can be some modifications of the service module to
> adapt to the customer specifics.

So far I agree with your email and therefore not with your document. The OSS/BSS is not, IMHO, a tool used by the customer.

Please see Figure 3 in draft-wu-opsawg-service-model-explained-05.txt that shows the customer distinct from the OSS/BSS.

> > This might all be fine and good, but later in the same section you say "Network
> > Service YANG Modules define service models to be consumed by external
> > systems.
> > These modules are commonly designed, developed and deployed by network
> > infrastructure teams." And there you introduce two terms that are previously
> > undefined and only server to add ambiguity. Specifically "external to what?" I
> > could make and argument that the OSS is developed and deployed by network
> > infrastructure teams, ad also that the OSS is external to the network itself.
> 
> Agree that external systems are not defined and this text has to be clarified. The
> external systems can be OSS and BSS.

If we relabelled our "Service Delivery Model" as "Network Service Model" would that be consistent?

That is, in any case, to say that the OSS/BSS does not talk directly to the devices.

> > And, in between these two quoted pieces of text, you have...
> >
> >   As an example, the Network Service YANG Module defined in
> >   [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
> >   model for Layer 3 IP VPN service configuration.
> 
> My question is where do you see the L3SM model
> above or below OSS?

Well, look at the figure in section 5 of draft-ietf-l3sm-l3vpn-service-model-19.txt

It is logically higher, but OSS/BSS are not "in the flow" as they are legacy components in a softwarized world.
However, per our pictures, OSS/BSS should use the same set of models/modules as used by the "service orchestrator".

> Because there are some nuances in the service module, but at the end we
> decided not to do sub classification

Mutter, mutter.
In the document, you talk about "network service modules" not "service modules" and only trim to "service module" in the text implying that you always actually mean "network service module".

> one is the business and one technical service.
> 
> When i read the YANG-Data-Model-for-L3VPN-service-delivery, it looked to me
> much more like a technical model, then the business model, as didn’t see SLA
> definitions to track the business parameters of the service use.

It is certainly not a business model and does not include SLAs. Other people have far more experience working on these things (TMF, MEF, ...) and it is not an IETF core competence. Our intention is that our module can be augmented or accompanied by other modules in order to create a business model, acknowledging that commercial details (even including SLAs) will vary from one operator to another, but that the core technical description of the service can be (and, it turns out, is) common across multiple providers.

We even wrote text in Section 5 of draft-wu-opsawg-service-model-explained to help with this.

> > Per my other email, this reference needs to be fixed. But I struggle to see the
> > L3SM module as consistent with your figure. It may or may not be consistent
> > with your text dependent on the interpretation.
> 
> Sure, we can fix that reference, but the authors of L3SM module should do their
> own module classification, as they are the only ones that know the intent of the
> module.

That is fine. They can classify it, and they can use your classification system, but only if it can be understood, is meaningful, and fits what they are trying to achieve :-)

Your text currently says
   As an example, the Network Service YANG Module defined in
   [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
   model for Layer 3 IP VPN service configuration.

Your text and figures show "Network Service YANG Module" as being something that the OSS/BSS talks (presumably toward a network orchestrator?). Thus the L3SM module does not fit here. And that is why we wrote draft-wu-opsawg-service-model-explained and included Figure 4 to augment your figure.

And *finally*, Tianran is concerned that there may be confusion arising from whether the module we reference are "Network service modules", "service delivery modules", "network configuration modules", "network element modules", or "device configuration modules". So many terms, but presumably these modules don't fit into all of the categories! The list is:

[I-D.dhjain-bess-bgp-l3vpn-yang]
[I-D.ietf-bess-l2vpn-yang]
[I-D.ietf-bess-evpn-yang]

I wonder what type of module you think these are.

Cheers,
Adrian