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
