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
