[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IPFIX] Semantic and structured data



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