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

Multiple identical Information Elements in a template

Dear all,

During the last PSAMP IETF meeting in Vancouver, we discussed the issue of multiple identical Information Elements in a template.

First of all, [IPFIX-PROTO] doesn't address the issue.
However, we do realize that multiple similar I.E.s are possible in PSAMP
Example 1: in a composite selector, we must export all selector IDs
    [PSAMP-PROTO] specifies:
   If the packets are selected by a Composite Selector, the Associations 
   ID field is composed of several Primitive Selectors. In such a case, 
   the Associations Report Interpretation MUST contain the list of all 
   the Primitive Selector IDs in the Associations ID.

Example 2: a composite selector composed of two hash functions, we might want to export both hash values in the same record.
Example 3: a composite selector, we must export the input sequence number of the primitive selector.
    [PSAMP-PROTO] specifies:
   For each selected packet, the Packet Report MUST contain the 
   following information: 
   ...
   - the input sequence number(s) of any Selectors that acted on the 
   packet   

There are actually 3 solutions to the problem. I classified them in order of my preference
Solution 1:
We try to fix [IPFIX-PROTO]. I think that this is the only right solution. If IPFIX is used to export other information (IPPM? NSIS?), there is a big chance that we will face this issue again.
Let me try to propose some text for this in a next email.

Solution 2:
We overload the I.E.s like we did with the MPLS label: mplsLabelStackEntry2, mplsLabelStackEntry3, mplsLabelStackEntry4, etc...
So we would have selectorId1, selectorId2, selectorId3, selectorId4, etc...
The advantage is that we don't modify [IPFIX-PROTO]. The disadvantage is that we overload the information model.
How many do we need? Which do we need now, as opposed to the future?

Solution 3:
For each occurrence of a PSAMP I.E. that might be duplicated in a PSAMP record, we specify the rule in the [PSAMP-PROTO].
For example, [PSAMP-PROTO] specifies:
   If the packets are selected by a Composite Selector, the Associations 
   ID field is composed of several Primitive Selectors. In such a case, 
   the Associations Report Interpretation MUST contain the list of all 
   the Primitive Selector IDs in the Associations ID.  If multiple 
   Selectors are contained in the Associations Report Interpretation, 
   the Selectors ID MUST be identified in the order they are used.
The advantage is that we don't have to change [IPFIX-PROTO].
The disadvantage is that we put some more PSAMP rules on the top of IPFIX.
What now if IPFIX is used by another protocol (example: NSIS) that requires the extra set of PSAMP rules? Shall we say that the we use the PSAMP protocol and not the IPFIX protocol? This doesn't work too well. I think that we should keep the IPFIX rules in [IPFIX-PROTO]

Feedback?

Regards, Benoit.