Why not start with just 1?

On Sep 24, 2014:5:00 PM, at 5:00 PM, Dean Bogdanovic <[email protected]> wrote:

> 
> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau <[email protected]> 
> wrote:
> 
>> 
>> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas <[email protected]> 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 
>>>> <[email protected]> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to