Subject: Re: [i2rs] multi-headed control of I2RS agent v.s. i2rs-Ephemeral-state

From: Linda Dunbar <[email-masked]>
Date: Fri, 14 Aug 2015 20:57:37 +0000

Thanks Joel and Andy for the clarification.

See my additional comments inserted below:

From: Andy Bierman [mailto:[email-masked]]
Sent: Saturday, July 18, 2015 9:55 PM
To: Linda Dunbar
Cc: [email-masked]; Susan Hares; [email-masked]
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Aug 2015 17:06:45 -0400

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:
> *From:*Andy Bierman [mailto:[email-masked]]
> *Sent:* Saturday, July 18, 2015 9:55 PM
> *To:* Linda Dunbar
> *Cc:* [email-masked]; Susan Hares; [email-masked]
> *Subject:* Re: [i2rs] multi-headed control of I2RS agent v.s.
> i2rs-Ephemeral-state
>
> Hi,
>
> [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
>
> 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.
>
> - 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.
>
> 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
>
>
> [email-masked] <mailto:[email-masked]>
> [email-masked]