RE: [bmwg] New version of "IPv6 Benchmarking Methodology" draft

["Chip Popoviciu \(cpopovic\)" <cpopovic@cisco.com>]

Bill,

Many thanks for the thorough and in-depth review of the document!

We integrated almost all the changes you recommended and they will be
reflected in the next version of the document. Please see a few minor
comments in line <c></c>.

Again, many thanks for your great help with this draft!

Best Regards,
Chip 

-----Original Message-----
From: Bill Cerveny [mailto:bill@wjcerveny.com] 
Sent: Wednesday, October 25, 2006 2:35 PM
To: Chip Popoviciu (cpopovic); bmwg@ietf.org; v6ops@ops.ietf.org
Subject: Re: [bmwg] New version of "IPv6 Benchmarking Methodology" draft

My initial edits on draft-popoviciu-bmwg-ipv6benchmarking-02.txt below. 
I've attached a "diff" file and a file containing these edits.

Bill Cerveny

Section 2. Tests and Results Evaluation

s/Not all these tests/Not all of these tests/

Section 3. 
s/Neighbor Discovery/neighbor discovery/g s/DUT during the duration/DUT
for the duration/ s/test traffic end points, the IPv6 source and
destination addresses/test traffic end points and the IPv6 source and
destination addresses/ (I think this revised grammatical form is correct
although still awkward; the original form is grammatically incorrect)

Text: 
The static option can be used as long as it is supported by the test
tools. The dynamic option is preferred if the test tool interacts with
the DUT during the duration of the test in order to maintain the
respective neighbor caches active. 

First sentence says plural test tools; second says singular test tool.

s/supported by the test tools/supported by the test tool/

Pasted from
<http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-02.
txt> 

s/above described/above/

"above described test scenarios ..." -- Have you described test
scenarios above?

"either static or dynamic Neighbor Discovery can be used" -- perhaps
rephrase as "either static or dynamic options for neighbor discovery can
be used"

"in order to maintain the respective neighbor caches active." suggest
changing to "to maintain the respective neighbor caches in an active
state."

s/Neighbor Advertisement/neighbor advertisement/g s/Neighbor
Solicitation/neighbor solicitation/g s/Neighbor Unreachability
Detection/neighbor unreachability detection/g

<c>We made the similar changes you suggested everywhere else in the doc
but left them as they are here since we introduce the acronyms for these
terms: Neighbor Advertisement (NA), etc. </c>

"These requirements are designed to reflect the characteristics of IPv6
unicast traffic in all its aspects. Using this IPv6 traffic leads to a
complete evaluation of the network element performance."  -- awkward,
but not sure about best way to clarify and say the same thing.


"For all other media types refer to the recommendations of RFC2544."

Maybe change to:

"Refer to recommendations in RFC2544 for all other media types."

"Note that the minimum size of a relevant IPv6 packet (it carries
minimal upper layer information) is larger than that of an IPv4 packet
because the former has a 40-byte header while the latter has a minimum
header of 20 bytes."

Maybe change to:
"Note that the minimum IPv6 packet size (40 bytes) is larger than that
of an IPv4 packet (20 bytes). Tests should compensate for this
difference."

Section 4.1.2:
s/The Packet over SONET (PoS)/Packet over SONET (PoS)/

For this reason it is recommended to evaluate the forwarding performance
of such interfaces supported by the DUT.

Change to:

Evaluating the forwarding performance of PoS interfaces supported by the
DUT is recommended.

Section 4.2.

s/aspects of the IPv6/aspects of IPv6/

Section 4.2.1

s/either one of the following two categories/either of the following/

s/The Interface ID portion of the Global Unicast/The interface ID
portion of global unicast/ -- 

"It is recommended that multiple iterations of the benchmark tests be
conducted using the following prefix lengths: 32, 48, 64, 126 and 128."
-- this doesn't seem clear to me. Where are these iterations of prefix
lengths used? On all "subnets", including interface links?

<c>I agree, it was unclear. Here is the re-written sentence:

It is recommended that multiple iterations of the benchmark tests be
conducted using the following 
   lengths: 32, 48, 64, 126 and 128 for the advertised traffic
destination prefix. 

</c>

%s/Interface/interface/g
%s/Link Local/link local/g
%s/Router Advertisement/router advertisement/g

What does 50% jitter mean?  If using an IETF RFC definition, reference
it.

s/The IPv6 source and destination addresses SHOULD appear not/The IPv6
source and destination addresses SHOULD not appear/

Section 4.3
s/Extension Headers/Extension headers/

s/Fragmented traffic, Mobile IP based traffic, Authenticated and
Encrypted traffic/Fragmented traffic, mobile IP based traffic,
authenticated and encrypted traffic/

s/traffic that has no EH/traffic that have no EH/

<c>since we refer to traffic and not packets, doesn't "has" apply better
than "have"?</c>

s/Hop-by-Hop/hop-by-hop/g
s/Destination Options header/Destination options header/g
s/Encapsulating Security Payload/Encapsulating security payload/g

NDR not defined

<c>Very good observation, changed to throughput and referenced 2544.
</c>

Inconsistency in way that plural extension headers are referenced - EH
or EHs

s/The device resources/Device resources/

Second half of below sentence incorrect or awkward:

The tests with traffic containing each EH individually MUST be
complemented with tests that contain a chain of two or more EH, chain
not containing the Hop-by-Hop EH.

<c> Changed to:

The tests with traffic containing each individual EH MUST be
complemented with tests that
    contain a chain of two or more EH (the chain MUST not contain the
Hop-by-hop EH). 

</c>

s/These extension headers/Extension headers/ -- isn't this a
characteristic of all extension headers, not just the ones listed?

<c>Correct.</c>

s/Their presence will modify the minimum size used in testing./Their
presence will modify the minimum packet size used in testing./

s/Broadcast Frames/broadcast frames/g

s/IPv6 Management and Routing Update Frames/IPv6 management and routing
update frames/

s/Source Addresses/source addresses/g
s/Destination Addresses/destination addresses/g

<c>We are using capital letters just to show the correlation with the
acronyms (SA, DA).</c>

Clarify that correct DUT filtering behavior must be verified

Section 8.
s/Special capabilities SHOULD NOT exit/Special capabilities SHOULD NOT
exist/

Section 10. 

s/Cherveny/Cerveny/ :-)

<c>Appologies for this! :) Fixed!</c>


On Sat, 14 Oct 2006 18:23:12 -0400, "Chip Popoviciu (cpopovic)"
<cpopovic@cisco.com> said:
> Dear BMWG and v6ops WG members,
>  
> We posted a new version of the IPv6 Benchmarking Methodology draft:
>  
> http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-02
> .t
> xt
>  
> This draft has the following major changes with respect to the 
> previous
> rev:
> - Includes recommendations for benchmarking with traffic that has the 
> Hop-by-Hop Extension Header (as suggested by v6ops and BMWG)
> - Updated frame size recommendations for Ethernet to include Jumbo 
> frames (Appendix updated to include line rates values for all frame
> sizes)
> - Proposal for IPv6 benchmarking prefix assignment by IANA
> - The Security section contains the new standard text discussed within

> BMWG This version also includes many editorial changes suggested by 
> the reviewers.
>  
> Any feedback, comment or advice would be most welcomed.
>  
> Best Regards,
> Ciprian Popoviciu for the authors of this draft