We discussed saving and re-exposing lower priority operations when
higher priority ones were removed. The working group decided that was a
bad idea, as it has a tendency to produce unintended consequences.
Also, all direct over-writes among I2RS operations are considered
errors. They will need to produce notifications of these errors. And
then the higher priority one is applied as a means of producing
deterministic results, not because it is reliably right.
Also, if an I2RS client has read permission on I2RS data, it reads the
current value. No matter what priority the value was set using.
So I would be really unhappy with trying to model this as an overlay per
priority. It seems to produce even more complexity, more unexpected
results, and does not help us.
If I2RS data can be modeled as a single datastore with read-through to
the underlying operational state, and no possibility of performing a
commit then it can probably be made to work.
Yours,
Joel
On 5/26/15 11:22 PM, Kent Watsen wrote:
I likely won't be able to make tomorrow's interim meeting. Hopefully this
helps.
In the off-list discussion Jeff mentioned, it was stated that using
distinct datastores avoids architectural problems and special purpose
extensions. This is a perspective I'm coming to have as well.
Section 7.1 of draft-haas-i2rs-ephemeral-state-reqs-00 describes
disadvantages to having multiple datastores, namely issues around
instance-identifiers and must/when expressions. My opinion is that since
I2RS is defining a new concept, it can also define the necessary semantics
to enable what's needed. While it's true that normal datastores can't
reference each other, these are not normal datastores. To underscore
this, if I2RS selects RESTCONF, NETCONF's datastores are no longer
relevant. In fact, the term "datastore" may be tripping us up, perhaps we
call it an "overlay" ;)
So Section 7.2 of draft-haas-i2rs-ephemeral-state-reqs-00 describes
disadvantages to the overlay approach, namely complexity and consistency
issues. Neither of which I fully understand. The overlay approach was
discussed on list last September and again in October. It actually seemed
to have a lot of support, albeit some minor issues, but they don't seemed
nearly as bad as issues discussed in other proposals to date.
My proposal is to revisit the overlay approach again, defining the
necessary rules as needed. Taking a step into design, I propose not just
one overlay, but N overlays for N priorities as follows:
- each client has an assigned priority
- each overlay has an assigned priority
- clients can read lower priority overlays, but not higher priority
overlays
- each client writes into the overlay of matching priority (no
exceptions)
- the system calculates the effective configuration using this algorithm:
initialize accumulation buffer with NV-config
for priority from lowest to highest:
merge into accumulation buffer overlay[priority]
assert conceptual `validate` on accumulation buffer succeeds
Where the merge operation includes the following rules:
- merging a scalar value overwrites lower-priority values
- merging an ordered-by user list entry causes the entry goes to
The beginning of the list (this assumes an ordering semantic, a
YANG annotation may be needed to indicate directionality)
- it is not possible to simply delete a lower-priority value
And client interactions with an overlay includes the following rules:
- any update (including on NV config) that might cause the
conceptual `validate` on the accumulation buffer to fail has
the effect of necessary config to be first *copied* into the
higher-priority overlay.
The primary advantages to having multiple overlays are
- priority doesn't need to be stored per leaf
- issues around how lower priority client updates interact
with higher priority config disappear.
One problem with the approach of having multiple overlays (as oppose to
just one) is that it has the consequence of re-exposing a lower-priority
value when a higher-priority value is removed...unless we insist that
writing higher-priority value wipes out matching lower-priority value (not
including NV-config, of course). What's unnerving about re-exposing a
lower-priority ephemeral value is that one might argue why the system
didn't instead restore an ephemeral value from a client with the same
priority instead. I assume that two clients of equal priority would have
their own way of resolving it, or else I2RS disallows clients having equal
priorities...
Thanks,
Kent
On 5/26/15, 12:40 PM, "Jeffrey Haas" <[email protected]> wrote:
Working Group,
The following document is a straw-man document attempting to document
changes necessary to implement I2RS's ephemeral state needs.
This document has already gotten some discussion off-list with several of
the usual contributors to the netmod and netconf Working Groups as an
attempt to gain some early traction in the discussion. While that
discussion has been energetic, it hasn't achieved any further consensus
from
the contents posted herein.
I would like to request that further discussion related to this draft take
place on the mailing list.
This draft will be a topic for tomorrow's virtual interim. My apologies
for
not posting this more promptly.
-- Jeff
----- Forwarded message from [email protected] -----
Date: Tue, 26 May 2015 12:14:57 -0700
From: [email protected]
To: [email protected]
Subject: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : I2RS Ephemeral State Requirements
Author : Jeffrey Haas
Filename : draft-haas-i2rs-ephemeral-state-reqs-00.txt
Pages : 9
Date : 2015-05-26
Abstract:
This document covers requests to the netmod and netconf Working
Groups for functionality to support the ephemeral state requirements
to implement the I2RS architecture.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-haas-i2rs-ephemeral-state-reqs-00
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
----- End forwarded message -----
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
