Subject: [ipfix] better ways to describe the protocol

From: Nevil Brownlee <[email-masked]>
Date: Tue, 18 May 2004 12:56:08 +1200

Hi all:

Back about mid-February I got into a discussion with the protocol'
draft' editors about how we describe/explain the protocol, airing
the view that our current notation (flowsets, options templates, etc.)
seems unduly confusing to me.  Instead I proposed a file-like
description, which seemed simpler and easier to understand.

I'd like to open this idea up for wider discussion.  Here are copies
of two of my earlier note on this, how does this sound to you?

Cheers, Nevil

----- Forwarded message from [email-masked] -----
    Date: Tue, 17 Feb 2004 16:55:19 +1300

Hi Benoit, Stewart and Ganesh

I don't like 'Flowset' either.  It's OK for flow data records,
but seems very odd when it refers to template or option records.

I suggest that 'block' would be a better word.
That way we'd have blocks of template records, flow records, etc.

You already have a block structure defined -
each block starts with
    a template ID (your Flowset ID)
and a length (inclusive in bytes) of the block.

The template ID identifies which template defines the structure
for this block, so lets call it the template ID (rather than Flowset ID).

You have special values of template ID (0..255) used to overload
the field, i.e. they tell us that these are defining various kinds
of template - they're definition blocks rather than data blocks.

Of those, template
  0  defines a new template (your 'IETF exclusive' one)
        [how about just calling that a 'standard' template, 
        i.e. one which uses only information elements defined in
        the IPFIX INFO RFC?]

  2  defines a new template in which the element ids are qualified
        by explicitly specifying their Enterprise Number.
        [how about reserving Enterprise 0 for the IPFIX standard
        information elements, just to be complete?]

  1  defines a new options template, i.e. one which uses info
        elements from a set which describe the meter/exporter
        [these need to be defined in IPFIX INFO].

  3  defines a new options template, with enterprise IDs specified
        for each 'option' element.

I find the name 'options template' confusing.  They're really
information elements which describe the meter/exporter.

How about renaming them 'meter templates?'
That way we'd have
    Flow Templates - specifying Flow Records, using info elements defined
                       in terms of the flows

and Meter Templates - specifying Meter Records, using info elements
                       defined in terms of the meter/exporter.

To go with that, we'd have four kinds of blocks:
  Flow Template block
  Flow block
  Meter Template block
  Meter block

Now, re-reading the section on your options templates, I'm confused about
their Scope-related fields.  I understand why that's needed, i.e. to
specify which part of the meter a given subset of the options template
relates to.  If I understand it correctly, 

for each scope (1..X) we have a sub-block specifying the elements
we want reported for that scope.  Then

Option Length is the total length of all the (type,length) pairs
for a scope, and

Option Scope Length is the total length for all the scope sub-blocks.

Have I got that right?  If so, your example on page 50 doesn't
seem to be correct.  Or have I misunderstood?

Also, do we actually need an Option Scope field?  Given that we know
the total block length (from the Length field), we can walk along
the scope sub-blocks until we get to the end.
Or, if we do want something to make it easier to parse, how about
having the 'Option Scope Length' give the number of scope sub-blocks
which follow?

Again, looking at the example on page 50, it shows an options
data record with sub-blocks for each scope (as I thought from the
above discussion).  But the 'options data flowset' description
in section 8.5.3 says the order is 'values for each scope' for
each option in the list.  Which order is intended??

Sorry to send such a rambling posting, but I really find the
'options data' sections very confusing indeed.  I think it would
help if each of the defining sections began with a sentence or two
describing the record structure in terms of header and data,
as you do for the IPFIX message layout in section 7.

If you're happy with my 'blocks, headers and sub-blocks' approach
I could try writing an overview description for you ...

One more thing: I like your section 8.2, Field Type format.
Since you've specified it so clearly, how about referring to it in following
sections, e.g. "a template block is a block header followed by an
ordered list of Field Types" ?  As it is you don't actually use
Field Types anywhere, at least I didn't notice it.

Cheers, Nevil

----- End forwarded message -----

---- Forwarded message from [email-masked] -----
    Date: Thu, 19 Feb 2004 16:57:13 +1300

Hi Juergen et al:

I like your suggestions for simplifying the IPFIX protocol, i.e. we
finish up with something very simple, like this (using 'block' instead
of 'flowset' to describe it):

  IPFIX packet ::=  <header>  <block>+  # one or more blocks

  <block> ::= <data block> | <template block>

  <data block> ::= <template id> <data for flow>+

  <template block> ::= <flow template> |  <option template>
       # I suggest that 'meter' might be a better word than 'option' here

  <flow template> uses template id = 2, <option template> uses id = 3

  And I like the idea of just having the scope fields in all templates.
  Can you give us some detail on how the scope info would be encoded?
  And can we juggle all this so that NetFlow-v9 records will fit into

----- End forwarded message -----

I don;t know how you feel about BNF descriptions,  but I find the
above a lot clearer than the current text in the protocol draft.

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/