Re: GSE

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

    > From: "Tony Li" <Tony.Li@procket.com>

    >> my comment about "overstating my enthusiasm for separation *as a
    >> solution to multi-homing issues*" .. Separation would indeed be a
    >> useful building block in some of the solutions, I think

    > I will go farther than you on one point: I believe that separating the
    > locator is _absolutely necessary_ to a scalable, workable solution. I
    > have no mathematical proof of this, but the combination of the
    > constraints involved and the aesthetics make it compelling to me.

It all depends on what your specific goals for multi-homing are (and people
keep saying "multi-homing" to refer to a very large set of possible
*different* targets). My multihoming points page:

  http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_points.txt

identifies three different points along the "reliability" axis:

 - Allow new outgoing connections
 - Allow new incoming connections
 - Keep existing connections open

I suspect that one could come up with workable designs for the first two
which don't absolutely need separation of location and identification.


To think about those first two cases for a second, they need either i)
multiple addresses, or ii) support from the routing (so that a single
destination address in a packet gets treated differently depending on the
current topology).

My conclusion is that ii) is only feasible either a) in the case of the
largest organizations, or b) when the multihomed entity has its various
"links" terminate within a topologically limited scope. (The latter, b), would
also require much better abstraction in the routing than we seem to have
today.)


Thinking about the latter, you wind up with a similar set of choices; you need
either i) a way to identify an entity, one which remains constant even in the
presence of multiple addresses, or ii) support from the routing (with the same
caveats as above).

When you think about identifying the entity, you don't have to have a separate
namespace; both MIPv6 and 16+16 use the same namespace, but they both do
explicitly separate identity and location.


Having said all that, I will repeat what I said before:

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

And I will further add that I think those two functions are best served by
separate namespaces (i.e. different syntax and semantics).

I fully realize that engineering considerations, thinking about the current
limited problem domain, may point in other directions.

It is, however, not a role I have any interest in, to attempt to guide the
IPv6 community in whether they are best served by thinking about architectural
improvements, or limited engineering patches.

	Noel