[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> From: RJ Atkinson <firstname.lastname@example.org>
> 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:
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.