Benchmarking the Neighbor Discovery Protocol
draft-ietf-bmwg-ipv6-nd-06

Minor clarification comments:

1) section 2.2.4: "This stream contains two flows, each contributing 500 packets per second to the 1,000 packet per second aggregate."
    Are these packets send alternating or in a block or does that not matter?

2) section 3.1.1: "When the timer expires, stop the test stream, wait sufficient time for any queued packets to exit, ..."
  That's the sending queue at the tester? I guess you'd also want to give it some time to make sure the packets send out can still be received. Does it makes sense to recommend a time here that's safe?

3) And a more general but even less important question: Isn't the base test included in the scaling test? And if so, do you still need to define the base test separately?

Just an idle thought... Given what we've learned about tests,
car manufs and diesel engines recently, I wonder if it'd be a
good idea for the security considerations sections of this
kind of RFC to consider how a DUT implementer might cheat?
In this case, I guess there could be a scenario where the
"clear the NC" operation is not really done (for a short
time, after a test pattern has been observed recently) so
that the DUT appears to perform better during tests. I'd
guess that some of the folks designing these tests thought
about some of that, but it might be no harm to start writing
that down as well. (Note this really is just a suggestion,
I'm not complaining at all. OTOH, while it'd be a bit of
work, it might be fun of a kind:-)

* Section 2

What does this mean in real life?

"Furthermore, Link A and Link B must be lossless."

* Section 2.1.2

The Router advertisements need to contain some values in the M and O bits. I think the values for these bits need to be specified in this section.

* Section 2.2.5

Why does the tester have counters for RS packets received and RA packets sent? It is unclear why this would be useful as both should always be zero.