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

From: Ben Campbell <[email-masked]>
Date: Mon, 05 Jun 2017 20:39:23 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-bmwg-vswitch-opnfv-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bmwg-vswitch-opnfv/

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

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

-4, figures:

Figure numbers and cross references would be very helpful for this section.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 6 Jun 2017 14:32:57 +0000

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

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Monday, June 05, 2017 11:39 PM
> To: The IESG
> Cc: [email-masked]; Sarah Banks; bmwg-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Ben Campbell's No Objection on draft-ietf-bmwg-vswitch-opnfv-
> 03: (with COMMENT)
> 
...
[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/

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

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

thanks again,
Al

---

From: Ben Campbell <[email-masked]>
Date: Thu, 8 Jun 2017 08:47:29 -0400

Hi, thanks for the response. Please see inline:

> On Jun 6, 2017, at 10:32 AM, MORTON, ALFRED C (AL) <[email-masked]> wrote:
> 

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

> The learning phase is benchmarked separately.

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

> [ACM] OK, we'll add them.

Thanks!

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 8 Jun 2017 13:59:25 +0000

> Sent: Thursday, June 08, 2017 8:47 AM
> To: MORTON, ALFRED C (AL)
> Cc: The IESG; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]; [email-masked]
> Subject: Re: Ben Campbell's No Objection on draft-ietf-bmwg-vswitch-
> opnfv-03: (with COMMENT)
> 
...
> >
> 
> 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.)
> 
> >
...
[ACM] 
Thanks.

Using Benoit's comments, I've suggested wording that makes this
draft more about *contributions* to work in BMWG, and less about
"progress" of the VSPERF project. The authors wanted BMWG to 
take advantage of what we learned, and the best way to do that
was to clearly describe new test setups and new configuration
parameters in a less ephemeral form (wikis and OS docs disappear).
We also wanted to help BMWG folks appreciate the rest of the work
that was needed, and make some recommendations. 

I'm sure the VSPERF project folks will continue to collaborate
as long it is useful.
Al