On Sep 25, 2014:6:26 AM, at 6:26 AM, Juergen Schoenwaelder <[email protected]> wrote:
> Joel,
>
> my expectations about the intelligence of I2RS clients is perhaps
> lower than yours. Do you really believe I2RS clients will be smart to
> adapt to whatever some other unknown conflicting I2RS client injects
> into a shared ephemeral datastore?
>
> I do not expect smartness. My hope is that I2RS clients involved in a
> conflict can be signalled and probably more important that a human
> operator can be signalled that I2RS clients step into each other so
> that a human can take action to resolve things. Automatic conflict
> resultion based on observation what state is injected by other I2RS
> clients seems to me a huge (idealistic) assumption.
>
> I would find conflict detection during the merge operation likely
> more reliable than conflict detection based on smart I2RS clients
> monitoring closely what is going on in a shared datastore.
>
> I assume there will be dumb I2RS clients.
I too assume "dumb" clients (i.e.: or those with minimal computational
horsepower). Given that assumption, I've thought that the "merge" operation
should be a simple copy-over-the-stored-config operation. This is why we
shouldn't have more than one ephemeral store. If its treated this way, its
quite literally, just a copy-over operation. My original ideas around i2rs
were always such that the ephemeral store was just a scratch pad where objects
were stored to reflect a shadow of a subset of the running config (just the
forwarding state information) until such time as it could get copied there
"soon" after, either via a timer popping or an explicit command from the OS or
client(s). Access to that store was done using a variant of Netconf that a)
avoided the configuration verification process from Netconf and b) was RESTful
in nature. What we have been discussing here with multiple stores (and
priorities) has vastly and IMHO unnecessarily, complicated the original idea
which was quite simple and obtainable with mostly off-the-shelf technological
components (i.e.: RESTConf + a hacked Netconf daemon + yang models). It is the
latter recipe from with which I think we should use as a starting point to
build crash test dummy implementations from to see if this thing works rather
than discussing the theoretical aspects of complicating that further. Sorry,
just my $.02.
--Tom
>
> /js
>
> On Thu, Sep 25, 2014 at 06:12:00AM -0400, Joel M. Halpern wrote:
>> Separate ephemeral data stores for distinct I2RS clients would seem a
>> very bad idea.
>> It is perfectly acceptable for one client to read information being
>> manipulated by another cleitn. And if so, the reader should see the
>> results of that other clients activity.
>>
>> Also, separate stores would not produce the error results required in
>> the case of collision.
>>
>> So no, I do not see a use case from I2RS for multiple ephemeral data stores.
>>
>> Yours,
>> Joel
>>
>> On 9/24/14, 9:48 PM, Dean Bogdanovic wrote:
>>>
>>> On Sep 24, 2014, at 5:19 PM, Andy Bierman <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>>
>>>> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>>>
>>>>> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas
>>>> <[email protected] <mailto:[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]
>>>> <mailto:[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
>>>>
>>>>
>>>>
>>>> What does this really mean?
>>>> I did not understand the details at the interim.
>>>> Does this mean each datastore has separate data models?
>>>
>>> yes, each data store has separate data models
>>>
>>>> Does this mean each service represent separate I2RS clients?
>>>
>>> each ephemeral datastore represents separate I2RS clients.
>>>
>>>>
>>>> The only real reason to have multiple ephemeral datastores
>>>> would be to create the same instances of 1 or more data nodes
>>>> in multiple datastores. (multiple concurrent overlays).
>>>
>>> I view it differently. In subscriber management different data models
>>> are used for residential and business subscribers. Some service data
>>> models can be very unique for business customers. So separating them in
>>> different data stores makes sense, as they there are no overlaps with
>>> each other, only with NC config store. In this case, we can get better
>>> performance.
>>>>
>>>> IMO this sort of complexity should be left out of the agent.
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> Andy
>>>>
>>>>>
>>>>>
>>>>>> references.
>>>>>>
>>>>>> -- Jeff
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>> _______________________________________________
>>>> i2rs mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> i2rs mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> 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/>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
