Subject: RE: [bmwg] WGLC on IPv6 Benchmarking

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 8 Aug 2007 16:09:27 +0200

1. It looks like it is appropriate for the header of the document to
mention that it 'Updates RFC 2544 (when approved)'. 
 
2. I believe that the title may be mis-leading as it talks about IPv6
benchmarking without making clear that it is a complementary document to
RFC 2544 which deals with Benchmarking Methodology for Network
Interconnect Devices. Folks who do search through an RFC repository may
be led to believe that the document covers specific aspects of IPv6 like
IPv6 transition mechanisms and devices for example. I suggest to change
the title in something more explicit like ' Benchmarking Methodology for
IPv6-capable Network Interconnect Devices' or even 'IPv6 Aspects of
Benchmarking Methodology for Network Interconnect Devices' (or similar).
 
3.  Section 4.1.1 - We should include here the conclusions of the
parallel discussions that we had on the list concerning frame size.
Those included to my best recollection the note proposed by Chip: 
 
> "Note: The recommended 1518 bytes frame size represents the maximum
size of an untagged Ethernet frame. According to the IEEE 802.3as
standard, the frame size can be increased up to 2048 bytes to
accommodate frame tags."
 
Also I believe that mentioning jumbo frames should be made only in a
similar note, with explicit text that makes clear that jumbo frames are
currently out of the scope of the IEEE 802.3 standard. 
 
4. The table in Appendix A.1 should include a row for length 2048 as per
IEEE 802.3as
 
5. Add IEEE 802.3 - 2005 and IEEE 802.3as as Informative References. 
 
Dan

________________________________

	From: Al Morton [mailto:[email-masked]] 
	Sent: Sunday, July 15, 2007 5:36 AM
	To: [email-masked]
	Subject: [bmwg] WGLC on IPv6 Benchmarking

	BMWG:
	
	A WG Last Call period for the Internet-Draft on
	
	"IPv6 Benchmarking Methodology"
	<draft-ietf-bmwg-ipv6-meth-02.txt>
	
	will be open from 14 July 2007 through 10 August 2007.
	
	A URL for this Internet-Draft is:
	
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipv6-meth-02.txt
	
	Version 02 incorporates changes suggested during development
	prior to the draft becoming a chartered item, and the recent
	WGLC comments (closing on 20 March 2007).
	
	The authors believe that all comments from the working group
	have been addressed, and have documented all comments and
resolutions
	to date:

http://home.comcast.net/%7Eacmacm/BMWG/IPv6-meth-comment-resolution.pdf

<http://home.comcast.net/%7Eacmacm/BMWG/IPv6-meth-comment-resolution.pdf
	They would also like to point out that their mixed traffic
methodology 
	has been proven with an actual test tool implementation of their
draft 
	recommendations.
	
	This draft is continuing through the BMWG Last Call Process.
This is
	the second Working Group Last Call. See
	http://www1.ietf.org/mail-archive/web/bmwg/current/msg00846.html
	
	Please express your opinion on whether or not this
Internet-Draft
	should be submitted to the Area Directors for consideration to
	publish the draft as an Informational RFC.  Send your comments
	to this list or [email-masked]
	
	Al
	bmwg chair 

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: "Chip Popoviciu \(cpopovic\)" <[email-masked]>
Date: Wed, 8 Aug 2007 15:23:33 -0400

Dan,
 
Many thanks for all your feedback leading up to this summary. I have two
questions/comments related to the points you listed:
 
- For point 1, do you envision any additional text beyond a change in
title (as you suggest in point 2) and the fact that the Abstract
explains that this is an update/complement to RFC2544?
- For point 2, I prefer the second option you proposed because we don't
introduce qualifiers such as "capable". Also, what do you think of the
following title: "IPv6 Benchmarking Methodology for Network Interconnect
Devices"? It would relate immediately to RFC 2544's title and would be
more generic.
 
Thank you again for your help with this work!
 
Best Regards,
Chip

From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, August 08, 2007 10:09 AM
To: Al Morton; [email-masked]
Subject: RE: [bmwg] WGLC on IPv6 Benchmarking

 

 

Dan

	BMWG:

	

	

	

	
	
	Al
	bmwg chair

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 9 Aug 2007 10:52:47 +0200

See in line. 
 
Dan

	From: Chip Popoviciu (cpopovic) [mailto:[email-masked]] 
	Sent: Wednesday, August 08, 2007 10:24 PM
	To: Romascanu, Dan (Dan); Al Morton; [email-masked]
	Subject: RE: [bmwg] WGLC on IPv6 Benchmarking

	Dan,
	 
	Many thanks for all your feedback leading up to this summary. I
have two questions/comments related to the points you listed:
	 
	- For point 1, do you envision any additional text beyond a
change in title (as you suggest in point 2) and the fact that the
Abstract explains that this is an update/complement to RFC2544?
	 
	[DR] A sentence in the Abstract or Introduction section
clarifying that IPv6 transition mechanisms are not within the scope
could help, but I do not insist on it. 
	 
	- For point 2, I prefer the second option you proposed because
we don't introduce qualifiers such as "capable". Also, what do you think
of the following title: "IPv6 Benchmarking Methodology for Network
Interconnect Devices"? It would relate immediately to RFC 2544's title
and would be more generic.
	
	[DR]  This would be fine. 

	Best Regards,
	Chip

---

From: Al Morton <[email-masked]>
Date: Fri, 10 Aug 2007 15:08:18 -0400

><draft-ietf-bmwg-ipv6-meth-02.txt>

...closes today.

Just a few, mostly editorial suggestions,
Al
(as a participant)

S 1, 3rd para.
To be consistent, include the RFC number for
"Benchmarking Terminology for ..." [6] in the text.
All the other RFCs in this section are referred to by number,
and RFC 1242 should not be left out.

S 5.1, 3rd para,
    "The frame sizes listed for IPv6 include the extension headers used in
    testing (see section 4.3). "
should be 5.3

S 5.2.1 1st para

    "IANA reserved the IPv6 address block xxxxx/48 for use with IPv6
    benchmark testing.  These addresses MUST be assumed to be not
    routable on the Internet and MUST not be used as Internet source or
    destination addresses.

    Note to IANA: Replace "xxxxx" with assigned prefix."

I suggest that it's more efficient to ask the IANA folks to edit one
section, the IANA section (8), and just make a reference to it here.

possible text:
    IANA has reserved an IPv6 address block for use with IPv6
    benchmark testing (see section 8).  It MAY be assumed that
    addresses in this block are not globally routable and they
    MUST NOT be used as Internet source or destination addresses.

    <note deleted>
and
5.2.2.  Test Traffic Protocol Addresses

    The IPv6 source and destination addresses for the test streams SHOULD
    belong to the IPv6 range assigned by IANA as defined in section 8.

S 7
under Extension Header specific conditions, the text should reference
section 5.3 not 4.3.

S 7.4  Back-to-Back Frames.

I don't think we should have an objective for a test we've decided not to
recommend, so suggest deleting the Objective: lines.

---

From: "Chip Popoviciu \(cpopovic\)" <[email-masked]>
Date: Fri, 10 Aug 2007 15:15:49 -0400

Thank you Al for your comments and suggestions. All the feedback
received from the WG during this last call will be shortly integrated in
the new version of the document.

Best Regards,
Chip

-----Original Message-----
From: Al Morton [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 3:08 PM
To: [email-masked]
Subject: Re: [bmwg] WGLC on IPv6 Benchmarking

...closes today.

Just a few, mostly editorial suggestions, Al (as a participant)

S 1, 3rd para.
To be consistent, include the RFC number for "Benchmarking Terminology
for ..." [6] in the text.
All the other RFCs in this section are referred to by number, and RFC
1242 should not be left out.

S 5.1, 3rd para,
    "The frame sizes listed for IPv6 include the extension headers used
in
    testing (see section 4.3). "
should be 5.3

S 5.2.1 1st para

possible text:

    <note deleted>
and

    The IPv6 source and destination addresses for the test streams
SHOULD
    belong to the IPv6 range assigned by IANA as defined in section 8.

S 7

I don't think we should have an objective for a test we've decided not
to recommend, so suggest deleting the Objective: lines.