Finally, a small commentary
smd at sprint.net
Fri Jan 20 07:28:19 UTC 1995
I shall try to bring a Sprint fibre-map on a slide
to NANOG as that will clarify why we changed our current
engineering plan from this:
| | |
| | |
| / \ |
| \ / |
(SEAttle WA, CHIcago IL, PENnsauken NJ
STocKton CA, Kansas City MO, CHEyenne WY,
NAShville TN, ANAheim CA, ForT Worth TX,
The idea was not to make a backbone which
looks like the Sprint logo in a box. :)
Most of the new design evolved out of a plan to build a POP
in Cheyenne WY to save on back-haul costs bettween
SprintLink and customers in places like Denver and
Salt Lake City.
The fibre paths support either model fairly well,
but the general impression is that we can save
on DS3 and backhaul mileage (both of which are
expensive) under the newer plan, assuming we
are running forward with Cheyenne.
Also, the new plan better matches east-west traffic
flow to the current fibre plant, something we are keen on
doing so we can avoid longer-than-necessary north-south detours.
Finally the switching delay in a series of nominally working
Cisco routers in either of the paths above is in many cases
less than the added speed-of-light delay through Kansas City.
(There is a phone company HQ in Kansas City that tends to
slow down passing photons...)
Ideally we will settle finally on a plan that strikes a good
balance between delays through our POPs vs. delays between
Provisioning and build-out will start towards the end
of this quarter.
P.S.: Oh, I should reiterate that this is a purely defensive
backbone design that is based on the assumption that
we will scale upwards from DS3 quickly (we anticipate OC3 or
4xDS3 by the end of the year; which depends on whether we
have multiple OC3 customers or not), that we have no real
idea where inter-carrier touchdown points will evolve beyond
the NAPs, MAEs and so forth (we see a need for one in the
Texas area already, for example), that we have no concrete
idea of what our aggregate egress/ingress bandwidths will be
("big") or how much of a bias we will see towards the D.C.
and San Francisco areas as opposed to elsewhere, and
finally, we are not fully certain where we will see a big
need to build local POPs. All of this means we need to
remain flexible and adaptable first and foremost.
I am not terribly fond of the model for reasons I explained
at IETF, however, given what we know and what we can
anticipate and what we *can't* anticipate, the current
designs are, imho, fairly reasonable compromises.
More information about the NANOG