[IPFIX] updated IPFIX drafts
Paul Aitken <paitken@cisco.com> Fri, 10 January 2014 13:55 UTC
Return-Path: <paitken@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 0FE281AE062 for <ipfix@ietfa.amsl.com>; Fri, 10 Jan 2014 05:55:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level:
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 r6TPteNDhr16 for <ipfix@ietfa.amsl.com>; Fri, 10 Jan 2014 05:55:06 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id E22CE1AE05C for <ipfix@ietf.org>; Fri, 10 Jan 2014 05:55:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4765; q=dns/txt; s=iport; t=1389362096; x=1390571696; h=message-id:date:from:mime-version:to:subject; bh=Vr2sNdaY1Mh3HJbnvHInKpj+NtkHheFuplXE3PpuIQw=; b=iaPostAXtFMr8K2jVfECpXht9JVt9hVkWypbcg1r0iSpC2U+awf6YXW5 8pfps8NAo4Sj+5f30jWIAd8vBYZDFSb2nYH4+/cyhEjxEG/JED45xDpax Hasig3oiweTSKN1/tfoeYRB7W2tYesyGwoU7Xd4AphRVVbJ0QMeutIJWk k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAFb6z1KQ/khM/2dsb2JhbABZgws4uyMWdIMkIB0WGAMCAQIBSw0IAQGIAA2YdqoUF5NGBJgXgTCFFYtQgy0
X-IronPort-AV: E=Sophos;i="4.95,638,1384300800"; d="scan'208,217";a="3446151"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 10 Jan 2014 13:54:55 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0ADsssT005052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipfix@ietf.org>; Fri, 10 Jan 2014 13:54:55 GMT
Received: from [10.61.100.1] (dhcp-10-61-100-1.cisco.com [10.61.100.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0ADsroY022166 for <ipfix@ietf.org>; Fri, 10 Jan 2014 13:54:54 GMT
Message-ID: <52CFFBC8.1020207@cisco.com>
Date: Fri, 10 Jan 2014 13:55:20 +0000
From: Paul Aitken <paitken@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: IETF IPFIX Working Group <ipfix@ietf.org>
Content-Type: multipart/alternative; boundary="------------090205090301040904010808"
Subject: [IPFIX] updated IPFIX drafts
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, 10 Jan 2014 13:55:09 -0000
I updated two drafts during the holidays: http://tools.ietf.org/html/draft-aitken-ipfix-unobserved-fields-02 The IPFIX protocol is designed to export information about observations, and lacks a method for reporting that observations are unavailable. This document discusses several methods for reporting when fields are unavailable, reviews the advantages and disadvantage of each, and recommends methods which should be used. This is a huge hole in IPFIX which we cannot ignore. eg * how can you report that although you observed 1,000 packets, none of them contained an IPv4 source address? * how can you report the 15-minute average in the (t < 15mins) interval ? Cisco is already using several of the techniques in this draft. http://tools.ietf.org/html/draft-aitken-ipfix-equivalent-ies-01 This document specifies a method for an IPFIX Exporting Process to inform an IPFIX Collecting Process of equivalence between different Information Elements, so that the Collecting Process can understand the equivalence and be enabled to process data across a change of Information Elements. This draft provides a mechanism for exporters to migrate from enterprise-specific elements to IANA-standard elements with minimal collector impact. Andrew Feren and I identified a surprisingly large list of existing duplicate Information Elements to which this draft applies, thus the update. P.
- [IPFIX] updated IPFIX drafts Paul Aitken