nanog mailing list archives

Re: multi homing pressure


From: Owen DeLong <owen () delong com>
Date: Wed, 19 Oct 2005 13:37:24 -0700

That's the operators' view, but not the customer's.
The customer wants redundancy.

That's why SLAs exist.

No... SLAs exist to extract some compensation when the level of service
doesn't meet the need.  In a mission critical situation, SLAs are
pretty worthless.  The primary benefit of an SLA is that it (hopefully)
provides incentive to the provider to avoid screwing up the service.
It doesn't directly do anything to directly improve the service or
restore service from an outage.


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've done simple ASN/BGP based multihoming for a number of businesses, and,
it can be done on a mostly set-and-forget basis.  If you have your upstreams
supply 0.0.0.0/0 via BGP and no other routes, and, you advertise your
networks, believe it or not, that's a pretty stable configuration.  If
your upstreams are reasonably reliable, that works pretty well.  If not,
and, you care about knowing what your upstreams can't reach at the moment,
then, you need a full feed and life becomes slightly more complicated.

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).

It's also not a complete solution to the problem.  Sure, there are a class
of customers whose needs that meets.  However, because this meets some
needs does not mean that it is legitimate to pretend that other needs do
not exist.

While we're at this, I'll debunk a few common myths:

Myth:   Renumbering pain is proportional to network size.
Fact:   Renumbering pain is proportional to the number of devices
        which need to be touched over which you do not have
        administrative control.  A /16 which is entirely under my
        control and which is not present in ACL and other entries
        outside of my control is much easier to renumber than
        a /24 which contains a bunch of VPN terminators and
        serves 10,000s of customers who all have my addresses
        in their VPN boxes and ACLs on their firewalls.

Myth:   The need to multihome is proportional to the size of
        the organization.
Fact:   Some large organizations have only a few critical needs for
        the network and those needs are easily colocated in other
        facilities.  For the rest of their use, being single-homed
        or multi-piped to a single provider is quite adequate.

        Some small organizations, OTOH, cannot function if their
        access to the network is impaired.  For these organizations,
        multihoming is not only important, it's life and death.

Myth:   PI space is not needed in IPv6 because we fixed the need.
Fact:   PI space in IPv6 scares people because of the potential
        for unconstrained routing table growth.  What is needed
        is to fundamentally change the way we do routing.  IPv6
        stopped well short of this goal, and, as such, provides
        little benefit beyond the original TUBA proposal, having
        decided that all of the real problems that needed to be
        solved were "too hard".  IPv6 does nothing to eliminate
        the need for PI space and ASNs at end sites that need
        to be truly multihomed.  Shim6 is an attempt at
        providing some level of workaround to this deficiency,
        but, for full functionality, it requires significant
        implementation on all affected end-nodes and some
        of the routing infrastructure.  For now, it's just
        a pipe dream.  In the long-run, it's a very complex
        hack to replace what could be a relatively simple
        correction.


Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.

Attachment: _bin
Description:


Current thread: