[02:54:09] --- bmwgkd2 has joined
[02:54:23] --- bmwgkd2 has left
[02:56:15] --- bmwgkd2 has joined
[02:56:20] --- bmwgkd2 has left
[03:13:59] --- mattz has joined
[03:21:23] --- bmwgkd has joined
[03:22:50] <bmwgkd> Bonjour! The agenda can be found here:
[03:22:55] <bmwgkd> http://tools.ietf.org/agenda/63/bmwg.html
[03:23:54] <bmwgkd> The presentations can be found here: http://home.comcast.net/~acmacm/
[03:35:25] --- oern has joined
[03:36:06] <bmwgkd> The BMWG agenda slides are here: http://home.comcast.net/~acmacm/IDcheck/BMWGagenda.ppt
[03:41:30] --- oern has left
[03:44:43] <bmwgkd> Agenda was approved as proposed in slide 2.
[03:45:50] <bmwgkd> Slide 4, 5 reviews the WG activity since last mtg.
[03:49:17] <bmwgkd> Slide 6; 802.11T work.See the email on the reflector. A draft is to be updated with current proposals.
[03:49:56] <bmwgkd> Resource Reservation Presentationhttp://home.comcast.net/~acmacm/IDcheck/benchres63.ppt
[03:51:00] <bmwgkd> Slide 2: Andras states lots of diction cleanup.
[03:51:38] <bmwgkd> Slide 3 speaks to important changes, such as the load factors.
[03:52:50] <bmwgkd> The notion of signalling deficiit was an important change.
[03:53:31] <bmwgkd> Slide 4: More load conditions; scalability was a difficult concept; it's the boundary of between where the
[03:53:50] <bmwgkd> router is well behaved vs. it's overloaded.
[03:54:19] <bmwgkd> Combination of load factors can combine to give good and bad behavior.
[03:54:31] <bmwgkd> The notion of "reasonable time" is problematic.
[03:55:24] <bmwgkd> Many signalling protocols don't define these time frames, so it's even more difficult for us. E.g., is 10 minutes acceptable for a signaling event to be complete
[03:56:51] <bmwgkd> Andras states the I-D is a hefty 5 years old; let's get to consensus, so we can move on!
[03:57:36] <bmwgkd> acmorton: Have to watch out that reasonable time, does not become a conformance or acceptance test.
[03:58:27] <bmwgkd> Andras: we have to watch out, because the notion of the correct behavior is an important.
[03:58:50] <bmwgkd> Eliot Gerber: loss free is an important concept; is it unique?
[03:59:45] <bmwgkd> IPSec Presentation
[03:59:47] <bmwgkd> http://home.comcast.net/~acmacm/IDcheck/IPsec63.ppt
[04:00:58] <bmwgkd> Slide 1: Big notion - create tests that identify implementation limits, not interop.
[04:01:42] <bmwgkd> Methodology is still in its infancy.
[04:02:28] <bmwgkd> Slide 3: tunnelling definition were rework; caused some rework. Created notion IPsec tunnel.
[04:02:36] <bmwgkd> Added IPv6.
[04:03:04] <bmwgkd> Scope beyond gateway; expansion into hosts.
[04:03:53] <bmwgkd> Merike ipv6 requires manual keying, so led to tunnel terminology rework.
[04:04:16] <bmwgkd> Transport and tunnel mode support added, too.
[04:04:45] <bmwgkd> How many folks read draft? Less than 6.
[04:06:37] <bmwgkd> Tim, Slide 4. IkeV2? Not so strongly of the editors to jump into this right now. IFF need for IkeV2, better suited for an additional I-D. (Merike: Another reason, backward compatibility with IKEv1.)
[04:07:16] <bmwgkd> IPsec frag throughput. Maybe a reassembly?
[04:08:28] <bmwgkd> Xauth/Modcfg accounted for in reporting formats.
[04:09:13] <bmwgkd> Slide 5. Measurement units & Framesizes - some discussion may be warranted.
[04:10:36] <bmwgkd> Slide 6: notion of active tunnel will be deprecated in lieur of configured tunnel.
[04:11:03] <bmwgkd> Slide 7: 00 version of meth draft in next 2 weeks.
[04:11:38] <bmwgkd> Big IPv6 facelift for meth I-D
[04:12:55] <bmwgkd> Input needed? (slide 10) Test topologies, test set up, and identification of areas that need to be addressed or are otherwise missing.
[04:13:32] <bmwgkd> WGLC simultaneously for both docs?
[04:14:03] <bmwgkd> acmorton: generally like to do term then methods.
[04:15:23] <bmwgkd> Merike: meth assumptions flawed caused reworked term. Would like catch reworking both I-Ds simultaneously.
[04:15:32] <bmwgkd> acmorton: timeframe?
[04:15:43] <bmwgkd> merike: a couple of months from now.
[04:15:58] <bmwgkd> acmorton: that's a good timeframe.
[04:16:49] <bmwgkd> Slide 10: some movement of documentation from term to meth and vice versa, for clarity.
[04:17:04] <bmwgkd> Slide 11: contacts, that's it. Please offer comments.
[04:18:38] <bmwgkd> Accelerated Life Test I-Ds (acmorton for scott poretsky)
[04:18:42] <bmwgkd> http://home.comcast.net/~acmacm/IDcheck/Poresky63.ppt
[04:19:40] <bmwgkd> Slide 2: Al will selectively present from scott's deck.
[04:20:08] <bmwgkd> Slide 5: Accelerated Stress
[04:20:34] <bmwgkd> Who read the draft? (only the chairs)
[04:22:04] <bmwgkd> Method draft received the changes; added two "flavored" methods - for eBGP and Operational Security.
[04:23:54] <bmwgkd> acmorton: expectation of zero packet loss. Is this an acceptance criteria? Need to be clear.
[04:24:27] <bmwgkd> kdubray: May just need reinforcement. zero packet loss is an absolute value; not an acceptance value.
[04:26:00] <bmwgkd> acmorton: This is a watershed work as it tests the traditional scope of BMWG benchmarks. It would be nice to see that comparisons can be used as a cross vendor benchmark.
[04:27:08] <bmwgkd> Back to agenda.
[04:27:54] <bmwgkd> Agenda slides. Slide 11.
[04:28:46] <bmwgkd> ACmorton: Rally around the notion of our central tenet "Benchmark".
[04:29:28] <bmwgkd> Slide 9 statues possible required attributes.
[04:31:23] <bmwgkd> Bert wijnen: restrict to IETF protocols?
[04:34:48] <bmwgkd> kdubray: notion of "internetworking technologies or services".
[04:35:23] <bmwgkd> bert: clarifies that conformance is not an IESG limit; it's a communal limit.
[04:35:56] <bmwgkd> kdubray: looking to refine the notion of benchmarking between tests.
[04:37:11] <bmwgkd> Andras: difficult to avoid the areas of acceptance/conformance. It's built in the test. Loss or loss free. It's
[04:37:15] <bmwgkd> not trial.
[04:37:21] <bmwgkd> That's trivial. :-)
[04:39:20] <bmwgkd> acmorton: what about precondition to benchmarking. E.g., assumption that protocol conformance is in place.
[04:39:56] <bmwgkd> Andras: that's ok; what about when there's no "conformance" point or acceptable bar in the protocol reference.
[04:46:14] <bmwgkd> Tim V: who will give the conforming certification.
[04:46:42] <bmwgkd> Andras: It doesn't benefit vendors to cheat.
[04:48:14] <bmwgkd> Merike: Wording need to be provide in bmwg to preclude cheating; (rfc2285 is a good example)
[04:49:35] <bmwgkd> Slide 7, (yes 7), Current milestone status.
[04:49:49] <bmwgkd> Oops this is Agenda slide 7.
[04:51:21] <bmwgkd> Scott Poretsky looking for help in editorship in the diffserv benchmarking methodology.
[04:52:03] <bmwgkd> Milestones will need to be respun to reflect reality.
[04:52:16] <bmwgkd> New work:
[04:53:31] <bmwgkd> Back to the poretsky deck http://home.comcast.net/~acmacm/IDcheck/Poresky63.ppt
[04:54:03] <bmwgkd> see slide 6.
[04:54:38] <bmwgkd> These slides summarize the proposed new work item.
[04:55:26] <bmwgkd> acmorton: how many read? no one.
[04:55:58] <bmwgkd> david kessens: why are talking about this, if no one read.
[04:57:29] <bmwgkd> acmorton: lots of folks read initial proposal and comment at earlier meetings and list email.
[04:57:49] <bmwgkd> david: just assure there's interest on the area.
[04:59:22] <bmwgkd> david: and make sure the support is persistent, not just instaneous.
[05:00:02] <bmwgkd> acmorton: sums up.
[05:02:49] <bmwgkd> We're done. Au revoir!
[05:10:52] --- mattz has left: Replaced by new connection
[05:20:40] --- bmwgkd has left