Re: Multiple identical Information Elements in a template -> proposed IPFIX text

[Benoit Claise <bclaise@cisco.com>]

Replying to myself with some proposed text for the solution 1...

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.

In section 8 "Template Management", after the following paragraph...

   If a specific Information Element is required by a Template but is 
   not available in observed packets, the Exporting Process MAY choose 
   to export Flow Records without this Information Element in a Data 
   Record defined by a new Template. 

I would add:

   If an Information Element is required more than once in Template,
   the different occurrences of this Information Element SHOULD follow
   the logical order of their treatments by the Metering Process.
   For example, if a selected packet goes through two hash functions,
   and if the two hash values are sent within a single template, the 
   first occurrence of the hash value should belong to the first hash
   function in the Metering Process. For example, when exporting the 
   two source IP addresses of an IPv4 in IPv4 packets, the first 
   sourceIPv4Address Information Element occurrence should be the IPv4
   address of the outer header, while the second occurrence should be 
   the inner header one.

In section 9 "The Collecting Process's Side", at the very end, I would add:

     The Collector MUST support the use of Templates containing multiple occurrences of
     the similar Information Elements.

Note: this text should solve the section 3.1.2.1 
"Multiple IE of same field type" open issue in draft-boschi-ipfix-implementation-guidelines-00.txt 

Regards, Benoit.

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.