Subject: [netmod] Fwd: New Version Notification for draft-bogdanovic-netmod-yang-model-classification-02.txt

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 24 Mar 2015 00:13:20 +0000

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bogdanovic-netmod-yang-model-classification-02.txt
Date: March 23, 2015 8:12:24 PM EDT
To: Dean Bogdanovic <[email-masked]<mailto:[email-masked]>>, Dean Bogdanovic <[email-masked]<mailto:[email-masked]>>, Benoit Claise <[email-masked]<mailto:[email-masked]>>, Carl Moberg <[email-masked]<mailto:[email-masked]>>, "Carl Moberg" <[email-masked]<mailto:[email-masked]>>, Benoit Claise <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-bogdanovic-netmod-yang-model-classification-02.txt
has been successfully submitted by Dean Bogdanovic and posted to the
IETF repository.

Name: draft-bogdanovic-netmod-yang-model-classification
Revision: 02
Title: YANG model classification
Document date: 2015-03-23
Group: Individual Submission
Pages: 12
URL:            http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-yang-model-classification-02.txt
Status:         https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-yang-model-classification/
Htmlized:       http://tools.ietf.org/html/draft-bogdanovic-netmod-yang-model-classification-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-bogdanovic-netmod-yang-model-classification-02

Abstract:
  YANG became de facto standard language for data modeling in the
  industry.  More and more groups uses YANG to create protocol and
  service models, both for configuration and operational models.
  Currently there is a lack of consistent terminology to categorize
  those models.  A consistent terminology would help models
  categorization, assist in the analysis the YANG data modeling effort
  in the IETF and in the industry, and facilitate the YANG-related
  discussions between different groups.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 26 Mar 2015 19:55:57 +0000

Dean et. all,

I said in the meeting that two levels of models - service and device, would
be sufficient.

After talking to operators, I am not so convinced, and here is why. First
of all, we are misrepresenting the term service models as operators see it.
A service is something that customer orders. That could be "I need 1G link
between these two end points and I want your gold level QoS service on
it.". Period. There is no mention of what IP address or which device this
will get configured on. These parameters, as we know are needed to
configure any service on a device. These service models reside in the BSS
layer.

So we need a modelling layer between the service level model and the device
(NE) level model. These models for the lack of better term can be called
network abstraction level models, which consists of models that constitute*
non-orderable network objects* e.g. the IP address of the end points where
the 1G service would be configured and the device-id where the QoS
parameters need to configured for the gold service. They model parameters
that customers typically do not specify or the BSS layer knows or cares
about. These network abstraction level models reside in the SDN controller
or the NETCONF client.

Then come the device level models that you and me are familiar with and are
the focus of most models being developed in IETF. The device level models
are models of features supported by the device and reside on the device
itself.

If we keep these three levels for model definitions, it will be easier to
classify where any particular model should reside.

On Mon, Mar 23, 2015 at 5:13 PM Dean Bogdanovic <[email-masked]> wrote:

>
>
> Begin forwarded message:
>
>  *From: *<[email-masked]>
>  *Subject: **New Version Notification for
> draft-bogdanovic-netmod-yang-model-classification-02.txt*
>  *Date: *March 23, 2015 8:12:24 PM EDT
>  *To: *Dean Bogdanovic <[email-masked]>, Dean Bogdanovic <
> [email-masked]>, Benoit Claise <[email-masked]>, Carl Moberg <
> [email-masked]>, "Carl Moberg" <[email-masked]>, Benoit Claise <
> [email-masked]>
>
>
> A new version of I-D,
> draft-bogdanovic-netmod-yang-model-classification-02.txt
> URL:
> http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-yang-model-classification-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-yang-model-classification/
> Htmlized:
> http://tools.ietf.org/html/draft-bogdanovic-netmod-yang-model-classification-02
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-bogdanovic-netmod-yang-model-classification-02
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>  _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Mar 2015 21:58:38 +0100

Good old TMN distinguished 'element management', 'network management',
'service management' (+ business management). These last century terms
may not be fancy anymore now that we prefer talking about controllers
and orchestrators but then we do not really seem to invent something
new either.

http://en.wikipedia.org/wiki/Telecommunications_Management_Network

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jan Lindblad <[email-masked]>
Date: Fri, 27 Mar 2015 11:23:09 +0100

Mahesh, Dean, all,

The word “service” has many meanings, of course. Service providers often understand the terms used in TM Forum: Customer Facing Service (CFS) and Resource Facing Service (RFS). CFS’ are what customers orders, e.g. “triple play”. They map to the “technical services” in the network. Like a package of Connectivity, mail, voip, video and Spotify. Each RFS may in turn be composed of lower level RFS’. Connectivity might consist of DNS, DHCP, NAT, basic firewall and internet access.

I think there isn’t much point in us starting to standardize the CFS structure. To the extent that this needs to be standardized, other organizations are already on to that. Instead, we should focus on the more common RFS types.

/jan

> I said in the meeting that two levels of models - service and device, would be sufficient.
> 
> After talking to operators, I am not so convinced, and here is why. First of all, we are misrepresenting the term service models as operators see it. A service is something that customer orders. That could be "I need 1G link between these two end points and I want your gold level QoS service on it.". Period. There is no mention of what IP address or which device this will get configured on. These parameters, as we know are needed to configure any service on a device. These service models reside in the BSS layer.
> 
> So we need a modelling layer between the service level model and the device (NE) level model. These models for the lack of better term can be called network abstraction level models, which consists of models that constitute non-orderable network objects e.g. the IP address of the end points where the 1G service would be configured and the device-id where the QoS parameters need to configured for the gold service. They model parameters that customers typically do not specify or the BSS layer knows or cares about. These network abstraction level models reside in the SDN controller or the NETCONF client.
> 
> Then come the device level models that you and me are familiar with and are the focus of most models being developed in IETF. The device level models are models of features supported by the device and reside on the device itself.
> 
> If we keep these three levels for model definitions, it will be easier to classify where any particular model should reside.