Re: [bmwg] comments on draft-novak-bmwg-ipflow-meth-04

[Al Morton <acmorton at att.com>]

At 05:39 PM 10/23/2009, Al Morton wrote:
> Hi Jan and Benoit,
>
> I have a few comments and suggestions on your draft, below.
>
> Al (as a participant)
>
> ============================================================================
> ...
> (stopping at the end of 3.4 for now)

4.1 Test Topology
...
   In the test topology with bidirectional traffic (Figure 3), the
   sender and receiver are basically on the same device, which generates
   the traffic to be sent through the DUT, and received back once it
   reaches the ?END?.

Bidirectional Traffic?  I don't remember seeing this in earlier
BMWG testing...

<skipped stuff>

7. Flow Monitoring Accuracy

   The pure Flow monitoring tests in section 5 provide the capability to
   verify the Flow monitoring accuracy in terms of the exported Flow
   Record data. Since every Flow Record created in the Cache is
   populated by just one packet, the full set of captured data on the
   Collector can be parsed (e.g. providing the exported Flow Record
   contents not only the Flow Record count) and each set of parameters
suggestion (if correct):
   ...(e.g. providing the exported Flow Record
   contains info beyond the Flow Record count)
   ^^^^^^^^^^^^^^^^^^^^
...
    The exported Flow Record is considered accurate if:

      a. all the Flow Record fields are present in each exported Flow
         Record
      b. all the Flow Record fields values match the value ranges
         as set by the traffic generator (for example an IP address
         falls within the range of the IP addresses increments on the
         traffic generator)
      c. all the possible Flow Record fields values as defined at the
         traffic generator have been found in the captured export data
         on the Collector. This check needs to be offset to potential
         detected packet losses at the DUT during the test

   If Packet Sampling is deployed then only verifications in point 1
   and 2 can be performed.

I think you meant a. and b. above.


8. Evaluating Flow Monitoring Applicability
...
   It needs to be kept in mind that the above is a very rough and
   averaged Flow activity estimate which cannot account for traffic
   anomalies like large number of for example DNS request packets which
   are typically small packets coming from many different sources and
   represent mostly just one packet Flow.
comment:
Models of Live Traffic have the goal of realism, but also raise
questions as to the meaning of the results...

9. Miscellaneous Tests

   This section lists the tests which could be useful to asses a proper
   Flow monitoring operation under various operational or stress
   conditions. These tests are not deemed suitable for any benchmarking
   for various reasons.
comment:
Then this should probably be an Appendix.

12. Security Considerations
Thanks for using the "standard" text here.