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

RE: Architectural approaches to multi6




Indeed.  If, in fact, we can convert upper layers to deal
with just the identifiers, we would be very close to done.  ;-)

Tony


|    -----Original Message-----
|    From: Bound, Jim [mailto:Jim.Bound@hp.com] 
|    Sent: Monday, March 24, 2003 2:57 PM
|    To: Iljitsch van Beijnum
|    Cc: RJ Atkinson; multi6@ops.ietf.org
|    Subject: RE: Architectural approaches to multi6
|    
|    
|    OK that is fair.
|    /jim
|    
|     
|    
|    
|    > -----Original Message-----
|    > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] 
|    > Sent: Monday, March 24, 2003 5:48 PM
|    > To: Bound, Jim
|    > Cc: RJ Atkinson; multi6@ops.ietf.org
|    > Subject: RE: Architectural approaches to multi6
|    > 
|    > 
|    > On Mon, 24 Mar 2003, Bound, Jim wrote:
|    > 
|    > > > 3: remove addresses from all places in the protocol stack 
|    > above the IP
|    > > >    layer. If higher layers are unaware of addresses and 
|    > the addresses
|    > > >    follow the topology, IP can route around failures 
|    by changing
|    > > >    addresses.
|    > 
|    > > Wearing my IP stack product developer hat.  Errrrr maybe in 
|    > the year 
|    > > 2050 if we start now.  The entire stack on end systems 
|    and routing 
|    > > code on embedded systems I have worked with have 
|    addresses not only 
|    > > embedded but permeated through all layers.  I see the 
|    > vision but don't 
|    > > have to be real here?
|    > 
|    > Yes, we have to be real at some point but not just yet. First 
|    > we have to determine if 3. has merit.
|    > 
|    > And I have reason to believe transition won't be as hard as 
|    > it may seem at first glance.
|    > 
|    > 
|    > 
|    
|