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

[Atsushi Kobayashi <[e-mail]>]

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]