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

["Susan Hares" <[e-mail]>]

Juergen and Robert:  

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

   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:[e-mail]] On Behalf Of Robert Wilton
Sent: Thursday, June 23, 2016 10:13 AM
To: [e-mail]
Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

Hi,

On 23/06/2016 13:02, Juergen Schoenwaelder wrote:
> 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).
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?


>
>     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.
I think that ephemeral state could also use configuration nodes as a
constraint, so it isn't just operational state covered by REQ-3.

>
> 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?
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


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

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