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 some op-ex budgets being blown over the weekend, both as a result of capacity that would otherwise have been constrained automagically reprovisioning itself upward (ratcheting up the capacity comes at a price, right?), and as a result of accounting departments arguing over "you used it" versus "an attack caused an automatic system to provision bandwidth that I didn't really want so I don't want to pay for it." It's not hard to imagine a lot of edge customers infected with the latest flavor-of-the-week worm having conversations with their upstream providers about 95th percentile billing real soon now. Picture this aspect of the 1434/udp worm: It hits late on a Friday 1/24 (PST), in theory after lots of end-user IT shops have gone home for the weekend. January is a 31-day month - the 5% of samples tossed in a 95th percentile calculation represent a little over 37 hours of usage. Those IT shops have 37 hours to patch their systems, until Sunday (1/26) afternoon, and prevent their bill for January from being defined by 1434/udp worm usage. Oops, Sunday (1/26) was the Super Bowl. Missed the window. Systems get patched Monday (1/27). On Monday (2/3), lots of bills for January usage are going to be calculated. How many surprises will there be, and how much time in February will be devoted to Customer X disputing their January bill with Vendor Y? Auto-provisioning technology is quite exciting, being able to implement sweeping changes in many powered devices simultaneously with one point'n'click. In the interior of a network, the spending decisions that back the execution of that point'n'click are at least all within one organization. In a customer/vendor relationship, I can easily imagine the vendor wanting the customer to be able to run the dollar meter faster with the greatest of ease (and possibly associate some minimums with those increases, so that the click-down can't follow the click-up too closely), and any billing disputes mercifully only involve two parties. At an exchange point scenario, though, where two networks presumably have independently agreed to pay money to a third to connect via this optical switch, we now have the case where one can affect the monthly bill of the other by a point'n'click (again, I am making the assumption that the additional value represented by increased capacity will cause additional charges to be incurred - to two parties, now that we're in an exchange point scenario). The kind of policies that the control system now needs to implement undergo a dramatic shift in order to implement the business rules of an exchange point - from network R's perspective: network S may be have a specific cap on now much additional capacity it can cause network R to buy from exchange point E network T may have priority over network S when contending for limited headroom (without E revealing to S that T has priority) a total cap for monthly spending of $N with exchange point E may be set, after which all requests for additional capacity will be denied (and just for humor value) auto-provisioned capacity can only be added in response to legitimate traffic increases 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. I get the picture that the control software can organize views hierarchically. Exchange points aren't organized hierarchically, though (well, the non-bell-shaped ones aren't), they're organized as a mesh. The nice thing about Ethernet-based exchanges is that: they allow the structure of the network to mirror the structure of the organization (as networks have a habit of doing) easily the use of VLAN tags allows backplane slot capacity to be divided between peers without the hard boundaries per-peer that slicing and dicing SONET imposes but still within an overall cap that a) sets a boundary on the traffic engineering problem space on the interior side of the connected router and b) can be periodically reviewed the business rules that the technology has to implement are relatively clean, easy to understand, free of dependencies between customers of the exchange (beyond their initial agreement to exchange traffic with each other). 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. Stephen VP, Eng. PAIX