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