There are two VERY basic questions.
First, is the case of two I2RS clients modifying the same "thing"
something we consider normal and desirable, or is it an error. The
earlier discussions was that it is an error. In discussing the many
different kinds of direct and indirect collateral issues that arise, we
concluded that we could not expect the I2RS agent to be able to
determine the "right" thing to do in the general case.
I have not seen any evidence that foer the general case we actually know
this better now. And I do see a LOT of side effects and implications.
For a pure RIB node solution, we already have the tools for multiple
writers. the existing RIB models already have the notion of multiple
entries whose key differs by who created the entry. And the notion that
the RIB manager decides. We could easily represent each I2RS client as
a source, and let the RIB manager handle the rest.
But this is a RIB only solution.
My understanding of the WG conclusion was that we wanted a common
solution for a broad range of cases, including the RIB. And that we
were happy to treat collision as an error. If there is new information
(I have not seen any) or if the WG has changed its mind, then so be it.
As an example, if one is creating policy entries that make assumptions
about your route entries being in efect, then having the system change
what is in effect can produce very strange and unexpected behaviors.
Yours,
Joel
On 11/5/15 2:05 AM, Susan Hares wrote:
Joel:
<chair hat off>
I agree that opening up the decision on caching will open a lot of issues.
In my mind, this email thread has shown there may be operational issues with
the "no-caching issue." We are about to send the requirements to the
IESG/NETCONF, and I want to validate the caching/no-caching decision.
Let me give an example.
Client 1 - priority 5 -- route1 nh 2 time 1
Client 2 - priority 6 -- route1 nh 1 time 2
Client 3 - priority 4 -- route 1 nh 3 time 3
Config - priority 0 - route 1 nh 4 time 2
Node = route with subnode nexthop
If you:
a) save the priority + Nh differences + priority + Time
b) assign config (lowest priority) + reboot tie
then the priority resolution can resolve the node.
I believe this is the basic multiple creators concept you mentioned in your
emails for RIBs. I believe we agree that this is solvable. I do not see how
this fails to solve a partial RIB.
Taking the P.I. Topology draft and FB-RIB, I think a similar sequences can
resolve the problem. If not, would you let me know the example that does
not fit.
In our earlier discussions, we stated the grouping of nodes (route, NH,
interfaces) did not fit the model. In my subsequent discuss with yang
folks, I came to realize a grouping of nodes which are under a particular
point and we could use this.
Route -----------
| \ |
Prefix Nh priority
If this is true, then the model could provide language that handles the
grouping of variables or things being referred. This understanding of the
capability (which other I2RS WG members may have known) provides me a way to
model the grouping of parameters. So, I can perceive a possibility of
solving caching.
Is this much of my question understandable? The next part of my question
was to inquire what do you see as some of the issues that we need to
consider on the panes of glass.
<i2rs individual contributor off >
Sue
-----Original Message-----
From: Joel Halpern Direct [mailto:[email protected]]
Sent: Wednesday, November 04, 2015 6:42 PM
To: Susan Hares; 'Joel M. Halpern'; 'Andy Bierman'
Cc: [email protected]; 'Russ White'
Subject: Re: [i2rs] Conversation on Priority and Panes
The working group can always reconsider any decision.
But if we are going to do so, we need to recognize that the earlier
discussion covered a LOT of issues that need to be dealt with.
I do not understand the question in the first part of your email, so I can
not comment on it.
It is quite clear that caching is not required to meet a <1 second loop.
In particular, this seems to be a major change in another agreement.
We as a group concluded that over-write and other forms of collision are
errors. They are not the control loop for which we are optimizing. The
loop we said we are after is the loop from event detection through analysis
and response generation to response application. That loop is completely
unaffected by caching.
So first, I think folks need to recognize that this discussion is revisiting
several different and related WG architectural agreements.
Yours,
Joel
On 11/4/15 5:23 PM, Susan Hares wrote:
Joel:
On the reading of composite panes, if you believe that ephemeral can
be set on any configuration node or as an independent then the
following
Config-node-1
ephemeral node-1 (client 1),
ephemeral Node-1 (client 2),
Each ephemeral node could have an ID and a priority. The composite
mode can apply a consistent policy: (E.g. high priority with tagging for
first-wins). Asking for a composite in the rpc for read is a possible
use
for the composite. Asking for all of these nodes is possible.
I believe this caching is required for the "tight-loop" issue of < 1
second response for query/response.
If we define the group issues in the Yang language, then I think we
can handle the multiple I2RS ephemeral entries with more memory space.
The amount of memory space used by the I2RS caching entries can be set
by the implementation in the Agent, and expressed by the model
capabilities. I agree with Andy's original position that Caching will
be necessary for high performance on medium to large scale Data models.
Lastly, I am not sure our consensus on the "no-caching" was strong
enough to refuse to consider it now. Meaning less than 10 people in
interims or email
-- should not prevent a larger group from reconsidering. This is a
different type of consensus as a long debate on list plus IETF
discussions.
Sue
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern
Sent: Tuesday, November 03, 2015 6:49 PM
To: Andy Bierman; Susan Hares
Cc: [email protected]; Russ White
Subject: Re: [i2rs] Conversation on Priority and Panes
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
