North American Network Operators Group

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

Re: What is multihoming was (design of a real routing v. endpointid seperation)

  • From: Owen DeLong
  • Date: Mon Oct 24 05:27:27 2005

--On October 24, 2005 10:01:21 AM +0100 [email protected] wrote:


> the market wouldn't
> feel the need to have to dual home.

the internet model is to expect and route around failure.
Seems to me that there is some confusion over the meaning
of "multihoming". We seem to assume that it means BGP multihoming
wherein a network is connected to multiple ASes and uses BGP
to manage traffic flows.

As I understand it, the term multihoming in a network operations
context is defined as:

(A multihomed network is)
A network which is connected via multiple distinct
paths so as to eliminate or reduce the likelihood that a single
failure will significantly reduce reachability.

Note, this is independent of the protocols used, or, even of
whether or not what is being connected to is the internet.
So, it does not assume BGP.  It does not assume an AS.

Now, in the context of an ARIN or NANOG discussion, I would expect
to be able to add the following assertions to the term:

1.	The connections are to the internet.  A connection which
	is not to the internet is of little operational
	significance to NANOG, and, ARIN has very little to
	do with multihoming in general, and, even less if it is
	not related to the internet.

2.	The connections are likely to distinct ISPs, although, in
	some cases, not necessarily so.  Certainly, if one is to
	say one is addressing the issues of multihoming, then,
	one must address both values for this variable.

3.	Most multihoming today is done using BGP, but, many other
	solutions exist with various tradeoffs.  In V6, there is
	currently only one known (BGP) and one proposed, but,
	unimplemented (Shim6) solution under active consideration
	by IETF. (this may be untrue, but, it seems to be the
	common perception even if not reality).

Other people use this term in very different ways. To some people
it means using having multiple IP addresses bound to a single
network interface. To others it means multiple websites on one
server.

That is not multihoming.  That may be an implementation artifact
of some forms of multihoming (using the addresses assigned by
multiple providers ala Shim6 proposal), but, multiple addresses
on an interface do not necessarily imply multihoming.  In fact,
more commonly, that is virtual hosting.

And to many consumers of network access it is a synonym for
redundancy or resiliency or something like that. BGP multihoming
is not the only way to satisfy the consumers of network access
and design a solution in which failure is expected and it is
possible for the customer to route around failure.

It certainly is one component of a redundancy/resiliency solution.

A single tier-2 ISP who uses BGP multihoming with several
tier 1 ISPs can provide "multihoming" to it's customers
without BGP. For instance, if this tier-2 has two PoPs
in a city and peering links exist at both PoPs and they
sell a resilient access service where the customer has
two links, one to each PoP, then it is possible to route
around many failures. This is probably sufficient for most
people and if the tier-2 provider takes this service seriously
they can engineer things to make total network collapse exteremely
unlikely.

As long as you are willing to accept that a policy failure in
said Tier2 ISP could impact both pops simultaneously, and,
accept that single point of failure as a risk, then, yes,
it might meet some customers' needs. It will not meet all
customers' needs.

Another way in which consumer's could be "multihomed" would be
to have their single access link going to an Internet exchange
where there is a choice of providers. If one provider's network
fails, they could phone up another provider at the exchange and
have a cross-connect moved to restore connectivity in an hour or
so. This will satisfy many people.

Again, there are tradeoffs and risks to be balanced here as there
are multiple single points of failure inherent in such a
scenario.  However, at the IP level, such a network would, indeed
be multihomed.  The layer 1 and 2 issues not withstanding.

Of course there are many variations on the above theme. This is
an issue with multiple solutions, some of which will be superior
to BGP multihoming. It's not a simple black or white scenario.
And being a tier-1 transit-free provider is not all good. It may
give some people psychological comfort to think that they are in
the number 1 tier, but customers have good reason to see tier-1
transit-free status as a negative.

I'm not sure why you say some are superior to BGP multihoming.
I can see why some are more cost effective, easier, simpler
in some cases, or, possibly more hassle-free, but, the term
superior is simply impossible to define in this situation,
so, I'm unsure how you can categorize something as superior
when the term can't be defined sufficiently.

Owen


--
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.

Attachment: pgp00050.pgp
Description: PGP signature