Re: [IPFIX] draft-muenz-ipfix-configuration-02

[Gerhard Muenz <[e-mail]>]

Hi Carsten,

Schmoll, Carsten wrote:
> I had a first look at the draft and have noted a few remarks
> and questions (see below, inline , after the beep).
>
> I think that the draft is a good idea and will check in
> more detail next week. So far the model seems consistent to me.

Thank you very much for your valuable feedback. I'm happy to see that
your comments refer to smaller issues only, i.e. the main concept
of the data model does not seem to be too bad :)

> I'm currently working in a project where we are planning
> an implementation to control monitoring probes of different
> types - and have done some UML modeling for that as well.
>
> Esp. the modeling of the sampling config is very similar to
> what you have proposed. Would be good if we can sync on that.

It would be very interesting to know more about your project, which
probes you use, how you configure them etc.
As a background information: The current configuration data model has
been conceived with two existing device implementations in mind, namely
Flexible Netflow and Vermont. This is because these are the two
implementations that Benoit and me know the best. So we tried to enable
an easy mapping between the device-independent configuration data model
and the current implementations.
Now, we would like to know if this model is also suitable for other
implementations, and what kind of changes are eventually needed to make
it more generic.

Below, I'll respond to some of your comments inline.

Regards,
Gerhard


>>  Abstract
>>  
>>     This document specifies a data model for the configuration of
>>     Metering Processes, Exporting Processes, and Collecting Processes for
>>     IPFIX and PSAMP compliant monitoring devices.  An implementation of
> 
> I suggest to change: implementation -> specification

Yes, maybe "specification" is a better term. Yet, in another, similar
context, the expression "implementation in XML" has been used as well:
"The Intrusion Detection Message Exchange Format (IDMEF)", RFC 4765

  "This document describes a data model to represent information
   exported by intrusion detection systems and explains the rationale
   for using this model.  An implementation of the data model in the
   Extensible Markup Language (XML) is presented, an XML Document Type
   Definition is developed, and examples are provided."

http://www.rfc-editor.org/rfc/rfc4765.txt

>>     the data model in Extensible Markup Language (XML) is defined using
>>     XML Schema language.
>>  
> -snip-
> 
>>  1.  Open Issues
>>  
>>     General issues:
>>     o  Find a consensus of common configuration parameters.
>>     o  Shall we recommend the usage of Netconf protocol, which provides
>>        mechanisms for communicating device capabilities, error messages
>>        etc.?
> 
> IMO it is good to recommend but not mandate a protocol. 
> The power of this draft is the independance from the used protocol.

I agree. Even without a protocol, the structure is useful. For example,
we use it for Vermont's configuration files, i.e. for local device
configuration.

However, it seems that manufacturers prefer Netconf for XML based
configuration, so the data model should work fine with Netconf.
At the IPFIX session in Chicago, some new initiatives in the direction
of standardizing guidelines for XML configuration data models have been
mentioned. I have not checked this yet. Has anybody else???

IMHO the data model has to fulfill our IPFIX/PSAMP-specific requirements
at the first place. Guidelines, if they exist, should be followed as
long as to do not prevent us from specifying suitable solutions for
IPFIX/PSAMP.

>>     Specific issues:
>>     o  Treat observationPointId, meteringProcessId, exportingProcessId,
>>        selectorId, selectionSequenceId (all unsigned32) of the IPFIX
>>        information model as configurable parameters or identifiers?
>>        *  Observation Points and Metering Processes do not have
>>           identifiers in the configuration data model, but
>>           observationPointId and meteringProcessId could be configuration
>>           parameters.
> 
> I think there needs to be an observation point identifier in the data model.
> If that can be signalled to an IPFIX exporter and used by it instead of a
> self-generated (albeit locally unique) obs. point id, it can be quite
> useful.
> Speaking in database terms this id would be a primary key for each such
> object.

Yes, a configurable observationPointId/meteringProcessId would
facilitate the management of configuration data.
On the other hand, devices would have to implement a table mapping
configurable Ids to physical/logical entities/resources.

>>        *  exportingProcessId could replace the identifier of the
>>           ExportingProcess class in the configuration data model.
>>        *  selectorId could become a configuration parameter of the
>>           selection methods specified within the SelectionProcess class.
>>           selectionSequenceId could be a configuration parameter of the
>>           SelectionProcess class or replace the identifier of the
>>           SelectionProcess class.  Yet, the configuration data model
>>           allows deploying the same Selection Process at different
>>           Observation Points, and in this case, the identifiers would
>>           always be the same.
>>     o  Which are the common SCTP specific export parameters?
>>  
>>  
>>  2.  Introduction
>>  
>>     IPFIX and PSAMP compliant monitoring devices (routers, switches,
>>     monitoring probes, mediators, collectors etc.) offer various
>>     configuration possibilities that allow adapting network monitoring to
>>     the goals and purposes of the application, e.g. accounting and
>>     charging, traffic analysis, performance monitoring, security
>>     monitoring etc.  The use of a common device-independent configuration
>>     data model for IPFIX and PSAMP compliant monitoring devices
>>     facilitates network management and configuration, especially if
>>     monitoring devices of different implementers and/or manufacturers are
>>     deployed simultaneously.  The purpose of this document is the
>>     specification of such a device-independent configuration data model
>>     that covers the commonly available configuration parameters of
>>     Metering Processes, Exporting Processes, and Collecting Processes.
>>  
>>     The specified data model is implemented in Extensible Markup Language
> 
> I'd say
> 	"The data model is specified in Extensible Markup Language"
> (but I wont push on that rephrasing :)
> 
>>     (XML) [W3C.REC-xml-20040204], which allows extending it easily with
>>     additional device-specific parameters.  Furthermore, optional
>>  
>>  
>>  
>>  Muenz & Claise   draft-muenz-ipfix-configuration-02.txt         [Page 3]
>>  
>>  Internet-Draft    IPFIX/PSAMP Configuration Data Model         June 2007
>>  
>>  
>>     parameters as well as parameters not supported by a particular
>>     monitoring device implementation can be simply omitted.  Any
>>     restrictions and extensions of the configuration data model should be
>>     known to the network management system in order to avoid sending
>>     unsupported configuration data to the monitoring device.  Note that
>>     the communication of monitoring device capabilities to the network
> 
> Question: is "device capabilities" synonymous with "extensions of the
> configuration data model"?

The capabilities could describe device-specific extensions of the
configuration data model, but this is not the main purpose.

In general, the device capabilities describe the available resources of
the device as well as the configuration possibilities. Examples:
- which interfaces/linecards can be used as Observation Points
- what kind of sampling methods are supported
Based on these capabilities, the usage of the configuration data model
has to be restricted. Protocols like Netconf provide a mechanism to
query capabilities from a device, which allows the management system to
adapt the configuration data accordingly.

>>     management system is currently out of scope of this document.
>>  
>>     There are various candidate protocols, like the Network Configuration
>>     Protocol (Netconf) [RFC4741] or the Simple Object Access Protocol
>>     (SOAP) [W3C.REC-soap12-part1-20070427], that are suitable for
>>     transferring XML data from a network management system to a
>>     monitoring device.  However, the configuration data model specified
>>     here is not specific to any of these.
>>  
> 
> Looking at the UML diagrams this could as well be used as 
> Entity-Relation diagrams as in modeling for a relational database!
> I suggest to say a few words stating that this information model is 
> also well suited to structure a *storage* for IPFIX config data.

We could mention this relationship. However, I do not think that we need
a standard that specifies how to storage the configuration data in a
database.

> -snip-
> 
>>  5.1.  ObservationPoint Class
>>  
>>     +---------------------+
>>     | ObservationPoint    |
>>     +---------------------+        1 +--------------------+
>>     | observationDomainId |<>--------| Interface/Linecard |
>>     |                     |          +--------------------+
>>     |                     |
>>     |                     |     0..* +--------------------+
>>     |                     |<>--------| MeteringProcess    |
>>     +---------------------+          +--------------------+
>>  
>>     +-----------------+   +------------------+
>>     | Interface       |   | Linecard         |
>>     +-----------------+   +------------------+
>>     | ifIndex         |   | entPhysicalIndex |
>>     | ifName          |   | entPhysicalName  |
>>     +-----------------+   +------------------+
>>  
>>                       Figure 3: ObservationPoint class
>>  
>>     The ObservationPoint class identifies an Observation Point of the
>>     monitoring device, i.e. an interface or a linecard.  The
>>     ObservationPoint class may specify the Observation Domain ID if the
>>     monitoring device implementation supports this configuration.
>>  
>>     The configuration parameters to identify an interface or a linecard
>>     are as follows:
>>  
>>     o  ifIndex, ifName: Index and name of the interface according to
>>        corresponding objects in the IF-MIB.  Only one of them must be
>>        specified to identify the interface. entPhysicalIndex,
>>        entPhysicalName: Index and name of the linecard according to the
>>        corresponding objects in the ENTITY-MIB.  Only one of them must
>>        specified to identify the linecard.
>>  
>>     The ObservationPoint class may specify one or multiple Metering
>>     Processes.
>>  
> 
> I am wondering whether a metering process should be linked to an interface.
> At the moment they are independent, i.e. there is now way to tell on what 
> interface a process is invoked. Not sure if this is desirable.

Let me explain the current reasoning behind it:

Existing implementations like Flexible Netflow and Vermont treat
Selection Processes (packet samplers/filters) and record caches (hash
tables) as separate and reusable entities (or instances).
This means (as an example): You can fill a cache with the output of two
different selection processes. And the output of a specific Selection
Process can go into multiple caches.

A Metering Process refers to a specific combination of Selection
Processes and a cache, but does not correspond to a reusable entity.
This is reflected in the current model: Selection Processes and caches
are regarded as instances (with identifies) that can be combined and
linked to an Observation Point with an embracing MeteringProcess-Tag.


-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  [phone]       Fax: [phone]
E-mail: [e-mail]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz


_______________________________________________
IPFIX mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipfix