Hi, I think it is fairly clear that the server will only be able to detect a direct overlap. In any case, the client that is getting data removed needs to use pub/sub to be told what is going on. The I2RS agent will not set up any pub/sub for any client. The client must do this itself via pub/sub configuration. The agent will just return an error if the edit is not accepted.
The current YANG design is clear: No client is allowed to cause an edit that will leave the datastore invalid wrt/ YANG validation. That means that a high priority client WILL LOSE if it attempts to overwrite partial data in a way that breaks validation. (This is not what the I2RS arch says to do). A "solution" might be to ignore all YANG validation in the ephemeral datastore. Full YANG validation will be slow and even more complicated than plain NETCONF. No validation will be a huge security hole. Andy On Mon, Nov 30, 2015 at 11:30 AM, Joel M. Halpern <[email protected]> wrote: > I am not understanding your comment. > As I understand it, Andy was asking about indirect collisions or side > effects, where modification of item A by entity B (either an over-write or > just a modification of something that was in base config) make the > modification C that was done by entity D incorrect. We had discussed that, > and agreed that as a general matter, such indirect problem detection was > not something we want (wanted) to address. > There are some cases that are represented by YANG constraints. I don't > think our decision on this reflects an opinion on what and which YANG > constraints should be enforced by I2RS. The issue is generally about side > effects that are not anticipated by model designers. > > The assumption ew made was that at least the application designer had a > hope of anticipating them, and therefore the client could monitor objects > when there is a state dependency. (If no one realizes there is a > dependence, things will break. I don't see a way around that.) > > Yours, > Joel > > On 11/30/15 2:23 PM, Susan Hares wrote: > >> Joel and Andy: >> >> For the first version of the I2RS protocol, the WG did agree that the >> I2RS agent is required to detect and report on collisions. However, >> Andy is asking a valid question on how to detect the linkage within >> models or between models. >> >> Andy's example is one of the group portions of a model (eg. An I2RS RIB >> route) or group portions between multiple models (BGP policy + BGP peer >> or BGP Policy and BGP local route). >> >> I tried to present this concept at IETF 94 to start this discussion. >> >> The solutions can be: a) model structure or language in yang to detect >> grouping within a model, b) Yang library information to detect modules, >> or c) something else. >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern >> Sent: Tuesday, November 24, 2015 11:15 AM >> To: Andy Bierman >> Cc: Jeffrey Haas; PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; Russ >> White; [email protected] >> Subject: Re: [i2rs] Conversation on Priority and Panes >> >> 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. >> >> Yours, >> >> Joel >> >> 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] >> <mailto:[email protected]%20%3cmailto:[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] >> <mailto:[email protected]%20%3cmailto:[email protected]>>> >> >> > CC: "[email protected] <mailto:[email protected]> >> <mailto:[email protected]%20%3cmailto:[email protected]%3e>" <[email protected] >> >> > <mailto:[email protected]>>, "'Joel M. Halpern'" >> >> > <[email protected] <mailto:[email protected] >> <mailto:[email protected]%20%3cmailto:[email protected]>>>, 'Andy >> >> > Bierman' <[email protected] <mailto:[email protected] >> <mailto:[email protected]%20%3cmailto:[email protected]>>>, Sue >> >> > Hares <[email protected] <mailto:[email protected] >> <mailto:[email protected]%20%3cmailto:[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] <mailto:[email protected]> >> >> https://www.ietf.org/mailman/listinfo/i2rs >> >>
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
