[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.
| >
| >
| >
|
|