On Tue, Nov 24, 2015 at 8:14 AM, Joel M. Halpern <[email protected]
<mailto:[email protected]>> wrote:
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.
OK, punting the problem is fair enough.
What happens when the YANG validation for /foo[19] and /bar[1]
now fails because /foo[42] was changed? Does the agent reject
the edit from the higher priority client? Does I2RS ignore YANG validation,
assuming the YANG authors really didn't mean what they wrote?
Yours,
Joel
Andy
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]>>>
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]>>>
CC: "[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>" <[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]>>>, 'Andy
Bierman' <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>, Sue
Hares <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[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
