Subject: Re: [netmod] Motivations for Structuring Models

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 1 Sep 2015 21:21:09 +0000

Hi Randy,

GDMO had some very powerful concepts.  The ability to separate definition hierarchy and containment hierarchy is indeed very powerful.  In many ways, it was ahead of its time.  The problem I see is that in the context of YANG (much simpler), I don't think the same concept of name bindings is applicable, really.  The difference is that in GDMO, MOC definitions did not make any statement about naming/ containment - this made it possible to separate containment out from other aspects of the model, cleanly, as they were orthogonal concepts.  In YANG, however, the definition of the containment structure is very much at the core of what is being defined as part of the model.  This is in part what makes it simple (and IMHO arguably also easier to read and consume - name bindings were arguably "harder to follow"), but there are some limitations that we are starting to bump into.  I think it is possible to address these (allowing the definition of mount points is one proposal), but the mechanism will need to be different from name bindings simply because the MOCs being linked are not defined "on their own", but as part of containment relationships intrinsically tied to their definitions.    

--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Monday, August 31, 2015 12:32 PM
To: [email-masked]
Subject: Re: [netmod] Motivations for Structuring Models

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Aug 31, 2015 8:04 AM
>To: Randy Presuhn <[email-masked]>, [email-masked]
>Subject: Re: [netmod] Motivations for Structuring Models
...
>> What GDMO did was to use a separate "NAME BINDING" construct to 
>> specify contexts in which instances might show up, allowing instances 
>> to be put in places that weren't even imagined when the original 
>> class definition was written.  Name bindings could be standardized, 
>> or be vendor or even product-specific, allowing the simplicity or 
>> complexity of a given system's instance tree to reflect the actual 
>> simplicity or complexity of that system, rather than requiring all 
>> systems to be structured for the worst case.
>
>How could this be expressed in YANG terms? (I tried to figure it out 
>myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT 
>Recommendation X.722).

A key concept of naming in that universe is "containment".
As with X.500 Directory or modern file systems, object instances are identified by their "distinguishing attribute(s)" within the context of a containing object.  The containment hierarchy within a given system generally reflects physical or logical containment.

Perhaps an example of how it could be used would help.
Suppose I've defined a "cpu" class and a "motherboard" class.
Further suppose that the "cpu" class has an attribute called "processorId" which is guaranteed to be unique within any naming context in which one might find more than one processor as immediate siblings. To say that a cpu could be identified
(named) within the context of a motherboard, one could say something like

cpuOfMotherboard NAME BINDING
     SUBORDINATE OBJECT CLASS cpu AND SUBCLASSES;
     NAMED BY SUPERIOR OBJECT CLASS motherboard AND SUBCLASSES;
     WITH ATTRIBUTE processorId;
     REGISTERED AS blah ;

This says that if one has located an instance of the motherboard class or any of its subclasses, instances of the cpu class that are immediately contained by it could be named within that context by their "processorId" attribute.  (A meta-model requirement is that any instantiable object class needs to have at least one attribute suitable for use in naming.)

Later, say we find that we need to model line cards with cpus, and those line cards (for whatever reason) are not derived from the motherboard class.  But we can still use the cpu class to manage those processors by adding another name binding:

cpuOfLinecard NAME BINDING
     SUBORDINATE OBJECT CLASS cpu AND SUBCLASSES;
     NAMED BY SUPERIOR OBJECT CLASS lineCard AND SUBCLASSES;
     WITH ATTRIBUTE processorId;
     REGISTERED AS blahblah ;

The point is that the class definition does not by itself determine where object instances might appear in a managed system; the supported name bindings determine where instances can be, whether (and how) they are created, and whether (and how) they can be deleted.

Is that a bit clearer?  No tidy way to do all of this in Yang-land is apparent to me - the (meta-) modeling assumptions seem too far removed, particularly with regard to inheritance and containment - but someone more creative than me might figure out how to do it.  But the point is not to ape GDMO.  The point is that this capability was included in that world to address real-world modeling needs, and we're seeing those same needs resurfacing here.

Randy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Sep 2015 02:01:04 +0200

I like the idea to step back and I actually only now found the time to
read this thread, from its very start all the way to GDMO. (This is
how my email client mutt sorted the thread for me. ;-)

I agree that we do have a big big data model coordination challenge in
the IETF (and soon beyond as other SDOs start to extend IETF models).
The sad truth is that addressing the challenge requires say 85% human
brains (good early reviews paired with followup communication plus and
some oversight and steering) and perhaps 10% better tools and likely
only 5% conventions (if at all). This being the IETF, we seem to focus
on the 10% and the 5% of the challenge first (probably because we know
how hard it is to allocate the human resources needed to work on the
85% of the challenge). Things get somewhat interesting if well
intended attempts to address the 2% of the challenge end up
destabilizing data models that were written to form basic building
blocks and that we have published (through a consensus process) and
that have been implemented and deployed and that were also designed to
provide a basis for other SDOs to extend them (I am talking about
ietf-interfaces, obviously).

Concerning the openconfig proposal that started this debate, I fail to
see how good model design becomes significantly easier by having a
rigid fixed plan where the models are to be rooted. Writing good
extensible models is hard, and it will always be. A big part of the
problem is (i) to identify a common model for a technology that can be
implemented across multiple devices and (ii) to future prove the model
such that extensions of the model can work easily (and predicting the
future remains difficult for most of us).

To me, it seems we have a software engineering challenge paired with
the specifics of working in a volunteer organization that in addition
has its own internal boundaries (called areas and working groups). We
also witness the differences of opinion between people who believe
small design teams for criticial pieces can help to solve the 85%
challenge and people who believe more agile processes should be used
(where you throw out rough ideas quickly and subsequently iteratively
revise them to either become a good idea or to remove them if they did
not fly). Unfortunately, the meta-debate between a more traditional
approach and a more agile approach does not help with the 85%
challenge, at least not in the near future.

So in conclusion, I believe the key problem is a lack of skilled human
resources that can help with the 85% of the challenge. So what can we
do? Trying to increase the amount of skilled human resources involved
in data model writing (training, mentoring, sharing of know-how - but
this is a long-term process) and making sure that the skilled human
resources we have stay productive by focusing work, by prioritizing
work, and by maintaining a constructive atmosphere.

Looking at the many things going on and the number of people deeply
technically involved in those things, I am increasingly concerned that
we loose focus and make no measurable progress on the things we want
to achieve.

/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: Randy Presuhn <[email-masked]>
Date: Tue, 1 Sep 2015 20:54:46 -0400 (EDT)

Hi -

>From: "Alexander Clemm (alex)" <[email-masked]>
>Sent: Sep 1, 2015 2:21 PM
>To: Randy Presuhn <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: RE: [netmod] Motivations for Structuring Models
>
>Hi Randy,
>
>GDMO had some very powerful concepts.  The ability to separate
>definition hierarchy and containment hierarchy is indeed very
>powerful.  In many ways, it was ahead of its time.  The problem
>I see is that in the context of YANG (much simpler), I don't
>think the same concept of name bindings is applicable, really.

Agreed.  At best it would probably be an ugly bolt-on;
some of the concerns it is intended to address are ones
that folks in the Netconf universe have tended to declare
out-of-scope, though as more people use these tools we'll
probably encounter more calls to revisit those long-held
assumptions.

> The difference is that in GDMO, MOC definitions did not make
> any statement about naming/ containment - this made it possible
> to separate containment out from other aspects of the model,
> cleanly, as they were orthogonal concepts.  In YANG, however,
> the definition of the containment structure is very much at
> the core of what is being defined as part of the model.

That's a polite way of saying the difficulty is architectural,
and *completely* fixing it would likely be disruptive.  I
think you're right.

>  This is in part what makes it simple (and IMHO arguably
> also easier to read and consume - name bindings were arguably
> "harder to follow"), but there are some limitations that we
> are starting to bump into.

They're essentially the same problems as arise with naming
in SNMP-land, with the same causes and consequences.

> I think it is possible to address these (allowing the
> definition of mount points is one proposal), but the
> mechanism will need to be different from name bindings
> simply because the MOCs being linked are not defined "on
> their own", but as part of containment relationships
> intrinsically tied to their definitions.    

I agree a mechanism to accomplish something like it will
likely be quite different.  Name bindings rely on a particular
characteristics of the metamodel and have specific consequences
for the management protocol, and both sets of assumptions don't
hold true in netconf/yang-land.  Trying to ape GDMO does not
seem like a productive route to me, given where Yang already
finds itself.

As long as naming is so closely bound to the definition,
however, use of the models is constrained in unhelpful ways.
Using mount points, at least as they've been formulated so far,
only addresses parts of the problem.  Whether that's going to
be good enough remains to be seen.  Without mount points or
something similar, what we currently have is only about as broken
as SNMP/SMI, and the industry got a lot of mileage out of that.

I suspect the debate over mount points will be the beginning of
netconf's counterpart to the "subagent wars" where the issue was
not so much one of "can this be made to work with(out) this
technology increment" than one of "what is the impact of this
technology increment on our overall development/deployment/operational
cost".

Randy