On 07/12/2016 16:13, Juergen Schoenwaelder wrote:
On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote:
Alas, xpath filtering is optional, and I'm not sure how many devices have
implemented support for it. Further, this still requires every client to be
coded to avoid receiving the information that they are very unlikely to be
interested in.
I would much prefer a solution where the clients don't get this (mostly
noise) data unless they explicitly ask for it. Otherwise for an Ethernet
interface you might return 10 leaves of potentially useful opstate
information, along with 50+ leaves of quite low layer diagnostics
information that is likely to be of very little use except for to the select
few people that are actively involved in trying to diagnose hardware faults.
I expect that there will be many augmentations to lets say /interfaces
(or /interfaces-state). How does a data model writer determine which
ones are 'noise' and which ones are not? How does a a data model
writer determine which ones are costly to implement and which ones are
not (since this may vary widely between systems)?
It isn't so much as it being noise. I see that the two quite different
sets of config false nodes are:
(1) The first set of nodes are those that are useful to a client to
manage a device and to determine whether the device's actual behaviour
matches the expected behaviour based on the configuration. This is the
same set of data that has traditionally been modeled via SNMP, and I
think of as being the operational state of the device.
(2) If it is determined from the nodes above that a device is behaving
in an abnormal way, then the second set of nodes are aimed at device
developers/engineers to ascertain why the device is not behaving as
specified. A lot of this internal diagnostics information may only be
of use to a developer who is familiar with the code (or intricacies of
the hardware), and/or has a deep level of understanding of how a
particular feature works. I would see that most of this information is
very likely to be device specific, and presented in a device specific
way, and may include internal debug and dumps of internal data-structures.
I believe that most of the time, operators are only interested in
interacting with that first set of data because that is all that is
useful and required to manage their devices, and hence that is what I
think should be modeled in the operational state datastore. However, in
many cases, having a standard automated way of fetching that second set
of data is still useful, because it facilitates more efficient
diagnostic tools to be created in the future.
Specifically for Ethernet, 802.3 specifies a clear separation between
what they expect to be made available via a management protocol vs what
is regarded as being an internal API, specifically:
-802.3 Clause 30 specifies the main management objects, that I would
expect to be broadly accessible to management clients, and what we are
planning on basing the Ethernet YANG on. (This is consistent with what
is available in the Ethernet related MIBs and the OpenConfig Ethernet
model).
- the internal interface is defined as the MDIO registers in 802.3
Clause 45. Looking at these register definitions, although the
registers themselves can be given meaningful names, the values
themselves would probably just be returned as opaque 16 bit register
values, since the YANG "bits" type isn't flexible enough to represent
the packed values they sometimes contain (specifically where they are
using a set of bits to represent an enumerated value).
Perhaps it is useful to tell client writers that well behaving clients
should ask for what they need (and understand) and that they should
avoid asking generic 'give me everything you have' questions.
I really think that there are two separate classes of data here, and it
makes more sense to treat them as such.
Defining RPCs to fetch the internal diagnostics data on demand seems OK
to me, or alternatively marking the nodes as being diagnostics related
and putting that in a separate datastore would seem to be reasonable.
If you have to deal with lazy clients that like to grab everything,
you can control them via NACM. Simply exclude access to some branches.
This will likely just mean that every device would have to support this
NACM to handle the mainline case. That sounds like a lot of extra
unnecessary work for everyone.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
