Pedro:
<WG hat off> For my person insight (as IDR chair) I would like to hear off-list how you think Griffin's work applies to the I2RS context. Russ has given his reason why. I agree I2RS is now discussion the conflict of configuration between clients · assume that we have two or more clients that produce perfectly sound routing information (no wedgies there), · assume they talk to the same agent For your 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? · I think you must break determine if you are working on the same data model or linked models. · Currently we use the priority metric + First wins. I’m interest to hear about alternative ways. <WG Hat on> Please note that I have not changed what will be in I2RS protocol version 1, but it is important to provide additional insight to NETCONF/RESTCONF-I2RS protocol team on what might come in generation 2 of the I2RS protocol. <WG Hat off> Sue -----Original Message----- From: PEDRO ANDRES ARANDA GUTIERREZ [mailto:[email protected]] Sent: Tuesday, November 24, 2015 10:32 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 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 < <mailto:[email protected]> [email protected]> Fecha: lunes, 23 de noviembre de 2015, 14:06 Para: paag < <mailto:[email protected]> [email protected]>, 'Jeffrey Haas' < <mailto:[email protected]> [email protected]> CC: " <mailto:[email protected]> [email protected]" < <mailto:[email protected]> [email protected]>, "'Joel M. Halpern'" < <mailto:[email protected]> [email protected]>, 'Andy Bierman' < <mailto:[email protected]> [email protected]>, Sue Hares < <mailto:[email protected]> [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 three 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
