On 11/5/15 20:18, Russ White wrote:
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?
I don't think we should assume that just because the client removes
state it wants to unsubscribe from the stream. It may want to watch
what's going on for events where it can reinsert itself (as an example).
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?
Yes, this gels with my understanding.
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?
It does. One other point that Jason Coleman, Jason Sterne and I were
discussing yesterday is how we handle config in this same pane of glass
model. That is, if I want to override a route via config, how would
that work with existing ephemeral state?
The idea proposed was to be able to assign a priority to those [static]
routes that would, in essence, make them ephemeral with the associated
priority. This would allow one from the CLI participate in the I2RS
process.
There might be other options, but this made a lot of sense at the time.
Joe
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
