Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation

Gerhard Muenz <muenz@net.in.tum.de> Thu, 26 February 2009 08:37 UTC

Return-Path: <muenz@net.in.tum.de>
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54593A69B4 for <ipfix@core3.amsl.com>; Thu, 26 Feb 2009 00:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.182
X-Spam-Level:
X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhNxb8sk9XGi for <ipfix@core3.amsl.com>; Thu, 26 Feb 2009 00:37:43 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 8DB453A69A1 for <ipfix@ietf.org>; Thu, 26 Feb 2009 00:37:42 -0800 (PST)
Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 9BEA1483D0; Thu, 26 Feb 2009 09:38:01 +0100 (CET)
Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 81F5E3CD7; Thu, 26 Feb 2009 09:38:01 +0100 (CET)
Message-ID: <49A654E6.8000605@net.in.tum.de>
Date: Thu, 26 Feb 2009 09:37:58 +0100
From: Gerhard Muenz <muenz@net.in.tum.de>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Andrew Johnson <andrjohn@cisco.com>
References: <4998D006.1030106@cs.waikato.ac.nz> <49A2C8D8.3000402@net.in.tum.de> <49A31B3C.8070004@cisco.com> <49A3C322.4030000@net.in.tum.de> <49A3F1CA.80801@cisco.com> <FDB62598-788E-4F28-945B-F13C0D99A419@tik.ee.ethz.ch> <49A3F7FD.7080902@net.in.tum.de> <49A3FA98.6060403@cisco.com> <49A3FDE1.6040405@net.in.tum.de> <49A408AD.7080201@cisco.com> <49A4100C.3070902@net.in.tum.de> <49A41630.4030208@cisco.com> <49A50021.3050100@net.in.tum.de> <49A55E5E.9060609@cisco.com>
In-Reply-To: <49A55E5E.9060609@cisco.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms080009060307070808020305"
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: Maji - an open source IPFIX meter implementation
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 26 Feb 2009 08:37:45 -0000

Hi Andrew,

>>> Yes, I know.  It's very difficult to export min/max/mask using IPFIX
>>> without defining new Information Elements for each field you want to
>>> filter on.
>>
>> Hm, I do not think that defining min/max/mask IEs for every existing IE
>> is needed. I'm sure that a better solution can be found.
> 
> Perhaps, I'd certainly like to think so, but so far I've not seen any real
> contenders.  I can't think of anything that doesn't need data types and/or
> deviate a lot from how we use IPFIX today.
> 
>>>> Note that the configuration data model is based in PSAMP-MIB where
>>>> "start", "stop" and "mask" are mentioned as parameters of property
>>>> match
>>>> filtering. It seems that these parameters are outdated?
>>> When we added the Filtering Interpretation Report in version 02 we
>>> didn't have min/max/mask either.  There's just no easy way to export
>>> this sort of think in IPFIX without defining three additional I.E.s per
>>> field.  Unless anyone can think of something?
>>
>> Yes:
>> http://tools.ietf.org/html/draft-sommer-ipfix-mediator-ext-01
> 
> I don't see how this helps, other than the ability to exclude certain
> values.  I didn't see any indication of how to handle multiple uses of
> the same I.E., but presumably they follow the same rule as for different
> I.E.s and are added with an AND operation, and are therefore
> automatically conflicting.

The abstract data type portRanges has been conceived to report a list of
port numbers. This ADT can be used to define an IE
destinationTransportPortList which can be used in the Filtering
Interpretation Report we have today.

I admit that an ADT portRange is very restrictive. Maybe, it is better
to standardize an ADT listUnsigned16 which works like "orderedList" in
the draft. This ADT can be used to express a list of values for any
unsigned16-field.

You are right, this approach requires new IEs, but only one new IE for
any existing one where it makes sense. Instead of assigning new IE Ids,
we could think of a trick using a specific enterprise number (like in
biflow) to extend the ADT of existing IEs to list-type ADTs.

> For example, how would you represent a match on the TCP syn flag?  With
> min/max/flags we could have 0x02, 0x02, 0x02.  Easy.
>
> In the Filtering Interpretation Report you could use multiple inclusion
> filters / selection paths:
> 
>  OP1, TCP flags = 0x02
>  OP1, TCP flags = 0x03
>  OP1, TCP flags = 0x06
>  OP1, TCP flags = 0x07
>  ...
>  OP1, TCP flags = 0x1A
>  OP1, TCP flags = 0x1B
>  OP1, TCP flags = 0x1E
>  OP1, TCP flags = 0x1F
> 
> Yuck.

Can you give me an example of all destination ports except port 80 ;)

> How would this be done with
> http://tools.ietf.org/html/draft-sommer-ipfix-mediator-ext-01?

We have not thought of TCP flags, yet.

First, we could define an ADT listUnsigned8. Then you can
describe all the values from above with a single IE tcpControlBitsList.

If you prefer min/max/mask, an ADT minMaxMaskUnsigned8 could be defined
with a length of 3 octets.

>> In my opinion, the current property match filtering specified in PSAMP
>> is too restrictive because it only covers simplistic fiters that are
>> rarely used in practice. Maybe it should be removed from the documents
>> until a better solution is found.
> 
> Well, a future draft could extend the filtering mechanisms, but I don't
> think we should discard what we have today.  A new selection type can be
> added later when we have a way of representing more complex solutions.

Do you think that it is possible to standardize such ADTs that follow
this "any value of"-semantic? Or would it be a solution that deviates "a
lot from how we use IPFIX today" - as you call it?

Cheers,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: muenz@net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz