On Wed, Oct 1, 2014 at 10:13 AM, Jeffrey Haas <[email protected]> wrote:
> On Wed, Oct 01, 2014 at 09:54:12AM -0400, Alia Atlas wrote: > > Thanks for the explanation. It matches with what I understand for > > configuration. > > Where I am confused is why I2RS - which is doing ephemeral only and > matches > > closer to the direct proprietary APIs directly to > > the routing processes - is being tied up in this. > > The annoying fact is that we have to reconcile what we want to do with the > semantics of existing netconf/yang. > We do? I agree that NetConf/RestConf/YANG are the bases that the WG wants to use to build I2RS. I don't think that anyone has the idea that they match perfectly or wouldn't need modification for this use. > The property of being able to override some bit of local config with > ephemeral config implies at least another data store in those semantics. > Otherwise you'd have to redefine the existing semantic as "a given writer > may SET a value of a higher visibility priorty and it's allowed to go away > and reveal the original value of lower visibility priority". > We had that semantic initially (I forget which draft) - and there was serious WG pushback that it was too complicated. I think that a LOT of this simplifies if you make one of two assumptions. Either the CLI/NetConf-for-config overrides I2RS or I2RS overrides the CLI/NetConf-for-config. If I2RS is lower priority than CLI/NetConf, then when config comes in, any I2RS state is preempted and the appropriate I2RS client is notified. If I2RS overrides, then when I2RS state comes in, the associated CLI state is deleted. I grant that the latter case is more complicated - and I'd be really surprised to see implementations that were comfortable going there yet. Regards, Alia This makes sense as a merge/patch operation, but less so with a single > object store. > > -- Jeff >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
