Subject: [i2rs] Point about writable running

From: Joe Clarke <[email-masked]>
Date: Thu, 13 Nov 2014 21:57:56 -0500

During today's meeting Dean made a comment that we could use writable 
running as a way to do ephemeral state.  I have a concern about this.  I 
know it may seem like an implementation detail, but I feel that most 
vendors (and operators) assume that things in the running datastore 
_could_ become persistent.

That is, if I write to the running data store, and my human user sees 
these I2RS ephemeral state in the "show running-config" (or the like), 
they might think those are persistent.  There is no indication that they 
are ephemeral.  On top of that, some NMS systems that use 
screen-scraping for config archive might grab this ephemeral config and 
later restore state that should not be restored.

I just wanted to bring this up as I would rather see more of the panes 
of glass approach rather than try to override an existing datastore for 
this kind of thing.  Or maybe I misunderstood Dean's comment...

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Nov 2014 22:06:07 -0500

I agree Joe.  The challenge with using any of the existing stores is 
that if someone says "commit" they need to get the NetConf / RestConf 
normal changes to that, but not the I2RS changes.

Yours,
Joel

On 11/13/14, 9:57 PM, Joe Clarke wrote:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Nov 2014 19:46:40 -0800

On Thu, Nov 13, 2014 at 6:57 PM, Joe Clarke <[email-masked]> wrote:
> know it may seem like an implementation detail, but I feel that most vendors
> (and operators) assume that things in the running datastore _could_ become
> persistent.
>
> That is, if I write to the running data store, and my human user sees these
> I2RS ephemeral state in the "show running-config" (or the like), they might
> think those are persistent.  There is no indication that they are ephemeral.
> On top of that, some NMS systems that use screen-scraping for config archive
> might grab this ephemeral config and later restore state that should not be
> restored.
>

I think the local-config=persistent assumption is flawed.
In IOS, local config does not persist unless and until the "write mem"
command is invoked. Persistence is often an operator decision,
not hard-wired into the transaction.

> I just wanted to bring this up as I would rather see more of the panes of
> glass approach rather than try to override an existing datastore for this
> kind of thing.  Or maybe I misunderstood Dean's comment...

I agree.
Tagging the config data as ephemeral does not work if
the local config needs to re-activate once the I2RS state is removed.
(e.g., next-hop example).  A YANG instance-identifier cannot
distinguish between the config and ephemeral versions of each node.

I think Dean meant the I2RS edits take effect right away, like
:writable-running in NETCONF.  There is no commit phase,
like with the candidate datastore.

> Joe

Andy

---

From: "Fedyk, Don" <[email-masked]>
Date: Fri, 14 Nov 2014 04:08:29 +0000

Hi

I've been trying to understand the models here.  To me what we are describing is a general case of 2 entities trying to configure a switch. 

Consider one operator or user for short.
A user may be able to write to the running config datastore some subset. 
A user may copy that to the config datastore (save config).  (If they do not the copy the running subset is ephemeral)
Also:
A user may write to a candidate config datastore some subset. 
A user may verify/activate the candidate config. 
A user may commit that candidate config (once running) (save config). (If they do not commit that config subset is ephemeral).
Some devices do not support all config operations. 

Then consider two users trying both to config the same device. 
A  user may be blocked from changing config items that are currently ephemeral. 
A user may be allowed to override the config items that are ephemeral. 
The override may be priority based where user A with higher priority can override user B but not the reverse. 

So if the user A is i2rs agent and the user B is an operator where the config items may allow priority per item,  doesn't this cover the bases for what is needed? 

Cheers,
Don

> -----Original Message-----
> From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Thursday, November 13, 2014 10:06 PM
> To: Joe Clarke; [email-masked]
> Subject: Re: [i2rs] Point about writable running
> 
> I agree Joe.  The challenge with using any of the existing stores is that if
> someone says "commit" they need to get the NetConf / RestConf normal
> changes to that, but not the I2RS changes.
> 
> Yours,
> Joel
> 
> > running as a way to do ephemeral state.  I have a concern about this.
> > I know it may seem like an implementation detail, but I feel that most
> > they might think those are persistent.  There is no indication that
> > they are ephemeral.  On top of that, some NMS systems that use
> > screen-scraping for config archive might grab this ephemeral config
> > and later restore state that should not be restored.
> >
> > of glass approach rather than try to override an existing datastore
> > for this kind of thing.  Or maybe I misunderstood Dean's comment...
> >
> > Joe
> >
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Nov 2014 23:16:56 -0500

The case that causes complications for treating only one store is:
1) You have a running box, with a CLI client A and an I2RS client.  The 
I2RS client understands and expects that its changes will NOT be committed.

2) In some order, A and B each make changes in the device.  It is 
sufficient for this case that they are completely non-overlapping changes

3) After both changes have been made, and the box is running happily, 
the CLI client says "commit".

In order to meet the I2RS requirements, the data that the I2RS client 
has provided MUST NOT be saved in persistent store.  Things may well 
break if it is stored.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Nov 2014 23:21:26 -0500

Just to finish what I did not mention, remember that I2RS does not lock, 
and is expected to ignore any Netconf locks.  (I think this is similar 
how restconf is expected to work, but I am not sure.)

Yours,
Joel

On 11/13/14, 11:16 PM, Joel M. Halpern wrote:
>> I've been trying to understand the models here.  To me what we are
>> describing is a general case of 2 entities trying to configure a switch.
>>
>> A user may copy that to the config datastore (save config).  (If they
>> do not the copy the running subset is ephemeral)
>> Also:
>> A user may commit that candidate config (once running) (save config).
>> (If they do not commit that config subset is ephemeral).
>> So if the user A is i2rs agent and the user B is an operator where the
>> config items may allow priority per item,  doesn't this cover the
>> bases for what is needed?
>>
>> Cheers,
>> Don
>>
>>> that if

---

From: "Fedyk, Don" <[email-masked]>
Date: Fri, 14 Nov 2014 04:22:41 +0000

Then the commit from A would have to be "commit what A wrote to running store" not "commit the running store".   No?

Don

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, November 13, 2014 11:17 PM
> To: Fedyk, Don; Joe Clarke; [email-masked]
> 1) You have a running box, with a CLI client A and an I2RS client.  The I2RS
> client understands and expects that its changes will NOT be committed.
> 
> 2) In some order, A and B each make changes in the device.  It is sufficient for
> this case that they are completely non-overlapping changes
> 
> 3) After both changes have been made, and the box is running happily, the CLI
> client says "commit".
> 
> In order to meet the I2RS requirements, the data that the I2RS client has
> provided MUST NOT be saved in persistent store.  Things may well break if it is
> stored.
> 
> Yours,
> Joel
> 
> > A user may commit that candidate config (once running) (save config). (If
> they do not commit that config subset is ephemeral).
> > So if the user A is i2rs agent and the user B is an operator where the config
> items may allow priority per item,  doesn't this cover the bases for what is
> needed?
> >
> > Cheers,
> > Don
> >
> >>> During today's meeting Dean made a comment that we could use
> >>> writable running as a way to do ephemeral state.  I have a concern about
> this.
> >>> I know it may seem like an implementation detail, but I feel that
> >>> most vendors (and operators) assume that things in the running
> >>> datastore _could_ become persistent.
> >>>
> >>> That is, if I write to the running data store, and my human user
> >>> sees these I2RS ephemeral state in the "show running-config" (or the
> >>> like), they might think those are persistent.  There is no
> >>> indication that they are ephemeral.  On top of that, some NMS
> >>> systems that use screen-scraping for config archive might grab this
> >>> ephemeral config and later restore state that should not be restored.
> >>>
> >>> I just wanted to bring this up as I would rather see more of the
> >>> panes of glass approach rather than try to override an existing
> >>> datastore for this kind of thing.  Or maybe I misunderstood Dean's
> comment...
> >>>
> >>> Joe
> >>>
> >>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Nov 2014 23:28:04 -0500

I don't recall seeing that form of commit in any protocol that has been 
proposed.  I think it would be rather hard to do.

Yours,
Joel

---

From: "Fedyk, Don" <[email-masked]>
Date: Fri, 14 Nov 2014 05:04:49 +0000

What is the alternative?  
Lock out operators from committing a running datastore when anything is I2RS ephemeral?  Is there an I2RS withdraw ephemeral? How would a user invoke that? 

I think I2rs could also accidentally commit any users ephemeral config too without a mechanism to prevent it. It works both ways. 

Cheers,
Don 

> Sent: Thursday, November 13, 2014 11:28 PM
> > Then the commit from A would have to be "commit what A wrote to running
> store" not "commit the running store".   No?
> >
> > Don
> >
> >> 1) You have a running box, with a CLI client A and an I2RS client.
> >> The I2RS client understands and expects that its changes will NOT be
> committed.
> >>
> >>> A user may copy that to the config datastore (save config).  (If
> >>> they do not the copy the running subset is ephemeral)
> >>> Also:
> >>> The override may be priority based where user A with higher priority
> >>> can
> >> override user B but not the reverse.
> >>>
> >> items may allow priority per item,  doesn't this cover the bases for
> >> what is needed?
> >>>
> >>> Cheers,
> >>> Don
> >>>
> >>>> I agree Joe.  The challenge with using any of the existing stores
> >>>> is that if someone says "commit" they need to get the NetConf /
> >>>> RestConf normal changes to that, but not the I2RS changes.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>>> sees these I2RS ephemeral state in the "show running-config" (or
> >>>>> the like), they might think those are persistent.  There is no
> >>>>> systems that use screen-scraping for config archive might grab
> >>>>> this ephemeral config and later restore state that should not be
> restored.
> >>>>>

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 14 Nov 2014 00:10:10 -0500

I2RS has no commit operation in its spec.  This was discssued by the WG, 
and we specifically agreed that I2RS settings are never committed / 
persisted.

There are multiple proposed approaches to solutions that may well be 
viable.  If it can be made to work, the two spaces with references from 
ephemeral to regular (I think that is model 2) seems a good starting 
point to meet the requirements.  It may be that this can be made 
equivalent to models 1 or 4, in which case that is okay with me too.

Yours,
Joel

---

From: Kent Watsen <[email-masked]>
Date: Sun, 16 Nov 2014 06:09:28 +0000

Joel,

RESTCONF will return 409 (Conflict) if a NETCONF datastore is locked. 

Thanks,
Kent

> On Nov 13, 2014, at 8:21 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Just to finish what I did not mention, remember that I2RS does not lock, and is expected to ignore any Netconf locks.  (I think this is similar how restconf is expected to work, but I am not sure.)
> 
> Yours,
> Joel
> 
>>> can override user B but not the reverse.
>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 16 Nov 2014 05:55:31 -0500

Thanks.  It sounds like we will need to be careful with the structure of 
what is being referenced so as not to run into locking issues.  Most of 
the suggestions I have heard make that sound doable.

Yours,
Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Nov 2014 11:15:56 +0100

Hi,

just to clarify:

  If you write to the running configuration datastore (e.g., via
  RESTCONF) and the running configuration datastore is locked, then
  the write is rejected.

If there were a separate ephemeral datastore, then this ephemeral
datastore may not have locks and there may be some form of a policy
that controls how ephemeral content and running config datastore
content is merged into what controls the behavior of the box.

/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: Jeffrey Haas <[email-masked]>
Date: Fri, 28 Nov 2014 14:39:21 -0500

Joel,

On Thu, Nov 13, 2014 at 11:28:04PM -0500, Joel M. Halpern wrote:
> I don't recall seeing that form of commit in any protocol that has
> been proposed.  I think it would be rather hard to do.

One of the prior complicating details had been I2RS saying we'd use "netconf
and restconf" when we selected our protocol earlier this year.  

As we've since seen, netconf commit and datastore semantics (protocol
components) significantly complicate our needs.  This has been a detail that
I believe is pushing netconf off the table and moving us more firmly into
restconf.

This "thrashing of requirements" comes not from any mis-intention, but
mostly a lack of understanding of underlying protocol components by people
who are more interested or studied in protocols or modeling.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 29 Nov 2014 12:41:49 +0100

> I believe is pushing netconf off the table and moving us more firmly into

I like to understand this better. My understanding is that there are
several implementations underway that use the same backend
infrastructure for both NETCONF and RESTCONF. So I wonder how RESTCONF
exposes datastore semantics that are simpler to deal with than NETCONF
datastore semantics. I personally find the 'unified' datastore defined
in RESTCONF somewhat handwaving.

   Each RESTCONF edit of a datastore resource is saved to non-volatile
   storage in an implementation-specific matter by the server.  There is
   no guarantee that configuration changes are saved immediately, or
   that the saved configuration is always a mirror of the running
   configuration.

This leaves it completely up to the implementation what is made
persistent and when. While this may be great for implementors, I am
not sure how this gives you predictable semantics needed to build
implementations that work with different protocol implementations.

Yes, I this is an issue I should raise on the NETCONF list. But for
me, a protocol with unclear semantics is even harder to deal with than
a protocol where it is actually clear in which situations which
content is made persistent.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Nov 2014 18:38:16 -0800

> implementations that work with different protocol implementations.

Not what, just when.  The text is intended to allow for implementations
that may NV-save in the background, so a reboot just after an
edit may or may not come back.  I will try to clarify this text in the
-04 version.

> content is made persistent.

IMO the combination of RESTCONF (+ TBD extensions)
and YANG Patch allows the client to clearly specify the intended results,
and the unified datastore lets the server integrate the ephemeral datastore
with the running config and the operational state however it wants.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Nov 2014 21:42:11 -0500

I can not tell from your description Andy who has control and who has 
predictability.  If the device folds the I2RS changes into the permanent 
state, and saves them, it will make a mess with the way the WG has 
assumed things to work.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Nov 2014 19:54:48 -0800

On Sat, Nov 29, 2014 at 6:42 PM, Joel M. Halpern <[email-masked]> wrote:
> state, and saves them, it will make a mess with the way the WG has assumed
> things to work.
>

I am not suggesting the I2RS edits ever change the running or persistent
configuration.  The TBD extensions include some mechanism to
tell RESTCONF to edit the ephemeral config instead of any other datastore.

ephemeral for I2RS:

  PATCH /restconf/edata

running for RESTCONF:

  PATCH /restconf/data

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Nov 2014 23:52:51 -0500

Thank you.  That sounds like a useful path to go down.
Yours,
Joel

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 30 Nov 2014 10:21:50 +0100

> tell RESTCONF to edit the ephemeral config instead of any other datastore.

But what if the same parameter appears both in edata and data? Let's say
it is "hostname". What happens if it is edited in edata? If the same
change is not applied in /restconf/data, then a RESTCONF client that
doesn't know about edata has no way to discover the actual hostname the
system is using.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 30 Nov 2014 10:26:20 +0100 (CET)

> I believe is pushing netconf off the table and moving us more firmly into

Just to be clear; the semantics you are talking about are not inherent
to the *protocol*, they are tied to the *datastore*.  This means that
NETCONF and RESTCONF will show similar behavior (somewhat dependant on
which capabilities NETCONF advertises; as has been pointed out the
client has more control over the NETCONF datastores, leading to more
predictable behavior).

So the reasoning should not be: "NETCONF commit has unwanted semantics
and/or performace, therefore we should use RESTCONF".  Rather it
should be "Writes to the configuration datastore has unwanted
semantics and/or performace, therefore we need to carefully define the
semantics for the new ephemeral datastore" - and once that is done it
is trivial to define the necessary protocol extensions for both
NETCONF and RESTCONF.

Another way of stating this is that NETCONF commit semantics don't
matter if I2RS defines a new ephemeral datastore.  (Modulo
interactions with the config datastore).

/martin