North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: multi homing pressure

  • From: Owen DeLong
  • Date: Wed Oct 19 16:39:14 2005

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


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

Attachment: pgp00038.pgp
Description: PGP signature