Subject: [i2rs] extended datastores slide

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jun 2015 06:24:25 -0700

Hi,

I prepared 1 slide (based on Kent's slide).
I am trying to understand the types of data
and how they are identified in YANG and conceptually
separated for protocol access.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jun 2015 09:28:49 -0400

The separations and effects shown there match my understanding.
Thank you,
Joel

On 6/24/15 9:24 AM, Andy Bierman wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 24 Jun 2015 09:35:45 -0400

Andy: 

I will post this slide for the i2RS meeting. 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, June 24, 2015 9:24 AM
To: [email-masked]; [email-masked]
Subject: [i2rs] extended datastores slide

Hi,

 

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jun 2015 06:52:38 -0700

Hi,

thanks.
A few details of the solution I am working on...

1) defaults are not used in the ephemeral datastore

The default-stmt is altered for the ephemeral datastore.
Default leafs are ignored (except for XPath evaluation).
Otherwise the schema default would always override the configuration.

2) XPath hierarchy is based on config-stmt.

  config=true context node -> can reference config=true
  config=ephemeral context node -> can reference true + ephemeral
  config=false context node -> can reference true, ephemeral, false

3) must/when evaluation applies only to the datastore indicated by
config-stmt
     config=true -> running
     config=ephemeral -> ephemeral
     config=false -> operational

4) panes of glass applied to data instances
    all running datastore instances are visible in the ephemeral datastore
    all ephemeral datastore instances are visible in the operational
datastore

5) admin-foo and oper-foo can go away

  The instance of 'admin-temp' in the operational datastore would return
  the value in effect, not the desired value, so 'oper-temp' is not needed
  and the correlation between config, ephemeral, and operational is
maintained
  in the common instance-identifier in all 3 datastores

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Jun 2015 16:23:56 +0200 (CEST)

Hi,

> A few details of the solution I am working on...

I would (still!) use a new statement "i2rs:ephemeral true;" to mark
ephemeral nodes on config false nodes.  This can be done w/o changing
YANG.

> Otherwise the schema default would always override the configuration.

I see your point, but if I create a list instance entirely in the
ephemeral data store, I would assume defaults in that list instance to
be used.

I think the logic should be that if no value is set in the config or
ephemeral, then the default value is used.  The ephemeral value
overrides the configured value.

> 5) admin-foo and oper-foo can go away

Yes, but I assume that they don't *have* to go away.  For example, the
duplex example would still have two nodes, since the syntax is
different.

>   in the common instance-identifier in all 3 datastores

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jun 2015 07:33:13 -0700

> overrides the configured value.
OK

> duplex example would still have two nodes, since the syntax is

I didn't say "have" -- I said "can"
I think the OC folks are right that the same syntax could be used but
the operational value would never be 'auto'.  A separate object
is better though (in this case).

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Jun 2015 16:37:59 +0200 (CEST)

> is better though (in this case).

Yes, agreed; I just wanted to be sure.  I think this is worth pointing
out explicitly.  In many cases the oper- node is not needed, but it
might be.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jun 2015 08:11:20 -0700

On Wed, Jun 24, 2015 at 7:34 AM, Phil Shafer <[email-masked]> wrote:

> Andy Bierman writes:
> List instances in the ephemeral datastore with no matching
> instance in the committed datastore would need to have
> default values from the schema.
>
> Think of defaults as the pane of glass that sits behind
> all other planes.
>
>
good point

> Are you talking about must/when statements in config false nodes?
>

yes -- all values of config-stmt

>
> I think the key point is that the committed config must be valid
> without references anything else.  The ephemeral config must be
> valid without referencing config false nodes.
>

exactly -- that is what I was trying to say above

> ephemeral nodes should be able to reference config=true nodes.
> An ephemeral interfaces should be able to reference a pre-configured
> filter/policer.  But the reverse would not be true.
>
>

The issue is where to enforce the YANG datastore validation for must/when.
The "portability" of must/when is a general problem, but more datastores
makes
it more complicated

> What is "all running datastore instances"?
>

All the data instances (like interfaces) are visible in the ephemeral
for the purpose of XPath and path-stmt (leafref) evaluation

> The issues remain: what happens when the set of possible values
> varies between the operational world and the configuration world?
>

New notifications can be defined to let a client know when a data resource
converges or diverges from the configured value.

> How is that expressed in the data model?  "auto" would not be an
> operational value for "duplex".  "none" would not be a valid
> configuration value, but would be the operational value for an
> empty port.
>

good point -- the operational instance would not exist is the status is
'none'

> Thanks,
>  Phil

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jun 2015 10:52:02 -0700

On Wed, Jun 24, 2015 at 10:14 AM, Phil Shafer <[email-masked]> wrote:

> Why not?  The interface might exist but not have an ethernet
> cable plugged in.  "show interfaces" would show the physical
> instance, but duplex could be "none".
>
>

OK -- good point

In NETCONF terms, a new <get> parameter or
a new <get-operational> operation could be used
to read the operational datastore.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Jun 2015 18:35:01 +0200

> separated for protocol access.

I do not understand the 'config ephemeral' on the left side. I think
it is the implementation (or its configuration) that decides which
data models also exist in the ephemeral data store.

/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: Andy Bierman <[email-masked]>
Date: Thu, 25 Jun 2015 09:45:24 -0700

> data models also exist in the ephemeral data store.

This is to allow for data that can only be edited in the ephemeral datastore
instead of running or ephemeral datastore.  It allows the XPath (and other
rules)
to be different than the existing rules for the running datastore.

My slide did not go as far as Jeff wanted wrt/ allowing ephemeral data
to reference operational data, but I think this would be OK.

As Jeff pointed out, the ephemeral data does not exist until
a controller creates it, unlike the persistent config that will be
applied at boot-time before the operational state exists.

/js

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 25 Jun 2015 13:02:28 -0400

Juergen: 

Where would you put the "config ephemeral"?

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, June 25, 2015 12:35 PM
To: Andy Bierman
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] [netmod] extended datastores slide

On Wed, Jun 24, 2015 at 06:24:25AM -0700, Andy Bierman wrote:
> I am trying to understand the types of data and how they are 
> identified in YANG and conceptually separated for protocol access.
> 

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Jun 2015 19:11:56 +0200

> Where would you put the "config ephemeral"?

Perhaps this is not needed.

/js

---

From: Phil Shafer <[email-masked]>
Date: Wed, 24 Jun 2015 10:34:15 -0400

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 24 Jun 2015 10:46:27 -0400

>out explicitly.  In many cases the oper- node is not needed, but it

Would we be better of having YANG statements that detail the
way the model changes between config and operational modes?
Otherwise the tie-in between the oper-leaf and config-leaf
needs to be modeled.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 24 Jun 2015 13:14:49 -0400

Thanks,
 Phil