Re: [IPFIX] IPFIX at IETF 89, London

Benoit Claise <bclaise@cisco.com> Fri, 14 February 2014 21:49 UTC

Return-Path: <bclaise@cisco.com>
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 C95321A0445 for <ipfix@ietfa.amsl.com>; Fri, 14 Feb 2014 13:49:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.549
X-Spam-Level:
X-Spam-Status: No, score=-14.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Vo8tFbz5Fz7W for <ipfix@ietfa.amsl.com>; Fri, 14 Feb 2014 13:48:59 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1671A0411 for <ipfix@ietf.org>; Fri, 14 Feb 2014 13:48:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3103; q=dns/txt; s=iport; t=1392414529; x=1393624129; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5aWlz6VOYP13TDbFdqi9UvsTHDgnXGwijN5C/NpKq6k=; b=FI/e1m0/IuvAGrAAUlWvuMJG6TYhK7f9m2ai/iFRg3SIzd/AATJ67U/c D37pEEaP4xCbiAxnd31lW9H2YzJFIXoZsruU0eP6yf1iMmi+oxLYITAX3 rKPYWDLKNmEfuEDnyJ8po41vzC60GzDlp2NsIXWYlBSgokpu0uYReH0mn Q=;
X-IronPort-AV: E=Sophos;i="4.95,847,1384300800"; d="scan'208";a="304228984"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 14 Feb 2014 21:48:49 +0000
Received: from [10.82.245.17] (rtp-vpn2-1296.cisco.com [10.82.245.17]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1ELmlau018538; Fri, 14 Feb 2014 21:48:47 GMT
Message-ID: <52FE7355.2000809@cisco.com>
Date: Fri, 14 Feb 2014 14:49:41 -0500
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Andrew Feren <andrewf@plixer.com>, Paul Aitken <paitken@cisco.com>, Nevil Brownlee <n.brownlee@auckland.ac.nz>, IPFIX Working Group <ipfix@ietf.org>
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> <8E7542283B89BB4DB672EB49CEE5AAB7054010B8@PLXRDC01.plxr.local>
In-Reply-To: <8E7542283B89BB4DB672EB49CEE5AAB7054010B8@PLXRDC01.plxr.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/cpjhYyrFyKjILnsgRrvyzoKEdlI
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: Fri, 14 Feb 2014 21:49:02 -0000

Hi Andrew,
> Hi Benoit,
>
> I think both topics are interesting, but if I had to pick one to put some work into it would be the unobserved fields draft.  There is a need to communicate this information (or lack of information ;-).  I am already starting to see exports where different vendors are choosing different ad hoc methods to communicate N/A for the same IEs.
>
> As for draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie, I'm mostly interested in anything that encourages exporters to "publish" info about the IEs they export.  Given the lack of uptake for 5610 I'm not optimistic that an alternate/updated version of 5610 will get any more traction.
You nailed it. This is my argument against 
draft-aitken-ipfix-equivalent-ies.
RFC 5610 is a nice mechanism for all the Exporters to send some IPFIX 
information (the  type of  enterprise(specific IEs) to the Collector, to 
basically plan nice.  In practice, do you see any implementation of it 
in your Collector?
I'm afraid that draft-aitken-ipfix-equivalent-ies would fall in the same 
category.

> Most of the time I'd be happy to get a text file with 7013 style Information Element Specifiers.
Yes, received a single time from the different vendors (as opposed from 
all the Exporters) and hard-coded in collectors. Note that some 
automation is possible if the format is agreed upon.

Regards, Benoit (as a contributor)
>
> Just my 2 cents,
> -Andrew
> ________________________________________
> From: Benoit Claise [bclaise@cisco.com]
> Sent: Monday, February 10, 2014 7:50 PM
> 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.
>> .
>>
> .
>