If this is for redundancy, also keep in mind that most 'cuts' occur
in the last mile. Unless you are in a major facility with engineered
entrance/egress diversity a failure will result in ALL terrestrial
links failing. This is a very string argument for a limited
bandwidth satellite or EVDO backup link. (Which one depends on many
other factors.)
Tim McKee
VP, Network Services
SDN Global <http://www.sdnglobal.com>
On Jul 18, 2007, at 7:44 PM, [EMAIL PROTECTED] wrote:
Hi Daniel,
Could you provide a little more detail as to your requirements?
Bandwith, applications (voice, video, etc...) number of sites, that
sort of thing. On the surface the first thing that comes to mind is
redundancy. You are going to have outages, especially if you have
to go that far point to point. The best thing would be to have a
second circuit with another carrier on a diverse path. The worst
thing is when both the primary circuit and the backup were ordered
through the same carrier and both go down during the came fiber
cut. Worse still is when they were ordered from two different
carriers but carrier B actually bought bandwidth from carrier A
resulting in the same outcome.
Daniel <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
07/16/2007 05:37 PM
To
nanog@nanog.org
cc
Subject
Carrier Recommendations
All,
I am currently in the process of evaluating carriers for future
expansion into international regions, primarily Asia, Europe and
South America.
I am comfortable with AT&T and Verizon however I would like to make
sure I include all the major players and would like your direct
feedback and commentary in regards to any of them.
These are the key areas I am concerned with.
Support
Reliability
Flexibility
Complexity
Coverage
I am looking at two deployment options as well if anyone would like
to comment.
1) A single carrier for global connectivity to all sites (mpls etc)
2) A single carrier for global regional connectivity, and in
country/regional carriers for all local offices that funnel back to
regional aggregation points.
Any insight would be greatly appreciated.
Thanks, Daniel
=====
Tim McKee