Subject: [i2rs] Two thoughts on an ephemeral data store

From: Jeffrey Haas <[email-masked]>
Date: Wed, 24 Sep 2014 11:30:51 -0400

In the proposed overlay model, presume that we have ephemeral data from a
model that lives within an augmentation to a local config model.  In other
words, the ephemeral nodes are children of the local config nodes.

Presume, per discussion, that the local config lives in the "config" data
store and that the ephemeral config - the augmenting nodes above - live in
the ephemeral data store.

If we delete the container in the local config that the epehemeral config is
augmenting, is there any expectation that such a deletion should carry
through to the ephemeral config?

Per the netmod interim discussion, probably not.  It's in a separate
datastore.  But it does lead to integrity issues since we now have orphaned
state.  In this particular example, permitting the deletion to carry through
to the ephemeral datastore at least provides one additional level of
consistency.

-----

My second thought is would we ever want to provide filtering in the
conditional checks (must/when) in the ephemeral datastore based on the
underlying source of the data?  Since local config would be shadowed into
the ephemeral datastore, do we want the ability to match on the source of
the node set under evaluation?

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Sep 2014 08:47:18 -0700

> to the ephemeral datastore at least provides one additional level of
I think the concept of "shadowing the local config" makes this behavior
confusing.
If the ephemeral datastore instances remains after the config datastore
instances are deleted, how is that really shadowing?

IMO, shadowing only occurs when the ephemeral datastore is edited.
It is used as a snapshot to reduce the I2RS payload size (shadow patch?.
But the data that gets created in the ephemeral datastore is complete and
self-contained.  The actual data structures are implementation details.
Maybe the local config is cloned, maybe it is shadowed.

-----
> the node set under evaluation?

Each datastore should only validated against itself, or else the
XPath implementation would be even more complicated.  If the ephemeral
datastore
is supposed to be fast (I remember 5000 updates a second from the BoF)
then running validation tests across multiple datastores constantly will
not help.

Or do you mean flag a must/when as "do-not-use" in the ephemeral datastore?
If that were possible it would help speed up the server.

> -- Jeff
Andy

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 24 Sep 2014 11:53:32 -0400

Andy,

> Maybe the local config is cloned, maybe it is shadowed.

I agree that this begs the semantics a bit.  Is it a shadow or a snapshot?
Each one has impact.

In the snapshot case, if you delete stuff from the local config, do we
effectively "reapply the ephemeral patch" on top of it?  Does the ephemeral
datastore get notified that the local config has changed and is permitted to
let that operation fail?

Part of the motivation will come from where your box gets its state from.
If it's from reading the ephemeral config, then local config semantics with
regard to snapshot vs. shadow become very important.

> If that were possible it would help speed up the server.

I'm thinking of it as a form of meta-data, just like creator (user) would
be.  Thus, "datastore='ephemeral'" or "datastore='config'" type semantics.

I'm not currently arguing that this has a use case yet.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Sep 2014 08:17:54 +0200

I believe this question is a general question, not particular to the
way we realize ephemeral data. If I2RS injects state that is not
consistent with config, then that state is likely ignored (at least
this is what I understood when we touched this point last week).

Conceptually, with the shadowing approach, there is a 'merge'
operation between the config datastore and ephemeral datastores.  If
the merge fails, then (as far as I recall last weeks discussion) it is
expected that a notification is emitted to the I2RS system(s)
involved.

I2RS seems to seek for high transaction rates. And NETCONF people love
to keep the config datastore self-consistent. If changes to the config
datastore invalidate I2RS content, then this needs to be signalled to
I2RS clients to take action. I think it would be wrong to reject an
otherwise valid config change because it creates a conflict with
ephemeral state the config system may not even be aware of.

/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: "Joel M. Halpern" <[email-masked]>
Date: Thu, 25 Sep 2014 06:19:55 -0400

Top posting for ease of reading, but retaining the content for those who 
want context.

As I understand the shadow proposal, there is the regular local config 
data store, and then there is a second data store (shadow) used by I2RS 
for its ephemeral data.  That store is never persisted.  So far, so good.

Then Andy asked about when they are synchronized, and suggested that 
they would be sychronized only when the shadow datastore is established 
by teh first I2RS modification request (if I understood him correctly).

I don't think that works.  Suppose that I2RS has adjusted data items A 
and B, creating and filling the shadow data store.  And then someone 
using CLI / normal NetCONF adjusts item C.  If an I2RS client goes to 
read C, or does some operation which depends upon the value of C, it has 
to be working with the new value of C, not the value at the time the 
ephemeral store was created.

Yours,
Joel

On 9/24/14, 11:47 AM, Andy Bierman wrote:
>
>
> On Wed, Sep 24, 2014 at 8:30 AM, Jeffrey Haas <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Sep 2014 12:29:35 +0200 (CEST)

Jeffrey Haas <[email-masked]> wrote:
> Per the netmod interim discussion, probably not.

My interpretation of the interim discussion is that the deletion
carries through.

> It's in a separate
> datastore.

But a special datastore which acts a shadow to the config.  I think
this is an important property of this datastore.

/martin

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Sep 2014 10:16:59 -0400

Juergen,

> expected that a notification is emitted to the I2RS system(s)

Working through my examples to discuss this, I realized the fault in my
logic: If we treat the delete operation in the local config for overlapping
schemas as propagating through to the ephemeral datastore, it's effectively
not a deterministic merge.  It's a merge of the last party's state on top
and that's not what we want.

Consider the thought withdrawn. :-)

> ephemeral state the config system may not even be aware of.

Agreed.  This does help solidify the case about the need to deal with
inconsistencies introduced by changes to the underlying local config.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Sep 2014 10:19:37 -0400

> My interpretation of the interim discussion is that the deletion

To be clear what I meant, consider:

local config:      ephemeral:
A                  A/B - B is introduced as an augmentation of A

If A is deleted, the question is whether we had B as an orphan or not.

Thus, it "carries through" in the sense that the merge results in
inconsistent state rather than B being deleted as well.

-- Jeff

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Sep 2014 16:39:01 +0200 (CEST)

> A                  A/B - B is introduced as an augmentation of A

I think there might be a terminology confusion here, so let's do a
simple example.

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

In ephemeral config we now do SET /foo[id=42]/a  to 4711.  Thus, in
ephemeral we now have a single node (a) with value 4711.

What happens if we in local config delete foo 42?

If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now
presented to the internal apps?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Sep 2014 08:44:14 -0700

> presented to the internal apps?

Yes -- and what is presented to a client that retrieves the ephemeral config
in a GET request? IMO, coupling the datastores does not make sense.

Your example is 1 reason I prefer the "shadow shapshot" approach.
I think the local config and client that added the "foo" entry in the
ephemeral datastore
are meant to have different priorities.  The entries are not coupled.
One wins and the other loses (main use-case is that ephemeral wins).

Editing "foo 42" in the local config just changes what will be installed as
local config
when the device restarts (or the ephemeral state is removed).  It should
not change
the injected I2RS state at all.  IMO it is really important that edits stay
within a single
datastore.

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 26 Sep 2014 00:57:20 +0000

FWIW, I would think the semantics should be kept simple.

The complexity here comes from the fact that there are dependencies between different data stores, and some objects that are part of one data store need to be reflected in a different data store.

It would seem this can be addressed with two fairly simple principles:

(a)    A datastore needs to have a clear way to reference objects in a different datastore, really have them incorporated into the same namespace.

(b)   It needs to be clear who owns the "golden copy" of an object.  I needs to be clear which objects are "authoritatively owned" by a datastore vs which ones are reference.  This is the datastore where the object is maintained, updated, created; this is where conditions and constraints are evaluated, etc.

Where an ephemeral datastore has dependencies on data in another datastore, it should incorporate these other objects "by reference".  The objects that are authoritatively owned by the ephemeral datastore can refer to those objects, have them referred to in conditions and constraints, and so on.  (This can also indicate which ephemeral objects are to be removed when an object in the other datastore they depend on is deleted, etc)

Changes to the non-ephemeral objects (e.g. the running datastore) have to be made to the "golden copy", i.e. the owning datastore.  One way to do that involves implementing a "write-through" operation, in which an update to an ephemeral copy of the object is realized by having the server of the ephemeral datastore turn around and make a corresponding request at the other datastore.

Very simple semantics.  I think this is preferrable to have different copies of the same object in different datastores, requiring "logical anding" (or other inter-datastore arithmetic) of different copies representing the same object to figure out what actual value is in effect, etc.

In the netmod WG, we have today posted a draft for what we refer to as requirements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requirements-00.txt), motivating why a it would be useful to have a capability to "mount" subtrees from a remote datastore into a local datastore, and the requirements that such a capability needs to address.  While the original use case and motivation described there are somewhat different, it seems applicable to the discussion here.

--- Alex

From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, September 25, 2014 8:44 AM
To: Martin Bjorklund
Cc: Jeffrey Haas; [email-masked]
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
> > Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

Your example is 1 reason I prefer the "shadow shapshot" approach.
I think the local config and client that added the "foo" entry in the ephemeral datastore
are meant to have different priorities.  The entries are not coupled.
One wins and the other loses (main use-case is that ephemeral wins).

Editing "foo 42" in the local config just changes what will be installed as local config
when the device restarts (or the ephemeral state is removed).  It should not change
the injected I2RS state at all.  IMO it is really important that edits stay within a single
datastore.

/martin

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 26 Sep 2014 11:30:00 -0400

Alexander: 

To help me understand your proposal, let us move to the previous example: 

Previous example: 

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

Your model:

a)  The value 4711 - would be a "non-golden" copy.

b)  It would not be written through to the the "golden copy".

Questions: 

a)  How would you specify a "write-through" copy? 

b)  Can I2RS decide later it wants to write-through the golden copy?  Or are
variables only "non-write-through" and "write-through"?

c)  If we delete foo 42, what happens? 

Thank you,

Sue Hares 

From: i2rs [mailto:[email-masked]] On Behalf Of Alexander Clemm
(alex)
Sent: Thursday, September 25, 2014 8:57 PM
To: Andy Bierman; Martin Bjorklund
Cc: Jeffrey Haas; [email-masked]; Eric Voit (evoit)
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

The complexity here comes from the fact that there are dependencies between
different data stores, and some objects that are part of one data store need
to be reflected in a different data store.  

(a)    A datastore needs to have a clear way to reference objects in a
different datastore, really have them incorporated into the same namespace.

(b)   It needs to be clear who owns the "golden copy" of an object.  I needs
to be clear which objects are "authoritatively owned" by a datastore vs
which ones are reference.  This is the datastore where the object is
maintained, updated, created; this is where conditions and constraints are
evaluated, etc.  

Where an ephemeral datastore has dependencies on data in another datastore,
it should incorporate these other objects "by reference".  The objects that
are authoritatively owned by the ephemeral datastore can refer to those
objects, have them referred to in conditions and constraints, and so on.
(This can also indicate which ephemeral objects are to be removed when an
object in the other datastore they depend on is deleted, etc)

Changes to the non-ephemeral objects (e.g. the running datastore) have to be
made to the "golden copy", i.e. the owning datastore.  One way to do that
involves implementing a "write-through" operation, in which an update to an
ephemeral copy of the object is realized by having the server of the
ephemeral datastore turn around and make a corresponding request at the
other datastore.  

Very simple semantics.  I think this is preferrable to have different copies
of the same object in different datastores, requiring "logical anding" (or
other inter-datastore arithmetic) of different copies representing the same
object to figure out what actual value is in effect, etc.  

In the netmod WG, we have today posted a draft for what we refer to as
requirements for a peer mount
(http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requiremen
ts-00.txt), motivating why a it would be useful to have a capability to
"mount" subtrees from a remote datastore into a local datastore, and the
requirements that such a capability needs to address.  While the original
use case and motivation described there are somewhat different, it seems
applicable to the discussion here.  

--- Alex

 

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

 

when the device restarts (or the ephemeral state is removed).  It should not
change

datastore.

/martin

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Sep 2014 08:55:39 -0700

> To help me understand your proposal, let us move to the previous example:

So in this "foo 42" step, you are assuming that the NETCONF or RESTCONF
client
told the NETCONF or RESTCONF server that the edit to the local config is
supposed
to be copied to the ephemeral datastore?  So modifications to those
protocols
to edit multiple datastores at once will be needed? (Your Q (a) below)
So we are assuming the 2 datastores are in sync so concurrent edits are
feasible?

> ephemeral we now have a single node (a) with value 4711.

You have this only if the previous step copied "foo 42".
You cannot create a child node unless the parent exists or is also getting
created.
If you delete a node, the entire subtree (the XPath descendant-or-self
axis) is deleted.
I hope the various plans to couple the running and ephemeral datastores do
not
try to violate these rules.

Andy

Your model:
> b)  Can I2RS decide later it wants to write-through the golden copy?  Or
> are variables only "non-write-through" and "write-through"?
>

Andy

> *From:* i2rs [mailto:[email-masked]] *On Behalf Of *Alexander
> Clemm (alex)
> *Sent:* Thursday, September 25, 2014 8:57 PM
> *To:* Andy Bierman; Martin Bjorklund
> *Cc:* Jeffrey Haas; [email-masked]; Eric Voit (evoit)
> *Subject:* Re: [i2rs] Two thoughts on an ephemeral data store
>
>
>
> The complexity here comes from the fact that there are dependencies
> between different data stores, and some objects that are part of one data
> store need to be reflected in a different data store.
>
>
>
> (b)   It needs to be clear who owns the "golden copy" of an object.  I
> needs to be clear which objects are "authoritatively owned" by a datastore
> vs which ones are reference.  This is the datastore where the object is
> Where an ephemeral datastore has dependencies on data in another
> datastore, it should incorporate these other objects "by reference".  The
> objects that are authoritatively owned by the ephemeral datastore can refer
> to those objects, have them referred to in conditions and constraints, and
> so on.  (This can also indicate which ephemeral objects are to be removed
> when an object in the other datastore they depend on is deleted, etc)
>
>
>
> Changes to the non-ephemeral objects (e.g. the running datastore) have to
> be made to the "golden copy", i.e. the owning datastore.  One way to do
> that involves implementing a "write-through" operation, in which an update
> to an ephemeral copy of the object is realized by having the server of the
> Very simple semantics.  I think this is preferrable to have different
> copies of the same object in different datastores, requiring "logical
> anding" (or other inter-datastore arithmetic) of different copies
> representing the same object to figure out what actual value is in effect,
> etc.
>
>
>
> requirements for a peer mount (
> http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requirements-00.txt),
> motivating why a it would be useful to have a capability to "mount"
> subtrees from a remote datastore into a local datastore, and the
> *From:* i2rs [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Andy Bierman
> *Sent:* Thursday, September 25, 2014 8:44 AM
> *To:* Martin Bjorklund
> *Cc:* Jeffrey Haas; [email-masked]
> *Subject:* Re: [i2rs] Two thoughts on an ephemeral data store
>
>
>
>
>
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 26 Sep 2014 13:33:54 -0400

Andy: 

I'm asking Alexander what his model is as it is unclear. Rather than tear
about my question, let's let him respond, and then debate the details. 

Sue 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, September 26, 2014 11:56 AM
To: Susan Hares
Cc: Alexander Clemm (alex); Martin Bjorklund; Jeffrey Haas; [email-masked];
Eric Voit (evoit)
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

Alexander: 

Previous example: 

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

 

If you delete a node, the entire subtree (the XPath descendant-or-self axis)
is deleted.

 

Andy

Your model:

Questions: 

Thank you,

Sue Hares 

Andy

--- Alex

 

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

 

datastore.

/martin

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 26 Sep 2014 13:45:48 -0400

Andy: 

. please correct this to: 

I'm asking Alexander what his model is as it is unclear. Rather than tear a
apart my question, let's let him respond, and then debate the details. 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, September 26, 2014 1:34 PM
To: 'Andy Bierman'
Cc: 'Jeffrey Haas'; [email-masked]; 'Alexander Clemm (alex)'; 'Martin
Bjorklund'; 'Eric Voit (evoit)'
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

Andy: 

Sue 

 

Alexander: 

Previous example: 

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

 

 

Andy

Your model:

Questions: 

Thank you,

Sue Hares 

Andy

--- Alex

 

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

 

datastore.

/martin

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 26 Sep 2014 23:53:43 +0000

Hi Susan, Andy, all,

there would be two datastore - "local" and "ephemeral".
Local implements and owns foo, instantiated as you describe below.  This is the golden copy.
Furthermore, for simplicity sake, assume that list foo is contained in a container, foos.

The ephemeral datastore implements a separate model "foo-ext".
This model declares a reference / "mount" to "foos" in the local datastore.
In addition, it defines some other data, that is "owned" by the ephemeral datastore.  (This data can have conditions/constraints to data that has been mounted from foo.)

So, in the ephemeral you might have

foo-ext
+-- M foos  --> /local/foos
+-- bar

An application/client that accesses ephemeral can access foo 42 via /foo-ext/foos/foo 42.  The fact that the ephemeral datastore turns around as needed, as the golden copy is owned by local, is transparent to the application.  If someone changes foo 42, e.g. because they access the local datastore directly, that will be reflected in the ephemeral datastore by virtue of the fact that it in effect acts as a "cache" to the data in the local datastore.

Now, there are a couple of items to consider:

-          If you want to have a list where some list elements reside on one datastore, others in another, you cannot do that directly.  What you need to do in that case is to introduce a partition (as part of the model that you implement in the ephemeral) that e.g. has a "my-foos" container containing the list elements it authoritatively owns, and a separate "cached-foos" container that "contains" the list elements from the other datastore.

-          Should you be able to have a remote data item contain a local one?  I would argue that you should not allow for that, precisely to avoid the scenario in which the local object get "decapitated" because something happens to the containing objects that are owned by a different system.  If you want to attach a piece of ephemeral data to the remote data item, you should do so with other ways than containment, e.g. adding a leafref to the mounted/referenced remote object.

The distinction to other proposals is that with this proposal, the ephemeral datastore defines its own separate model (which indicates which data it "owns", vs which data it "caches"). Note that the model for the cached data does not need to be redefined; it is used as-is; the fact that there is another datastore which decides to incorporate that information is not something the local datastore needs to be aware of.

Does this answer your questions?
--- Alex

From: Susan Hares [mailto:[email-masked]]
Sent: Friday, September 26, 2014 8:30 AM
To: Alexander Clemm (alex); 'Andy Bierman'; 'Martin Bjorklund'
Cc: 'Jeffrey Haas'; [email-masked]; Eric Voit (evoit)
Subject: RE: [i2rs] Two thoughts on an ephemeral data store

Alexander:

Previous example:

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

Your model:

Questions:

b)  Can I2RS decide later it wants to write-through the golden copy?  Or are variables only "non-write-through" and "write-through"?

Thank you,
Sue Hares

From: i2rs [mailto:[email-masked]] On Behalf Of Alexander Clemm (alex)
Sent: Thursday, September 25, 2014 8:57 PM
To: Andy Bierman; Martin Bjorklund
Cc: Jeffrey Haas; [email-masked]<mailto:[email-masked]>; Eric Voit (evoit)
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

--- Alex

From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, September 25, 2014 8:44 AM
To: Martin Bjorklund
Cc: Jeffrey Haas; [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

/martin

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 28 Sep 2014 00:20:36 -0400

If I am reading you correctly, you are saying taht if an I2RS client is 
manipulating data that is stored in the underlying golden store, you 
want that golden store changed.
I think that won't work for the requirements.  As far as I can tell from 
your proposal, this would result in I2RS changes being stored when 
someone on the CLI does a commit.  Which is not what is wanted.

Conversely, a read-through model would seem to work.  Objects which have 
been created / modified in the I2RS store, when read from the I2RS store 
have their I2RS value.  If you attempt to read or reference a value that 
has not been modified in I2RS, you read-through to the underlying data 
store, and see its value.

Yours,
Joel

On 9/26/14, 7:53 PM, Alexander Clemm (alex) wrote:
> Hi Susan, Andy, all,
>
> there would be two datastore – “local” and “ephemeral”.
>
> The ephemeral datastore implements a separate model “foo-ext”.
>
> This model declares a reference / “mount” to “foos” in the local datastore.
>
> In addition, it defines some other data, that is “owned” by the
> ephemeral datastore.  (This data can have conditions/constraints to data
> that has been mounted from foo.)
>
> An application/client that accesses ephemeral can access foo 42 via
> /foo-ext/foos/foo 42.  The fact that the ephemeral datastore turns
> around as needed, as the golden copy is owned by local, is transparent
> to the application.  If someone changes foo 42, e.g. because they access
> the local datastore directly, that will be reflected in the ephemeral
> datastore by virtue of the fact that it in effect acts as a “cache” to
> the data in the local datastore.
>
> -If you want to have a list where some list elements reside on one
> datastore, others in another, you cannot do that directly.  What you
> need to do in that case is to introduce a partition (as part of the
> model that you implement in the ephemeral) that e.g. has a “my-foos”
> container containing the list elements it authoritatively owns, and a
> separate “cached-foos” container that “contains” the list elements from
> the other datastore.
>
> -Should you be able to have a remote data item contain a local one?  I
> would argue that you should not allow for that, precisely to avoid the
> scenario in which the local object get “decapitated” because something
> happens to the containing objects that are owned by a different system.
> If you want to attach a piece of ephemeral data to the remote data item,
> you should do so with other ways than containment, e.g. adding a leafref
> to the mounted/referenced remote object.
>
> The distinction to other proposals is that with this proposal, the
> ephemeral datastore defines its own separate model (which indicates
> which data it “owns”, vs which data it “caches”). Note that the model
> for the cached data does not need to be redefined; it is used as-is; the
> fact that there is another datastore which decides to incorporate that
> information is not something the local datastore needs to be aware of.
>
> *From:*Susan Hares [mailto:[email-masked]]
> *Sent:* Friday, September 26, 2014 8:30 AM
> *To:* Alexander Clemm (alex); 'Andy Bierman'; 'Martin Bjorklund'
> *Cc:* 'Jeffrey Haas'; [email-masked]; Eric Voit (evoit)
> *Subject:* RE: [i2rs] Two thoughts on an ephemeral data store
>
> Alexander:
>
> a)The value 4711 – would be a “non-golden” copy.
>
> b)It would not be written through to the the “golden copy”.
>
> Questions:
>
> a)How would you specify a “write-through” copy?
>
> b)Can I2RS decide later it wants to write-through the golden copy?  Or
> are variables only “non-write-through” and “write-through”?
>
> c)If we delete foo 42, what happens?
>
> Thank you,
>
> Sue Hares
>
> *From:*i2rs [mailto:[email-masked]] *On Behalf Of *Alexander
> Clemm (alex)
> *Cc:* Jeffrey Haas; [email-masked] <mailto:[email-masked]>; Eric Voit (evoit)
> between different data stores, and some objects that are part of one
> data store need to be reflected in a different data store.
>
> (a)A datastore needs to have a clear way to reference objects in a
> (b)It needs to be clear who owns the “golden copy” of an object.  I
> needs to be clear which objects are “authoritatively owned” by a
> datastore vs which ones are reference.  This is the datastore where the
> object is maintained, updated, created; this is where conditions and
> constraints are evaluated, etc.
>
> datastore, it should incorporate these other objects “by reference”.
> The objects that are authoritatively owned by the ephemeral datastore
> can refer to those objects, have them referred to in conditions and
> constraints, and so on.  (This can also indicate which ephemeral objects
> are to be removed when an object in the other datastore they depend on
> is deleted, etc)
>
> Changes to the non-ephemeral objects (e.g. the running datastore) have
> to be made to the “golden copy”, i.e. the owning datastore.  One way to
> do that involves implementing a “write-through” operation, in which an
> update to an ephemeral copy of the object is realized by having the
> server of the ephemeral datastore turn around and make a corresponding
> request at the other datastore.
>
> copies of the same object in different datastores, requiring “logical
> anding” (or other inter-datastore arithmetic) of different copies
> representing the same object to figure out what actual value is in
> effect, etc.
>
> (http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requirements-00.txt),
> motivating why a it would be useful to have a capability to “mount”
> requirements that such a capability needs to address.  While the
> original use case and motivation described there are somewhat different,
> it seems applicable to the discussion here.
>
> --- Alex
>
> *From:*i2rs [mailto:[email-masked]] *On Behalf Of *Andy Bierman
> *Cc:* Jeffrey Haas; [email-masked] <mailto:[email-masked]>
> Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>  > > Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 28 Sep 2014 12:40:40 +0200

>    foo 42

Lets say more precisely, I assume this would be:

     <foo>
       <id>42</id>
     </foo>

Note that id is required (key) and a is optional.

> ephemeral we now have a single node (a) with value 4711.

I assume your mean ephemeral datastore now contains:

     <foo>
       <id>42</id>
       <a>4711</a>
     </foo>

I do not know what Alexander is proposal but open #4 would merge the
two and the resulting operational state would be:

     <foo>
       <id>42</id>
       <a>4711</a>
     </foo>

This is not a particularly interesting example though...

/js

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 10:54:38 -0400

[Responding in thread order]

> ephemeral we now have a single node (a) with value 4711.

Correct.  

> What happens if we in local config delete foo 42?

The original set for the ephemeral datastore was for id=42, I'd expect the
GET to still return foo id=42 a=4711

> presented to the internal apps?

foo id=42 a=4711

A slightly different example:

local config: foo id=42 a=1

GET returns foo id=42 a=1

SET /foo[id=42]/a to 4711 in the ephemeral datastore.

GET returns foo id=42 a=4711

Two potential actions:
a) Delete /foo[id=42] in the ephemeral datastore.
   GET returns id=42 a=1 (the underlying local config remains)
b) Delete /foo[id=42] in the local config
   GET returns id=42 a=4711 (the overlay ephemeral config)

-----

In general, I'm not expecting the above type of behavior to be a common i2rs
operation where local config and ephemeral config overlap.  When they do,
the above example shows ephemeral having priority over local config - but as
we discussed, that semantic may not always be the desired one.

What I find more likely is either:

foo id=42 a=1 # Datastore local config
foo id=43 a=4711 # Datastore ephemeral 

No overlap.

Or alternatively:
   list foo {
     key id;
     leaf id { type int32; }
     leaf a { type int32; }
     leaf i2rs:b { type int32; }
   }

Where b is introduced either via augmentation from a separate module or
alternatively something like b is explicitly listed in the module defining
foo.  In either case, b is noted to be an item that intended for the
ephemeral data store.  This leads to the question:

SET foo id=42 a=1 # Datastore local config
SET foo id=42 b=4711 # epehemeral data store

GET foo returns id=42 a=1 b=4711

And then:
a) Delete foo id=42 in the local config
   GET returns foo id=42 b=4711 
b) Delete foo id=42 in the ephemeral datastore
   GET returns foo id=42 a=1 

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 11:01:10 -0400

Alex,

> (a)    A datastore needs to have a clear way to reference objects in a different datastore, really have them incorporated into the same namespace.

This was discussed in my draft for the netmod interim.  Right now, that is
an issue if we have them in a different datastore and not in the same
namespace.  The "option 4" is really to have a unified schema across the
datastores and thus we no longer have issues for how to do references.

> (b)   It needs to be clear who owns the "golden copy" of an object.  I needs to be clear which objects are "authoritatively owned" by a datastore vs which ones are reference.  This is the datastore…

This seems obvious, but there are a few potentially conflicting scenarios.

If objects that are always intended to be ephemeral are never going to
conflict (but may lie on top of) local config, there is never a conflict.
There is simply referential integrity issues if the underlying local config
is deleted and ephemeral config remains.

If the objects are always disjoint, there is never a conflict.

But if you permit an ephemeral object to override a local config one within
the schema, we have this issue.  Our options would appear to be:
- Do not permit such overrides.  Design your models so that when it is
  desired to configure the same underlying operational state from multiple
  sources, it is through disjoint pieces of the model.  An example would be
  for static routes to have a local-config mechanism and a completely separate
  ephemeral config model.  This is the "easy" option.
- Permit such overrides as long as the semantics are "clear".

> In the netmod WG, we have today posted a draft for what we refer to as requirements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requirements-00.txt), motivati…

I'll have to ready this draft.  From the title, the ability to "mount" a
subtree was one of the likely use cases in i2rs where augmenting protocol
modules was done rather than "copy and paste" sections (or utilizing well
refactored groupings) in a separate model.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 11:02:36 -0400

On Sun, Sep 28, 2014 at 12:20:36AM -0400, Joel M. Halpern wrote:
> If I am reading you correctly, you are saying taht if an I2RS client
> is manipulating data that is stored in the underlying golden store,
> you want that golden store changed.
> I think that won't work for the requirements.  As far as I can tell
> from your proposal, this would result in I2RS changes being stored
> when someone on the CLI does a commit.  Which is not what is wanted.

I agree with you, Joel.  This doesn't match the semantics the I2RS WG
wanted.

> Conversely, a read-through model would seem to work.  Objects which
> have been created / modified in the I2RS store, when read from the
> I2RS store have their I2RS value.  If you attempt to read or
> reference a value that has not been modified in I2RS, you
> read-through to the underlying data store, and see its value.

Hopefully my most recent example shows this.

-- Jeff

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 30 Sep 2014 12:23:10 -0700

On Sep 25, 2014:6:19 AM, at 6:19 AM, Joel M. Halpern <[email-masked]> wrote:

> Top posting for ease of reading, but retaining the content for those who want context.
> 
> As I understand the shadow proposal, there is the regular local config data store, and then there is a second data store (shadow) used by I2RS for its ephemeral data.  That store is never persisted.  So far, so good.
> 
> Then Andy asked about when they are synchronized, and suggested that they would be sychronized only when the shadow datastore is established by teh first I2RS modification request (if I understood him correctly).
> 
> I don't think that works.  Suppose that I2RS has adjusted data items A and B, creating and filling the shadow data store.  And then someone using CLI / normal NetCONF adjusts item C.  If an I2RS client goes to read C, or does some operation which depends upon the value of C, it has to be working with the new value of C, not the value at the time the ephemeral store was created.

	It might be useful to define the operational semantics of what the shadow data store is.  In my opinion, its modifying a version of the running config of the device.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 30 Sep 2014 16:55:33 -0400

Tom,

> 	It might be useful to define the operational semantics of what the shadow data store is.  In my opinion, its modifying a version of the running config of the device. 

During the interim, the phrase I was using was "active" config.

Effectively when both local config and ephemeral config are both functioning
without issues, logically:

Without ephemeral datastore:
Active = Running

With ephemeral datastore:
Active = Running + Ephemeral.
(I.e. patch running < ephemeral)

The question about whether we have "pull-up/snapshot" of local config on top
of ephemeral or simply "overlay/see-through" is mostly an implementation
detail to cover what happens when there's problems.

-----
Overlay:
Active = patch running < ephemeral

Ephemeral crashes:
Active = running (should still be in tact)

Instead, running goes away
Active = patch NULL < ephemeral

This may lead you to an invalid config.

-----
Snapshot:

Active = cp running ephemeral.candidate ; patch ephemeral.candidate <
ephemeral; mv ephemeral.candidate ephemeral.

Ephemeral crashes: Running config remains.

Instead, running goes away:
Ephemeral = last state of ephemeral, potentially with future changes laid on
top.

In other words, in the snapshot implementation, if you lose local config,
you have the last in tact state of running copied in ephemeral.  You still
must track the individual ephemeral-only changes to lay on top of it.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 30 Sep 2014 13:59:16 -0700

> must track the individual ephemeral-only changes to lay on top of it.

	That makes sense. 

	--Tom

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 1 Oct 2014 04:03:27 +0000

Hi, one reply inline, <Alex>.  
--- Alex

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Monday, September 29, 2014 8:03 AM
To: Joel M. Halpern
Cc: [email-masked]; 'Martin Bjorklund'; Eric Voit (evoit); Alexander Clemm (alex); 'Andy Bierman'; 'Jeffrey Haas'; Susan Hares
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

> when someone on the CLI does a commit.  Which is not what is wanted.

I agree with you, Joel.  This doesn't match the semantics the I2RS WG wanted.

<ALEX> Your understanding is correct.  These are the semantics of the proposal.  When the data in the golden store is changed, it is changed.  It is the authoritative copy; the changes will be visible in the other datastores that reference it / mount it and there is no question which values/settings are in effect.  It's not "panes of glass" semantics where which setting is in effect is computed from overlays of the same object instance across different datastores.  The semantics are simpler.  If you want to have settings that go into effect when something in another datastore is deleted etc, you can still achieve that, but you will need to reflect that explicitly in the model.  Whether that's a tradeoff you're willing to make is I guess subject for discussion.  
</ALEX>

> I2RS store have their I2RS value.  If you attempt to read or reference 
> a value that has not been modified in I2RS, you read-through to the 
> underlying data store, and see its value.

-- Jeff

---

From: Alia Atlas <[email-masked]>
Date: Wed, 1 Oct 2014 00:16:40 -0400

Hi Alex, Tom, Joel, et al.

(top-posting)  In the initial I2RS framework, we had the ideal of different
data lifetimes as well as being able to have
written state be permanent or ephemeral.  The I2RS WG consensus was very
clear that I2RS should only support
ephemeral state and that is reflected in the architecture.

In the architecture, the configuration interacts with an I2RS Agent based
on the relative priorities of the configuration
and the I2RS client that wrote the state.  An easy example - certainly what
I'd assume to occur while gaining initial
experience - is that the configuration always overrules I2RS Clients.  If
state is written by an I2RS client that depends
on configuration and the configuration is deleted, then the I2RS client's
state is also deleted and the client is notified.
This is what would happen if it were another I2RS client that caused the
change as well.

I'm quite happy to see focused discussion on how we can actually use YANG
for I2RS in the nitty-gritty details, but I am
concerned that what we end up with is what I2RS is rather than a different
animal.

no-hats Alia

On Wed, Oct 1, 2014 at 12:03 AM, Alexander Clemm (alex) <[email-masked]>
wrote:

> Cc: [email-masked]; 'Martin Bjorklund'; Eric Voit (evoit); Alexander Clemm
> (alex); 'Andy Bierman'; 'Jeffrey Haas'; Susan Hares
> <ALEX> Your understanding is correct.  These are the semantics of the
> proposal.  When the data in the golden store is changed, it is changed.  It
> is the authoritative copy; the changes will be visible in the other
> datastores that reference it / mount it and there is no question which
> values/settings are in effect.  It's not "panes of glass" semantics where
> which setting is in effect is computed from overlays of the same object
> instance across different datastores.  The semantics are simpler.  If you
> want to have settings that go into effect when something in another
> datastore is deleted etc, you can still achieve that, but you will need to
> reflect that explicitly in the model.  Whether that's a tradeoff you're
> willing to make is I guess subject for discussion.
> </ALEX>
>
>

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 1 Oct 2014 05:38:00 +0000

Hello Jeff,

just one brief reply/comment to point (b) in your summary, inline

Thanks
--- Alex

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Monday, September 29, 2014 8:01 AM
To: Alexander Clemm (alex)
Cc: Jeffrey Haas; [email-masked]; Martin Bjorklund; Eric Voit (evoit); Andy Bierman
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

...

If objects that are always intended to be ephemeral are never going to conflict (but may lie on top of) local config, there is never a conflict.
There is simply referential integrity issues if the underlying local config is deleted and ephemeral config remains.

But if you permit an ephemeral object to override a local config one within the schema, we have this issue.  Our options would appear to be:

<ALEX> Yes,  and the third option is the one in which you treat the datastores as separate entities in which references and dependencies as well as what constititutes the "golden copy" are explicitly exposed  instead of being implicitly manged.  
Of course there are some constraints that need to be imposed on the model and what's allowed, such as not allowing a "local" object to be contained in and existentially depend on a "remote" object owned by a different datastore, due to the referential integrity issues that you point out.  I would consider such constraints features, not limitations of the model.  
</ALEX>

...