Last Call Review of draft-ietf-bmwg-dcbench-methodology-07

Request Review of draft-ietf-bmwg-dcbench-methodology
Requested rev. no specific revision (document currently at 18)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-06-13
Requested 2017-05-30
Authors Lucien Avramov,
Draft last updated 2017-06-08
Completed reviews Opsdir Last Call review of -15 by Scott Bradner (diff)
Genart Last Call review of -07 by Dan Romascanu (diff)
Genart Telechat review of -12 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu 
State Completed
Review review-ietf-bmwg-dcbench-methodology-07-genart-lc-romascanu-2017-06-08
Reviewed rev. 07 (document currently at 18)
Review result Ready with Issues
Review completed: 2017-06-08


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-bmwg-dcbench-methodology-??
Reviewer: Dan Romascanu
Review Date: 2017-06-08
IETF LC End Date: 2017-06-13
IESG Telechat date: Not scheduled for a telechat


This Informational I-D describes test and evaluation methodology and measurement techniques for physical network equipment in the data center. It's an useful and clearly written document and it is ready for publication, after a number of minor issues and nits will be addressed. 

Major issues:

Minor issues:

1. There is one single mention of the scope being benchmarking of 'physical network equipment in the data center'. I assume this is written as opposed to virtual networking equipment. This is not included in the title or repeated any place else. I suggest to make more clear the scope by mentioning 'physical equipment' at least once more, for example in the Introduction section. 

2. Section 1.2: I am a little concerned about adding additional interpretations to the keywords in RFC2119. 

Especially about: 

'MAY: Comprehensive metric for the scenario described'

MAY has a different meaning in 2119, and the fact that a metric is 'comprehensive' (whatever this means) seems to me orthogonal to the 2119 semantics. The proposed interpretation makes little sense to me, if 'comprehensive' than why not required? or at least as a 'should'? 

3. Section 6.2: 'The intensity of a microburst MAY be varied ...' It would be useful to make clear what is meant by 'intensity'. 

Nits/editorial comments: 

1. The different formatting of the references [1], [2], etc. vs. [RFC2119], etc. is slightly confusing. Unless there is some good reason I suggest to fix this. Also use of references is inconsistent through the text, sometimes they are mentioned, sometimes they are not. 

2. Section 2.2: 'Alternatively when a traffic generator CAN NOT be connected ' - this capitalization is not conformant to RFC2119. 

3. 'vlan ZZZ' is not consistent with 'vlan X' and 'vlan Y' previously used. 

4. Missing reference - RFC 6985

5. Missing expansion and references for DSCP and COS

6. Sections 3.3 and 6.3: s/number of iteration/number of iterations/

7. The methodology (e.g. in section 5) makes an assumption that the DUT has at least nine ports. This may be trivial in a DC, but it's worth being mentioned