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 |