Subject: Re: [ipfix] drawing the line between protocol and data model document

From: Benoit Claise <[email-masked]>
Date: Tue, 03 Jun 2003 16:45:33 +0200

Mark,

>On Thu, May 01, 2003 at 10:51:49AM -0400, [email-masked] wrote:
>
><snip>
>
>  
>
>>The richness of the protocol encoding specification is another
>>matter. The protocol would reference each element in the data
>>model and define exaclty how that element is encoded. In the above 
>>example, the protocol is free to encode that as an unsigned byte 
>>if the value is < 256. 
>>    
>>
>
>The ramifications of doing this with a template based system are a bit
>ugly.  Consider a flow with just 2 counters -- octets, packets.
>Each could have a 1 to 8 byte encoding.  That's a potential of 64
>different templates for representing 1 type of flow.
>
>This (at first glance) looks like it adds considerable cycles to the
>encode / decode process to save a few bytes in the transport.
>
>The current v9 spec appears to allow this, but only for IN_BYTES and
>IN_PKTS.
>
>  
>
>>                                          counter with length
>>   IN_BYTES                 1       N     N x 8 bits for bytes
>>                                          associated with an IP Flow
>>    
>>
>
>Is this true?  Benoit?
>  
>
I'm trying to catch up with my IPIFX emails; I know I'm late on this 
thread, which seems to have reached consensus as far as I can tell, but 
as this is a direct question to me, let me answer.
Actually, there are:
BYTES            1             4             field type for the 32 bit 
bytes counter
BYTES_64      23           8             field type for the 64 bit bytes 
counter

So the draft that you refer to needs a quick update.

Regards, Benoit

>
>mark
>
>--
>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/
>  
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 Jun 2003 13:31:05 +0200

Dear all,

> thread, which seems to have reached consensus as far as I can tell, 
> but as this is a direct question to me, let me answer.
> Actually, there are:
> BYTES_64      23           8             field type for the 64 bit 
> bytes counter

Let me reply to my own email because, after speaking to different 
people, I have to correct what I said.
We actually do:

                                          Incoming counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow

                                          Incoming counter with length
   IN_PKTS		    2       N     N x 8 bits for packets
                                          associated with an IP Flow

And no BYTES_64 is defined.

Regards, Benoit.