Subject: Re: [ipfix-protocol] Re: Multiple identical Information Elements in a template -> proposed IPFIX text

From: Andrew Johnson <[email-masked]>
Date: Mon, 16 Jan 2006 16:55:21 +0000

Sven Anderson wrote:
> Hi Andrew,
> 
> Andrew Johnson schrieb:
> 
>> You are trying to solve the issue of building a flow record with element
>> captured from different observation points.  The problem with using the
>> same I.E.s for the same field but seen in different places is that you
>> can't tell which entry in the record applies to which field.  Even adding
>> an order dependence doesn't solve this issue because there is no
>> requirement to put all versions of the element in the record.  This is
>> detailed in your proposal but your solution is quite a complex addition
>> to the protocol.
> 
> 
> As long as an observation point can be an superset of other observation 
> points, as it is defined at the moment, all fields are amiguous, also if 
> you use the I.E. only once.
> 
>> This is the issue Benoit's proposal is an attempt to solve.  For example
>> a classification routines may classify a packet as classes 1, 10 and 15
>> similtaneously because these classes have independent properties.  In
>> this example order may not seem important, but if you want to match the
>> classes with some statistics about each class then making it order
>> dependent allows the order of each to be alligned.
> 
> 
> I agree in the case of you example. This is another situation, as these 
> special fields can have different values even in an atomic observation 
> point. But Benoits example of IPv4 in IPv4 is an case, where I would 
> say, it's an case of two observation points, before and after 
> unwrapping.

I disagree.  In the same way as we can report a TCP source port for a
packet which is passing through an observation point we can also have a
look at the inner IPv4 header.

> That's why I think it matches to my proposal. Don't get me 
> wrong, I support Benoits proposal, i just would go a little bit further. 
> If there are multiple I.E.s allowed, is it so much more complexity to 
> include an 0-length I.E. for separation? Maybe I don't have enough 
> experience to overview the implications.

How to deal with multiple elements of the same type is not clearly defined
in IPFIX and some contradictory proposals have arisen.  Benoit's proposal
clarifies the situation and provides a useful mechanism to deal with
certain problems, all without adding much complexity to the protocol.

Since IPFIX is almost complete, with several implementations in
development, it is a little late to add something of the complexity you
are suggesting.  Also, your suggestion seems a lot like a workaround for
a problem that was overlooked at the design stage of the protocol.

> As I'm quite new to the IETF-community: is this a typical situation, 
> where I should initiate an draft for an IPFIX extension? Or should I 
> just shut up? ;-)

I think you have identified a real problem, the question is how best to
solve it.  As a draft which shows how to solve this problem in IPFIX then
you are restricted by the IPFIX protocol.  At the moment there is no
restriction on what order you put elements into an IPFIX record and as
such I'm not sure your proposal works within the current IPFIX framework.

An alternative solution may be to send the flow information spread over
several flow records.  Each record would have a flowID (to link the
seperate records) and an observationPointID (to identify the origin of
the information in this record).

A completely different tack might be to examine how to send supplementary
information about each element, such as whether it is a key field, more
info on the Observation Domain, any supplementary configuration options,
etc.

Andrew

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