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

From: Paul Aitken <[email-masked]>
Date: Thu, 01 Nov 2012 21:15:55 +0000

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.

---

From: Paul Aitken <[email-masked]>
Date: Thu, 01 Nov 2012 22:08:58 +0000

Having missed the WGLC announcement and just seen the IESG LC 
announcement, I thought I should quickly review the 04->05->06->07 diffs.

As usual I have just a few minor points which I hope are helpful.

Sorry things are a bit jumbled up this time, which is due to reviewing 
the three versions in order rather than the larger 04->07 all at once.

Section 3, 5th paragraph:

     I think the paragraph means to say that conversion between Flows is 
possible.
     However, I mis-read that the IEs can be converted within a flow - 
so there's potential ambiguity here:

    While much of the discussion in this document, and all of the
    examples, apply to the common case that the Original Flows to be
    aggregated are all of the same underlying type (i.e., are represented
    with identical Templates or compatible Templatescontaining a core
    set Information Elements which can be freely converted to one
    another), and

Also, there's a missing "of":

    with identical Templates or compatible Templates containing a core
    set*of*Information Elements

Section 8:

     Why was "pt" used for "protocolIdentifier"? Surely "pr" would have 
been more obvious choice and less easily confused with "Port".

Under Figure 19: remove ";" :

    After applying the interval distribution step to the source data in
    Figure 10,*;*  the Partially Aggregated flows are shown in Figure 20.

Under Figure 24: remove space before the comma:

    information from the Original Flows in Figure 10 , and as such is not

Section 6.2:

    Note that when aggregating flows from multiple
    Metering Processes with different active timeouts, the delay is
    *determined by*  the maximum active timeout.

     -  it's not so much "determined by" as "proportional to", because 
an allowance should also be made for other delays.

Section 3, paragraph 4:

     s/anonymising/anonymizing/ for consistency with the 8 other uses in 
the doc.

Section 8:

    The data records given as input to the examples in this section are
    shown below;

     say "in Figure 10", else the figure isn't referenced until after 
Figure 12.

P.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 2 Nov 2012 00:24:02 -0400

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-masked]> 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
>>>> 
> 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.
> 1. drop the late flows. In this case the late traffic is utterly lost, which may be quite undesirable.
> 
> 2a. don't close aggregations immediately, but wait for some period and accept late flows.
> 
> 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

---

From: Brian Trammell <[email-masked]>
Date: Fri, 2 Nov 2012 00:26:11 -0400

Hi, Paul,

Good comments, all, thanks; will address along with area review and other IESG processing comments. 

Cheers,

Brian

On 1 Nov 2012, at 18:08, Paul Aitken <[email-masked]> wrote:

> Having missed the WGLC announcement and just seen the IESG LC announcement, I thought I should quickly review the 04->05->06->07 diffs.
> 
> Sorry things are a bit jumbled up this time, which is due to reviewing the three versions in order rather than the larger 04->07 all at once.
> 
> 
>     I think the paragraph means to say that conversion between Flows is possible.
>     However, I mis-read that the IEs can be converted within a flow - so there's potential ambiguity here:
> 
>    set of Information Elements
> 
> 
> Section 8:
> 
>     Why was "pt" used for "protocolIdentifier"? Surely "pr" would have been more obvious choice and less easily confused with "Port".
> 
> 
>    Figure 10,; the Partially Aggregated flows are shown in Figure 20.
> 
> 
>    determined by the maximum active timeout.
> 
>     -  it's not so much "determined by" as "proportional to", because an allowance should also be made for other delays.
> 
> 
> Section 3, paragraph 4:
> 
>     s/anonymising/anonymizing/ for consistency with the 8 other uses in the doc.
> 
> 
> Section 8:
>     say "in Figure 10", else the figure isn't referenced until after Figure 12.
> 
> 
> P.
>

---

From: Paul Aitken <[email-masked]>
Date: Fri, 02 Nov 2012 10:12:16 +0000

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

Then it has been well reviewed :-)

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

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.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 2 Nov 2012 06:58:18 -0400

Hi, Paul,

On 2 Nov 2012, at 6:12, Paul Aitken <[email-masked]> wrote:

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

Hm, indeed, the draft is called "Aggregation" in the subject of the WGLC message...

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

Works for me. I'll put it on the pile for -08

Cheers, Brian

---

From: Paul Aitken <[email-masked]>
Date: Fri, 02 Nov 2012 11:18:20 +0000

> Hm, indeed, the draft is called "Aggregation" in the subject of the WGLC message...

Thanks, I see it now.

P.