Re: [IPFIX] clarification questions

ramki Krishnan <ramk@Brocade.com> Thu, 28 March 2013 21:06 UTC

Return-Path: <ramk@Brocade.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 6E64821F8FF0 for <ipfix@ietfa.amsl.com>; Thu, 28 Mar 2013 14:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.264
X-Spam-Level:
X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1]
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 UsyL2ytVY++0 for <ipfix@ietfa.amsl.com>; Thu, 28 Mar 2013 14:06:07 -0700 (PDT)
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0622621F8BE2 for <ipfix@ietf.org>; Thu, 28 Mar 2013 14:06:07 -0700 (PDT)
Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r2SL36NP026339; Thu, 28 Mar 2013 14:06:06 -0700
Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1bcqdc880h-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Mar 2013 14:06:06 -0700
Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 28 Mar 2013 14:06:05 -0700
Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 28 Mar 2013 14:06:05 -0700
From: ramki Krishnan <ramk@Brocade.com>
To: Gerhard Muenz <muenz@net.in.tum.de>, IPFIX Working Group <ipfix@ietf.org>
Date: Thu, 28 Mar 2013 14:06:04 -0700
Thread-Topic: [IPFIX] clarification questions
Thread-Index: Ac4rMRTQYHDORG/mSAqhpClT0ppV7wAobknw
Message-ID: <C7634EB63EFD984A978DFB46EA5174F2BFD7ECDEC9@HQ1-EXCH01.corp.brocade.com>
References: <C7634EB63EFD984A978DFB46EA5174F2BFD7ECDAFA@HQ1-EXCH01.corp.brocade.com> <515362E7.9040306@net.in.tum.de>
In-Reply-To: <515362E7.9040306@net.in.tum.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BFD7ECDEC9HQ1EXCH01corp_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-28_07:2013-03-28, 2013-03-28, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303280219
Cc: Ning So <Ning.So@tatacommunications.com>
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: Thu, 28 Mar 2013 21:06:09 -0000

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

o   Is 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)

o   One 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)

o   Is 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