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

Hi Benoit,


On 2/24/12 5:48 AM, "Benoit Claise" <[email protected]> wrote:

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

[RP] That would be good.

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

[RP] exactly.

-Rahul

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