On Wed, 19 Oct 2005, Todd Vierling wrote:
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