Joel: Comments below. Thank you for your comment.
Sue -----Original Message----- From: Joel M. Halpern [mailto:[email protected]] Sent: Thursday, November 05, 2015 2:38 AM To: Susan Hares; 'Joel M. Halpern'; 'Andy Bierman' Cc: [email protected]; 'Russ White' Subject: Re: [i2rs] Conversation on Priority and Panes There are two VERY basic questions. [agreed] 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. <wg chair hat on> [Sue: agreed - this is what we agreed upon. I am doing a "final check" on this concept before I ship off the requirements to the NETCONF. ] <wg chair hat off> 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. <wg chair hat on> [Sue: I am asking for the side effects so that I have an informed list and implications. You can send these to the list or to me individually.] <wg chair hat off> <individual contributor hat on> My work with NETMOD/NETCONF has changed some of my views so I am asking this question to understand how it aligns with the new things I have learned. 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. [Sue: In my personal opinion, I think RIB only solution works for Protocol independent RIB, FB-RIB, and topology. ] <individual contributor off> <wg chair on> 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. We have not changed the WG conclusion to treat collision as an error. I am fact finding to see if others still see the list of problems. I am asking people to send the problem list to me or the list. <WG hat off> 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. <individual contributors hat on> Are you concerned about the model changing or the data within a model changing? My understanding is the netconf module library yang module can provide model changing info. This is one way that the route policy make assumptions about the route. If the data changes regarding policy, these policy nodes can have version. In the gated implementation of this concept (10+ years ago), we used a policy node version in order to solve this problem. We also used a binary version of XML. <individual contributor hat off> <WG chair hat on> Joel I appreciate your patience as I discuss pro/cons because I must defend our joint work to NETCONF. <WG chair hat off> 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
