Subject: Re: [IPFIX] draft-ietf-ipfix-structured-data-02 feedback

From: "Gowri Dhandapani (gowri)" <[email-masked]>
Date: Wed, 29 Sep 2010 19:53:26 -0700

Hi Carsten,

Thank you for your comment, please see replies inline.

From: Schmoll, Carsten [mailto:[email-masked]] 
Sent: Monday, July 26, 2010 11:58 AM
To: Benoit Claise (bclaise); Gowri Dhandapani (gowri); Stan Yates
(syates); Paul Aitken (paitken)
Cc: Zseby, Tanja; [email-masked]
Subject: draft-ietf-ipfix-structured-data-02 feedback

Dear authors,

I had a look at draft-ietf-ipfix-structured-data-02 recently and I find
it in very good shape already.

Here my questions and comments in hope they are helpful.

1.)

You wrote with respect to packet observation:

"Ideally, the measurement at the second Observation Point should

start a little bit later than at the first Observation Point,

allowing the packets to arrive at the destination."

I believe this is a too stringent look at packet observation.  I would
expect that each packet tracking solution must be able to cope with
incomplete, and non-matching records. Consider just the case that
traffic runs both ways and already then there is no way to start the
measurements so that both observation points see exactly the same
packets. I would therefore remove that paragraph or replace it with one
that states that packet matchers must be quite flexible and cope with
non-ideal situations (however I believe that such text is not needed in
this draft)

This text has been removed.

2.)

"4.3.1. basicList
 
      A basicList specifies a generic Information Element with a
      basicList abstract data type as defined in Section 4.1.1
<http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-02#section-
4.1.1> . and list
      semantics as defined in Section 4.2.1
<http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-02#section-
4.2.1> .  For example, a list of
      port numbers, a list of interface indexes, etc.

"

When I then read 4.3.1 the first time and then 4.2.1 and 4.2.1  I got
the impression then 4.2.1 sort of extends 4.1.1 and that basicList may
also represent a list of elements conforming to an IPFIX template, i.e.
already cover the abstract type subTemplateList.  I don't know how I
would rewrite it, but would want to make sure that it cannot be
misinterpreted this way. (or is it just me?)

Even before Section 4.3.1, Section 4.1.1 states "The type "basicList"
represents a list of zero or more instances of any single Information
Element, primarily used for single-valued data types. Also, the
encoding is clarified in Section 4.5 as well. 

3.)

"A Collection Process decodes list elements from the BasicList

          Content until no further data remains.  A field count is not

          included but can be derived when the Information Element is

          decoded."

Question:

               Is there any case at all where a field count does exist
in the data records? I think not.

              The end of a (sub-)list of data will always be detected by
end of the (subelement-) byte stream as specified by the length field(s)
in the data records in bytes.

               Correct?

The field count is not included explicitly and yes, you are right -
decoding will be done until the length as specified in the length field.

4.)

"An Exporting Process MUST take care when encoding such data to not

      exceed the maximum allowed length of an IPFIX Message, 65535

      bytes, respecting the IPFIX specifications [RFC5101] that imposes:

      "The IPFIX Message Header 16-bit Length field limits the length of

      an IPFIX Message to 65535 octets, including the header".

"

Completely agree. Good you added this text. Maybe write one more
sentence to make clear that the 64k limit pertains to the "outermost"
size of each list and/or complex data structure. Hmm, what *if* my
complex data structures are bigger than that?  Can the joint use
together with commonPropertiesID be of help? If so, then I would add one
or two sentences on that.

Please refer to Section 9.1.1 for using Structured Data in
commonProperties.

5.

On a sidenote:

Does anyone see the general need for an IPFIX draft on "exporting big
blobs of data with IPFIX" ?

Then maybe, finally, I could send all my vacation photos via IPFIX to
the photo printing service  -  simply using netcat , if I had them
stored as IPFIX file, that is  ;-)

Iinteresting suggestion J

Thanks

Gowri

Best regards

Carsten

 

-- 

"With great power comes great responsibility!"  What power, you ask?
UNIX root privileges.

Carsten Schmoll

Dipl.-Ing.

Project Manager

Network Research

+49 (0) 30 3463-7136

Fraunhofer FOKUS

www.fokus.fraunhofer.de