[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.