Continuing in line, although this may get too deep:
On 10/1/14, 11:14 AM, Dean Bogdanovic wrote:
On Oct 1, 2014, at 11:08 AM, Joel Halpern Direct
<[email protected]> wrote:
In line:
On 10/1/14, 11:03 AM, Dean Bogdanovic wrote:
On Oct 1, 2014, at 10:53 AM, Joel M. Halpern
<[email protected]> wrote:
...
This actually does lead to a related question. How does an
I2RS client delte the state it has created. (Note that said
state might actually include a deletion from the underlying
data.)
How, if the client writes only into ephemeral store?
There is nothing in the I2RS work that says that the only requests
that the I2RS client can make are creation or modify operations.
It seems perfectly legitimate for an I2RS client to decide that the
what needs to be done is to remove some static route or policy
statement, because circumstances have temporarily changed.
That is opening a can of worms. You can not allow deletion of data
that is not owned by the client. That can create instability of the
system and the network. Using your example, I2RS client should enter
a new static route or policy statement that would nullify the
existing one.
One can argue that all of I2RS is a can of worms. But I don't think
that is reasoanble.
Your proposal would mean that if the goal of the I2RS client was to
cause a specific route, that had been pinned by the operator, to follow
dynamic routing instead, then the I2RS client would ahve to monitor the
rib for any non-applied changes, mirror the rib manager logic, and
manually update the static route with the answer the rib manager would
have produced if the static route were not there?
Seems rather complex and error prone for a reasonable policy hammer.
One of the agreements reached in teh I2RS work early on is that if the
operator wants to shoot his foot using I2RS and produce a really painful
configuration, then he is free to do so.
Yours,
Joel
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
