[i2rs] Ownership and Subscription

[Russ White]

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
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Conversation on Priority and Panes

[Russ White]

Y'all --

After sleeping on the discussion last night, I think the panes of glass (or
is it pains of glass?? :-)  ) is still by and large another expression of
the priority concept within I2RS. The concept does bring up one specific
point of interest, however -- what about backup information? Some vendor
RIBs, for instance, allow a routing process to install not only the best
path as calculated by the process -- but if the process fails to install,
some RIB implementations allow the process to place the route in the "backup
pool." This allows the local RIB process to drop to the "second best path,"
in terms of priority, so the local RIB doesn't need to query the routing
processes to switch in the case of a withdraw or change in topology.

To convert this to I2RS terms, it does seem worthwhile to me to have the
capability for a local agent to accept an install instruction for some
particular ephemeral state, and if the install fails, to hold that state for
future use. This would apply to any sort of ephemeral data, including that
which is configured locally on the network device. Rather than trying to
think of this as "panes of glass," though, this would convert it to simply a
backup list of lower priority items the local agent can use in the case of
the failure of the highest priority item currently in use.

The nice thing about this view is that it doesn't require a lot of changes
at the protocol level. The only thing that needs to be available is the
option for an agent to send three different types of answers to an install
request --

1. This ephemeral state was installed and is now being used.
2. This ephemeral state was rejected/not installed -- with potential codes
for why (out of range parameter, etc.)
3. This ephemeral state was not installed, but is being held as a backup.

Using these semantics, the actual implementation of such a feature is up to
the local agent. It might be that some agents don't know how to hold backup
information, or that it doesn't make any sense to hold some sorts of
information in a backup list. This is fine -- the install can just be
rejected without further note. Locally configured information could simply
be treated as an item on the backup list, such that the priorities can be
considered as always in deciding what to install when any particular action
is taken.

It seems, to me, that this is a simpler way to consider the same problem
set, and reduces to an actual protocol mechanism that appears (?) to be
fairly simple, and leaves as much flexibility as possible for any given
agent implementation.

Thoughts?

:-)

Russ 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Joel M. Halpern]

We discussed storing backup ephemeral state.  There are a number of 
issues that arise if we permit that.


For example, if state gets over-ridden, but preserved, then even though 
it is not doing any good, the client which installed the state must 
still monitor for any related dependenecies so as to not leave incorrect 
pending state.
Which also means that a client has to be able to remove state it has 
created, even though that state has been over-ridden.  And probably has 
to be able to create state which won't take effect.  Which in turns 
means that you need to be able to read your own effects and the current 
state separately.


In general, earlier working group discussion found this to add a lot of 
complexity.  So our agreement for now is that there is no storing of 
non-effecting state by I2RS.  Caching or other performance improvements 
are for future study.


Yours,
Joel

On 11/2/15 7:39 PM, Russ White wrote:

Y'all --

After sleeping on the discussion last night, I think the panes of glass (or
is it pains of glass?? :-)  ) is still by and large another expression of
the priority concept within I2RS. The concept does bring up one specific
point of interest, however -- what about backup information? Some vendor
RIBs, for instance, allow a routing process to install not only the best
path as calculated by the process -- but if the process fails to install,
some RIB implementations allow the process to place the route in the "backup
pool." This allows the local RIB process to drop to the "second best path,"
in terms of priority, so the local RIB doesn't need to query the routing
processes to switch in the case of a withdraw or change in topology.

To convert this to I2RS terms, it does seem worthwhile to me to have the
capability for a local agent to accept an install instruction for some
particular ephemeral state, and if the install fails, to hold that state for
future use. This would apply to any sort of ephemeral data, including that
which is configured locally on the network device. Rather than trying to
think of this as "panes of glass," though, this would convert it to simply a
backup list of lower priority items the local agent can use in the case of
the failure of the highest priority item currently in use.

The nice thing about this view is that it doesn't require a lot of changes
at the protocol level. The only thing that needs to be available is the
option for an agent to send three different types of answers to an install
request --

1. This ephemeral state was installed and is now being used.
2. This ephemeral state was rejected/not installed -- with potential codes
for why (out of range parameter, etc.)
3. This ephemeral state was not installed, but is being held as a backup.

Using these semantics, the actual implementation of such a feature is up to
the local agent. It might be that some agents don't know how to hold backup
information, or that it doesn't make any sense to hold some sorts of
information in a backup list. This is fine -- the install can just be
rejected without further note. Locally configured information could simply
be treated as an item on the backup list, such that the priorities can be
considered as always in deciding what to install when any particular action
is taken.

It seems, to me, that this is a simpler way to consider the same problem
set, and reduces to an actual protocol mechanism that appears (?) to be
fairly simple, and leaves as much flexibility as possible for any given
agent implementation.

Thoughts?

:-)

Russ

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Russ White]

> For example, if state gets over-ridden, but preserved, then even though it
is
> not doing any good, the client which installed the state must still
monitor for
> any related dependenecies so as to not leave incorrect pending state.
> Which also means that a client has to be able to remove state it has
created,
> even though that state has been over-ridden.  And probably has to be able
> to create state which won't take effect.  Which in turns means that you
need
> to be able to read your own effects and the current state separately.

I would think this should be a client specific implementation detail... I
don't see why, from a protocol level, it should be disallowed, when the
changes involved would be minor (or at least it seems to me?).

:-)

Russ

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Ownership and Subscription

[Joel M. Halpern]

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

On 11/2/15 8:27 PM, Russ White wrote:



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






___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Russ White]

> Allowing caching means that we have to specify additional mechanisms (such
> as read-through and write-through, and returns for successful writes that
do
> not actually take effect, and probably other aspects.)

I don't really see it as "caching..." I'm thinking more of the backup route
situation in the RIB, specifically.

> So we agreed that was for future consideration, as it is by no means
minor.

I would argue it's worthwhile to at least leave space in the protocol
definition for the third return option, and leave it up to agent
implementations to deal with the complexity if desired in the future.

:-)

Russ

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Mon, Nov 2, 2015 at 6:05 PM, Joel Halpern Direct <
jmh.dir...@joelhalpern.com> wrote:

> What we side with regard to the atomicity of collisions was that the model
> needed to specify that.  So if the model writer concludes that the leaves A
> and B in your example are so closely coupled that bad things will happen if
> different people write different parts, then they can say the container is
> the granularity.  Usually, I would expect the leaf to be the granularity.
> We do not expect the I2RS agent (or the underlying system) to guess the
> granularity.
>
>
OK -- so it is part of the data model definition.  Good.
These are the details wrt/ "first wins" that need to be understood.
The WG and proto-dt needs to think about what YANG extensions would be
needed
to describe these boundaries in machine-usable form.

Yours,
> Joel
>
>
Andy


> On 11/2/15 9:02 PM, Andy Bierman wrote:
>
>>
>>
>> On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7ri...@gmail.com
>> > wrote:
>>
>>
>>  > For example, if state gets over-ridden, but preserved, then even
>> though it
>> is
>>  > not doing any good, the client which installed the state must still
>> monitor for
>>  > any related dependenecies so as to not leave incorrect pending
>> state.
>>  > Which also means that a client has to be able to remove state it
>> has
>> created,
>>  > even though that state has been over-ridden.  And probably has to
>> be able
>>  > to create state which won't take effect.  Which in turns means
>> that you
>> need
>>  > to be able to read your own effects and the current state
>> separately.
>>
>> I would think this should be a client specific implementation
>> detail... I
>> don't see why, from a protocol level, it should be disallowed, when
>> the
>> changes involved would be minor (or at least it seems to me?).
>>
>>
>> I am not sure I understand edit collision processing.
>> The proposals is that the ephemeral datastore contains data
>> from 1 or more clients.  The data from different clients is
>> non-overlapping
>> (for some definition of that).
>>
>> I will avoid running config + ephemeral leaf-override for now.
>> Assume the data model is entirely for I2RS:
>>
>>container foo {
>>   leaf A { type int32; }
>>   leaf B { type int32; }
>>}
>>
>> 1) client-worst set /foo/A to 42{ "foo": { "A":42 } }
>>
>> 2) client-best sets /foo/B to 7   { "foo": { "B":7 } }
>>
>> 3) Is client-best going to knock out data owned by client-worst?
>> what happens to /foo/A?
>>
>> Q1) Is this a collision because /foo is written by both clients?
>>if not, does client-best own /foo and /foo/A, and client-worst owns
>> /foo/B?
>>If yes, then step (2) is effectively a PUT, no matter what method is
>> really used
>>
>> Q2) what notifications are sent to client-worst, if any (depending on
>> answer to Q1)
>> (client-worst either lost ownership of /foo or /foo and /foo/A)
>>
>> Consider that A and B can be arbitrary subtrees, not just leafs.
>>
>> How are the edit collision boundaries specified?
>> Simple YANG overlap will cause lots of deletions.
>> More granular/complex boundary specification would help
>> avoid such deletions where the 2 clients could actually co-exist.
>>
>>
>> :-)
>>
>> Russ
>>
>>
>>
>> Andy
>>
>> ___
>> i2rs mailing list
>> i2rs@ietf.org 
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>>
>>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7ri...@gmail.com> wrote:

>
> > For example, if state gets over-ridden, but preserved, then even though
> it
> is
> > not doing any good, the client which installed the state must still
> monitor for
> > any related dependenecies so as to not leave incorrect pending state.
> > Which also means that a client has to be able to remove state it has
> created,
> > even though that state has been over-ridden.  And probably has to be able
> > to create state which won't take effect.  Which in turns means that you
> need
> > to be able to read your own effects and the current state separately.
>
> I would think this should be a client specific implementation detail... I
> don't see why, from a protocol level, it should be disallowed, when the
> changes involved would be minor (or at least it seems to me?).
>
>
I am not sure I understand edit collision processing.
The proposals is that the ephemeral datastore contains data
from 1 or more clients.  The data from different clients is non-overlapping
(for some definition of that).

I will avoid running config + ephemeral leaf-override for now.
Assume the data model is entirely for I2RS:

  container foo {
 leaf A { type int32; }
 leaf B { type int32; }
  }

1) client-worst set /foo/A to 42{ "foo": { "A":42 } }

2) client-best sets /foo/B to 7   { "foo": { "B":7 } }

3) Is client-best going to knock out data owned by client-worst?
   what happens to /foo/A?

Q1) Is this a collision because /foo is written by both clients?
  if not, does client-best own /foo and /foo/A, and client-worst owns
/foo/B?
  If yes, then step (2) is effectively a PUT, no matter what method is
really used

Q2) what notifications are sent to client-worst, if any (depending on
answer to Q1)
(client-worst either lost ownership of /foo or /foo and /foo/A)

Consider that A and B can be arbitrary subtrees, not just leafs.

How are the edit collision boundaries specified?
Simple YANG overlap will cause lots of deletions.
More granular/complex boundary specification would help
avoid such deletions where the 2 clients could actually co-exist.




> :-)
>
> Russ
>
>

Andy



> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Joel Halpern Direct]

What we side with regard to the atomicity of collisions was that the 
model needed to specify that.  So if the model writer concludes that the 
leaves A and B in your example are so closely coupled that bad things 
will happen if different people write different parts, then they can say 
the container is the granularity.  Usually, I would expect the leaf to 
be the granularity.  We do not expect the I2RS agent (or the underlying 
system) to guess the granularity.


Yours,
Joel

On 11/2/15 9:02 PM, Andy Bierman wrote:



On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7ri...@gmail.com
> wrote:


 > For example, if state gets over-ridden, but preserved, then even
though it
is
 > not doing any good, the client which installed the state must still
monitor for
 > any related dependenecies so as to not leave incorrect pending state.
 > Which also means that a client has to be able to remove state it has
created,
 > even though that state has been over-ridden.  And probably has to
be able
 > to create state which won't take effect.  Which in turns means
that you
need
 > to be able to read your own effects and the current state separately.

I would think this should be a client specific implementation
detail... I
don't see why, from a protocol level, it should be disallowed, when the
changes involved would be minor (or at least it seems to me?).


I am not sure I understand edit collision processing.
The proposals is that the ephemeral datastore contains data
from 1 or more clients.  The data from different clients is non-overlapping
(for some definition of that).

I will avoid running config + ephemeral leaf-override for now.
Assume the data model is entirely for I2RS:

   container foo {
  leaf A { type int32; }
  leaf B { type int32; }
   }

1) client-worst set /foo/A to 42{ "foo": { "A":42 } }

2) client-best sets /foo/B to 7   { "foo": { "B":7 } }

3) Is client-best going to knock out data owned by client-worst?
what happens to /foo/A?

Q1) Is this a collision because /foo is written by both clients?
   if not, does client-best own /foo and /foo/A, and client-worst owns
/foo/B?
   If yes, then step (2) is effectively a PUT, no matter what method is
really used

Q2) what notifications are sent to client-worst, if any (depending on
answer to Q1)
(client-worst either lost ownership of /foo or /foo and /foo/A)

Consider that A and B can be arbitrary subtrees, not just leafs.

How are the edit collision boundaries specified?
Simple YANG overlap will cause lots of deletions.
More granular/complex boundary specification would help
avoid such deletions where the 2 clients could actually co-exist.


:-)

Russ



Andy

___
i2rs mailing list
i2rs@ietf.org 
https://www.ietf.org/mailman/listinfo/i2rs




___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs