> The danger I see there is that a specific policy applied by one client (app) > may > trigger unintended changes in a part of the "planes of glass" it is not aware > of. Hence a full copy is needed in each client (app) may be needed… This also > holds for subscribing to change notifications. How can I subscribe to a change > notification of something I’m not or I don’t want to be aware of?
I don't see how that's going to be any different whether the alternate states are held in the agent or on the clients -- either way, doing "x" might trigger some other client to do "y." The only difference is how long it takes for the first client to see the second client doing "y," and then reacting to it by doing "z." Even trying to make certain every client has a full list of all possible conditions there will still be race conditions in the mix, so that won't solve the problem, either. At some point, you're going to hit your head against CAP -- it's just a matter of where, when, and how to manage it. The only real solution to this sort of problem is to have a definitive single "metric" that provides an answer to every situation. Just like with a routing protocol, you can't build a distributed system that uses more than one metric without ending up with wedgies (hence BGP). Mike Shand once told me this is an np(complete) problem -- I'm guessing Mike is right on this one. It seems, to me, that this is precisely what the "priority" in this system provides -- in any case, the client with the best priority wins. As no two clients can have the same priority (it's tied to the client id, from what I remember), it "just works." The one situation you can get in to is when client 1 says "do x," client 2 says, "do y," and you end up with a routing loop or contradictory policies applied. This is going to be a problem no matter where the information is stored. I don't think we can address this at the protocol level -- all the protocol can do is be as accurate about current state as it's installed as possible. The agent should be able to detect some situations like this and refuse to install the offending state. The clients may be able to detect some of this, as well, and fix things. But I don't see how we could specify such a thing in the protocol. Or rather, if we do, when we'd ever be able to stop specifying such things... :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
