Re: GSE

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: RJ Atkinson <rja@extremenetworks.com>

    > I agree with tli, jnc, and others that the best architectural approach
    > to supporting multi-homing while not hosing the operational routers in
    > the DFZ is to separate host identity from routing goop.

Ummm, I think you're somewhat overstating my enthusiasm for separation *as a
solution to multi-homing issues*.

Having said that, part of the problem with discussion of separate host
identification from routing-names has always been that people always seem to
look at the tradeoffs in the context of a single issue: one of the early
rounds of discussion focussed on mobile processes, for example.

I do remain completely convinced that we *do* need to separate host
identification from routing-names, but my enthusiasm comes from a broad
architectural perspective, not a particular case (such as multi-homing).


When I look at multi-homing, as laid out in:

    http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_points.txt
	
I see a very complex cross-product set of goals, and corresponding to that
(and not laid out fully in that note) there are a large range of potential
mechanisms. (There's also an axis in the problem-space which I forgot to
mention, which is "is the 'base address' (a la MIPv6) still online, or is the
rendezvous point unavailable.)

For some goals, (e.g. multi-homing Google) it might indeed make sense to have
the routing do it. For others (e.g. multi-homing a single machine) it's clear
that the routing can't do it. Whether "one size will fit all", I really don't
know. We might wind up with a couple of different mechanisms, each tuned to a
separate part of the problem space.

So, perhaps my comment about "overstating my enthusiasm for separation *as a
solution to multi-homing issues*" now has a little more depth to it.
Separation would indeed be a useful building block in some of the solutions, I
think, but that's all it is - a useful building block in some solutions.

	Noel