mSQL Attack/Peering/OBGP/Optical exchange

Fri Jan 31 07:43:25 UTC 2003

At 6:54 +0000 1/31/03, Vijay Gill wrote:
>David Diaz <techlist at smoton.net> 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
>router as appropriate and reroute patches.
>
>>  If a customer goes from their normal OC3 ---> OC12 for 4hrs three
>>  times in a month... what do you bill them for?  Do you take it down to
>>  the DS0/min level and just multiple or do you do a flat rate or a per
>>  upgrade???
>
>Does this include the monkey cost as the monkey switches the ports
>around? (well, technically you can get software switchable oc3/oc12
>ports, but substitute for 48/192 and go from there)

No monkeys.  I was referring to the protocols that people have been 
working on that automatically "reprovision" on the fly.  The very 
simplistic view is (and this can be within your own network).

Router A ---> Optical box/mesh ---> Router B

Router A determines it needs to upgrade from OC3 to OC12 sends 
request and AUTH pwd ---> Optical mesh ----> Router B acks, says ok I 
do have capacity and your AUTH pwd verified  ---> OC12 ---> Optical 
---> OC12 ---> Router B

Actually there are different ways to do this. It goes beyond what I 
was asking here.  But I would be happy to expand on it.  You can 
actually on day one have a OC48 handing off 1310nm to the Optical 
switch.  The switch could then provision OC3s, OC12s off that.  The 
switches Im speaking of do virtual concant., so they can slice and 
dice the pipe.  Nothing says you have to use the whole thing on day 1.

Actually that was sort of the point for a lot of people that were 
interested.  They could have an OC48 and have 2 x OC12s off of that 
going to two different locations/peers.  If peer numbers 3 and 4 show 
up at the mesh/box then it's a simple point and click to provision 
that as soon as they are hot.

Sidenote:  As far as monkeys go.  You dont need a monkey since the 
protocol is theoretically doing it on the fly from layer3 down to 
layer1.  Not to mention that CNM (customer network management) 
exists, which allows customers to actually have READ and WRITE privs 
on their "owned" circuits.  So your own monkeys could do it with 
point and click.  Neat thing from using this as a wholesale carrier 
is the ability to actually take an OC192, sell an OC48 to a customer, 
have that customer sell an OC12 off of that and so on.  Everyone 
would have their own pwd that allows them to view their circuit and 
those "below" them but not above etc etc.  It's off topic but 
interesting.

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.

On last thought.  On the "leaving spare capacity comment.  If you 
might mean to say that OC48 ports on your router are much more 
expensive then OC12, and therefore with 20 peers, buying 20 x OC48 
ports when u usually use an avg of OC12 on each is cost prohibitive, 
I can understand that.  1) how do you do it today with those peers, 
since you dont like the avg sustained model.  2) what if you had 20 x 
OC12 ports but had 1 space OC48 port that would dynamically make 
layer1 connections to whichever peer needed that capacity at that 
moment?  Forgeting the BGP config issue for the moment on the layer3 
side.  Would this be an improvement?  Basically a hot spare OC48 that 
could replace any of the OC12s on the fly?

dave

>
>
>>  The point was you could bump up on the fly as needed, capacity
>>  willing, then down.  The obvious factor is having enough spare
>>  capacity in the bucket.  This should not be an issue within the 4
>
>And the monkey. I really don't have enough capital sitting around to
>leave a spare port idle for the 4 hours a day I need it.
>
>>  This sort of addressed the "how do i design my backbone"
>>  argument. Where engineers ahve to decide whether to built for peak
>>  load and provide max QoS but also the highest cost backbone; or
>>  whether to built for avg sustained utilization.  This way you can
>>  theoretically get the best of both worlds.  As long as the billing
>>  goes along with that.
>
>I don't plan to be buying service from anyone who is building to
>average sustained utilization (sic).  My traffic tends to be bursty.
>
>/vijay