Re: [IPFIX] [QUAR] Re: Export of long lived flow information

Andrew Feren <andrewf@plixer.com> Mon, 29 October 2012 13:08 UTC

Return-Path: <andrewf@plixer.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA6221F85C0 for <ipfix@ietfa.amsl.com>; Mon, 29 Oct 2012 06:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.595
X-Spam-Level:
X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, TRACKER_ID=2.003]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kR1RNxPt95bG for <ipfix@ietfa.amsl.com>; Mon, 29 Oct 2012 06:08:42 -0700 (PDT)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 0435621F853F for <ipfix@ietf.org>; Mon, 29 Oct 2012 06:08:41 -0700 (PDT)
Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Oct 2012 09:08:40 -0400
Message-ID: <508E7FD8.6000207@plixer.com>
Date: Mon, 29 Oct 2012 09:08:40 -0400
From: Andrew Feren <andrewf@plixer.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Thunderbird/19.0a1
MIME-Version: 1.0
To: Paul Aitken <paitken@cisco.com>
References: <CCAF4E37.114EE%andrewf@plixer.com> <508E6EF2.8000801@cisco.com>
In-Reply-To: <508E6EF2.8000801@cisco.com>
Content-Type: multipart/alternative; boundary="------------070202020409000807040800"
X-OriginalArrivalTime: 29 Oct 2012 13:08:40.0619 (UTC) FILETIME=[84056FB0:01CDB5D6]
Cc: John Court <johnwcrt@au1.ibm.com>, ipfix@ietf.org
Subject: Re: [IPFIX] [QUAR] Re: Export of long lived flow information
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2012 13:08:43 -0000

Hi Paul,

Interesting observation.   The use of flow in these has never tripped me 
up the same way as the text in the original question.

On 10/29/2012 07:56 AM, Paul Aitken wrote:
> Should we change "this Flow" to "accounted in this Flow Record" 
> throughout the registry?
>
> I counted 67 instances. eg:
>
>
> octetDeltaCount
>
>          The number of octets since the previous report (if any)
>          in incoming packets for this Flow at the Observation Point.

For this I think Flow is correct.  I also think this highlights the 
distinction being made by people between Flow and Flow Record.  If a 
Flow is bounded the same way (has the same start and end time) as a Flow 
Record then there can't have been a previous report for this Flow.  The 
Flow and Flow Record would be the same.

>
>
> tcpControlBits
>
>          TCP control bits observed for packets of this Flow.
>          The information is encoded in a set of bit fields.
>          For each TCP control bit, there is a bit in this
>          set.  A bit is set to 1 if any observed packet of this
>          Flow has the corresponding TCP control bit set to 1.
>          A value of 0 for a bit indicates that the corresponding
>          bit was not set in any of the observed packets
>          of this Flow.
>
>
> flowDurationMilliseconds
>
>          The difference in time between the first observed packet
>          of this Flow and the last observed packet of this Flow.

Eep.  Thinking about this is making me rethink my initial +1, but I do 
still think some rewording is needed.  Using Flow Record works for 
deltas, but not for totals.  I'm not sure yet what the right wording is.

>
>
> ingressInterface
>
>            The index of the IP interface where packets of this Flow
>            are being received.
>
>
> egressInterface
>
>            The index of the IP interface where packets of
>            this Flow are being sent.

I think these last two are typically part of what defines a flow and 
won't change with out changing the Flow.  So I guess Flow is as good as 
Flow Record.
>
> P.