On Thu, Dec 17, 2015 at 11:17:21PM +0000, Robert Wilton wrote: > Hi, > > For the Ethernet interface model that we are working on, the question > has come up on how best to model capabilities of a physical item of > hardware. > > In this particular case of Ethernet interfaces there are various > capabilities that we would like to model, but to give some concrete > examples: > - whether a particular Ethernet interface supports auto-negotiation > configuration > - what speed values may be configured on a particular interface > - whether the interface supports half duplex in addition to full duplex > - what modes of flow control are supported on the interface. > > All of these properties may change depending on what hardware is > currently inserted (e.g. this could be as coarse as a linecard or as > granular as a pluggable optics module). I.e. it is not the case that > the capabilities for all interfaces on a device would be the same, and > hence YANG features don't appear to help with this scenario. > > The current assumption is that we would model these dynamic capabilities > as operational state leaves. However, there is a general question as to > where these leaves should be placed. Should they be inline in the > interface config tree, or should there be a separate capabilities > container to hold them somewhere?
Inline in the config tree means that config must exist for the capabilities to be able to exist and I do not think this is the case here. Hence, this is operational state data that should exist in the state tree. > Further, in an ideal world it would be desirable to constrain the > allowed configuration values to those that are supported by the > capabilities, although writing such must statements on the config node > that reference state data is not allowed. The RFC 7223 model is that interface configuration is applied to matching interfaces and there is the possibility that this does not work out (e.g., interface types or interface properties do not match). Constraining the config by the (dynamic) interface properties would imply that configurations may become invalid spontaneously, which is something YANG does not allow. In other words, there can be a mismatch between 'intended config' and 'applied config' in such situations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
