Hi,
We are currently working on modelling 802.3 Ethernet YANG within the
802.3 YANG study group.
One interesting issue that has come up is the scope of the operational
state data that could be modeled:
At the top level, an operator may just want to know whether an Ethernet
interface is up or down.
At a second level, if the Ethernet interface is down, then there is some
high level diagnostics information that may be useful to an operator to
diagnose why the interface isn't up (e.g. alarms information, optical
power levels, auto-negotiation protocol status).
There is also a third level, of very detailed, 802.3 hardware register
information defined in 802.3 Clause 45. Such information is probably of
most relevance to the engineers developing and programming Ethernet
chips and PHYs, but is sometimes useful for resolving potential vendor
inter-operation issues. Retrieving this information out of the Ethernet
chips can be comparatively slow.
The question that was being discussed is whether it is appropriate to
model all three levels on information in the 802.3 Ethernet YANG models,
or whether only the top level and second level information can/should be
modeled via YANG?
If we were to model the third level information in YANG then it would
seem highly desirable for that information to not be returned in
response to a general NETCONF <get/> request because the information is
generally not of relevance and has potential performance issues in
returning it. Instead, it would seem desirable to only return this data
if it was specifically requested (e.g. a <get/> request on the node
containing the third level information), or if a hypothetical filter
extension was specified and used to explicitly include it in the
response. Given that there doesn't seem to a great way to currently
achieve this in YANG, this makes me think that it isn't sensible to
model this third level of detailed information in YANG at this time. Do
others agree?
Have others faced similar issues, and if so, how have you solved them?
Input welcome. Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
