Re: [IPFIX] IPFIX at IETF 89, London

Juergen Quittek <Quittek@neclab.eu> Wed, 12 February 2014 14:52 UTC

Return-Path: <Quittek@neclab.eu>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5B1A099A for <ipfix@ietfa.amsl.com>; Wed, 12 Feb 2014 06:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.15
X-Spam-Level:
X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnhjLbE9S57L for <ipfix@ietfa.amsl.com>; Wed, 12 Feb 2014 06:52:11 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 10E3A1A09B1 for <ipfix@ietf.org>; Wed, 12 Feb 2014 06:52:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 02DD7106C6E; Wed, 12 Feb 2014 15:52:03 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIaWYqzgFD6h; Wed, 12 Feb 2014 15:52:02 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id DA0B8106C6A; Wed, 12 Feb 2014 15:51:27 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 12 Feb 2014 15:51:06 +0100
From: Juergen Quittek <Quittek@neclab.eu>
To: Benoit Claise <bclaise@cisco.com>, Paul Aitken <paitken@cisco.com>, Nevil Brownlee <n.brownlee@auckland.ac.nz>, Andrew Feren <andrewf@plixer.com>, IPFIX Working Group <ipfix@ietf.org>
Thread-Topic: [IPFIX] IPFIX at IETF 89, London
Thread-Index: AQHPJqYuRGHNYWHAu0y7FJaSANXb05qvBo6AgAAh3YCAAolscA==
Date: Wed, 12 Feb 2014 14:51:05 +0000
Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A49AB4@PALLENE.office.hd>
References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> <52F80BCA.2030408@auckland.ac.nz> <52F8AAB5.5050604@cisco.com> <52F9430C.3040909@cisco.com> <52F95765.50902@cisco.com> <52F973CD.80607@cisco.com>
In-Reply-To: <52F973CD.80607@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.2.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipfix-ads@tools.ietf.org" <ipfix-ads@tools.ietf.org>, "ipfix-chairs@tools.ietf.org" <ipfix-chairs@tools.ietf.org>
Subject: Re: [IPFIX] IPFIX at IETF 89, London
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 12 Feb 2014 14:52:13 -0000

Dear all,

As technical contributor, I send my view on the two drafts from Paul:

The equivalent-ies draft is targeted at several use cases and with some of them I see need for discussion. I would have no problem with a standard that restricted to be only applied if an exporter changes the IE identifier without any other technical change, for example, after registering an enterprise-specific IE at IANA with a new number. But if this feature is used for other use cases as listed in the draft, I see a lot of issues that should be investigated. Two example issues are (1) exporters declaring "similar" IEs to be equivalent and (2) conflicting equivalence declarations from different exporters. There are more issues like these. Most of them can reduced to the core problem that the draft only defines a message format and not under which condition two IEs may or must not be declared equivalent.

For the unobserved-fields draft I see similar issues. The semantics is not fully clear and the same holds for implications on collectors. Does unobserved mean: I did not observe the IE, because there was no instance in any observed packet, because observation failed, because there is no instrumentation to observe the IE, or for any other reason. These are all different use case and there are more of them, maybe with more subtle differences, that need discussion.

My conclusion is, that I see both drafts addressing valid issues, but not as drafts to be finished soon. The both drafts look like good candidate an "experimental" RFCs, because "equivalence" of measurements and "unobserved" flow properties are concepts that may need time and operational experience to define them well.

Cheers,
    Juergen

> -----Original Message-----
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Dienstag, 11. Februar 2014 01:50
> To: Paul Aitken; Nevil Brownlee; Andrew Feren; IPFIX Working Group
> Cc: ipfix-ads@tools.ietf.org; ipfix-chairs@tools.ietf.org
> Subject: Re: [IPFIX] IPFIX at IETF 89, London
> 
> Paul,
> 
> At this point, I will be listening to the chairs to see  ...
>      if this is really "interesting",
>      if there is enough support from the IPFIX community,
>      if there is enough discussion on it,
>      and if this work could be done in the decent time.
> 
> (*) I guess that I'm so much involved in IPFIX that I have strong opinions
> about your drafts. That's the price you pay for an AD who knows IPFIX by
> heart.
> 
> Regards, Benoit
> > Benoit,
> >
> >>> I've presented these ideas in previous WG meetings, where the
> >>> consensus was to wait for the next re-charter.
> >> Consensus, sure?
> >
> > Yes: the work was interesting, but not relevant to the current
> > charter. So, bring it up at the next recharter - which hasn't happened
> > yet.
> >
> >
> >> I checked the meeting minutes and I don't see that.
> >> What I recall is that two different proposals were discussed
> >> (draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie-00),
> >> with no clear winner.
> >
> > Sure; each of these drafts has different merits. It would be up to the
> > WG to decide on the best solution.
> >
> > Look, here's a real problem in IPFIX which has resulted in not one but
> > *two* different drafts trying to solve it in different ways. Do you
> > propose to ignore it?
> >
> > P.
> > .
> >