Subject: [Netconf] New Datastores? (was Re: RESTCONF content=all on conflicts?)

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Jun 2016 19:56:19 -0700

On Thu, Jun 23, 2016 at 1:49 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> On Wed, Jun 22, 2016 at 05:13:00PM +0100, Robert Wilton wrote:
> >
> >
> > draft-ietf-netmod-opstate-reqs defines Operational State as:
> >
> >    Operational State:  Operational State is the current state of the
> >        system as known to the various components of the system (e.g.,
> >        control plane daemons, operating system kernels, line cards).
> >        The operational state includes both applied configuration and
> >        derived state.
> >
> > The definition in draft-schoenw excludes the applied configuration as
> part
> > of the operational state datastore which I would read as being
> inconsistent
> > with the definition above.
>
> The <operational-state> datastore in the I-D represents _all_
> operational state, irrespective of its origin. I think partitioning
> the operational state is not useful. Again, this discussion does not
> really belong into this thread.
>
>
Sorry I do not have time to read all the drafts so I can understand your
differences of opinion within the design team.

Balazs has asked repeatedly for a way to identify counters
as not being operational state.  How is this issue solved?

Current datastores work with (at least) 3 fundamental rules:

  1) datastore child nodes are an implementation-specific collection
      of top-level YANG data nodes.

  2) each datastore shares a common schema tree, such that data is
      specified exactly the same for any datastore in RPC input parameters

  3) datastores are expected to be complete, such that YANG validation tests
      for all modules will pass for a valid datastore

I prefer an RPC approach (is-it-applied-yet) rather than retrieving data
from 2 places.  The client should keep checking that intended config
has not been changed in the running datastore, as well as checking
the applied datastore.

Metadata can work as well.
Retrieving data with metadata about opstate takes 1 round-trip, not N.

/js

Andy

> --
> 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/>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 24 Jun 2016 14:36:58 +0100

On 24/06/2016 03:56, Andy Bierman wrote:
>
>
> On Thu, Jun 23, 2016 at 1:49 PM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > The definition in draft-schoenw excludes the applied
>     configuration as part
If this means the partitioning into separate "abstract" datastores in 
draft-wilton, this is really just a labeling of the source/semantics of 
the data in the operational state datastore.

> as not being operational state.  How is this issue solved?
At the moment, there is no proposed solution for this, but it hasn't 
really been discussed.

We already have a "config=true" keyword, and "ephemeral" looks as if it 
is going to be a likely addition from the I2RS requirements, so I think 
that as least having a "statistics" keyword to label particular nodes as 
relating to statistics may make sense.

Whether these should be a separate user independent datastore to the 
operational state datastore, or just a labelled part of the "operational 
state datastore" probably needs to be debated further?

> Retrieving data with metadata about opstate takes 1 round-trip, not N.
My proposal is to use metadata.

The nodes in the intended config can be labelled as to whether or not 
they are applied.  Clients could query for this using an option (similar 
to with-defaults).   Or what I think is a better solution is for client 
to be able to register for notification (YANG Pub/Sub) of the intended 
configuration datastore + metadata annotations. Hence the client would 
be notified as the configuration gets applied (or if it fails) without 
having to poll the server at all.

I also envisage that similar annotations would be applied to an 
"operational state datastore" which would indicate where particular 
values have come from.  E.g. are they due to applied configuration, or 
system created entries (such as interfaces), etc.

Thanks,
Rob

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