> If I understood correctly, LISP, ivip and other similar proposals  
> are mainly based on one assumption: host should not be changed  
> because the cost of host change is believed to be much larger than  
> that of router change. At least, the recent discussion about the  
> tradeoff between initial packet delay/loss and the scalability of  
> the mapping system is based on that assumption. That is to say, the  
> EID->RLOC mapping query is initialized by the ITR, but not host.  
> Provided that host could be changed and could do the EID-RLOC  
> mapping query on behalf of ITR and carry the obtained RLOC  
> information in the packets, most of the pain discussed recently in  
> RRG mail-list will not exist.

The assumption LISP, in particular makes, is that the design will make  
the least amount of changes to host protocol stacks, host  
configuration files, router code and router configuration files. That,  
with the features documented in the lisp-interworking draft, in my  
book is the true and honest definition of "incremental deployability".

The recommendation for a LISP deployment is to place 2 routers (which  
already exist) at a dual-homed customer/edge site with new LISP code.  
Nothing else in the network has to change. Of course there are various  
cases, if you want to to TE-LISP that an ISP can independently decide  
to run LISP in their domain. And if you want to combine LISP  
encapsulation services and NAT services in one box.

> If the above assumption (host should not be change and still use  
> IPv4) is true, how will LISP, ivip and other similar proposals deal  
> with the address depletion problem? Should we still use

Well an EID/RLOC split adds one new namespace to address systems out  
of. That gives you more addresses on the order of the total  
addressable address space of the namespace's address family (IPv4 or  
IPv6). You could iterate to build multiple levels of hierarchy. Just  
like people have done with multi-level NAT.

> NAT to solve the address depletion issues?  If so, we would have to  
> tolerate the side-effect of NAT on the new application design and  
> deployment, especially peer-to-peer applications which has already  
> accounted for 80% in total internet traffic volume nowadays. Or  
> should we adopt IPv6

My motto is "translate before encapsulate". Because the addresses used  
by the transport protocol are global addresses (one of the addresses  
are global or public where your own is private).

So you combine the encapsulation and address translation services in  
the same box.

We have an existence proof that LISP can work with NAT. That is, when  
implemented in two different boxes in serial. We have on our prototype  
todo list to combine both functionalities in one box.

> (IPv6 can be adopted as EID in the above proposals) to solve the  
> address depletion problem? If so, the change of host is unavoidable  
> and this is conflicted with the basic assumption of the above  
> proposals. Or should we operate on the Internet multiple times to  
> solve the many existing problems one by one? If the deadline of the  
> routing scalability issue is close to that of the address depletion  
> issue, why not solve them in one solution?

That is the intention of LISP. To work with any address family. Hence  
the prototype we are testing, every feature we add gets benefit to  
IPv4 as well as IPv6. And soon, we will have mixed EID-RLOCs (v4 EIDs  
with v6 RLOCs or mixed RLOCs and v6 EIDs with v4 RLOCs or mixed RLOCs).

Dino

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