Subject: [netmod] a few comments on draft-wilton-netmod-opstate-yang

From: Lou Berger <[email-masked]>
Date: Thu, 4 Feb 2016 17:31:54 -0500

Hello,

A few of us in the routing area architecture yang DT discussed
this draft yesterday and had a couple of comments, (note that the
open config contributors who are members of the design team did
not participate in this discussion):

- that with tooling, it is possible for the models available
using your extension have important similarities to the model
conventions proposed by open config. We think it would be worth
mentioning that tooling extensions could be used to auto generate
both yang and tree formats that would be effectively available
using the extension.

- we think there is significant value in having a tools based
approach which uses existing models, and which keeps config nodes
in unmodified locations. Chris Hopps came up with the idea of a
minor change to your extension where instead of adding 4 new
config leaf values cfg-* replacing the original leaf, the three
new leaf values would be added underneath a sibling node, perhaps
called <leaf>-cfg.  The benefit of this is that user code would be
the same with respect to intended config with or without your
extension. This also addresses the list index problem.

- also from Chris: it would be useful to have a way of retrieving
intended config along with any applied config that differs from
the intended config, e.g. with-config-state=intended+diff-cfg.

Thoughts?

Lou (with Chris)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Feb 2016 10:50:19 +0100

This I-D seems to break core design assumptions of YANG data encoding
works and hence it seems to break all existing implementations. If you
define

  leaf mtu { type uint32; }

then this is encoded as

  <mtu>9000</mtu>

and there is not room for mixed content. I am stictly against any
solution that is not backwards compatible.

/js

On Thu, Feb 04, 2016 at 05:31:54PM -0500, Lou Berger wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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: Robert Wilton <[email-masked]>
Date: Fri, 5 Feb 2016 10:09:37 +0000

Hi Juergen,

I don't really follow your point.

The solution is fully backward compatible - in that only clients that 
make use of the protocol extension would see the new encoding. Existing 
clients would continue to see the encoding as directly defined in the 
YANG schema, and a server would be able to support old and new clients 
concurrently.

Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 05 Feb 2016 11:11:37 +0100 (CET)

> solution that is not backwards compatible.

It is backwards compatible in the sense that the client has to
explicitly ask for this new encoding from the server.  However, the
solution requires new code paths for encoding/decoding the data.
Interactions with subfiltering is also a bit unclear.

But I have another observation.  Just like
draft-kwatsen-netmod-opstate, this solution makes the assumption that
the server internally has knowledge of "applied" vs. "intended" values
for data modelled as config true.  The two solutions differ in the way
this data is requested and encoded.

I would argue (no surprise here) that the encoding proposed in
draft-kwatsen-netmod-opstate is much simpler.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Fri, 5 Feb 2016 11:36:24 +0000

Hi Lou (& Chris),

Thanks for the comments.

> both yang and tree formats that would be effectively available
Yes.

I've not considered it in detail, but using tooling extensions it may be 
possible to get even closer to the OpenConfig structure/conventions if 
required.  E.g. something roughly along the lines of every "config true" 
leaf gets put into a config container and state container, state leaves 
just go in a state container, interfaces & interfaces-state could be 
merged similarly, etc. Of course this would be more complex that the 
approach proposed in the draft.

> extension. This also addresses the list index problem.
Yes, there is still a possible naming clash if a model already had a 
config leaf called "<leaf>-cfg".

Possibly this could be mitigated by putting the additional meta data 
leaves in a separate namespace, or perhaps the pragmatic approach would 
be to say don't allow leaves to be called "<leaf>-cfg"!

The reasoning for the approach documented in the draft is that I 
perceive that it is cleaner for client that want the intended vs applied 
split, but agree that the approach that Chris suggests could make 
backwards compatibility easier for clients.

> the intended config, e.g. with-config-state=intended+diff-cfg.
Yes, I think that such filters should be fairly easy to define and 
implement.  I.e. if there is a scheme in place for returning the 
intended and applied values it should be quite straight forward on the 
server side to filter which elements are returned for a particular request.

Thanks,
Rob

> .

---

From: Lou Berger <[email-masked]>
Date: Fri, 05 Feb 2016 06:55:14 -0500

Rob,
Thanks for the response, see below.

> approach proposed in the draft.

While achieving closer alignment with the layout proposed in the open 
config draft is certainly possible, that is not where we were headed. Our 
point was that with a modification to pyang it would be trivial to show the 
tree that would result with your proposal as well as, with a little more 
tooling work, auto generate additional leaves / information. -- and that 
would be generally helpful. I can see how this would be useful during model 
discussion and development, as well as facilitate certain implementation 
approaches. I was not proposing any meaningful change to the Yang that 
would be provided by the server running your extension in this bullet.

> be to say don't allow leaves to be called "<leaf>-cfg"!

I think keeping things as simple as possible is a good idea. Perhaps to 
even further reduce the possibility of naming conflict use something like 
-metadata rather than -cfg.

> backwards compatibility easier for clients.

Keep in mind that this is a user in this case. His argument for minimizing 
deltas/ maximizing similarity resonates with me. I can also see how this 
change would make things a bit easier on the server side.

> server side to filter which elements are returned for a particular request.

Excellent.

Thanks for the response,

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Feb 2016 13:23:54 +0100

> YANG schema, and a server would be able to support old and new clients 

The YANG RFC details how data is encoded in XML. People have written
and deployed code against based on this RFC. I do not accept an
approach where an RPC option can simply request that the encoding
defined in the YANG RFC is ignored and replaced with a very different
encoding.

/js (stating a clear opinion as a technical contributor)

---

From: Lou Berger <[email-masked]>
Date: Fri, 05 Feb 2016 07:52:33 -0500

Juergen,

How do you feel about the proposed modification on the table? (Leaving the  
model defined config leaves untouched and adding a -CFG or -metadata 
sibling node which would contain the additional automatically generated 
leaves.)

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Feb 2016 18:40:42 +0100

Lou,

there are things I find fundamentally flawed and things I find
somewhat flawed. I do not understand why we need to mess around with
data encodings at all. I do not see what gets simpler by messing
around with the data encodings. Engineering decisions are usually
cost/benefit tradeoffs. I see the costs, I am unsure about the
benefits.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Feb 2016 16:41:34 -0800

> defined in the YANG RFC is ignored and replaced with a very different
+1

I brought this up awhile back.

Not only is the YANG schema replaced by some "formula", there is no
indication
in the <rpc-reply> at all that this is being done.  Only the sender of the
<rpc> knows
that the special encoding rules are used instead of the YANG rules.
IMO, this solution is a non-starter.

> /js (stating a clear opinion as a technical contributor)

Andy

---

From: Robert Wilton <[email-masked]>
Date: Mon, 8 Feb 2016 13:21:52 +0000

On 06/02/2016 00:41, Andy Bierman wrote:
>
>
> On Fri, Feb 5, 2016 at 4:23 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> in the <rpc-reply> at all that this is being done.  Only the sender of 
> the <rpc> knows

Obviously the client knows that it is making a request using this 
encoding, and looking at the information contained in an RPC reply I 
can't see how a client can usefully process an RPC reply unless they 
also have the request context.

So, IIRC, your concern is specifically that a generic YANG client 
library cannot validate that the RPC reply is well formed against the 
schema without knowledge about the request.  Is that correct?

> IMO, this solution is a non-starter.
OK, and yet my understanding is that the folks requesting a solution to 
the opstate problem are saying that the applied datastore approach is 
also a non-starter, or at least very undesirable.  (Note - I don't 
actually know whether they regard the solution in 
draft-wilton-netmod-opstate-yang to be any more palatable.)

 From a clients operational perspective I can see how the OpenConfig 
model, with separate intended config and applied config leaves that are 
co-located in the schema tree makes life easy for the client in a way 
that having a separate applied configuration datastore doesn't seem to.

Rob

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Feb 2016 14:45:53 +0100 (CET)

> On 06/02/2016 00:41, Andy Bierman wrote:

[...]

> OK, and yet my understanding is that the folks requesting a solution
> to the opstate problem are saying that the applied datastore approach
> is also a non-starter, or at least very undesirable.

But the key to finding a solution that works for everyone is to
understand *why* a datastore is a non-starter.  As I noted in a
previous email, both your solution and the datastore solution rely on
the assumption that the server internally knows the difference between
the "intended" and "applied" value for the config true nodes.

> (Note - I don't

Right; so if their objection is that the server cannot know the
difference between "intended" and "applied" for the config true leafs,
neither of our solutions work.

And if their objection is that their proprietary protocol does
can/does not encode the datastore in the "get" request, then
I suspect that their protocol also does not know your proposed
encoding.

> model, with separate intended config and applied config leaves that
> are co-located in the schema tree makes life easy for the client in a
> way that having a separate applied configuration datastore doesn't
> seem to.

I can see how the applied datastore model makes life easier for the
client, e.g., a diff can be done w/o any data model knowledge at all.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Mon, 8 Feb 2016 15:22:36 +0000

Hi Martin,

> understand *why* a datastore is a non-starter.  As I noted in a
[Caveat - I don't speak for the OpenConfig operators, this is just my 
perception from previous drafts, conversations, implementing some of the 
OpenConfig models]

My understanding is that they want something this is very similar to how 
the OpenConfig models look.  After all, their preferred solution to the 
opstate problem would be for IETF to standardize on the approach used in 
OpenConfig model design.  E.g. all config nodes are defined in 
groupings, and then instantiated under both "config" and "state" containers.

I believe that their concerns are primarily about how the operators 
systems interact with the models from a management client perspective 
rather than device implementation concerns.

With the OpenConfig model/approach they get:
  - The choice of having one single tree that contains all the data 
(intended, applied and derived) - but can be split into multiple trees 
if they wish.  (I.e. with their model they have no requirement to be 
aware of separate data stores at all.)
  - Every piece of data in that tree has a unique path to identify it 
(makes the data easy to interact with).
  - The intended config, applied config, and derived state can all be 
programmatically compared.
  - Related information is co-located in the tree (e.g. if you were 
browsing the data tree).

With a datastore solution, I think that it means:
  - Either they have to put intended and applied config into separate 
trees, or they have to come up with their own scheme to combine them 
into a single tree (given that the cfg intended/applied names clash).
  - If separate trees, to ensure paths are unique they would need to 
prefix every path with the name of the datastore/tree (hassle).
  - Comparing the intended and applied trees is a bit more hassle (they 
would need to perform a pairwise walk across both intended and applied 
configuration trees).
  - When data is being returned from the server (if it is even allowed 
for two datastores to be returned in the same request) then data would 
not be co-located.  I.e. you have to read in all the data for both 
intended and applied config datastores before you can start processing 
any of it.  Whereas if the data is returned in a single tree then 
co-located data would be returned together and the the stream of data 
can be filtered/processed without building up an intermediate combined 
tree of all the data.

> the "intended" and "applied" value for the config true nodes.
Please can you clarify - I don't really follow this point.

For all solutions, it only makes sense if the server internally knows 
the difference between intended and applied values, so I assume that is 
just a given.

> client, e.g., a diff can be done w/o any data model knowledge at all.
Possibly.  But that requires that they have to manage having a separate 
datastore for applied config in the first place, and I'm not convinced 
that doing a pairwise diff across two datastores is any easier than the 
equivalent "diff" algorithm that they would write for checking the 
config state in the OpenConfig models.

Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Feb 2016 17:20:59 +0100

> schema without knowledge about the request.  Is that correct?

None of the existing tools that assume YANG defined data is XML
encoded according to RFC 6020 will not be able to process data in a
new encoding.

/js

---

From: Eliot Lear <[email-masked]>
Date: Mon, 8 Feb 2016 17:26:13 +0100

Juergen,

> encoded according to RFC 6020 will not be able to process data in a

Reversing you're negatives you are asserting that all existing tools
that assume that YANG defined data is XML encoded will be able to
process data in a new encoding.  Is that really what you meant to say? 
If so, could you kindly explain what you mean by "tools"?

Yours for less double negatives...

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Feb 2016 08:37:07 -0800

Hi,

The XML namespace matches the YANG namespace-stmt.
The JSON module name prefix matches the YANG module name.
All YANG tools use these instance document mechanisms to find
the correct YANG schema to apply.  All YANG tools will correctly
decide the opstate reporting does not match the YANG module schema,
and reject the instance document.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Feb 2016 17:40:10 +0100

> Yours for less double negatives...

Sorry, a non native speaker screwing this up. s/None of/All/

/js

---

From: Lou Berger <[email-masked]>
Date: Mon, 8 Feb 2016 12:56:37 -0500

Hi Juergen, (All)

I've change the subject line as I'm really commenting on all three
documented options in this message.

On February 5, 2016 12:41:17 PM Juergen Schoenwaelder
<[email-masked]> wrote:

> cost/benefit tradeoffs.

I completely agree with this statement, as a general statement. the
motivation in this case is that users are saying that the current
solution is inadequate. I think it behooves us to listen and see if a
better tool can be provided that addresses the limitations raised.

> I see the costs, I am unsure about the
> benefits.
>

I think this is a question of perspective. I get that from a protocol
standpoint, and possibly even language standpoint, why this  discussion
can  be considered unneeded complexity. I wouldn't even be surprised if
the open config folks agreed with you, as the core of  their solution
really doesn't need changes to the underlying protocol or language.

As I see it, there are three options on the table to address the core
issue of OpState:

1. Do nothing in Netconf / restconf or yang, and leave it to  model
conventions = openconfig draft

2. Extend Netconf / restconf , but not yang or models = Kent's draft

3. Use a language / tools based approach to augment models and
automatically produce a form of option 1  style convention changes,
without model definition restrictions. ~= Rob's draft (I'll assume
changes previously discussed on list)

WRT 1: We've heard from the model development community, i.e. model
writers, that 1 is doable but painful and easily done incorrectly. It
also impacts other SDOs, i.e. non ietf model writers.

WRT 2: We heard from the user community, at least a small number of
representatives, that 2 alone doesn't address their needs.  But it's
also clear that some in the WG would prefer Option 2 (and most/all of
these are its coauthors.)

WRT 3: There's some discussion on how/if Option 3 might best meet the
user requirements.  I think focusing on this approach on the list could
be helpful.

One question I have for you, Juergen, and the other authors of 2 is if
there are changes/improvements to 3 that you/the can see that would make
acceptable? Note I am NOT asking which the authors prefer as this is clear.

For the authors of 1, I think it would be worth hearing if a
language/tools based approach to populating the Applied Configuration
information is workable for them.

Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Feb 2016 19:57:57 +0100 (CET)

Hi,

Lou Berger <[email-masked]> wrote:
> I completely agree with this statement, as a general statement.

I agree with Juergen - I read his statement to be about Robert's
proposed solution.  

> the
> solution is inadequate.

Which solution is the current solution?

> I think it behooves us to listen and see if a
> representatives, that 2 alone doesn't address their needs.

We have heard from the open config people that their proprietary
protocol does not support datastores, but no more details.

> But it's

This was the preferred solution of the room in Yokohama.  2 of the 4
authors were present.

> acceptable? Note I am NOT asking which the authors prefer as this is clear.

I think this solution is pretty messy.  Also, it is unclear to me how
it affects things like filtering and access control for example.  Can
instance-identifiers all refer to these auto-generated nodes; are
these nodes really part of the model or not?  How is partial locking
affected?  There are lots of details to work out.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Feb 2016 11:17:17 -0800

> also impacts other SDOs, i.e. non ietf model writers.

This solution assumes that the overhead of retrieving data (while the server
is applying config) does not impact performance.  IMO retrieving 2 separate
data trees and comparing them on the client uses a lot of bandwidth and
it makes the server even more busy, so applying the config will take
even longer.

The only solution possible by replicating the YANG objects would be to
retrieve both trees and compare them on the client.

I prefer a solution that does not involve any polling by the client,
such as a notification based solution.

Since operations are data-driven in YANG, implementing a new RPC
is the same cost as implementing new YANG data nodes.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Feb 2016 20:41:28 +0100 (CET)

Hi,

Robert Wilton <[email-masked]> wrote:
> [Caveat - I don't speak for the OpenConfig operators, this is just
> my perception from previous drafts, conversations, implementing some
> of the OpenConfig models] 
> 
> My understanding is that they want something this is very similar to
> how the OpenConfig models look.  After all, their preferred solution
> to the opstate problem would be for IETF to standardize on the
> approach used in OpenConfig model design.  E.g. all config nodes are
> defined in groupings, and then instantiated under both "config" and
> "state" containers. 
> 
> systems interact with the models from a management client
> perspective rather than device implementation concerns. 
> 
>    (intended, applied and derived) - but can be split into multiple
>    trees if they wish.  (I.e. with their model they have no
>    requirement to be aware of separate data stores at all.) 

Here's a slightly updated version of a drawing that has been used to
explain how configuration data flows through the system:

  [candidate] -> [running/intended] -> [applied]
                        |
                        v
                    [startup]

We used to have three instantiations of configuration nodes, now we
have four (applied).

Three of these are datastores.  They can be programmatically compared
(even without data model knowledge).  Note that a "datastore" can be
viewed as a label (with associated semantics) of an instantiation of
these nodes.

It is unclear to me why applied must be special (modelled explicitly
rather than a named instantiation of the nodes).

Your list above applies only to the intended,applied subset of the
instantiations.  If you want to e.g. check how startup differs from
running you need a different mechanism than to check how applied
differs from running, which means different code paths etc.

>    trees, or they have to come up with their own scheme to combine
>    them into a single tree (given that the cfg intended/applied names
>    clash).

Do you mean in their proprietary protocol?

>    prefix every path with the name of the datastore/tree (hassle).

I don't see why it would be such a hassle; compare:

  /intended/interfaces/interface[name='eth0']/mtu

vs.

  /interfaces/interface[name='eth0']/config/mtu

>  - Comparing the intended and applied trees is a bit more hassle
>    (they would need to perform a pairwise walk across both intended
>    and applied configuration trees). 
>  - When data is being returned from the server (if it is even
>    allowed for two datastores to be returned in the same request) then
>    data would not be co-located.  I.e. you have to read in all the
>    data for both intended and applied config datastores before you can
>    start processing any of it.  Whereas if the data is returned in a
>    single tree then co-located data would be returned together and the
>    the stream of data can be filtered/processed without building up an
>    intermediate combined tree of all the data. 
> 

In the open config solution there is just one schema and the server
just calls the instrumentation to fill in the values.  The server
doesn't know if a node is "applied" or "derived".

In our solutions, the server knows from the request what data is
requested, and calls the corresponding instrumentation.

/martin

> For all solutions, it only makes sense if the server internally
> knows the difference between intended and applied values, so I
> assume that is just a given.
> 
> 
> >
> >> (Note - I don't
> Possibly.  But that requires that they have to manage having a
> separate datastore for applied config in the first place, and I'm
> not convinced that doing a pairwise diff across two datastores is
> any easier than the equivalent "diff" algorithm that they would
> write for checking the config state in the OpenConfig models. 
>  
> Rob
> 
> 
> >
> >
> > /martin
> >
> >
> >> Rob
> >>
> >>
> >>>

---

From: Lou Berger <[email-masked]>
Date: Mon, 8 Feb 2016 14:57:35 -0500

Hi Andy,

Thanks for the very good comments. 

Which solutions(s) were you commenting on -- you say "this" so is ambiguous.

Lou

On 2/8/2016 2:17 PM, Andy Bierman wrote:
>
>
> On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Juergen, (All)
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 8 Feb 2016 14:53:40 -0500

Martin,
    Thanks for the response.  See below.

> Which solution is the current solution?

anything in an rfc or soon to be an rfc. IMO.

> protocol does not support datastores, but no more details.

I think I've heard users say what they believe is true from their
perspective and context.  I've heard others say we disagree (or stronger
statements.)

> This was the preferred solution of the room in Yokohama.  2 of the 4
sure.  And we know that the IETF consensus is not judged by who is in
the room.  It is of course useful information to the WG and the chairs.

> affected?  There are lots of details to work out.

This is useful comments and would like to see what the options
are/should be WRT Option 3.  Do you have any opinions on this?

Thanks,
Lou

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Feb 2016 12:29:58 -0800

Hi,

I was commenting on solution 1.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Feb 2016 21:42:52 +0100 (CET)

[...]

> the room.  It is of course useful information to the WG and the chairs.

You wrote "most/all of [those who prefer option 2] are its coauthors".

My observation was that just 2 of the coauthors were in the room, and
still this was the preferred solution; thus I think that your
statement that I quoted is incorrect.

/martin

---

From: Lou Berger <[email-masked]>
Date: Mon, 8 Feb 2016 15:48:25 -0500

[retry]

Martin,

> You wrote "most/all of [those who prefer option 2] are its coauthors".
I was referring to the on-list discussion, but fair point.  But keep in
mind that an in-person meeting isn't an authoritative source of WG
consensus from the IETF process standpoint.

> statement that I quoted is incorrect.
okay, let me modify my comment:
OLD
and most/all of these are its coauthors
NEW
at very least its coauthors

Lou

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Feb 2016 12:58:35 -0800

Hi,

It should be up to the co-chairs to make consensus calls.
The IETF 94 minutes indicate that "solution 2" (RPC-based)
had consensus in the room.

https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html

I have not seen any evidence that room consensus has changed on the mailing
list.

Andy

---

From: Lou Berger <[email-masked]>
Date: Mon, 8 Feb 2016 15:43:00 -0500

Thanks Andy -- It seems to me that there are aspects of your comments
that apply to each...

Lou

On 2/8/2016 3:29 PM, Andy Bierman wrote:
> On Mon, Feb 8, 2016 at 11:57 AM, Lou Berger <[email-masked]
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Hi Juergen, (All)
>     >
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     >     > Lou,
>     >     >
>     > This solution assumes that the overhead of retrieving data
>     (while the
>     > server
>     >     user requirements.  I think focusing on this approach on the
>     list
>     >     could
>     >     be helpful.
>     >
>     >     acceptable? Note I am NOT asking which the authors prefer as
>     this
>     >     is clear.
>     >
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >     >>
>     >     >> >Phone: +49 421 200 3587         Campus Ring 1 | 28759
>     Bremen |
>     >     Germany
>     >     >> >Fax:   +49 421 200 3103       
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Feb 2016 13:20:47 -0800

>   [candidate] -> [running/intended] -> [applied]

A special set of RPC operations for <get-applied>, etc.
would work just the same as reusing the NETCONF operations, except we can
remove
the datastore parameter (by hard-wiring it to 'applied').  So datastores
are not really the issue.

Many devices do not experience any significant delays when applying
datastore edits, so there is no need at all on these devices to be concerned
about the applied datastore. There is no need to have all the extra data
nodes
defined in the YANG module.

IMO vendors will continue to use their own modules.
It is very expensive to keep rewriting the same YANG module code over and
over.
An RPC or notification-based solution can work with all data models, without
any YANG rewrites or any disruption to existing client code.

Datastores work well in NETCONF because they scale well.  They only have
cost when
they are implemented and used. They are also extensible - if I2RS needs
special editing semantics, it is much lower cost to add a datastore rather
than
rewriting all the YANG modules to make an "ephemeral" container, and
another copy of all the YANG data nodes.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Mon, 8 Feb 2016 21:21:08 +0000

> rather than a named instantiation of the nodes).

I would say that applied configuration differs from the other three in 
that it isn't really configuration at all.

It is a just a representation of what the system is currently doing, but 
to make it easy to relate back to the configuration it happens to use an 
equivalent schema as for the configuration (but logically with the 
config:true labels replaced with config:false).

Given that the applied configuration is operational state, technically I 
think that it should just be part of the existing "operational state" 
datastore.  But then the problem is that the nodes have the same path as 
the intended configuration nodes in the running configuration datastore 
and hence the namespace will collide during a get request ...

> Do you mean in their proprietary protocol?
No, I was meaning in the proprietary management systems application code.

>    /interfaces/interface[name='eth0']/config/mtu
I think that the existing protocol messages (e.g. NETCONF/etc) don't 
explicitly include the datastore name in the request/reply.  Often the 
appropriate data store is inferred from the context (or the request).  
Hence more code is needed to add/remove the datastore name when appropriate.

E.g. when I do a get request on 
"/intended/interfaces/interface[name='eth0']/mtu" I need to remember to 
strip off "/intended", and ensure that I frame the request to the right 
datastore.  And when I get a rpc-reply from a get-config request I need 
to know the context of the request so that I can annotate the reply with 
the appropriate datastore.

What if I want to get both 
"/intended/interfaces/interface[name='eth0']/mtu" and 
"/applied/interfaces/interface[name='eth0']/mtu"?  Do I need to split 
this into two separate requests and combine the responses?

So, given the choice between the two paths above, once of them seems to 
involve more code and work on the client side, and more chance of 
mistakes/confusion.

Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Feb 2016 22:37:50 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> It is a just a representation of what the system is currently doing,
> but to make it easy to relate back to the configuration it happens to
> use an equivalent schema as for the configuration (but logically with
> the config:true labels replaced with config:false).

Just like "running" is not writable in a server that supports
"candidate" but not :writable-running.

> Given that the applied configuration is operational state, technically
> I think that it should just be part of the existing "operational
> state" datastore.  But then the problem is that the nodes have the
> same path as the intended configuration nodes in the running
> configuration datastore and hence the namespace will collide during a
> get request ...

This is a problem/known issue with <get> in NETCONF.  There have been
various proposals to fix this, e.g. Andy's "get2".  I'd rather fix the
problem in the protocol once, than in all data models.

> "/intended/interfaces/interface[name='eth0']/mtu" I need to remember
> to strip off "/intended", and ensure that I frame the request to the
> right datastore.  And when I get a rpc-reply from a get-config request
> I need to know the context of the request so that I can annotate the
> reply with the appropriate datastore.

... just like I have to remember to remove the last occurance of
"config" and replace it with "state" to get applied.  This (path
handling) is trivial in both solutions.

> this into two separate requests and combine the responses?

Currently yes.  Just like if you want to get both the values from
startup and from running.  Also in this case, I'd prefer to solve the
problem generically in the protocol.

/martin

> So, given the choice between the two paths above, once of them seems
> to involve more code and work on the client side, and more chance of
> mistakes/confusion.
> 
> Rob
> 
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Feb 2016 00:33:42 +0000

[As co-chair]

Andy et al.,

Please keep in mind this message from Benoit:

https://www.ietf.org/mail-archive/web/netmod/current/msg14585.html

And note that Lou is trying to perform the analysis now.

Thanks,
Kent

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 8, 2016 at 3:58 PM
To: Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>, Juergen Schoenwaelder <[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]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] OpState Solution Options

Hi,

I have not seen any evidence that room consensus has changed on the mailing list.

Andy

On Mon, Feb 8, 2016 at 12:48 PM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
[retry]

Martin,

On 2/8/2016 3:42 PM, Martin Bjorklund wrote:
> Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
>> Martin,
>>> Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
> [...]
>
>>>> But it's

Lou

---

From: Robert Wilton <[email-masked]>
Date: Tue, 9 Feb 2016 11:17:13 +0000

> encoded according to RFC 6020 will not be able to process data in a
OK.

As Lou indicates, the proposed protocol schema encoding could also be 
generated by tooling (i.e. a pyang plugin).

I.e. a client can take the source YANG models (e.g. as defined by IETF) 
and apply a transformation to them that would generate a set of YANG 
models that are the same except that they have the extra applied 
configuration nodes added to them.

An opstate aware client could use the generated YANG models to both 
internally manage the manageability data, and also to validate that the 
messages sent to/from the server conform with the extended schema.

Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 9 Feb 2016 15:06:54 +0000

> "candidate" but not :writable-running.
That isn't really the same.

The issue isn't so much about whether this is writable or not, but 
whether the data is configuration or state.

> handling) is trivial in both solutions.
I don't agree that the complexity is the same here for both cases.

In the OpenConfig models you just get and process the item that you want:
  - No extra path manipulation is required.
  - The path itself always fully resolves to an individual value.
  - There is never any ambiguity.

OK.

Can you please suggest an approach of how to return a single tree that 
contains the data from two separate datastores (where the leaf paths may 
overlap)?  I think that the approach would need to work both for get 
requests and also notification data.

Rob

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Feb 2016 15:42:36 +0000

>requests and also notification data.

I know that this is a difference between the solutions, but I don’t see it listed as a requirement.  There is a requirement to return the diff, but that’s all.  Is there actually a need to return both sets of data?  - or is this just a desire for the diff to be able to return both (as oppose to the transform)?  Just wondering if this is a must-have or a nice-to-have.

Kent

---

From: Lou Berger <[email-masked]>
Date: Tue, 9 Feb 2016 12:45:44 -0500

Kent,

On 2/9/2016 10:42 AM, Kent Watsen wrote:
> I know that this is a difference between the solutions, but I don’t see it listed as a requirement.  There is a requirement to return the diff, but that’s all.  Is there actually a need to return both sets of data?  - or is this just a desire for the diff to be able to return both (as oppose to the transform)? 
What I see is from draft-ietf-netmod-opstate-reqs

       C.  Be able to retrieve both the applied configuration and
           derived state aspects of operational state together

I see the original OpenConfig doc/approach as supporting this (returning
both sets) but not stating this as an explicit requirement.  I do think
I've heard such usage in discussions too.

>  Just wondering if this is a must-have or a nice-to-have.
I think this is one for Anees/Rob...

Lou

---

From: Robert Wilton <[email-masked]>
Date: Tue, 9 Feb 2016 17:46:32 +0000

> I know that this is a difference between the solutions, but I don’t see it listed as a requirement.  There is a requirement to return the diff, but that’s all.  Is there actually a need to return b…
My desire is to find a overall solution that from a client usability 
perspective is on a par with the OpenConfig models.

At the moment, my understanding is that the OpenConfig operators don't 
have a need (or desire) to use datastores. I'm probably wrong, but 
personally I think that for any datastore solution to really be viable 
the use of those datastores needs to be made as seamless as possible for 
the clients.

However, I still think that an encoding/protocol based solution has the 
opportunity to provide a solution that from a client perspective feels 
similar to the OpenConfig models, but has the additional benefit that it 
doesn't force all the YANG models to have the intended/applied config 
split, and arguably has the benefit that the source YANG models are 
easier to read than the grouping approach used in the OpenConfig models.

Rob

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Feb 2016 20:54:20 +0000

Hi Lou, 

>           derived state aspects of operational state together

Maybe I’m turned around, but I thought this was about returning both intended and applied configurations together at the same time, which I didn’t know was a requirement.   Certainly returning applied config + derived state (e.g., all op state) is a requirement, as you cite above.

>I've heard such usage in discussions too.

Yes, actually, they returned all three sets of data (intended config, applied config, and derived state)

>I think this is one for Anees/Rob...

It would be good to get that clarification.   I wonder if it might be considered  errata  ;)

Kent

---

From: Lou Berger <[email-masked]>
Date: Wed, 10 Feb 2016 06:43:21 -0500

Kent,

Thanks for the response see below.

On February 9, 2016 3:54:41 PM Kent Watsen <[email-masked]> wrote:

>
> Hi Lou,
>
>
>
>
>
>
>>>>I know that this is a difference between the solutions, but I don’t see it 
>>>>listed as a requirement.  There is a requirement to return the diff, but 
>>>>that’s all.  Is there actually a need to return both sets of data?  - or is 
>>>>this just a desire for the diff to be able to return both (as oppose to the 
>>>>transform)?
> Maybe I’m turned around, but I thought this was about returning both 
> intended and applied configurations together at the same time, which I 
> didn’t know was a requirement.   Certainly returning applied config + 
> derived state (e.g., all op state) is a requirement, as you cite above.
>

You're headed the right way. Was just pointing out what is in the 
requirement document.

> It would be good to get that clarification.

Agreed.
Lou
>  I wonder if it might be considered  errata  ;)
>
>
> Kent
>
>
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 10 Feb 2016 07:09:11 -0500

Hi Andy,

> It should be up to the co-chairs to make consensus calls.

100% agree.

> had consensus in the room.

I don't see a consensus call/decision in the minutes, nor one made on the list.

I suspect you (and others) might find rfc7282 a bit surprising, and 
certainly worth the read if trying to understand the meaning of a hum and 
census in the ietf context.

> I have not seen any evidence that room consensus has changed on the mailing

I take both Kent's  mail and Benoit's earlier mail as pretty strong 
indicators that we don't have a declared consensus of the Working Group.

In my earlier mail I was basically suggesting that rather than taking the 
beauty contest approach, that we as a working group see if there is some 
middle ground solution that combines the best of all options being 
discussed. I did suggest looking at this as a modification of 3, but 
perhaps a better way of phrasing it would be calling  it 2.5 or perhaps 
even 6 - -- as in the sum of all.

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Feb 2016 14:29:23 +0100

> messages sent to/from the server conform with the extended schema.

I fail to see how on the fly schema translations makes things simpler
(and I am sure there are a number of little questions that pop up if
you really do this).

I am still waiting for the argument that convinces me that merging
datastores into a single tree makes the writing of clients orders of
magnitude simpler. If the only real technical argument is "I need to
be able to retrieve data from multiple datastores in a single RPC
operation", then lets simply define such an RPC (that works for
arbitrary combinations of datastores and not just two specific ones)
and move on. If the problem is in the existing RPC primitives, then
lets extend them instead of building hacks around them using on the
fly schema translations and what not.

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 10 Feb 2016 15:11:08 +0000

On 10/02/2016 13:29, Juergen Schoenwaelder wrote:
> magnitude simpler.
I cannot present such an argument that a protocol based solution is 
orders of magnitude better than using multiple datastores.

But I wonder whether the OpenConfig operators might also ask the WG the 
same question of whether a datastore solution is orders of magnitude 
better than the OpenConfig solution?

My best guess is that at the moment they would regard a datastore 
solution as being inferior to their current working solution (for which 
they have models that are further ahead than IETF, running code, some 
major vendors committed to implementing those models, and seeming more 
interest from the large network operators in using those models).

Will vendors actually implement a datastore based solution if the 
OpenConfig operators (who are raising the requirement) don't actually 
want/need to use it?

Then I guess the final question I have is whether SDO produced models 
will still be relevant if they lag 2 years behind the OpenConfig models, 
and those models have become a defacto standard?

>   If the only real technical argument is "I need to
I've already stated what I perceive are the client warts with data 
stores.  Martin has commented on some of those.  Alas, I doubt that you 
would find them any more compelling if I restate them again.

Rob

---

From: Kent Watsen <[email-masked]>
Date: Wed, 10 Feb 2016 16:16:25 +0000

[chair hat on]

>and those models have become a defacto standard?

Let’s just focus on solving the engineering problem at hand.  The OC folks are more than welcomed to assist (seriously guys, where are you?), but let’s not speculate on their positions.

>> operation"... <SNIP/>

I want to point out again (see [1]) that there is no requirement listed to return two configuration datastores in one RPC response - only the diff is specified as being required.  Yes, solution #1 has this ability, but that doesn’t translate to a requirement.   Unless we hear from operators that this was a missed requirement, we should not view it as such.

[1] https://mailarchive.ietf.org/arch/msg/netmod/ei_Xhnz22NoeMjlqY42DrUFGalI

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Feb 2016 10:04:00 +0100

> better than the OpenConfig solution?

This has been explained. I am not going to repeat the arguments. I am
going to ignore any further discussion here until 'the operators' come
out of their corner and start to engage in _technical_ discussion.

/js