"Firms must defend against ISP clashes, warns Gartner
Commercial row between ISPs shows vulnerability of single sourcing
says analyst"
http://www.computerweekly.com/Articles/Article.aspx?liArticleID=212391
Looks like it's about to enter the corporate rule book
"Gartner said every location that requires mission-critical
internet connectivity, including externally hosted
websites, should be multi-homed"
and end "tier 1" hosting
brandon
it will be interesting to see if this has acutal impact on
ASN allocation rates globally.
- jared
200k routes, here we come!
In a message written on Wed, Oct 19, 2005 at 11:31:32AM -0400, Jared Mauch wrote:
it will be interesting to see if this has acutal impact on
ASN allocation rates globally.
I have done no analysis, but I do believe this is having an effect
on the number of prefixes announced by many of the players involved.
Looking at the top 10-20 peers over here, all of them show prefixes
announced by the peers to be growing faster than the global prefix
table. The only way that makes sense is if existing prefixes are
being announced through additional providers.
It would be interesting to see those more into BGP routing analysis
to look at that (possible) trend. It's probably causing a shift
in how BGP processing occures on both a device and a network level
(more redundant paths) which could have implications for future
gear.
it is just good common sense though, eh? Also, there have been some
pressures through the SOX and other compliance activities to push dual
carrier things in the recent past.
Well, not necessarily.
Tier-2s should be given much more credit than they typically are in
write-ups like this. When a customer is single homed to a tier-2 that has
multiple tier-1 upstreams, and uses a delegated netblock from the tier-2's
aggregations, that means one less ASN and one or more less routes in the
global table.
It's a Good Thing(tm).
tv@duh.org (Todd Vierling) wrote:
Tier-2s should be given much more credit than they typically are in
write-ups like this. When a customer is single homed to a tier-2 that has
multiple tier-1 upstreams, and uses a delegated netblock from the tier-2's
aggregations, that means one less ASN and one or more less routes in the
global table.
That's the operators' view, but not the customer's.
The customer wants redundancy.
So we should try to find a way to tell them "Hey, it's mostly Tier-1's
(or wannabes) that play such games, stick to a trustworthy Tier-2.
And, hey, btw., connect redundantly to them, so you have line failure
resiliency and also a competent partner that cares for everything else."
Only seeing the operators' view will amount to nothing in the customer's
will to run along with the Tier-2.
Eventually, it breaks down to trust. And customers learn that the "big
players" are not always trustworthy. Oh, and customers do not always
remember names.
Yours,
Elmar.
> > > "Gartner said every location that requires mission-critical
> > > internet connectivity, including externally hosted
> > > websites, should be multi-homed"
> >
> > 200k routes, here we come!
>
> it is just good common sense though, eh?Well, not necessarily.
Sorry,
> > > "Gartner said every location that requires mission-critical
> > > internet connectivity, including externally hosted
> > > websites, should be multi-homed"
is common sense. If you have something 'mission critical' to your business
you had better have more than one link out... It'd make great sense to
make sure that the links in question atleast didn't end up on the same
router at the far end, and while you are at it, get them to different
providers (hopefully) in different telco-hotels.
Tier-2s should be given much more credit than they typically are in
write-ups like this. When a customer is single homed to a tier-2 that has
multiple tier-1 upstreams, and uses a delegated netblock from the tier-2's
aggregations, that means one less ASN and one or more less routes in the
global table.
I'm not such a believer in the tier-n classifications, single homing a
critical resource is just dumb, regardless of the 'tier' you stick it in.
gartner, as gartner normally does, is just stating the obvious and making
money doing it.
For you.
For the customer with an Internet "mission critical app", being tied to a Tier 2 has it's own set of problems, which might actually be worse than being tied to a Tier 1.
The Internet is a business tool. If providers do not meet business requirements, providers will not be supported. Period.
If 200K routes, or more ASNs, or small customers multihoming, or stuff like that scares you, find another line of work. (Hint-hint to the v6 fanatics.)
I think this is largely dependant on the specific topology and
redundancy in the Tier-2's network and the way they provide multiple
uplinks. When done well, with uplinks spread over separate physical
locations, well thought out IP adressing and de-centralised exits from
the Tier-2's network out to multiple Tier-n's, there's usually a benefit
to multi-homed connections to a Tier-2 rather than a Tier-1, with
minimum capacity and pricing being the most important ones.
patrick@ianai.net (Patrick W. Gilmore) wrote:
For the customer with an Internet "mission critical app", being tied
to a Tier 2 has it's own set of problems, which might actually be
worse than being tied to a Tier 1.
Please elaborate.
Elmar.
> Tier-2s should be given much more credit than they typically are in
> write-ups like this. When a customer is single homed to a tier-2 that has
> multiple tier-1 upstreams, and uses a delegated netblock from the tier-2's
> aggregations, that means one less ASN and one or more less routes in the
> global table.That's the operators' view, but not the customer's.
The customer wants redundancy.
That's why SLAs exist.
So we should try to find a way to tell them "Hey, it's mostly Tier-1's
(or wannabes) that play such games, stick to a trustworthy Tier-2.
And, hey, btw., connect redundantly to them, so you have line failure
resiliency and also a competent partner that cares for everything else."
Something like that, but not quite. Whenever one of these reports, which
boil down to "everyone must multi-home!", appears, it typically has a stark
lack of information on alternatives to *direct* multi-homing.
Many customers would rather not multihome directly, and prefer "set it and
forget it" connectivity. It's much easier to maintain a multi-pipe
connection that consists of one static default route than a pipe to multiple
carriers. The former requires simple physical pipe management, which can be
left alone for 99% of the time. The latter requires BGP feed, an ASN, and
typically much more than 1% of an employee's time to keep running smoothly.
Obtaining single-homed connectivity from a Tier-2 mostly "outsources"
network support, and small to medium size businesses tend to like that.
It's not the only leaf end solution to the problem, but it's a viable one
(and can be less costly to the rest of the world in turn).
I probably used poor word choice. The "Tier" of a provider is just marketing unless you are talking about the networks in the "DFZ" ("SFI club", or whatever). When I made that statement, I was thinking more about the marketing hype, meaning a "tier two" not only has transit, but is a smaller, probably regional provider. Naturally, a "tier two" might very well be a huge company with network assets on multiple continents and 10s of Gbps (or more) of traffic.
The problems with a small provider might include:
* Business viability
* Global reach
* Capacity
* Redundant architecture
* Etc., etc., etc.
Depends on the customer which of these are important. The guy with 10 Mbps of traffic all in Nashville, TN doesn't care about global reach or capacity, but might be VERY interested in redundant architecture & business viability. A mom-n-pop shop might not be the right choice for him.
The guy with 12 datacenters in 6 states - or countries - might have different ideas of what is important. Maybe he's OK with one site going offline one day a year if he can save $10K on transit costs, so a mom-n-pop shop would be fine.
Personally, I think if your application really is "mission critical", then you _must_ be multi-homed with your own space and own ASN. Anything less and you've tied your business to a vendor. I might like some networks, but I don't want my corporate life & death to be tied to any of them when I can ensure my independence for what is probably a small sum of money in the grand scheme of things.
The question of which providers to use as upstreams is a business decision based on the items above, cost, and lots of other stuff.
Sorry if I was unclear before.
patrick@ianai.net (Patrick W. Gilmore) wrote:
The problems with a small provider might include:
* Business viability
* Global reach
* Capacity
* Redundant architecture
* Etc., etc., etc.
Thanks - understood 
I see, btw, a lot of Tier-3 (or -4, -5) providers that have easily
survived their Tier-2 Transits going down the river.
If customers can be convinced that the tier thing has nothing to
do with business viability and/or stability, and that size does
not always matter, we might get them on the right track.
As long as they believe the marketing-speak, that Tier-1 ISPs
are god (no double-o here) and Tier-2's are still quite good,
but everything else is crap for "real" business, well...
Always remember: For every customer, their stuff _is_ mission
critical. So everyone will take the multihoming road if they
can afford it.
We can make it more expensive, or we can offer other solutions.
Yours,
Elmar (formerly with a Tier-17, quite stable though)
Do SLA's say "if you are out of the water for 30 minutes we will also cover your lost business revenue?" There are some times with service guarantees just are not enough (e.g., manned space flight support).
There is no such thing as an SLA on the Internet that is worth what you lose when the line goes down.
Part of the problem of paying so little for a "mission critical" application.
And part of the reason multi-homing is so important for a "mission critical" application.
That's the operators' view, but not the customer's.
The customer wants redundancy.That's why SLAs exist.
SLAs exist to provide a means of allowing a vendor to 'feel your pain' when you experience some type of a service outage. They generally do not exist to act as a cost recovery mechanism for customers who lose revenue when mission critical app XYZ can't access 'the network', people coming in from 'the network' cannot access it. Being able to deduct some percentage of your monthly spend with your carrier often doesn't balance well against a network outage that affects the mission critical app that brings in a substantial percentage of the company's revenue.
Each organization's tolerance for outages (read: revenue impact) must be weighed against the costs of multihoming and making the investments in infrastructure to improve relibility.
Something like that, but not quite. Whenever one of these reports, which
boil down to "everyone must multi-home!", appears, it typically has a stark
lack of information on alternatives to *direct* multi-homing.
Hence Chris's earlier post about the multitude of think tanks which exist to state the obvious and make a buck while doing it 
Many customers would rather not multihome directly, and prefer "set it and
forget it" connectivity. It's much easier to maintain a multi-pipe
connection that consists of one static default route than a pipe to multiple
carriers. The former requires simple physical pipe management, which can be
left alone for 99% of the time. The latter requires BGP feed, an ASN, and
typically much more than 1% of an employee's time to keep running smoothly.
I disagree with some of this. I've set BGP up for customers before on many occasions. Many were quite happy with a primary-backup mode of connectivity, which can be accommodated by getting an ASN, configuring BGP on your router(s) and with your upstreams, announcing your route(s) and accepting a default route from those upstreams. My experience has been that these types of setups are also pretty much 'fire and forget' as far as the customer is concerned - *once they're up and running*. If customer XYZ doesn't have the expertise in-house to set it up, they will often bring in a consultant to do it. I do agree that the process of applying for an ASN and so forth can take some time, but it's typically a one-time process.
Customers who want to actually attempt to tune traffic to fit the size of
their pipes are the ones who require much more time in the maintenance of their BGP environment, and often have higher capex and opex to go with it (bigger router to handle full BGP feeds, $router_vendor support contracts for same, etc).
Obtaining single-homed connectivity from a Tier-2 mostly "outsources"
network support, and small to medium size businesses tend to like that.
It's not the only leaf end solution to the problem, but it's a viable one
(and can be less costly to the rest of the world in turn).
That depends greatly on the business need that drives the decision in the first place. Plus, some organizations are finding that locating critical service outside of their borders either voliates their security policies, or can hamper compliance with outside security mandates (GLB, SOX, HIPAA, etc). Maintaining compliance + improving reliability can motivate organizations to multihome.
jms
Date: Wed, 19 Oct 2005 12:20:25 -0400 (EDT)
From: Todd Vierling
That's why SLAs exist.
I thought SLAs existed to comfort nontechnical people into signing
contracts, then denying credits via careful weasel words when the time
comes for the customer to collect. Or maybe I'm just cynical.
Many customers would rather not multihome directly, and prefer "set it and
forget it" connectivity. It's much easier to maintain a multi-pipe
connection that consists of one static default route than a pipe to multiple
carriers. The former requires simple physical pipe management, which can be
left alone for 99% of the time. The latter requires BGP feed, an ASN, and
typically much more than 1% of an employee's time to keep running smoothly.
Single carrier + multiple POPs != difficult. Even a lowly 2500 can be
loaded up with a carrier-assigned private ASN and fed a couple routes.
(Maybe it's a little more complex when one needs equal-cost multipath,
but it's still hardly rocket science.)
Obtaining single-homed connectivity from a Tier-2 mostly "outsources"
network support, and small to medium size businesses tend to like that.
See above.
It's not the only leaf end solution to the problem, but it's a viable one
(and can be less costly to the rest of the world in turn).
Eddy
For the customer with an Internet "mission critical app", being tied
to a Tier 2 has it's own set of problems, which might actually be
worse than being tied to a Tier 1.
The key word is "might". In fact, I would posit that a Tier 2 with multiply redundant transit to all of the Tier 1s could theoretically have better connectivity than an actual Tier 1. The Tier 2 transit provides flexibility that the transit-free Tier 1s do not have. Just my opinion.
Anyway, it has been my experience that most (but not all) of the customers that want to "multihome" are _really_ wanting either: A. geographic/router redundancy. or B. easy renumbering. Geographic redundancy can be done within a single AS and IP block. They just don't know to ask it that way. (And easy renumbering will eventually be solved with v6. Eventually.)
The demand for multi-homing might not be as great as suspected.
John
For the customer with an Internet "mission critical app", being tied
to a Tier 2 has it's own set of problems, which might actually be
worse than being tied to a Tier 1.The key word is "might". In fact, I would posit that a Tier 2 with multiply redundant transit to all of the Tier 1s could theoretically have better connectivity than an actual Tier 1. The Tier 2 transit provides flexibility that the transit-free Tier 1s do not have. Just my opinion.
Anyway, it has been my experience that most (but not all) of the customers that want to "multihome" are _really_ wanting either: A. geographic/router redundancy. or B. easy renumbering. Geographic redundancy can be done within a single AS and IP block. They just don't know to ask it that way. (And easy renumbering will eventually be solved with v6. Eventually.)
It has been my experience that most needing to multihome wish to do so to avoid failures within an ISP, failures with a circuit to the ISP, and failures with routers.
I should think that with the recent L3/Cogent issue, it should be QUITE clear that multihoming requires linking to two separate backbones, or two separate regionals that buy transit from multiple backbones. Vagaries in backbone providers is high on the list, IMO, and rules out the "multihome to a single provider" approach.