What is multihoming was (design of a real routing v. endpoint id seperation)

Mon Oct 24 09:24:57 UTC 2005

--On October 24, 2005 10:01:21 AM +0100 Michael.Dillon at btradianz.com 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20051024/969ca00d/attachment.sig>