Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-02-04 Thread David Diaz
Well the feedback onlist and extensive offlist was great. The respondents seem to feel that because of the rapid onset of the attack, an dynamically allocated optical exchange might have exacerbated the problem. But this is also the benefits, it allows flexible bandwidth with a nonblocking ba

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-02-04 Thread Kurt Erik Lindqvist
Actually, I think that was the point of the dynamic provisioning ability. The UNI 1.0 protocol or the previous ODSI, were to allow the routers to provision their own capacity. The tests in the real world done actually worked although I still believe they are under NDA. The point was to prov

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-31 Thread Jack Bates
From: "Iljitsch van Beijnum" > If my regular saturday morning traffic is 50 Mbps and a worm generates > another 100, then 150 Mbps is a valid need as being limited to my usual > 50 Mbps would mean 67% packet loss, TCP sessions go into hibernation and > I end up with 49.9% Mbps of worm traffic. >

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-31 Thread Iljitsch van Beijnum
On Fri, 31 Jan 2003, Jack Bates wrote: > If a proper rulebased system were implemented, wouldn't this account for the > issues? For example, implementation of an increase is only allowed by peer E > if the traffic has been a gradual increase and X throughput has been met for > T amount of time. P

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-31 Thread Stephen Stuart
> > > We don't know anything we could do with 50ms provisioning without > > making a disaster (c) smd 2001. > > indeed. but i sure would like one or two day provisioning, as > opposed to 18 months. The space where that problem exists is within and and at the edge of carrier networks. I think

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-31 Thread Randy Bush
> We don't know anything we could do with 50ms provisioning without > making a disaster (c) smd 2001. indeed. but i sure would like one or two day provisioning, as opposed to 18 months. randy

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-31 Thread Stephen Stuart
> Of course, I realize that to implement the necessary rules would add a > complexity that could cost largs sums of money due to mistakes. Implementing the automation that can (correctly) implement the necessary rules is an enormous challenge, and it's unclear whether anyone in the marketplace wi

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-31 Thread Jack Bates
From: "Stephen Stuart" > Billing disputes in the exchange point now involve three parties, and > become more complex as a result - this, in theory, results in the > technology not reducing op-ex but shifting it from the operations > department to the accounting and legal departments. > If a prope

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-31 Thread Vijay Gill
Stephen Stuart <[EMAIL PROTECTED]> writes: > Optical switch technology, and the control systems that cause the > technology to implement the business rules of an exchange point, have > a ways to go before they're ready for prime-time. We don't know anything we could do with 50ms provisioning wit

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-31 Thread Stephen Stuart
> My posted comment was concerning if this technology of layer3 to > layer1 integration/communication would have exacerbated the mSQL worm > as it might have had more ability to grab larger peering pipes. Were that to have been the case, it would probably would also have been responsible for so

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-30 Thread David Diaz
At 6:54 + 1/31/03, Vijay Gill wrote: David Diaz <[EMAIL PROTECTED]> writes: was to "pay" for what you used when you used it. The biggest technical factor was "how the heck do you bill it." Actually I'd think the biggest technical factor would be the trained monkey that would sit at t

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-30 Thread Vijay Gill
David Diaz <[EMAIL PROTECTED]> writes: > was to "pay" for what you used when you used it. The biggest > technical factor was "how the heck do you bill it." Actually I'd think the biggest technical factor would be the trained monkey that would sit at the switch and do OIR of line cards on the ro

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-30 Thread David Diaz
Actually, I think that was the point of the dynamic provisioning ability. The UNI 1.0 protocol or the previous ODSI, were to allow the routers to provision their own capacity. The tests in the real world done actually worked although I still believe they are under NDA. The point was to prov

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-30 Thread Vijay Gill
David Diaz <[EMAIL PROTECTED]> writes: > With the rapid onset of an attack such as the one sat morning. Models > I have show that not only would the spare capacity been utilized > quickly but that in a tiered (colored) customer system. That the lower > service level customers (lead colored, silve

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-30 Thread Kurt Erik Lindqvist
I have received information on router utilizations, some routers it seems may have held up better then others. That information is useful. But I am working on some optical exchange point/optical metro designs and this might have a dramatic impact if one considers things like OBGP, Uni 1.0,

Re: mSQL Attack/Peering/OBGP/Optical exchange

2003-01-26 Thread Rubens Kuhl Jr.
- Original Message - | One other considerations is that optical IXs will have a greater | impact on the internet, possibly good and bad. With larger circuit | sizes of OC48 and OC192 for peering. An attack would have a greater | ability to flood more traffic. A failure of a peering ses

mSQL Attack/Peering/OBGP/Optical exchange

2003-01-26 Thread David Diaz
Morning all, In light of the recent attack, and the dramatic impact it had on internet connectivity. I was wondering if any operators (esp of exchange pts) would provide information on utilization. Especially any common backplane %s. I have received information on router utilizations, some