Subject: [IPFIX] [Fwd: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt]

From: Benoit Claise <[email-masked]>
Date: Wed, 04 Mar 2009 09:14:57 +0100

Dear all,

Here is a new IPFIX draft.
I think that the abstract is quite clear about its goal.

Regards, Benoit.

-------- Original Message --------
Subject: 	I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt
Date: 	Tue, 3 Mar 2009 15:15:01 -0800 (PST)
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Export of Structured Data in IPFIX
	Author(s)	: B. Claise, G. Dhandapani, S. Yates, P. Aitken
	Filename	: draft-claise-structured-data-in-ipfix-00.txt
	Pages		: 36
	Date		: 2009-3-3
	
        This document specifies an extension to IP Flow Information 
        eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 
        information model specified in [RFC5102] to support hierarchical 
        structured data and lists (sequences) of Information Elements in 
        data records.  This extension allows definition of complex data 
        structures such as variable-length lists and specification of 
        hierarchical containment relationships between Templates. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-claise-structured-data-in-ipfix-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 23 Mar 2009 13:57:58 +0100

Hi Benoit, Gowri, Stan, Paul,

I like your approach of structured data types. Such types, especially
the list type, are urgently needed in the context of PSAMP!
Interestingly, you do not mention these applications in the draft. So,
I'll briefly sketch them:

1) PSAMP Selection Sequence Report Interpretation
-------------------------------------------------

Here, RFC5476 explicitly mentions the need for list types:

   Scope:     selectionSequenceId
   Non-Scope: one Information Element mapping the Observation Point
              selectorId (one or more)

   An Information Element representing the Observation Point would
   typically be taken from the ingressInterface, egressInterface,
   lineCardId, exporterIPv4Address, or exporterIPv6Address Information
   Elements (specified in [RFC5102]), but is not limited to those: any
   Information Element specified in [RFC5102] or [RFC5477] can
   potentially be used.  In case of more complex Observation Points
   (such as a list of interfaces, a bus, etc.), a new Information
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Element describing the new type of Observation Point must be
   specified, along with an Options Template Record describing it in
   more detail (if necessary).

In fact, this is the business case that you pretend not to see for
Options Templates in 5.2 of your draft ;)

2) PSAMP Property Match Filtering
---------------------------------

From RFC75476:

   When multiple different Information Elements are defined, the filter
   acts as a logical AND.  Note that the logical OR is not covered by
   these PSAMP specifications.

In practice, a logical OR is urgently needed. See my recent discussion
with Andrew on the ML:
http://www.ietf.org/mail-archive/web/ipfix/current/msg04802.html

In draft-sommer-ipfix-mediator-ext-01, we proposed ADTs orderedList,
orderedPair, and portRanges which allow the definition new IEs for port
ranges etc. Your proposal is more generic as it does not require the
specification of a new IE for every purpose where a list is needed.

The OR-semantic of a filter could be solved with a new Information
Element anyList which is derived from the ADT basicList. In contrast to
IE basicList, anyList introduces the semantic that exactly one of the
reported values was observed. As a consequence, we can export an anyList
of port numbers in Property Match Filtering in order to describe a
filter that selects packets given a list of port numbers.

I would appreciate if the above issues were addressed in a future
version of your draft!

Further comments:

>      3.1. IPFIX Limitations 
> ...
>       To export this information in IPFIX, the data would need to be 
>       flattened (thus losing the hierarchical relationships) and a new 
>       IPFIX Template created for each alert, according to the number of 
>       applicationID elements in each target, the number of targets and 
>       attackers in each participant and the number of participants in 
>       each alert.  Clearly each Template will be unique to each alert, 
>       and a large amount of CPU, memory and export bandwith will be 

bandwidth

>       wasted creating, exporting, maintaining, and withdrawing the 
>       Templates.  

>      4.4.1. basicList 
> ...
>        BasicList Content
>        
>           A Collection Process decodes list elements from the BasicList 
>           Content until no further data remains.  A record count is not 
>           included but can be derived when the Information Element is 
>           decoded. 

Replace record count by field count?

>      5.2. Structured Data Information Elements Applicability in Options 
>         Template Sets 
> 
>       All the examples in this document uses the Structured Data 

use

>       Information Elements, abstract data types, and data type semantic 
>       in Template Sets.  However, they could also be used in and Options 

remove "and"

>       Template Sets. 

>     8.1. Encoding BasicList 
> 
>       Consider encoding an user_record containing the following data: 

a user_record

Regards,
Gerhard

Benoit Claise wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Atsushi Kobayashi <[email-masked]>
Date: Mon, 23 Mar 2009 23:00:01 +0900

Dear Gerhard, Benoit, Gowri, Stan, Paul,

Gerhard, good point. I hope logical OR.

I think BasicList also allows to encode the egress interface indexes of
multicast packets/flows, and the BGP communities of specific destination
IP address. Even AS path can be encoded in a Flow Records. 

It can be considered more sophisticated way than traditional one. I hope
that the examples about Flow Records in the draft are rich to be easy to
understand.

And also, in QoS performance measurement, Exporter or Mediator creates
some metrics every 1 or 2 seconds, so they need to export data record
every 1 or 2 seconds. BasicList allows to encode metrics list during
some periods, such as 60 sec. It can reduce redundancy.

Regards,
Atsushi KOBAYASHI

On Mon, 23 Mar 2009 13:57:58 +0100
Gerhard Muenz <[email-masked]> wrote:

> In practice,  is urgently needed. See my recent discussion
> with Andrew on the ML:
> Dipl.-Ing. Gerhard M〓z
> Technische Universit舩 M〓chen
> Boltzmannstr. 3, 85748 Garching bei M〓chen, Germany

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637