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
On 11/14/14, 12:04 AM, Fedyk, Don wrote:
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
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 13, 2014 11:28 PM
To: Fedyk, Don; Joe Clarke; [email protected]
Subject: Re: [i2rs] Point about writable running
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
On 11/13/14, 11:22 PM, Fedyk, Don wrote:
Then the commit from A would have to be "commit what A wrote to running
store" not "commit the running store". No?
Don
-----Original Message-----
From: Joel M. Halpern [mailto:[email protected]]
Sent: Thursday, November 13, 2014 11:17 PM
To: Fedyk, Don; Joe Clarke; [email protected]
Subject: Re: [i2rs] Point about writable running
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
On 11/13/14, 11:08 PM, Fedyk, Don wrote:
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 protected]] On Behalf Of Joel M.
Halpern
Sent: Thursday, November 13, 2014 10:06 PM
To: Joe Clarke; [email protected]
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
On 11/13/14, 9:57 PM, Joe Clarke wrote:
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
