Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

From: Randy Presuhn <[email-masked]>
Date: Thu, 17 Dec 2015 15:45:23 -0800 (GMT-08:00)

Hi -

> From: Robert Wilton
> Sent: Dec 17, 2015 1:12 PM
> To: Andy Bierman
> Cc: "[email-masked]"
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
...
>     Your requirement is a bit too strong for my liking.
>
>     To paraphrase your requirement text, it is forcing that all
>     compliant NETCONF/RESTCONF servers MUST support any clients that do
>     not want to differentiate between intended config and applied
>     config.

Do do otherwise sound to me like an interoperability disaster,
and would encourage the "siloization" of toolsets.

>     However, this requires all opstate aware servers:
>
>      - To handle a mix of clients, some of which are opstate aware, and
>      some that are not.

This seems perfectly reasonable.  To do otherwise torpedoes the very
notion of interoperability.

>      - To potentially handle a mix of requests, some of which are
>      opstate aware requests, and some are not.

Ditto. 

>     It also prevents:
>
>      - Having a server that is implemented to only support opstate aware
>      clients.

Avoiding the creation of such servers sounds like a *good* thing to me.

>      - Having a server side configuration knob to control the behaviour
>      (since it would affect the semantics for all clients).

This also sounds like something which it would be desireable to prevent.    

I think I'm squarely with Andy on this one.

Randy

---

From: Robert Wilton <[email-masked]>
Date: Fri, 18 Dec 2015 11:33:44 +0000

Hi,

> I think I'm squarely with Andy on this one.

Taking a step back ...

I am probably way off the mark, but my perception is that some (perhaps 
many) of the folks in the WG still perceive that the opstate 
requirements are niche requirements for some unusual scenarios, and that 
everyone else is happy with the status quo and don't want/need them.

Alas, I don't share that view.  For me, the opstate requirements can be 
summarized as saying that the operators just want to know what 
configuration the device is actually running in a format that is 
convenient for them to use.  This really doesn't appear to be 
unreasonable request to me, and if I was writing to a network 
manageability API then I would choose to use opstate because I perceive 
that it is a more robust and easier to use API.  The counter arguments 
appear to be that it is too hard for devices to provide this 
information, and that the operators have historically managed without it.

However, I think that several things have changed, and hence negate 
these counter arguments: (i) the operators want to have much more 
automation and management over their devices, (ii) they have found a way 
to group together and have a more vocal voice about what they need and 
want, (iii) the operators have realized that they don't need to wait for 
the SDOs and can create defacto standard models on their own if they 
have to.

Personally, I would like us to stop spending time churning on the 
requirements and actually get on to discussing the solutions.  To be 
honest, there has been relatively little change in my understanding of 
the requirements from reading draft-openconfig-netmod-opstate-01 back in 
July, and I was expecting to discuss the solution drafts back in 
September.  Here we are in December, and I'm not convinced that we have 
truly made significant progress.

The only reason that I submitted a solution draft to this problem was 
because I thought it unlikely that OpenConfig would support a multiple 
datastore solution, and I could see strong resistance amongst the IETF 
engineers to the proposed OpenConfig solution.  I was hoping that my 
proposed solution might be seen for the compromise that it is between 
the two opposing positions.  But I care less on what the solution is, 
and more whether we can agree on one and move forward.

As someone that is quite new to SDO processes, my main concern is that 
IETF (and other standards bodies) are moving too slowly here, and that 
by the time that IETF have produced a sufficiently complete set of YANG 
models to manage network devices it will be too late because the 
industry will already have converged on the OpenConfig models, which 
although not perfect, are close to being usable now, and are being 
evolved at a much quicker pace ...

So my hope for the early new year is that we can reach common ground 
with OpenConfig and converge on a single set of YANG modules for 
managing network devices, and that includes having a solution to the 
Opstate problem.

Finally, if my acquiescing to Andy's requirement is helpful to move this 
process forward then that is fine with me.  As I have previously 
indicated, I don't really think that it helps with framing or discussing 
the solutions, but equally I can live with it since I suspect that the 
solutions are likely to comply with it anyway.

Apologies for the long email, and given I may not be actively reading 
the WG emails over the next couple of weeks, I'll wish you all happy 
holidays!

Thanks,
Rob

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Dec 2015 06:08:37 -0800

On Fri, Dec 18, 2015 at 3:33 AM, Robert Wilton <[email-masked]> wrote:

> many) of the folks in the WG still perceive that the opstate requirements
> are niche requirements for some unusual scenarios, and that everyone else
> is happy with the status quo and don't want/need them.
>
> configuration the device is actually running in a format that is convenient
> for them to use.  This really doesn't appear to be unreasonable request to
> me, and if I was writing to a network manageability API then I would choose
> to use opstate because I perceive that it is a more robust and easier to
> use API.  The counter arguments appear to be that it is too hard for
> devices to provide this information, and that the operators have
> historically managed without it.
>
> However, I think that several things have changed, and hence negate these
> counter arguments: (i) the operators want to have much more automation and
> management over their devices, (ii) they have found a way to group together
> and have a more vocal voice about what they need and want, (iii) the
> operators have realized that they don't need to wait for the SDOs and can
> create defacto standard models on their own if they have to.
>
> honest, there has been relatively little change in my understanding of the
> requirements from reading draft-openconfig-netmod-opstate-01 back in July,
> and I was expecting to discuss the solution drafts back in September.  Here
> we are in December, and I'm not convinced that we have truly made
> significant progress.
>
> proposed solution might be seen for the compromise that it is between the
> two opposing positions.  But I care less on what the solution is, and more
> whether we can agree on one and move forward.
>
> IETF (and other standards bodies) are moving too slowly here, and that by
> the time that IETF have produced a sufficiently complete set of YANG models
> to manage network devices it will be too late because the industry will
> already have converged on the OpenConfig models, which although not
> perfect, are close to being usable now, and are being evolved at a much
> quicker pace ...
>
> So my hope for the early new year is that we can reach common ground with
> OpenConfig and converge on a single set of YANG modules for managing
> network devices, and that includes having a solution to the Opstate problem.
>
> process forward then that is fine with me.  As I have previously indicated,
> I don't really think that it helps with framing or discussing the
> solutions, but equally I can live with it since I suspect that the
> Apologies for the long email, and given I may not be actively reading the
> WG emails over the next couple of weeks, I'll wish you all happy holidays!
>
>

The "old manager/new agent" problem has been around for at least 3 decades.
Experience has shown that adding new features in a way that does not break
existing deployments requires forethought and planning.

The backward compatibility requirement is not hard to meet.
Simply require the client to opt-in to the new behavior.
That's it.  Problem solved.

> Rob

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 18 Dec 2015 15:22:48 +0100

> On 18 Dec 2015, at 15:08, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> I am probably way off the mark, but my perception is that some (perhaps many) of the folks in the WG still perceive that the opstate requirements are niche requirements for some unusual scenarios, and that everyone else is happy with the status quo and don't want/need them.
> 
> Alas, I don't share that view.  For me, the opstate requirements can be summarized as saying that the operators just want to know what configuration the device is actually running in a format that is convenient for them to use.  This really doesn't appear to be unreasonable request to me, and if I was writing to a network manageability API then I would choose to use opstate because I perceive that it is a more robust and easier to use API.  The counter arguments appear to be that it is too hard for devices to provide this information, and that the operators have historically managed without it.
> 
> However, I think that several things have changed, and hence negate these counter arguments: (i) the operators want to have much more automation and management over their devices, (ii) they have found a way to group together and have a more vocal voice about what they need and want, (iii) the operators have realized that they don't need to wait for the SDOs and can create defacto standard models on their own if they have to.
> 
> Personally, I would like us to stop spending time churning on the requirements and actually get on to discussing the solutions.  To be honest, there has been relatively little change in my understanding of the requirements from reading draft-openconfig-netmod-opstate-01 back in July, and I was expecting to discuss the solution drafts back in September.  Here we are in December, and I'm not convinced that we have truly made significant progress.
> 
> The only reason that I submitted a solution draft to this problem was because I thought it unlikely that OpenConfig would support a multiple datastore solution, and I could see strong resistance amongst the IETF engineers to the proposed OpenConfig solution.  I was hoping that my proposed solution might be seen for the compromise that it is between the two opposing positions.  But I care less on what the solution is, and more whether we can agree on one and move forward.
> 
> As someone that is quite new to SDO processes, my main concern is that IETF (and other standards bodies) are moving too slowly here, and that by the time that IETF have produced a sufficiently complete set of YANG models to manage network devices it will be too late because the industry will already have converged on the OpenConfig models, which although not perfect, are close to being usable now, and are being evolved at a much quicker pace ...
> 
> So my hope for the early new year is that we can reach common ground with OpenConfig and converge on a single set of YANG modules for managing network devices, and that includes having a solution to the Opstate problem.
> 
> Finally, if my acquiescing to Andy's requirement is helpful to move this process forward then that is fine with me.  As I have previously indicated, I don't really think that it helps with framing or discussing the solutions, but equally I can live with it since I suspect that the solutions are likely to comply with it anyway.
> 
> Apologies for the long email, and given I may not be actively reading the WG emails over the next couple of weeks, I'll wish you all happy holidays!
> 
> 
> 

Is it not? I would say it severely restricts the workflow for the data model development. The ultra-conservative update rules essentially permit only incremental changes to published modules. This would be fine if the data model landscape already was reasonably stable. We are not that far though, and everything is in flux. So I believe we would be much better off with "release early - release often" strategy, which is made impossible by the existing update rules.

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Dec 2015 15:49:48 +0100

> Is it not? I would say it severely restricts the workflow for the data model development. The ultra-conservative update rules essentially permit only incremental changes to published modules. This…

There is a "release early - release often cycle" in the IETF process -
it is called the Internet Drafts stage. Unfortunately, often people
wait for things to stabilize (becoming an RFC) before implementing. I
assume we would have fewer but more solid data models if they would
all come along with running code behind them (and ideally > 1
independent implementations). The problem might be "us" and not the
update rules.

/js

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 18 Dec 2015 16:16:04 +0100

> On 18 Dec 2015, at 15:49, Juergen Schoenwaelder <[email-masked]> wrote:
> 

There are other disadvantages to I-Ds, for example that they have to be updated every six months. It is actually funny: RFC used to mean "request for comments", then later I-D acquired this role, so now we probably need a "drafty draft" category.

> independent implementations). The problem might be "us" and not the

The update rules mean that it is risky to publish a data model in an RFC. And indeed, if there is a need, for one reason or another, to restructure, for example, ietf-interfaces, it will have to become a new module (ietf-interfaces-dash?) and the revision history will be broken. Doing this more than once would turn the data model ecosystem into a mess.

Backward compatibility is nice, but making it an absolute requirement, which is even ingrained in the data modelling language specification, is IMO absurd.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 18 Dec 2015 15:25:08 +0000

Hi Rob, 
Thanks for authoring the comprehensive response. I’m in complete agreement
and support publication of the document.
Thanks,
Acee 

On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)" <[email-masked] on behalf of

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Dec 2015 16:27:19 +0100

> The update rules mean that it is risky to publish a data model in an RFC. And indeed, if there is a need, for one reason or another, to restructure, for example, ietf-interfaces, it will have to be…

No, it does not.
 
> Backward compatibility is nice, but making it an absolute requirement, which is even ingrained in the data modelling language specification, is IMO absurd.

I can grab interface statistics from pretty much all devices on my
network using a single data model and SNMP. This is a feature, not a
bug. You may find this not worth the effort or you might even find
this absurd in todays world. I do not have to share this view.

Can we stop here and get back to the I-D discussed in this thread? If
you want to complain about absurd YANG update rules, please do so
using a separate thread.

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 18 Dec 2015 20:02:36 +0000

Hi Robert,

I agree that -01 doesn’t add much on top of -00.  This is expected as we’re in the fit and finish phase.  If you want to help finish the draft, then please consider responding to one of these threads:

  http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html  (re: rollback-on-error)
  http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html  (re: model-structure)

As for this thread:

1. Regarding adding an explicit backwards-compatibility requirement, please note that what was written here is still in effect: http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.  Note that no objections have been raised yet, so this will likely happen.

2. Regarding adding an applicability statement, there is currently only one voice asking for it, which isn’t enough to warrant a change.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Dec 2015 12:19:15 -0800

On Fri, Dec 18, 2015 at 12:02 PM, Kent Watsen <[email-masked]> wrote:

>
> Hi Robert,
>
> I agree that -01 doesn’t add much on top of -00.  This is expected as
> we’re in the fit and finish phase.  If you want to help finish the draft,
> then please consider responding to one of these threads:
>
> 1. Regarding adding an explicit backwards-compatibility requirement,
> please note that what was written here is still in effect:
> http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.  Note
> that no objections have been raised yet, so this will likely happen.
>
> 2. Regarding adding an applicability statement, there is currently only
> one voice asking for it, which isn’t enough to warrant a change.
>
>
I did not ask to add an AS to the charter.
I don't think the WG agrees enough on the problem to write such a document.

Andy

>
>
>
> On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton" <
> [email-masked] on behalf of [email-masked]> wrote:
>
> >Hi,
> >

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 18 Dec 2015 14:54:16 -0800

Agree with Andy and Randy.

> On Dec 17, 2015, at 3:45 PM, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
> 
>> From: Robert Wilton

Mahesh Jethanandani
[email-masked]

---

From: Benoit Claise <[email-masked]>
Date: Mon, 21 Dec 2015 18:47:49 +0100

Andy,
>
>
> On Fri, Dec 18, 2015 at 12:02 PM, Kent Watsen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Hi Robert,
>
>     I agree that -01 doesn’t add much on top of -00.  This is expected
>     as we’re in the fit and finish phase.  If you want to help finish
>     the draft, then please consider responding to one of these threads:
>
>     1. Regarding adding an explicit backwards-compatibility
>     requirement, please note that what was written here is still in
>     effect:
>     http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.
>     Note that no objections have been raised yet, so this will likely
>     happen.
>
>     2. Regarding adding an applicability statement, there is currently
>     only one voice asking for it, which isn’t enough to warrant a change.
>
>
I hope that nobody disagrees that the operational state design and how 
to structure the models are the two blocking factors to publish YANG 
models. If you disagree or don't see this, let me know, I should 
communicate better.
I hope that nobody disagrees that there is a problem to be solved (a 
problem statement extracted from 
https://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/). We 
havea bunch of operators <http://www.openconfig.net/participants>, 
coming to the IETF, telling us they have a problem. So there is a problem.
I hope that nobody really believes that because some people in IETF (or 
in any other SDOs) thinks that what those operators want is a bad idea, 
those operators will not get what they request/pay for from their suppliers.

Regards, Benoit (OPS AD)
>
>
>     Thanks,
>     Kent
>
>
> Andy
>
>
>
>
>     On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton"
>     <[email-masked] <mailto:[email-masked]> on
>     behalf of [email-masked] <mailto:[email-masked]>> wrote:
>
>     >Hi,
>     >
>     >>> Cc: "[email-masked] <mailto:[email-masked]>"
>     >> [email-masked] <mailto:[email-masked]>
>     >[email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Dec 2015 19:02:31 +0100

> models. If you disagree or don't see this, let me know, I should 

Even if it may spoil your day, I disagree that there is a blocking
factor that should stop us from publishing models. There seem to be
ways to address the requirements without having to block all work or
to redo what that we have published. But sure, if you make it a
blocking factor, it will be one.

> those operators will not get what they request/pay for from their suppliers.

To be fair, those operators also tell us that they use protocols that
are not IETF protocols and it remains somewhat unclear what those
protocols are we are expected to optimize data model solutions for.

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 21 Dec 2015 19:04:55 +0000

Hi Kent,

>    http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html  (re: rollback-on-error)
Done.  In this case I think that "rollback-on-error" semantics should be 
reasonably well understood transactional semantics, so I don't think 
that we need to churn/delay the precise definition for the requirements 
draft.  We can always wordsmith the definitions in whatever solution 
draft we end up coming up with anyway ...

>    http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html  (re: model-structure)
Done.

> 1. Regarding adding an explicit backwards-compatibility requirement, please note that what was written here is still in effect: http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.  N…
That's fine with me.  As you can probably tell I don't really agree that 
adding this requirement is necessary or particularly helpful, but I 
doubt that it will matter and it certainly isn't worth spending any 
extra time debating it further.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Dec 2015 20:21:18 +0100

> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I agree with Juergen. It is not clear to me how the proposed split between intended and applied configuration is supposed to affect the data models we are working on.

Lada

---

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Dec 2015 12:38:00 +0100

Jürgen,
> factor that should stop us from publishing models.
Interestingly, I received that feedback again recently, this time from 
the OSPF and ISIS YANG model authors.
> There seem to be
> to redo what that we have published.
That's my hope too.
> But sure, if you make it a
I'll chose to ignore this last sentence.

Regards, Benoit

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Dec 2015 12:45:35 +0100

> On 22 Dec 2015, at 12:38, Benoit Claise <[email-masked]> wrote:
> 
> Jürgen,
> Interestingly, I received that feedback again recently, this time from the OSPF and ISIS YANG model authors.

Did they mention any reason *why* it is a blocking factor for their modules?

Thanks, Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 22 Dec 2015 12:03:01 +0000

Jurgen, Lada, 

>Did they mention any reason *why* it is a blocking factor for their

This should be obvious - the OSPF and IS-IS WG are not going to publish
YANG models that don’t meet the ops-state requirements. Why would we
publish standards that don’t meet the requirements and are, consequently,
irrelevant? Failure to recognize this is a real blocking issue.

Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Dec 2015 13:25:18 +0100

Hi Acee,

> On 22 Dec 2015, at 13:03, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Jurgen, Lada, 
> 

Can you please explain what specific ops-state requirements aren't met in those modules? I am interested because the same problem may possibly be present in our ietf-routing module.

Thanks, Lada

---

From: Nadeau Thomas <[email-masked]>
Date: Tue, 22 Dec 2015 07:55:19 -0500

> On Dec 22, 2015:6:38 AM, at 6:38 AM, Benoit Claise <[email-masked]> wrote:
> 
> Jürgen,

	This is a blocking factor that people are not considering: The RFC process the 
IETF has in place is not suitable for rapid/modern/canonical model development.  It will 
be difficult for the IESG review process to scale to even a couple models during any given 
telechat period given the state of the document review/approval process. How do we 
envision the IESG reviewing 250+ models (and growing)?  Besides the initial RFC version, 
rapid refresh/update of models has the same issues. 

	—Tom

---

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Dec 2015 14:01:37 +0100

> rapid refresh/update of models has the same issues.
I don't disagree, but I propose that we stick to the oper state 
discussion in this email thread.

Regards, Benoit

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 22 Dec 2015 13:07:07 +0000

Hi Lada,

On 12/22/15, 7:25 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>Can you please explain what specific ops-state requirements aren't met in
>those modules? I am interested because the same problem may possibly be
>present in our ietf-routing module.

That’s easy - the requirements as stated in
https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/

We could go back and reorganize the IGP models and add separate leaves for
intended and applied config and meet these requirements. However, if we
conclude on a more elegant solution, it would be great to avail ourselves
to that solution. 

Thanks,
Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Dec 2015 14:24:26 +0100

> On 22 Dec 2015, at 14:07, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Lada,
> 

OK, so you probably already have a solution for implementing intended and applied configuration. In my view, since intended and applied configuration have identical schemas (Requirement 1C), there is no reason for repeating any leaves in the data model.

> conclude on a more elegant solution, it would be great to avail ourselves

I don't know whether it is more elegant but certainly a possible solution is to have a separate datastore for applied configuration and use the same data model (config true part) for both intended and applied configuration.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Dec 2015 07:49:43 -0800

> conclude on a more elegant solution, it would be great to avail ourselves

At the last IETF, the consensus in the room was to use an RPC-based
solution.
Has that changed? What aspect of the RPC-based solution is blocking data
model development?

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Dec 2015 03:06:52 +0000

>I agree with Juergen. It is not clear to me how the proposed split between intended and applied configuration is supposed to affect the data models we are working on.

As I understand it, solution #1 affects the models themselves, whereas solutions #2 and #3 are transparent to the models.

Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Dec 2015 09:22:10 +0100

> On 23 Dec 2015, at 04:06, Kent Watsen <[email-masked]> wrote:
> 
> 
> 
> 
> 
> 

Then #1 looks like a non-starter to me.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 23 Dec 2015 15:01:41 +0000

On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
<[email-masked] on behalf of [email-masked]> wrote:

>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>><[email-masked]> wrote:
>>>> 
>>> I agree with Juergen. It is not clear to me how the proposed split
>>>between intended and applied configuration is supposed to affect the
>>>data models we are working on.
>> 
>> 
>> As I understand it, solution #1 affects the models themselves, whereas
>>solutions #2 and #3 are transparent to the models.
>

I’d like to point out that we also have the requirement to allow retrieval
of derived-state along with intended-config and applied-config. This will
require modification to most of the existing YANG drafts as most now have
separate trees for config and operational state. Note that this is
discussed in sections 6, 7.3, and 7.4 of
https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.

Thanks,
Acee

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Dec 2015 07:46:39 -0800

> https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
A NETCONF <get> with a subtree filter  can retrieveg both config and
non-config subtrees
at the same time.  A new RPC can be added (or existing <get> RPC extended)
to
filter various conditions.  I don't see how the YANG data layout affects
the definition
of "rpc" statements in another module.

Thanks,

Andy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 23 Dec 2015 16:11:14 +0000

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 23, 2015 at 10:46 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>, Kent Watsen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

>
>> On 23 Dec 2015, at 04:06, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>>
>>
>>
>>
>><[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>>
>>>
>>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>>

A NETCONF <get> with a subtree filter  can retrieveg both config and non-config subtrees
at the same time.  A new RPC can be added (or existing <get> RPC extended) to
filter various conditions.  I don't see how the YANG data layout affects the definition
of "rpc" statements in another module.

There is the requirement to be able to do the retrievals but there is also this requirement:

 C.  The mappings needs to be programmatically consumable

Now, if the derived-state nodes are located with the config-nodes, then this is readily satisfied. Another way of satisfying the requirement may be structural and naming conventions but this is not as sure as co-location.

Thanks,
Acee

Thanks,
Acee

Andy

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

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Dec 2015 08:18:16 -0800

On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) <[email-masked]> wrote:

>
>
> From: Andy Bierman <[email-masked]>
> To: Acee Lindem <[email-masked]>
> Cc: Ladislav Lhotka <[email-masked]>, Kent Watsen <[email-masked]>, "
> [email-masked]" <[email-masked]>
> Now, if the derived-state nodes are located with the config-nodes, then
> this is readily satisfied. Another way of satisfying the requirement may be
> structural and naming conventions but this is not as sure as co-location.
>
>
There can be meta-data returned (XML attributes) that identify the
additional properties.
This is better co-location since the pattern cannot be unintentional (as it
can with the
config-within-state containers).

Andy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 23 Dec 2015 18:22:11 +0000

Date: Wednesday, December 23, 2015 at 11:18 AM

On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

There can be meta-data returned (XML attributes) that identify the additional properties.
This is better co-location since the pattern cannot be unintentional (as it can with the
config-within-state containers).

This may be an option for published models. However, for models in development, wouldn’t it be easier to just move the nodes rather than defining the relationships in meta-data?

Thanks,
Acee

Thanks,
Acee

Andy

Thanks,
Acee

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Dec 2015 10:34:23 -0800

On Wed, Dec 23, 2015 at 10:22 AM, Acee Lindem (acee) <[email-masked]> wrote:

> This may be an option for published models. However, for models in
> development, wouldn’t it be easier to just move the nodes rather than
> defining the relationships in meta-data?
>
>

I prefer an RPC-based solution using a similar approach to the
<with-defaults> parameter
already defined in NETCONF and RESTCONF.  Not only does it work for all
models
without changing the data model, it only requires 1 subtree to be retrieved
instead of 2.

However, any solution that requires lots of data to be retrieved seems
counter-productive
to the most obvious use-case.  It has been stated many times "what if the
server is busy adding
100,000 routes, so that is why applied != intended".  Well, if the server
is busy applying config edits,
then burdening the server with lots of retrieval requests can only slow it
down.

Thanks,

Andy

---

From: Robert Wilton <[email-masked]>
Date: Wed, 23 Dec 2015 20:52:48 +0000

Hi,

On 23/12/2015 18:22, Acee Lindem (acee) wrote:
>
>
> From: Andy Bierman <[email-masked] <mailto:[email-masked]>>
> To: Acee Lindem <[email-masked] <mailto:[email-masked]>>
> Cc: Ladislav Lhotka <[email-masked] <mailto:[email-masked]>>, Kent 
> Watsen <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>     On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>         To: Acee Lindem <[email-masked] <mailto:[email-masked]>>
>         Cc: Ladislav Lhotka <[email-masked] <mailto:[email-masked]>>,
>         Kent Watsen <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>             On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee)
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>                 <[email-masked]
>                 <mailto:[email-masked]> on behalf of
>                 [email-masked] <mailto:[email-masked]>> wrote:
>
>                 >
>                 >> On 23 Dec 2015, at 04:06, Kent Watsen
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>                 >>
>                 >>
>                 >>
>                 >>
>                 >>
>                 >>
>                 >><[email-masked]
>                 <mailto:[email-masked]> on behalf of
>                 [email-masked] <mailto:[email-masked]>> wrote:
>                 >>
>                 >>>
>                 >>>><[email-masked]
>                 <mailto:[email-masked]>> wrote:
>                 >>>>
>                 >>>>> I hope that nobody disagrees that the
>                 operational state design and
>                 >>>>>how
>         Now, if the derived-state nodes are located with the
>         config-nodes, then this is readily satisfied. Another way of
>         satisfying the requirement may be structural and naming
>         conventions but this is not as sure as co-location.
>
>

Just relying on meta-data to relate config and state would probably add 
a lot of relations noise to the models.  I would imagine that this would 
make the models source YANG files harder to read, and potentially have a 
slight negative performance impact in the clients - which may be 
important if they have to relate many nodes.

Hence why I think that it is best to use co-location where possible, and 
just use explicit meta-data where the nodes are further apart in the 
data tree.

This still leaves the question as to what to do with the interfaces vs 
interfaces-state.  There would seem to be two possible solutions to me: 
(1) merge the trees together as per OpenConfig, or (2) add a special 
case rule for interfaces.  I think that this is an issue that neither 
Kent's nor my draft fully addresses.

Thanks,
Rob

>
> Thanks,
> Acee
>
>
>
>         Thanks,
>         Acee
>
>
>     Andy
>
>
>
>                 Thanks,
>                 Acee
>
>
>
>             Andy
>
>
>
>                 >
>                 >Lada
>                 >
>                 >>
>                 >> Kent
>                 >>
>                 >>
>                 >>
>                 >>> Lada
>                 >>>
>                 >>>>
>                 >>>>> I hope that nobody really believes that because
>                 some people in IETF
>                 >>>>>(or
>                 >>>>> in any other SDOs) thinks that what those
>                 operators want is a bad
>                 >>>>>idea,
>                 >>>>> those operators will not get what they
>                 request/pay for from their
>                 >>>>>suppliers.
>                 >>>>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Dec 2015 13:35:06 -0800

On Wed, Dec 23, 2015 at 12:52 PM, Robert Wilton <[email-masked]
> wrote:

> From: Andy Bierman < <[email-masked]>[email-masked]>
> To: Acee Lindem < <[email-masked]>[email-masked]>
>> [email-masked]" < <[email-masked]>[email-masked]>
>>> >> On 23 Dec 2015, at 04:06, Kent Watsen < <[email-masked]>
>>> [email-masked]> wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>< <[email-masked]>[email-masked] on behalf of
>>> [email-masked]> wrote:
>>> >>
>>> >>>
>>> >>>>< <[email-masked]>
>>> [email-masked]> wrote:
>>> >>>>
> Just relying on meta-data to relate config and state would probably add a
> lot of relations noise to the models.  I would imagine that this would make
> the models source YANG files harder to read, and potentially have a slight
> negative performance impact in the clients - which may be important if they
> have to relate many nodes.
>
>
The meta-data is not defined in the YANG models. It is defined for the
protocol.
Co-location doesn't really scale.  A system may have candidate, running,
startup,
and even proprietary "state-related" data collections. It would take 3 or 4
copies of the data to
model these datastores inside the data models.

But IMO any solution that burdens the server with retrieval
requests while the device is busy applying config will only
make the problem worse.

> just use explicit meta-data where the nodes are further apart in the data
> tree.
>
>

I looked at your draft.
Is it implemented anywhere?
It requires a custom parser that sometimes parses the leaf "foo" as a YANG
leaf
but if the special request is made, then the reply will be returning "foo"
as a container of leafs,
instead of a leaf like normal.

> interfaces-state.  There would seem to be two possible solutions to me: (1)
> merge the trees together as per OpenConfig, or (2) add a special case rule
> for interfaces.  I think that this is an issue that neither Kent's nor my
> draft fully addresses.
>

This is different -- interfaces-state can contain discovered interfaces that
have not been configured yet.

Andy

>>> >>>> Fax:   +49 421 200 3103         <
>>> <http://www.jacobs-university.de/>http://www.jacobs-university.de/>
>>> >>>>
>>> >>>> <[email-masked]>[email-masked]
>>> >>>> <https://www.ietf.org/mailman/listinfo/netmod>
>>> >>> <[email-masked]>[email-masked]
>>> >>> <https://www.ietf.org/mailman/listinfo/netmod>
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 23 Dec 2015 22:05:46 +0000

Hi Andy,

On 23/12/2015 21:35, Andy Bierman wrote:
>
>
> On Wed, Dec 23, 2015 at 12:52 PM, Robert Wilton 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>>             Cc: Ladislav Lhotka <[email-masked]
>>             <mailto:[email-masked]>>, Kent Watsen <[email-masked]
>>             config-nodes, then this is readily satisfied. Another way
>>             of satisfying the requirement may be structural and
>>             naming conventions but this is not as sure as co-location.
>>
>>
>>     This may be an option for published models. However, for models
>>     in development, wouldn’t it be easier to just move the nodes
>>     rather than defining the relationships in meta-data?
>
>     Just relying on meta-data to relate config and state would
>     probably add a lot of relations noise to the models.  I would
>     imagine that this would make the models source YANG files harder
>     to read, and potentially have a slight negative performance impact
>     in the clients - which may be important if they have to relate
>     many nodes.
>
>
> Co-location doesn't really scale.  A system may have candidate, 
> running, startup,
> and even proprietary "state-related" data collections. It would take 3 
> or 4 copies of the data to

I think that we may be talking across purposes.  My comments are 
regarding the relationship between operational nodes (aka derived state) 
and configuration, as per Acee's comments regarding my draft above.

> requests while the device is busy applying config will only
I think that with the OpenConfig model based approach, the assumption is 
that they would register to be notified of changes to the datastore 
nodes.  If it is possible to register for such notifications with an 
appropriate level of filtering/granularity then I imaging that a 
management client wouldn't necessarily need to ever poll/read the data 
(except on corned case scenarios).  Instead, it can just rely on push 
notifications of the nodes that have changed.  I would think that such a 
system would be performant.

>
>
>     Hence why I think that it is best to use co-location where
>     possible, and just use explicit meta-data where the nodes are
>     further apart in the data tree.
>
>
>
> I looked at your draft.
Thanks.

> Is it implemented anywhere?
No.  Realistically, I would expect that it would need to gain more 
support before anyone would spend time implementing it.

> It requires a custom parser that sometimes parses the leaf "foo" as a 
> YANG leaf
> but if the special request is made, then the reply will be returning 
> "foo" as a container of leafs,
Yes, agreed.

I'm not sure whether you have had the opportunity to look at the version 
2 of the draft that I published at the beginning of the week.  The main 
body of the draft hasn't really changed, but I have added an appendix 
with a possible overview of how it might be implemented using attributes 
(as you previously suggested).  If you have time to review the appendix, 
then I would be interested to know whether this is what you had broadly 
envisaged.

>
>
>
>     This still leaves the question as to what to do with the
>     interfaces vs interfaces-state.  There would seem to be two
>     possible solutions to me: (1) merge the trees together as per
>     OpenConfig, or (2) add a special case rule for interfaces.  I
>     think that this is an issue that neither Kent's nor my draft fully
>     addresses.
>
>
Yes, of course, but has the downside that it forces a separation between 
the configuration and operational state for interfaces.

Personally, ignoring all the backwards compatibility issues, I would 
prefer that interfaces and interfaces-state were a combined single list 
(as proposed by OpenConfig).  E.g. something along the lines of:
  - the system can still provide an operational list of discovered 
interfaces so that clients can know what is there.
  - but management agents would be expected to explicitly configure 
(i.e. create an entry for) all interfaces for which it wanted to 
retrieve data for.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Dec 2015 14:08:15 +0100

> just use explicit meta-data where the nodes are further apart in the 

For me, the most obvious and least disrupting solution remains a new
datastore. We already have running and startup, it seems logical to
extend this with an applied datastore. If there is a need to retrieve
data from multiple data stores in a single RPC call, then lets define
an RPC that does it.

> Kent's nor my draft fully addresses.

I assume there are more data models out there (implemented, deployed)
that follow the RFC 7223 model. And there are cases where operational
state goes beyond applied config so I am not sure merging really helps
anyone. If the verbs (=RPCs) are too restrictive, lets extend the
verbs instead of forcing even more complexity on the data models.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Dec 2015 15:24:11 +0100

> (i.e. create an entry for) all interfaces for which it wanted to 

A clear separation of config from operational state is one of the
outcomes of the IAB workshop documented in RFC 3535 and it is one of
the key foundations of both NETCONF and YANG. Config and operational
state have different and _independent_ lifetimes - you can have config
for resources that are not present and you can have operational state
for resources that are present but not configured. In addition, the
data models for operational state are often not the same as the data
models for configuration. Merging all things back into a single list
with a single keying (naming) structure gets us back into the mess we
were in with SNMP.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Dec 2015 17:46:38 +0100

> On 28 Dec 2015, at 15:24, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I agree. A good example is in ietf-routing: static routes are part of configuration but in state data they only appear in RIBs together with protocol originated-routes - there is no representation of static routes per se in state data. Data models for configuration and state data can indeed be rather different.

I would also add that IMO state data can in general be expected less standardised than configuration because they often need to be closer to the underlying device implementation.

Lada