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

From: Benoit Claise <[email-masked]>
Date: Wed, 01 Apr 2009 12:38:53 +0200

Gerhard,

Thank you very much for the nice feedback on the draft.
See inline.
> 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
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   
Good catch. Will be added in the next version.
>    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 ;)
>   
Maybe. In section 5.2, we mentioned:

      Therefore, a Structured Data Information Element could be used as 
      scope in an Options Template Set.  However, in practice, the 
      authors don't see an immediate business case for such a case. 

In the case of selectionSequenceId, the selectionSequenceId is a unique Id.
We're thinking: do we need a list in the scope field?
>
> 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.
>   
We'll tried to.
>
> I would appreciate if the above issues were addressed in a future
> version of your draft!
>
>
> Further comments:
>   
All editorial changes have been inserted already.

Thanks again.

Regards, Benoit.
>   
>>      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:
>   
>> 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.
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipfix
>>     
>
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 01 Apr 2009 12:44:49 +0200

Kobayashi-san,

Due to the lack of time, we focused just on a few examples, with the IPS
alert being the most important one.
While we started to receive feedback on this draft, we quickly
understood that it was a mistake to (only) focus on IPS alert, as this
is not a security draft.
We'll address some more examples in the next version. Your examples are
good ones. The best one is the export of performance metrics... from a
mediation function or from the original exporter.

Regards, Benoit.

> 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
>> Chair for Network Architectures and Services (I8)
>> Department of Informatics
>> Technische Universit舩 M〓chen
>> Boltzmannstr. 3, 85748 Garching bei M〓chen, Germany
>> Phone:  +49 89 289-18008       Fax: +49 89 289-18033
>> E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz
>>
>>
>>     
>
> --- 
> Atsushi KOBAYASHI  <[email-masked]>
> NTT Information Sharing Platform Lab.
> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
>

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 01 Apr 2009 13:21:10 +0200

Benoit,

> We're thinking: do we need a list in the scope field?

You are right. Of course, the list of OP identifiers would not appear as
a scope field. I should have read the copied text more carefully ;)

Regards,
Gerhard

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