Catching up myself too… 1) I think I didn’t get my message through WRT Griffin/Sobrinho. I would constrict that kind of effects to the routing protocol (running as an App and sending NETCONF commands to the devices to configure the routes it computes), rather than including this kind of problem in the I2RS space. It seems to me that we would be unnecessarily complicating the problem, (which BTW is complex enough right now)
2) I see no flaw in v1. However, conflict resolution in general is a topic I’m working on and if work on v2 would include related topics, I’d be glad to try to contribute, Best, /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: Sue Hares <[email protected]> Fecha: lunes, 30 de noviembre de 2015, 20:14 Para: paag <[email protected]>, 'Russ White' <[email protected]>, 'Jeffrey Haas' <[email protected]> CC: "[email protected]" <[email protected]>, "'Joel M. Halpern'" <[email protected]>, 'Andy Bierman' <[email protected]> Asunto: RE: [i2rs] Conversation on Priority and Panes >Pedro: > >[Catching up with last week's email]. ><WG chair hat off> >I am aware of T. Griffin's and Sobrinho's work on a metric that can be applied >across the network. I am interested to see how this could be applied to I2RS >protocol. Could you provide off-list with an example of how this might work. > >On conflicting stages, >Catching conflicting states on a configuration is single node has been done in >many routers for syntax and for context. However, catching conflicting states >across the network is more difficult. Parts of the configuration may vary >from router to router. For example, if you focus on flow of data packets, >You must have a higher level abstraction that validates the flow of data >controlled by routes in routers, interfaces, and policy. > ><WG chair hat on> >Initial I2RS work examined some of these topics, but we agree this work was >out of scope for the version of the protocol. If you feel there flaw in our >first version of I2RS, please indicate this point. If you feel this topic >should be addressed in a second version, please let me know. > ><WG Chair hat off> > > >-----Original Message----- >From: PEDRO ANDRES ARANDA GUTIERREZ [mailto:[email protected]] >Sent: Monday, November 23, 2015 2:04 AM >To: Russ White; 'Jeffrey Haas' >Cc: [email protected]; 'Joel M. Halpern'; 'Andy Bierman'; 'Susan Hares' >Subject: Re: [i2rs] Conversation on Priority and Panes > >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 > ________________________________ 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
