On Tue, Nov 24, 2015 at 8:14 AM, Joel M. Halpern <[email protected]> wrote:
> The agent is required to detect and report direct collisions. > It is not required or expected to detect indirect collisions, which are > the complex source of wedgies and other interesting behaviors. > > OK, punting the problem is fair enough. What happens when the YANG validation for /foo[19] and /bar[1] now fails because /foo[42] was changed? Does the agent reject the edit from the higher priority client? Does I2RS ignore YANG validation, assuming the YANG authors really didn't mean what they wrote? Yours, > Joel > > Andy > PS: The WG discussed requiring a maintained connection between the client > and agent, and agreed not to do that. Which means that no, agents do not > delete state just because clients have disappeared. > > > On 11/24/15 11:01 AM, Andy Bierman wrote: > >> >> >> On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern <[email protected] >> <mailto:[email protected]>> wrote: >> >> I believe that determining whether two independent and internally >> consistent sets of changes can, in combination, produce a wedgie or >> other failure is a research problem. >> As far as I know, the I2RS working group concluded that it was a >> sufficiently hard problem that we did not expect the I2RS agent to >> get involved in trying to detect, much less remediate, such >> cross-object inconsistencies. >> >> >> >> But the I2RS agent is responsible for identifying an edit collision >> between >> a new low-priority request and existing higher priority edits. That sounds >> involved to me. So the agent cannot possibly solve this problem >> yet it is responsible for precisely that in order to implement client >> priority. >> >> The agent can see that /foo[42] exists in the request and /foo[42] exists >> in the ephemeral datastore, and call that a collision. >> >> However, if /foo[1] or /bar[19] are also part of the "edit", such that >> simply replacing >> /foo[42] will break things, then the agent will not know. It will simply >> overwrite >> /foo[42] and leave /foo[1] and /bar[19] in the datastore. >> >> So is the low-priority client responsible for removing /foo[1] and >> /bar[19]? >> Seems the answer is no. The client can go away and there are no cleanup >> requirements mentioned in the architecture. >> >> >> >> Yours, >> Joel >> >> >> >> Andy >> >> >> On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote: >> >> Hi Russ, >> >> I’m trying to identify the differences between interactions with >> routing protocols in I2RS and what is purely conflicts between >> clients. Currently I see too many issues overlapping and I fear >> that the trees are not letting us see the forest. >> >> So my take on routing protocols and wedgies might have been too >> compact :-) Let me give it a second try: Stepping outside the >> I2RS problem space, there is a lot of work that shows that the >> origin for BGP-4 instability is that our beloved route-maps >> create metrics that are not monotonically increasing or >> decreasing and that makes the routing protocols meta-stable. >> (BTW, I’m the first culprit when it comes to the use of them, I >> have created more than one wedgie :-P ) Acknowledging that this >> is a significant (and quite complex) problem for the Internet in >> general, I feel that it should be treated somewhere else (GROW?). >> >> The perspective I would like to take here is: >> - assume that we have two or more clients that produce perfectly >> sound routing information (no wedgies there) >> - assume they talk to the same agent >> - now my questions >> 1.- is there any way to detect whether the clients >> produce contradicting/conflicting information? >> 2.- is there any way to resolve these >> contradictions/conflicts? >> >> 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] <mailto:[email protected]>> >> Fecha: lunes, 23 de noviembre de 2015, 14:06 >> Para: paag <[email protected] >> <mailto:[email protected]>>, 'Jeffrey Haas' >> <[email protected] <mailto:[email protected]>> >> CC: "[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>, "'Joel M. Halpern'" >> <[email protected] <mailto:[email protected]>>, 'Andy >> Bierman' <[email protected] <mailto:[email protected]>>, Sue >> Hares <[email protected] <mailto:[email protected]>> >> Asunto: RE: [i2rs] Conversation on Priority and Panes >> >> >> 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. >> >> >> I assume you mean in the routing space, and not in the >> controller/client space, correct? In terms of a distributed >> protocol? So, you're saying the delay could use "metrics" >> between 11 and 20, while the bandwidth could use "metrics" >> between 21 and 30, etc? And then you just add them all >> together? That's what IS-IS has done for years... Even BGP >> really only has one "metric," with following "tie >> breakers..." So if you have something like weight/local >> pref/etc, such that they occupy different "spaces" in a bit >> pattern (something suggested, btw, in the original wide >> community work, and in other places, as well), you're >> actually just building a single metric. >> >> You've not "solved" the multiple metric problem -- just done >> something a little different than EIGRP's K values to >> combine them into a single metric, which is where you need >> to be to have the ability to build a single stable SPT/DAG. >> >> 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. >> >> >> This doesn’t apply to the problem at hand, though... You >> seem to be saying (clarify if wrong) -- >> >> 1. Give each client some set of bits out of a 128 bit number >> space (or larger, etc.) >> 2. Each client can have different "metrics" within their own >> number space >> 3. When a client attempts to add some ephemeral state, they >> use a metric within their "space" >> 4. The agent can just use the straight number as a relative >> priority for each potential piece of state >> >> This doesn't do anything different than the current concept >> of priority between clients, only in the current plan each >> client only has one priority, rather than multiples. I don't >> see where this relates to the problem at hand. >> >> 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? >> >> >> This is precisely where the problem lies. And this is where >> you're going to hit the CAP theorem in full force. There are >> only a few choices -- >> >> 1. Make the database eventually consistent >> 2. Shut down accessibility during changes >> 3. ?? >> >> (1) is the idea of either having the agent call back to all >> the clients when state they installed is overwritten or >> allowing the agent to locally store some state where it >> already has the information in hand and install it locally >> -- the only real difference between these two solutions is >> the "balance of complexity versus speed..." The entire >> discussion here is how much additional complexity are we >> actually adding by doing "panes of glass," which are just >> locally stored state which isn't currently installed. I'm >> arguing that there's minimal complexity added that you're >> not already going to have in the system to allow the agent >> to store information locally _if_ it chooses to. Jeff is >> arguing (I think) that the "panes of glass" concept is a >> coherent way of looking at this problem that will help us >> understand and manage the complexity in a way that makes >> sense. Joel is arguing (I think) that this sort of solution >> is out of the WG charter, and it's too complex. I _think_ I >> have the th >> >> r >> ee general perspectives right, but I don't know if I really have >> so... :-) >> >> >> (2) is the idea of locking the database while you're >> changing it. This is explicitly outside the scope of I2RS >> entirely, given we're trying to design something that's >> atomic/restful. There are a lot of techniques you can use to >> speed up locking -- row locking, sharding, etc. -- but none >> of these are interesting from the I2RS perspective. >> >> :-) >> >> 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
