RE: [RRG] loc/id split and HIP (was LISP)

[Sheng Jiang <shengjiang@huawei.com>]

Pekka,

I don't misunderstand the HIP concept. Let's end our argument here. I know
HIP can work with legacy IP applications. You made it clear enough in your
hip-application draft, in section 3.

Back to my original points, I did not attack HIP as a solution. What I was
saying was there are deployment costs to pay, either by applications or by
mapping systems.

Regards,

Dr. Sheng JIANG

IP Research Department, Networking Research Department, Network Product
Line, Huawei Technologies Co. Ltd.

*-----Original Message-----
*From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf Of Pekka
Nikander
*Sent: Wednesday, October 10, 2007 11:52 AM
*To: Sheng Jiang
*Cc: Routing Research Group list
*Subject: Re: [RRG] loc/id split and HIP (was LISP)
*
*>> Hence, the [limitations w.r.t mobility] in the draft refers only
*>> to the case where you basically want to preserve existing Internet
*>> semantics, i.e., an IP address points to the host *currently*
*>> reachable at the location.  Then, if the host moves, those UDP
*>> applications that cache the address break today.  In this
*>> scenario, HIP doesn't change anything since we don't want to
*>> change the semantics.
*>>
*>> If you willing to work with different semantics where the meaning
*>> of an IP address is changed somewhat, you can "fix" the situation
*>> and make also UDP applications to work, even when they do cache IP
*>> addresses.  That won't be simple and it will configuration would
*>> be ugly -- therefore we don't recommend it.  It would be better to
*>> use LSIs (which would have different semantics anyway) or,
*>> preferably, HITs.
*>
*> Pekka, I think you mis-understood what I meant originally. When I
*> said "ALL applications to be modified in order to support HIT", I
*> referred to those applications that use IP as identifier within
*> their implementations.
*
*I don't think I misunderstood you.  When I wrote about legacy
*applications, I really meant legacy applications that use IPv4
*addresses directly in their data structures and configuration files.
*
*I really mean that you *can* make HIP to work with such legacy
*applications, but you pay for it.  In practise you have to have some
*"local" configuration (not necessarily host-local, though) that
*statically binds such statically used legacy IPv4 addresses into
*HITs.  That changes the semantics that people generally expect about
*IPv4 addresses today; OTOH, such changed semantics would be closer to
*what people expected from IPv4 addresses before NATs, DHCP, and
*mobility.
*
*--Pekka Nikander
*
*PS.  All that I'm trying to do here is to correct some common
*misconceptions about HIP.  You are not alone thinking that HIP
*doesn't work with legacy IPv4 applications, while it does.
*
*As I have written a few times, I don't think that HIP, as it is
*today, would be able to solve the routing table scalability problem.
*See my previous messages for what would be needed in order to HIP
*help there.
*
*
*--
*to unsubscribe send a message to rrg-request@psg.com with the
*word 'unsubscribe' in a single line as the message text body.
*archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg