Andy, On Thu, May 01, 2014 at 09:03:07AM -0700, Andy Bierman wrote: > > And thus, "we need a new data store". How it interacts with similarly > > configured objects in other datastores is another detail I'm trying to > > tease > > out as a requirement. > > > > > OK -- I hope this ASCII art helps. > > NC/RC I2RS > | | > V V > +-------------------+ +----------------+ > | local config | | i2rs-config | > +-------------------+ +----------------+ > | | > V V > +-------------------------------------------+ > | operational state | > +-------------------------------------------+ > > The operational state contains a data-model dependent mix > of local and i2rs configuration, + learned data from protocols. > The "i2rs-config" datastore is like a "fastpath" config (as Tom described). > The operations on the local-config datastore use different rules and the 2 > only > mix in the operational state.
Fully parallel, which was the detail I was trying to get to. Thanks. [...] > > Consider my BGP example noted elsewhere. If I want to say "create a BGP > > peer" as an I2RS operation and some of that behavior relies on other > > underlying configuration (autonomous system, security policies, etc.) my > > choices appear to be either to have some amount of shadowed configuration > > objects on top of an existing BGP module or have a somewhat parallel module > > (perhaps inheriting configuration objects from the main BGP module). > > > > Which would you do? > > > > > I would start by making sure the management of the local config and > the I2RS config were fully aligned, because it is inevitable (if not > obvious) > that definitions in all 3 boxes above need to share data naming, data types, > and even data nodes. A YANG grouping would be the starting point for > sharing objects. (Not sure if any tweaks needed to support I2RS uses-stmt). I'm not sure this fully answers my question. In the case they are congruent, would you ever want to have I2RS simply share the yang config (obviously needing some syntax changes that permits such overlap) or would you prefer that they be simply use language inheritance features across modules? Perhaps that is a better way to ask it: Within the same module or using two modules? If within the same module, there is the implication of a requirement for changes to the language to permit them to do so harmoniously. If across different modules, there is the suggestion but not requirement that as Working Groups provide yang modules for managing their components that they are structured in such a way to permit I2RS re-use in our modules. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
