Re: Fwd: New Version Notification for draft-cerveny-bmwg-ipv6-nd-02.txt

"MORTON, ALFRED C (AL)" <[email protected]>
Newsgroups gmane.ietf.bmwg
Message-ID <2845723087023D4CB5114223779FA9C8AB2EAC8E@njfpsrvexg8.research.att.com>
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 protected] [mailto:[email protected]] On Behalf Of
> William Cerveny
> Sent: Monday, October 21, 2013 10:46 AM
> To: [email protected]
> Subject: [bmwg] Fwd: New Version Notification for draft-cerveny-bmwg-ipv6-
> nd-02.txt
> 
> 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 protected]
> To: William Cerveny <[email protected]>, William Cerveny
> <[email protected]>, 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
> 
> _______________________________________________
> bmwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bmwg
_______________________________________________
bmwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bmwg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.