[12:46:08] --- Raj has joined
[13:20:55] --- jperser has joined
[13:22:38] --- jperser has left
[15:10:10] --- jaykarthik has joined
[15:10:16] <jaykarthik> Hi Raj
[15:28:32] --- Raj has left
[15:28:35] --- acmacm has joined
[15:29:53] <acmacm> Hi Jay
[15:30:03] <jaykarthik> Hi Al
[15:30:25] <jaykarthik> I presumed this is Al ... am I right ?
[15:30:47] <acmacm> yes
[15:31:01] <acmacm> Are you listening to the audio?
[15:31:19] <jaykarthik> Not yey ..but will be shortly at 4 PM EST
[15:31:23] <jaykarthik> yet
[15:31:46] <acmacm> OK
[15:48:23] --- jaykarthik has left: Replaced by new connection
[15:54:16] --- jaykarthik has joined
[15:57:15] --- jperser has joined
[16:02:49] <jaykarthik> I can hear clear
[16:02:55] <jaykarthik> Yes
[16:05:28] --- bmwgkd has joined
[16:10:20] --- Raj has joined
[16:10:47] --- Raj has left
[16:10:56] --- Rajiv has joined
[16:11:04] <Rajiv> Hello Jay
[16:11:17] <Rajiv> Hello Al
[16:11:27] <jaykarthik> Hi Rajiv
[16:11:43] <Rajiv> The audio feed is very clear
[16:29:55] <jaykarthik> Congrats Jerry
[16:30:08] <jperser> Thanks
[16:30:27] --- BillC has joined
[16:31:57] --- sporetsky has joined
[16:32:07] <bmwgkd> This still leaves a security statement void.
[16:32:17] <Rajiv> hi Scott
[16:32:25] <sporetsky> Hi everyone
[16:32:31] <jaykarthik> Hi Scott ... congrats on getting RFC 4689 done !
[16:32:39] <sporetsky> Thanks!
[16:32:44] <jperser> Scott, I came to San Deigo to buy you a beer.
[16:32:57] <sporetsky> March
[16:33:00] <sporetsky> in Prague
[16:33:09] <bmwgkd> BTW, RFC3116 has a decent "reference" to a stock BMWG
[16:33:14] <bmwgkd> security boilerplate.
[16:34:16] <sporetsky> Which draft is Al discussing?
[16:34:30] <BillC> starting with v6 benchmarking draft in a sec
[16:34:45] <sporetsky> Which is he discussing now?
[16:34:46] <jperser> Core router
[16:34:59] <sporetsky> What I thought
[16:35:01] <jperser> IPV6 now
[16:35:18] <jperser> AL is new to technology
[16:36:13] <jperser> Ipv6 Benchmarkng slide 2
[16:36:26] <sporetsky> I do want to point out it is not a "Core Router draft"
[16:36:42] <sporetsky> It is a "Stress Benchmarkign Draft" that can be applied to any networking device
[16:36:47] <jperser> Al has moved on since your not here, Scott
[16:37:02] <sporetsky> My audio stream is very poor in the hotel
[16:37:09] <sporetsky> in jp
[16:37:11] <jperser> Slide 3
[16:38:15] <jperser> Slide 4
[16:48:13] <BillC> http://www3.ietf.org/proceedings/06nov/slides/bmwg-5.ppt
[16:48:35] <jperser> slide 4
[16:50:26] <Rajiv> We will be responding to comments received from Arun Gandhi soon
[16:50:35] <Rajiv> on the terminology document
[16:50:56] <Rajiv> Thanks to Arun for reviewing the terminology document
[16:51:29] <Rajiv> yes
[16:54:52] <sporetsky> I agree Al
[16:55:03] <Rajiv> definitely
[16:55:22] <bmwgkd> Al - and the best way for folks to do that is to COMMENT TO THE LIST versus direct response to the principal authors. It will help David assess rigourous support.
[16:55:37] <sporetsky> Absolutely
[16:55:48] <sporetsky> Can you repeat the comment?
[16:55:52] <sporetsky> It wa shard to hear
[16:56:13] <sporetsky> Terminology is not specific to MPLS
[16:56:19] <sporetsky> right
[16:56:27] <Rajiv> David meant to say that how we can apply to the work outside MPLS
[16:56:42] <sporetsky> This is Jerry
[16:56:42] <Rajiv> Sorry, it was Jerry i believe
[16:56:55] <sporetsky> It is more general -- Read the TERMINOLOGY
[16:57:20] <sporetsky> Terminology defines Failover
[16:57:42] <sporetsky> Yes
[16:58:04] <Rajiv> We will add protection switching to the term document
[16:58:10] <sporetsky> Why?
[16:58:21] <sporetsky> We re-use exisiting term Failover
[16:58:55] <Rajiv> as Al mentioned that since the work heavily focus on protection switching
[16:59:03] <Rajiv> so it might be a good idea to define
[16:59:05] <Rajiv> it
[16:59:36] <jaykarthik> Protection should not only denote the "primary tunnel" but also the "protected interface"
[17:00:18] <jaykarthik> The backup tunnel protects the primary LSP as well as the downstream link and node and can be captured in the terminology draft.
[17:00:41] <sporetsky> Methodology needs to use Failover Event
[17:00:59] <Rajiv> total time
[17:01:09] <sporetsky> Packet Loss due to Failover Event
[17:01:11] <sporetsky> Not both
[17:01:14] <sporetsky> only aggreggate
[17:01:35] <sporetsky> Measue only aggregate!
[17:01:52] <Rajiv> the calculations are dependent on the packet loss
[17:01:55] <sporetsky> as externally observable from packet loss
[17:02:44] <sporetsky> We do not benchmarks components
[17:03:01] <jaykarthik> For an end user the detection time is not of concern as much as the aggregate
[17:03:06] <sporetsky> Terminology deines causes
[17:03:11] <sporetsky> in Failover Event
[17:04:32] <sporetsky> Absolutely!
[17:04:44] <sporetsky> For jabber to be effective comments to be read real-time
[17:05:08] <Rajiv> yes
[17:05:15] <Rajiv> yes
[17:05:16] <sporetsky> No
[17:05:19] <sporetsky> to Offered Load
[17:05:25] <sporetsky> No it is not
[17:05:36] <sporetsky> Time calculated from packet loss with known pps
[17:06:16] <sporetsky> Correct
[17:06:29] <Rajiv> Al - when you say time based, what do you mean?
[17:06:42] <sporetsky> It is time as externally measurable from packet loss
[17:07:08] <sporetsky> with known offered load
[17:07:14] <sporetsky> equalling device tput
[17:07:16] <Rajiv> ok
[17:07:33] <sporetsky> Agree!!!!!!
[17:07:36] <sporetsky> Packet Loss!
[17:07:38] <Rajiv> triggering point
[17:07:43] <sporetsky> BMWG decided this 3 years ago
[17:08:12] <sporetsky> That is what we do - Scott should read the draft
[17:08:14] <sporetsky> !!!!
[17:08:26] <sporetsky> we have it
[17:08:32] <sporetsky> It is in IGP Convergance
[17:08:58] <sporetsky> Convergence is <1 sec
[17:09:04] <sporetsky> so your assumption is incorrect
[17:09:09] <sporetsky> I disagree
[17:09:11] <sporetsky> strongly
[17:09:38] <Rajiv> Thanks Al
[17:09:44] <Rajiv> for reading the comments
[17:09:50] <Rajiv> from Jabber
[17:09:58] <Rajiv> Thanks to LeRoux
[17:10:23] <sporetsky> Told you
[17:11:26] <sporetsky> Were there comments on the mailing list for WGLC?
[17:11:41] <Rajiv> for methodology
[17:11:45] <Rajiv> i do not think so
[17:12:13] <sporetsky> What is a support problem?
[17:12:35] <jperser> Scott, I'll read the drafts again. I need to apply protection metrics to Wireless Mesh NEtworks
[17:13:03] <jperser> Customer support problem.
[17:13:05] <sporetsky> Thanks
[17:13:43] --- jperser has left
[17:14:01] --- jperser has joined
[17:14:59] <jperser> slide 2
[17:16:50] <jperser> slide 5
[17:19:11] <sporetsky> OK
[17:19:14] <sporetsky> we can add that
[17:22:03] <jperser> slide 7
[17:23:02] <jperser> slide 8
[17:27:12] <sporetsky> Benchmarking Control perofrmanc ein the rpesence of media
[17:27:26] <sporetsky> that is why the Associated Media term is important
[17:30:35] <jperser> slide 9
[17:33:05] <sporetsky> Thanks Al!
[17:33:35] <sporetsky> Which draft?
[17:34:02] <jaykarthik> Multicast VPN Scalability Benchmarking <http://www3.ietf.org/proceedings/06nov/slides/bmwg-3.ppt>
[17:34:17] <sporetsky> Thanks Jay
[17:34:25] <jaykarthik> NP Scott ...
[17:36:07] <jperser> slide 4
[17:39:08] <jperser> slide 6
[17:41:24] <jaykarthik> Yes Silvija
[17:41:27] <jaykarthik> We need it.
[17:41:56] <jperser> slide 8
[17:42:59] <jaykarthik> And preferably the terminology should be common for VPN as well as MVPN scalability bencmarking.
[17:45:46] <sporetsky> Agree
[17:46:07] <jperser> slide 11
[17:46:20] <jperser> slide 10
[17:49:05] <jaykarthik> Did the audio just fail ? Or is it at my end ?
[17:49:31] <jperser> ANyonbe else hear him?
[17:49:54] <jaykarthik> Fine again ...
[17:50:51] <sporetsky> Did the authors of this draft read the Multicast Benchmarking standards?
[17:51:09] <sporetsky> I can hear
[17:51:32] <sporetsky> There should be consistency with those drafts as well
[17:51:39] <sporetsky> excuse me, RFCs
[17:53:40] <sporetsky> Good
[17:54:23] <Rajiv> i can hear
[17:55:20] <jperser> Next is WLAN Switch Benchmarking <http://www3.ietf.org/proceedings/06nov/slides/bmwg-4.ppt>
[17:55:40] <sporetsky> Thanks Jerry
[17:56:27] <jperser> slide 2
[17:58:14] <jperser> slide 4
[17:59:19] <sporetsky> Could the Hash and Stuffing draft be updated with explanation why Wireless LAN does not apply?
[17:59:53] <jperser> Still discussing that with David Newman and Corporate.
[18:00:01] <jperser> slide 5
[18:00:01] <sporetsky> ok
[18:00:06] <sporetsky> good luck with that
[18:00:59] <jperser> The problem is that a random MAC address to a seurity concoius network looks like a hacker.
[18:01:49] <jperser> I have had several controllers lock out my test equipment because it thought I was probing for security holes.
[18:03:39] <jperser> slide 8
[18:03:45] <sporetsky> Interesting problem
[18:03:50] <sporetsky> thanks for the explanantion
[18:04:27] <sporetsky> Did you inadvertently develop a Nessus type test for WLAN?
[18:04:34] <sporetsky> That is initself a useful test
[18:04:43] <sporetsky> in itself
[18:08:27] --- BillC has left
[18:08:39] <jaykarthik> Thanks Al
[18:08:52] <sporetsky> Thanks Al
[18:09:08] <sporetsky> That was a very productiv emeeting
[18:09:13] <Rajiv> Thanks Al
[18:09:36] <Rajiv> This was my first on Jabber, but I think it is a very good compromise
[18:09:46] <sporetsky> agree
[18:10:03] <Rajiv> thanks everyone
[18:10:08] <Rajiv> bye
[18:10:13] <sporetsky> bye
[18:10:16] --- Rajiv has left
[18:10:18] <jperser> bye scoot
[18:10:28] <jperser> *scott
[18:10:36] <sporetsky> later
[18:10:37] <jperser> Im drinking your beer
[18:10:41] --- acmacm has left
[18:10:42] --- sporetsky has left
[18:10:45] --- jperser has left
[18:10:47] <jaykarthik> Bye all
[18:10:49] --- jaykarthik has left
[18:10:56] --- bmwgkd has left