North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: mSQL Attack/Peering/OBGP/Optical exchange
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 backplane. So backbones with a critical event such as a webcast have the capacity they need when they need it. A common shared backplane architecture might provide a nature bottleneck. One can also see this as a possible growth problem the rest of the time. Respondents strayed away from the specific subject of the dynamics of the Optical exchange under an mSQL type attack and went into the pros and cons. The number one topic: Billing Billing was also the biggest challenge in implementation of the technology. Once the ability was there, and the real world tests showed this technology was actually functional. No one was exactly sure of the business algorithm to charge by. Most commentators were concerned about losing billing control. That a peer (possibly under attack) may actually cause fees to be assessed to your own backbone. It must be understood that your network must give approval for this to happen. And if you have CNM (customer network management) enabled and even running on a screen in your noc, u are aware immediately when this happens. Without that, you have your specific peer locked down to whatever size pipe you have chosen. On the billing, it might be flat rate with the ability to "burst" to a higher sized capacity. Perhaps this is a flat rate charge, or would allow you to burst a certain amount of hours etc. No one has gotten a clear picture. The simplest answer is probably to do, as was mentioned, a similar scheme as in IP. Bill to the 95th percentile. It seems fair. Use a multiplier of DS0s per hour x $ and go with that. You might even lock it down so that at a certain $ figure, no more bursting is allowed. I do not like that kind of billing to network control, but it would seem that CFOs would demand some kind of ceiling limit. As far as oscillation between protection scheme in different layers. This has been a problem with things like an IP over ATM network. It should not be a problem and there has been a lot of testing. It is true the possibility for thrashing is there but probably not at sub 50ms layers. We have that now over sonet private peering circuits. But even in a metro wide optical exchange scheme, the two farthest points on the mesh being ~100 miles, reroute time was 16ms. Those are the real world tests when we were testing the network as we were breaking routes. There were some discussions of rule sets. No conclusions. filters should probably be left to the backbones with very little control at the optical layer (IX). The only rule sets might be to service levels or billing. David At 9:11 +0100 2/4/03, Kurt Erik Lindqvist wrote: 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.Well the problem with optical bandwidth on demand is that you will have to pay for the network even when it isn't being used. Basically you have three billing principles, pay per usage, pay for the service, a mix of the two. With all the models you still need to distribute the cost over bandwidth and in worst case this will end up being higher per transfered data. -- David Diaz [email protected] [Email] [email protected] [Pager] www.smoton.net [Peering Site under development] Smotons (Smart Photons) trump dumb photons
|