Subject: [netmod] draft-openconfig-netmod-model-structure-00

From: Thomas D. Nadeau <[email-masked]>
Date: Fri, 13 Mar 2015 12:56:36 -0400

I wanted to kick off a discussion on this draft ahead of the meeting
as I have a few questions around this after reading the draft.

	First off, this kind of operational feedback is important for NETMOD 
and the IETF's Yang modeling efforts to be grounded in reality. Thank you for
pushing this draft out. 

	Second, my questions:

	1) how we address these issues in models that are already in-flight (or are RFCs) ?
	
	2) should existing models hold and be retrofit ?

	3) the recommendations that are in this draft might be best pushed into a "best practices of design" draft much like we have for SNMP MIBs on the MIB Doctor's wiki.

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Mar 2015 11:12:08 -0700

Hi,

I did not see the value in defining a set of NP containers to use for
structuring other data.  When new modules are added, the location(s)
within the conceptual data tree should be considered,
but publishing modules that just contain NP containers
as place-holders should not be done.

Is there some assumption that discovery is improved by picking
containers in advance of any content for those containers?
Is there some assumption that the client does not
need to analyse the module advertisements from the server
if these containers are used for data organization?

IMO, we would be better off with a YANG conformance model
and classification system that used schema information rather
than ad-hoc NP-containers that happen to be named in
a way that connotes functional cohesion.

Andy

On Fri, Mar 13, 2015 at 9:56 AM, Thomas D. Nadeau
<[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Anees Shaikh <[email-masked]>
Date: Sun, 15 Mar 2015 00:14:21 -0400

Tom, thanks for the comments.  The current draft develops a common
structure that composes existing models, but we don't specifically address
how existing models should be refactored to enable this.  We describe a few
options in the draft which would require (re)writing individual modules to
enable this sort of composition so that there is a well-known root.  We'd
certainly like to see existing in-flight models take this problem into
account, though I think we need to first define what a device tree looks
like.

I think part of the draft on how to write composable modules would be a
good fit for a best practices draft (along with parts of
draft-bierman-netmod-yang-conformance-04).  But we also would like to see a
common structure that enables clients to have well-defined paths to address
data for the entire device -- this latter part may be better as a separate
model.  Our current draft motivates and proposes a structure for models but
does not (yet) define an actual data model.

thanks.
-- Anees

On Fri, Mar 13, 2015 at 12:56 PM, Thomas D. Nadeau <[email-masked]>
wrote:

>         3) the recommendations that are in this draft might be best pushed
> into a "best practices of design" draft much like we have for SNMP MIBs on
> the MIB Doctor's wiki.
>
>         --Tom
>
>

---

From: Anees Shaikh <[email-masked]>
Date: Sun, 15 Mar 2015 02:33:09 -0400

Andy, my comments inline.   thanks.
-- Anees

> as place-holders should not be done.

As we say in the draft, the module described in the draft is not meant to
be an actual full device data model, but rather an illustration of a
structure for models to be composed into a usable whole.  A next step would
be to define the data model where models can be fit.

> if these containers are used for data organization?

Not necessarily -- discovery and advertisements are still important for a
client to understand capabilities of various individual models.  But the
premise here is that individual models, with no common way to use them
together aren't operationally useful for users who want to manage a
complete system.  And yes, I would say having a structure for the tree in
advance, and supported across implementations, is as important as defining
the content of individual models / containers.

> a way that connotes functional cohesion.

YANG conformance is important but does not address the problem of having a
common structure for the set of models comprising a managed device (for
example).  Section 4.1 in draft-bierman-netmod-yang-conformance-04 talks
about the related problem of defining revisions for a set of models -- we
are addressing the problem of what the structure of the set is.  Model
classification is also not addressing this problem -- the focus of that
work is on categorizing individual models. Our draft also discusses some
related issues of using a meta-model like this to categorize models
(functionally), and also build subsets of the device tree that are relevant
for different types of services.

> >         3) the recommendations that are in this draft might be best
> pushed into a "best practices of design" draft much like we have for SNMP
> MIBs on the MIB Doctor's wiki.
> >
> >         --Tom
> >
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 15 Mar 2015 10:11:48 +0100

> account, though I think we need to first define what a device tree looks

Which problem is solved by having a common root such as 'device'?

Note, this is what we have today to terms of published RFCs (in the
order of publication date):

+-- netconf-state (RFC 6022)
+-- nacm (RFC 6536)
+-- ipfix (RFC 6728)
+-- system (RFC 7317)
+-- system-state (RFC 7317)
+-- interfaces (RFC 7223)
+-- interfaces-state (RFC 7223)
+-- snmp (RFC 7407)

There is a certain 'foo' (config true) and 'foo-state' (config false)
pattern of top-level nodes evolving, you see it in some I-Ds as well
(but surely not all of them).

When it comes to which models form together a meaningful unit, I
believe we are talking about explicit conformance statements like Andy
proposed a while back. Such 'package' statements require to cut
through the schema tree (or forrest), I do not think that finding a
single nesting structure will be sufficient to solve that problem.

/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: Benoit Claise <[email-masked]>
Date: Thu, 19 Mar 2015 18:16:58 +0100

Dear authors,

A couple of high level points, next to Tom's questions.

With some many new YANG models these days, it's about time that we start 
organizing how all these models fit together. So thanks for this draft.
And it's great that this feedback come from operators.

I believe that you have some good points in your section 4.1 service 
catalog.

Note: the following tree hierarchy would have helped me reviewing the 
draft (even if I understand this is just an illustration at this point)

$ pyang -f tree model-structure.yang
module: model-structure
    +--rw device
       +--rw info
       |  +--rw device-type?   enumeration
       +--rw hardware
       +--rw system
       |  +--rw dns
       |  +--rw ntp
       |  +--rw dhcp
       |  +--rw syslog
       |  +--rw ssh
       |  +--rw stat-coll
       |  +--rw oam
       |  |  +--rw snmp
       |  |  +--rw cfm
       |  |  +--rw twamp
       |  +--rw aaa
       |  |  +--rw tacacs
       |  |  +--rw radius
       |  +--rw users
       +--rw interfaces
       |  +--rw ethernet
       |  |  +--rw aggregates
       |  |  +--rw vlans
       |  |  +--rw lfm
       |  +--rw sonet-sdh
       |  +--rw addressing
       |  |  +--rw ipv4
       |  |  |  +--rw vrrp
       |  |  +--rw ipv6
       |  |     +--rw vrrp
       |  +--rw tunnels
       +--rw acl
       +--rw qos
       +--rw logical-routers
          +--rw logical-router* [router-id]
             +--rw router-id            uint8
             +--rw router-name?         string
             +--rw layer-2-protocols
             |  +--rw vsi
             |  +--rw ipv6-ndp
             |  +--rw arp
             |  +--rw rstp
             |  +--rw lldp
             |  +--rw ptp
             +--rw layer-3-protocols
                +--rw global
                |  +--rw bgp
                |  +--rw igp
                |  |  +--rw is-is
                |  |  +--rw ospf
                |  |  |  +--rw ospf2
                |  |  |  +--rw ospf3
                |  |  +--rw igp-common
                |  +--rw bfd
                |  +--rw pim
                |  +--rw igmp
                |  +--rw static-routes
                |  +--rw mpls-te
                |     +--rw global
                |     +--rw signaling
                |     |  +--rw rsvp
                |     |  +--rw segment-routing
                |     |  +--rw ldp
                |     +--rw label-switched-paths
                |        +--rw constrained-path
                |        +--rw igp-congruent
                |        +--rw static
                +--rw vrf* [vrf-name]
                |  +--rw vrf-name         string
                |  +--rw bgp
                |  +--rw igp
                |  |  +--rw is-is
                |  |  +--rw ospf
                |  |  |  +--rw ospf2
                |  |  |  +--rw ospf3
                |  |  +--rw igp-common
                |  +--rw bfd
                |  +--rw pim
                |  +--rw igmp
                |  +--rw static-routes
                +--rw routing-policy
                   +--rw common
                   +--rw bgp-policy
                   +--rw igp-policy
                   +--rw vrf-policy

Regards, Benoit

---

From: Anees Shaikh <[email-masked]>
Date: Thu, 19 Mar 2015 15:52:07 -0400

Benoit, thanks for the comments -- I think you understand the motivation.
BTW, apologies, we only included snippets of each section of the tree in
the draft to make it easier to read.  We can add the full tree in an
appendix, per your suggestion.

For anyone else interested, the YANG code is also available in the
YangModels repo:
https://github.com/YangModels/yang/tree/master/experimental/openconfig/structure

thanks.
-- Anees

On Thu, Mar 19, 2015 at 1:16 PM, Benoit Claise <[email-masked]> wrote:

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Mar 2015 13:28:58 -0700

Hi,

I agree with Juergen that NP containers for 'device' and 'hardware'
seem too generic.

I am not in favor of moving any published modules.

Also curious why we would want a special "placeholder module"
with its own namespace and collection of mandatory top-level
NP-containers.

A server would implement this module and
then every other module in the world will augment this module?

The server will return all the empty NP-containers that
are not populated?  (Yes, according to the YANG module)

Every time somebody wants to add a new top-level node,
they have to update this module (and RFC)?

Andy

On Thu, Mar 19, 2015 at 12:52 PM, Anees Shaikh <[email-masked]> wrote:
> BTW, apologies, we only included snippets of each section of the tree in the
> draft to make it easier to read.  We can add the full tree in an appendix,
> per your suggestion.
>
>> 3) the recommendations that are in this draft might be best pushed into a
>> "best practices of design" draft much like we have for SNMP MIBs on the MIB
>> Doctor's wiki.
>>
>> --Tom
>>
>>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 19 Mar 2015 18:34:29 -0400

That is a good point. I think The Yang Doctors have a best practice that suggests this at the top of documents/drafts in the same way we did them for MIBs.

> On Mar 19, 2015:1:16 PM, at 1:16 PM, Benoit Claise <[email-masked]> wrote:
> 
> Dear authors,
> 
> With some many new YANG models these days, it's about time that we start organizing how all these models fit together. So thanks for this draft. 
> I believe that you have some good points in your section 4.1 service catalog. 
> 
> Note: the following tree hierarchy would have helped me reviewing the draft (even if I understand this is just an illustration at this point)
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>> 
> 
>