Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Oct 2014 13:57:29 +0000

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-masked]> 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-masked]> 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-masked]> 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-masked]
>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>> 
>>> _______________________________________________
>>> i2rs mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>> 
>> 
>> _______________________________________________
>> i2rs mailing list
>> [email-masked]
>> 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-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Oct 2014 10:08:42 -0400

> The simple solution is to make the i2rs config changes apply immediately to the running config/state.

This is the perspective I've been working from.

Even so, the semantics of what happens when an underlying change to local
config invalidates the ephemeral config.  What do we do?

This is the point Andy Bierman keeps coming to.

-- Jeff (who has opinions, but needs to hear the WG)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 01 Oct 2014 10:43:28 -0400

I can live with that model.
Simplified and repeated:
If an object is deleted in running, and the object itself was not 
created as a whole in I2RS, then the object, and any changes to elements 
within the object, is also deleted in the I2RS ephemeral store, even if 
some I2RS clients had written some of those elements.

I would expect I2RS to generate notifications of those deletions.

This gives us a consistent operating paradigm, with a means for I2RS 
clients to be more explicit about their intent, without creating 
significant complexity.

Yours,
Joel

On 10/1/14, 2:43 AM, Juergen Schoenwaelder wrote:
> On Tue, Sep 30, 2014 at 07:52:13PM -0400, Joel M. Halpern wrote:
>
>> 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.
>>
>> 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.
>
> If I2RS only modifies the next hop and the underlying route is delete
> from config, then the route should be removed from the operational
> state. If I2RS wants the route to persist even if the underlying
> config goes away, then the I2RS client has to inject a complete
> routing record overlaying the underlying route from config. I believe
> this is actually simple as long as we keep it simple.
>
> /js
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 1 Oct 2014 08:08:02 -0700

On Oct 1, 2014:7:43 AM, at 7:43 AM, Joel M. Halpern <[email-masked]> wrote:

> If an object is deleted in running, and the object itself was not created as a whole in I2RS, then the object, and any changes to elements within the object, is also deleted in the I2RS ephemeral store, even if some I2RS clients had written some of those elements.

	This is another simplification: the I2RS objects MUST be a subset of what is available in the normal/running config.

> I would expect I2RS to generate notifications of those deletions.

	Or just define notifications on the store as you normally can in the yang model.  Is there really a need for special "i2rs" notifications or just config-change-related ones?

> This gives us a consistent operating paradigm, with a means for I2RS clients to be more explicit about their intent, without creating significant complexity.

	Lets try! 8)

	--Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 01 Oct 2014 11:11:29 -0400

What does "must be a subset" mean?
There are actuyally levels of that which I think the I2RS work could 
accept.  Prohibiting I2RS from starting OSPF when it was not running is 
probably reasonable.
On the other hand, prohibiting I2RS from creating a new static route to 
a destination is clearly not workable.

But both of those are creating a new portion of the tree, within an 
existing tree (namely the whole configuration.)

So this "simplification" does not seem to mean anything.
One of the nice things abotu Juergen's proposal is that it does not say 
"I2RS can not do X."  Rather it, says "to do X, I2RS must use mechanism 
Y".

Yours,
Joel

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Oct 2014 15:16:26 +0000

Tom,

> 	This is another simplification: the I2RS objects MUST be a subset of what is available in the normal/running config.

Do you mean by what is currently active in the normal running config or what is possible to be in the normal running config. 
I would say it: I2RS object CAN be any subset of what is available in the normal/running config.

Dean

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 1 Oct 2014 08:40:35 -0700

> I would say it: I2RS object CAN be any subset of what is available in the normal/running config.

	Im going from a netconf/yang model perspective with the assumption that %100 of a configuration is modeled in yang and operationally available via netconf (or restconf).  If you then think of this configuration as a configuration set of objects, I like to think about i2rs as a proper subset of this.  Operational reality also shows this to be the case. There seems to be no good reason to have something you can configure/read from this set of objects that differs if you use the i2rs "protocol" versus netconf/restconf.

	--Tom

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Oct 2014 16:00:03 +0000

Tom,

I'm in agreement with you. Thank you for clarifying it.

Dean

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 2 Oct 2014 10:11:13 -0400

On Wed, Oct 01, 2014 at 08:40:35AM -0700, Thomas D. Nadeau wrote:
> Im going from a netconf/yang model perspective with the assumption that
> %100 of a configuration is modeled in yang and operationally available via
> netconf (or restconf).  If you then think of this configuration as a
> configuration set of objects, I like to think about i2rs as a proper
> subset of this.  Operational reality also shows this to be the case. There
> seems to be no good reason to have something you can configure/read from
> this set of objects that differs if you use the i2rs "protocol" versus
> netconf/restconf.

I've intentionally not been prodding at a second half of the "option 4"
conversation: What is the impact on netconf protocol operations.

Per the interim, a significant portion of the semantics we want simply are
addressed by having an ephemeral data store using existing "source" or
"target" semantics in netconf.  GET operations have some ambiguity and may
require extension to allow one to get a given view - merged or not.

-- Jeff