For clarity, I was trying to make sure we understood that they need to
be separate stores. As far as I can tell there is no need for
'copy-to-local'.
Yours,
Joel
On 5/1/14, 3:08 PM, Andy Bierman wrote:
On Thu, May 1, 2014 at 11:28 AM, Joel M. Halpern <[email protected]
<mailto:[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.
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] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/i2rs
<https://www.ietf.org/mailman/listinfo/i2rs>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
