Subject: [Rtg-yang-coord] YANG leaf writing to running-datastore

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 02 Mar 2015 22:42:55 +0000

Is there a way to restrict having a leaf be written to running datastore
only? In other words, the leaf should never be written to startup
datastore. Along the lines of an ephemeral datastore, except in this case
it is a configuration parameter, and not something the device has learnt.

The particular case that comes to mind is putting an ethernet port in
loopback mode. This is done mainly to put the port in a debug mode, and is
meant to be temporary. But under no circumstance should it ever be written
to a saved datastore in a way that the port comes up in loopback mode.

If there is no such capability today, can we consider adding it?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Mar 2015 01:19:57 +0100

> If there is no such capability today, can we consider adding it?

There is no such capability today.

Ephemeral datastores were discussed last year. An ephemeral datastore
would most likely provides the functionality you are looking for but I
am not sure this idea is actively pushed forward by anyone at this
point in time.

The closest you have today is a device that supports an explicit
startup datastore. After copying changes to <startup>, you can modify
<running> and the changes will not persist until to copy <running>
back to <startup>. But of course, this is brittle if there are
multiple changes and some should persist but others not. This is what
let to the notion of ephemeral datastores.

/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: David Ball <[email-masked]>
Date: Tue, 03 Mar 2015 09:55:30 +0000

Wouldn't that be best done with an RPC?

     David

On 02/03/15 22:42, Mahesh Jethanandani wrote:
> Is there a way to restrict having a leaf be written to running 
> datastore only? In other words, the leaf should never be written to 
> startup datastore. Along the lines of an ephemeral datastore, except 
> in this case it is a configuration parameter, and not something the 
> device has learnt.
>
> loopback mode. This is done mainly to put the port in a debug mode, 
> and is meant to be temporary. But under no circumstance should it ever 
> be written to a saved datastore in a way that the port comes up in 
> loopback mode.
>
> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

-- 
David Ball
<[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Mar 2015 11:12:09 +0100

> Wouldn't that be best done with an RPC?

An ephemeral data store would provide a generic solution for this kind
of problem. RPCs tend to be specific (or you invent a generic RPC that
actually models an ephemeral data store).

/js

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Tue, 3 Mar 2015 13:42:20 +0000

Adding netconf into this as we're talking about generic netconf functionality here.

The concept of having other (somewhat arbitrary) data stores is something that may be useful for this "debug" type of configuration.  It may even make sense to have both a debug-running & a debug-startup datastore for debug (and perhaps a debug-candidate as well).  Some implementations effectively treat debug as a separate datastore (e.g. allow saving debug info separately from the rest of the configuration).

A similar approach may also make sense for Lawful Interception configuration which is often treated separately from the rest of config.

I think we'd have to extend the <hello> in some way to indicate which capabilities (which yang modules) apply to which datastores.

Jason

-----Original Message-----
From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, March 03, 2015 5:12 AM
To: David Ball
Cc: Mahesh Jethanandani; [email-masked]
Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore

> Wouldn't that be best done with an RPC?

An ephemeral data store would provide a generic solution for this kind of problem. RPCs tend to be specific (or you invent a generic RPC that actually models an ephemeral data store).

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Mar 2015 14:57:10 +0100

Hi,

please consult the NETMOD physical interim minutes (September 2015)
and followup discussions on the I2RS list concerning ephemeral
datastores. If people find some of this useful, someone needs to
condense the ideas into an I-D. (Note that the motivation back then
was to deal with I2RS injected ephemeral config state.)

/js