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

[Dino Farinacci <dino@cisco.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.

I hope you are not saying that a Loc/ID split solution should solve  
this problem with NATs? There are solution to solve this in NATs. So  
LISP, colocated with a NAT will take advantage of the solution.

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

No, not at all. Hosts support IPv6 today. So there are no further  
changes. You run IPv6 in hosts and routers at a site. The ISPs can run  
IPv4 or IPv6 as they choose.

> EID-RLOC mapping pressure could be lifted from ITR to host during this

What do you mean by lifted?

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

1) If you put Loc/ID functionality in hosts, then they will have to  
change. Don't want to
   do this because it kills deployability.
2) The packet loss/delay is for the first packet of the first flow  
between two sites. This is
   pretty minor and people have blown this out of porportion.
3) The ITR need not hold the entire mapping database. There is an  
option to do so, but it's not
   required and arguably not needed.

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