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 protected]] On Behalf Of Russ White
Sent: Monday, November 02, 2015 6:49 PM
To: [email protected]
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


 

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

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

Reply via email to