Subject: RE: [IPFIX] draft-muenz-ipfix-configuration-02

From: "Schmoll, Carsten" <[email-masked]>
Date: Fri, 17 Aug 2007 12:46:21 +0200

Hello Gerhard, Benoit,

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.

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.

Best regards,
Carsten.

- BEEP -

>  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

>     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.

>     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.

>        *  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"?

>     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.

-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.

> -----Original Message-----
> From: Gerhard Muenz [mailto:[email-masked]] 
> Sent: Monday, July 02, 2007 11:30 PM
> To: [email-masked]
> Subject: [IPFIX] draft-muenz-ipfix-configuration-02
> 
> 
> Dear all,
> 
> A new version of the IPFIX Configuration draft has been published:
> 
> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configur
ation-02.txt
> 
> Comments and feedback are welcome.
> 
> Best regards,
> Gerhard
> 
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipfix
> 
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: "Schmoll, Carsten" <[email-masked]>
Date: Fri, 17 Aug 2007 12:46:21 +0200

Hello Gerhard, Benoit,

Best regards,
Carsten.

- BEEP -

-snip-

I'd say

-snip-

ation-02.txt

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 17 Aug 2007 17:06:16 +0200

Hi Carsten,

> 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 :)

> 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

> 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 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.

> Speaking in database terms this id would be a primary key for each such

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.

> 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.

> 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.

> 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:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 17 Aug 2007 17:06:16 +0200

Hi Carsten,

Regards,
Gerhard

---

From: Andreas Kind <[email-masked]>
Date: Fri, 31 Aug 2007 12:15:56 +0200

Gerhard, Benoit,

I looked at your draft and think that the data model is useful and makes 
sense. It seems to me not only suited to configure exporters which are 
similar to Flexible NetFlow (my initial fear ;-) but also for flow 
meters in general.

The example clarified that it is indeed possible to use multiple 
Observation Points per CacheParameters instance (ie, multiple interfaces 
feeding a single flow table) -- a standard scenario. I suggest to 
clarify this point already in Section 4 by adding these sentences to the 
SelectionProcess and CacheParameter items in the item list:

* "A Selection Process can be referred from multiple Metering Processes."
* "A specification of Cache Parameters can be referred from multiple 
Metering Processes."

Here some other comments:

* As it does not make sense to have an Observation Point without a 
Metering Process, I would label the aggregation in Figure 1 and 3 with 
'1..*'. The same might apply to Collection Process. Of course, this 
would also mean:

       <xsd:element name="MeteringProcess" type="meteringProcess_type"
           minOccurs="1" maxOccurs="unbounded" />

and

       <xsd:element name="MeteringProcess" type="reference_type"
           minOccurs="1" maxOccurs="unbounded" />

* Software-based flow meters quite often use file system based 
Observation Points and Exporters. For instance, people want to read from 
a capture file and export as IPFIX records. An other scenario is to 
listen on an interface (or multiple) and write to a file (eg, à la 
draft-boschi-ipfix-exporting-type). In the former case, something more 
general than Interface / Line Card is necessary which allows for 
specifying not only the file name but also the content format, such as 
tcpdump/pcap. Maybe URI syntax? In the latter case, the Destination 
class may actually be generic enough for file-based export.

* It would be useful to have description fields with instances which can 
be referred to. So, I'd suggest to have 'descr="..."' fields with 
ObservationPeriod, SelectionProcess, CacheParameters, etc.

* You use the unit 'Sec' but it is not an SI unit. Maybe you want to use 
's'.

* Finally something which might be out of scope: Is it possible to do 
incremental (re-)configuration to reduce the XML overhead in the traffic 
to the device to be configured?

Best regards -- Andreas

Gerhard Muenz wrote:
> http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-02.txt
>

---

From: Andreas Kind <[email-masked]>
Date: Fri, 31 Aug 2007 12:15:56 +0200

Gerhard, Benoit,

and

Best regards -- Andreas