I have to agree with Tom, we have to make it simple. What configuration is written where is a matter of policy. Each administrator can/will have different policies what is written where.
In my opinion config and ephemeral config are merged together with OR function (cfg || eph) = active config For simplicity, if there is a dependency on configuration from persistent config, minimum working cfg should be copied to ephemeral. Even if admin decides to shut down that functionality, admin can go into all data stores, persistent, running and ephemeral DB and remove it from there and disallow changes until further notice. It is very hard to standardize policies and I don't think we should do it. Dean On Oct 1, 2014, at 2:47 AM, Juergen Schoenwaelder <[email protected]> wrote: > Tom, > > this is correct only if the NETCONF server supports the :startup > capability. During the interim, I said that there are certain > 'synchronization points' at which the running datastore is made > persistent. What these 'synchronization points' are depends on the > capabilities of the NETCONF server. In other words, I2RS should assume > that the 'running configuration datastore' is generally persistent > (even if there may be periods where this is not true, until the next > 'synchronization points' has been reached. > > The main reason we discussed ephemeral datastores is that they will > never have any 'synchronization points'. > > /js > > On Tue, Sep 30, 2014 at 06:34:32PM -0700, Thomas Nadeau wrote: >> The running config is by virtue not preserved until an action to save it is >> made. Of the operator wishes to save the running config then yes they >> "commit" it. >> >> I honestly think we're making this harder than it needs to be. >> >> Tom >> >> >> >> >>> On Sep 30, 2014, at 6:23 PM, Joel M. Halpern <[email protected]> wrote: >>> >>> There are multiple problems with "just copying it to running." >>> The primary one is that as per the I2RS WG rough consensus, the I2RS mods >>> are not supposed to be preserved across a restart. >>> But if they are copied to running, and an operator then does a commit, they >>> will get preserved. >>> In fact, if they get copied to running, and an operator then makes other >>> changes and wants to commit them, he can't help but commit the I2RS changes. >>> >>> Yours, >>> Joel >>> >>>> On 9/30/14, 8:35 PM, Thomas Nadeau wrote: >>>> >>>> >>>> >>>> >>>>> On Sep 30, 2014, at 4:52 PM, Joel M. Halpern <[email protected]> wrote: >>>>> >>>>> I was tyring to understand the descriptions being used. >>>>> >>>>> After looking back at the email, and talk to folks, there seem to be two >>>>> different issues. >>>>> >>>>> The first one is what happens the complete running config disappears. >>>>> As far as I am concerned, the device can do anything it wants, and >>>>> whatever it does is probably wrong. After all, for the running config to >>>>> disappear there have to be very serious problems. >>>> >>>> Yea >>>> >>>>> >>>>> The second issue is what happens when something (foo) is deleted from the >>>>> running config, but some property of that thing (foo/a) has been set by >>>>> I2RS. Unfortunately,as far as I can tell, there is not a good general >>>>> rule. >>>> >>>> The simple solution is to make the i2rs config changes apply immediately >>>> to the running config/state. >>>> >>>>> Some examples: >>>>> If the operator takes down BGP, and deletes the full BGP configuration, >>>>> then the presence of I2RS policy rules should not cause BGP to keep >>>>> running. >>>>> On the other hand, if foo is a static route create by operations, and >>>>> then I2RS modified the next hop for that route, I tend to suspect that >>>>> the route I2RS has "created" by doing so should stay around even if the >>>>> operator goes in a deletes the static route. >>>>> >>>>> I suspect that the issue is determining what scope is being created when >>>>> I2RS writes b/c/d/foo/a. I don't think it is obvious or that there is a >>>>> consistent rule. >>>> >>>> If you make it just write to the running config, you have no issues. >>>> >>>> Tom >>>> >>>> >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> _______________________________________________ >>>>> 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 > > -- > 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/> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
