Tom, I'm in agreement with you. Thank you for clarifying it.
Dean On Oct 1, 2014, at 11:40 AM, Thomas D. Nadeau <[email protected]> wrote: > > > On Oct 1, 2014:8:16 AM, at 8:16 AM, Dean Bogdanovic <[email protected]> wrote: > >> 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 > > 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 > > > >> >>> >>>> 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
