See below, Heiner In einer eMail vom 26.06.2010 06:05:08 Westeuropäische Sommerzeit schreibt [email protected]:
completely disagree with this idea of separating "architecture" from "engineering" - especially the idea of leaving "engineering" to someone else to solve. Can you point to any successful outcomes of this disdain for, or deferment of interest in, "engineering"? In any field whatsoever - software development, IETF protocols, ship-building, aircraft design, commercial buildings, dam, road or railway construction? Except when doing the initial brainstorming, a designer of a new architecture should be able to show it will work at all levels of the design - irrespective of whether some people think of these levels as "architecture" or "engineering". The proposed architectural enhancements for IPv4 and IPv6 should also have a clear set of goals and non-goals, and address the major challenges of the need for widespread voluntary adoption. It should also go beyond scalable multihoming to achieve mobility on a massive scale. The RRG has not developed or achieved consensus on a set of goals, or a problem statement. ILNP has no list of goals or non-goals. I have attempted to do this with Ivip, and I think I have generally succeeded. But it seems that the result far exceeds the attention span or interest of most RRG members to read and comment about. Even my attempt at writing an RRG Recommendation: http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html seems to be too long (19 pages) and detailed for anyone to comment on. ILNP is simple and short enough for you and many other RRG people to read and comment upon. However, it is completely inadequate as a solution to the routing scaling problem - for reasons I mentioned in msg06219. HH: Right. It is a bad idea to come up with an architecture which defers the proof of functioning to any later engineering. And also: It is a bad thing to focus only on one issue (e.g. scalability) at a time and to disregard the many concurrent issues (Multicast, TE, mobility, dealing with loops, ...). Also,an architecture should not only be backward compatible but also future-compatible. Prior coming up with some architecture the true causes of the misachievements should be identified and discussed. I can understand the sticking to DV, given that the alternative were a flat topology of the entire internet. But this argument is broken. Do the DV-supporters know what future progress they are disabling hereby ? Or do they think, it causes only some inconvenience (table size, churn) which newer hardware shall/will handle ? I really would appreciate hearing from the DV-supporters which disadvantages they are aware of. With DV you will never get to knowing not only the topology but also the current traffic load. Instead this is cut off for good! It suits Ran's preference for remaining a the "architectural" end of the design process, his lack of interest in what he regards as "engineering" details - and his evident lack of interest in questions of adoption: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ Nor, it seems, do you or Ran have interest/time to comment on some critiques of ILNP, such as what I just wrote about ILNP's approach to mobility (msg07031). Neither you or Ran have written anything to help Fred Templin refine his IRON IDs, which I understand you also want to have published as IRTF RFCs. I am not suggesting that you or any other RRG folks should spend time on Ivip or IRON or anything else. We are all volunteers. However, given the pervasive lack of interest in any proposal which involves sufficient complexity to actually work, I don't think you should claim the RRG has done its job properly. Most active participants have failed to read and meaningfully discuss significant contributions such as Ivip, or more recently, IRON. There has been considerable RRG discussion of LISP, but the LISP folks have generally been uninterested in discussing these substantial critiques, either on the RRG list or in the LISP WG. I know we are all short of time. But with Ivip in general, and with TTR Mobility, you have had 3 years. To gain a good understanding of the 3 month-old DRTM, you can read 6 pages of text and peruse three diagrams. That would take an hour or less. This is a fraction of the effort which you and many other people put into reading and writing RRG messages every week, so as the months and years go by, being short of time is clearly not the limiting factor. I think you, Ran and some other folks are too focused on changing all hosts to relieve the Network of some extra workload. This is a very pure, mathematical, approach by which you limit the functionality of the network and its routers in order that they can scale very well. You appear untroubled by the consequent requirement that hosts to do extra work and use new, more complex, protocols. As a result of your elevation of network simplicity to the primary goal, you you quickly dismiss any Core-Edge Separation architecture such as LISP, Ivip or IRON. With ILNP, you are pursuing an architecture which changes all host stacks (and for IPv4 requires upgrades to all DFZ and other routers), because it suits your conviction that the Network can't or shouldn't be called upon to be made more complex and do extra work, to support current host protocols in the quest for scalable multihoming and mobility. Four days ago I argued: "Overloading" of Loc & ID functions is good for hosts and should be maintained http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html that the current host protocols and the division of labor between routing system and hosts have profound advantages. I have mentioned this frequently in the past. Yet no-one has commented. ILNP will probably never be adopted even slightly by genuine users in IPv6, where it has some technical elegance - due to: 1 - The need for host stack changes. 2 - Substantial benefits for adopters and for scalable routing only being delivered once almost every host and network adopts it. 3 - Being unsuitable for mobility. 4 - Burdening all hosts with extra packets or longer packets. 5 - Introducing extra delays in the establishment of communication sessions. ILNP has absolutely zero chance of helping with the IPv4 scaling / multihoming / mobility problem for these reasons and because it requires longer packets (with the IPv4 Option) and upgrades to all DFZ and other routers in order to handle this Option. Right, Robin. That's why we non-ILNPers can be very relaxed. Sad enough for IPv6 that it would need ILNP to become ...I don't know what to say. These problems with any CEE (Loc/ID Separation) approach have been obvious since before this recent 3 year phase of the RRG's work - which is why people developed LISP, Ivip, IRON and TIDR. So I think that in recommending ILNP, you are completely mistaken. Hopefully in the future there will be a group of people with time and interest to discuss and contribute to architectures which are complete enough (and therefore more complex than ILNP and more carefully designed than LISP) to actually achieve all the goals of scalability, multihoming, mobility and widespread adoption by voluntary means alone. I am neither afraid of LISP nor ILNP wrt eventual progresses because it is wrong to believe that only the "one chosen solution" will do. Just the contrary: For about 10 years all is provided to enable RFC 2547-VPNs. Well, you can use the hereby developed technique (which is based on vendor-specific information elements) to build an overlay instead for private traffic ( VPN ) rather for public traffic, i.e. to detect singular clusters of the new architecture (TARA, lvip, XYZ) and to interconnect them with whichever sort of tunnels. Like all those VPNs can co-exist, the new architectures can co-exists as well. The best one will succeed, and not the first one. Hence, this race last January for becoming CHOSEN just costs me a tired smile. At future years I intend to write up Ivip and DRTM more thoroughly and hopefully write some code for a test network. Until then, please see: http://www.ietf.org/mail-archive/web/rrg/current/msg06823.html in response to Tom Petch (msg06831) regarding his suggestion I write RFCs for the CES/CEE distinction and for DRTM. - Robin _______________________________________________
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
