On Tue, May 31, 2016 at 02:27:12PM -0400, Joel M. Halpern wrote:
If I understood you correctly Juergen, you are suggesting using your
document:
https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
as a basis for addressing the I2RS requirements.
No. All I am saying is that there are discussions underway basically
triggered by openconfig ideas and that we need to find a common
architectural model for the various datastores different groups like
to have. The I-D cited above is input to this discussion. The
discussion goes beyond I2RS concerns but still I2RS concerns should be
considered by this discussion.
I am having trouble understanding how the approach in your document would
work for ephemeral configured information.
1) The document says that such information is treated like other control
protocols.
1a) How would one use NetConf or RestConf to write this?
Via an ephemeral datastore. The difference is that this ephemeral
datastore primarily interacts with operational state. This actually
seems consistent since I2RS tends to favor to relate to state more
than to config.
1b) How would the controllable relationship with conventional configuration
be realized
The ephemeral datastore overwrite, right? So an implementation pulls
from the <applied> config datastore and the ephemeral datastore and
the (+) function gives content from the ephemeral datastore
preference.
1c) How would the descriptions of this information be provided? (Arguably,
this last is not a requirements question, but it would help in understanding
your proposal.
A YANG module. Perhaps I do not understand the question.
2) Similarly, since operations have been segregated by datastore, how would
an I2RS client read the configured information to tell what was being
applied?
Be careful with 'applied' since there now is an 'applied' datastore
with very specific meaning. But in general, a client that wants to
read one of the configuration datastores simply reads that datastore.
3) How would the I2RS requirement for priority of operation be applied?
It is the magic (+) function that merges <applied> config with
<ephemeral> config leading to operational state.
4) How would the requirement for reversion to configured values upon removal
of an I2RS modification be done?
The magic (+) function would have to take care of it.
It is very hard as a reader to tell if your approach is acceptable, better
than, or worse than, the one we have on the table.
I understand. The alternative model is to have <ephemeral> somewhere
between <applied> and <operational state>. But then it seems people
want <ephemeral> really behave more like other control plane protocols
that also typically interact directly with <operational state>.
As far as I can tell, in terms of a consistent architecture for data stores,
both approaches consist of creating extra data stores when needed.
Yes. But details matter. For example, <intended> and YANG
configuration datastore validation are one thing, I tend to believe
that I2RS validation really means something different. Hence I am
pointing out that we need the I2RS requirements but then we
(NETMOD/NETCONF people) also need to come up with an architectural
model that considers things that are beyond I2RS' scope.
/js
