On Tue, Jan 10, 2017 at 10:18 AM, Robert Wilton <[email protected]> wrote:
> > > On 10/01/2017 17:25, Andy Bierman wrote: > > > > On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton <[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]> 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. > > > This is a real hack. I liked the if-feature approach much better e.g. leaf oper-speed { if-feature "not operational-datastore"; ... } > 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. > > It failed because there are no transactions, not because the oper-speed leaf exists or not. > > > 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. > > OK -- Joel informs me the I2RS charter is not constrained to RIB data at all. > > > 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)? > basic=report-all just means the server never suppresses defaults. It always returns them in <rpc-reply> messages. > > Rob > Andy > > > > >> >> Rob >> >> >> >>> /js >>> >>> >> > Andy > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
