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

From: Gerhard Muenz <[email-masked]>
Date: Tue, 04 Sep 2007 14:51:49 +0200

Andreas,

thank you very much for your feedback.
Please find my replies inline.

Andreas Kind wrote:
> 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."

We will adopt this clarification in the next version of the draft.

> 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" />

A Collecting Process is mostly used to store the received data in files
or in a database or to pass it to an analyzer. We would like to
configure such Collecting Processes without any linkage to a Metering
Process as well.
On the other hand, a CP->MP combination is a very special case
(mediator, concentrator). So, in the case of the Collecting Process, the
0..*/minOccurs="0" should stay.

There is a practical issue as well: The 0..* and minOccurs="0" enables
step-by-step configuration and reconfiguration and ensures that
intermediate configurations are not invalid.
Assume that you have a running OP->MP->EP configuration and then you
want to remove the link between OP and MP without losing the the OP
parameters/configuration. Then, at some later time, you can provide a
new linkage between the OP and a new MP, for example, which requires
only a small change.

All in all, I'm not sure if we should restrict the minimum number of
Metering Processes per Observation Point in the configuration data model
to 1.

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

In the case of ObservationPoint, would you agree with a third option in
addition to "Interface" and "Linecard"?
Like "File" or "Repository"?
In the same way, Exporter could support "File" as a fourth option
besides "Sctp", "Tcp" and "Udp".

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

Good idea.

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

Agreed.

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

It's XML, so you can do XML processing with the configuration data, e.g.
using XPath to identify specific nodes or positions where you want to
manipulate the data.

Netconf Protocol provides mechanisms to edit parts of an existing
configuration as well. If people say that they want do IPFIX
configuration using Netconf, then we will add some notes about how the
configuration data model should be used with Netconf protocol.

Best regards,
Gerhard

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

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

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 04 Sep 2007 14:51:49 +0200

Andreas,

Good idea.

Agreed.

Best regards,
Gerhard