On May 1, 2014:3:08 PM, at 3:08 PM, Andy Bierman <[email protected]> wrote:
> > > > On Thu, May 1, 2014 at 11:28 AM, Joel M. Halpern <[email protected]> wrote: > Jeff, I think the problem is subtler. > Even if I2RS wants to manipulate data represented in the config-true (CLI > equivalent) tree, the I2RS data is still actually separate. If you ask what > the CLI has set, you get one answer. If you ask what I2rS has set you get a > different answer. And if you ask what is actually operating you get the > result of the arbitration. > At least that is what the architecture describes. > > This clearly can be modeled in YANG. It may take a little more effort. > > > I didn't think the I2RS charter covered writing to the local configuration, > that is maintained by NETCONF. I hope not. > > But if there is some intent to support a "copy-to-local-config" option > in the I2RS protocol, then a mapping from the I2RS data to the > local config data would be needed. Right. The thinking was to include some option in the protocol extensions to trigger a copy-to-local-config "later" either of the entire running config, or parts of it. But the normal operation was only (and as quickly as possible) to the running config/rib/system. --Tom > > > Yours, > Joel > > Andy > > > On 5/1/14, 2:17 PM, Jeffrey Haas wrote: > Andy, > > On Thu, May 01, 2014 at 11:10:11AM -0700, Andy Bierman wrote: > that is not what the "edit-data" extension does. > It is a sub-statement that identifies I2RS editable data no matter what > YANG module is used to define the data. The YANG config=true statement > identifies a data node as part of the configuration datastore. The edit-data > extension cannot be used on a config=true node, only non-configuration. > > module foo { > ... > import i2rs { prefix i2rs; } > > container config-data { > // NETCONF definitions here > } > > container i2rs-data { > config false; > i2rs:edit-data; > } > > You're crystal clear to me now. Thank you. This was not permitting I2RS to > be able to interact with/overlay part of config-data (per your example) as I > had hoped. > > Nesting is also possible -- up to the data modeler to decide what to use: > > 1) i2rs-data inside config-data > 2) i2rs-data inside oper-data > 3) oper-data inside i2rs-data > > What I had been hoping was for config-data to permit elements that > were effectively config true,i2rs. > > (Or s/i2rs/ephemeral/ as per previous messagees.) > > IMO, I think we want multiple data stores for configuration for adding > routes to the rib. > > How many does I2RS need for itself? > > To clarify, a config-data data store, an i2rs-data datastore where > the i2rs portion may overlap. > > Since I'm apparently not making my point well, I'll see if I can mockup my > understanding in a netconf like transaction. (For Dean, I haven't caught up > in my reading to restconf, else I'd do that.) > > -- 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
