Andy Bierman <[email protected]> writes: > On Thu, May 1, 2014 at 8:23 AM, Jeffrey Haas <[email protected]> wrote: > >> Andy, >> >> On Thu, May 01, 2014 at 08:02:17AM -0700, Andy Bierman wrote: >> > I think this has been explained several times already, >> > starting in the IETF 89 slides. >> > >> > I don't think anybody has said NC/RC/YANG could be used >> > as the I2RS protocol without a single change. People has said >> > it is the best starting point for I2RS. There seemed to be an >> overwhelming >> > consensus in the London meeting and on this mailing list to >> > use NC or RC + YANG as the I2RS starting point. >> >> Since we've not been very good about getting requirements explicitly >> listed, >> part of the point of my questions is to tease out those details. >> >> > IMO, there needs to be a new datastore in the architecture that >> > contains I2RS data. The I2RS protocol will define how this data is >> accessed. >> > It's really not that complicated. >> >> 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.
Right, but then some rules have to be stated for dealing with the operational state so that NC/RC and I2RS (or another protocol, for that matter) don't step on each other's toes. > > >> I2RS does not have any interaction with the "local config" except maybe >> > to read it. The NETCONF configuration datastores (candidate, running, >> > startup) are >> > not going to be used by I2RS. Nothing I2RS does is going to even >> slightly >> > alter the definition of any NETCONF configuration procedures. >> >> 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). This needn't necessarily be true - I think the common denominator really is the operational state. I can imagine different configuration protocols/systems speaking completely different languages. Just an example: OpenWRT defines a UCI format for configuring a firewall that is quite different from the standard configuration of iptables, although under the hood OpenWRT uses iptables as well. Lada > > > > -- Jeff >> > > > Andy > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
