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-boun...@ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, January 20, 2017 12:25 AM > To: netmod@ietf.org > Cc: ops...@ietf.org; > draft-ietf-netmod-yang-model-classificat...@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 > ops...@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
