RE: IETF multihoming powder: just add IPv6 and stir

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

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

    > If you follow this argument a bit further, the number of possible paths
    > internal to the core explodes.
    > ...
    > Frankly, there's no way to reasonably support a host path selection
    > feature in the Internet architecture.

Sorry, but this assertion is not correct.

It's true that one cannot support separate state for each individual flow in
the core of the network. Hoever, this does not mean that one cannot support
host path selection, both setup and non-setup (i.e. completely done by the
header of each individual packet).

The problems involved in some of the simplistic approaches to doing host path
selection were brought to my attention many years ago; the first being the one
that you actually (if my memory serves at this great distance) introduced me
to, the necessity to scale router state, as explained in this note:

    http://users.exis.net/~jnc/tech/state_growth.html

There's another related problem with flow setup even with aggregated flows,
which Vadim Antonov first explained to me, which is more of an O(N) problem at
the edges, related to the growth of the overall network.


In any event, after much thought, I've come up with a number of mechanisms
that allow you to provide host path selection in a feasible manner.

One can do a certain amount with address selection - there'a grad student at
MIT called Xiaowei Yang who's doing a PhD on that. I don't happen to like
that approach, I'm not really sure sure why - probably because it feels like
a kludge.

However, with a certain amount of cleverness, and also trading off per-packet
header overhead to reduce per-flow state in the switches, one can do an
amazing amount.

I don't want to bore everyone with a long explanation, and sorry, no it's not
written down, but very briefly, it all depends on having virtual links in the
topology map which correspond to instantiated aggregated flows (and
recursively so). You can either do an end-end flow setup which uses those
virtual links (and the flow stack in the packet header), or you can play all
sorts of interesting tricks with the flow stack to cause packets to take paths
composed of those virtual links, or you can do a mixture of the two.

I not sure if I have that problem Vadim identified with the full-blown
flow-setup case completely licked, but I have some ideas which I think will
do it.


    > There is no way to completely specify the path of a packet without a
    > connection oriented setup protocol.

Source route in the header?

	Noel