subject:"Re\: \[netmod\] Motivations for Structuring Models"

Re: [netmod] Motivations for Structuring Models

2015-09-09 Thread Andy Bierman

On Wed, Sep 9, 2015 at 2:43 PM, Benoit Claise  wrote:

> Andy,
>
> [taking on excerpt, out of context, to make a point]
>
> 1) As a consumer of YANG models, how do I identify the set of models that
>> provide a set of functionality? How do YANG model writers ensure that their
>> models are as easy to deal with as possible by having consistent modelling
>> approaches for config?
>>
>
> RTFM
>
> That type of language is neither polite, nor useful.
>
>
Sorry - Now that I know there are banned acronyms, I will write RTM instead.


> Regards, Benoit (OPS AD)
>

Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-09-09 Thread Benoit Claise


Andy,

[taking on excerpt, out of context, to make a point]


1) As a consumer of YANG models, how do I identify the set of
models that provide a set of functionality? How do YANG model
writers ensure that their models are as easy to deal with as
possible by having consistent modelling approaches for config?


RTFM

That type of language is neither polite, nor useful.

Regards, Benoit (OPS AD)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-09-01 Thread Randy Presuhn

Hi -

>From: "Alexander Clemm (alex)" <a...@cisco.com>
>Sent: Sep 1, 2015 2:21 PM
>To: Randy Presuhn <randy_pres...@mindspring.com>, "netmod@ietf.org" 
><netmod@ietf.org>
>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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-09-01 Thread Alexander Clemm (alex)

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 mechan
 ism 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:netmod-boun...@ietf.org] On Behalf Of Randy Presuhn
Sent: Monday, August 31, 2015 12:32 PM
To: netmod@ietf.org
Subject: Re: [netmod] Motivations for Structuring Models

Hi -

>From: Ladislav Lhotka <lho...@nic.cz>
>Sent: Aug 31, 2015 8:04 AM
>To: Randy Presuhn <randy_pres...@mindspring.com>, netmod@ietf.org
>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 a

Re: [netmod] Motivations for Structuring Models

2015-08-31 Thread Acee Lindem (acee)

Hi Mahesh,

I think that if we leave structure to the WGs, we will end up with models that 
have a WG-centric view with their corresponding model being at the root and any 
instantiation (logical-network-element, networking-instance, VRF, etc) being 
done within the model. Is this what we want? In routing, we had the benefit of 
the routing-cfg model also being considered and concluded the debate in favor 
of adopting the routing-cfg structure for the routing protocol models.

Thanks,
Acee

From: Mahesh Jethanandani 
<mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>>
Date: Friday, August 28, 2015 at 7:44 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Martin Bjorklund <m...@tail-f.com<mailto:m...@tail-f.com>>, 
"r...@rob.sh<mailto:r...@rob.sh>" <r...@rob.sh<mailto:r...@rob.sh>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] Motivations for Structuring Models

Acee,

This is going to become very interesting very quickly. Routing DT has decided 
to define a container for oam-protocols. LIME has decided it wants to define a 
generic YANG module for all OAM in draft-tissa-lime-yang-oam-model.

Which model does BFD augment? Or did you just kill the whole charter for LIME??

On Aug 28, 2015, at 6:20 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

Why doesn’t it help? In the next revision of the Routing YANG DT model,
we’ve switched from including specific models to defining classes of
models with identities. For example,

grouping oam-protocols {
 container oam-protocols {
 list oam-protocol {
 key "type";
 leaf type {
 type identityref {
 base oam-protocol-type;
 }
 mandatory true;
 description
 "The Operations, Administration, and


  Maintenance (OAM) protocol type, e.g., BFD,


  TWAMP, CFM, etc.";
 }
 description
 "List of OAM protocols configured for a


  networking instance.";
 }
 description
 "Container for list of OAM protocols configured for a


   networking instance.";
 }
 description
 "Grouping for OAM protocols configured for a


  networking instance.";
 }


Then the grouping is include the networking-instances.  By doing this, the
intent is that it would be evident as to where a particular model would be
found.

Mahesh Jethanandani
mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-31 Thread Robert Varga

On 08/28/2015 02:55 PM, Martin Bjorklund wrote:

But, as I have said before, the device abstraction is really
> >important - in the NMS/OSS/controller/whatever.  There we have a list
> >of devices, and each device has a name and meta-data and then its real
> >data, so for example we can have:
> >
> > /devices/device[name='rtr4']/ip
> > /devices/device[name='rtr4']/port
> >
> >and then we put all data models from the device under a common
> >container 'data':
> >
> > /devices/device[name='rtr4']/data/interface/
> > /devices/device[name='rtr4']/data/xconnect/
> >
> >If the device had a top-level container "device" this would have been:
> >
> > /devices/device[name='rtr4']/data/device/interfaces

>This approach*DOES*  logically structure configuration around the
>concept of a device.

Yes - in the NMS/OSS/controller -*not*  on the device!

I will add that at that layer a flat list is probably not going to be 
good enough in face of layers and federations. That is definitely a 
different issue and one where 'relocating' YANG models becomes important.

At that layer I could not care less if interfaces are enumerated in 
/interfaces or /device/interfaces -- I will end up relocating the models 
to fit the logical layout anyway, as I will need to have them placed in 
a structure which makes sense to my end users.

On the device layer, though, I have to say that /device is just a 
redundant layer of abstraction. Stuff augmenting it will fan out just as 
it does currently at /. Furthermore we will end up with 'structural 
models', which are somewhat of a first-class citizen and 'functionality 
models', which have to augment some structural model. I think end users 
care more about interaction with the latter.

From OpenDaylight implementation perspective, augmentations are 
slightly harder to work with, simply because their underlying concept 
does not have a language-level equivalent in Java (but it does in other 
languages). For this reason I would advocate not using a structural base 
unless it allows us to express a relationship which we couldn't do 
otherwise.

Bye,
Robert

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-31 Thread Robert Varga


On 2015-08-27 22:37, Rob Shakir wrote:
First off, we drew a picture [0] that showed the set of modules that 
we figured we might need. These break down into various bits of device 
functionality. To make this more accessible as something that could be 
shown in a draft, we expressed it in YANG and used pyang to draw out 
the tree.


The layout of the sets of functions that we have, and how they are 
grouped, is the important thing. The fact that we are configuring a 
device makes /device a good starting point. I think this is how you 
implemented NEDs in NCS too...?


Cheers,
r.

[0]: http://rob.sh/files/model-structure.pdf


A picture speaks a thousand words. As someone largely ignorant of 
routing operations, I have to ask, though: What is the value of having a 
set of logical routers each containing a set of VRFs? Wouldn't a 
structure having a 'global router' and a per-VRF logical router achieve 
the same thing (purely from modeling perspective)?


Thanks,
Robert

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-28 Thread Martin Bjorklund

Rob Shakir r...@rob.sh wrote:

Martin,

Apologies, I switched to a new client and, wow, yes, it's not
readable. I reported a bug and switched clients again... I *hope* this
one is more readable (and it was when I checked last).

Thank you Rob!

I'll put aside questions of whether the questions I'm asking are
completely fair. Apologies. They're written from my perspective of
problems I'm actually experiencing.
Martin Bjorklund mailto:m...@tail-f.com
August 27, 2015 at 15:45
1) As a consumer of YANG models, how do I identify the set of models
that provide a set of functionality?

So the idea is that this structure is defined in one module,
ietf-something-structure, right?

And then different oam protocol modules augment this structure?

How does this help you find the modules that augment this structure?

If I have to
rather look through / to find a subset of some ping functionality in
one module, and some in another, it's not clear to me how I even start
to find the right thing - because at the moment one type of ping lives
in one module, and another in a completely different one, even though
they're almost identical in terms of management plane interface.

I agree this sounds like a bad design. I absolutely agree that it is
necessary to look at how a generic X is handled before doing a model
for a specific instance of X. For example, it is probably useful to
define how interfaces in general are managed before creating a model
for ethernet interfaces. And maybe useful to think about how routing
protocols in general are handled before doing a model for bgp.

[...]

“Just read through the modules” is not acceptable answer when
considering making things easy to use for YANG model consumers.

But how does the top-level node /device (sorry, but I really have to
ask this) solve this problem? I *really* do not understand this.
Even with your solution you'd have a set of modules that augment this
structure, right? How do I know what these other modules are?

You didn't answer this question. So I repeated it above and below ;)

Now, I should add that the way I see your solution is a YANG module
that defines a structure of NP-containers. You (or was it Anees?)
then mentioned that we shouldn't focus so much on the *YANG module*;
it was the structure that was important.

First off, we drew a picture [0] that showed the set of modules that
we figured we might need. These break down into various bits of device
functionality. To make this more accessible as something that could be
shown in a draft, we expressed it in YANG and used pyang to draw out
the tree.

Thanks, this is what I remember you mentioned in Dallas.

But what does this really mean? Are you proposing:

1) to define one model ietf-something that contains this proposed
structure, which then other modules augment?

2) to define one single ietf model, period. no augments by the
ietf.

3) to define the structure more loosely in text, and use this
structure when new models are developed?

4) something else?

The layout of the sets of functions that we have, and how they are
grouped, is the important thing. The fact that we are configuring a
device makes /device a good starting point. I think this is how you
implemented NEDs in NCS too...?

No, each NED (device) is modelled according to its native model. So
for example the IOS NED has /interface, /ip, /xconnect, etc.

But, as I have said before, the device abstraction is really
important - in the NMS/OSS/controller/whatever. There we have a list
of devices, and each device has a name and meta-data and then its real
data, so for example we can have:

/devices/device[name='rtr4']/ip
/devices/device[name='rtr4']/port

and then we put all data models from the device under a common
container 'data':

/devices/device[name='rtr4']/data/interface/
/devices/device[name='rtr4']/data/xconnect/

If the device had a top-level container device this would have been:

/devices/device[name='rtr4']/data/device/interfaces

/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-28 Thread Martin Bjorklund

Andy Bierman a...@yumaworks.com wrote:
 Just because some people don't agree that the existing modules should be
 moved doesn't mean the NETMOD WG wants every module to create its
 own top-level node.

I agree, but I would go one step further and say that just b/c we
don't think that /device is a good idea doesn't mean that the NETMOD
WG wants every module to create its own top-level node.

(The point being that I think /device is a bad idea even if we didn't
have these 7 modules published)

 Create some organization for the 194 new modules.
 I completely agree with you that these modules should be written with
 a coherent development plan in mind.

+1

 Given that CLIs are being driven by YANG, I completely agree that
 understanding of the command hierarchy is useful.   I have no objections
 to the creation of a hierarchy or node placement plan or whatever.
 This is a non-issue.

+1  (although I think it will be challenging... I wouldn't try to
create one single node placement plan for *everything*; routers, app
servers, set-top boxes, radio base stations, just to mention a few
types of boxes that have YANG models today)


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-28 Thread Acee Lindem (acee)



On 8/28/15, 9:24 AM, Martin Bjorklund m...@tail-f.com wrote:

Acee Lindem (acee) a...@cisco.com wrote:
 
 
 On 8/28/15, 8:55 AM, netmod on behalf of Martin Bjorklund
 netmod-boun...@ietf.org on behalf of m...@tail-f.com wrote:
 
 Rob Shakir r...@rob.sh wrote:
  
  Hi Martin,
  
  Thanks for the reply.
   Martin Bjorklund mailto:m...@tail-f.com
   August 28, 2015 at 02:33
   So the idea is that this structure is defined in one module,
   ietf-something-structure, right?
  
   And then different oam protocol modules augment this structure?
  
   How does this help you find the modules that augment this
structure?
  Yes, this is the intention. By then generating the tree of the
overall
  structure, then I can see what different containers are created
  there. It's not perfect (and hey, this suggestion is a *draft* for a
  reason - but yet again, there are not alternatives) - but the fact
  that the modules augment a common path adds some information that
they
  are grouped to providing the same functionality, not
  disparate. ietf-routing does the same thing, it gives me the fact
that
  at /routing/routing-instance/routing-protocols there are a bunch of
  control-plane protocols that are related to routing.
 
 Ok.  So your proposal doesn't help with the problem of locating
 relevant YANG modules, but once their located, it is easier to find
 the ones related to a specific function, b/c they would augment a
 common path.  Is this what you mean?
 
 Why doesn’t it help? In the next revision of the Routing YANG DT model,
 we’ve switched from including specific models to defining classes of
 models with identities. For example,
 
  grouping oam-protocols {
   container oam-protocols {
   list oam-protocol {
   key type;
   leaf type {
   type identityref {
   base oam-protocol-type;
   }
   mandatory true;
   description
   The Operations, Administration, and
 
 
Maintenance (OAM) protocol type, e.g., BFD,
 
 
TWAMP, CFM, etc.;
   }
   description
   List of OAM protocols configured for a
 
 
networking instance.;
   }
   description
   Container for list of OAM protocols configured for a
 
 
 networking instance.;
   }
   description
   Grouping for OAM protocols configured for a
 
 
networking instance.;
   }
 
 
 Then the grouping is include the networking-instances.  By doing this,
the
 intent is that it would be evident as to where a particular model would
be
 found. 

Now I am a user of YANG models.  I am searching for the YANG module
that defines OAM for BFD.  How does your model above help me find it?

If one can envision a function to list the schema rather than the actual
config data, you could retrieve the schema for the oam-protocols
container. It would seem reasonable to support such a function.

Thanks,
Acee




/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-28 Thread Ladislav Lhotka


 On 27 Aug 2015, at 19:49, Rob Shakir r...@rob.sh wrote:
 
 Lada,
 
 
 
 On August 27, 2015 at 12:54:39, Ladislav Lhotka (lho...@nic.cz) wrote:
 
 We certainly need *some* structure, and since there was a requirement to 
 support multiple routing instances, a list of them seems natural. 
 Great, we agree that we need some structure like we have for routing 
 elsewhere.
 
 Can you point me towards any proposal other than 
 draft-openconfig-netmod-model-structure or 
 draft-rtgyangdt-rtgwg-device-model–00 for this structure?

The current structure was pretty much a direct consequence of the previous 
NETMOD charter:

http://datatracker.ietf.org/doc/charter-ietf-netmod/06/

And as I said, we did consider having some universal top-level structure but we 
rejected this idea, mainly because every other module would then have to be an 
augment.

 
 Already, implementors are having problems with this - because existing 
 modules that are pretty mature (ietf-bgp for example), need more 
 functionality than is in ietf-routing to make usable multi-VRF systems, let 
 alone multi-routing-instance. If there were some structure, we could 
 understand how these models need to be augmented to support the use cases. 
 I’ll come back to the case of how I configure something that is a L2 virtual 
 forwarding instance, that uses has a L3 IP interface within it.

ietf-routing is still open for any changes, but I think it has nothing to do 
with the presence or absence of /device.

 
 On the latter comments in your mail, I place little importance on obsoleting 
 existing RFCs, I care about:

I would concur that the rules for updating published modules are too strict for 
this stage, and that more flexibility is needed atleast until the YANG 
landscape stabilises.

 
   • Primarily: whether the existing models let me configure things that I 
 need to on my network (or form a suitable base for doing so).
   • Secondary: impact to existing implementations where these models are 
 actually usable to some external consumer.

What I and others don’t understand is how the /device container helps, or the 
current flat structure prevents, reaching these aims.

Cheers, Lada

 Kind regards,
 r.
 
 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-28 Thread Rob Shakir



Hi Martin,

Thanks for the reply.

Martin Bjorklund mailto:m...@tail-f.com
August 28, 2015 at 02:33
So the idea is that this structure is defined in one module,
ietf-something-structure, right?

And then different oam protocol modules augment this structure?

How does this help you find the modules that augment this structure?
Yes, this is the intention. By then generating the tree of the overall 
structure, then I can see what different containers are created there. 
It's not perfect (and hey, this suggestion is a *draft* for a reason - 
but yet again, there are not alternatives) - but the fact that the 
modules augment a common path adds some information that they are 
grouped to providing the same functionality, not disparate. ietf-routing 
does the same thing, it gives me the fact that at 
/routing/routing-instance/routing-protocols there are a bunch of 
control-plane protocols that are related to routing.

“Just read through the modules” is not acceptable answer when
considering making things easy to use for YANG model consumers.

But how does the top-level node /device (sorry, but I really have to
ask this) solve this problem?  I *really* do not understand this.
Even with your solution you'd have a set of modules that augment this
structure, right?  How do I know what these other modules are?

You didn't answer this question.  So I repeated it above and below ;)
Right. There was really a reason NOT to answer it. /device is 
irrelevant. It does not matter - it is simply how *this proposal* 
chooses to group things, based on the fact that we think that operators 
logically configure devices when dealing with these models. From your 
comments on NCS below, it seems to me that if we'd made this a list, 
then there'd be significantly less concern? I just can't understand why 
this is something to get hung up on. If /device isn't the right root, 
please show me what is - and WHY it's better.


Structuring configuration and operational around some idea that all the 
configuration belongs to a physical device seems very, very logical to 
me. Further defining groups so that we have an understanding of how to 
build a coherent set of models for the functionalities required of that 
device seems a very clear next step after this.

Thanks, this is what I remember you mentioned in Dallas.

But what does this really mean?  Are you proposing:

   1)  to define one model ietf-something that contains this proposed
   structure, which then other modules augment?

   2)  to define one single ietf model, period.  no augments by the
   ietf.

   3)  to define the structure more loosely in text, and use this
   structure when new models are developed?

   4)  something else?
As part of iterating on this idea, we are working to understand the 
practicalities of (1). This is exactly the approach that ietf-routing is 
taking for routing protocol modules.

The layout of the sets of functions that we have, and how they are
grouped, is the important thing. The fact that we are configuring a
device makes /device a good starting point. I think this is how you
implemented NEDs in NCS too...?

No, each NED (device) is modelled according to its native model.  So
for example the IOS NED has /interface, /ip, /xconnect, etc.

But, as I have said before, the device abstraction is really
important - in the NMS/OSS/controller/whatever.  There we have a list
of devices, and each device has a name and meta-data and then its real
data, so for example we can have:

/devices/device[name='rtr4']/ip
/devices/device[name='rtr4']/port

and then we put all data models from the device under a common
container 'data':

/devices/device[name='rtr4']/data/interface/
/devices/device[name='rtr4']/data/xconnect/

If the device had a top-level container device this would have been:

/devices/device[name='rtr4']/data/device/interfaces
This approach *DOES* logically structure configuration around the 
concept of a device. If we are really just debating whether 
/devices/device is a list or whether it's a container, I'm even more 
confused than I was before. Please see my earlier comment.


Cheers,
r.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-28 Thread Martin Bjorklund

Rob Shakir r...@rob.sh wrote:
 Martin,
 
 We are almost certainly not on the same page as to what we're
 debating.
  Martin Bjorklund mailto:m...@tail-f.com
  August 28, 2015 at 08:55
  https://www.postbox-inc.com/?utm_source=emailutm_medium=sumlinkutm_campaign=reach
 
  Ok.  So your proposal doesn't help with the problem of locating
  relevant YANG modules, but once their located, it is easier to find
  the ones related to a specific function, b/c they would augment a
  common path.  Is this what you mean?
 Having a structure to the way that the tree is defined helps a
 developer trying to consume functions find the relevant
 functionality. The model-writer needs to be aware of this structure. I
 think there is an important difference between model writer (not very
 many of these), and model consumer (lots of these).

I don't understand this answer (or maybe you misunderstood my question?).

  But this is the what we have been arguing about!  Remove /device and
  we can put this behind us and move forward.
 
 So, if I take openconfig-model-structure and make it look like:
 
 module: model-structure [NB: trimmed for legibility.]
   +--rw info
   +--rw hardware
   +--rw system
   +--rw interfaces
   +--rw acl
   +--rw qos
   +--rw logical-routers
  +--rw logical-router* [router-id]
 +--rw router-iduint8
 +--rw router-name? string
 +--rw layer-2-protocols
 +--rw layer-3-protocols
+--rw vrf* [vrf-name]
+--rw routing-policy
 
 Then you have no objection to this approach? Even though it will
 *still* very likely obsolete RFC'd models, which don't fit into the
 structure.

I didn't say that I agree with all nodes in the structure, but I do
agree that a structure for common things (like intrefaces, routing
protocols, oam functions etc) is useful.

RFC 7223 already defines /interfaces and RFC 7317 defines /system, so
I assume they can be kept.  Unless of course you think the namespace
is important.

As for logical-routers, see the other thread.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Nadeau Thomas


 On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman a...@yumaworks.com wrote:
 
 
 
 On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir r...@rob.sh 
 mailto:r...@rob.sh wrote:
 
 Andy,
 
 Apologies, I don’t understand how your mail answers the questions that I 
 posed.
 
 On August 27, 2015 at 12:25:20, Andy Bierman (a...@yumaworks.com 
 mailto:a...@yumaworks.com) wrote:
 
 A whole lots of words here, but I am still confused why /device is better 
 than /
 for solving your data model awareness problem.
 
 Please re-read my email - here’s the single statement where I said that this 
 was NOT the discussion that I think is important:
 
 It strikes me that there is a need to take a step back from the debate of 
 whether /device is a good idea or not.
 
 
 I’m not sure how this could be clearer.
 
 
 Sorry -- are you suggesting that maybe /device adds no value beyond /?
 If so, I agree.
 
  
 YANG is no different than any other part of the source code.
 Reusable YANG is just as likely or unlikely as reusable C,
 depending on how aware people are of the existing code base.
 
 Which OAM? Read the modules and decide. No magic there.
 How would /device vs / (as the first node) help you figure this out?
 
 Nobody is objecting at all to creating structure for the new modules.
 If /device has siblings, then let's see them in the uber-tree.
 The objection is to adding in a useless layer, and moving existing
 data nodes, which breaks existing implementations of all those data nodes.
 
 Please suggest an alternate approach to the one that is laid out in 
 draft-openconfig-netmod-model-structure that you believe will help with the 
 two problems that I raised. I’ll rephrase them here with less explanation, 
 albeit that comes with less clarity.
 
 1) As a consumer of YANG models, how do I identify the set of models that 
 provide a set of functionality? How do YANG model writers ensure that their 
 models are as easy to deal with as possible by having consistent modelling 
 approaches for config?
 
 
 RTFM

Andy, 

While it might be frustrating, coming to an understanding of what the 
problem is or might be, and then looking at
why the existing mechanisms/models or additional ones solve these requirements 
(or do not) is what is at hand.  I think everyone agreed
at the interim meeting that the requirements were clear and sound.  This is 
detailed in the meeting minutes.  If anyone disputes this,
I am happy to do an official WG call for consensus on these specifics, but 
given the unanimous agreement at the meeting, I did
not feel that it was necessary to do this.  Based on that, the next question 
is: are these problems solved with what is here today, 
or do we need another approach/es.  Rob is clearly not an idiot and is asking 
for detailed reasons why you and others
believe what he/OpenConfig have proposed is insufficient. Please be as 
considerate and constructive as he has been in asking his
questions when you address them. 

—Tom (Speaking as Co-chair)


 2) As a creator of YANG mode
 
 ls, how do I know the targets for references such that I capture references 
 to the elements that I want, given there is no currently defined structure?
 
 
 
 The modules you are using have data locations defined.
 In order to define YANG data (with YANG 1.0 or 1.1)
 a top-level data node or augment-stmt will be present specifying the 
 /path/from/root
 
 How do you know where data is that has not been defined yet?
 You don't and YANG has no ability to reference undefined data anyway.
 
 
 “Just read through the modules” is not acceptable answer when considering 
 making things easy to use for YANG model consumers. I want to have things 
 that are logical to humans such that they can easily adopt YANG-based 
 netmgmt. If they need to adopt the ecosystem by having to use hodgepodge 
 approaches, then this feels like we are fundamentally missing an opportunity 
 to simplify things.
 
 
 
 Why isn't RTFM good enough?
 Is there some expectation that just /the/path/from/root is enough
 to make somebody an expert in managing some feature or an expert
 in writing new YANG modules?
 
 Additional tools outside the scope of IETF standardization work are needed
 to make development easier.
 
 Nothing whatsoever is stopping the routing area from defining some structure
 for new modules.  Pick whatever you like.
 
 The only pushback is wrt/ obsoleting existing RFC modules and moving the
 data nodes in them to a different location. Some of us do not agree that
 a problem has been demonstrated that warrants starting over for these RFCs.
 
 
 I want to make sure that we DO have re-usable YANG - like we have re-usable 
 code elsewhere. In my experience this is done elsewhere by defining 
 conventions that ensure that this is the case. 
 
 
 Regards,
 r.
 
 
 Andy
 
 ___
 netmod mailing list
 netmod@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Rob Shakir

Hi Andy,

I’m struggling with this debate.
On August 27, 2015 at 13:59:55, Andy Bierman (a...@yumaworks.com) wrote:


Sorry -- are you suggesting that maybe /device adds no value beyond /?
If so, I agree.
No, I am suggesting that should understand what the alternatives to solving 
issues are, before moving on to debating the merits of a particular solution 
that has nothing to compare and contrast against.

One container does not add value, the structure (which happens to start with 
/device in ONE proposal, to which there are no alternates) is what matters. 
Unfortunately you seem to be stuck on this container. Please ignore it and 
focus on the problems I defined.

 RTFM
Great. So, I need to go and write a bunch of different implementations of how 
to set up a ping, and trawl through a huge number of roots to find things that 
are related. If this is the approach we take with IETF modules, then they will 
be worse to use than the existing configuration approaches that we have. At 
least the vendor specific ones have some form of logic as to how they are 
usable to consumers.

2) As a creator of YANG models, how do I know the targets for references such 
that I capture references to the elements that I want, given there is no 
currently defined structure?

The modules you are using have data locations defined.
In order to define YANG data (with YANG 1.0 or 1.1)
a top-level data node or augment-stmt will be present specifying the 
/path/from/root

How do you know where data is that has not been defined yet?
You don't and YANG has no ability to reference undefined data anyway.
Consider VRRP ‘tracking’. I want to be able to add some form of new thing that 
VRRP might track. If we’ve defined a structure that says that there is some 
list of ‘tracking-objects’ that I can leafref to, then my new OAM mechanism can 
augment there. If there is no such structure, then we cannot do that, and 
rather the VRRF model only leafrefs to the currently known paths (my ‘track’ 
leaf has explicit leafref to a subset of ‘ping’ and known continuity checks 
when I wrote the module). Adding the new OAM mechanism then means a new version 
of the VRRP module - which seems suboptimal. The first approach is cleaner, but 
needs someone to define the structure such that we get it right.

Nothing whatsoever is stopping the routing area from defining some structure
for new modules.  Pick whatever you like.

The only pushback is wrt/ obsoleting existing RFC modules and moving the
data nodes in them to a different location. Some of us do not agree that
a problem has been demonstrated that warrants starting over for these RFCs.
Defining structure with arbitrary subsets of the tree doesn’t help! As an 
operator I want to be able to configure a device, because this is what my 
network is built from. Not IETF areas.

Do you suggest that the existing models are placed as a constraint on any new 
work in YANG? If so, I’d be grateful if you can point out to me what the 
precedent is to show that they are useful in the real world?

Kind regards,
r.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Rob Shakir

Hi Lada,

Thanks for the reply.
On August 27, 2015 at 11:21:18, Ladislav Lhotka (lho...@nic.cz) wrote:

This one is actually easy to explain, exactly as the top-level container 
interfaces in ietf-interfaces: it is a courtesy to XML encoding. 
Apologies, I’m not sure my question was clear enough. The point was, why do we 
need a model that defines a structure for routing if one that defines a 
structure for device is not useful?

Thanks,
r
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Rob Shakir

Hi Andy,

On August 27, 2015 at 14:48:58, Andy Bierman (a...@yumaworks.com) wrote:

Did you really think that just because we created a nice DML that
somehow you would not need to know about the topic of your YANG module?
I actually have heard this complaint from some people.  Great.  How does
YANG help?  I still have to be an expert in MPLS to write a YANG module
that manages MPLS.  Yep.  That's right.  Nothing in YANG helps you
know more than you do now about specific networking technologies.
No, I didn’t at all.

So, I work operating networks, and the surrounding systems that we use to 
manage them. I could consider myself to have some knowledge in the various 
areas that I’m trying to model right now - and am even luckier to be able to 
work with a bunch of folk who have also operated different networks, such that 
we can figure out how things should be laid out. So, we’re writing these 
modules - and you’ll see them here: 
https://github.com/YangModels/yang/tree/master/experimental/openconfig

What I am saying is that as the person looking at how to /actually use/ these 
modules, it is much, much easier for me if I can have some idea of where to 
find things that I know are related, and have some consistency in the approach.

The group of people that are writing these modules noted the need for us to 
have some structure. However, the IETF is also writing a bunch of modules, 
which we figure it’d be super-neat if we can use.

So we wrote some conventions, one is a structure; the other is an approach for 
how opstate is modelled.

From your mail, I think that you are saying that you don’t care how we do this. 
If that’s the case we’ll head off and write our modules.

However, there are two discrepancies:

Lots of others in the IETF are writing models, and we’d like all these to 
combine to be usable. To do this, we need to agree on a structure. NETMOD 
looked like the place to do this based on the fact that 
draft-ietf-netmod-routing-cfg is a NETMOD draft. So we brought them here. 
Your objection is based on a specific subset of models that have already been 
created, that you assert will still need to exist. This is then counter to the 
fact that I can go and model things how I like. Again, it seems like raising 
the issues that we have with these models in context of a structure should be 
something raised with NETMOD, given that these documents are the output of 
NETMOD according to the data tracker.
There are really two options:

a) NETMOD does not care about how models fit together - because their contents 
are arbitrary. If this is the case, fine, I’ll talk with the area directors as 
to where we should propose these approaches such that the pan-IETF models end 
up working nicely together within the DML that this group has defined.
b) NETMOD does care, and should try and define a structure because it is the 
custodian working group for YANG and YANG models.

I think a lot of my problems are solved by having a defined structure for 
models, that has been worked through by folks with protocol knowledge, and 
knowledge of how these elements are used and managed. I would like it to be 
adopted by the IETF. My view is that b) is currently true - and hence it was 
brought to NETMOD.

At the moment, I can’t reconcile the apparent disparities between your 
statements in this mail and your objections in other messages. Further to this, 
I still cannot see any alternative to the structure that we did define - so 
whilst I can remove /device from the start of the path, which ‘protects’ 
/interfaces [0] - this doesn’t actually help me progress anything. This is why 
“/device or not” is irrelevant.

r.

[0]: Note that actually, some work to refactor 7223 further to just its path 
has been done… 
https://github.com/YangModels/yang/tree/master/experimental/openconfig/interfaces
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Andy Bierman

On Thu, Aug 27, 2015 at 11:19 AM, Rob Shakir r...@rob.sh wrote:

 Hi Andy,

 I’m struggling with this debate.

 On August 27, 2015 at 13:59:55, Andy Bierman (a...@yumaworks.com) wrote:


 Sorry -- are you suggesting that maybe /device adds no value beyond /?
 If so, I agree.

 No, I am suggesting that should understand what the alternatives to
 solving issues are, before moving on to debating the merits of a particular
 solution that has nothing to compare and contrast against.



There is a proposal for the data root -- use / as we are doing now.



 One container does not add value, the structure (which happens to start
 with /device in ONE proposal, to which there are no alternates) is what
 matters. Unfortunately you seem to be stuck on this container. Please
 ignore it and focus on the problems I defined.

  RTFM

 Great. So, I need to go and write a bunch of different implementations of
 how to set up a ping, and trawl through a huge number of roots to find
 things that are related. If this is the approach we take with IETF modules,
 then they will be worse to use than the existing configuration approaches
 that we have. At least the vendor specific ones have some form of logic as
 to how they are usable to consumers.


Did you really think that just because we created a nice DML that
somehow you would not need to know about the topic of your YANG module?
I actually have heard this complaint from some people.  Great.  How does
YANG help?  I still have to be an expert in MPLS to write a YANG module
that manages MPLS.  Yep.  That's right.  Nothing in YANG helps you
know more than you do now about specific networking technologies.

I don't see what the huge number of roots has to do with this issue.



 2) As a creator of YANG models, how do I know the targets for references
 such that I capture references to the elements that I want, given there is
 no currently defined structure?

 The modules you are using have data locations defined.
 In order to define YANG data (with YANG 1.0 or 1.1)
 a top-level data node or augment-stmt will be present specifying the
 /path/from/root

 How do you know where data is that has not been defined yet?
 You don't and YANG has no ability to reference undefined data anyway.

 Consider VRRP ‘tracking’. I want to be able to add some form of new thing
 that VRRP might track. If we’ve defined a structure that says that there is
 some list of ‘tracking-objects’ that I can leafref to, then my new OAM
 mechanism can augment there. If there is no such structure, then we cannot
 do that, and rather the VRRF model only leafrefs to the currently known
 paths (my ‘track’ leaf has explicit leafref to a subset of ‘ping’ and known
 continuity checks when I wrote the module). Adding the new OAM mechanism
 then means a new version of the VRRP module - which seems suboptimal. The
 first approach is cleaner, but needs someone to define the structure such
 that we get it right.


No matter what set of NP containers you create, there might be stuff that
could
reasonably be put in different places.  So what?  This is part of the
design choice
when picking the one true home for everything.

The structure is ad-hoc and arbitrary.  Its only value is in the
common agreement of where things should go.  So make up
some structure and fill it in.  What's the problem?


Nothing whatsoever is stopping the routing area from defining some structure
 for new modules.  Pick whatever you like.

 The only pushback is wrt/ obsoleting existing RFC modules and moving the
 data nodes in them to a different location. Some of us do not agree that
 a problem has been demonstrated that warrants starting over for these RFCs.

 Defining structure with arbitrary subsets of the tree doesn’t help! As an
 operator I want to be able to configure a device, because this is what my
 network is built from. Not IETF areas.

 Do you suggest that the existing models are placed as a constraint on any
 new work in YANG? If so, I’d be grateful if you can point out to me what
 the precedent is to show that they are useful in the real world?


I have not seen any evidence that moving /interfaces, /interfaces-state,
/nacm, /netconf-state, /netconf, /ipfix, /system and /snmp will solve any
real problems.
There are implementations of these modules already.

Are you suggesting that work the new routing modules cannot proceed
because these 8 top-level nodes are somehow preventing this work?
Are you suggesting it would solve your OAM or VRRP design problems
if the path was /device/interfaces instead of just /interfaces?



Kind regards,
 r.


Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Nadeau Thomas


 On Aug 27, 2015:2:29 PM, at 2:29 PM, Andy Bierman a...@yumaworks.com wrote:
 
 
 
 On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas tnad...@lucidvision.com 
 mailto:tnad...@lucidvision.com wrote:
 
 On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman a...@yumaworks.com 
 mailto:a...@yumaworks.com wrote:
 
 
 
 On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir r...@rob.sh 
 mailto:r...@rob.sh wrote:
 
 Andy,
 
 Apologies, I don’t understand how your mail answers the questions that I 
 posed.
 
 On August 27, 2015 at 12:25:20, Andy Bierman (a...@yumaworks.com 
 mailto:a...@yumaworks.com) wrote:
 
 A whole lots of words here, but I am still confused why /device is better 
 than /
 for solving your data model awareness problem.
 
 Please re-read my email - here’s the single statement where I said that this 
 was NOT the discussion that I think is important:
 
 It strikes me that there is a need to take a step back from the debate of 
 whether /device is a good idea or not.
 
 
 I’m not sure how this could be clearer.
 
 
 Sorry -- are you suggesting that maybe /device adds no value beyond /?
 If so, I agree.
 
  
 YANG is no different than any other part of the source code.
 Reusable YANG is just as likely or unlikely as reusable C,
 depending on how aware people are of the existing code base.
 
 Which OAM? Read the modules and decide. No magic there.
 How would /device vs / (as the first node) help you figure this out?
 
 Nobody is objecting at all to creating structure for the new modules.
 If /device has siblings, then let's see them in the uber-tree.
 The objection is to adding in a useless layer, and moving existing
 data nodes, which breaks existing implementations of all those data nodes.
 
 Please suggest an alternate approach to the one that is laid out in 
 draft-openconfig-netmod-model-structure that you believe will help with the 
 two problems that I raised. I’ll rephrase them here with less explanation, 
 albeit that comes with less clarity.
 
 1) As a consumer of YANG models, how do I identify the set of models that 
 provide a set of functionality? How do YANG model writers ensure that their 
 models are as easy to deal with as possible by having consistent modelling 
 approaches for config?
 
 
 RTFM
 
   Andy, 
 
   While it might be frustrating, coming to an understanding of what the 
 problem is or might be, and then looking at
 why the existing mechanisms/models or additional ones solve these 
 requirements (or do not) is what is at hand.  I think everyone agreed
 at the interim meeting that the requirements were clear and sound.  This is 
 detailed in the meeting minutes.  If anyone disputes this,
 I am happy to do an official WG call for consensus on these specifics, but 
 given the unanimous agreement at the meeting, I did
 not feel that it was necessary to do this.  Based on that, the next question 
 is: are these problems solved with what is here today, 
 or do we need another approach/es.  Rob is clearly not an idiot and is asking 
 for detailed reasons why you and others
 believe what he/OpenConfig have proposed is insufficient. Please be as 
 considerate and constructive as he has been in asking his
 questions when you address them. 
 
 
 Are you suggesting that the openconfig drafts offer some solution
 to how do I use this YANG module that does not involve reading the YANG 
 module?
 If so, I didn't see it.  Please point it out to us.

I am not taking sides. I hope I don’t need to point out these guys have 
presented an alternative 
solution. The WG must consider this seriously as it is a serious proposal that 
is being seriously
considered in other parts of the IETF such as the routing area.  I will point 
out again that we are
looking at this closely and thoroughly. If its determined to be desired via 
consensus, 
then we will go forward with it; if not, then no.  Its my action and job to 
determine this and I’ve
outlined the process for this. 

 My only objection is to moving data that has already been published in an RFC.
 I am not the only person on this list that has questioned to value of
 moving this small number of data models to new roots in the data tree.
 
 Everything done in an IETF meeting needs to be confirmed on
 the mailing list.  You know that. 
 
 So what specifics are you ready to declare have WG consensus?

Again, my assumption was that there was sufficient consensus and 
understanding around
the requirements (not the solutions) after the interim meetings.  I explicitly 
asked that
question at the meeting and went around the WebEx call to confirm.   Those 
conclusions were
documented in the meeting minutes posted on the list.

—Tom




 
 
 
   —Tom (Speaking as Co-chair)
 
 
 
 Andy
  
 2) As a creator of YANG mode
 
 ls, how do I know the targets for references such that I capture references 
 to the elements that I want, given there is no currently defined structure?
 
 
 
 The modules you are using have data locations

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Rob Shakir

Martin,

Apologies, I switched to a new client and, wow, yes, it's not readable.
I reported a bug and switched clients again... I *hope* this one is more
readable (and it was when I checked last).

I'll put aside questions of whether the questions I'm asking are
completely fair. Apologies. They're written from my perspective of
problems I'm actually experiencing.

Martin Bjorklund mailto:m...@tail-f.com
August 27, 2015 at 15:45
1) As a consumer of YANG models, how do I identify the set of models
that provide a set of functionality?

I think that neither your proposed solution or what we have today (7
published modules) solves this problem.
I respectfully disagree. By defining some form of structure for the
models, I can have a logical grouping that gives me some pointers as to
where to find the right things that I need. I want to configure OAM,
great, let's go look at
/device/logical-network-elements/logical-network-element/network-instances/network-instance/oam-protocols
- because that's where all OAM stuff happens to live. If I have to
rather look through / to find a subset of some ping functionality in one
module, and some in another, it's not clear to me how I even start to
find the right thing - because at the moment one type of ping lives in
one module, and another in a completely different one, even though
they're almost identical in terms of management plane interface.

I agree, an alternative is that one can have something that has a
registry that defines sets of functionality, and we then need to define
the 'blocks' of functionality that we need (hey! this looks a lot like
some definition of a set of modules!). If this is a better solution,
yes, please, propose it. The way that we proposed in
openconfig-model-structure tries to have a way that you can not have a
single model code-block and pull in different logical sub-modules, but
know where to find the functionality you need.

How do YANG model writers
ensure that their models are as easy to deal with as possible by
having consistent modelling approaches for config?

Hmm, your question contains the answer; that's cheating ;-)

Shouldn't the question be:

How do YANG model writers ensure that their models are as easy to
deal with as possible?

The answer to this one is the same as to the question how do a C
programmer ensure that his program is as easy to deal with as
possible?
How do I write code that is generally easy to deal with? Follow
conventions that generally tell me where to put stuff, and how to name
it. What I don't understand is why model-structure or opstate is
actually different to defining such conventions?

2) As a creator of YANG models, how do I know the targets for
references such that I capture references to the elements that I
want, given there is no currently defined structure?

Again your question is biased... shouldn't it be:

As a creator of YANG models, how do I know the targets for
references such that I capture references to the elements that I
want?

And the answer to this one is the same as to question 1 - I don't
think your proposal solves this, and the solution is that you need to
find these other modules.
Structure really helps me here, since when someone creates a module that
wants to reference a particular type of function, then we reference a
well-known path for that. If someone adds a function of that type, it
must sit in that path so it can be referenced. See the VRRP example I
wrote out before.

“Just read through the modules” is not acceptable answer when
considering making things easy to use for YANG model consumers.

First off, we drew a picture [0] that showed the set of modules that we
figured we might need. These break down into various bits of device
functionality. To make this more accessible as something that could be
shown in a draft, we expressed it in YANG and used pyang to draw out the
tree.

Cheers,
r.

[0]: http://rob.sh/files/model-structure.pdf

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Andy Bierman

On Thu, Aug 27, 2015 at 12:48 PM, Rob Shakir r...@rob.sh wrote:

 Hi Andy,

 On August 27, 2015 at 14:48:58, Andy Bierman (a...@yumaworks.com) wrote:

 Did you really think that just because we created a nice DML that
 somehow you would not need to know about the topic of your YANG module?
 I actually have heard this complaint from some people.  Great.  How does
 YANG help?  I still have to be an expert in MPLS to write a YANG module
 that manages MPLS.  Yep.  That's right.  Nothing in YANG helps you
 know more than you do now about specific networking technologies.

 No, I didn’t at all.

 So, I work operating networks, and the surrounding systems that we use to
 manage them. I could consider myself to have some knowledge in the various
 areas that I’m trying to model right now - and am even luckier to be able
 to work with a bunch of folk who have also operated different networks,
 such that we can figure out how things should be laid out. So, we’re
 writing these modules - and you’ll see them here:
 https://github.com/YangModels/yang/tree/master/experimental/openconfig

 What I am saying is that as the person looking at how to /actually use/
 these modules, it is much, much easier for me if I can have some idea of
 where to find things that I know are related, and have some consistency in
 the approach.

 The group of people that are writing these modules noted the need for us
 to have some structure. However, the IETF is also writing a bunch of
 modules, which we figure it’d be super-neat if we can use.

 So we wrote some conventions, one is a structure; the other is an approach
 for how opstate is modelled.

 From your mail, I think that you are saying that you don’t care how we do
 this. If that’s the case we’ll head off and write our modules.

 However, there are two discrepancies:

1. Lots of others in the IETF are writing models, and we’d like all
these to combine to be usable. To do this, we need to agree on a structure.
NETMOD looked like the place to do this based on the fact that
draft-ietf-netmod-routing-cfg is a NETMOD draft. So we brought them here.
2. Your objection is based on a specific subset of models that have
already been created, that you assert will still need to exist. This is
then counter to the fact that I can go and model things how I like. Again,
it seems like raising the issues that we have with these models in context
of a structure should be something raised with NETMOD, given that these
documents are the output of NETMOD according to the data tracker.

 There are really two options:

 a) NETMOD does not care about how models fit together - because their
 contents are arbitrary. If this is the case, fine, I’ll talk with the area
 directors as to where we should propose these approaches such that the
 pan-IETF models end up working nicely together within the DML that this
 group has defined.
 b) NETMOD does care, and should try and define a structure because it is
 the custodian working group for YANG and YANG models.


this is a strawman.
Just because some people don't agree that the existing modules should be
moved doesn't mean the NETMOD WG wants every module to create its
own top-level node.

Create some organization for the 194 new modules.
I completely agree with you that these modules should be written with
a coherent development plan in mind.




 I think a lot of my problems are solved by having a defined structure for
 models, that has been worked through by folks with protocol knowledge, and
 knowledge of how these elements are used and managed. I would like it to be
 adopted by the IETF. My view is that b) is currently true - and hence it
 was brought to NETMOD



Given that CLIs are being driven by YANG, I completely agree that
understanding of the command hierarchy is useful.   I have no objections
to the creation of a hierarchy or node placement plan or whatever.
This is a non-issue.

The issue I see is whether the existing 7 modules should be grandfathered
or whether these RFCs have to be changed to Obsolete status and replaced
with new RFCs.



Andy





 At the moment, I can’t reconcile the apparent disparities between your
 statements in this mail and your objections in other messages. Further to
 this, I still cannot see any alternative to the structure that we did
 define - so whilst I can remove /device from the start of the path, which
 ‘protects’ /interfaces [0] - this doesn’t actually help me progress
 anything. This is why “/device or not” is irrelevant.

 r.

 [0]: Note that actually, some work to refactor 7223 further to just its
 path has been done…
 https://github.com/YangModels/yang/tree/master/experimental/openconfig/interfaces


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Kent Watsen


Hi Martin,

BTW, are these interim meeting
minutes available somewhere?  This is not the first time I had to
search old emails in order to find interim minutes.

I just sent email to the WG chairs alias asking about this.  I'm proposing
that minutes for interim meetings be linked off the Minutes page too, as
they are already for conference meetings
(http://tools.ietf.org/wg/netmod/minutes)

Using the meeting manager tool I have access to, I can see a list of all
the interim meetings that were scheduled in 2014 and 2015.  And I can
drill down to find the link for the minutes that were uploaded for that
meeting.  Looking at the results (see below), I see that the minutes were
uploaded for about 1/2 of the meetings.  In some cases, this is an error
by the chairs forgetting to upload them or not knowing that they should
and, in other cases, this is because (I speculate) that the interim
meeting was cancelled and was left dangling.

For interim meetings that took place and yet missing minutes, Tom and I
will work to get them posted.  For the interim meetings that were
cancelled, I imagine we can uploaded some fake minutes that just say the
meeting was cancelled, though I'd much rather find a way to delete the
meeting entirely from the meeting manager tool's record - I'll ask around
to see if that's possible...


2015-10-12 : none linked
2015-10-05 : none linked
2015-09-28 : none linked
2015-09-21 : none linked
2015-09-14 : none linked
2015-09-07 : none linked
2015-08-31 : none linked
2015-08-24 : 
https://www.ietf.org/proceedings/interim/2015/08/24/netmod/minutes/minutes-
interim-2015-netmod-15
2015-06-25 : none linked
2015-06-18 : none linked
2015-03-12 : none linked
2015-03-05 : 
https://www.ietf.org/proceedings/interim/2015/03/04/netmod/minutes/minutes-
interim-2015-netmod-5
2015-03-04 : none linked
2015-02-22 : none linked
2015-02-18 : 
https://www.ietf.org/proceedings/interim/2015/02/18/netmod/minutes/minutes-
interim-2015-netmod-4
2015-02-04 : 
https://www.ietf.org/proceedings/interim/2015/02/04/netmod/minutes/minutes-
interim-2015-netmod-3
2015-01-21 : 
https://www.ietf.org/proceedings/interim/2015/01/21/netmod/minutes/minutes-
interim-2015-netmod-2
2015-01-15 : none linked
2015-01-08 : none linked
2015-01-07 : 
https://www.ietf.org/proceedings/interim/2015/01/07/netmod/minutes/minutes-
interim-2015-netmod-1
2014-12-17 : 
https://www.ietf.org/proceedings/interim/2014/12/17/netmod/minutes/minutes-
interim-2014-netmod-19
2014-12-11 : none linked
2014-12-04 : none linked
2014-12-03 : 
https://www.ietf.org/proceedings/interim/2014/12/03/netmod/minutes/minutes-
interim-2014-netmod-18
2014-11-19 : 
https://www.ietf.org/proceedings/interim/2014/11/19/netmod/minutes/minutes-
interim-2014-netmod-17
2014-10-22 : none linked
2014-10-15 : 
https://www.ietf.org/proceedings/interim/2014/10/15/netmod/minutes/minutes-
interim-2014-netmod-15
2014-10-08 : 
https://www.ietf.org/proceedings/interim/2014/10/08/netmod/minutes/minutes-
interim-2014-netmod-14
2014-10-01 : 
https://www.ietf.org/proceedings/interim/2014/10/01/netmod/minutes/minutes-
interim-2014-netmod-13
2014-09-24 : none linked
2014-09-17 : 
https://www.ietf.org/proceedings/interim/2014/09/17/netmod/minutes/minutes-
interim-2014-netmod-11
2014-09-10 : none linked
2014-09-03 : 
https://www.ietf.org/proceedings/interim/2014/09/03/netmod/minutes/minutes-
interim-2014-netmod-9
2014-08-27 : 
https://www.ietf.org/proceedings/interim/2014/08/27/netmod/minutes/minutes-
interim-2014-netmod-8
2014-07-16 : none linked
2014-07-09 : 
https://www.ietf.org/proceedings/interim/2014/07/09/netmod/minutes/minutes-
interim-2014-netmod-6
2014-07-02 : 
https://www.ietf.org/proceedings/interim/2014/07/02/netmod/minutes/minutes-
interim-2014-netmod-5
2014-06-25 : none linked
2014-06-18 : none linked
2014-06-11 : 
https://www.ietf.org/proceedings/interim/2014/06/11/netmod/minutes/minutes-
interim-2014-netmod-2
2014-06-04 : 
https://www.ietf.org/proceedings/interim/2014/06/04/netmod/minutes/minutes-
interim-2014-netmod-1



Kent


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Qin Wu

Hi,
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Andy Bierman
发送时间: 2015年8月28日 0:25
收件人: Rob Shakir
抄送: netmod@ietf.org
主题: Re: [netmod] Motivations for Structuring Models

On Thu, Aug 27, 2015 at 6:56 AM, Rob Shakir r...@rob.shmailto:r...@rob.sh 
wrote:

NETMOD,

One of the chairs encouraged me to post this to the list. I didn’t really find 
how it fits in to the existing threads, but I wanted to make an observation.

It strikes me that there is a need to take a step back from the debate of 
whether /device is a good idea or not.

As a user of something that results from compiling/generating bindings from a 
YANG model, I have two requirements:

  *   I need to be able to compose the right modules to be able to get the 
functionality that that the thing I’m trying to configure uses.

 *   Let’s say I want to configure some OAM continuity checking functions - 
for both MPLS and IP.
 *   Right now, I have the choice of ‘ietf-lspping’ which defines 
/lsp-pings, then ‘mplstp-oam’ which defines /mplstp-oam. Presumably then we’ll 
have ‘ietf-ip-oam’ and then ‘ietf-ipv6-oam’.
 *   As a developer - how do I figure out which models I need to build my 
OAM function. Do I have to trawl some directory to find all of the different 
fragments of OAM
[Qin]: I think this is also what LIME WG is trying to solve by defining generic 
YANG model for OAM to provide technology independent framework. Please take a 
look at LIME WG charter:
http://datatracker.ietf.org/wg/lime/charter/

 *   Do I then need to accept the complexity of dealing with the fact that 
the structures of LSP pings is completely different to the IP OAM structures? 
[Given that there is no co-ordination of models, then this will happen.]
 I think this is something we need to try to avoid. I believe coordination 
of these models are really needed.

  *   As someone that is building YANG models, how do I know where I should 
leaf-ref too.

 *   Let’s say I want to tie an OAM probe to some protocol liveliness - 
where do I point my leafref to? At the moment, without some structure, than any 
path that is specified is pointing to some placeholder location, until we agree 
where the structure might sit.
   [Qin]: Two comments:

1.   I think draft-rtgyangdt-rtgwg-device-model-00 provide a good structure 
for these OAM models organization but not limited to provide structure for OAM 
model organization.

  +--rw logical-network-elements

+--rw networking-instances

   +--rw networking-instance* [networking-instance-name]

  +--rw oam-protocols

  |  +--rw bfd

  |  +--rw cfm

  |  +--rw twamp



2.   draft-tissa-lime-yang-oam-model also provide a good common structure 
for OAM models organization.
LIME WG is chartered to work on generic YANG model for OAM (the relevant draft 
is draft-tissa-lime-yang-oam-model)and provides a common structure for various 
OAM technologies, technology specific OAM data models will be worked on 
respective protocol WGs(e.g., BFD, MPLS).

Therefore based on LIME charter (http://datatracker.ietf.org/wg/lime/charter/), 
the relation with protocol based OAM models can be depicted, for example, as 
follows:
   +-+-+-+-+-+
   | LIME gen|
   |OAM YANG |
   +-+-+-+-+-+
|
|
+-+
|  |   | ||
+-+-+-+-+-+   +-+-+-+-+-+   +-+-+-+-+-+ +-+-+-+-+-+  +-+-+-+-+-+
| CFM |   | MPLS-TP |   | MPLS| | IP  | . . .|  foo|
|OAM YANG |   |OAM YANG |   |OAM YANG | |OAM YANG |  |OAM YANG |
+-+-+-+-+-+   +-+-+-+-+-+   +-+-+-+-+-+ +-+-+-+-+-+  +-+-+-+-+-+
  | | |   |  |
  |   +-+-+-+-+-+   +-+-+-+-+-+   |  +-+-+-+-+-+
  |   | MPLS-TP |   | MPLS|   | . . .|  foo|
  |   |sub tech |   |sub tech |   |  |sub tech |
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

Re: [netmod] Motivations for Structuring Models

23 matches

Site Navigation

Mail list logo

Footer information