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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 19 Jan 2017 16:25:16 -0000

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

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 23 Jan 2017 09:32:36 +0000

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:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Friday, January 20, 2017 12:25 AM
> To: [email-masked]
> Cc: [email-masked];
> [email-masked]
> 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.
> 
> latter case - processing that we have called "service orchestration" but
> might (of course) be what leads to the operator poking the OSS/BSS.
> 
> 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
> 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.
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 30 Jan 2017 11:49:50 +0000

> On Jan 19, 2017, at 4:25 PM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi,
> 

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.
> 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.
>   model for Layer 3 IP VPN service configuration.

My question is where do you see the L3SM model 

above or below OSS?

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

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.

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

> delivery" which I took to imply a different module.]

No worries and sorry for late reply

Dean

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 30 Jan 2017 11:52:30 +0000

> On Jan 23, 2017, at 9:32 AM, Tianran Zhou <[email-masked]> wrote:
> 
> To add more comments: 
> 

The idea is that the classification drafts will provide guidelines for the authors to do their own classification. As mentioned in my previous email, the only people who will be able to do the right classification, are the module authors.

Please see I’m using distinction between module and model. Model can consist of multiple modules and in models you can get classification ambiguity. Modules are much more clear to classify.

Dean

> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod