Subject: [i2rs] Ownership and Subscription

From: "Russ White" <[email-masked]>
Date: Mon, 2 Nov 2015 19:49:06 -0500

Y'all --

After some thought on the entire ownership and subscription issue raised
yesterday in the WG meeting -- to repeat the problem for those who weren't
there... If an application/controller installs state into a particular agent
running on a particular network node, what should we do with the
notifications, etc.? Should the agent maintain some sort of "ownership" of
the item in some way, so the agent can notify the owner/installer when their
information is overwritten? Or should such notifications simply be pub/sub,
where anyone (including the owner) can subscribe to changes in the item?

I actually think the answer is both... IMHO, the agent should maintain a
"who installed this" set of bits, but do nothing with these bits other than
maintain them and include them in any notifications. These "bits" don't need
to be anything complicated -- any sort of nonce would do, somehow calculated
so there is little chance of the bits being replicated between controllers
(a problem to be solved later, probably, or outside the confines of the
protocol definition). My thinking is this -- when something is installed in
the local ephemeral state by the agent, then the process might look like --

1. The install signal is received
2. The priorities are examined, and the specific state installed
3. The installer is automatically subscribed to the notifications (the
installer can decide to be removed from the pub/sub, but subscription should
be on by default)
4. If the installer's state is overwritten, it receives a notification
5. This notification contains the "owner bits," which is really just
shorthand for the installer to quickly check to see if "I installed this"
Local policy in the controller might use this information in different ways.
It's really just a bit of shorthand to help the controllers process things
more efficiently, rather than real "ownership bits" in the more traditional
sense.

This seems like it solves the problems at hand -- ownership only implies
subscription because the subscribe happens by default, but it's not really
attached to the "ownership bits." It also, however, provides a shortcut for
the "owner" to know what's going on with "their" installed state.

Thoughts?

:-)

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 2 Nov 2015 20:13:31 -0500

In order to apply the priority mechanism, we effectively have to retain 
the information for ephemeral state about who installed it.  This is 
particularly true given the agreement that all clients will have unique 
priorities.

Given that, it seems simple and useful to always include that installer 
in the list of people who receive a notification that the modification 
has been over-written.  For one thing, that avoids any kind of race 
condition where the over-ride could occur before the creator has a 
chance to add his notification request.

In particular, remember that we architecturally consider such 
over-writes to be an error.  The priority mechanism makes no pretense of 
correctness.  Rather, it tries to produce predictability.  So notifying 
the participants in an error of the problem seems necessary.  Which is 
why the architecture document mandates it.

Yours,
Joel

On 11/2/15 7:49 PM, Russ White wrote:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Russ White" <[email-masked]>
Date: Mon, 2 Nov 2015 20:27:09 -0500

> In order to apply the priority mechanism, we effectively have to retain
the
> information for ephemeral state about who installed it.  This is
particularly
> true given the agreement that all clients will have unique priorities.

If all clients must have unique priorities, why do we need to use this
information in the priority mechanism?

> Given that, it seems simple and useful to always include that installer in
the
> list of people who receive a notification that the modification has been
over-
> written.  For one thing, that avoids any kind of race condition where the
> over-ride could occur before the creator has a chance to add his
notification
> request.

It is useful -- I'm not arguing that we shouldn't do this _by default_, only
that we shouldn't make this mechanism separate from any other pub/sub. It
would seem to be easier to have one mechanism that's common, rather than
multiples... I would say -- mandate it by default, but allow the client to
turn it off if it wants after the state has been installed. This keeps the
mechanism the same across all clients.

:-)

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 2 Nov 2015 20:52:44 -0500

I would indeed expect to use the same mechanisms for delivering the 
error notifications as for all other notificaitons.

And I suppose one could allow a client to unsubscribe from such 
notifications.  But it actually seems to encourage dangerous behavior to 
do so.  And adds extra complexity.

Yours,
Joel

---

From: "Russ White" <[email-masked]>
Date: Mon, 2 Nov 2015 21:15:32 -0500

> I would indeed expect to use the same mechanisms for delivering the error
> notifications as for all other notificaitons.
> 
do
> so.  And adds extra complexity.

Can you explain how it adds extra complexity? I can argue it adds more
complexity in terms of race conditions/etc. either way, so I don't see a net
gain in complexity from the protocol side. What I do see is the option to
reduce complexity on the agent side of things by disconnecting the two data
stores (?).

Again, my entire purpose here is to clarify and simplify, not to make things
harder... Complexity always has tradeoffs, though.

:-)

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Nov 2015 16:51:07 -0500

Russ: 

I have long argued for the node having the "owner bits".   I am willing to
be convinced that the multiple panes of glass (owner1, owner2, owner3) can
be made to work in this first version of I2RS. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Russ White
Sent: Monday, November 02, 2015 7:49 PM
To: [email-masked]
Subject: [i2rs] Ownership and Subscription

Y'all --

1. The install signal is received
2. The priorities are examined, and the specific state installed 3. The
installer is automatically subscribed to the notifications (the installer
can decide to be removed from the pub/sub, but subscription should be on by
default) 4. If the installer's state is overwritten, it receives a
notification 5. This notification contains the "owner bits," which is really
just shorthand for the installer to quickly check to see if "I installed
this"
Local policy in the controller might use this information in different ways.
It's really just a bit of shorthand to help the controllers process things
more efficiently, rather than real "ownership bits" in the more traditional
sense.

Thoughts?

:-)

Russ

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 12 Nov 2015 23:15:52 +0000

Russ, 

Is it referring to the draft-ietf-i2rs-pub-sub-requirements-03?

Some questions: 
- the information that Applications need is probably not the original YANG data model values. I would think that the information any application need are some level of processed information based on the YANG data model collected by the I2RS Agent. 

- Why does I2RS need to worry about the ownership information? 

- Why can't notification run in parallel with the pub/sub? 

Linda 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Russ White
Sent: Monday, November 02, 2015 6:49 PM
To: [email-masked]
Subject: [i2rs] Ownership and Subscription

Y'all --

After some thought on the entire ownership and subscription issue raised yesterday in the WG meeting -- to repeat the problem for those who weren't there... If an application/controller installs state into a particular agent running on a particular network node, what should we do with the notifications, etc.? Should the agent maintain some sort of "ownership" of the item in some way, so the agent can notify the owner/installer when their information is overwritten? Or should such notifications simply be pub/sub, where anyone (including the owner) can subscribe to changes in the item?

I actually think the answer is both... IMHO, the agent should maintain a "who installed this" set of bits, but do nothing with these bits other than maintain them and include them in any notifications. These "bits" don't need to be anything complicated -- any sort of nonce would do, somehow calculated so there is little chance of the bits being replicated between controllers (a problem to be solved later, probably, or outside the confines of the protocol definition). My thinking is this -- when something is installed in the local ephemeral state by the agent, then the process might look like --

1. The install signal is received
2. The priorities are examined, and the specific state installed 3. The installer is automatically subscribed to the notifications (the installer can decide to be removed from the pub/sub, but subscription should be on by default) 4. If the installer's state is overwritten, it receives a notification 5. This notification contains the "owner bits," which is really just shorthand for the installer to quickly check to see if "I installed this"
Local policy in the controller might use this information in different ways.
It's really just a bit of shorthand to help the controllers process things more efficiently, rather than real "ownership bits" in the more traditional sense.

This seems like it solves the problems at hand -- ownership only implies subscription because the subscribe happens by default, but it's not really attached to the "ownership bits." It also, however, provides a shortcut for the "owner" to know what's going on with "their" installed state.

Thoughts?

:-)

Russ