Subject: [IPFIX] several problems on RFC 5470

From: "田红成" <[email-masked]>
Date: Fri, 27 Aug 2010 09:43:18 +0800

Dear Sir(Madam),

I would like to ask some questions about RFC 5470 .

(1)In Section 5.1.1, "For long-running Flows, the Metering Process should expire the Flow on a regular basis or based on some expiration policy." I don't know whether you can give several examples for some expiration policy at the side of the metering process. As such, In Section 5.1.2, "For long-lasting Flows, the Exporting Process should export the Flow Records on a regular basis or based on some export policy.", I am not sure whether you can give several examples for some expiration policy at the side of the exporting process if different from the expiration policy at the side of the metering process. .

(2)In Section 5.1.1, "When a long-running Flow is expired, its Flow Record may still be maintained by the Metering Process so that the Metering Process does not need to create a new Flow Record for further observed packets of the same Flow". I don't know whether the "flowStartMilliseconds" value, if exists, for this flow record may maintain unvaried or change depending on different updating policies of "flowStartMilliseconds" value when further observed packets of the same Flow arrive.

(3)In Section 5.7, the part of Figure 4 (Sampling and Filtering.bmp) is attacked below, I don't know why Sample Si and Filtering Fi need to repeat, It seems that sampling criterias may be all performed once and subsequent Filtering criterias may be all made once, too. 

(4)In Section 6.3, "The configuration in this case may be encoded as {ID, observation points (O1,O2), sampling algorithm, interval (1 in 100)}, where ID is the Observation Domain ID for the domain containing O1 and O2.". I am not sure which information element is defined for the configuration information.  

(5)I am not sure which information element is defined for Filters of the metering process.  

(6)I don't know whether the metering process and corresponding observation domain is of the one-one Map.

(7)I don't know whether the collectors and relevant links may form a physically isolated network from Intenet.

Thank for your attention!

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]

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 27 Aug 2010 11:01:04 +0200

Hello,

Thank you very much for your questions. This kind of feedback is very 
valuable as it shows how well non-IPFIXlers are able to understand what 
is written in the documents.

I'm not an author of this document. Nevertheless, I can try to answer 
your questions.

At first, some general remarks:

RFC 5470 is informational. It gives background information which shall 
help people to understand IPFIX. If you are looking for detailed 
specifications, you should read RFCs 5101, 5102, 5476, 5477.

If you are mainly interested in IPFIX Device architecture, it is worth 
looking at draft-ietf-ipfix-configuration-model-07 which clarifies 
certain issues.

> (1)In Section 5.1.1, "For long-running Flows, the Metering Process
> should expire the Flow on a regular basis or based on some expiration
> policy." I don't know whether you can give several examples for some
> expiration policy at the side of the metering process. As such, In
> Section 5.1.2, "For long-lasting Flows, the Exporting Process should
> export the Flow Records on a regular basis or based on some export
> policy.", I am not sure whether you can give several examples for
> some expiration policy at the side of the exporting process if
> different from the expiration policy at the side of the metering
> process.

Using active timeouts is the common way to expire long-running Flows.

For information about common Flow expiration policies, you may look at 
the Cache parameters in draft-ietf-ipfix-configuration-model-07:
> http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-07#section-4.3

Regarding the last paragraph of 5.1.2, I also do not understand why 
5.1.2 describes a special behavior for long-lasting Flow.

However, it generally makes sense to give the Exporting Process the 
freedom to delay the export of Flows according to some export policy.
Here are some use-cases:
- rate limiting
- fill up IPFIX Messages to avoid the export of many small messages

> (2)In Section 5.1.1, "When a long-running Flow is expired, its Flow
> Record may still be maintained by the Metering Process so that the
> Metering Process does not need to create a new Flow Record for
> further observed packets of the same Flow". I don't know whether the
> "flowStartMilliseconds" value, if exists, for this flow record may
> maintain unvaried or change depending on different updating policies
> of "flowStartMilliseconds" value when further observed packets of the
> same Flow arrive.

It is possible to either keep the original flow start timestamp or to 
create a new one. However, if you keep the timestamp, you also keep the 
counters!

The first behavior corresponds to Cache Mode "permanent", the second to 
Cache Modes "timeout" or "natural":
> http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-07#section-4.3

> (3)In Section 5.7, the part of Figure 4 (Sampling and Filtering.bmp)
> is attacked below, I don't know why Sample Si and Filtering Fi need
> to repeat, It seems that sampling criterias may be all performed once
> and subsequent Filtering criterias may be all made once, too.

Unfortunately, the loop-back arrow is not explained in the text (or I do 
not find it). I assume that it means that you can apply _different_ 
instances of sampling/filtering functions sequentially. However, you 
would never connect the output of one instance to the input of the same 
instance.

You should have a look at the PSAMP documents:
http://tools.ietf.org/wg/psamp/

> (4)In Section 6.3, "The configuration in this case may be encoded as
> {ID, observation points (O1,O2), sampling algorithm, interval (1 in
> 100)}, where ID is the Observation Domain ID for the domain
> containing O1 and O2.". I am not sure which information element is
> defined for the configuration information.

See RFC 5476.

> (5)I am not sure which information element is defined for Filters of

See RFCs 5476, 5477.

> (6)I don't know whether the metering process and corresponding
> observation domain is of the one-one Map.

No. You can have multiple Metering Processes for the same OD.

> (7)I don't know whether the collectors and relevant links may form a
> physically isolated network from Intenet.

You mean the link between Exporters and Collectors?
You may use an isolated network, but you do not have to.
See security considerations in RFC 5101:
http://tools.ietf.org/html/rfc5101#section-11

Regards,
Gerhard

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

---

From: "田红成" <[email-masked]>
Date: Tue, 31 Aug 2010 23:10:40 +0800

Dear Gerhard,
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.  
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.
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. 
4）I don't know whether lineCardId and portId can change when the linecard is re-initialized.
I am looking forward to hearing from you. Thank you very much!

best ragards
 ------
Hongcheng Tian

发件人： Gerhard Muenz 
发送时间： 2010-08-27  16:59:45 
收件人： 田红成 
抄送： IPFIX 
主题： Re: [IPFIX] several problems on RFC 5470 
 
Hello,
See RFC 5476.
See RFCs 5476, 5477.