> The notification to a client that some or all of its data was just overridden > is a > separate matter from whether the client wants all or part of its data to be > removed or altered.
I would argue this should be a SHOULD... The idea would be that any client who sets state should be subscribed, but anyone can unsubscribe. This leaves the default to the "right thing," but gives clients the option to sort their own "aggregation" of signaling for efficiency/etc. I'm uncertain about the unsubscribe at this point -- I tend to think we shouldn't bother with "auto-unsubscribe on remove state," as we can't guess either way, and it's just as easy for clients to queue up the removal of state and the unsubscribe one after the other. Not convinced this is the right answer, though -- thoughts? > One proposal to the design team is the notion that the server supports an > advertised (static) number of clients (max client panes). > Each client must be assigned a priority, such that every client has its own > pane, so adding a valid edit does not fail. Activating the edit is a separate > matter. Each client can flush all or part of its own pane. Just to clarify, I think we're all saying the same thing, just using different terms. If each client must have a unique id, and the client id is directly tied to the priority of the client in terms of installing state, then the pane is also "everything with the same priority," which also means "everything installed by one client." So in relation to the state of a single object, the list of "lower priority" things that aren't installed can be seen as what Joel is calling a "cache." From the perspective of the client, all the state it has installed can be seen as a "pane." Does this sound right to everyone? One point -- it might not be valid for each type of object to have this sort of "backup information." For instance, in the case of a virtual topology built in ephemeral state, it might well be the case (I've not thought it through yet) that it is an error to overwrite lower priority information with higher. To Joel's point, the backup data (I don't like the term "cache," because it has a different set of connotations for me, but I can deal with it if that's the term everyone settles on) could introduce a lot of complexity unless we also introduce the idea of a set of "things" as a "whole object." In other words, in the case of a route, a "whole object" might include the reachable destination (NLRI in BGP terms), the next hop (which could be a tunnel tail end from the local router's perspective), potentially a stack of markers (like an MPLS label stack), potentially an outbound interface, and potentially a MAC header rewrite. This entire "object" would need to be installed as one "thing," think, to make the "cache" coherent (again, I could be wrong here). To change just the "next hop," a client would need to install "the whole route," I think, or we risk some major issues in coherency. I'm not saying this is possible/not possible today, just throwing out thoughts as they occur to me. Does all of this make sense? :-) Russ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
