Re: [IPFIX] draft-ietf-ipfix-a9n

Rahul,

Thanks for your review.
>
>> Hi,
>>
>> Here are my comments.
>>
>> I think correlation is important part of aggregation and this draft 
>> should
>> include a section on it.
>> There are different cases of correlation which the draft should touch.
>>
>> 1. Key fields of Aggregated Flow is same or the subset of all original
>> Flows
>>       * In this case the correlation is straight forward. The values 
>> from
>> the original flows are simply merged (added/replaced/etc) into matching
>> aggregated flow.
>> 2. Key fields of Aggregated Flow is larger than at least one original 
>> flow.
>>       * An example is best to describe this case. One original flow 
>> contain
>> (5-tuple, src-interface, byte) and another original flow contains
>> (5-tuple, transaction-delay). Now the aggregated flow has the key fields
>> of srcip, dstip and src-interface). One of the flow doesn't have
>> information on per source-interface basis. So the aggregator will 
>> perform
>> aggregation at two level and represent that data in ipfix-structured
>> format. The above data would look like
>>
>> Srcip, dstip, transaction_delay, { List of {src-interface, byte } }
>> =====  =====  =================  ==================================
>> A,     B,     200,               { (Ethernet0/0, 1500),
>>                                     (Ethernet1/0, 1600) .. }
>> A,     C,     300,               { (Ethernet0/0, 1500) }
>>
Maybe we can point to RFC6313 as a potential solution, but not specify 
the rules in this draft.
Btw, the rules would be very difficult to specify.
So, some generic text.
>>
>>
>> Section 5.1.1 Distributing values across Interval
>> -------------------------------------------------
>> * should add 'synchronized expiry of Original Flows' - Under this method
>> Flow C would be exported three times with start-time/end-time 
>> matching the
>> aggregation interval start-time/end-time.
Make sense to me.
>>
>> * There will always going to some original flows which will arrive late
>> and will not be accounted. It will be good have a cumulative counter of
>> such late arrivals on per template id (aggregated flow) basis. This
>> cumulative count should be periodically exported along with end-time
>> (time-of-snapshot). The counter will provide a degree of confidence 
>> in the
>> data exported by the aggregator for each template.
So you want something similar to "The Metering Process Statistics Option 
Template" from RFC5101, http://tools.ietf.org/html/rfc5101#page-23, but 
for the Aggregation Intermediate Aggregation Process, right?

Regards, Benoit.
>>
>> Section 5.2 Spatial aggregation
>> -------------------------------
>> * Is it a good idea to add an example of deriving a key in aggregate 
>> flow
>> from multiple keys or non-keys or combination of Original keys. E.g
>> 5-tuple translated to a session-id from metadata table.
>> * Along similar line, derivation of aggregate flow key from multiple 
>> keys
>> from different Original flows. One flow reports 5-tuple and byte-count.
>> The other flow reports 5-tuple and the user-id. The aggregated flow has
>> the user-id as key and byte-count as collect. I guess this can be
>> considered a correlation.
>>
>>
>> Thanks,
>> -Rahul
>>
>>
>>
>
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix
>
>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix