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

Paul,

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

Points inline.

On 1 Nov 2012, at 16:15, Paul Aitken <[email protected]> wrote:

> Nevil, when was the WGLC on this document? I can't find any WG emails with the appropriate subject line.
> 
> 
> Brian, the IESG LC prompted me to re-review this. Please see inline as usual...
> 
> 
>>>> 2.  Terminology
>>>> 
>>>>    Terms used in this document that are defined in the Terminology
>>>>    section of the IPFIX Protocol [I-D.ietf-ipfix-protocol-rfc5101bis]
>>>>    document are to be interpreted as defined there.
>>>> 
>>>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>>>    document are to be interpreted as described in [RFC2119].
>>>> 
>>>>    In addition, this document defines the following terms
>>>> 
>>>>    Aggregated Flow:   A Flow, as defined by
>>>>       [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of zero
>>>>       or more original Flows within a defined Aggregation Interval.  The
>>>> 
>>> Zero things can't be aggregated. You can only say, "none were seen".
>> This is equivalent to what's written in the terminology, no? Export of an aggregation of an empty set is the same thing as an assertion that nothing was observed corresponding to the given key in the reported interval.
> 
> So to be quite clear: when zero flows are aggregated, is the result zero Aggregated Flows, or is the result one Aggregated Flow which says there was nothing to be aggregated? (I know it sounds odd, but it's a serious question.)

It depends (I know it sounds flippant, but it's a serious answer).

If an IAP has been configured to report all volumes (matching some selection) per (regular, externally imposed) interval, for example, and it observed zero packets for an interval, it should report that so it's clear there were no flows and not a missing report: "I was looking for this key, but I didn't see it, sorry!"

On the other hand, when aggregating by more complicated keys or larger selections it probably doesn't make much sense to report "I saw no flows" for all the keys for which no flows/packets/bytes were seen, unless one is trying to generate a whole bunch of useless data records e.g. to stress-test a collector.

The intention is to leave this up to implementors as appropriate for each specific set of application requirements.
>> 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. 

Cheers,

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