On Fri, May 2, 2014 at 8:40 AM, Jeffrey Haas <[email protected]> wrote: > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: > > I picture the operational state as the mixing bowl for the 2 config > sources > > and data learned from protocols and system events. It seems > > both NETCONF and I2RS would be able to pick the data is cares about > > out of that. > > I think this is what I'd like to see personally. > > > This is a weakness in YANG that may get improved in YANG 1.1. > > Since it is officially just for NETCONF, there are no mechanisms > > (other than vendor extensions) to tag the data as specific to > > some subset of protocols. > > As I mentioned elsewhere, I'm hoping we don't go down the path of "editable > operational state", instead configuration semantics for our purposes. > > I guess I agree, because when trying to figure out some corner-cases, I changed the datastore name to "i2rs-config".
IMO this makes it easier to conceptualize the underlying system as the result of the priority-based arbitration between local-config and i2rs-config. It is easier to see that the system is going to have to re-install an entry from local-config when an I2RS client removes a higher-priority entry from i2rs-config (e.g., your BGP peer example). Both configs exist in parallel, and the oper-state has the entry that is higher priority. > > I think that we will, that is the set of YANG leafs etc that I2RS will > > > want to edit and the sets of leafs that I2RS will want to get in a > > > straightforward manne will not be the same (eg the latter will include > > > read-only statistics and 'config true'). And yes, it could all be done > > > with filters, which could be a nightmare. > > > > > > > > Examples of read-only data that only I2RS would want to get would help. > > I believe that it would largely overlap config false state desired for > normal module purposes in many cases. For example, interface statistics > would likely be part of the standard interface module. Where things get > interesting are specific augmentations that tie different information > domains together - interface stats correlated against routing, for example. > (For prefix X, traffic is seen - similar to IPFIX exports.) > > -- Jeff > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
