Subject: Re: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion

From: "Susan Hares" <[email-masked]>
Date: Fri, 1 Apr 2016 16:40:46 -0400

Gert:

Thank you for your thoughts. 

Sue 

From: Gert Grammel [mailto:[email-masked]] 
Sent: Wednesday, March 30, 2016 1:30 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion

As a long time observer I also admit to be a bit at odds with respect to the term ephemeral. Defining ephemeral as the set of data that doesn't survive a reboot (i.e. Power cycle) looks a bit rough.

There seem to be 3 cases for state info after reboot:

1) the server is able to recover lost data by local means. This is usually referred to as persistent. (Agent not involved, data is the same as before reboot)

2) an i2rs agent needs to reprovision data after reboot (Agent involved, data is controlled by agent)

3) the server reconstructs data from external sources other than i2rs clients. (Agent not involved, data not controlled)

The term 'non-persistent' covers 2&3. 

The current draft text talks in section 1.2 about "ephemeral static state" which I interpret as 2) only. However it is not so clear why it is considered static. 

That would mean case 3) is ephemeral dynamic state, but that isn't defined yet and it could be as static as 2).

I admit having used the term "ephemeral" meaning case 2) only, which occasionally causes confusion. 

So yes, I am in favor of adding a definition to the architecture. At this point I am undecided if we need new terminology or if a  narrower definition would be sufficient.

Gert

Sent from my Apple ][

On 30 Mar 2016, at 10:02, "[email-masked]" <[email-masked]> wrote:

Hi,

I think it’s a good idea to give a definition in the beginning of the document. The i2rs definition matches also my definition which we are using to describe the fact, that a customer specific service “configuration” on a service node does not survive a reboot.

Just my 2 cents 

Nic

Von: i2rs [mailto:[email-masked]] Im Auftrag von Susan Hares
Gesendet: Donnerstag, 24. März 2016 18:02
An: [email-masked]
Cc: 'Joel Halpern Direct'; [email-masked]; 'Fred Baker (fred)'
Betreff: [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion

Hi all: 

<wg chair hat on> 

The draft-ietf-i2rs-architecture document has been approved as an RFC.  In the review, the OPS-DIR review indicated that “ephemeral” meant more than “does not survive a reboot”. They have asked the I2RS working group if replacing “ephemeral” with non-persistent (across power on/off or reboot cycles) would be a better choice.  

What do you think – leave at it at “ephemeral” or change to “non-persistent (across power on/off or reboot cycles) ? We will have a 1 week call on 

This would mean every place that “ephemeral” is listed, the authors would replace with “non-persistent”.  In the first instance, we will indicate “non-persistent (across power on/off or reboot cycles).

<wg chair hat off>  

As the author, I think we are better to define ephemeral at the beginning as “non-persistent (across power on /off or reboot).  Changing the definition at this point, I suspect will simply confuse people. 

Sue Hares

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Russ White" <[email-masked]>
Date: Thu, 31 Mar 2016 18:17:42 -0400

> The harm from persisting the data is in terms of robustness, not in terms
of
> interoperability.  With multiple interacting clients, and allowance for
lowered
> error checking, things can go wrong.

And in terms of what I2RS is setting out to do -- we're not trying to
configure the box in a general sense. We're trying to provide an interface
to the "routing system," which doesn't mean the entire router (which seems
to be a lost point in much of the ongoing shuffle). The "routing system"
generally means the control plane, which manages "ephemeral state" in its
normal mode of operation (I know there are exceptions, but building rules
based on exceptions is always a recipe for bad rules). 

Hence, the original concept was to stay away from anything that smells like
a configuration. 

> The fallback in the case of I2RS is that reboot will drop all the state,
so no
> persistent harm can be caused.

Right -- which means if you mess with the control plane in such a way as to
make the box unreachable, reboot it, and things rebuild to a known state.

:-)

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 1 Apr 2016 17:09:05 -0400

Linda:

Thank you for your questions.  Ephemeral in the I2RS context means (as Dean indicated) 

1)      Does not persist after a reboot, 

2)      Does not allow you to roll back to a previous ephemeral state (it is not saved), 

It is not the same as the word “volatile” in English or non-persistent.  This is why we have to define it in the I2RS architecture draft. 

Please note by default if the configuration changes after an I2RS ephemeral changes, the configuration changes wins.   

Sue 

From: Linda Dunbar [mailto:[email-masked]] 
Sent: Thursday, March 31, 2016 4:09 PM
To: Dean Bogdanovic; Susan Hares
Cc: Joel Halpern Direct; [email-masked]; BRUNGARD, DEBORAH A; Gunter Van De Velde; [email-masked]
Subject: RE: [OPS-DIR] [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion

Is “ephemeral” same as “volatile” (whose opposite state is ”non-volatile”)? 

Is “non- ephemeral”  same as “persistent”  or “ non-volatile”? 

Linda

From: OPS-DIR [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Friday, March 25, 2016 2:39 PM
To: Susan Hares
Cc: Joel Halpern Direct; [email-masked]; BRUNGARD, DEBORAH A; Gunter Van De Velde; [email-masked]
Subject: Re: [OPS-DIR] [i2rs] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion

Sue,

IMO, ephemeral has two meaning in i2rs architecture

1. it doesn’t survive reboot

2. you can’t roll back to a previous ephemeral state

Dean

On Mar 25, 2016, at 10:01 AM, Susan Hares <[email-masked]> wrote:

Deborah: 

Section 2 is exactly the place I would put the definition of ephemeral. 

Sue 

From: BRUNGARD, DEBORAH A [mailto:[email-masked]] 
Sent: Friday, March 25, 2016 9:50 AM
To: Susan Hares; 'Fred Baker (fred)'; 'Gunter Van De Velde'
Cc: [email-masked]; [email-masked]; 'Joel Halpern Direct'
Subject: RE: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion

Hi all,

As Alia is a co-author, I was assigned as the responsible AD for this document. The document is not with the RFC Editor – it’s been approved by the IESG with a revised ID needed to address comments raised by the IESG. And so the current discussion.

I had also raised the concern on needing more clarity on the definition of ephemeral during my AD review. The authors added some information. That clearly was not enough. As the term is used multiple times in the document and is the basis for another draft on requirements (draft-ietf-i2rs-ephemeral-state) which refers extensively to the architecture document, I agree the authors need to add more definition. Fred has a good suggestion – the term should be visible in a glossary section early in the document. It’s not currently included in Section 2’s Terminology – Sue, how about adding it to that section?

I think the authors know what is needed and thank everyone for the discussion and their time reviewing.

Thanks,

Deborah

From: i2rs [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, March 25, 2016 9:18 AM
To: 'Fred Baker (fred)' < <mailto:[email-masked]> [email-masked]>; 'Gunter Van De Velde' < <mailto:[email-masked]> [email-masked]>
Cc:  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; 'Joel Halpern Direct' < <mailto:[email-masked]> [email-masked]>
Subject: Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion

Fred: 

Thank you for the review, and your comments here.  I wished I’d asked about the word ephemeral earlier. 

Sue 

From: Fred Baker (fred) [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Thursday, March 24, 2016 2:59 PM
To: Gunter Van De Velde
Cc: Susan Hares;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Joel Halpern Direct
Subject: Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion

My comment was a review comment, that the word was being used in a way that wasn't consistent with its dictionary definition (something with a short lifetime, quite irrespective of birth/death processes) or common usage (at least in my context). At this point, the draft has been sent to the RFC Editor, so to my mind this discussion is mostly moot. If in your other drafts you are pointing people to a glossary in the architecture document (which I imagine you already are) and the architecture document defines the term as you are using it, you have probably done enough.

On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde < <mailto:[email-masked]> [email-masked]> wrote:

I am ok nowadays with using the terminology “Ephemeral”, although for a non-natve speaker it is non-trivial exotic word, particular if the intended usage doesn’t 100% reflect the Webster dictionary intended meaning.

It is only about a year ago i started reading up on i2rs and discovered this particular terminology, and at the time a google search on this terminology was not very conclusive and resulted to some confusion. 

I understand very well the confusion at play here from non-native english speaker perspective.

Adding text to explain the context in which the term Ephemeral is useful/advised. fwiw now that i am used to seeing ‘Ephemeral' as non-permanent config across reboot, i’m adapted its intended purpose… 

Is the goal to explain the intended meaning in each draft/rfc mentioning it?

Be well,

G/

On 24 Mar 2016, at 18:02, Susan Hares < <mailto:[email-masked]> [email-masked]> wrote:

Hi all: 

<wg chair hat on> 

<wg chair hat off>  

Sue Hares

_______________________________________________
OPS-DIR mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/ops-dir> https://www.ietf.org/mailman/listinfo/ops-dir

_______________________________________________
OPS-DIR mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/ops-dir> https://www.ietf.org/mailman/listinfo/ops-dir