再有要解决ITR感知迁移后如何切换EID对应的Locator IP问题：1）使用上面几种感知迁移发生的方法后，都可以将ITR的EID对应Locator IP临时表项删除，由ITR重新发起一套EID的寻址流程获取新的Locator IP，缺点是稍慢。2）在上面第4种解决方案中，原始ETR收到新ETR的通知后，向ITR发个EID变更信息告知新的ETR地址，由ITR向新的ETR直接发请求获取新的Locator IP，不经MR/MS倒腾一遍手了，这样需要在LISP中多定义一个EID变更报文和相关处理流程。切换速度能提升些，但也稍微复杂了些。

提问题->找多个解决方案->比较不同方案的利弊，协议设计就是这么个过程。

LISP即使能够成事，至少也得2年以后了，所以大家可以先看个热闹，等RFC标准立起来再介入也不迟。也许Cisco回头觉着整这个太费劲，说不定哪天就偃旗息鼓了。别的厂商又真不见得有这么大号召力能把LISP忽悠起来。全当学着玩了，目前别拿LISP太当真。

另外多说一句LISP在Mobile里面的应用场景，Cisco已经今年5月份已经向IETF提出了draft-meyer-lisp-mn-05，其中mn就是mobile node缩写。简单来说就是在手机上支持ITR/ETR功能，可参考下图：

技术上很有想法，市场发展上不咋看好。感觉Cisco把手伸到手机里面，还不如前文提到的伸进服务器虚拟化里面有搞头。

小结

小结一下，数据中心多站点选路目前网络厂商单从路由角度来看没有什么好的方案，还是用DNS搞定更靠谱一些，只要应用程序的BS结构始终领先前行，暂时就还不用考虑其他的解决方案。让那些有钱有势的大厂商去试验吧，大家在后面跟进就是了。搞预研是有一定风险的行为，资源消耗了，万一路没选对，大厂商还能壮士断腕，小厂商就得折腰而终了，须慎研慎行。

凡事都有两面，换而言之，混乱的局面也是崛起的机会，如果谁能想到个啥招，搞个盒子出来，从路由或者其他层面独立解决多站点选路的问题，还是可以一试的。大赚不好说，但搞到像F5/Redware/Citrix这种规模并不是没得奔头。