On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote:
> Jeff:
>
> The fourth option is interesting and creative. A few questions/requests: 1)
> How would the fourth model be expressed in the yang model - config
> (empheral)?
The beauty of the fourth option is that it does not require a large
set of new data models. The idea is that you have a standard config
data model and you use the same model for an ephemeral datastore. The
server will then take the contents of the config datastore and 'merge'
it with the content of any ephemeral datastores to produce what the
box ends up doing (the operational state). The merging function will
take priorities into account should conflicts arise. Here is the
relevant figure (taken from the meeting minutes):
+-----------------+
| |
+--- (+) ---+ |
^ ^ v
+---+ +---+ +---+
| | | | | |
|(1)| | | | |
| | | | | |
+---+ +---+ +---+
NC config ephemeral operational
datastore datastore state
(1) The complete NC config datastore is at certain synchronization
points made persistent
(+) Priority resolution, priorities may be per datastore or per
user or per 'application' or even per data node
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
