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