On Thu, May 1, 2014 at 9:09 AM, Jeffrey Haas <[email protected]> wrote: > 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. > > I prefer 1 module, but it is not that simple. The user-defined typedefs and identities (for identityref data type) can be shared (e.g. imported from a common-types module). Even if the data nodes are separate, the definitions can share YANG semantics in various ways.
New YANG statements (or extensions) to identify data affected by I2RS will allow the data models to be mixed in the same module, augment across modules, etc. > 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. > > I think it would be most efficient if a WG considered complete management of a new protocol feature, and chartered configuration, I2RS, monitoring, and notification support at the same time. The IETF approach for the last 2 decades has been to leave most of the management to the vendor CLI. The problem with this approach is that over-laying monitoring systems (vendor + standard) is easy, but not true for APIs that change the system. Once the vendor API is in place, it is very difficult to overlay an incompatible standard API. -- Jeff > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
