RE: IETF multihoming powder: just add IPv6 and stir

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

Hmm.  I really don't want to add fuel to the fire on these issues, but I feel
that it is important to respond to these criticisms because I don't agree with
the analysis.  See the end of the messag for some further comments.


On Fri, 2 May 2003, Christian Huitema wrote:

> > > I am not sure I want to say that we recharter to the GSE++ model. I
> > > think we need to recharter mainly to update the milestones and also
> to
> > > perhaps change the charter somewhat.
> > 
> > Ok, the charter isn't the most important thing, what we want to
> > accomplish is.
> 
> Frankly, I don't believe that there is all that much value in the
> so-called "GSE++" model. I see many shortfalls:
> 
> 1) Rewriting addresses in the site exit routers deprives smart hosts
> from the capacity to select their preferred return path;

I proposed that this only need be done for hosts which are not MH aware.

> 
> 2) There is a lot of ambiguity as to whether the proposed identifiers
> relate to an interface, a host or a session, and these choices lead to
> extremely different trade-offs;

I don't know what you mean by this.  I thought they referred to whole sites.

> 
> 3) We know from previous discussion that 64 bits is too short for a
> randomly assigned global space;

I thought we were talking about a M + S + 64 bits address space where the M
bits can be guaranteed globally unique and the S bits are managed by the site. 
For the purposes of global routing, this is unique enough to guarantee no
collisions.  The uniqueness of the 64 bits within the local segment are managed
by existing mechanisms of address autoconfig.

> 
> 4) It is kind of too late to rewrite the TCP implementations that are
> already out there.

Yes, but such a proposal can work with mixed TCP implementations.  The only
difference between the two is whether to modify addresses at the edge or in the
stack.  I'm sure there must be a way to arrange it so that the end hosts can
choose to do the translation themselves.

> 
> In fact, if we really want to go towards this independent identifier
> path, I believe we should make it a session identifier, used by some
> form of TCP++. Using it for routing does not appear all that practical.
> 
> -- Christian Huitema
> 
> 
> 

I might add an out of band comment about the political issues surround this
whole MH debate.

I am agnostic about which proposal(s) make it and at the end of the day will
support whatever proposal is chosen.  I haven't got the time (I have plenty of
other work to do) or money (can't afford to go to IETF meetings) to be an
activist for any particular proposal and I don't need the karma points for my
career.  All I care about is whether in 10 or 20 years time that whatever's in
place will work well and history will show that the right decision was made.

It's for these very reasons that I haven't invested a great amount of time into
a formal proposal that everyone can pull apart.  I am happy to throw ideas into
the arena and chew them over, but until a firm direction is established and
there is overwhelming support for that direction I'm reluctant to spend any
more time than is necessary on the debate. 

Regards

Peter
--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210