Re: [IPFIX] clarification questions

Gerhard Muenz <muenz@net.in.tum.de> Tue, 02 April 2013 18:20 UTC

Return-Path: <muenz@net.in.tum.de>
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 4597221F8BBB for <ipfix@ietfa.amsl.com>; Tue, 2 Apr 2013 11:20:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDVTVRFSI17Q for <ipfix@ietfa.amsl.com>; Tue, 2 Apr 2013 11:20:09 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mailsender1.informatik.tu-muenchen.de [131.159.0.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5AA21F8BB6 for <ipfix@ietf.org>; Tue, 2 Apr 2013 11:20:08 -0700 (PDT)
Received: from [192.168.2.34] (g227197049.adsl.alicedsl.de [92.227.197.49]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 7C31A19AF833; Tue, 2 Apr 2013 20:20:05 +0200 (CEST)
Message-ID: <515B2151.9090304@net.in.tum.de>
Date: Tue, 02 Apr 2013 20:20:01 +0200
From: Gerhard Muenz <muenz@net.in.tum.de>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: ramki Krishnan <ramk@Brocade.com>
References: <C7634EB63EFD984A978DFB46EA5174F2BFD7ECDAFA@HQ1-EXCH01.corp.brocade.com> <515362E7.9040306@net.in.tum.de> <C7634EB63EFD984A978DFB46EA5174F2BFD7ECDEC9@HQ1-EXCH01.corp.brocade.com>
In-Reply-To: <C7634EB63EFD984A978DFB46EA5174F2BFD7ECDEC9@HQ1-EXCH01.corp.brocade.com>
Content-Type: multipart/alternative; boundary="------------090703070603000808020802"
Cc: Ning So <Ning.So@tatacommunications.com>, IPFIX Working Group <ipfix@ietf.org>
Subject: Re: [IPFIX] clarification questions
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: Tue, 02 Apr 2013 18:20:11 -0000

Hi Ramki,

In your own implementation, you can use whatever parameter you want. 
Regarding the standard configuration data model, I do not think that an 
exportInterval parameter should be added to TimeoutCache and 
NaturalCache. This would change the meaning of TimeoutCache and 
NaturalCache as described in RFC 6728.

Regards,
Gerhard


On 28.03.2013 22:06, ramki Krishnan wrote:
>
> Hi Gerhard,
>
> Thanks a lot. More below.
>
> >>- With TimeoutCache and NaturalCache, the Flow is only exported when 
> it is expired. At expiration, the Flow is immediately removed from the 
> Cache. A longlasting flow will result in a new Flow being created in 
> the Cache.
>
> For applications, especially security, it would be worthwhile to 
> periodically export the flow for monitoring purposes. We could add an 
> optional "exportInterval" parameter similar to PermanentCache for 
> this. Your comments/thoughts would be appreciated.
>
> Hi Gerhard/All,
>
> >>It seems that your actual question is how flow selection fits into 
> the IPFIX device architecture which has been taken as a basis for RFC 
> 6728. Concretely, you seem to wonder  whether your flow selection is a 
> kind of Selection Process or a new kind of Cache (or maybe both?).
>
> The new data models I am trying to specify are based on the following 
> draft and presentation at the IETF Orlando meeting.  It seems to me 
> that a good starting point is specifying a new flow selection process. 
> Your comments/thoughts would be appreciated.
>
> http://www.ietf.org/proceedings/86/slides/slides-86-ipfix-1.pptx
>
> http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling/
>
> Thanks,
>
> Ramki
>
> *From:*Gerhard Muenz [mailto:muenz@net.in.tum.de]
> *Sent:* Wednesday, March 27, 2013 2:22 PM
> *To:* ramki Krishnan
> *Cc:* IPFIX Working Group; Ning So
> *Subject:* Re: [IPFIX] clarification questions
>
>
> Hi Ram,
>
> The configuration model of RFC 6728 does not cover flow selection. If 
> you want to configure something like flow selection, you need to 
> extend the model.
>
> It seems that your actual question is how flow selection fits into the 
> IPFIX device architecture which has been taken as a basis for RFC 
> 6728. Concretely, you seem to wonder  whether your flow selection is a 
> kind of Selection Process or a new kind of Cache (or maybe both?).
>
> I cannot answer this question because I do not know how it would be 
> implemented.
>
> Regarding your question:
> - With TimeoutCache and NaturalCache, the Flow is only exported when 
> it is expired. At expiration, the Flow is immediately removed from the 
> Cache. A longlasting flow will result in a new Flow being created in 
> the Cache.
> - It's different with PermanentCache. Here, the Flow remains in the 
> Cache, and the status is periodically exported.
>
> Regards,
> Gerhard
>
> On 27.03.2013 18:40, ramki Krishnan wrote:
>
>     Dear IPFIX experts,
>
>     From RFC 6728,
>
>     1.Section 4.3.2
>
>     oIs there a way to periodically export the flows if we are using a
>     TimeoutCache or NaturalCache ?
>
>     2.Suppose we want to populate the cache only with long-lived large
>     flows (see Note1  below for data model definitions)
>
>     oOne way to achieve this would be to have a selection process,
>     using a unique observation domain, which filters the long-lived
>     large flows. Are any other better ways ?
>
>     3.Continuing from 3) - suppose we want to sample the other flows
>     (not the long-lived large flows)
>
>     oIs there a way to not include the long-lived large flows in the
>     selection process ?
>
>     Note 1:
>
>     -observationInterval: The minimum time interval to observe a flow
>     for performing further processing of the flow. Unit is in seconds.
>
>     -bandwidthThreshold: The minimum bandwidth of the flow during the
>     observation interval for declaring the flow a long-lived large
>     flow. Unit is in Mbps.
>
>     For example, a flow which is at or above 10 Mbps
>     (bandwidthThreshold )for a time period of at least 30 seconds
>     (observationInterval) could be declared a long-lived large flow.
>
>     --
>
>     Thanks,
>
>     Ram (aka Ramki)
>
>
>
>
>     _______________________________________________
>
>     IPFIX mailing list
>
>     IPFIX@ietf.org  <mailto:IPFIX@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/ipfix
>