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

To add more comments: 

On the L2SM meeting, several people (4 or more) believed the 3 service delivery model examples ([I-D.dhjain-bess-bgp-l3vpn-yang], [I-D.ietf-bess-l2vpn-yang] and [I-D.ietf-bess-evpn-yang]) are actually device models.

I think both of the two I-Ds ([draft-ietf-netmod-yang-model-classification] and [draft-wu-opsawg-service-model-explained]) can check if those YANG models are device models or service models.

Regards,
Tianran

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: Friday, January 20, 2017 12:25 AM
> To: netmod@ietf.org
> Cc: opsawg@ietf.org;
> draft-ietf-netmod-yang-model-classification@ietf.org
> Subject: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
> 
> Hi,
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> In draft-wu-opsawg-service-model-explained Figure 4 we have tried to show
> how we (the authors) think L3SM fits into your classification. Here we place
> L3SM further up the layering stack.
> 
> [Apologies for not spotting this sooner. The citation
> "YANG-Data-Model-for-L3VPN-service-delivery" includes the term "service
> delivery" which I took to imply a different module.]
> 
> Thanks,
> Adrian
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg