Right - while there may be unique access models for the data which reflect unique I2RS or NETCONF requirements, I don¹t see why the domain specific (e.g., OSPF) model content would be different.
On 9/29/14, 6:57 PM, "Dean Bogdanovic" <[email protected]> wrote: >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
