Joel: <WG chair Hat on> My recollection of the meeting is that the operations people wanted limit I2RS validation to get performance. <WG chair hat off>
Is this decision reasonable to the group? Does this decision mean our notifications in RIB-IM/RIB-DM should change? Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern Sent: Monday, November 30, 2015 4:27 PM To: Andy Bierman Cc: Jeffrey Haas; PEDRO ANDRES ARANDA GUTIERREZ; Russ White; Susan Hares; [email protected] Subject: Re: [i2rs] Conversation on Priority and Panes I agree Andy. We have our choice of poison. We can perform full validation, which is likely to be slow, but very useful. Or we can omit validation, which introduces risks. I don't know if I would call those security risks in general, although one can probably get some security risks out of validation failures. (We do still assume that permissions are checked.) The conclusion after discussion last time around, and particularly the request from the operators who were in the room at the time, was that the operators were happy with a situation where they could gain significant performance at the risk of shooting themselves in the foot. Yours, Joel On 11/30/15 3:20 PM, Andy Bierman wrote: > 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] > <mailto:[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] > <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] <mailto:[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]> > > > <mailto:[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] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>%20%3cmailto:[email protected] > <mailto:20%253cmailto%[email protected]>>>> > > > Fecha: lunes, 23 de noviembre de 2015, 14:06 > > > Para: paag <[email protected] > <mailto:[email protected]> > > > <mailto:[email protected] > <mailto:[email protected]>>>, 'Jeffrey Haas' > > > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>%20%3cmailto:[email protected] > <mailto:20%253cmailto%[email protected]>>>> > > > CC: "[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] > <mailto:[email protected]>%20%3cmailto:[email protected] > <mailto:20%253cmailto%[email protected]>%3e>" <[email protected] > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>>, > "'Joel M. Halpern'" > > > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>%20%3cmailto:[email protected] > <mailto:20%253cmailto%[email protected]>>>>, 'Andy > > > Bierman' <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>%20%3cmailto:[email protected] > <mailto:20%253cmailto%[email protected]>>>>, Sue > > > Hares <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>%20%3cmailto:[email protected] > <mailto:20%253cmailto%[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]> <mailto:[email protected] > <mailto:[email protected]>> > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
