> 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. Some other id/loc split proposals including SIX/ONE, NODE ID and HRA can kill these two "birds" with one stone. > > If you want to deploy v6 EID, which means a change to host, ... > 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. Can most of the hosts and internal routers within site network worldwide already support IPv6 today? If so, there would be a little pain in the transition from v4 to v6 with the help of LISP, provided we put weather most of the applications are v6-ready aside. > 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. If you don't hurry to deploy LISP with v6 EID within the forthcoming 3-5 years, time should be enough to upgrade the host stack to support that function if necessary. > 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. We need data to tell us the real impact, otherwise, LISP doesn't need to propagate so many branches ;) > 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. Does Eliot also agree with this opinion? ^_^
Best regards, Xiaohu Xu -- to unsubscribe send a message to [EMAIL PROTECTED] 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
