Pedro: I welcome your insights on this problem space.
Sue -----Original Message----- From: PEDRO ANDRES ARANDA GUTIERREZ [mailto:[email protected]] Sent: Friday, November 20, 2015 2:13 AM To: Jeffrey Haas; Russ White Cc: [email protected]; 'Joel M. Halpern'; 'Andy Bierman'; 'Susan Hares' Subject: Re: [i2rs] Conversation on Priority and Panes HI list, I’m working on a project were we are also taking on this problem space. Although we are currently OpenFlow based, we are trying to generalise our mechanisms. We hope we may be able to contribute in this discussion. Best, /PA PS: answers inline --- 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 >An API based mechanism addresses the issue, but the question basically >comes down to how to expose the remainder of the associated state for >the RIB in such an implementation. Do we expose operational state? If >so, we can have a config=false representation of that state. You either expose the state or you require the different apps to maintain a copy of the state, which is sort of A) dangerous, because an app could be building a corrupted/biased view of the state if they cannot “spoof" the configuration traffic from other apps and then start creating havoc B) tedious, because we need all apps to replicate the state >How do we expose the provisioned state? Do we require the user to >issue a series of RPCs to get the state? It would be very convenient >if it were present as a config=true set of nodes, but this is the >problem we're avoiding. What we'd end up with is potentially something >similar to what the OpenConfig group wants: state that is provisioned, >but distinct from the operational state of the system. In this >example, it'd be effectively a second piece of operational state. I see the benefits of that approach. However there is a drawback there and that is the responsiveness and how to control race conditions there: APP1: gets (and locks) the state, calculates the new state and then writes (and unlocks) the state APP2: sees the state is locked and waits until it is unlocked to get and lock it to do its operations That A) may slow down apps a lot. (Dunno if that can be even desirable to avoid oscillation) B) rings some bells in the back of my mind regarding deadlocks I studied (long ago) at the university :-) like what happens if APP1 and APP2 access the state at the same time, etc. > >I'm thinking more and more that a significant portion of our problem >spaces come down to some form of the above discussion. I2RS priority >is rather painful to create and enforce when your interface to >provision it is config=true nodes in an ephemeral datastore. It's a >bit clearer when it is provisioned via RPC instead. > >-- Jeff > >_______________________________________________ >i2rs mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/i2rs ________________________________ 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
