Subject: [ipfix] Date: Thu, 11 May 2006 09:48:42 -0400

From: Brian Trammell <[email-masked]>
Date: Thu, 11 May 2006 08:50:04 -0500

All,

draft-trammell-ipfix-biflow-01 proposes single record biflows (see
section 5) as an efficient method for the export of bidirectional
flow data. This method is motivated by a desire to increase overall
collection efficiency in measurement infrastructures wherein biflow
assembly can be pushed to the Metering Process edge, and by a need to
have a strong link in the data between directions of a biflow.

However, this method requires the allocation of "reverse" information
elements to represent data from the additional direction in each
biflow. Revision -01 of the biflow draft proposes two possible
allocation policies for these IEs, but leaves the choice between them
as an open issue.

Briefly, the two policies outlined in the draft are:

1. Direct allocation of reverse information elements - adding between
150 and 200 information elements to the information model, as was
done with the post* IEs, but on a larger scale.

2. Allocation of a single private enterprise number (PEN) to signify
"reverse". Information elements within this private space would be
equivalent to their counterparts in IETF/IANA-allocated IE space,
except that they would apply to the reverse direction of the flow.
For example, octetTotalCount has IE number 85; reverseOctetTotalCount
would then be assigned IE number 85 within this private space.

See the -01 revision of the biflow draft for details.

On further review, we are proposing that reverse information elements
be assigned by the second policy. We are continuing our dialogue with
IANA and have no reason to believe an enterprise number could not be
assigned for this purpose.

Our motivation behind this proposal is as follows:

1. The first policy presents a difficult management problem. The
relationship between forward and reverse direction information
elements would have to be maintained over time; as new IEs are added
to the IANA registry, someone would have to evaluate whether the new
IE has a sensical reverse direction, and if so, add the reverse
direction as well. This adds management overhead to a process that is
not yet well-defined itself, and it is unclear who would take on the
task.

2. The first policy effectively reduces future expansion of the IANA
registered IE space by half.

3. The second policy is much more flexible. The management problem  
outlined
is solved by "dimensioning" the information element space -
any future addition to the IANA-managed IE space automatically gains its
reverse counterpart. If a future revision of the IPFIX protocol has a
dimensioned IE space, as has been suggested within the WG from time to
time over the past year, the second policy is more compatible with the
future direction of the protocol.

We'd like to hear the working group's comments on this proposed
selection of policy; we're prepared to incorporate this commentary
and address all other outstanding open issues in the document in a
new revision for Montreal.

Regards,

Brian