I would go back and ask basic question What state do we want to change via I2RS?
static route dynamic routing protocol stateless firewall filters xVPN (E/L2/L3) etc based on that we can then decide if going through configuration or directly accessing responsible daemon is better way. As far I know, we wanted to allow i2rs agent to change any supported state on the device. If that is still the case, then we need to go through the configuration. If want to limit change of the state to certain primitives, then we can investigate what other options are available for i2rs Dean On Dec 3, 2014, at 1:30 PM, Russ White <[email protected]> wrote: > >> [Don] I agree. We need to define semantics for the datastore and >> predictable results for the writable running state or active >> configuration. It seems to me if there is priorities and overlap >> with various datastores there should be blocking or overriding of >> ephemeral data too. > > If we stuck to routing table state, rather than configuration state, then we > probably wouldn't have such overlaps in the first place... Or rather the > overlaps would be resolved through an 'administrative distance' sort of > mechanism, and each individual write would be wholly atomic, meaning there > would be no interlocking state changes. > > That we are talking about having interlocking state changes within a single > device implies, to me, that we're far afield of the original intent of I2RS > (?). > > :-) > > Russ > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
