multi homing pressure

Wed Oct 19 16:55:52 UTC 2005

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