I had assumed that the YANG "datastore" was the repository in which the
I2RS agent stored all of the operations it had applied, who had applied
them, etc.
This actually does lead to a related question.
How does an I2RS client delte the state it has created. (Note that said
state might actually include a deletion from the underlying data.)
The client is not required to have the knowledge of what the config /
I2RS state was before it performed its operation. And even if it were,
having an I2RS client set it to a specific value is not the same as
removing the I2RS state (because of priority.)
I don't think we have been explicit about the need to express this, but
it is implicit in the architecture.
Yours,
Joel
On 10/1/14, 12:25 AM, Alia Atlas 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.
Regards,
no-hats Alia
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
