Re: I-D Action: draft-ietf-bmwg-ipv6-nd-03.txt
"MORTON, ALFRED C (AL)" <[email protected]>
| Newsgroups | gmane.ietf.bmwg |
|---|---|
| Message-ID | <[email protected]> |
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:[email protected]] On Behalf Of internet-
> [email protected]
> Sent: Wednesday, September 21, 2016 1:36 PM
> To: [email protected]
> Cc: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/bmwg