Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-03

From: Al Morton <[email-masked]>
Date: Fri, 16 Sep 2011 11:42:21 -0400

At 11:22 AM 8/1/2011, Al Morton wrote:
>BMWG,
>CC: IPFIX WG,
>
>This message begins the third WG Last call on the draft:
>
>IP Flow Information Accounting and Export Benchmarking Methodology
>
>A URL for this draft is:
>http://tools.ietf.org/html/draft-ietf-bmwg-ipflow-meth-03

In addition to Paul's comments, I found a few more -
mostly clarifying edits, I think.

Since I have to read every WGLC in case it reaches consensus and
moves to publication-requested, I'm writing these comments as
Al
bmwg chair

1 Introduction, 5 para
     ... Therefore, this document focuses on a
     methodology for how to measure the maximum IP flow rate that a
     network device can sustain without impacting the forwarding plane,
     without losing any IP flow information, and without compromising the
     IP flow accuracy (see section 7 for details).
Suggest:
     ... Therefore, this document specifies a
                                  ^^^^^^^^^^^^
     methodology to measure the maximum IP flow rate that a
     ^^^^^^^^^^^^^^^^^^^^^^

1 Introduction, 7 para
     ... A variety of different network device architectures exist that are
     capable of Flow monitoring and export. As such, this document does
     not attempt to list the various white box variables (CPU load,
     memory utilization, TCAM utilization etc) that could be gathered as ...

TCAM, and all other unusual acronyms, need to be expanded at first use.

 >>> Somewhere, there is a list of acronyms that IETFers need not expand,
     I couldn't find it today, and wonder if anyone knows its location.

2.2.5 Flow Export Rate

    Definition:
       The number of Cache entries that expire from the Cache (as defined
       by the Flow Expiration term) and are exported to the Collector
       within a measurement time interval.

       The measured Flow Export Rate MUST include BOTH the Data Stream
       and the Control Information, as defined in section 2 of [RFC5470].
"BOTH" is not an RFC2119 requirement term, so it can't be capitalized
here as though it is.  You could try:
       The measured Flow Export Rate MUST include *both* the Data Stream

3.  Flow Monitoring Performance Metric
Suggest:
3.  Flow Monitoring Performance Benchmark

(for rationale behind this change, see the comment/text below)

3.3 Measurement Concept, last paragraph:
...
    The Monitoring Plane handles Flows which reflect the analysed
    traffic. The metric that measures the Monitoring Plane performance is
    Flow Export Rate, and the benchmark is the Flow Monitoring
    Throughput.
Suggest:
    ...The metric for Monitoring Plane performance is
                  ^^^
    Flow Export Rate, and the benchmark is the Flow Monitoring
    Throughput.

4.1 Measurement Topology, 1 para

    ...Instead of the Forwarding Plane, these appliances generally
    have some kind of feed (an optical splitter, an interface sniffing
    traffic on a shared media or an internal channel on the DUT providing
    a copy of the traffic) providing the information about the traffic
    necessary for Flow monitoring analysis. The measurement topology then
    needs to be adjusted to the appliance architecture.
Suggest:
                                        ... The measurement topology then
    needs to be adjusted to the appliance architecture, and MUST be
    described in the results.

4.2 Baseline DUT Set Up, 3 para

    The DUT export interface (see figure 2) MUST be configured with
    sufficient output buffers to avoid dropping the Flow Export data due
    to a simple lack of resources in the interface hardware.
Suggest that since the buffer size is critical,
we make it a mandatory part of the results/report.

11.2 Informative References
Add references to the RFCs listed in the Existing Terminology Section.