Re: [IPFIX] review of draft-ietf-ipfix-a9n-04

[Paul Aitken <[e-mail]>]

Brian,

> I wondered this myself, and I suspect you can't find the LC announcement for this document because you may not be searching far enough in the past.

Not so. I searched both my email and the IPFIX WG archive back to 
-a9n-00 on October 31st 2011.


> WGLC on -a9n began on 5 February 2012, nearly nine months ago (!!!), following a Christmas delay on top of an indication of WGLC readiness at the Taipei IETF meeting.
>
> Since that time, -04 was published in response to WGLC comments, -05 was published in response to comments you sent on an outdated individual version of the draft, -06 in response to your -04 review comments, and -07 in response to Benoit's AD review.

Then it has been well reviewed :-)


>>> BTW, the case of a collector or mediator aggregating received flows presents another possibility: the flow could be received late (eg, delayed export), so rather than re-opening an old start / mid / end aggregation, the flow is simply included in the "current" aggregation. ie, real time aggregation, regardless of the flow timestamps.
>>> A good point; however, this is already covered in section 6.2:
>>>
>>>     In certain circumstances, additional delay at the original Exporter
>>>     may cause an IAP to close an interval before the last Original
>>>     Flow(s) accountable to the interval arrives; in this case the IAP
>>>     SHOULD drop the late Original Flow(s).  Accounting of flows lost at
>>>     an Intermediate Process due to such issues is covered in
>>>     [I-D.ietf-ipfix-mediation-protocol].
>>>
>>> Would you suggest loosening the language to allow an IAP to fake timestamps to avoid drops in delay-intolerant situations?
>> So there are several options:
>>
>> 1. drop the late flows. In this case the late traffic is utterly lost, which may be quite undesirable.
>>
>> 2. re-open the appropriate aggregation to correctly account the late flows.
>> 2a. don't close aggregations immediately, but wait for some period and accept late flows.
>>
>> 3. account the late flows in the current (though wrong) aggregation.
>>
>> I'd prefer that the doc discussed the options or gave reasons rather than simply advising "SHOULD drop".
> The real solution IMO is wait and make sure you've got everything, and treat exceptions as just that. 2a. is just a variant of that solution with two different kinds of waiting. 3. is for when it's more important to be conservative than to be correct, when waiting all the time isn't possible. But this is getting very deeply into implementation choices and application-specific requirements, so I'm inclined to leave it as is. The intention here, again, is to give recommendations for non-corner cases while allowing implementation flexibility.

What you say seems to be contrary to the "SHOULD drop" recommendation. 
Perhaps that should be downgraded to "MAY drop", which seems to give 
permission rather than a recommendation.

P.