Russ: [Still Catching up on old email.. ] The I2RS priority in the architecture requires each client has 1 priority. The architecture allows for multiple clients to have the same priority (client 1 priority 1; client 2 priority 2). The resolution for two clients having the same priority is first-one at a priority level wins.
I agree that the protocol can only be accurate. The final solution is the metric that resolves all contention on priority and ties on priority. Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Russ White Sent: Friday, November 20, 2015 8:11 AM To: 'PEDRO ANDRES ARANDA GUTIERREZ'; 'Jeffrey Haas' Cc: [email protected]; 'Joel M. Halpern'; 'Andy Bierman'; 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes > 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
