Subject: [netmod] Motivations for Structuring Models

From: Rob Shakir <[email-masked]>
Date: Thu, 27 Aug 2015 09:56:58 -0400

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?
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.]
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.
On the first issue here, it strikes me that this is what ietf-routing is doing. It is placing a set of models under some root node which happens to be /routing. If we don’t need /device, then why do we need /routing?

The other point here, is that it is entirely unclear how ietf-routing actually fits in to the structure. I can configure L3 protocols here, great. But what happens when the ‘instance’ that I create has L2 protocols too (e.g., is a VPLS with a routed L3 interface in it), or is a mix of the two? ietf-routing doesn’t help me here - but there’s no overall structure that tells me what should fit in. If we have some structure then we can start to define what models should do what such that they are actually usable to people who want to build things via YANG models.

I would also observe that of the vendor implementations of YANG models I have looked at already, almost all define some form of structure of the data within them. In addition, the OSS tools that I’ve looked at that help interact with devices via NETCONF/YANG do the same thing.

When I originally drew the tree that was iterated on to form openconfig-model-structure, the reason to draw it was not to create some ‘/device’ node. It was to answer the two questions above. Reviewing Section 1 of draft-openconfig-netmod-model-structure, these problems are again drawn out.

The issue of the IETF here is that we are solutions-driven. It is difficult to bring this ‘challenge’ to the IETF without bringing a solution. I first raised these points with one of the routing ADs almost a year ago. I had found that in our attempts to define any form of models for higher-layer functions in the systems we were debating at the time, we needed an architecture for the models at that layer. The same thing is needed at the device layer - the draft I presented in Dallas is an attempt to suggest a possible solution for the challenges I outlined above.

So. Please can we take a step back and figure out if the IETF is interested in building models that are usable to the consumers of them?

To me, this means debating solutions for the two questions above, and then figuring out how to support that structure.

If we don’t solve this issue in the IETF, then efforts elsewhere that are more usable to developers will probably have to remain separate.

Just my £0.0002,
r.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Aug 2015 17:21:00 +0200

Hi Rob,

Rob Shakir <[email-masked]> writes:

> On the first issue here, it strikes me that this is what ietf-routing
> is doing. It is placing a set of models under some root node which
> happens to be /routing. If we don’t need /device, then why do we need
> /routing?

This one is actually easy to explain, exactly as the top-level container
"interfaces" in ietf-interfaces: it is a courtesy to XML encoding.

In both cases, a list is just below the top-level container. If the
top-level container wasn't there we could see interleaved entries of
both lists in XML encoding, for example

<routing-instance>...</routing-instance>
<interface>...</interface>
<routing-instance>...</routing-instance>
<interface>...</interface>
<interface>...</interface>

This was considered problematic, so the top-level containers were added
to avoid this.

Note that this is not an issue in JSON encoding where all entries of a
list are neatly organised in an array:

"interface": [{...}, {...}, {...}]
"routing-instance": [{...}, {...}]

Cheers, Lada

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

---

From: Rob Shakir <[email-masked]>
Date: Thu, 27 Aug 2015 11:30:44 -0400

Hi Lada,

Thanks for the reply.
On August 27, 2015 at 11:21:18, Ladislav Lhotka ([email-masked]) 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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2015 09:24:47 -0700

On Thu, Aug 27, 2015 at 6:56 AM, Rob Shakir <[email-masked]> 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.
>
> 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?
>       - 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.]
>    - 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.
>
> On the first issue here, it strikes me that this is what ietf-routing is
> doing. It is placing a set of models under some root node which happens to
> be /routing. If we don’t need /device, then why do we need /routing?
>
> The other point here, is that it is entirely unclear how ietf-routing
> actually fits in to the structure. I can configure L3 protocols here,
> great. But what happens when the ‘instance’ that I create has L2 protocols
> too (e.g., is a VPLS with a routed L3 interface in it), or is a mix of the
> two? ietf-routing doesn’t help me here - but there’s no overall structure
> that tells me what should fit in. If we have *some structure* then we can
> start to define what models should do what such that they are actually
> usable to people who want to build things via YANG models.
>
> I would also observe that of the vendor implementations of YANG models I
> have looked at already, almost all define some form of structure of the
> data within them. In addition, the OSS tools that I’ve looked at that help
> interact with devices via NETCONF/YANG do the same thing.
>
> When I originally drew the tree that was iterated on to form
> openconfig-model-structure, the reason to draw it was not to create some
> ‘/device’ node. It was to answer the two questions above. Reviewing Section
> 1 of draft-openconfig-netmod-model-structure, these problems are again
> drawn out.
>
> The issue of the IETF here is that we are solutions-driven. It is
> difficult to bring this ‘challenge’ to the IETF without bringing a
> solution. I first raised these points with one of the routing ADs almost a
> year ago. I had found that in our attempts to define any form of models for
> higher-layer functions in the systems we were debating at the time, we
> needed an architecture for the models at that layer. The same thing is
> needed at the device layer - the draft I presented in Dallas is an attempt
> to suggest a possible solution for the challenges I outlined above.
>
> So. Please can we take a step back and figure out if the IETF is
> interested in building models that are usable to the consumers of them?
>
> To me, this means debating solutions for the two questions above, and then
> figuring out how to support that structure.
>
> If we don’t solve this issue in the IETF, then efforts elsewhere that are
> more usable to developers will probably have to remain separate.
>
>

A whole lots of words here, but I am still confused why /device is better
than /
for solving your "data model awareness" problem.

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.

> r.
Andy

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Aug 2015 18:54:24 +0200

> On 27 Aug 2015, at 17:30, Rob Shakir <[email-masked]> wrote:
> 
> 
> Hi Lada,
> 
> 
> Thanks for the reply.

We certainly need *some* structure, and since there was a requirement to support multiple routing instances, a list of them seems natural.

In the past we also discussed the option of defining a common root for all configuration but we came to the conclusion that it is not needed.

Choices have been made and in some cases an alternative design could certainly be usable, too. However, since some of the models already became RFCs, convincing technical argument are needed to throw them away and go back to square 1. And I also think that moving from / to /device isn’t of that category.

Lada

---

From: Rob Shakir <[email-masked]>
Date: Thu, 27 Aug 2015 13:39:30 -0400

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 ([email-masked]) 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:

I’m not sure how this could be clearer.

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?

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?

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

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.

---

From: Rob Shakir <[email-masked]>
Date: Thu, 27 Aug 2015 13:49:22 -0400

Lada,

On August 27, 2015 at 12:54:39, Ladislav Lhotka ([email-masked]) 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?

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.

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

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.
Kind regards,
r.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2015 10:59:23 -0700

On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir <[email-masked]> wrote:

> Please re-read my email - here’s the single statement where I said that
> this was NOT the discussion that I think is important:
>
Sorry -- are you suggesting that maybe /device adds no value beyond /?
If so, I agree.

> 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

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

“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

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 27 Aug 2015 14:14:49 -0400

> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Andy,
> 
> On August 27, 2015 at 12:25:20, Andy Bierman ([email-masked] <mailto:[email-masked]>) wrote:
> 

	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?
> 
> 
> 
> a top-level data node or augment-stmt will be present specifying the /path/from/root
>

---

From: Rob Shakir <[email-masked]>
Date: Thu, 27 Aug 2015 14:19:11 -0400

Hi Andy,

I’m struggling with this debate.
On August 27, 2015 at 13:59:55, Andy Bierman ([email-masked]) 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.

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.

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.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2015 11:29:38 -0700

On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas <[email-masked]>
wrote:

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

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?

Andy

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2015 11:48:25 -0700

On Thu, Aug 27, 2015 at 11:19 AM, Rob Shakir <[email-masked]> wrote:

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

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

> 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,
Andy

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 27 Aug 2015 14:56:12 -0400

> On Aug 27, 2015:2:29 PM, at 2:29 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
> to "how do I use this YANG module" that does not involve reading the YANG module?

	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.

	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

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2015 12:11:19 -0700

On Thu, Aug 27, 2015 at 11:56 AM, Nadeau Thomas <[email-masked]>
wrote:

>>> 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.
>>>>
>>> 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,
>>
>> I am happy to do an official WG call for consensus on these specifics,
>> but given the unanimous agreement at the meeting, I did

We are going to interim meetings.
We are discussing the issues on the WG mailing list.
I was under the impression this is our process.

I hope we get past the hand-waving phase and
you can enumerate the exact changes and how they are going
to be accomplished.  For example, do all 7 of the existing RFCs need
to recharter and start over? Is a WG going to be formed to create the
uber-tree?

There have been several objections to moving /interfaces to
/device/interfaces.
Are you declaring that the IETF agrees that this change is needed, despite
all the objections and statements such as "an uber-tree makes things worse"?

> documented in the meeting minutes posted on the list.

Just because there are objections to a top-level container
named /device doesn't mean anything wrt/ the entire list of problems.
Stop trying to push these solutions through all-or-none.
Even if the IETF agrees to work on a problem, all solutions
are subject to review and alteration by the WG.  A design team
solution is just a starting point (but you know that).

>From my reading of the email (from Juergen, Tom, and others) there
are real concerns that we have not agreed on the problems to be solved.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Aug 2015 21:45:18 +0200 (CEST)

Hi Rob,

[I am replying to this email since you have your two issues clearly
enumerated here; thanks for doing that]

[side note: the text versions of your replies are very difficult to
read and thus reply to; your mail client doesn't quite get the
citation right.  is there any knob you can tweak to improve that?]

Rob Shakir <[email-masked]> wrote:
> Please re-read my email - here’s the single statement where I said
> that this
> was NOT the discussion that I think is important:
> 

Ok, I will try to do that.

> 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 provide a set of functionality?

I think that neither your proposed solution or what we have today (7
published modules) solves this problem.

This is a hard problem to solve.  It is similar to the problem of
finding the correct linux package that solves a given problem.  In
some cases I can search a central registry (package manager), and in
some cases I have to expand the search.

One solution is to not allow extensible modules at all; instead we
would work with ONE model that we just add to over time, and republish
this ever growing module when we need to.  Vendors and other SDOs
would not be able to add to this single module.  I don't think this is
a realistic approach.

Another solution is to try to have some kind of registry of all
modules.  This might work for IETF modules, but who knows what other
SDOs or vendors do?  (Incidentally there is such a registry for IETF
modules, maintained by IANA
(http://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml#yang-parameters-1))

For MIBs, there are sites that try to collect all published MIBs,
including vendor MIBs.

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

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

> “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?

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.

/martin

---

From: Rob Shakir <[email-masked]>
Date: Thu, 27 Aug 2015 15:48:50 -0400

Hi Andy,

On August 27, 2015 at 14:48:58, Andy Bierman ([email-masked]) wrote:

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Aug 2015 22:06:52 +0200 (CEST)

Nadeau Thomas <[email-masked]> wrote:
> I think everyone agreed
> at the interim meeting that the requirements were clear and sound.
> This is detailed in the meeting minutes.

Which interim meeting do you mean?  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.

The reason I ask is that I don't remember discussing requirements for
the structure; I do remember discussing requirements for relating
state to config though, but that is a separate issue.

/martin

---

From: Rob Shakir <[email-masked]>
Date: Thu, 27 Aug 2015 16:37:16 -0400

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:[email-masked]>
> August 27, 2015 at 15:45
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.
> programmer ensure that his program is as easy to deal with as
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?
> 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.
> 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.

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2015 14:33:54 -0700

On Thu, Aug 27, 2015 at 12:48 PM, Rob Shakir <[email-masked]> wrote:

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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Aug 2015 22:21:05 +0000

Hi Martin,

>BTW, are these interim meeting

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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Aug 2015 22:35:26 +0000

One response already, minutes for all interim meetings are linked here:

  http://www.ietf.org/meeting/interim/proceedings.html

This list contains entries other working groups too, and sorting by
groups, by clicking "Group" at the top, does not retain the secondary sort
on Date, so the NETMOD entries are grouped together, but all out of order
- ugh.  I'll see if this page can be improved too...

Kent

---

From: Qin Wu <[email-masked]>
Date: Fri, 28 Aug 2015 02:05:35 +0000

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

On Thu, Aug 27, 2015 at 6:56 AM, Rob Shakir <[email-masked]<mailto:[email-masked]>> wrote:

NETMOD,

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Aug 2015 08:33:54 +0200 (CEST)

Rob Shakir <[email-masked]> 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!

> 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
> - because that's where all OAM stuff happens to live.

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

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.

[...]

> > structure, right?  How do I know what these other modules are?

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

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

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Aug 2015 09:54:20 +0200 (CEST)

> moved doesn't mean the NETMOD WG wants every module to create its

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)

> a coherent development plan in mind.

+1

> to the creation of a hierarchy or "node placement plan" or whatever.

+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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Aug 2015 14:05:49 +0200

> On 27 Aug 2015, at 19:49, Rob Shakir <[email-masked]> wrote:
> 
> Lada,
> 
> 
> 

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-VR…

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

---

From: Rob Shakir <[email-masked]>
Date: Fri, 28 Aug 2015 08:32:28 -0400

Hi Martin,

Thanks for the reply.
> August 28, 2015 at 02:33
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.
> 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.
>        structure when new models are developed?
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.
>     /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.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Aug 2015 14:55:46 +0200 (CEST)

Rob Shakir <[email-masked]> wrote:
> 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

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?

> irrelevant. It does not matter

But this is the what we have been arguing about!  Remove /device and
we can put this behind us and move forward.

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

Sure, an operator configure devices.

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

No that would be even worse!  If every device had a list of exactly
one device (itself), the operator would have to do the equivalent of:

  $ ssh rtr2
  ...
  > config
  # device device rtr2 interface eth0

On most routers you don't do this. You just do:

  > config
  # interface eth0

Or in an orchestrator like NCS you'd have to do the equivalent of:

  $ ssh orchestrator
  ...
  > config
  # devices device rtr2 data devices device rtr2 interface eth0

This just doesn't make any sense.

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

Just use '/'.  The point is that *on the device* a root of /device
doesn't make any sense.

I am all for a common model of a device list to be used in the
NSM/OSS/..., but that is a separate issue.

> 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.
> practicalities of (1). This is exactly the approach that ietf-routing
> is taking for routing protocol modules.

Thanks for the clarification.

> concept of a device.

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

> If we are really just debating whether

/martin

---

From: Rob Shakir <[email-masked]>
Date: Fri, 28 Aug 2015 09:11:55 -0400

Martin,

We are almost certainly not on the same page as to what we're debating.
> August 28, 2015 at 08:55
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>
>
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).
> 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-id            uint8
             +--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 certainly do not have the impression that this is a common position 
from the other replies.

I reviewed this thread, and I'm just not sure that any of my responses 
say that the very top-level container is the most important thing. I 
even said this in the original post:

"When I originally drew the tree that was iterated on to form 
openconfig-model-structure, the reason to draw it was not to create some 
‘/device’ node. It was to answer the two questions above."

Rgds,
r.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 28 Aug 2015 13:20:47 +0000

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

Thanks,
Acee

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Aug 2015 15:24:29 +0200 (CEST)

> intent is that it would be evident as to where a particular model would be

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?

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 28 Aug 2015 13:28:52 +0000

>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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Aug 2015 15:37:59 +0200 (CEST)

Rob Shakir <[email-masked]> wrote:
> 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?).

> 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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 28 Aug 2015 16:44:11 -0700

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) <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Sat, 29 Aug 2015 01:40:33 +0000

Hi, Mahesh:
Just want to clarify.
I think what Routing DT team is doing is complementary to what LIME WG is doing.
what routing DT team is doing is to identify all the existing models and the models that are under development for OAM, routing, interface,  etc, to see how these models for different technology, protocol, feature(e.g., ACL, QoS) can fit together to form comprehensive structure and deliver the service.

LIME work wants to provide common structure for various OAM technologies by defining generic YANG model for OAM. But the focus is to define generic YANG model for OAM.
Based on LIME WG charter All the technology specific models are extension to this generic model. The relationship between these OAM related models can depicted as following:
                           +-+-+-+-+-+
                           | 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 |

The example given by Acee is to provide a list of OAM protocols which need to be ready to configure a network instance. There is no overlapping.

-Qin
发件人: netmod [mailto:[email-masked]] 代表 Mahesh Jethanandani
发送时间: 2015年8月29日 7:44
收件人: Acee Lindem (acee)
抄送: [email-masked]
主题: Re: [netmod] Motivations for Structuring Models

Acee,

grouping oam-protocols {

                      TWAMP, CFM, etc.";
             }
             description

                  networking instance.";
         }
         description

               networking instance.";
     }
     description

          networking instance.";
 }

Mahesh Jethanandani
[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Sat, 29 Aug 2015 02:11:49 +0000

Hi,
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Acee Lindem (acee)
发送时间: 2015年8月28日 21:29
收件人: Martin Bjorklund
抄送: [email-masked]
主题: Re: [netmod] Motivations for Structuring Models

On 8/28/15, 9:24 AM, "Martin Bjorklund" <[email-masked]> wrote:

>> >> > Martin Bjorklund <mailto:[email-masked]> August 28, 2015 at 
>> >> > 02:33 So the idea is that this structure is defined in one 
>> >> > module, ietf-something-structure, right?
>> >> >
>> >> 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.
>> >
>> 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 {
>> 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.
>

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.

[Qin]: Sorry to chime in, To be honest, I think the above example gives a list of OAM protocol models we can identify and but doesn't provide relationship among these OAM related models, e.g., which model is a basic model, which model is extension to basic model. Figure 1 of draft-tissa-lime-yang-oam-model-06 provides such relationship just like what draft-ietf-netmod-routing-cfg-19 did, ietf-routing is a basic model, ietf-ipv4-unicast-routing and ietf-ipv6-unicast-routing are two example of model extension to ietf-routing.

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 31 Aug 2015 18:44:52 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 28, 2015 at 7:44 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] Motivations for Structuring Models

Acee,

On Aug 28, 2015, at 6:20 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

grouping oam-protocols {

                      TWAMP, CFM, etc.";
             }
             description

                  networking instance.";
         }
         description

               networking instance.";
     }
     description

          networking instance.";
 }

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 31 Aug 2015 12:10:09 -0700

Qin,

My question was more rhetorical. What I was trying to highlight was that the process of trying to define a strict overall tree like structure is fraught with issues. Your interpretation of where oam-protocols  reside on a device could be different from say Acee’s interpretation or mine. And who is to say, that interpretation is wrong. 

The other point, that Martin also brought up, is that today a BFD configuration typically looks like this in CLI (under an interface).

Device(config-if)# bfd interval 50 min_rx 50 multiplier 5

You are asking that that should now look more like:

Device# devices device lime bfd interval 50 min_rx 50 multiplier 5

or even:

Device(config-if)# lime bfd interval 50 min_rx 50 multiplier 5

How does that make any more sense?

> On Aug 28, 2015, at 6:40 PM, Qin Wu <[email-masked]> wrote:
> 
> Hi, Mahesh:
> Just want to clarify.
> 发件人: netmod [mailto:[email-masked] <mailto:[email-masked]>] 代表 Mahesh Jethanandani
> 发送时间: 2015年8月29日 7:44
> 收件人: Acee Lindem (acee)
> 抄送: [email-masked] <mailto:[email-masked]>
> On Aug 28, 2015, at 6:20 AM, Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> [email-masked] <mailto:[email-masked]>
Mahesh Jethanandani
[email-masked]

---

From: Robert Varga <[email-masked]>
Date: Tue, 1 Sep 2015 02:01:51 +0200

On 08/28/2015 02:55 PM, Martin Bjorklund wrote:
>> >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

---

From: Robert Varga <[email-masked]>
Date: Tue, 1 Sep 2015 02:07:56 +0200

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

---

From: Rob Shakir <[email-masked]>
Date: Mon, 31 Aug 2015 20:24:21 -0400

Hi Robert,

> the same thing (purely from modeling perspective)?

We’re modelling two different things here. One is a physical system that we can have run multiple logical systems (think a bare metal machine running multiple VMs), and then the other is a logical separation of solely routing tables within one of the logical systems (think Linux network namespaces). 

There are N logical systems to each physical system, and M routing tables (VRFs) to each logical system. A logical system might come with its own set of protocol daemons, authentication etc., whereas a VRF typically would not.

Thanks,
r.

---

From: Robert Varga <[email-masked]>
Date: Tue, 1 Sep 2015 02:38:50 +0200

> There are N logical systems to each physical system, and M routing tables (VRFs) to each logical system. A logical system might come with its own set of protocol daemons, authentication etc., where…

Makes sense, thanks for making it clear. The set of logical systems is a 
flattened list of the hierarchical reality (e.g. running VMs inside a 
VM), with some additional metadata to express how logical systems relate 
to each other from containment perspective.

Bye,
Robert

---

From: Qin Wu <[email-masked]>
Date: Tue, 1 Sep 2015 00:53:18 +0000

Hi, Mahesh:

发件人: Mahesh Jethanandani [mailto:[email-masked]]
发送时间: 2015年9月1日 3:10
收件人: Qin Wu
抄送: Acee Lindem (acee); [email-masked]
主题: Re: [netmod] Motivations for Structuring Models

Qin,

My question was more rhetorical. What I was trying to highlight was that the process of trying to define a strict overall tree like structure is fraught with issues.

[Qin]: What LIME is doing is define the structure in the same way as routing-cfg did and provide common structure for various OAM technologies.

Your interpretation of where oam-protocols reside on a device could be different from say Acee’s interpretation or mine. And who is to say, that interpretation is wrong.

or even:

[Qin]: Why BFD extending from LIME model change this CLI configuration, why BFD extending from routing-cfg not change this CLI configuration?

Based on your reason or concept, It looks you are proposing

“

Device# devices device rt bfd interval 50 min_rx 50 multiplier 5
or even:

Device(config-if)# rt bfd interval 50 min_rx 50 multiplier 5

“
by augmenting routing-cfg with BFD specific.
In my understanding, whether you are using common structure of routing-cfg or using common structure of LIME model or “using its own structure without considering to interact with other OAM models”, it doesn’t change CLI used for BFD configuration.
Let me give you another example,
“

Device# devices device ospf interval 50

“

Do you think CLI will be changed as follows:

“

Device# devices device rt ospf interval 50

“
When OSPF configuration model is extending from routing-cfg? My understanding is No.

On Aug 28, 2015, at 6:40 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Mahesh:
Just want to clarify.

-Qin
发件人: netmod [mailto:[email-masked]] 代表 Mahesh Jethanandani
发送时间: 2015年8月29日 7:44
收件人: Acee Lindem (acee)
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [netmod] Motivations for Structuring Models

Acee,

grouping oam-protocols {

                      TWAMP, CFM, etc.";
             }
             description

                  networking instance.";
         }
         description

               networking instance.";
     }
     description

          networking instance.";
 }

Mahesh Jethanandani

Mahesh Jethanandani