Hi Joel, Here are two critiques which I think apply to ILNP and the other 5 proposals which I believe are core-edge elimination, schemes as I wrote:
http://www.ietf.org/mail-archive/web/rrg/current/msg05562.html GLI-Split hIPv4 Name-Based Sockets Name overlay (NOL) service for scalable Internet routing RANGI - Robin 1 - Core-edge elimination schemes are impossible to introduce widely enough on a voluntary basis to solve the routing scaling problem. Section 4.1 of this paper mentions this, in terms of the core-edge elimination schemes involving changes in edge networks in order to reduce costs in core/transit networks: Towards a Future Internet Architecture: Arguments for Separating Edges from Transit Core Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf There is no direct incentive for edge networks to make this investment. Also, the benefits only flow once all edge networks fully adopt the new system. Core-edge elimination involves new host functionality - in stacks and often in applications. This is at odds with the constraints due to the need for widespread voluntary adoption: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ because the upgraded hosts can only achieve scalable multihoming, TE, portability etc. when communicating with the initially very small subset of other hosts which are also upgraded. These benefits are too small to enable the abandonment of existing unscalable portability, multihoming etc. arrangements and too small to motivate many people to adopt the new system. This list of constraints has been discussed on the RRG and has received considerable support. No-one has suggested this list miss-states the real constraints which exist, or that there is another way of introducing a solution than by widespread voluntary adoption. 2 - Core-edge elimination schemes place more routing and addressing responsibilities on hosts. Its OK for a scalable routing architecture to make this an option, but core-edge elimination schemes enforce it on all hosts. This means all hosts must be more complex and engage in extra communications in order to implement their new responsibilities. This can be a problem even for well-connected hosts, where looking up mapping, engaging in cryptographic exchanges etc. are necessary before user data can be transacted, involving extra delays, state, CPU effort etc. It is completely unworkable for mobile hosts which typically have low CPU capabilities and most importantly are connected via wireless links which are slow, unreliable and expensive. I wrote about this on the RRG and then made a web page: http://www.ietf.org/mail-archive/web/rrg/current/msg05471.html http://www.firstpr.com.au/ip/ivip/RRG-2009/host-responsibilities/ _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg