On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau <tnad...@lucidvision.com> wrote:

> 
> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas <jh...@pfrc.org> wrote:
> 
>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote:
>>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder 
>>> <j.schoenwael...@jacobs-university.de> wrote:
>> [...]
>>>> 
>>>>             +-----------------+
>>>>             |                 |
>>>>       +--- (+) ---+           |
>>>>       ^           ^           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
>>> 
>>>     These are precisely the qualities I and some others were thinking of 
>>> when we started i2rs. The idea is quite simple, as you have said above and 
>>> really needs not be complicated more.  
>> 
>> It has its own complications.
>> 
>> Do we permit more than one ephemeral datastore?  If so, this simplifies data
>> object priority when resolving the operational state.  But this also
>> complicates operational state integrity when you have multiple cross
> 
>       I vote for keeping this simple for starters. Lets get an implementation 
> or two of a single ephemeral data store. This avoids having multiple 
> priorities too; its just 1.
> 
>       --Tom
We can allow multiple ephemeral data stores, but the only dependency can be 
with the NC config datastore. Example:

residential services
business services

each of the configuration sits in their own ephemeral datastore, but only 
dependency is on NC config store. 

As we are still keeping 1 to 1 overlay, not many to 1.

Dean

> 
> 
>> references.
>> 
>> -- Jeff
>> 
> 
> _______________________________________________
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to