Re: [OPSAWG] network management data models - a rewrite

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Nov 25, 2011 at 05:59:13PM +0100, Benoit Claise wrote:

> >  The second important infrastructure data model is defined in the
> >  Entity MIB [RFC4133]. It exports the containment hierarchy of the
> >  physical entities (slots, modules, ports) that make up a networking
> >  device and as such it is a key data model for inventory management.
> >  Physical entities can have pointers to other data models that
> >  provide more specific information about a physical entity (e.g.
> >  physical ports usually point to the related network interface).
> >  Entity MIB extensions exist for physical sensors such as temperature
> >  sensors embedded on line cards or sensors that report fan rotation
> >  speeds [RFC3433].
> BC> I would not mention this ENTITY-MIB extension about sensor. To
> the audience, it might seem that we have master the Internet of
> Things with SNMP, which is not correct at all!

You mentioned this earlier and this is why I wrote text that is more
specific: "physical sensors such as temperature sensors embedded on
line cards or sensors that report fan rotation speeds". If people
still misunderstand this because they are only used to scan for
keywords and then make up their own story I think we can't help.
 
> >Another extension models states and alarms of
> >  physical entities [RFC4268]. Some vendors have extended the basic
> >  Entity MIB with several proprietary data models.
> >
> >* Link Layer Data Models
> >
> >  A number of data models exist in the form of MIB modules covering
> >  the link layers IP runs over, such as ADSL [RFC4706], VDSL
> >  [RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515, RFC3606],
> >  Cable Modems [RFC4546] or Ethernet [RFC4188, RFC4318,
> >  RFC4363]. These so called transmission data models typically extend
> >  the generic network interfaces data model with interface type
> >  specific information. Most of the link layer data models focus on
> >  monitoring capabilities that can be used for performance and fault
> >  management functions and to some lesser extend for accounting and
> >  security management functions. The IEEE has meanwhile taken over the
> >  responsibility to maintain and further develop data models for the
> >  IEEE 802 family of protocols [RFC4663]. The cable modem industry
> >  consortium DOCSIS is working with the IETF to publish data models
> >  for cable modem networks as IETF standards-track specifications.
> >
> >* Network Layer Data Models
> >
> >  There are data models in the form of MIB modules covering IP/ICMP
> >  [RFC4293, RFC4292] network protocols and their extensions (e.g.,
> >  mobile IP), the core protocols of the Internet. In addition, there
> >  are data models covering popular unicast routing protocols (OSPF
> >  [RFC4750], ISIS [RFC4444], BGP-4 [RFC4273]) and multicast routing
> >  protocols (PIM [RFC5060]).
> >
> >  Detailed models also exist for performance measurements in the form
> >  of IP performance metrics [RFC2330]. IP performance metrics include
> >  the definition of measurement methodologies with the goal to produce
> >  repeatable and comparable measurement results. There is a growing
> >  number of metrics defined for measuring loss, delay, connectivity,
> >  etc.
> >
> >  The necessary data model infrastructure for configuration data
> >  models covering network layers are currently being defined using
> >  NETCONF and YANG.
> >
> >* Transport Layer Data Models
> >
> >  There are data models for the transport protocols TCP [RFC4022], UDP
> >  [RFC4113], and SCTP [RFC3873]. For TCP, a data model providing
> >  extended statistics is defined as well [RFC4898].
> >
> >* Application Layer Data Models
> >
> >  Some data models have been developed for specific application
> >  protocols (e.g., SIP [RFC4780]). In addition, there are data models
> >  that provide a generic infrastructure for instrumenting applications
> >  in order to obtain data useful primarily for performance management
> >  and fault management [RFC2287, RFC2564]. In general, however,
> >  generic application MIB modules have been less successful in gaining
> >  wide-spread deployment.
> >
> >* Network Management Infrastructure Data Models
> >
> >  A number of data models are concerned with the network management
> >  system itself. This includes, in addition to a set of SNMP MIB
> >  modules for monitoring and configuring SNMP itself [RFC3410], some
> >  MIB modules providing generic functions such as the calculation of
> >  expressions over MIB objects, generic functions for thresholding and
> >  event generation, event notification logging functions and data
> >  models to represent alarms [RFC2981, RFC2982, RFC3014, RFC3877]. In
> >  addition, there are data models that allow to execute basic
> >  reachability and path discovery tests [RFC4560].  Another collection
> >  of MIB modules provides remote monitoring functions, ranging from
> >  the data link layer up to the application layer. This is known as
> >  the RMON family of MIB modules [RFC3577].
> >
> >  The IPFIX protocol [RFC5101] is used to export information about
> >  network flows collected at so called observation points (typically a
> >  network interface). The information elements [RFC5102] carried in
> >  IPFIX cover the network and transport layer very well but also
> >  provides some link layer specific information elements. Work is
> >  underway to further extend the standardized information that can be
> >  carried in IPFIX.
> Let's add a reference to [IPFIX-IANA]. Note: [IPFIX-IANA] already
> exists as a reference in the draft.
> 
> Also add the following sentence "For example, the information
> element extension for packet sampling is
> specified in the the "information model for packet sampling reports"
> [RFC5477]

Fine.

> >  The SYSLOG protocol document [RFC5424] defines an initial set of
> >  Structured Data Elements (SDEs) that relate to content time quality,
> >  content origin, and meta-information about the message, such as
> >  language. Proprietary SDEs can be used to supplement the IETF-
> >  defined SDEs.
> >
> I guess that we should say a few words about RADIUS and Diameter
> TLV/AVP in this " Network Management Infrastructure Data Models "
> section.
> This way we would cover all entries (except CAPWAP) from "Table 5:
> Data Models and their Extensibility"

I am less familiar with their AVPs and how to summarize them. I agree
that they should be mentioned - would be great is someone can propose
text.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>