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
