Re: [bmwg] feedback on draft-ietf-bmwg-ipflow-meth-05

["Jan Novak (janovak)" <[e-mail]>]

Hi Paul,

Thank you for your text suggestions and language
corrections - these are always particularly valuable.

I will address your comments in the next submitted
draft version.

Jan

The climate of Edinburgh is such that the weak succumb young .... 
and the strong envy them.
                                 Dr. Johnson



-----Original Message-----
From: Paul Aitken (paitken) 
Sent: 16 January 2012 21:27
To: Jan Novak (janovak)
Cc: Al Morton
Subject: feedback on draft-ietf-bmwg-ipflow-meth-05

Jan,

I've finally been able to review the latest version of the draft.

I apologise that it's taken so long. Although it's late, hopefully this 
is still useful for the WGLC which ended Jan 1st.

What few comments I have are minor. I think the draft should progress 
swiftly now.

I'm sure Al would like to see these comments on the WG mailing list. 
I'll wait for your feedback.

Thanks,
P.

> Internet Engineering Task Force                      Jan Novak
> Internet-Draft                                       Cisco Systems,
Inc.
> Intended status: Informational
> Expires: 7 June, 2012                                    6 December
2011
>
>           IP Flow Information Accounting and Export Benchmarking
>                                 Methodology
>                    draft-ietf-bmwg-ipflow-meth-05.txt
>
> Abstract
>
>     This document provides a methodology and framework for quantifying
>     the performance impact of monitoring of IP flows on a network
device
>     and export of this information to a collector. It identifies the
rate
>     at which the IP flows are created, expired, and successfully
exported
>     as a new performance metric in combination with traditional
>     throughput. The metric is only applicable to the devices compliant
>     with the Architecture for IP Flow Information Export [RFC5470].
>
> 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. There SHOULD NOT be any
export
>        filtering, so that all the expired cache entries are exported.
If
>        there is export filtering and it can't be disabled, this needs
to
>        be noted.
>
>        The measured Flow Export Rate MUST include *both* the Data
Stream

=====
PA
=====
I don't think you can add emphasis like this "*both*" in an RFC.


> 4.3 Flow Monitoring Configuration
>
>     This section covers all the aspects of the Flow monitoring
>     configuration necessary on the DUT in order to perform the Flow
>     monitoring performance measurement. The necessary configuration
has
>     a number of components (see [RFC5470]), namely Observation Points,
>     Metering Process and Exporting Process as detailed below.
>
>     The DUT MUST support the Flow monitoring architecture as specified
by
>     [RFC5470]. The DUT SHOULD support IPFIX [RFC5101] to allow easier
>     results comparison due to identical export protocol architecture
when
>     using a standard.

=====
PA
=====
Different DUTs may contain different partial IPFIX implementations, even

while claiming full IPFIX compatibility.

So I suggest, "The DUT SHOULD support IPFIX [RFC5101] to allow 
meaningful results comparison due to the standard export protocol."


>     The DUT configuration and any existing Cache MUST be erased before
>     application of any new configuration for the currently executed
>     measurement.
>
>     4.3.2 Metering Process
>
>        The Metering Process MUST be enabled in order to create the
Cache
>        in the DUT and configure the Cache related parameters.
>
>        The Cache Size available to the DUT MUST be known and taken
into
>        account when designing the measurement as specified in section
5.
>
>        The configuration of the Metering Process MUST be reported. For

=====
PA
=====

s/reported/recorded/ ?


>        example, when a Flow monitoring implementation uses timeouts to
>        expire entries from the Cache, the Cache's Inactive and Active
>        Timeouts MUST be known and taken into account when designing
the
>        measurement as specified in section 5. If the Flow monitoring
>        implementation allows only timeouts equal zero (e.g. immediate

=====
PA
=====
"equal to zero".


>        timeout or non-existent Cache) then the measurement conditions
in
>        the section 5 are fulfilled inherently without any additional

=====
PA
=====
s/the section 5/section 5/


>        configuration. The DUT simply exports information about every
>        packet immediately.

=====
PA
=====
Assuming there's no input or export sampling. eg, say "subject to the 
Flow Export Rate definition in section 2.2.5 and the assumptions about 
sampling in section 4.5.".

Or indeed, the second paragraph of 4.3.3 just below is sufficient - so 
you could say, "subject to the Exporting Process details below".


>        If the Flow monitoring implementation allows to configure
multiple

=====
PA
=====
s/allows to configure/allows configuration of/


>        Metering Processes on a single DUT, the exact configuration of
>        each process MUST be included in the results report. Only
>        measurements with the same number of Metering Processes can be
>        compared.
>
>        The Cache Size, the Inactive and Active Timeouts MUST be
included
>        as part of the results report.
> Novak                                                    Expires June,
2012
>                                 [Page 12]
> Internet-Draft        Flow Monitoring Benchmarking        December
2011

>
>        The Exporting Process SHOULD be configured with IPFIX [RFC5101]
as
>        the protocol to use to format the Flow Export data. If the Flow
>        monitoring implementation does not support it, proprietary

=====
PA
=====
s/support it/support IPFIX/


>        protocols MAY be used. Only measurements with same export
protocol
>        SHOULD be compared since the protocols may differ in their
>        export efficiency.

=====
PA
=====
Even identical protocols may use different IPFIX or NFv9 templates.

eg, there was a draft a few years ago which suggested that different 
field orders in the exported templates were more or less efficient.

So consider noting that only exports using identical templates should be

compared - if that's not too restrictive?
ie, if templates can't be configured or the field order is fixed, then 
that should be noted and the different field orderings recorded.


>        Various Flow monitoring implementations might use different
>        default values regarding the export of Control Information
>        [RFC5470] and therefore Flow Export corresponding to Control
>        Information SHOULD be analyzed and reported as a separate item
on
>        the measurement report. Preferably, the export of Control
>        Information SHOULD always be configured consistently across all
>        testing and configured to the minimal possible value - ideally
>        just one exported set of Control Information during each
>        measurement. Note that Control Information includes IPFIX
Options
> 4.4 Collector
>
>     The Collector is needed in order to capture the Flow Export data
>     which allows the Flow Monitoring Throughput to be measured.
>
>     The Collector can be used as exclusively capture device providing
>     just hexadecimal format of the Flow Export data. In such a case it
>     does not need to have any additional Flow Export decoding
>     capabilities and all the decoding is done off line.
>
>     However if the Collector is also used to decode the Flow Export
data
>     then it SHOULD support IPFIX [RFC5101] for easier results
analysis.

=====
PA
=====
I don't think that using IPFIX makes the analysis any easier. However, 
it probably makes the results more meaningful since implementations 
should be following the same standard.

So I'd say "for meaningful results analysis."


>     If proprietary Flow Export is deployed, the Collector MUST support
it
>     otherwise the Flow Export data analysis is not possible.
>
>     The Collector MUST be capable of capturing at the full rate the
>     Active Timeout
>        Active Timeout is set (if configurable) to a value equal to or
>        higher than the Inactive Timeout. It MUST be known in order to
>        define the measurement circumstances completely and equally
>        across implementations.
>
>     Flow Keys Definition:
>        The test needs large numbers of unique Cache entries to be
created
>        by incrementing values of one or several Flow Keys. The number
of
>        unique combinations of Flow Keys values SHOULD be several times
>        larger than the DUT Cache Size. This makes sure that any
incoming
>        packet will never refresh any already existing Cache entry.
>
>     The availability of Cache Size, Inactive Timeout, Active Timeout
as
>     configuration parameters is implementation specific. If the Flow
>     monitoring implementation does not support it, the test
possibilities

=====
PA
=====
s/not support it/not support these parameters/


>     as specified by this document are restricted. Some testing might
be
>     viable if the implementation follows the [IPFIX-CONFIG] document
and
>     needs to be considered on the case by case basis.
>
> 5.2 Traffic Configuration
>
>     Traffic Generation
>        The traffic generator needs to increment the Flow Keys values
with
>        each sent packet, this way each packet represents one Cache
entry
>        in the DUT Cache.
>