On Wed, Oct 1, 2014 at 3:23 PM, Thomas D. Nadeau <[email protected]> wrote:
> > On Oct 1, 2014:11:15 AM, at 11:15 AM, Andy Bierman <[email protected]> > wrote: > > > > On Tue, Sep 30, 2014 at 9:25 PM, Alia Atlas <[email protected]> wrote: > >> Hi, >> >> I'd like to really understand why I2RS needs a datastore and what that >> actually means. >> In my initial conception of what an I2RS agent would do for, say, writing >> a route in the RIB >> model, is that the I2RS agent would simply parse a received request from >> a standard format >> and model into the internal and pass that to a RIB Manager - just as an >> OSPF implementation >> might install a route to the RIB manager. An I2RS agent could also query >> the RIB Manager to >> read routes and there'd be events coming out. >> >> With the introduction of priorities to handle multi-headed writers and >> collision errors, the I2RS agent would need to store what was written by >> which client. >> >> What benefits and rationale does a YANG datastore add? Why does using >> one need to be >> standardized? >> >> I apologize if this seems a naive question, but it's been quite a while >> since I read up on YANG and NetConf/RestConf. >> >> > It is a great question because the datastore is used for 3 reasons in > NETCONF/YANG. > > 1) conceptual container for top-level YANG data nodes > 1a) source parameter for retrieval; target parameter for editing > 2) conceptual container for YANG validation rules for the running > datastore > 3) conceptual container for access control model > > > I don't agree that multiple ephemeral datastores are needed. Support for > multiple clients > within 1 datastore is needed. > > > That is precisely the point I've been making. We've been making this > discussion far too complex. > Yes - this does not need to be as complex. > > YANG validation rules for the ephemeral datastore are not interesting, > just the "active" > config (running + ephemeral). The access control model for I2RS is > different than NETCONF. > > Recent discussion has me confused: > > A) Are the YANG modules exactly the same for the running and ephemeral > datastores? > (Interim decided yes) > > > Lets hope so, or we've gone off into the woods... > That is my concern. I've seen no reasoning beyond wishful thinking and a desire to allow anything to be done quickly and ephemerally. > B) How are the same instances of the same data model related in the > running and ephemeral > datastores? > > I thought "phase 1" was supposed to be simple and the I2RS client would > just inject and remove > RIB data to override the running config. So, answer to (B) is: datastores > have independent > instances. If ephemeral instance exists, it is used. If deleted, then the > instance from the > running config (if any) becomes active. As long as the ephemeral instance > exists, the running config > instance is ignored. > > Is this consistent with the architecture document? > Which solution best fits the agreed upon architecture? > > > > > > Regards, >> no-hats Alia >> >> > Andy > > >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
