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?
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.
We can't be the first people to want to model dynamic capabilities, is
there a best practice on how they should be handled?
Any advice would be gratefully appreciated!
Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
