Re: configuration: writable MIB modules versus NETCONF/YANG modules

Hi,

I agree we could provide some guidance on notification/logging mechanisms. 

Here's how I see things:

The Syslog community insisted on maintaining the freeform text fields when
the IETF developed a standardized message format. 
The Syslog WG developed the SDE format to provide more structured and
standardized data to supplement the freeform text.
There have been few SDEs standardized in the IETF, and they tend to be
singletons rather than cohesive data models.
Since humans are good at interpreting freeform text, but applications
typically have difficulty with freeform text, Syslog is good for uses where
a human will be looking at the messages. Sys-logs can be filtered by
priority and word-matching techniques to lessen the onerous task of finding
relevant messages in the stream, but it comes down to human review and
interpretation, typically at the device/endpoint level.

I don't work with ipfix, but had some experience with one of the candidate
protocols that led to ipfix. 
My impression of ipfix is that it is really better at three major things
than SNMP and Syslog:
1) capturing and reporting large quantities of potentially short-lived data,
such as the creation and deletion of IP flows or NAT bindings, and
2) offloading large amounts of data quickly and reliably, since it works
over streaming sessions, and
3) efficiency, since it uses templates rather than self-identifying varbinds
or full syslog messages, cutting message overhead.

SNMP provides standardized objects organized into data models using OIDs,
that can be hard for operators to understand, but easier for applications to
process. SNMP applications can correlate standardized data models across
multiple devices, can initiate a poll in response to a notification to get
more information, and can correlate notifications with polled information
(often including historic polled data). 
SNMP applications can also act upon its data analysis by automated
modification of configurations using RW objects, where supported. SNMP
notifications end up being useful for large-scale automated management, and
for network management applications rather than just device management
applications, because SNMP is not only notification/logging, but an
integrated package of notification/logging + polling + cohesive data models
consistent across vendors + (where available) automatable SET capability.


David Harrington
[email protected]
+1-603-828-1401
> -----Original Message-----
> From: OPS-AREA [mailto:[email protected]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Friday, February 14, 2014 3:46 AM
> To: Dave Thaler
> Cc: [email protected]
> Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
> NETCONF/YANG modules
> 
> On Fri, Feb 14, 2014 at 06:39:00AM +0000, Dave Thaler wrote:
> 
> > As a chair of WGs outside the OPS area, I'd still like to see
> > additional guidance around notification/logging mechanisms as well
> > (IPFIX vs Syslog vs SNMP traps/informs, etc.)
> 
> This is much harder. Here is how I see things:
> 
> IPFIX works well for large amounts of notification/logging data that
> has a common structure, i.e. you get things reported with a few IPFIX
> templates. SYSLOG works well with semi-structured data - traditionally
> there was very little common structure and the value was in the
> free-form text field. SNMP again works with structured data that is
> defined in data models (which is different from many IPFIX templates
> that IPFIX data processors are expected to discover at runtime,
> although I am aware of I-Ds trying to nail down IPFIX templates).
> 
> Both, SYSLOG and SNMP notifications have seen many years of wide
> spread deployment, IPFIX for notification/logging is more a new kid on
> the block. IPFIX may have nice performance characteristics but most
> management systems I have seen support SNMP notifications and/or
> SYSLOG messages to extract notification/logging data but not IPFIX. I
> believe what is widely deployed today (and feel free to prove me
> wrong) is largely SYSLOG and SNMP for notification/logging data.
> 
> What I am saying here is that the situation is less clear cut compared
> to SNMP for persistent configuration.
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area