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

[Ballot comment]
* 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.

[Ballot comment]
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?

[Ballot comment]

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:-)

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-bmwg-ipv6-nd-04.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-bmwg-ipv6-nd@ietf.org, joelja@gmail.com, bmwg-chairs@ietf.org, acmorton@att.com, bmwg@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Benchmarking The Neighbor Discovery Protocol) to Informational RFC


The IESG has received a request from the Benchmarking Methodology WG
(bmwg) to consider the following document:
- 'Benchmarking The Neighbor Discovery Protocol'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-01-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bmwg-ipv6-nd/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bmwg-ipv6-nd/ballot/


No IPR declarations have been submitted directly on this I-D.