Finally, a small commentary
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: SEA-------CHI------PEN | | | STK-------K.C.-----D.C | | | ANA-------FT.W.----ATL to this SEA-------CHI------PEN | / \ | STK---CHE< >NAS--D.C. | \ / | ANA------FT.W.-----ORL (SEAttle WA, CHIcago IL, PENnsauken NJ STocKton CA, Kansas City MO, CHEyenne WY, NAShville TN, ANAheim CA, ForT Worth TX, ORLando FL) 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 our POPs. Provisioning and build-out will start towards the end of this quarter. Sean. 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.
participants (1)
-
Sean Doran