Benoit,Regarding multiple identical information elements, you proposed the following a couple of months ago:
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 ofthe 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.
I'm probably a bit late to the party on this, but yes, this seems exactly the right thing to do for IPFIX version 0x000A. However, I think we should be more explicit about the semantics implied by this approach, and more restrictive on the applicability of multiple information elements in order to avoid any grey areas that might be used by implementors to overload multiple IE support in mutually unintelligible ways.
Specifically, in investigating whether multiple information elements would be applicable for biflows -- exporting a forward direction counter in the first counter IE and a reverse direction counter in the second counter IE -- I realized you could argue that, because the reverse counters are related to the "second" direction seen at the Metering Process, you could use two IEs (say, octetTotalCount), have the first be the forward counter, the second be the reverse counter, and dispense with having to define any new information elements.
However, what would the limits be on this approach? Say I wanted to export forward and reverse non-key header fields, say, tcpSequenceNumber. Would this conflict with a Collecting Process expecting to receive data about some sort of (admittedly ill-advised) TCP-in-TCP tunneling scheme?
At this point I realized that overloading multiple IE support for the biflow case is probably not the right thing to do, at least with multiple IE support expressed as above. However, the language in the protocol document should make it explicit that only certain semantics are currently permitted with multiple identical information elements.
(As an aside, note that as this example is written, it _does_ obviate the need for all but one of the mplsLabelStackEntry IEs, since the label stack is "unwrapped" by the Metering Process in a defined order.)
Regards, Brian
Attachment:
PGP.sig
Description: This is a digitally signed message part