Re: Ben Campbell's No Objection on draft-ietf-bmwg-vswitch-opnfv-03: (with COMMENT)

Hi Ben, thanks for your review, please see below...

> -----Original Message-----
> From: Ben Campbell [mailto:[email protected]]
> Sent: Monday, June 05, 2017 11:39 PM
> To: The IESG
> Cc: [email protected]; Sarah Banks; bmwg-
> [email protected]; [email protected]; [email protected]
> Subject: Ben Campbell's No Objection on draft-ietf-bmwg-vswitch-opnfv-
> 03: (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-bmwg-vswitch-opnfv-03: No Objection
...
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> -General:
> 
> It seems a bit odd to me to use an IETF stream RFC to describe the
> status of an
> open source project, even when that project is closely related to IETF
> work.
> But I do not object strongly enough to get in the way of publication.
[ACM] 

Although this work is clearly in BMWG's charter, the WG is not quite
at the point where we are ready to write new RFCs. However, we 
do have a good collaboration with the several OPNFV projects
doing benchmarking, this one on vSwitches has recommended some
test methods which we will certainly take into account in future 
development.  

This draft, and the VSPERF project work in general, and BMWG's
understanding of this topic *all* benefited
from review and comments in BMWG. This is one form of

"...interaction between standards development in the IETF, 
development of running code, and open source efforts in the industry."
from https://www.ietf.org/blog/2017/05/iesg-retreat-3/

The interaction between open source efforts and BMWG is
also productive for other drafts; the WG
is almost ready to ship two new specifications
for SDN Controller Benchmarking (worked with the OPNFV Cperf project):
https://datatracker.ietf.org/doc/draft-ietf-bmwg-sdn-controller-benchmark-meth/
https://datatracker.ietf.org/doc/draft-ietf-bmwg-sdn-controller-benchmark-term/


> 
> -3.4: "It is essential to increase the flow timeout   time on a vswitch
> before
> conducting any performance tests that do not   intend to measure the
> flow setup
> time."
> 
> Does this mean to make allowances for the startup characteristics of virtual
> network elements, when physical elements might not have such limitations?  That
> seems sort of like optimizing for the test.
[ACM] 
This is an accepted aspect of benchmarking, and applies to both
physical and virtual network functions, such as switches and routers.
For example, RFC 2889 says:
   " ... The DUT/SUT address aging time SHOULD be configured to be greater than
   the period of the learning phase of the test plus the trial duration
   plus any configuration time required by the testing device."
See:
https://tools.ietf.org/html/rfc2889#section-3
The learning phase is benchmarked separately.

> 
> -4, figures:
> 
> Figure numbers and cross references would be very helpful for this
> section.
> 
[ACM] OK, we'll add them.

thanks again,
Al