Re: [IPFIX] draft-ietf-ipfix-a9n
Benoit Claise <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Forwarding to the IPFIX mailing list for visibility.
Thanks Rahul
Regards, Benoit.
> 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) }
>
>
>
> 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.
>
> * 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.
>
> 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