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

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


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


>>>     dest ip4       port  dist src
>>>     192.0.2.131    53           3
>>>     198.51.100.2   80           1
>>>     198.51.100.2   443          3
>>>     198.51.100.67  80           2
>>>     198.51.100.68  80           2
>>>     198.51.100.133 80           2
>>>     198.51.100.3   80           3
>>>     198.51.100.4   80           2
>>>     198.51.100.17  80           1
>>>     198.51.100.69  443          1
>>>
>> This table seems to be completely wrong. Even the total counts is wrong - ie, add up the "dist src" = 20. Yet Figure 9 has 24 entries.
> These are *distinct* sources per destination endpoint.
>
> For 192.0.2.131:53, there are 5 flows, but the sources are 192.0.2.2, 192.0.2.3, 192.0.2.131.

I went over it again and finally worked it out - so no issue.
(This has been troubling me for a while, but I didn't relish re-working 
the data.)


>>>     Benoit Claise
>>>     Cisco Systems, Inc.
>>>     De Kleetlaan 6a b1
>>>     1831 Diagem
>>>
>> Once again, in existing RFCs - and in Cisco's internal directory - this is "Diegem 1831".
> Per the Universal Postal Union, the most authoritative reference source I could find in English with a couple of minutes of googling, the proper format for addressing in Belgium places the postcode before the municipality name.
>
> See: http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/belEn.pdf

NB "Diagem" != "Diegem".

Looking at Benoit's 22 RFCs + 17 drafts reveals the following 52 usages:

      13 1831 Diegem
      10 Diegem  1831
       7 Diegem 1813
       6 Degem 1831
       5 Diegem 1831
       3 Degem  1831
       2 Degem  1813
       1 Diegem,   1831
       1 Diegem,   1813
       1 Diegem  B-1831
       1 Diegem  1813
       1 Brussels, Diegem  B-1831
       1 1831 Diagem

Some drafts even have > 1 format.

I'll leave you to draw your own conclusions.

P.

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