Subject: Re: combined Option Template Set and Template Set? (was Re: [ipfix-protocol] draft-ietf-ipfix-protocol-09.txt available)

From: Sebastian Zander <[email-masked]>
Date: Tue, 05 Apr 2005 09:06:56 +1000

Hi Benoit

Benoit Claise wrote:

> Hi Sebastian,
> 
>>
>>
>> Benoit Claise wrote:
>>
>>> Dear all, :
>>>
>>>> Hi Benoit,
>>>>
>>>>>>>>
>>>>>>>> "There are no constraints regarding the order the Template ID 
>>>>>>>> allocation."
>>>>>>>> ... the order _of_ the ...
>>>>>>>>
>>>>>>>> again, why do we need a separate defintion for template records? 
>>>>>>>> an options
>>>>>>>> template with scope field count = 0 is basically a template 
>>>>>>>> record so the
>>>>>>>> defintion is redundant.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Option Template has got the notion of scope. Personally I prefer 
>>>>>>> to make a clear distinction.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> i think scope it a more general concept. currently it is closely 
>>>>>> tied to
>>>>>> "option data" but the notion of 'option' is very ipfix specific. 
>>>>>> if i'd want
>>>>>> to send data with ipfix that require the use of scope i'd have to 
>>>>>> use option
>>>>>> templates even if my data has nothing to do with 'options'.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I thought initially that you wanted combine the Options Template 
>>>>> Set and Template Set into a single Set, which have a scope length 
>>>>> of 0 if appropriate.
>>>>> Now I'm not sure anymore. Practically, what do you suggest?
>>>>>
>>>>
>>>> yeah, my suggestion is to combine both definitions because de-facto the
>>>> template set is already a subset of the option template set (scope 
>>>> length 0).
>>>> the only advantage i see with the current 2 definitions is that you 
>>>> save 2
>>>> bytes in flow templates, which is not very much (especially with 
>>>> SCTP) for
>>>> effectively doubling the spec.
>>>>
>>>> the notion of 'option templates' (the only templates that have 
>>>> scope) is not
>>>> very general.
>>>
>>>
>>>
>>>
>>> I would like to ping the rest of the working group regarding this issue.
>>> Should we combine the Option Template Set and Template Set into a 
>>> single Set?
>>>
>>>>
>>>> is the flow keys option template an attempt to introduce scope to flow
>>>> templates? if yes (the current text in section 7.4 is a bit hard to 
>>>> understand
>>>> without having the field defintions) wouldn't it be much simpler to 
>>>> have scope
>>>> for all templates? 
>>>
>>>
>>>
>>>
>>> The point is that you only need to send this flow keys option 
>>> template if you want to know the flow keys associated with all the 
>>> information elements in the data record.
>>> Even if you would have a combined Option and Template Set, this would 
>>> not be simplified what you would send:
>>>    - you would still need a template for the data record
>>>    - you would still need a template for the flow key
>>> unless you want to send the flow key in every data record -> this is 
>>> not a good idea!
>>
>>
>>
>> well, my assumption was that the flow keys option template is always 
>> needed
>> because what can i do with the rest of the information without the 
>> flow key?
>> the flow key might not be needed if there are rules known by the 
>> exporter and
>> collector and something in the template would map to the rule(s) (is 
>> there
>> anything like a rule id in the info model?). the current draft does 
>> not really
>> explain these issues.
>>
> There is no rule ID in the information model.
> 
> Other reasons why you might not need to export the flow keys:
> - The flow keys are obvious. If you send <input ifIndex, number of 
> bytes, number of packets> the flow key is obvious. Even if you send 
> <input ifIndex, dest prefix, number of bytes, number of packets>, it 
> sounds reasonable to assume that flow keys are input ifIndex and 
> destination prefix.
> - There is only one set of flow keys defined in your entire network. For 
> example <input ifIndex, src IP address, dest IP address, src L4 port, 
> dest L4 port, DSCP, protocol> as specified in NetFlow.
> My point is that all Template Records don't need to send their 
> associated flow keys.

i think we have some termininolgy issues here. when i meant flow key i meant
the flow key _values_ and not the definition! i agree that the definition
does not always need to be exported. but the flow key values must always be
exported in the flow sets.

> 
>>
>> if you have to export the flow key information for each flow anyway 
>> you might
>> be better off to export it in the data record e.g. if there are lots 
>> of short-lived
>> flows that generate only one record. if you only have long flows and 
>> short interim
>> report intervals it might not be a good idea. depends on the 
>> application...
> 
> 
> You lost me somewhere...
> First of all, I encourage to send the flow keys in an Option Template, 
> sent just once per Template definition.

why do you need that when the scope in a flowset template would exactly define
what is the flow key? this is additional 2 bytes which is less than sending an
additional template.

> However, the IPFIX protocol doesn't prevent you to have a Template that 
> contains the flow-key information element. In this case, the flow-key 
> information element will be sent part of every data records. A waste of 
> bandwidth if you ask me.
 >
> Nothing to do with short or long flows, but with the flow 
> classification: i.e. the flow keys that classified the metered packets, 
> i.e. the Template definition

if you use scope to indicate the flow key you would add 2 bytes to all flowset
templates vs. sending a template. if you have long flows which require interim
exports (at least its a should afaik) it may be more efficient to export the key
via an option template. but most flows are short so i think the current method
is a waste of bandwidth and unnecessary complicated.

cheers,

Sebastian

> Regards,  Benoit.

-- 
Sebastian Zander
http://caia.swin.edu.au

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