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. > 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... > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
