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
- [IPFIX] Considering the circumstances under which… joel jaeggli
- Re: [IPFIX] Considering the circumstances under w… Wayne Tackabury
- [IPFIX] Winding down the ipfix working group. joel jaeggli
- Re: [IPFIX] Winding down the ipfix working group. Paul Aitken
- Re: [IPFIX] Winding down the ipfix working group. Brian Trammell
- Re: [IPFIX] Winding down the ipfix working group. Romascanu, Dan (Dan)
- Re: [IPFIX] Winding down the ipfix working group. Paul Aitken
- Re: [IPFIX] Winding down the ipfix working group. Brian Trammell
- Re: [IPFIX] Winding down the ipfix working group. Stewart Bryant
- Re: [IPFIX] Winding down the ipfix working group. Andrew Feren
- Re: [IPFIX] Winding down the ipfix working group. Stewart Bryant
- Re: [IPFIX] Winding down the ipfix working group. joel jaeggli
- Re: [IPFIX] Winding down the ipfix working group. Benoit Claise
- Re: [IPFIX] Winding down the ipfix working group. Benoit Claise
- Re: [IPFIX] Winding down the ipfix working group. Paul Aitken
- Re: [IPFIX] Winding down the ipfix working group. Stewart Bryant