On Wed, Oct 1, 2014 at 2:15 PM, 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 > Since I2RS is based on single operations - sort of like what I understand is the case for RestConf - I don't see this applying to I2RS. Am I missing something? > 2) conceptual container for YANG validation rules for the running > datastore > Again, I don't think that I2RS really is doing YANG validation. I guess this is a detail that isn't really discussed in the architecture, but my assumptions have been that it would negatively impact the desired speed and throughput of operations in I2RS. > 3) conceptual container for access control model > And as you say below, this is different for I2RS. So again - why does I2RS need a datastore? > > I don't agree that multiple ephemeral datastores are needed. Support for > multiple clients > within 1 datastore is needed. > > 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) > I understand that the NETMOD interim decided it'd be nice. But I'm not yet convinced or hearing reasons that convince me that it is the case for I2RS. For instance, the type of events or functionality and abstractions that make sense in I2RS may be quite different. Certainly, what we have for a RIB model is not what you'd see for a static routes configuration model. > 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. > It depends on the priorities between the config and I2RS. > Is this consistent with the architecture document? > Which solution best fits the agreed upon architecture? > The architecture lets the implementation determine what priority the CLI/NetConf-config is at compared to any I2RS client. If it is better, the the I2RS client would have its state rejected in case of an overlap. Cheers, Alia > 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
