Re: [IPFIX] Winding down the ipfix working group.

Stewart Bryant <stbryant@cisco.com> Wed, 17 December 2014 12:14 UTC

Return-Path: <stbryant@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 3DE441A8955 for <ipfix@ietfa.amsl.com>; Wed, 17 Dec 2014 04:14:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 y72Msa9qt3SB for <ipfix@ietfa.amsl.com>; Wed, 17 Dec 2014 04:14:55 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C2E1A1A7D for <ipfix@ietf.org>; Wed, 17 Dec 2014 04:14:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2863; q=dns/txt; s=iport; t=1418818495; x=1420028095; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qJYIIga3y5PkFc3/y75QmB+WZ/XIHPAsxn6wBf9AYHc=; b=eHpknH9u7kAa4C4aHM1DkhSx1QPcHsjMD61Ekv0GueOCpRSAzyyzxqwH iT1hf/U45kOQUeW1J8AeyqvNu39axtvmZ26//FEYNPVfc++bBL1q2GRNk p3U0GB2YTcl+riRV6h3231983VjRusPfh9oiziSbmge8xhOPMqDuOKdT/ Y=;
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="277569356"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 17 Dec 2014 12:14:53 +0000
Received: from [10.61.196.146] ([10.61.196.146]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBHCEruK017621; Wed, 17 Dec 2014 12:14:53 GMT
Message-ID: <549173BE.8050901@cisco.com>
Date: Wed, 17 Dec 2014 12:14:54 +0000
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Paul Aitken <paitken@Brocade.com>, Benoit Claise <bclaise@cisco.com>, Andrew Feren <andrewf@plixer.com>
References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com>, <548ECA8F.7030209@cisco.com> <08A9E6AF-F505-4D5D-AC9C-E35D2AF8E08D@plixer.com> <548ED9CF.8070309@cisco.com> <5491479B.6060305@cisco.com> <23B7BE54EACBED43957AB709C564F7B701853E2971@EMEA-EXCH01.corp.brocade.com>
In-Reply-To: <23B7BE54EACBED43957AB709C564F7B701853E2971@EMEA-EXCH01.corp.brocade.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/jfA5m924iw_qpunKhjNz43cVSmk
Cc: joel jaeggli <joelja@bogus.com>, IPFIX Working Group <ipfix@ietf.org>, "ipfix-chairs@tools.ietf.org" <ipfix-chairs@tools.ietf.org>
Subject: Re: [IPFIX] Winding down the ipfix working group.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
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, 17 Dec 2014 12:14:59 -0000

On 17/12/2014 10:37, Paul Aitken wrote:
> Benoit, All,
>
>>> Well a bit off the cuff, but how about pre-registered templates rather than refreshed templates so that IOT devices don't need to use energy or bandwidth to transmit them?
>> So going back to NetFlow v5? :-)
>> As you know, we had to move away from v5 to v9 to solve a real problem.
> Templates generally consume only a tiny portion of the export bandwidth, so they're a non-issue for hard-wired devices in an enterprise or data-centre setting.
>
> However, if a device isn't able to maintain an SCTP or TCP connection (eg because it's a low-power device which exports infrequently and powers down between exports, or it's a mobile device which goes out of range), then the exporter would need to re-send the template at the start of each export. In the worst case the template could be sent with each data record (assuming export over UDP), at which point templates become a significant portion of the export bandwidth. I've seen a packet capture from a device which actually does that.
>
> So I could imagine a use-case where pre-registered templates are useful. The exporter would only send data records, and the collector would have to obtain the necessary template(s) from a repository.
>
> However if the exporter sends the repository URL rather than the template then it's possible that there would be no export saving at all. If the exporter sends a template ID then we'd have to consider how the collector discovers where the repository is located and authentication of the received templates. If it's a central repository then we have to think about authentication for addition of new templates and whether modifications are allowed.
>
> If it was a real use case with actual demand behind it then it could be addressed in one draft which could be AD sponsored. However since it seems to be a theoretical idea with no demand, there seems to be no justification in keeping the WG open just for this.
>
> It could be an interesting NMRG project.
>
> P.
> .
>
I think my overall point is that IPFIX may have completed it's work as 
an NM protocol, but it has significant potential as a collection 
protocol in other applications. If we give the message that it is in 
maintenance or that we have no IETF interest in further development then 
we know what will happen: a new protocol will be needlessly developed 
from scratch.

With that in mind, mild hibernation might be a better approach. We do 
after all have WG in that state.

Paul understands the application application issue, but I am not 
convinced that a single draft developed in isolation somewhere will 
produce an adequate solution.

In terms of global templates, I would think that a global template ID of 
32bits, extensible in 32bit quanta to 128 bits would suffice for a while.

Stewart