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

Hi, thanks for the response. Please see inline:

> On Jun 6, 2017, at 10:32 AM, MORTON, ALFRED C (AL) <[email protected]> wrote:
> 
> 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/
> 

It's great to see close collaboration between an open source project and a working group. But I don't see how it follows that it's a good idea to publish project status as an RFC.  Especially a project that is moving rapidly. But as I said, I'm not going to get in the way of publication. (I'm not going to make a detailed argument, because others have already done so, and I concede that this seems to fit the WG charter.)

> 
>> 
>> -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.

Okay, I am willing to accept that this is common practice.

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

Thanks!

> 
> thanks again,
> Al
>