On 12/05/2016 07:10 PM, Robert Wilton wrote:
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?
How about having this state data reside under a config=true presence
container e.g. /interfaces/interface/ethernet-detailed-state... . The
user can then create the container for the interfaces he is interested
in reading the detailed state data.
Or have dedicated RPC in the model that enables/disables the presence of
the detailed state information for certain interfaces. Since the state
container is not mandatory.
In any case a grouping with the 802.3 Clause 45 information data will
definitely be usefull.
/Vladimir
Input welcome. Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
