On Oct 1, 2014:7:43 AM, at 7:43 AM, Joel M. Halpern <[email protected]> wrote:
> 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.
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
>
> 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
>>
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
