Subject: Re: multi-homing vs multi-connecting

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 2 Jan 2003 11:28:51 -0500

> From: Pekka Savola <[email-masked]>

    > 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
there's a useful division at an architectural level, which would be yet
another level of classification, but I'm going to have to ponder that for
a while.

I mean, at some point there is an architectural division where multi-homing
turns into routing - 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.

But I need to think about it more...

    > so it would seem you'd rather place 1.b) under 2) as a network providing
    > multiple prefixes is a already a site.

Yes, you only get 1.b if you have an entire network with multiple addresses,
and you only get that (presumably) if that network is multi-homed, ergo it's
site multi-homing.

So maybe site multi-homing needs to be split up into sub-classes - whether
based on the *mechanism* used to support it (multiple addresses, routing,
whatever), or on some significant *situational* difference (e.g. a stub site
which is multi-homed to different local ISP's, versus some more complex
situation).

    > From IPv4 perspective ... but in IPv6

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

	Noel

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 3 Jan 2003 22:41:45 +0100 (CET)

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

> 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

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.

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

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

Iljitsch

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 6 Jan 2003 06:47:47 -0500

On Friday, Jan 3, 2003, at 16:41 America/Montreal, Iljitsch van Beijnum 
> 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.

Ran