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. 

 

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

 

I doubt why the draft-irtf-rrg-design-goals-01 doesn't take the IPv4 address
depletion into account for a new routing and addressing architecture.

 

Best regards,

Xiaohu XU

 

Reply via email to