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

From: Linda Dunbar <[email-masked]>
Date: Sat, 18 Jul 2015 22:01:03 +0000

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

---

From: Andy Bierman <[email-masked]>
Date: Sat, 18 Jul 2015 19:55:07 -0700

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.

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]>
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.
>
>
>
> - 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
>
>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 19 Jul 2015 03:22:33 -0400

Thanks Andy.  I had missed that line in Linda's email.

I agree with Andy.  As I understand the WG agreements, ephemeral state 
has nothing to do with the presence or absence of a connection to the 
I2RS client which provided the state.  The ephemeral aspect is strictly 
about whether the state survives reboot of the device with the I2RS 
Agent (there is some ambiguity / flexibility about the case where the 
I2RS Agent reboots without the device itself rebooting, which we should 
be clear about.)

While the document title may be narrower than its scope (often the case 
with IETF documents) it is important that we get protocol mechanisms 
which deal with the priority as well as the ephemeral aspects.  I see no 
benefit in having two separate documents to discuss them.

Yours,
Joel

On 7/18/15 10:55 PM, Andy Bierman wrote:
> On Sat, Jul 18, 2015 at 3:01 PM, Linda Dunbar <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     __ __
>
>     Sue and Jeff, ____
>
>     __ __
>
>     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”.____
>
>     __ __
>
>     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____
>
>     __ __
>
>
>     [email-masked] <mailto:[email-masked]>