Hi James, In the "Long term clean-slate only for the RRG?" thread, you wrote:
>> I don't support IETF/IRTF working on any long term, clean slate >> solutions. OK. It is too big a job for the RRG in our time frame - March 2008 - but I think we should consider clean slate solutions which are scalable, and which would solve other problems, to recommend to whoever (perhaps the RRG in the future) carries on this work. Maybe there is a way that the IPv4 and IPv6 solutions which arise from the RRG recommendations could be designed in a manner which supports transition to a long-term "clean slate" architecture. Also, ideas about a clean-slate architecture may influence how long we plan the IPv4 and IPv6 fixes to last. >> I believe that the preliminary phases in which this work is >> now require small teams of creative individuals with new and >> quite radically different ideas. I fully agree. I think the best approach would be something like this: Various teams work on their own proposals and present them as clearly as possible, as their work develops. Then members of all teams, plus the RRG members who are not in any particular team, constructively criticise these proposals. >> An environment of required consensus and "design by committee" >> isn't conducive to the kind of creative thinking that is required >> for such solutions. I agree. I wrote about this in March: Concerns about the RRG process ... & how not to design an airliner http://psg.com/lists/rrg/2008/msg00971.html The top-down approach doesn't work very well because there are multiple fruitful directions which need to be developed into detailed proposals before the benefits and problems become apparent. Imagine a committee designing an airliner and first deciding whether to use carbon fibre composites or not. That is just one of many major interdependent decisions a designer makes. By choosing to go only one way, or the other, before exploring all the possible outcomes of each branch in the road, the committee is not able to discover all the synergies and problems which make or break an actual design. I think the RRG could develop some principles for choosing a good solution, for both IPv4 and IPv6 (there are some important technical differences, and a lack of urgency with IPv6) and recommend one or more of the proposals as worthy of further consideration and development. Perhaps the RRG might decide that none of the proposals are good enough yet for development in the next year or two - but instead recommend further research into or more short term (IPv4 and IPv6) solutions and into a long-term, clean-slate architecture. >> After all if Kleinrock, Cerf, and the rest had gone to ITU with >> the Internet in the early phase, would it have ever happened? I wasn't involved in those days, but I guess the ITU would be wanting see how the billing for each Internet call was done. It is hard to imagine a new architecture for the Internet developing without having to be approved by a bunch of committees. However perhaps an Ivip like map-encap scheme could be introduced by one or more commercial operators, to provide portable multihomable space - and with the TTR extensions, mobility. That might be so easy to adopt and useful for end-user networks, that it becomes widely adopted in a few years. Done properly, this would solve the routing scaling problem, making any alternative solution harder to introduce. This is not what I want to happen, but I could imagine it happening - especially if we drift well into the next decade without anything sufficiently attractive to end-users emerging from the IRTF-IETF committee system. I agree in the early days, multiple free-wheeling teams should work on their own proposals - with the RRG or similar acting as a testing ground for all the new proposals. I think it is vital that the team members constructively criticise the proposals of other teams. As I understand it, the RRG plan is not to debate specific proposals, but to develop an architectural specification from high-level discussions, without reference to current proposals. I think this is highly unlikely to produce a better proposal than those already developed. One aim of focussing on "high-level architectural" discussion of the solution space is to find potential solutions which were missed by the independent teams. However, I think no such new direction has been found so far, at least in terms of anything compatible with IPv4 and IPv6 without host changes. Ideally the small teams would have the resources to fully develop their ideas, build prototypes etc. So far, only the LISP team have been able to prototype their system. >> As for the other proposals, a solution for IPv4 is absolutely >> required, since that is what industry and society depends on, >> regardless of how much the IETF may desire that IPv6 become the >> basis of people's day to day interaction with the Internet. I agree entirely. >> I'm not sure about having different solutions for IPv4 and IPv6. >> I suspect that there would be a lot of pushback from vendors and >> operators on this when it went to standardization, and I'm sure >> there would be a draft that would pop up for >> "IPv4-solution-on-IPv6" that would rapidly gain consensus and >> overthrow any IPv6-only solution. I tend to agree, but since I think it is still early days, since IPv6 enables more technical methods to be use to solve the problem, since it isn't so urgent and since the installed base is so much smaller, I wanted to keep the path open for a different solution, if it was sufficiently superior to the IPv4 solution to justify whatever differences it entailed. - Robin -- 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
