On Mon, Nov 30, 2015 at 1:26 PM, Joel M. Halpern <[email protected]> wrote:
> 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. > > That's fine with me. The agent developer will be under pressure not to let the router segfault just to be a little faster (as always). A buffer overrun is still a problem whether a YANG constraint like "max-elements" exists or not . Yours, > Joel > Andy > > 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
