Acee: I think that you, Dean, and I hope to work toward a model that finds as much common ground for device specific. As Jeff pointed out, the domain specific configuration models need to look at all vendor yang to see we've found the IETF I2rs/config to make sure we've found that common ground. In my earlier request to review, it was based on concept of discovering anything with the OSPF models that need to be augmented for I2RS.
Dean suggests modular models that can be used to create the final model within the standard or proprietary - which is good. The error handling is key during commits or crashes. Thank you for active discussion, Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Acee Lindem (acee) Sent: Monday, September 29, 2014 7:39 PM To: Dean Bogdanovic; Jeffrey Haas Cc: Thomas Narten; [email protected]; Susan Hares; Alia Atlas Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
