Hi, Re the metric 'problem', just to be more precise in what would be needed, we are looking a metric that grows or decreases monotonically across the whole network. The theoretical grounds for this are in T. Griffin’s and Sobrinho’s work on BGP-4 and that lies already a couple of years ago and that makes the analysis much ‘easier’ (no worries about np(complete) problems, etc.). This could be applied in I2RS at the routing protocol level. So, we could discuss where that sits (should be the clients, right?) and I don’t know if that’s been already done, since I’m quite new to this list.
Now, having “solved” that part of the equation :-) , the part that interests me more is the conflicting clients problem, because this could be generalised to other problem spaces in the SDN area. I do agree that agents should be able to catch offending state before installing it and I’m looking for ways to specify a minimal set of features that need to be supported at protocol level. Anyone else interested? BR, /PA --- Dr. Pedro A. Aranda Gutiérrez Technology Exploration - Network Innovation & Virtualisation email: pedroa d0t aranda At telefonica d0t com Telefónica, Investigación y Desarrollo C/ Zurbarán,12 28010 Madrid, Spain Fragen sind nicht da, um beantwortet zu werden. Fragen sind da, um gestellt zu werden. Georg Kreisler -----Mensaje original----- De: Russ White <[email protected]> Fecha: viernes, 20 de noviembre de 2015, 14:11 Para: paag <[email protected]>, 'Jeffrey Haas' <[email protected]> CC: "[email protected]" <[email protected]>, "'Joel M. Halpern'" <[email protected]>, 'Andy Bierman' <[email protected]>, Sue Hares <[email protected]> Asunto: 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 > ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
