Subject: RE: [IPFIX] new work item candidate #4: extended types

From: "Schmoll, Carsten" <[email-masked]>
Date: Tue, 14 Aug 2007 17:33:26 +0200

Dear *,

I think this work item is worth working on to 
bring it finally into a draft. 

The IPFIX collector we have at FOKUS has exactly
the mentioned "problem". It can work with any IEs,
and store them to an SQL database, but Unknown Enterprise 
IEs can only be stored as octet arrays. With type
information we could give the correct column type
to database table columns. That would enable to 
read, analyze and correctly display+graph the collected 
values, e.g. knowing that these are signed 16 bit numbers.

With regard to the draft itself I'd suggest
to define fields closely related to the way that IEs 
are defined in the IPFIX information model now. So
in addition to  

ok >       3.1.  informationElementId . . . . . . . . . . . . . . . . . . .
4
ok >       3.2.  informationElementSemanticType . . . . . . . . . . . . . .
4
ok >       3.4.  privateEnterpriseNumber  . . . . . . . . . . . . . . . . .
6

I'd suggest to add or change

(add)    Name -> informationElementName
(add)    Description -> informationElementDescription : String
(add)    Units -> informationElementUnit  (octec, packets, etc.)
(rename) informationElementStorageType  -> informationElementDataType

I believe most beneficial would be to have the name field,
esp. for an IPFIX collector connected to a database
(it could use it naturally to name the columns for data which are
sent via previously unknown Enterprise IEs).

Dear authors, please let me know what you think about this proposal.
If you agree then I can of course write some small paragraph(s) on 
that in the coming weeks.

With best regards,
Carsten.

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Thursday, July 26, 2007 8:28 AM
> To: [email-masked]
> Subject: [IPFIX] new work item candidate #4: extended types
> 
> Dear all,
> 
> Candidates #4 to become a new IPFIX work item is described by
> draft draft-boschi-ipfix-extended-type-00.txt.
> 
> > 4. Extended Types (Elisa Boschi)
> >    Needed for IPFIX files, most useful for Enterprise IEs; need to
> >    specify what operations make sense for an IE.
> >    Support shown for this as a WG item, as for File Format.
> >    Milestones:  WG LC after IETF 70, to IESG before IETF  71.
> 
> It is a method for assigning data types to unknown IPFIX information
> elements by using option records that map data types to 
> element identifiers.
> 
> It can be applied in cases where an IPFIX collector does not know the
> data type of received information elements. This may in 
> particular happen
> if enterprise specific elements are used. Without this information the
> collector would treat these elements as if they were of type 
> octet array.
> With this information it may be able to treat them more appropriately.
> 
> The current version of the IPFIX file format draft recommends 
> using this
> method when IPFIX records are stored.
> 
> Do you think this is a useful extension of the IPFIX protocol?
> Do you think we should accept this as an IPFIX work item?
> Please have a look at the draft and send your comments.
> 
> Thanks,
> 
>     Juergen
> 
> 
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipfix
> 
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: "Schmoll, Carsten" <[email-masked]>
Date: Tue, 14 Aug 2007 17:33:26 +0200

Dear *,

With best regards,
Carsten.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 14 Aug 2007 17:17:59 -0400

Carsten,

Thanks for your comments and review! Comments inline:

On Aug 14, 2007, at 11:33 AM, Schmoll, Carsten wrote:

> ok >       3.1.   
> informationElementId . . . . . . . . . . . . . . . . . . .
> 4
> ok >       3.2.   
> informationElementSemanticType . . . . . . . . . . . . . .
> 4
> ok >       3.4.   
> privateEnterpriseNumber  . . . . . . . . . . . . . . . . .
> 6
>

We've received similar comments in other reviews. The present plan  
(which is currently partially completed in our working copy of the  
draft, slated for submission early next week) is to provide IPFIX  
Information Elements and associated IANA subregistries for each of  
the runtime-applicable information element properties expressible  
using the XML schema in Appendix B of the IPFIX Information Model  
(thereby making this draft a general method for inline export of an  
information model):

dataType -> informationElementDataType (octet, enumeration)
             (this is presently informationElementStorageType)
dataTypeSemantics -> informationElementSemanticType (octet, enumeration)
name -> informationElementName (string)
description -> informationElementDescription (string)
units -> informationElementUnits (octet, enumeration)*
range -> informationElementRangeBegin (uint64_t) **
      and informationElementRangeEnd (uint64_t)   **

* For the record, these are the units presently supplied in the  
information model and proposed numbers for them:

0x00	(no units)
0x01	bits
0x02	octets
0x03	packets
0x04	flows
0x05	seconds
0x06	milliseconds
0x07	microseconds
0x08	nanoseconds
0x09	4 octet words	(for IHL)
0x0A	messages	(for reliability OT fields)
0x0B	hops		(for TTL)
0x0C	entries		(for MPLS)

If there's anything notably missing from this list, we should address  
it now. We should also make it reasonably easy to add things to the  
IANA subregistry here.

** These will almost always be sent using reduced-length encoding in  
practice.

Also, it's not clear yet whether we want to provide IEs for the  
applicability, status, and group properties; these seem mainly useful  
in producing the IPFIX Information Model document itself.

> sent via previously unknown Enterprise IEs).

That and units do seem to be the two most useful properties not  
enumerated in the present revision, yes.

> that in the coming weeks.

Given that we seem to be thinking the same thing here, we quite like  
your proposal :) -- Contributions are of course always welcome... At  
this point most of the work we're doing on -01 is just finishing the  
enumerations, which is itself mainly just a formatting game played in  
xml2rfc, so it might be best to wait for the next revision at this  
point.

Cheers, and thanks again,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Tue, 14 Aug 2007 17:17:59 -0400

Carsten,

0x00	(no units)
0x01	bits
0x02	octets
0x03	packets
0x04	flows
0x05	seconds
0x06	milliseconds
0x07	microseconds
0x08	nanoseconds

Brian