Re: [bmwg] I-D Action: draft-ietf-bmwg-ipv6-nd-03.txt

Hi Ron, Bill, and Reji,

Thanks for preparing your updated draft.
Below find some comments and suggestions on
your latest version.

regards,
Al
(as a participant)

Section 1., paragraph 2:
OLD:

    o  Identify the IPv6 next-hop (i.e., the next IPv6 node that the
       packet traverses on route to its ultimate destination)

NEW:

    o  Identify the IPv6 next-hop (i.e., the next IPv6 node that the
 |      packet should traverse on route to its ultimate destination)

Section 1., paragraph 14:
OLD:

    The test procedures described herein assume that on the DUT, NDP does
    not compete for resources with other applications.  When NDP
    completes for resources, its scaling characteristics may not be
    commensurate with those reported by the benchmarks described herein.

NEW:

    The test procedures described herein assume that on the DUT, NDP does
    not compete for resources with other applications.  When NDP
 |  completes for resources, its scaling characteristics may differ
 |  from those reported by the benchmarks described, and may vary over time.

Section 2.1.1., paragraph 1:
OLD:

    DUT interfaces are numbered as follows:

    o  Link A - 2001:2:0:0::2/64

NEW:

    DUT interfaces are numbered as follows:
 [ACM] These addresses should be from the BMWG address block.
    o  Link A - 2001:2:0:0::2/64

Section 2.2.1., paragraph 1:
OLD:

    Interfaces are numbered as follows:

    o  Link A - 2001:2:0:0::1/64

NEW:

    Interfaces are numbered as follows:
 [ACM] These addresses should be from the BMWG address block.
    o  Link A - 2001:2:0:0::1/64

Section 2.2.4., paragraph 1:
OLD:

    The Tester sends a stream test traffic through Link A to the DUT.
    The test traffic stream contains one or more interleaved flows.
    Flows are numbered 1 through N, sequentially.

NEW:

 | The Tester sends a stream of test traffic through Link A to the DUT.
    The test traffic stream contains one or more interleaved flows.
    Flows are numbered 1 through N, sequentially.

Section 3.1., paragraph 1:
OLD:

    The purpose of the Baseline Test is to ensure that the DUT can
    forward every packet in the test stream, wThithout loss, when NDP is
    minimally exercised and not operating near its scaling limit.

NEW:

    The purpose of the Baseline Test is to ensure that the DUT can
 |  forward every packet in the test stream, without loss, when NDP is
    minimally exercised and not operating near its scaling limit.

Section 3.1.1., paragraph 6:
OLD:

    o  If the timer expires, stop the test stream and end the test

NEW:

    o  If the timer expires, stop the test stream and end the test
 |     (after waiting sufficient time for any queued packets to exit)

Section 3.1.1., paragraph 8:
OLD:

    o  When the timer expires, stop the test stream, log all counters and
       end the test

NEW:

 |  o  When the timer expires, stop the test stream, wait sufficient
 |     time for any queued packets to exit) log all counters and
       end the test

Section 3.1.2., paragraph 1:
OLD:

    The two counters associated with the flow (packets-sent and packets-
    received) must have equal values.  If they do not, an error has
    occurred.  Because this error is likely to affect Scaling Test
    results, the error must be corrected before the Scaling Test is
    executed.

NEW:

    The two counters associated with the flow (packets-sent and packets-
 |  received) should have equal values.  If they do not, an error has
    occurred.  Because this error is likely to affect Scaling Test
    results, the error must be corrected before the Scaling Test is
    executed.

Section 3.1.2., paragraph 2:
OLD:

    The log contains two counters (packets-sent and packets-received) for
    the flow.  If these values are identical, none of the initial packets
    belonging to the flow were lost.  However, if packets-sent is greater
    than packets received, initial packets were lost.  This loss of
    initial packets is acceptable.

NEW:

    The log contains two counters (packets-sent and packets-received) for
    the flow.  If these values are identical, none of the initial packets
    belonging to the flow were lost.  However, if packets-sent is greater
    than packets received, initial packets were lost.  This loss of
    initial packets is acceptable.
 [ACM] suggest to confirm initial packet loss, by observing the sequence
       numbers embedded in the test packets (or some other method).

Section 3.2.1., paragraph 7:
OLD:

    o  If the timer expires, stop the test stream and end the test

NEW:

    o  If the timer expires, stop the test stream and end the test
 |     (after waiting sufficient time for any queued packets to exit)

Section 3.2.1., paragraph 17:
OLD:

    After the above described procedure had been executed N times, clear
    the timer and reset it to expire in 1800 seconds.  When the timer
    expires, stop the stream, log all counters and end the test.

NEW:

    After the above described procedure had been executed N times, clear
    the timer and reset it to expire in 1800 seconds.  When the timer
    expires, stop the stream, log all counters and end the test
 |  (after waiting sufficient time for any queued packets to exit).

Section 3.2.2., paragraph 7:
OLD:

    If an implementation abides by the recommendation of RFC 6583, for
    any given counter pair, packets-received will either be equal to zero
    or packets-received.

    The log documents the time at which each flow was introduced to the
    test stream.  This log reveals the effect of NC size to the time
    required to discover a new IPv6 neighbor.

NEW:

    If an implementation abides by the recommendation of RFC 6583, for
    any given counter pair, packets-received will either be equal to zero
 |  or packets-received. <please add section reference in RFC 6583>
    The log documents the time at which each flow was introduced to the
    test stream.  This log reveals the effect of NC size to the time
    required to discover a new IPv6 neighbor.

Section 4.1., paragraph 1:
OLD:

    This measurement relies on the DUT to provide utilization
    information, which is subjective.

NEW:

    This measurement relies on the DUT to provide utilization
 |  information, which is not externally observable (not black-box).
 |  However, some testing organizations may find the CPU utilization
 |  is useful auxiliary information specific to the DUT model, etc.

> -----Original Message-----
> From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Wednesday, September 21, 2016 1:36 PM
> To: i-d-announce@ietf.org
> Cc: bmwg@ietf.org
> Subject: [bmwg] I-D Action: draft-ietf-bmwg-ipv6-nd-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Benchmarking Methodology of the IETF.
> 
>         Title           : Benchmarking The Neighbor Discovery Protocol
>         Authors         : William Cerveny
>                           Ron Bonica
>                           Reji Thomas
> 	Filename        : draft-ietf-bmwg-ipv6-nd-03.txt
> 	Pages           : 13
> 	Date            : 2016-09-21
> 
> Abstract:
>    This document provides benchmarking procedures for Neighbor Discovery
>    Protocol (NDP).  It also proposes metrics by which an NDP
>    implementation's scaling capabilities can be measured.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bmwg-ipv6-nd/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-bmwg-ipv6-nd-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bmwg-ipv6-nd-03
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg