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.

Yours,
Joel

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

Reply via email to