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 > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
