On 10/01/2017 17:25, Andy Bierman wrote:
On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
On 10/01/2017 16:16, Juergen Schoenwaelder wrote:
On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote:
On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <
[email protected]
<mailto:[email protected]>> wrote:
On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman
wrote:
I think itt is not realistic to say that
datastores are optional.
e.g. <enabled> leaf: If there is a standard way
to enable/disable config
then individual "enabled" leafs are redundant.
However XPath (must/when)
has no way to describe if the subtree is enabled
(which is a
show-stopper)
I may not understand what you are saying. From what I
know, there are
implementations that allow to 'comment out' nodes and
subtrees and
that work with clients in a backwards compatible way.
<foo-config> vs <foo-oper>. If the applied or
operational datastore is
assumed,
then there is no need to model the redundant
config-as-operstate.
If this is left out of the model, then the
datastore becomes mandatory.
If it is left in the model, the datasore becomes
redundant.
The basic premise that these datastores are
optional is flawed.
One cannot design a YANG module assuming the
datastores are present
if they are in fact optional.
The claim that all datastores are mandatory is equally
flawed.
correct -- nobody is saying that.
Well, I originally commented on the statement that intened
would be
required and adding complexity - it does not.
The reason this is different is that the YANG objects are
impacted.
Candidate vs. running has no impact whatsoever on the set of
YANG modules. The protocol is not self-selecting some objects
and making other objects invisible.
Yes. And the same is true for intended as long as an
implementation
does not support templates or inactive configuration objects.
But if I want to model <foo-state>, I will soon have to decide
to use <foo-state> and allow all protocols to read it or
model get-state(foo) and require a different module for each
protocol.
If you do /foo and /foo-state, things will just work with or
without
an operational state datastore.
True, but there would also be an undesirable duplication of data
in the data tree.
If you have only /foo, then an
operational state datastore may come in handy if you have to
support
config and state with different lifetimes.
I think that this may be more than "come in handy". I think that
there would be key information that clients would expect to be
available in a model but wouldn't be easily retrievable without
supporting the operational state datastore. Specifically you lose
the ability to easily query an operational property of a system
that can be configured, but hasn't been configured.
Example: Consider an Ethernet interface speed leaf that in the
running ds represents the configured speed, and in the operational
state ds represents the actual operational speed in use.
Normally, the operational speed would default to the maximum speed
supported by the hardware (or the negotiated value if auto-neg is
in effect). If a device doesn't support the operational state
datastore then you wouldn't be able to query the operational speed
of an interface if it hasn't also been configured.
This is my concern -- that data modelers will put in the <oper-speed>
leaf to make sure
all protocols (including existing NETCONF) can retrieve the oper-value.
I think that there may be a better way here: The data modelers design
the model on the assumption that an operational state datastore will be
present. We can then use a pyang plugin to generate an extra YANG model
that contains the missing state leaves that would be required for the
split config/state trees. E.g. if it finds a config leaf in foo/speed
it creates a module that contains foo-state/speed. I've been playing
around with pyang and I don't think that this would be too hard to do.
For many decades, this has been the design approach.
There have not been many leafs where interactions with control-plane
protocols
is a factor. The SNMP-style solution is ad-hoc, but the problem is
somewhat rare,
so it didn't really matter.
Yes, OK. But I think that SNMP failed for programmatic configuration,
it only seemed to get traction returning operational state.
The premise now seems to be that the problem is no longer rare
and lots of <oper-speed> type of data is needed. I am not even sure
this will
be true if I2RS is constrained to RIB data (as the charter dictates).
I think that I2RS is orthogonal to what the operational state datastore
is really solving, it just happens to help for I2RS as well.
Presumably, the same instrumentation gets invoked for get(oper-speed)
as get-state(admin-speed)
Yes, in the general case, I think that using the same instrumentation
would be a valid implementation.
But you may also be able to optimize this to fetching the information
from the running configuration datastore (if you know for sure that the
value will be the same).
If the additional metadata is being supported and returned then it may
also need to compare the operational value with the configured value and
schema default to choose the correct metadata annotation.
If the device support the with-defaults extension and appropriate
options then they could presumably retrieve the "complex default"
value from the device using one of the with-default query parameters.
with-defaults is a bit different because the YANG module can provide
the default
even if the server won't.
I was thinking of the "report-all" option. Wouldn't that mean that the
server would have to return the actual value for a config leaf that had
a complex default value (i.e. based on the hardware present)?
Rob
Rob
/js
Andy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
