Subject: [bmwg] WG Last Call on IPsec Benchmarking Terminology

From: Al Morton <[email-masked]>
Date: Wed, 15 Jun 2005 10:41:50 -0400

BMWG:

A WG Last Call period for the Internet-Draft on

"Terminology for Benchmarking IPsec Devices"
<draft-ietf-bmwg-ipsec-term-05.txt>

will be open from 15 June 2005 through 18 July 2005.

A URL for this Internet-Draft is:
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-bmwg-ipsec-term-05.txt

Version 05 addresses comments from
the working group at meetings and on the list since
March 2003 when version 00 was published.

This draft is entering the BMWG Last Call Process. See
http://www1.ietf.org/mail-archive/web/bmwg/current/msg00846.html
At this time, we are seeking volunteers to complete the
BMWG Last Call Review Template in the message of 4/27/04
titled, "Refinements to the BMWG Last Call Process".
Volunteers should contact [email-masked] and [email-masked]
A copy of the template is available here:
http://home.comcast.net/~acmacm/IDcheck/LastCallTemplate.txt

Whether or not you decide to volunteer for the directed review,
please express your opinion on whether or not this Internet-Draft
should be given to the Area Directors for consideration in
progressing the draft to an Informational RFC.  Send your comments
to this list or [email-masked] and [email-masked]

Kevin, Al
BMWG Co-Chairs 

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: David Newman <[email-masked]>
Date: Tue, 21 Jun 2005 15:50:32 -0700 (PDT)

> will be open from 15 June 2005 through 18 July 2005.

1. Section 7.7 on "tunnels" notes that the term is already overloaded and 
wisely subdivides the category to avoid confusion.

However, Section 7.7.2 lists multiple definitions for the single term 
"IPSec tunnel" -- a simplex case with one SA and a duplex case with two 
SAs.

Not that any vendor would be unscrupulous enough to double-count tunnels, 
but the term as defined is open to abuse. The discussion says assume 
two-way unless otherwise specified, but that's not strong enough.

Perhaps the term "IPSec tunnel" could be subdivided into "single SA IPSec 
tunnel" and "dual SA IPSec tunnel" or something like that.

2. Similarly, section 7.7.3 on "tunnel" includes the IPSec tunnel without 
specifying how many components are involved.

I'd be more comfortable mandating the use of dual SA IPSec tunnels since 
it's both more stressful and more common.

Also, I'm having difficulty parsing the "issues" text in section 7.7.3.

Same issue about tunnel component count in these sections:

7.7.4: "configured tunnel"
7.7.5: "established tunnel"
7.7.6: "active tunnel"

3. All the rate terms in section define "foo rate" as a maximum rate. 
However, the discussion in 10.5.1 specifies that tunnel setup rate 
"should be measured at varying number of tunnels on the DUT." Since rates 
are likely to be different with different variables in play, by 
definition they can't all be the "maximum."

It might be better to distinguish between rates (which can be measured at 
various loads) and maximum rates (which can be measured only at the 
highest  loads a device can handle without errors).

4. Section 10.7 defines tunnel failover time in the event of a 
"catastrophic failure," but does not define what constitutes such an 
event, or how it differs from a plain old failure.

The discussion compounds the confusion by noting that failures can be 
caused by events other than a catastrophic failure, such as "a [sic] 
encryption engine failure" or a link outage.

>From a functional standpoint, I don't know that it much matters what type 
of failure has occurred. It might be cleaner here to define what 
constitutes a loss of service that would trigger a failover -- ie, what 
IPSec components would need to go away for failover to occur?

5. Section 11 on security considerations ignores an elephant in the room. 
These are terms for testing the performance of security devices, and yet 
there is no discussion that separates the performance and security device 
testing contexts. I'd be more comfortable with language saying that 
performance and security testing have different goals, and that the terms 
given in this document focus exclusively on performance.

In case this section doesn't get rewritten, there's a semicolon where a 
comma belongs.

dn