Subject: multi-homing vs multi-connecting

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Jan 2003 14:45:15 +0200 (EET)

Hello,

There is one interesting issue brought up in 
draft-ietf-multi6-v4-multihoming-00.txt; there the terms "multi-homed" 
(always different ISP's) and "multi-attached" (same ISP) are separated.

I don't think this terminology has been well established?  At least as far 
as I've seen, multihoming has been used to refer to both (to some extent).

But nonetheless, the separation is interesting.

Multi-attaching, used with some techniques, provides a number of
protections against failure modes people often want to cover when
requiring multi-homing.  The main thing it does not provide is the ability
to switch providers at will with little effort (but then again, some other
proposals like draft-kurtis-multihoming-longprefix do not provide that
either).

Is it necessary to require a solution to "real" multi-homing problem
provided that multi-connecting mechanisms would provide a sufficient level
of control and protection?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Mon, 6 Jan 2003 11:00:47 -0500

> From: RJ Atkinson <[email-masked]>

    >> Multihoming makes routing more complex, as it adds more possible paths.

    > That is true of current IPv4 multi-homing, when talking about
    > inter-domain routing. It is NOT necessarily true for all approaches to
    > IPv6 multi-homing. In fact, it might be preferable to select an approach
    > that minimises the complexity increase on inter-domain routing due to
    > multi-homing.

I think we probably ought to distinguish between several different kinds of
"the routing is involved in this multi-homing solution".

On the one extreme, there's the "this thing has only one routing-name, and the
normal path-selection algorithm is always generating routes to it through
currently working links" - in other words, the current IPv4 multi-homing model.

But there are numerous others, e.g. Dave Clark's old "route fragments" idea
(and sorry, I don't have a citation for it), where along with the destination
"address", you get back a number of source route fragments, leading from
"large" topology elements your local router probably does know about (e.g.
major international ISP's) to the destination via various access paths to that
destination.

It's important to realize that, fundamentally, multi-homing (of *all* kinds)
*is* just a path-selection - i.e. routing - problem. I.e. there's more than
one way to get to the destination host, and somehow everyone/thing involved
has to get together to i) work them out, and ii) select one.

The problem is that the straightforward ways of doing this, ones that work in
a small network, don't work in something the size of the Internet because the
routing overhead explodes. So then you start trying to reduce the amount of
work; perhaps by offloading some of the work in various ways (some of which do
not look like routing).

Sure, there can be other non-routing implications, e.g. if you decide that the
you're going to use is multiple "addresses", then you have to deal with the
"how do I tell that address A and address B refer to the same host, the I'm
talking to" (provided of course that that problem is one you care about).

But basically multi-homing turns into a path-selection (i.e. routing) problem.

	Noel

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 6 Jan 2003 09:32:29 -0800

> Sure, there can be other non-routing implications, e.g. if you decide
that
> the
> you're going to use is multiple "addresses", then you have to deal
with
> the
> "how do I tell that address A and address B refer to the same host,
the
> I'm

Yup. The multiple addresses vs. single address decision is really an
implementation choice; the multiple addresses (or locators) solution is
basically a decision to move the complexity out of the routing system
and into the hosts. It does not remove the need to uniquely identify the
"host", if only as the closure of the equivalence relation "address A
and address B lead to the same point"; it simply removes the need to
have the routing system be aware of the identity relation. Arguably, it
also removes the opportunity for the routing system to do smart things,
but that is precisely the trade-off.

Obviously, there may be multiple paths leading to each of the multiple
addresses, so the decision is not strictly binary.

-- Christian Huitema