Subject: [bmwg] Comments on draft-popoviciu-bmwg-ipv6benchmarking-01

From: "Silvija Andrijic Dry \(sdry\)" <[email-masked]>
Date: Mon, 2 Oct 2006 07:45:24 -0400

Hi authors of draft-popoviciu-bmwg-ipv6benchmarking-01,
 
I reviewed this draft and overall  I thought it was very well written
and contains very useful information.
 
Here are couple of comments and questions:
 
1) Section 2, 1st paragraph
Why are you having such a strong (MUST) requirement to perform ALL tests
for all device types even when stating that not all are applicable to
every device type?
 
2) section 4
here you list frame sizes for ethernet (4.1.1) and POS(4.1.2) to be
tested. Should there be recomendation for mixed environments as well or
if such environment shouldn't be tested would be good to explicitly note
that ?
 
3) section 4
Should IMIX be tested? It's not mentioned here.
 
4) section 4.3
-As the draft choses not to make any recommendantion for testing w/
hop-by-hop header (as discussed in this section) you should then remove
hop-by-hop header from itemized list of EH's in the sentence that starts
with:
"For these reasons, all tests described in this
   document SHOULD be performed with both traffic that has no EH and
   traffic that has a set of EH selected from the following list:"
Perhaps your intention here was just to list possible EH's so maybe just
leading sentence can be rewritten to express that.
-Also after reading the entire 4.3 and 6 it's not 100% clear what this
"set of EH" (mentioned in the same sentence above) exactly is. When it
comes what needs to be executed EH wise listing you have in 6 is
actually much more clear (except that you should say how many EH's in
the chain) so maybe if you just make 4.3 consistent with that would be
good.
-In the same section you talk about testing with two or more EH, and
then at the end "chain of EH" and in section 6 again you mention
"chain". This area might need more clarity, i.e. be explicit that
"chain" is same as "two or more EH" and also does it matter whether
chain has 2 or 5 EH's? As if it does then maybe you should specify exact
# of EH's in the chain and if it doesn't would be good to mention that. 
 
Basically, it would be good to be more explicit and consistent in terms
of requirements for testing EH. I think I undestood what you are trying
to say but it might be open to interpretation. What I took from 4.3 and
6 was: 
- test 3 scenarios:1) no EH; 2) one EH; 3) chain of 2 or more EH's. 
- EH's that you test can be any EH from the first list in 4.3 except for
hop-by-hop
is that what you were trying to say?
 
5) Section 6
- You do review nicely all conditions/scenrios under which all tests
need to be executed but it would be nice to enumerate them so they are
more easy to identify and track.
- In list of EH scenarios i think you meant section 4.3 instead of 5.3
 
6) need to state explicitly that draft doesn't address multicast v6
traffic.
 
Thx,
 
Silvija
 
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: "Chip Popoviciu \(cpopovic\)" <[email-masked]>
Date: Tue, 3 Oct 2006 17:47:42 -0400

Silvija,
 
Thank you very much for your review of the document and your comments.
Please see my answer inline <c> </c>.
 
Best Regards,
Chip

________________________________

From: Silvija Andrijic Dry (sdry) 
Sent: Monday, October 02, 2006 7:45 AM
To: [email-masked]
Subject: [bmwg] Comments on draft-popoviciu-bmwg-ipv6benchmarking-01

 
 
1) Section 2, 1st paragraph
Why are you having such a strong (MUST) requirement to perform ALL tests
for all device types even when stating that not all are applicable to
every device type? 
<c> I think this is a good point. People might choose to execute only
the applicable tests that are of interest to them. Changed text to:
 
"Nevertheless, for each evaluated device it is recommended to perform as
many of the applicable tests described in Section 6 as possible." 
</c>
 
2) section 4
here you list frame sizes for ethernet (4.1.1) and POS(4.1.2) to be
tested. Should there be recomendation for mixed environments as well or
if such environment shouldn't be tested would be good to explicitly note
that ? 
<c> In Section 3 we are describing the test setup by reffering to
Section 6 of RFC2544 (the same setup is proposed here as well). In
Section 6 of RFC2544, the scenario of testing interfaces with different
media types is discussed (subsection 6.1). The same would apply in the
case of this draft as well. </c> 
 
3) section 4
Should IMIX be tested? It's not mentioned here.
<c> Originally we had IMIX in the traffic setup considerations however,
the work group decided that IMIX is not defined well enough and should
not be included in this benchmarking document. </c>
 
4) section 4.3
-As the draft choses not to make any recommendantion for testing w/
hop-by-hop header (as discussed in this section) you should then remove
hop-by-hop header from itemized list of EH's in the sentence that starts
with:
"For these reasons, all tests described in this
   document SHOULD be performed with both traffic that has no EH and
   traffic that has a set of EH selected from the following list:"
Perhaps your intention here was just to list possible EH's so maybe just
leading sentence can be rewritten to express that. 
<c>Your point is valid. Based on discussions we had during last IETF
within BMWG and v6ops we decided to include testing with individual EH
and for each EH including Hop-by-Hop. The interest in Hop-by-Hop comes
more from a security perspective (due to the fact that all nodes must
process traffic with this EH), i.e. find out the impact on resources of
using this EH type. The new version of the document contains these
changes which will fix the problem you are pointing to.
</c>
-Also after reading the entire 4.3 and 6 it's not 100% clear what this
"set of EH" (mentioned in the same sentence above) exactly is. When it
comes what needs to be executed EH wise listing you have in 6 is
actually much more clear (except that you should say how many EH's in
the chain) so maybe if you just make 4.3 consistent with that would be
good. 
<c>I agree, I think the next version of the document will fix these
inconsistencies. </c> 
-In the same section you talk about testing with two or more EH, and
then at the end "chain of EH" and in section 6 again you mention
"chain". This area might need more clarity, i.e. be explicit that
"chain" is same as "two or more EH" and also does it matter whether
chain has 2 or 5 EH's? As if it does then maybe you should specify exact
# of EH's in the chain and if it doesn't would be good to mention that.

<c>The text in the new version of the draft will indicate that the tests
should be executed with 1 or more EH. More than 1 EH represents a chain.
We make a recomendation on the number and order of EHs. This is a chain
expected in real life even though we do not go into the details of the
contents of each EH since it is not relevant for the tests. Text was
added to clarify this point.
</c>  
 
Basically, it would be good to be more explicit and consistent in terms
of requirements for testing EH. I think I undestood what you are trying
to say but it might be open to interpretation. What I took from 4.3 and
6 was: 
- test 3 scenarios:1) no EH; 2) one EH; 3) chain of 2 or more EH's. 
- EH's that you test can be any EH from the first list in 4.3 except for
hop-by-hop
is that what you were trying to say? 
<c>Exactly! We also excluded the ESP EH because we want the Upper Layer
Protocol information to be available for the tests that involve filters.
</c> 
 
5) Section 6
- You do review nicely all conditions/scenrios under which all tests
need to be executed but it would be nice to enumerate them so they are
more easy to identify and track. 
<c>This is a very good suggestion and will be integrated in the next
version of the draft. </c> 
- In list of EH scenarios i think you meant section 4.3 instead of 5.3 
<c>You are correct. Made the change. </c> 
 
6) need to state explicitly that draft doesn't address multicast v6
traffic. 
<c>Added a note at the end of section 4.4 that benchmarking with
multicast traffic is outside the scope of this document. </c>
 
Thank you again Silvija!
 
Chip 
 
Thx,
 
Silvija