Subject: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Jun 2016 14:02:51 +0200

Hi,

here are few comments on the latest version.

   Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
   operational state (e.g.  MPLS LSP-ID or a BGP IN-RIB) as a
   constraints.

I am not sure what 'must be able to utilized temporary operational
state as constraints' means. The text in the parenthesis does not help
me understand this better. Did you want to say something like:
'Ephemeral configuration state may have constraints that refer to
operational state'? I am using 'ephemeral configuration state' since
this is used in other places (although sometimes worded slightly
different).

   Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
   for purposes of implementing constraints.

Hm, now I wonder whether this is just a special case of
Ephemeral-REQ-03 and if so it is not clear why we need this as a
separate requirement. If this is not the case but something different,
then likely my interpretation of Ephemeral-REQ-03 is wrong.

s/2RS/I2RS in Ephemeral-REQ-05. I would actually rewrite the beginning
of Ephemeral-REQ-05 as follows:

   Ephemeral-REQ-05: I2RS interactions may
   lead to undesirable or unsustainable resource consumption on a system
   implementing an I2RS Agent.  It is RECOMMENDED that mechanisms be
   made available to permit prioritization of I2RS interactions, when
   appropriate, to permit implementations to shed work load when
   operating under constrained resources.  An example of such a work
   shedding mechanism is rate-limiting.

I would remove the Note: since I believe the key observation here are
the potentially high volume of I2RS interactions and not the fact that
there is a datastore involved that is ephemeral.

I am still struggling with Ephemeral-REQ-06:

   Ephemeral-REQ-06: The ability to augment an object with appropriate
   YANG structures that have the property of being ephemeral.  An object
   defined as any one of the following: yang module, submodule or
   components of submodule, or schema node.

Perhaps this is what you wanted to say?

   Ephemeral-REQ-06: The ability to augment YANG schema nodes with
   additional YANG schema nodes that have the property of being
   ephemeral.

I wonder why there are some ephemeral state requirements in sections
labeled with "I2RS Protocol version 1" while others seem to be
protocol version agnostic. What is the definition of I2RS protocol
versions?  Perhaps this notion of protocol version should simply be
removed; I am not sure it helps with the requirements.

   Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model
   that nodes have the following properties: ephemeral, writable/not-
   writable, and status/configuration.

This is confusing because it says 'nodes' while in YANG we distinguish
data nodes and schema nodes. For example, in YANG a schema node has a
property config true|false. This schema node property defines whether
corresponding data nodes are writable/non-writable. In other words,
some of this requirement seems to be covered by YANG already; so what
remains is the 'ephemeral' property - does the requirement expect this
to be a property of a schema node?

Editorial: s/prevent was the oscillation/prevent oscillation/

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 23 Jun 2016 15:12:50 +0100

Hi,

> this is used in other places (although sometimes worded slightly
I asked a similar question in the I2RS  interim meeting yesterday, I 
think that Sue's spoken explanation of the requirement was effectively:

    Ephemeral-REQ-03: Ephemeral state may have constraints that refer
    to operational state, this includes potentially fast changing or
    short lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB.

Perhaps this wording is more clear?

> then likely my interpretation of Ephemeral-REQ-03 is wrong.
I think that ephemeral state could also use configuration nodes as a 
constraint, so it isn't just operational state covered by REQ-3.

> to be a property of a schema node?
This also came up in the meeting yesterday.  My understanding is that 
there is a desire to be able to mark ephemeral operational state nodes 
in the YANG schema as writable.  One example given was to be able to 
have a single topology table that is predominantly learned from OSPF and 
ISIS but also have some static client entries added as well.

Personally, I would prefer that all operational state is read only, and 
to restrict writable nodes to configuration only.

Hence, this leads me to wonder whether the actual desire here is really 
to be able to have tables of ephemeral state (i.e. YANG lists) that 
consist of both ephemeral configuration and ephemeral state entries.

Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Jun 2016 17:41:38 +0200

On Thu, Jun 23, 2016 at 03:12:50PM +0100, Robert Wilton wrote:
> I asked a similar question in the I2RS  interim meeting yesterday, I think
> that Sue's spoken explanation of the requirement was effectively:
> 

Yes, this is clearer. One question of course is what is expected to
happen if constraints are becoming false due to (fast) operational
state changes, that is, what the expected consequence of this is.

> constraint, so it isn't just operational state covered by REQ-3.

Well, the Ephemeral-REQ-04 text says 'non-ephemeral state' - if your
interpretation is correct than this phrase is wrong or possibly
misleading.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Jun 2016 11:41:27 -0400

Juergen: 

Answers are listed below.  After you confirm Ephemeral-REQ-03,
Ephemeral-REQ-06, and Ephemeral-REQ-08, I will release a version-11. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, June 23, 2016 8:03 AM
To: [email-masked]
Subject: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

> I am not sure what 'must be able to utilized temporary operational state
as constraints' means. The text in the parenthesis does not help me
> 'Ephemeral configuration state may have constraints that refer to
operational state'? I am using 'ephemeral configuration state' since this is
used in other places (although sometimes worded slightly different).

Sue:  Ephemeral state is defined as "ephemeral configuration state" and
operational state.  Would this text be acceptable: 

Ephemeral State Requirements
In requirements Ephemeral-REQ-01 to Ephemeral-05, Ephemeral state 
is defined as potentially including both ephemeral configured state and
operational state.	

Ephemeral-REQ-03: Ephemeral state must be able to utilize operational state 
(e.g. MPLS LSP-ID or BGP In-RIB) as a constraint.      

> Ephemeral-REQ-03 and if so it is not clear why we need this as a separate
requirement. If this is not the case but something different, then likely my
interpretation of Ephemeral-REQ-03 is wrong.

Juergen: Ephemeral state was defined by the I2RS group as both ephemeral
configuration state and operational state in ephemeral portions of
datastore. 

>s/2RS/I2RS in Ephemeral-REQ-05. I would actually rewrite the beginning of
Ephemeral-REQ-05 as follows:

Sue: I will change /2RS/I2RS. 

 > shedding mechanism is rate-limiting.

Sue: The text that specifies  
"I2RS pub-sub, logging, RPC or other mechanisms may lead to undesirable 
   or unsustainable resource consumption on a system implementing an I2RS
Agent.:" 

provides useful information to the I2RS implementers.  Unless this really
causes problems, 
it would be useful to leave it.  I believe it says the same thing. 

>I would remove the Note: since I believe the key observation here are the
potentially high volume of I2RS interactions and not the fact that there is
a datastore involved that is ephemeral.

Sue: I can remove the note. 

   > additional YANG schema nodes that have the property of being

Sue:  If this text allows: 
1) yang modules that are all ephemeral, 
2) yang submodules that are all ephemeral, 
3) portions of submodules that are ephemeral,  and 
4) schema nodes that are ephemeral

Then I'll change it.  Please confirm. 

>I wonder why there are some ephemeral state requirements in sections
labeled with "I2RS Protocol version 1" while others seem to be protocol
version agnostic. What is the definition of I2RS protocol versions?  Perhaps
this notion of protocol version should simply be >removed; I am not sure it
helps with the requirements.

Sue: I will remove it.  However, the I2RS knows that it will add additional
features in a second revision.  However, that is probably self-evident if we
come up with a "bis" document. 

>This is confusing because it says 'nodes' while in YANG we distinguish data
nodes and schema nodes. For example, in YANG a schema node has a property
config true|false. This schema node property defines whether corresponding
data nodes are writable/non->writable. In other words, some of this
requirement seems to be covered by YANG already; so what remains is the
'ephemeral' property - does the requirement expect this to be a property of
a schema node?

We will change nodes to a "schema node". 

- changed 

/js

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Jun 2016 11:47:24 -0400

Juergen and Robert: 

I will use the following for Ephemeral-REQ-03.  

On Ephemeral-REQ-04, 

>for purposes of implementing constraints.

Non-ephemeral state is both configuration state (config true), and
operational state (config false). 

I believe these are two different requirements. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, June 23, 2016 11:42 AM
To: Robert Wilton
Cc: [email-masked]
Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

On Thu, Jun 23, 2016 at 03:12:50PM +0100, Robert Wilton wrote:
> > state as constraints' means. The text in the parenthesis does not 
> > help me understand this better. Did you want to say something like:

Yes, this is clearer. One question of course is what is expected to happen
if constraints are becoming false due to (fast) operational state changes,
that is, what the expected consequence of this is.

> > separate requirement. If this is not the case but something 
> > different, then likely my interpretation of Ephemeral-REQ-03 is wrong.

Well, the Ephemeral-REQ-04 text says 'non-ephemeral state' - if your
interpretation is correct than this phrase is wrong or possibly misleading.

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 23 Jun 2016 16:59:34 +0100

Hi,

>   operational state (e.g.  MPLS LSP-ID or a BGP IN-RIB) as a
That is the original text.  Am I correct in assuming that you meant this 
text instead?:

If so, this proposed text is OK with me.

> I believe these are two different requirements.
Yes.  Given that REQ-03 covers using operational state as a constraint, 
then would it be sufficient to word REQ-04 as:

Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral configuration
for purposes of implementing constraints.

Or perhaps to relate it more closely to REQ-03, as:

Ephemeral-REQ-03: Ephemeral state must be able to utilize non-ephemeral
configuration as a constraint.

Or is this missing something out?

Thanks,
Rob

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Jun 2016 12:17:54 -0400

Robert: 

I'm ok with the proposed change to Ephemeral-REQ-04. 

I will await Juergen's comment on Ephemeral-REQ-08, and then publish version
-11. 

Sue 
-----Original Message-----
From: Robert Wilton [mailto:[email-masked]] 
Sent: Thursday, June 23, 2016 12:00 PM
To: Susan Hares; 'Juergen Schoenwaelder'
Cc: [email-masked]
Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

Hi,

> I believe these are two different requirements.
Yes.  Given that REQ-03 covers using operational state as a constraint, then
would it be sufficient to word REQ-04 as:

Thanks,
Rob

misleading.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Jun 2016 12:19:05 -0400

Juergen and Robert:  

   Ephemeral-REQ-03: Ephemeral state may have constraints that refer
    to operational state, this includes potentially fast changing or
    short lived operational state nodes, such as MPLS LSP-ID or a BGP
IN-RIB.

Sue  

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Thursday, June 23, 2016 10:13 AM
To: [email-masked]
Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

Hi,

    Ephemeral-REQ-03: Ephemeral state may have constraints that refer
    to operational state, this includes potentially fast changing or
    short lived operational state nodes, such as MPLS LSP-ID or a BGP
IN-RIB.

> to be a property of a schema node?
This also came up in the meeting yesterday.  My understanding is that there
is a desire to be able to mark ephemeral operational state nodes in the YANG
schema as writable.  One example given was to be able to have a single
topology table that is predominantly learned from OSPF and ISIS but also
have some static client entries added as well.

Personally, I would prefer that all operational state is read only, and to
restrict writable nodes to configuration only.

Hence, this leads me to wonder whether the actual desire here is really to
be able to have tables of ephemeral state (i.e. YANG lists) that consist of
both ephemeral configuration and ephemeral state entries.

Rob

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Jun 2016 12:19:57 -0400

Robert: 

I changed Ephemeral-REQ-03 to: 

Is this OK? 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Thursday, June 23, 2016 12:00 PM
To: Susan Hares; 'Juergen Schoenwaelder'
Cc: [email-masked]
Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

Hi,

Thanks,
Rob

misleading.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 23 Jun 2016 17:40:29 +0100

Yes.

Thanks,
Rob

On 23/06/2016 17:19, Susan Hares wrote:
> .