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

[Benoit Claise <[e-mail]>]

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 <[e-mail]> wrote:
>
>   
>> 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,  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:
>>     
>>> 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: 	[e-mail]
>>> Reply-To: 	[e-mail]
>>> To: 	[e-mail]
>>>
>>>
>>>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>       
>> -- 
>> 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:  [phone]       Fax: [phone]
>> E-mail: [e-mail]    WWW: http://www.net.in.tum.de/~muenz
>>
>>
>>     
>
> --- 
> Atsushi KOBAYASHI  <[e-mail]>
> NTT Information Sharing Platform Lab.
> tel:[phone] fax:[phone]
>