Subject: [bmwg] Fwd: New Version Notification for draft-cerveny-bmwg-ipv6-nd-02.txt

From: William Cerveny <[email-masked]>
Date: Mon, 21 Oct 2013 10:45:30 -0400

I've updated the "Benchmarking Neighbor Discovery Problems" draft.

Updates since v00 and v01

- Transition to writing from the perspective of testing via standalone
Linux boxes to using specialized testers.
- Added narrative describing more about how NDP works and the problems
that are being benchmarked.
- Removed tests/measurements that rely upon information obtained from
DUT, such as CPU load, etc.
- Lots of text changes since v00.

To-do:
- New tests need to be understood better. In particular, specific value
and procedure needs to be clarified.
- I have left the concept of a “non-participating” network in the draft,
which is a leftover from v00. I’ve left it in for now because I might
have a use for it as I experiment more in testing. If it turns out I
don’t need it, I’ll remove references to non-participating network/node
in future revisions.
- Looking back at my IETF-86 notes, Scott Bradner had issues with
benchmarking “problems”, as this is currently a benchmarking
instantiation of RFC 6583, “Operational Neighbor Discovery Problems”.  I
haven’t changed this yet and need to determine what it should change to
…

Bill Cerveny

----- Original message -----
From: [email-masked]
To: William Cerveny <[email-masked]>, William Cerveny
<[email-masked]>, William Cerveny
Subject: New Version Notification for draft-cerveny-bmwg-ipv6-nd-02.txt
Date: Thu, 17 Oct 2013 12:46:13 -0700

A new version of I-D, draft-cerveny-bmwg-ipv6-nd-02.txt
has been successfully submitted by William Cerveny and posted to the
IETF repository.

Filename:        draft-cerveny-bmwg-ipv6-nd
Revision:        02
Title:           Benchmarking Neighbor Discovery Problems
Creation date:   2013-10-17
Group:           Individual Submission
Number of pages: 12
URL:            
http://www.ietf.org/internet-drafts/draft-cerveny-bmwg-ipv6-nd-02.txt
Status:         
http://datatracker.ietf.org/doc/draft-cerveny-bmwg-ipv6-nd
Htmlized:       
http://tools.ietf.org/html/draft-cerveny-bmwg-ipv6-nd-02
Diff:           
http://www.ietf.org/rfcdiff?url2=draft-cerveny-bmwg-ipv6-nd-02

Abstract:
   This document is a benchmarking instantiation of RFC 6583:
   "Operational Neighbor Discovery Problems" [RFC6583].  It describes a
   general testing procedure and measurements that can be performed to
   evaluate how the problems described in RFC 6583 may impact the
   functionality or performance of intermediate nodes.

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.

The IETF Secretariat

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 22 Oct 2013 13:14:52 -0400

Hi Bill,

I read the draft today, and want to share a few comments,
as a participant. I like the draft, and since I know there
are more comments coming, these will get us started.

Al

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Title: you could just drop "Problems"

I think you need a motivation section, beyond the reference to
the "Problems" RFC, before we get to the test setup.
What are we going to benchmark here?
something along the lines of recommended behavior in RFC6583?

Thanks for including the "Overview of NDP" section.
A nit is that the last two items (indented 3, 4)
are alternative results for 
sending the neighbor solicitation packet, and
could be further indented and re-numbered 1,2. 

sec 6.1, max number of valid hosts:

In the test procedure (for this and similar for other procedures),
the last step should end with:
"The number of hosts in the cache is the value of the
Max Valid Hosts benchmark for this configuration."
(or something like that, don't leave the benchmark in mystery)

sec 6.2, Stable state time:
It appears this procedure actually benchmarks the 
*return to stable state time* following overload.
overload may not be the best term, but I think we can 
improve on the text: 
"the intermediate node has gotten into a state where packets are dropped."

sec 6.3.1 NDP Prioritization:
new stream needed here, tester-unreachable stream.
maybe list all streams and other equipment capabilities up front
(more streams defined in section 6.5).
Also, step 5. "not always get responses/packets be received",
let's discuss clarifying this condition, so it's clear when achieved.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> William Cerveny
> Sent: Monday, October 21, 2013 10:46 AM
> To: [email-masked]
> Subject: [bmwg] Fwd: New Version Notification for draft-cerveny-bmwg-ipv6-
> nd-02.txt
> 
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 23 Oct 2013 07:51:02 -0400

BMWG,

The topic of IPv6 Neighbor Discovery-related benchmarking has been 
discussed in the BMWG for almost a year, so we should determine whether
there is support to include this work in our future charter, and 
discuss how to describe the work item in our charter text.

So, please read the current draft and the short description of work
below, then provide comments/edits and indicate whether you support
the work item. Let's use our IETF session on Friday Nov 8 as the deadline.

regards,
Al
bmwg co-chair

_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_

IPv6 Neighbor Discovery-related benchmarking

Large address space in IPv6 subnets presents several networking 
challenges, as described in RFC 6583. Indexes to describe the 
performance of network devices, such as the number of reachable
devices on a sub-network, are useful benchmarks to the operations
community. The working group will develop the necessary terminology
and methodologies to measure such benchmarks.