Tom,
On Oct 1, 2014, at 11:08 AM, Thomas D. Nadeau <[email protected]> wrote: > > 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. 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 > >> 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 >> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
