[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Again no multi6 at IETF#56



Tony,

Could you write up your technical idea without a lot of man hours to
describe and why it solves the multihome problem.  I would listen for
one.  But I am suspect of the entire notion of the separation, which
just being technically accute having heard many solutions to this over
the years.  This could not be agreed on regardless of IPv6 all the way
back to NIMROD, which had nothing to do with IPv6.

/jim

 


> -----Original Message-----
> From: Tony Li [mailto:Tony.Li@procket.com] 
> Sent: Sunday, March 16, 2003 1:40 AM
> To: Bound, Jim; Michel Py; Randy Bush; Kurt Erik Lindqvist
> Cc: Bob Hinden; multi6@ops.ietf.org
> Subject: RE: Again no multi6 at IETF#56
> 
> 
> 
> Jim,
> 
> |    >3) Change the semantics of a v6 address.
> |    
> |    So you are not suggesting a syntax change only semantics 
> |    to the 128bits?
> 
> 
> Correct.  If it matters, yes, I don't believe that the 
> current IPv6 approach is the ultimately correct way of 
> approaching things, but I'm not trying to cause a revolution 
> here.  Just prevent v6 from being a total waste of time.  We 
> can work with the 128 bits for now.
> 
> 
> |    But I don't believe location and identification should be 
> |    different. The
> |    address should be overloaded to support both context.I 
> |    believe that is
> |    possible.  The address is both a location and an 
> |    identifier. The IPv6
> |    address supports location top down from the left most bits 
> |    for routing.
> |    So I believe what you ask exists now.
> 
> 
> I'm asking that we separate the identifier and the location.  
> Can't do that if they're one and the same.  I agree that the 
> current semantics are one and the same today.  This is 
> exactly what makes multihoming hard.  
>     
> 
> |    Do you agree with the way we have stated the multi6 problem?
> 
> 
> Not particularly.  But I can state it very succinctly: a host 
> needs one identifier and multiple locators.
> 
> Tony
> 
>