Subject: Re: [netmod] i2rs client ownership

From: "Jmh.direct" <[email-masked]>
Date: Mon, 26 Aug 2013 09:15:00 +0200

Mostly, I am comfortable with your description.  Havong an information model of the metadata seems uaeful.

On the other hand for redundant clients cooperating for failover, etc. I think it is worth keeping in mind that they will need their own back-end coordination.  The I2RS agent ought not be the primary coordination channel.

Yours,
Joel

Sent from my Samsung smartphone on AT&T

-------- Original message --------
Subject: Re: [netmod] i2rs client ownership 
From: "Jan Medved (jmedved)" <[email-masked]> 
To: "Joel M. Halpern" <[email-masked]>,Andy Bierman <[email-masked]> 
CC: "[email-masked]" <[email-masked]>,Nitin Bahadur <[email-masked]>,Alia Atlas <[email-masked]>,"[email-masked]" <[email-masked]> 

On 8/24/13 2:31 AM, "Joel M. Halpern" <[email-masked]> wrote:

>For me, "ownership" of data is not a helpful way to think about this.
>(It is not incorrect, just unhelpful.)
>
>Rather, the base concept is that two different clients should not be
>writing the same data in the same time period.  (i.e. from when the
>first one writes it until he removes his modification.)

This is necessary, but not sufficient. If we allow multiple clients
(actually, identities, since the same identity can cover multiple clients)
to change state programmatically, we must allow for mechanisms for
programmatic state validation and troubleshooting.

For example, when there is a failover between a redundant pair of clients,
the newly active client instance must perform state synchronization, which
includes reading all the state that the previously active instance of the
client injected into the system. Therefore, the agent needs to know which
client injected which state into system (if the agent does not do that, we
need an external entity, such as the controller, to keep track of this).

Similarly for troubleshooting - when, for example, an operator wants to
purge state of a client that is/should not be active anymore, the system
should facilitate this action. A state purge for a client could happen,
for example, when an operator wants to shut down an application.

>
>When this fails, it is an error.
>We need to detect this error.
>So the I2RS Agent is required to keep track of enough information to
>detect and provide a predictable behavior in the event this occurs.
>The priority mechanism is a mechanism for providing better
>predictability.  If we don't like it, we can ditch it.

Priority is useful - no reason to ditch it. But it is not sufficient :-)

>
>In particular, one corrollary of this is that "ownership" does not, it
>seems to me, belong in the data model.  It is, as Alia and other said,
>metadata.

Yes, it is metadata. But it would be premature to exclude the option to
provide metadata along with the data - there are plenty of systems out
there that implement this concept and work quite well.

>Yours,
>Joel

Thanks,
Jan

>
>On 8/22/13 6:36 PM, Andy Bierman wrote:
>> On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved)
>><[email-masked]> wrote:
>>> Hi Alia,
>>>
>>> On 8/22/13 11:13 AM, "Alia Atlas" <[email-masked]> wrote:
>>>
>>>> Hi Juergen,
>>>>
>>>> I agree that the ownership of data seems more like meta-data to me
>>>>than
>>>> anything else.  I really would prefer not to clutter the data-models
>>>>with
>>>> it.
>>>
>>> It depends. If ownership is coarse grained, then having the ownership
>>> metadata in a separate tree is manageable. If it's fine-grained, having
>>> the ownership metadata embedded in the data tree is easier - both for
>>>the
>>> server as well as for the clients.
>>>
>>> I think with I2RS, ownership will likely be fine-grained.
>>>
>>
>> I think this "owner" concept needs a lot more work.
>> If owner 1 has a higher priority than owner 2, then owner 1 can clobber
>> anything that owner 2 already created. That doesn't sound fine-grained
>> to me.
>>
>> The "first one wins" concept only applies to clients with the same
>>priority.
>> The "last one wins" problem is addressed by assigning priorities to the
>>clients.
>> Now it is "highest priority wins" which is what is desired.
>>
>> If the client writing existing data has the same or lower priority as
>>the owner
>> that set the data, then the access is denied.  (Problem solved, first
>>one wins).
>> NACM would need some changes to support owner priority.
>> The augments that has been proposed is insufficient:
>> http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6
>>
>> (IMO, only sec. 3.6 of this draft is needed.)
>>
>>
>>>>
>>>> I think there are two (at least!) separate aspects that we need to
>>>>figure
>>>> out.  One is the permissions aspect - where we need to be able to
>>>>clearly
>>>> express what scope a particular role has.
>>>
>>> Agreed.
>>>
>>>>   The second is what an i2rs agent needs to store, manipulate, and
>>>>report
>>>> back.
>>>>
>>>> For the latter, the basic concept is described in
>>>> draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4
>>>>(which
>>>> discusses identity).  In Sec 5.2, it says:
>>>>
>>>>    "The I2RS agent stores the set of
>>>>    operations it has applied.  Simply, the I2RS agent stores who did
>>>>    what operation to which entity.  New changes replace any data about
>>>>    old ones.  If an I2RS client does an operation to remove some
>>>>state,
>>>>    that state is removed and the I2RS agent stores no more information
>>>>    about it.  This allows any interested party to determine what the
>>>>    current effect of I2RS on the system is, and why.  Meaningful
>>>>logging
>>>>    is also recommended."
>>
>>
>> If a client is really a broker, then is the owner string going to be
>>for the
>> upstream application or the broker?  Which clients are likely to
>> have the same priority and collide on the same data?
>>
>>
>>>>
>>>> Alia
>>>
>>> /Jan
>>
>> Andy
>> _______________________________________________
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod
>>

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Mon, 26 Aug 2013 16:11:16 +0000

From: "Jmh.direct" <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 26, 2013 12:15 AM
To: Jan Medved <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] i2rs client ownership

100% agreed.

But state sync after a failover is still needed. Consider a redundant client with active and standby instances. The active can either update the standby instance first and then the agent, or vice versa. The updates to the agent and the standby can never be completely  in sync. If a failure of the active instance happens between the updates to the agent and the standby instance, the newly active instance and the agent will be out of sync. Therefore, a state sync is needed after a failover.

Yours,
Joel

Thanks,
Jan

-------- Original message --------
Subject: Re: [netmod] i2rs client ownership
From: "Jan Medved (jmedved)" <[email-masked]<mailto:[email-masked]>>
To: "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>,Andy Bierman <[email-masked]<mailto:[email-masked]>>
CC: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,Nitin Bahadur <[email-masked]<mailto:[email-masked]>>,Alia Atlas <[email-masked]<mailto:[email-masked]>>,"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Jan

>><[email-masked]<mailto:[email-masked]>> wrote:
>>> Hi Alia,
>>>
>>> On 8/22/13 11:13 AM, "Alia Atlas" <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> Hi Juergen,
>>>>
>> [email-masked]<mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 26 Aug 2013 12:27:09 -0400

As long as we are careful not to get carried away with it, and ability 
to perform queries based on / about ownership does seem a useful 
capability for I2RS.    I observed in some other similar groups people 
tending to expect that to be sufficient to handle redundancy, without 
synch between the devices.  I was trying to be clear that in my view 
that is a non-goal.

Yours,
Joel

On 8/26/13 12:11 PM, Jan Medved (jmedved) wrote:
> To: Jan Medved <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>     Mostly, I am comfortable with your description.  Havong an
>     information model of the metadata seems uaeful.
>
>     On the other hand for redundant clients cooperating for failover,
>     etc. I think it is worth keeping in mind that they will need their
>     own back-end coordination.  The I2RS agent ought not be the primary
>     coordination channel.
>
>
> 100% agreed.
>
> But state sync after a failover is still needed. Consider a redundant
> client with active and standby instances. The active can either update
> the standby instance first and then the agent, or vice versa. The
> updates to the agent and the standby can never be completely  in sync.
> If a failure of the active instance happens between the updates to the
> agent and the standby instance, the newly active instance and the agent
> will be out of sync. Therefore, a state sync is needed after a failover.
>
>
>     Yours,
>     Joel
>
>
> Thanks,
> Jan
>
>
>     To: "Joel M. Halpern" <[email-masked]
>     <mailto:[email-masked]>>,Andy Bierman <[email-masked]
>     <mailto:[email-masked]>>
>     CC: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>,Nitin Bahadur <[email-masked]
>     <mailto:[email-masked]>>,Alia Atlas <[email-masked]
>     <mailto:[email-masked]>>,"[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>
>
>
>
>     >><[email-masked] <mailto:[email-masked]>> wrote:
>     >>> Hi Alia,
>     >>>
>     >>> On 8/22/13 11:13 AM, "Alia Atlas" <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>
>     >>>> Hi Juergen,
>     >>>>
>     >>[email-masked] <mailto:[email-masked]>

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Mon, 26 Aug 2013 17:40:59 +0000

>synch between the devices.  I was trying to be clear that in my view

Agreed 100%.

/Jan