headers
Pekka Savola | 2 Jan 13:45
Picon

multi-homing vs multi-connecting

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
Permalink | Reply | 0 comments |
headers
J. Noel Chiappa | 2 Jan 16:00
Picon

Re: multi-homing vs multi-connecting

    > From: Pekka Savola <pekkas <at> netcore.fi>

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

Another place where one term, "multi-homing", has been used to cover two
fairly different things are with so-called "site multi-homing" and "host
multi-homing" - the latter being a single host with multiple physical
interfaces.

	Noel
Permalink | Reply | 2 comments |
headers
Pekka Savola | 2 Jan 16:24
Picon

Re: multi-homing vs multi-connecting

On Thu, 2 Jan 2003, J. Noel Chiappa wrote:
>     > 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).
> 
> Another place where one term, "multi-homing", has been used to cover two
> fairly different things are with so-called "site multi-homing"  and
> "host multi-homing" - the latter being a single host with multiple
> physical interfaces.

Hmm.. I group these differently (though I can see why the above could also
be a useful classification), basically:

1) Host multi-homing (strictly speaking, "node" multihoming..)
 a) multiple interfaces and addresses: e.g. a mobile device with both 
GPRS+WLAN interface active
 b) one interface and more addresses: network is providing multiple 
prefixes (of possibly different properties).  It is the _host's task_ to 
deal with the issues.

 * a special case of either a) and b) are mechanisms employing a mapping
function between addresses (HIP, MIPv6 to a lesser degree of success) or
parts of addresses (LIN6).

2) Site multi-homing

 Either something like 3) possibly restricted a bit or the framework for 1)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael H. Lambert | 2 Jan 16:30
Picon
Favicon

Re: multi-homing vs multi-connecting

--On Thursday, 2 January 2003 10:00 -0500 "J. Noel Chiappa" 
<jnc <at> ginger.lcs.mit.edu> wrote:

> Another place where one term, "multi-homing", has been used to cover two
> fairly different things are with so-called "site multi-homing" and "host
> multi-homing" - the latter being a single host with multiple physical
> interfaces.

Is there a fundamental difference in these two "types" of multihoming?  In 
the IPv4 world, I would argue that there is not--it's just that the site 
router has better knowledge with which to make an interface selection than 
does the host (listen to RIP?).

Other than adding the non-trivial problem of source address selection to 
the mix, I don't see that IPv6 changes things.  The distinction seems to 
rest primarily in the WG charter.

Michael

+-----------------------------------------------------------------------+
| Michael H. Lambert, Network Engineer           Phone: +1 412 268-4960 |
| Pittsburgh Supercomputing Center               FAX:   +1 412 268-8200 |
| 4400 Fifth Avenue, Pittsburgh, PA  15213       lambert <at> psc.edu        |
+-----------------------------------------------------------------------+
Permalink | Reply | 0 comments |
headers
J. Noel Chiappa | 2 Jan 17:08
Picon

Re: multi-homing vs multi-connecting

    > From: "Michael H. Lambert" <lambert <at> psc.edu>

    >> two fairly different things are with so-called "site multi-homing" and
    >> "host multi-homing" - the latter being a single host with multiple
    >> physical interfaces.

    > Is there a fundamental difference in these two "types" of multihoming?

Yes, I think - although the two can have an area of overlap where blend into
each other, as you scale up.

If you have a host which is host multi-homed to widely different places in the
topology, it's crystal clear that you can't support this in the routing. (No
global host routes.) Therefore, if you want to do many of the more powerful
robustness things that multi-homing gives you, you have to separate location
and identity, and have that host manage multiple addresses.

(Of course, if you're willing to always have a particular connection associated
with a particular interface, and always use only that interface, then this is
no longer true - but at that point you're doing less powerful robustness
things. This may still be enough, though, in a world in which the connection
is no longer so important, and things like cookies are used to keep track of
the identity of the partner across multiple connections from different
[usually dial-up, but the mechanism works for multiple interfaces] addresses.)

At the other end of the scale, some of the more complex site multi-homing
things can really only be done through the routing (e.g. if you have N local
ISP's which are in turn connected to M global ISP's) - although it often needs
a more powerful routing architecture than the lame one we have now.
(Continue reading)

Permalink | Reply | 1 comment |
headers
J. Noel Chiappa | 2 Jan 17:28
Picon

Re: multi-homing vs multi-connecting

    > From: Pekka Savola <pekkas <at> netcore.fi>

    > I group these differently .. basically:

    > 1) Host multi-homing ..
    > a) multiple interfaces and addresses: e.g. a mobile device with both
    > GPRS+WLAN interface active

I understand the class, but caution you not to use mobile examples because it
will confuse many people... :-)

    > b) one interface and more addresses: network is providing multiple
    > prefixes (of possibly different properties). It is the _host's task_ to
    > deal with the issues.

My reaction to this classification is that you need to be careful not to mix
classifications based on the *kind of problem* one is trying to solve (which
is where my host/site distinction comes from) with classifications based on
the *mechanism* one is using.

Your classification is also an interesting one, but on the surface, because of
your mention of multiple addresses, it's a mechanism classification - not that
that's bad, just different.

Of course, your classification is also in some ways a problem classification,
because the former is the "classical" host/node multi-homing, whereas the
latter is really a subset of site multi-homing; more specifically, that subset
that we've been thinking is best handled with multiple addresses.

After reading Michael Lambert's message, I've been trying to work out if
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Huitema | 2 Jan 19:37
Picon
Favicon

RE: multi-homing vs multi-connecting

>     > Other than adding the non-trivial problem of source address
> selection to
>     > the mix, I don't see that IPv6 changes things.
> 
> Classical IPv6 dosn't. That's a big part of its problems.

Depends what you call classical IPv6. If you throw in the support for
"binding update", then IPv6 does a reasonable job at "host
multi-homing", and I believe that we only need a limited amount of
additional work to support "small site multi-homing"; essentially, you
have to get around egress filtering.

On the other hand, I certainly agree with your assessment of the more
complexes forms of multi-homing, and the data explosion that occurs if
we want to have site connected to N providers also choose the path
through M upstream providers. But we must be aware that the problem here
is not just graph theory; there are also economic/business issues that
affect the willingness of downstream providers to let customers choose
an upstream path.

-- Christian Huitema
Permalink | Reply | 1 comment |
headers
Iljitsch van Beijnum | 3 Jan 21:43
Favicon

Re: multi-homing vs multi-connecting

On Thu, 2 Jan 2003, J. Noel Chiappa wrote:

>     > In the IPv4 world, I would argue that there is not

> The IPv4 world is a second-rate beginner's quick hack in many ways, including
> mobility, routing and multi-homing, and I suggest you delete all knowledge of
> if from your mind. I refuse to discuss it.

This was almost the biggest laugh I had this year... Thanks for that.
(The biggest was "IPv6 will not catch on for the simple reason that it
sucks.", see http://www.kuro5hin.org/comments/2002/8/26/22240/1363/149)

As long as I'm wasting bandwidth: does anyone know of some way to
automatically tunnel IPv4 over IPv6? It seems to me that tunneling v4
over v6 is much more powerful than the other way around, as it could
allow extremely dense use of IPv4 addresses which would be useful during
the transition period.

Iljitsch

PS. Surfing the web with v6 is cool. Shame it's so hard to get a
v6-enabled browser on your Mac. Installing Apache 2 on it is easier...
Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 3 Jan 22:41
Favicon

Re: multi-homing vs multi-connecting

On Thu, 2 Jan 2003, J. Noel Chiappa wrote:

> I mean, at some point there is an architectural division where multi-homing
> turns into routing

I don't think we should try to separate these. There are ways to
multihome without involving routing, but that should never be an excuse
for the routing people to ignore multihoming.

> - e.g. if you have two tiers of upstream providers, local
> ones L1-L3, and global ones G1-G3, all cross-connected, and you want to
> specify which pair traffic to a particular destination takes, that's really a
> routing problem, not a multi-homing problem. Whereas the single host with
> multiple interfaces is clearly multi-homing.

Multihoming makes routing more complex, as it adds more possible paths.
However, wanting to influence routing beyond the immediate next hop
isn't something that fits with our current paradigm. If you really want
this, you need source routing. Doing it partially would be easier:
simply take many addresses and then select the one that has the best
routing properties. For instance, you can use G1/L1, G2/L1, G1/L2 and
G2/L2 addresses and then figure out which of those four address blocks
works best. Obviously this doesn't scale, but it could be useful.

>     > From IPv4 perspective ... but in IPv6

> See previous message! Empty your mind of all this old junk! :-)

"Those who do not remember the past are condemned to repeat it."  :-(
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pekka Nikander | 3 Jan 09:11

Re: multi-homing vs multi-connecting

Christian Huitema wrote:
> Depends what you call classical IPv6. If you throw in the support for
> "binding update", then IPv6 does a reasonable job at "host
> multi-homing",

Well, depends what you mean with reasonable.  With the new
security design, mandated by the desire to make MIPv6 to work
without security infrastructure, MIPv6 always generates some
signalling load.  That is, if a host is away from home, it
must keep sending signalling packets to all its active peers
to maintain the mobility state.  By default the state must be
refreshed about every five minutes.

Furthermore, I don't quite find the requirement of having a
separate home agent, i.e. a piece of infrastructure, as a
reasonable design for multi-homing.

> and I believe that we only need a limited amount of
> additional work to support "small site multi-homing"; essentially, you
> have to get around egress filtering.

Another difficulty is associated with the home agents, too.  If
a home agent is unreachable, the mobile node also becomes unreachable
as soon as it needs to refresh the mobility state, i.e., in about
five minutes.  Thus, you can't simply put a home agent in the
"small site multi-homed" network, that just doesn't work if the
home agent becomes unreachable due to a link failure.

Thus, IMHO, the signalling load and the requirement of having the
home agent always on-line make MIPv6 not-quite-reasonable as a
(Continue reading)

Permalink | Reply | 0 comments |

Gmane