[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