Re: [IPFIX] unobserved fields

Brian,

> On 10 Dec 2012, at 10:53, Paul Aitken <[email protected]> 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...)

Yes, there's a 16-bit type field in the EFS which specifies what the 
field attribute is (eg, OID, index, unobserved, ...). Actually I've been 
wonder whether there are any EFS which require data in both the template 
and the data record; if not then the topmost type bit could indicate 
this, so there'd only need to be one length field (rather than one for 
template info + one for data record info).

Since the "unobserved" field needs to be at least 8 bits (since IPFIX 
deals with bytes rather than bits), we can run to 255 "unobserved" 
reasons (plus zero for "observed").
So although we could start with just a few generic reasons, we can 
afford to call out exactly why no data was available. eg, "insufficient" 
could be due to insufficient time (eg, RTT or 1-minute average) or 
insufficient data (eg, average / mean).


P.


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

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix