Hi Vladimir,
Thanks for your suggestion. Please see some comments inline ...
On 06/12/2016 10:34, Vladimir Vassilev wrote:
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.
I'm not too keen on this approach. This would mean that an operator
would need to have NACM permissions to modify the configuration to be
allowed to retrieve read-only diagnostics information.
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.
This would sort of work, but then there is still some magic involved for
the client and device to have the knowledge not to return the
diagnostics information in a standard get request. I was thinking that
defining an extension to mark the leaves in the schema as being
diagnostics information might be the right way forward. However, I was
also thinking that just getting the basic (non diagnostics) operational
YANG specified would be a useful first step along the 802.3 Ethernet
model path.
In any case a grouping with the 802.3 Clause 45 information data will
definitely be usefull.
Given that there are a quite a lot of registers to define. It is quite
possible that defining YANG for all these registers would be deferred
until a future phase - do you see any issue with this?
Thanks,
Rob
/Vladimir
Input welcome. Thanks,
Rob
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
