Re: [IPFIX] unobserved fields

Brian Trammell <trammell@tik.ee.ethz.ch> Mon, 10 December 2012 10:21 UTC

Return-Path: <trammell@tik.ee.ethz.ch>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F91021F8E5E for <ipfix@ietfa.amsl.com>; Mon, 10 Dec 2012 02:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieQaAA6Go+hI for <ipfix@ietfa.amsl.com>; Mon, 10 Dec 2012 02:21:26 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 97DF121F8E57 for <ipfix@ietf.org>; Mon, 10 Dec 2012 02:21:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 59763D9304; Mon, 10 Dec 2012 11:21:22 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qULxNAJKC-Vw; Mon, 10 Dec 2012 11:21:22 +0100 (MET)
Received: from [192.168.0.79] (unknown [195.101.98.59]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 372BED930B; Mon, 10 Dec 2012 11:21:10 +0100 (MET)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Brian Trammell <trammell@tik.ee.ethz.ch>
In-Reply-To: <50C5B121.1080007@cisco.com>
Date: Mon, 10 Dec 2012 11:21:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8560F8F8-9EC3-4D0E-A3C0-14192CE04F61@tik.ee.ethz.ch>
References: <50C2314C.20300@plixer.com> <50C23D17.3030503@cisco.com> <88D44B6F-F10C-47FD-947C-A9171AD7F127@tik.ee.ethz.ch> <50C4D203.3090204@cisco.com> <7F3700A3-0562-47B0-8BEC-394951179E8C@tik.ee.ethz.ch> <50C5B121.1080007@cisco.com>
To: Paul Aitken <paitken@cisco.com>
X-Mailer: Apple Mail (2.1499)
Cc: IETF IPFIX Working Group <ipfix@ietf.org>
Subject: Re: [IPFIX] unobserved fields
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 10 Dec 2012 10:21:27 -0000

On 10 Dec 2012, at 10:53, Paul Aitken <paitken@cisco.com> wrote:

> Brian,
> 
>> Ahhhh -- okay, so you'd be proposing using an indexing mechanism, as with MIB objects, to explicitly link one IE in a record with another to allow the "observation index" IE to expose the observation state of each IE?
> 
> No. There's only one IE.

Ah. Okay. Got it. I'd missed something in my reading of the MIB draft, then (or, rather, I'd paid the most attention to the IE-index-based indexing, which looks the "most IPFIXish", to me anyway, and sort of assumed the others looked the same...)

> In MIB export, the template effectively says "here is a MIB, with two extensions; the first defines the OID (in the template); the second defines the index (in the data records)". Appropriate sizes are given, and the template and data records are extended accordingly. So instead of getting a 4-byte value in the data record, there might be 6 bytes: the 4 bytes value followed by a 2-bytes index. However the index has no IE of its own, so each new extension does not require a new IE.
> 
> In the unobserved fields scenario, the template would says "here is an IE, with an extension (in the data records)", and that extension would indicate the observability of the IE. So instead of 4 bytes of RTT time, there might be 5 bytes: 4 bytes of RTT (being zero, presumably), and 1 byte reporting "insufficient time".

thinking aloud... so, the "insufficient time" not-IE is an entry in a registry of "in-record IE decorator", like MIB index; there's an extension for "in-record IE decorator" which points to this registry entry; presumably, this decorator is "generic" enough to apply to most or all IEs? (actually, I'd call it just "insufficient data"; maybe it makes sense to combine this with other flags for per-record attributes, for the sake of efficiency...)

>> I think an example illustrating this -- how MIB-style EFS would support -unobserved-fields -- in the next rev of -unobserved-fields would be very useful.
> 
> Are MIBS ever unobserved?

I'm not enough of an SMI geek to answer that question. I'd seen MIB export as simply another source of information elements, so would ask "why not?" but there may be reasons why not that I don't appreciate.

(we've agreed to agree on the rest of the points, so <snip>)

Cheers,

Brian