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
