Subject: Re: [ipfix] Option templates issues

From: Benoit Claise <[email-masked]>
Date: Mon, 22 Dec 2003 13:04:03 +0100

Mark,

[sorry for the delay, i've been absent from the list for a while]

I understand the concern but let me ask a few questions.
What if the metering process can't "meter" one of them? Ex: flows not 
exported due to resource starvation
What if we would like to export some extra data types? Ex: IPv6 packets 
and bytes dropped
So what if the METERSTAT struct is slightly modified?

Ganesh had a good point I think:
    If the group can come up with fixed structs that you mentioned below,
    then I think what you propose can be adopted.

Aren't we going to spend a long time to determine what MUST be exported 
in this/those structure(s)?
What you defined in your METERSTAT makes perfectly from a collector 
point of view but will not always be possible to collect on the exporter?
And it does perfectly sense now, but what about in 1 year? So would we 
have a new data type with a new slightly different structure?

I'm just wondering what we should say in the protocol draft:
    1. SHOULD export a METERSTAT data type(as described in your email)? 
What if one data type can't be exported, we don't send any metering 
stats "message"?
    2. MUST export a metering statistics Options Templates that SHOULD 
contain lost_flows, lost_flows_pkts, lost_flows_bytes, lost_pkts, 
lost_bytes, time.
    3. MUST export a metering statistics Options Templates that MUST 
contain X, Y, and SHOULD contain Z
    4. MUST export a metering statistics Options Templates that contain 
at least X, Y

Actually, I think the flexibility of the Options Template is benefitial 
for any data types.

Now, this is a different story for the Hello, Failover, etc... types of 
messages that you spoke about, as the goal is totally different!

Regards, Benoit.

>
> I'd like to propose an alternative mechanism for sending auxiliary 
> data such
> as time synch messages, protocol hellos (needed for fail-over), metering
> process loss statistics (ie packets/flows lost due to resource 
> starvation),
> etc.
>
> The existing framework allows "other" data to be sent in options 
> templates.
> Take for example a metering process stat message.  Lets say the metering
> process will periodically report statistics such as
>
>   struct METERSTAT {
>     u_int32_t lost_flows;       /* flows not exported due to resource 
> starvation */
>     u_int32_t lost_flows_pkts;  /* packets in the lost flows */
>     u_int32_t lost_flows_bytes; /* bytes in the lost flows */
>     u_int32_t lost_pkts;   /* packets dropped by metering process */
>     u_int32_t lost_bytes;  /* bytes dropped by metering process */
>     time_t    now;         /* when this record was generated */
>   };
>
>   The question becomes how to encode this with an options template.
>
>   Each field in the record could have a type (6 types), then the 
> options template
>   would list each of the 6 types.  The problem here is during 
> decoding.  What
>   will the collector do if only 5 of these items show up.  The packet 
> decode
>   process is also not very straightforward when just data is sent 
> (other option
>   fields could be in the same template) because it will have to figure 
> out
>   what to do based on the field type and there's no way to group fields. 

>
>   The other option is to call METERSTAT a type (of length 24).  Now the
>   decode process can key off of the type and all the fields will 
> always be
>   there because METERSTAT is fixed and defined in the protocol 
> document just
>   like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I 
> have here
>   is why are we bothering with a template/data model for this.  Why 
> not just
>   use traditional TLV's.
>
>   So what I'd like to see (I think) is to take one of the existing 
> reserved
>   flowset ID's, lets say 3 and use it for generic TLV data encodings.  
> Then
>   define structured data in the protocol such as METERSTAT.  IMHO this 
> allows us
>   to address a number of other issues including how to add HELLO's for 
> the
>   (optional) reliable failover, how to add aux flags like "this is 
> potentially
>   a duplicate PDU because I failed over", etc.
>
>   The TLV encodings would only be used for the low bit-rate protocol 
> messages,
>   NOT the high bandwidth flow data.  I'm also not proposing the option 
> templates
>   go away, just that we use a more traditional method for encoding the 
> non flow
>   data.
>
> 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/

--
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: "Meyer, Jeffrey D (http://usage.fc.hp.c)" <[email-masked]>
Date: Mon, 22 Dec 2003 08:17:26 -0800

Hi,

  Again, I'd point out, that as Benoit indicates, there are likely to 
be different things we want to send as "options".

  Rather than inventing an entirely new model, just make option a 
flag on the template and REUSE what we already have for data records.
It's that simple!

-- Jeff

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Benoit Claise
Sent: Monday, December 22, 2003 4:04 AM
To: Mark Fullmer
Cc: [email-masked]
Subject: Re: [ipfix] Option templates issues

Mark,

Regards, Benoit.