Subject: Re: [IPFIX] several problems on RFC 5470

From: Gerhard Muenz <[email-masked]>
Date: Sun, 05 Sep 2010 22:06:44 +0200

Dear Hongchen,

> I have several questions about IPFIX, I am so sorry to bother you
> again.

> 1) According to IPFIX, I may define a flow through such flow keys,
> "source IP address, destination IP address, protocol number, source
> port, destination port". Simultaneously, I may use
> "flowStartMilliseconds, flowEndMilliseconds" as other flow
> properties. The metering process may use this configure to
> choose/filter/aggregate TCP/UDP packets passing through corresponding
> observation point. But For ICMP packets, I don't know whether the
> same metering process may maintain flow records of the same structure
> as TCP/UDP flow record. For example, protocol number is ICMP protocol
> number, source port is the ICMP [type field + code field],
> destination port is null or zero. If it is feasible, another metering
> process isn't needed to run specially for ICMP packets.

There is no simple answer.

IPFIX does not specify that a single Metering Process must be able to 
generate ICMP Flow Records without port number fields and TCP Flow 
Records with port number fields at the same time. So, this is 
implementation-specific.

IPFIX does not disallow the export of an ICMP Flow Record which contains 
a port number field. However, I would prefer not to have any port number 
fields.

In the IPFIX configuration data model, we are more explicit about the 
behavior of the Metering Process in the Cache Layout section:

http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-07#section-4.3.1

> 2) I am not sure whether the sample/filter Criterias, expiration
> policy for metering process and  exporting policy for exporting
> process must be configured through out-band mechanism.

If "out-band" means that IPFIX cannot be used to configure IPFIX 
Devices, then the answer is yes.

The document which covers the configuration of IPFIX Devices is the 
IPFIX configuration data model draft. It suggests the usage of NETCONF.

> 3)I don't know why such three Information Elements,
> sourceTransportPort, udpSourcePort, tcpSourcePort, can co-exist.
> Seemingly, sourceTransportPort may replace udpSourcePort,
> tcpSourcePort. I don't know why sctpSourcePort doesn't exist.

udpSourcePort implies that the transport protocol is UDP. So, you do not 
need to export the protocolIdentifier.

Up to now, nobody has requested an Information Element for 
sctpSourcePort. It can be added if necessary.

> 4) I don't know whether lineCardId and portId can change when the
> linecard is re-initialized.

I do not know. The description does not say anything about persistence. 
So, I would say that the behavior is unspecified.

Gerhard

---

From: "田红成" <[email-masked]>
Date: Mon, 6 Sep 2010 11:03:11 +0800

Dear Gerhard,
Thank you for your detailed answer, I have further consideration about the 1st question, marked with [discussion] below.

best ragards
 ------
Hongcheng Tian
Network Architecture Lab, Network Center,Tsinghua University
Mobile:   +86 13370195827
Add:       Room 1227B, Zijing Building 15, Tsinghua University, 100084 Beijing, China
Email:    [email-masked]

发件人： Gerhard Muenz 
发送时间： 2010-09-06  04:05:14 
收件人： 田红成 
抄送： IPFIX 
主题： Re: [IPFIX] several problems on RFC 5470 
Dear Hongchen,

[discussion]: For the same observation domain, I don't know whether one metering process is to meter UDP/TCP/SCTP flow which contains  
source port and destination port fields , and another metering process is to meter ICMP flow which doesn't contain any port field. And in such situation, I am not sure whether the overload on the router will double and the capturing rate will be significantly negatively influenced.
I don't know whether, by default, one metering process maintians only one type of flow record structure in IPFIX.