re: [RRG] Why not take address depletion issue into account

[Xu Xiaohu <xuxh@huawei.com>]

> 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.
I have no doubt that LISP can works well with NAT. But NAT have been a
serious obstacle for peer-to-peer application. As the peer-to-peer has
become the dominative traffic model, we should not neglect the side-effect
of NAT and the need for end-to-end argument since the new architecture
should suit the future traffic model and application demands.
> > (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).
If you want to deploy v6 EID, which means a change to host, I guess the
EID-RLOC mapping pressure could be lifted from ITR to host during this
transition. In this way, there is no need for the ITR to have cache and
there is no pain of packet loss/delay when cache missing. And there is also
no need for the ITR to hold a whole EID-RLOC mapping database.

Best regards,
Xiaohu XU



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