RE: IETF multihoming powder: just add IPv6 and stir

["Tony Li" <Tony.Li@procket.com>]

Noel,

The architecture that you describe is no longer the Internet
architecture.  Yes, ok, it's sorta vaguely like it, but it is
NOT the architecture that folks have in mind when they say that
they want to preserve host path selection.  Or have 'smart'
hosts.

Putting a source route in the header (or deeper) in the packet
has been tried and firmly rejected.  People want the ability
to select paths, but are unwilling to pay for it.

Tony


|    -----Original Message-----
|    From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] 
|    Sent: Saturday, May 03, 2003 6:53 PM
|    To: multi6@ops.ietf.org
|    Cc: jnc@ginger.lcs.mit.edu
|    Subject: RE: IETF multihoming powder: just add IPv6 and stir
|    
|    
|        > 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
|    
|