This was discussed with the working group, and the agreement was that
I2RS changes did not have lifetimes, were not dependent upon a
maintained connection, and were removed either on device reboot or
removal by the controller that put them there (or when overriden my
erroneous overlap.)
If you ahve new perspectives that were not discussed before, you can of
course ask the chairs to reopen the discussion.
Yours,
Joel
On 8/14/15 4:57 PM, Linda Dunbar wrote:
Thanks Joel and Andy for the clarification.
See my additional comments inserted below:
*From:*Andy Bierman [mailto:[email protected]]
*Sent:* Saturday, July 18, 2015 9:55 PM
*To:* Linda Dunbar
*Cc:* [email protected]; Susan Hares; [email protected]
*Subject:* Re: [i2rs] multi-headed control of I2RS agent v.s.
i2rs-Ephemeral-state
Hi,
very interesting comments...
I agree these are requirements that could apply to more than I2RS.
The first-one-wins (via client priority) details could apply to
configuration
as well as ephemeral state, and I wonder if NETCONF
should be changed to support it.
I don't agree that a lost connection caused all the state for that client
to disappear. In NETCONF, it is generally only the edits in progress
that are tossed. Since I2RS will not use a candidate config,
these multi-PDU edits should not be possible in I2RS.
[Linda] The lost connection could mean that configuration from the I2RS
agent is stale. At least there should be a timer for the data from the
I2RS agent whose connection has been lost. When the Timer expired during
the connection loss, the configuration should be wiped out.
Linda
I agree that the "access" procedures for ephemeral state can
be separated from "multi-head" procedures, but they are somewhat
coupled. I think the arch. doc mentioned parameters sent with an
edit to ask for a notification if the edit is rejected because higher
priority data already exists (notify me when my edit might work).
It seems multi-head control is mandatory to support.
Andy
On Sat, Jul 18, 2015 at 3:01 PM, Linda Dunbar <[email protected]
<mailto:[email protected]>> wrote:
Sue and Jeff,
There have been many postings/comments to
draft-ietf-i2rs-ephemeral-state-00, I went through many, but not all. In
case my comments have been addressed by previous postings that I missed,
I am really sorry for wasting your time.
I find the majority of the content in draft-ietf-i2rs-ephemeral-state-00
is about the “multi-headed control of a I2RS agent”.
IMHO, the “I2RS-ephemeral-state” should be addressed separately from
“multi-headed control”, because for networks that only use single
controller, they don’t have to deal with the complicated scheme of
multiple controllers, but they do need to conform to the
“ephemeral-state” via I2RS interface.
“I2RS-ephemeral-state” should be simply:
- all commands from I2RS interface are ephemeral, i.e. they do not
sustain restart, and all configuration from I2RS interface are voided
(or removed) when the connection to the I2RS agent is lost.
The Multi-headed control scheme described in the draft can also be
applied to persistent configuration.
draft-ietf-i2rs-ephemeral-state-00 introduced a new “ephemeral-config”
to NETCONF, does it mean that if I2RS client uses regular “config”
instead of “ephemeral-config”, the configuration becomes persistent?
It shouldn’t, in my opinion.
Linda Dunbar
_______________________________________________
i2rs mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
