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.
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
