As mentioned in my previous message, I think the current draft of: http://tools.ietf.org/html/draft-irtf-rrg-design-goals-04
has many deficiencies. While I was not involved in the recent discussions about updating it, many of the criticisms I just wrote were first posted to the list in 2007. I voted against publishing the current draft as an RFC, because I believe we can and should write something much better. Despite the continued importance and the architectural fascination of scalable routing, with global mobility for billions of individual end-user hand-held devices there seems to be only a handful of people still interested in the RRG's work. This is not surprising considering the lack of encouragement of views contrary to Tony's (and a few others') belief that the network must not be asked to do more, or be altered in any way, and that all hosts must be saddled with Loc/ID Separation: new protocols, more state, more and/or longer packets etc. Loc/ID Separation involves unacceptable delays when establishing a new communication. It can't provide mobility in an acceptable fashion. There are insurmountable barriers to voluntarily adopting these new arrangements - and it is only practical for IPv6. As far as I can tell, ILNP's claims that it will work with existing IPv6 applications are false - and I think this probably applies to all such CES architectures. So applications would need to be re-written - including probably changes to some application protocols themselves, not just the software. Theoretical purists will be pleased by all this - but it will never be practical or widely adopted. Fred, I am surprised you voted in support of publishing the current draft. Section 3.4 states that Loc/ID Separation is "desired" and then "required". This means CEE: GLI-Split, ILNP, Name-Based Sockets or RANGI - not LISP, Ivip and IRON. The original meaning of a sentence in 3.4 was to refer also to what some of us now call Core-Edge Separation (CES) architectures - LISP, Ivip and IRON - and to state that if such an architecture was adopted, that it is required to be compatible with Loc/ID Separation. (This sentence is now meaningless, since the way it describes CES, which was primarily LISP when the sentence was written in 2007-04, no longer applies to any architectures.) So if we ignore the currently meaningless form of this sentence and assume it means LISP, Ivip, IRON or any other CES architecture, then 3.4 says these are required to be compatible with ILNP etc. This seems to be impossible. Even if it was possible, there would be no reason to implement both CEE and CES approaches to the routing scaling problem. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
