The basic problem I have with your description is that it treats
over-writes as normal and desirable, and assumes that the priority
handling is producing the correct results. If we actually believed
that, I suppose making them more efficient would be sensible.
But that is not actually what we are doing. Priority over-write is a
disambiguation mechanism. There is no expectation that it is even a
good heuristic for correctness. It is merely predictable. Trying to
optimize the control loop for cases of improper behavior seems the wrong
place to optimize.
Having said that, if we want to get into multiple panes of ephemeral
glass then we are going to need mechanisms to
read the composite effect
read what I as a client have applied
indicate in the response to a write request that the agent has accepted
the request, even though it is not actually taking effect.
And if we do all that, clients whose state is pending will need to
maintain monitoring of all related activities even though their network
application is not in effect.
And, if there are multiple aspect of an operation, if one gets
over-written but retained, then the client probably can't leave it
there, but has to go in and remove that state, since the client will
likely be removing the rest of the related state that is still sitting
there with its lynchpin missing.
And then we get into the question of how much unapplied state is an
agent going to store. So it all probability the client still has to be
prepared for being told that not only was its state over-written (which
is technically an error) but that it got deleted too.
Yours,
Joel
On 11/3/15 6:14 PM, Andy Bierman wrote:
Hi,
This raises a data modeling issue.
Should every "backup parameter" be modeled explicitly in
the YANG module, or can the ephemeral datastore be used
for that, without any additional data model objects?
The I2RS architecture supports this "backup" concept (lower priority
client),
except it requires a notification from the agent and subsequent request
from the client to make the backup active. With NETCONF or RESTCONF
today, that round-trip will probably take around 500 to 1000 milli-seconds.
Probably much worse during high loads.
Our original proposal to the design team included a pane of glass
for each client (and unique priorities for each client), because some people
were talking about sub-milli-sec latency, and I know there is no way NETCONF
or RESTCONF is going to support this sort of tight control loop.
Whether the server rejects lower-priority edits right away, or whether
the agent caches the request in the form of a client-specific pane,
the client still needs to observe the data resources with pub/sub
and decide whether its own particular state is still relevant.
IMO the client complexity is the same either way, especially
since the caching is only done if the client requests it.
The only difference is likely to be almost a million times faster
fail-over to the backup on the server.
Andy
On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares <[email protected]
<mailto:[email protected]>> wrote:
Russ thank you for kicking off this discussion. It is an interesting
approach. I know that certain RIB implementations allows a back-up
route.
Sue
-----Original Message-----
From: i2rs [mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Russ White
Sent: Monday, November 02, 2015 7:39 PM
To: [email protected] <mailto:[email protected]>
Subject: [i2rs] Conversation on Priority and Panes
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
