Subject: [IPFIX] Semantic and structured data

From: Gerhard Muenz <[email-masked]>
Date: Sun, 08 Nov 2009 22:16:21 +0100

Dear all,

Regarding draft-ietf-ipfix-structured-data, I see the risk that the
semantic of the exported structured data is not clear.

How do you interpret the manifold occurrence of the same Information
Element (basicList) or the same group of Information Elements
(subTemplateList) in one record?

What does it mean if basicList, subTemplateList, or subTemplateMultiList
is used for a Flow Key field? Or non-key field?

Some Examples:

- BasicList of egress interfaces in a Flow Record
  How should a Flow Record be interpreted which contains a list of
  egress interfaces and a packet counter?
  Has every counted packet been sent on every egress interface?
    => multicast case, AND semantic (see example in section 8.1)
  Has every counted packet been sent on any one of the egress
  interfaces?
    => load balancing case, OR semantic
  Can it be used as a Flow Key or not?

- BasicList of destination ports in a Flow Record
  As every packet has only one destination port, the only reasonable
  interpretation is that the Flow contains packets having one of
  the reported port numbers.
    => OR semantic
  This would be a non-key field.

I think there are two solutions:

1. We decide that the semantic of list content is out of scope of
   draft-ietf-ipfix-structured-data. We add a note to the draft that
   the semantic must be clear from the context or the definition of the
   Information Elements used within the lists.

2. We define semantic lists, such as
   - andBasicList, andSubTemplateList, andSubTemplateMultiList
   - orBasicList, orSubTemplateList, orSubTempalteMultiList
   describing AND and OR semantic of the contained IEs/Templates,
   respectively.

As I wrote in an earlier mail, I see a good use case for orBasicList. It
could be used in the Selector Report Interpretation of Property Match
Filtering to report a filter like "port 80 or port 443".
http://www.ietf.org/mail-archive/web/ipfix/current/msg04856.html
At the moment, the Selector Report Interpretation is limited to AND.
However, if we also want to express a NOT, we still need another solution...

Regards,
Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Tue, 10 Nov 2009 06:26:49 +0100

Gerhard,

Thanks for your email.
I have no strong feelings about the two solutions you proposed.

 From a pure router point of view,  I don't see any use cases for 
logical OR in exporting flow records.
However, from a IPFIX Mediator point of view, I see some use cases.
I mean that it requires an Intermediate Aggregation Process or 
Intermediate Correlation Process to express: I've seen this flow record 
OR that flow record.
Now, it's true that even routers will have mediation functions...

I'm inclined to add orBasicList, orSubTemplateList, 
orSubTempalteMultiList to the draft (This is a small addition after all) 
and to express that, by default, a logical AND is assumed... 
specifically if the structured data is used in the IPFIX Mediation Protocol.

I'm not convinced by the NOT in the context of structured data, as we 
don't even have a concept of NOT for a single information element!

I would like to get some more feedback from others.

Regards, Benoit.

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

---

From: Brian Trammell <[email-masked]>
Date: Tue, 10 Nov 2009 13:08:21 +0100

hi Benoit, Gerhard,

In this case I'm strongly in favor of leaving semantics out of  
structured data. Structured data defines containers. The semantics of  
the containers as a whole and the elements change based upon the  
information elements within the container and within the record  
containing it. Wedging semantics into the structured data elements 1.  
risks further proliferation of (potentially non-interoperable) ways to  
represent the same thing, 2. gives us more ways to represent  
nonsensical things (an OR basicList of MPLS stack  
entries...means...what?), and 3. risks defining an inadequate semantic  
representation mechanism (what about semantics for records not using  
structured data? what about ordered versus unordered sets? what about  
OR basicList vs AND basicList vs nested AND and OR basicLists vs just  
three identical IEs?). If we really want an unambiguous semantic  
framework for IPFIX (and here I'm not convinced either way) that's  
best done on its own, addressing things at the information element and  
record level. Doing it here confuses the issue.

Regards,

Brian

On Nov 10, 2009, at 6:26 AM, Benoit Claise wrote:

> Intermediate Correlation Process to express: I've seen this flow  
> record OR that flow record.
> orSubTempalteMultiList to the draft (This is a small addition after  
> all) and to express that, by default, a logical AND is assumed...  
> I'm not convinced by the NOT in the context of structured data, as  
> we don't even have a concept of NOT for a single information element!
>