(I believe that your talking about dumb clients is because I2RS and
NetCONF YANG use terms differently. In I2RS, the Agent is the thing in
the box, and the Client is the smarter things outside the box.)
We wrote very specific rules into the architecture document the WG
adopted, specifically because we wanted to bound the expected
intelligence of the I2RS Agent.
The agent is required to detect collision. It is required to generate
error notification upon collision.
It is also required to use the priority mechanism to produce a
predictable composite result in the case of collision.
The odds of that result being what the human beings want is pretty small
But it is predictable. Which is all we felt we could ask for.
Yours,
Joel
On 9/25/14, 6:26 AM, Juergen Schoenwaelder 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.
/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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
