Subject: [ipfix-as] Feedback on the IPFIX-AS version 04

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Mar 2005 12:59:12 +0200

Dear all,

I reviewed the [IPFIX-AS] version 04. I sent a private email with minor 
editorial changes to the authors: no need to pollute the mailing list 
with this.

Here are the most important comments:
1. Sometimes you use flow records, sometimes records. I think you should 
be consistent and use data records, as defined in [IPFIX-PROTO]

2. Section 2.1.1 Example:
- Do you want to explain somewhere before that the Information Elements 
are taken out of the IPFIX-INFO. Otherwise people will have no clue what 
the value IP_SRC_ADDR = 0x0008 means below.
- How do you arrive to Length of 17 bytes?
- The example will have to be updated according to the latest version of 
IPFIX-INFO.
- IP Addresses compliant with RFC3330. [IPFIX-ARCH] and [IPFIX-PROTO] uses:

   198.18.0.0/15 - This block has been allocated for use in benchmark
   tests of network interconnect devices.  Its use is documented in
   [RFC2544].
- Why is it important to know that the DSCP will be 101110 00? Why don't you just put the integer value in there?

3. Section 2.8 "traffic monitoring"
   " This section describes how the monitoring of different metrics can 
be performed with IPFIX. All of the metrics require at least an 
extension of the IPFIX information model because the necessary 
information such as round-trip-time, packet Ids, etc., is currently not 
part of the information model. However given the   extensibility and 
flexibility of IPFIX the missing attributes can be easily defined."
I'm confused by this section:In section 2.7, you speak about SLA 
validation, and this section, you speak about metrics? The previous 
paragraph + the subsections should be part of 2.7!

4. Section 2.8.1 "Measurement of Round-trip-time (RTT)"
"In order to use this measurement technique, the IPFIX metering process 
needs to measure in both directions. "
Why? I don't have to measure anything on the destination for the RTT!

5. Section 2.8.2 "Measurement of One-way-delay (OWD)"
"The capability of using content information is out of scope of IPFIX 
but can be achieved by an optional extension"
What do you mean by"content information"? Do you mean payload?

"Nevertheless, in some scenarios it might even be sufficient to 
calculate a packet ID based on header fields (including datagram ID and 
maybe sequence numbers from transport protocols) without looking at 
parts of the packet content."
Again, do you mean "payload"?

"However, it is possible to extend IPFIX with a scheme to export 
per-packet information by providing special templates for that purpose.
Well, we don't need to extend anything to IPFIX, as per-packet 
information is just a special flow record composed of one packet. I 
think it should be stressed.

6. Do we want to have a new section 2.9 "others applications", 
expressing that IPFIX is a generic export mechanism, and that, as a 
consequence, IPFIX can be used for many more applications. The only 
condition is that the required information elements be specified in the 
IPFIX information model. As the Information Model is basically 
extensible with IANA, this is not a problem.

7.  section 3.1 IPFIX and AAA
"AAA defines a protocol and architecture for authentication, 
authorization and accounting for service usage"
Do we need a reference?

"The provisioning of accounting with IPFIX question: can be realized 
without an AAA infrastructure. The collector can directly forward the 
measurement information to an accounting application."
What does it mean "provisioning of accounting" Do you mean configuration?
collector = IPFIX collector?

Again, in this last paragraph, sometimes you use the "measurement 
information", sometimes "accounting records", sometimes "DIAMETER 
accounting records". And in the previous sections, you were using (data) 
records? This is confusing. BTW, this remark is valid throughout the 
document

8. section 3.2.3  Data Model Details 
"In IPFIX, fields such as ToPDUs and FromPDUs are stored in 64- bit 
counters. "
I've no idea what you are referring to? 

"Long-running flows may be broken into a sequence of shorter flows; in 
that case the flow counters are zeroed when the flow is exported."
This is not quite true anymore since we have both counters and absolute 
counters in [IPFIX-INFO]"
9. section 3.2.4 Application/Transport Protocol 
"The preferred protocol is SCTP (either reliable or partially reliable) 
or TCP"
UDP must be mentioned.

10 section 3.4 IPFIX and PSAMP
"The major difference between IPFIX and PSAMP protocols is that while 
the former exports flow records, the latter exports packet records."
This is not a difference in the protocols because the PSAMP protocol 
uses IPFIX.

I realized that you have references to PSAMP here. But you never had 
references to the IPFIX documents in the previous sections

11 section 4.0 limitations
"IPFIX works in ?push? mode that is data are automatically exported 
without waiting for a request. It is therefore a sub-optimal solution 
when the monitoring configuration needs to be  changed often. ?Pull? 
mode would be in that case more appropriate."
Can you please elaborate why? I don't get the point.
"In case of many exports, requiring many different templates, the 
Template IDs could not be enough"
We should express that Template IDs should not be generated for every 
combination of the information elements, but rather when a template is used.

12.  section 4.1 IPFIX and IPv6
    "There is no problem in reporting IPv6 data records with IPFIX, 
provided
    only that the transport protocol being used to carry IPFIX (SCTP
    is preferred) is running on the IPv6 network."
 
Well, there are 2 different ideas in here.
1.    Reporting the IPv6 data records. This is possible as we have the 
appropriate Information Elements
2.    Exporting on the top of IPv6. I don't think this is cover in the 
IPFIX protocol spec. Note that this problem is different that the first 
one because we might export IPv6 data records on the top of an IPv4 
transport.

13. Section 6 reference
We should also reference IPFIX-PROTO, IPFIX-ARCH, IPFIX-INFO

Thanks for your work on this draft.

Regards, Benoit.