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