To keep with the existing topic of the discussion (OSPF model), here is my question:
Why would you have two different OSPF models on a single device? That device has certain OSPF capabilities that are implemented and are represented by a data model. Configuration can be created based on it and written into a data store. Once you have a base model, you can decide to create other model, but it can be only subset of the base model. There is nothing preventing you to create a private model, but it has to be based on the base model. Why do you need different model for I2RS? I strongly believe that a single data model is needed, but having different config stores to save different configuration parts. In my mind, I2RS has to provide a good mechanism that allows non-vendor owner of the device to define what can be changed on the device. The 3rd party should be able to decide that all of device capabilities can be changed through I2RS (I would then argue why do you really want to do that) or they can decide to go as minimal as changing ACLs, but allowing only ACE to be added/deleted from ACL (which makes much more sense IMO). In I2RS we can focus on "light weight templates", that fills in specific stuff across multiple config snippets. L3VPN is such an example. It would fill in configs in BGP, routing instances, interfaces. It would all be based on the standard models. Another thing could be a proprietary data model like vCPE. Device owner creates private "light weight templates" and it allows I2RS clients to manage vCPEs. The proprietary vCPE template is a subset of device base model. Based on vCPE model, configuration is created and stored in a data store, which ever is supported by the device and decided by the owner. Now we have to figure out error handling, what happens when you populate a template, and the commit fails due to underlying config issue, how do you propagate such things back to the upper layer? IMO, all the minimum required configuration should be copied into ephemeral datastore, so if something breaks in the underlying config store, it is still viable, and there are no interdependencies between data stores. This is how the running config is created (cfg A || cfg eph) = cfg running Base config and ephemeral config are overlaid, ephemeral is see through to the base config, but device can function correctly by reading most of the config from ephemeral data store to certain extent. Dean On Sep 29, 2014, at 5:44 PM, Jeffrey Haas <[email protected]> wrote: > On Mon, Sep 29, 2014 at 09:41:09PM +0000, Acee Lindem (acee) wrote: >> I would hope that we have a single model for NETCONF and I2RS or at least a >> core OSPF model that contains the large intersection. > > That's why option 4 was suggested. Given that you now have a body of work > representing config for OSPF and knowing that I2RS may want to add state > into it, please take a look the option 4 discussion and see if it's a good > fit. > > A reminder to the wider WG: "Option 4" was simply the line of discussion > from the netmod interim. As seen in its thread it's either not fully > explained well or there's still confusion among the interim participants > what it actually means. It's not settled that this is what we'll be doing, > but it is currently the method that has received the most discussion. > > -- Jeff > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
