On Thu, Oct 31, 2013 at 06:05:57PM +0100, Benoit Claise wrote:
> During the OPSAWG/OPSAREA meeting, I will be addressing one issue
> that is now on the top of my mind: OPS guidance to the non-OPS
> community.
[...]
This topic seems to be coming up repeatedly. So either this is a real
problem to work on or it is something new ADs should be told about
because after getting into the job (which takes about two years I have
been told), they will raise this issue.
/js
PS: I am attaching my latest collection of ideas that was last
modified in November 2012 (!) and I think I did send it to
Benoit back then.
--
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/>
Guidelines for Developing Network Management Specifications
* Introduction
- WGs should consider operations and management aspects during the
development of protocol specifications. For such guidelines, see
RFC 5706.
- IAB recommandations documented in RFC 1052 lead to the development
of SNMP as the Internet network management protocol. This document
is meanwhile obsolete and only of historic value.
- Functional evolution of the SNMP framework failed (EOS working
group, SMIng working), new approaches came along (COPS-PR, SPPI),
resulting in an IAB workshop (documented in RFC 3535), which paved
the way to the creation of NETCONF.
- SYSLOG existed since the late 1980s but was not formally defined
as a standard protocol specification, leading to many variants,
making later attempts do document it challenging, see RFC 3164.
Its only since 2009 that there is a standards-track IETF
specification of SYSLOG [RFC5424].
- IPFIX [RFC5101], published in 2008, is a standards-track version
of NETFLOW, which dates back to the early 1990s, a proprietary
protocol for exporting network flow information.
- There are now several network management protocols that WGs can
use to address their network management needs. This document aims
at providing guidelines how to choose between the technologies.
* Relevant Network Management Technologies
** NETCONF/YANG
- NETCONF can transport and filter large amounts of data more
efficiently than SNMP
- NETCONF provides specific support to manipulate (persistent)
configuration datastores, including locking mechanisms to control
concurrency and rollback mechansims to run transactions across
a number of devices
- The NETCONF transports are all TCP based. Hence, NETCONF can
suffer from shaky network conditions, e.g., high degrees of packet
loss.
- The data modeling language YANG allows to model complex structured
data types much more easily than SMIv2, which is restricted to
flat tables
** SNMP/SMIv2
- SNMP is very low overhead for regular polling activities and
it provides a very lightweight event notification mechanism
- SNMP is particularly efficient if little information from many
devices is monitored
- SNMP uses a trap-directed polling approach. As such, regular
polling is assumed and notifications are essentially there to
reduce latency (i.e., no need to wait until the next polling cycle
and event notifications do not have to carry all details of the
event).
- The most widely deployed SNMP transports are UDP based and thus
allow SNMP managers to cope with shaky network conditions, e.g.,
high degrees of packet loss. (But note that it is implementation
dependent whether implementations do that.)
- There is a large collection of SNMP-based tools that collect and
integrate SNMP accessible data and do perform event correlation.
** SYSLOG
- SYSLOG traditionally does not use formally defined structured
data. Even though standards-track SYSLOG has support for
structured data, this does not seem to be widely used (yet).
- SYSLOG has a signature mechanism (RFC 5848), which can be very
useful to address legal requirements.
- Tools typically allow to filter SYSLOG messages (often by matching
messages against collections of regular expressions) and offer to
trigger reactions if a filter matches.
** IPFIX
- IPFIX was originally designed to export information about network
flows, often used for traffic engineering or accounting purposes
- IPFIX is template driven, which allows a rather compact encoding
of structured data that is sent frequently since the naming and
type information is carried in a template, separated from the data
itself
* Network Management Avtivities
** Configuration
- For configuration, NETCONF/YANG is the choice since there are no
direct competitors for configuration.
** Periodic Monitoring
** xxx Monitoring
** Logging
- SYSLOG has been widely used for logging, mainly due to its
flexibility. The SYSLOG signature mechanism makes it rather
attractive in situations where legal requirements require to
proof the origin and integrity of log messages.
- IPFIX has more recently been proposed as an alternative for
logging since it allows to bundle a number of similarly
structured log messages into a single IPFIX messages. However, at
this point in time, this is a proposal, it is not clear yet that
the larger community has concensus on this direction of evolution
of IPFIX.
** Alerting
- SYSLOG has been widely used for event notification; it does not
require a formal data model and thus is very flexible for device
implementors but as a consequence requires more work on the event
notification receiver side
- SNMP has been widely used for event notification; it relies on a
formal data model and thus is a bit easier to deal with on the
even notificaiton receiver side but less flexible for device
implementors
- It seems there are deployments that prefer to translate all event
notifications into SYSLOG format and there are deployments that
prefer to translate all event notifications to SNMP format
- NETCONF event notifications may make sense to provide event
notifications to configuration management applications but likely
will not compete any time soon with SNMP notifications and SYSLOG
messages
* Guidelines
WGs are not required to produce SMIv2 data models (MIB modules) nor
are they required to produce YANG data models (YANG modules).
However, they are encouraged to do so. Note that MIB modules can
even be read-only by providing appropriate compliance statements.
The decision whether SMIv2 or YANG is more appropriate must be taken
by the WG.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
