Hi Tony, You have taken no interest in Ivip since I first devised it in June 2007. The slides you and Lixia presented at the meeting misrepresented Ivip, and misclassified two Core-Edge Separation (Locator / Identifier Separation) architectures as being CEE (GLI-Split) and just a "mapping proposal" (Name Based Sockets).
http://www.ietf.org/mail-archive/web/rrg/current/msg06373.html So I don't hold much hope that my comments will alter what you decide to write as the Recommendation: > As can be seen from the extensive list above, the group explored a number of > possible solutions. Unfortunately, the group did not reach rough consensus > on a single best approach. Accordingly, the decision of the co-chairs is to > recommend that the IETF pursue work in the following areas: > > - Aggregation in Increasing Scopes [I-D.zhang-evolution] > > - Identifier/Locator Network Protocol (ILNP) [ILNP Site] > > - Renumbering [I-D.carpenter-renum-needs-work] This is simple and brief - but these are not virtues, since this is a complex field and you are recommending the path by which the world's largest and most important IT/communication system should be fundamentally altered. I expect most people reading your Recommendation will recognise it comes from you and Lixia alone. Since you don't provide any analysis of the proposals you rejected, I think most people will give it very little weight. Perhaps they will also notice that the LISP team didn't bother to write a rebuttal or contribute substantially to any critiques of other architectures. Those who read the archives will note the occasional protests at you banning or discouraging debate on "proposals" (AKA "candidate architectures") for most of the last 3 years - while exhorting us to discuss "architecture". Yet you gave little or no examples of how this should be done. They may also notice that in recent months the only proposal you commented on to any significant degree was ILNP. The RRG Report contains introductory information for a bunch of proposals, and people can read the critiques, rebuttals and responses - and read further in the various websites and IDs. This is a valuable contribution to the field. Your Recommendation adds nothing to the field. I think it is of minor interest to anyone what you and Lixia think is the best way forward - since you provide no arguments for you position whatsoever. If you fleshed out your Recommendation with detailed analysis of the architectures you prefer, comparing them in detail with those you reject, then that material would be a contribution to the field, depending on how accurately you understood the architectures and how acute your analysis was. If anyone wants to see the form of a well researched and carefully argued Recommendation, with a statement of the goals and non-goals, and analysis of the key points of the various architectures, they can take a look at my message from 8 March: http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html Ideally the RRG Recommendation would be along these lines - as a consensus document. Failing that, ideally, the co-chair's Recommendation should be at least this detailed. This is especially so since, due to your inaction, the RRG didn't achieve one of its earliest goals: http://www.irtf.org/charter?gtype=rg&group=rrg as a starting point, the RRG will produce a document enumerating the design goals for a new routing architecture. Your Recommendation has no real meaning - no-one can be sure what it is you are hoping to achieve with these architectures. The Design Goals ID (01) resulted from very early, limited, discussions to early July 2007: http://www.ietf.org/mail-archive/web/rrg/current/msg06160.html You never responded to my suggestions a few days later on improving it: http://www.ietf.org/mail-archive/web/rrg/current/msg00203.html Note the message number - 203. We are now up to 6440. The Charter also states that the RRG will prepare a taxonomy. I provide a taxonomy in msg06373 and in other messages cited from there. You have never commented on this, other than to assert, without arguments, that the CES/CEE architectural distinction is invalid or not useful. Bill Herrin and others also worked on a taxonomy in late 2008: http://bill.herrin.us/network/rrgarchitectures7.html In 2010, the closest thing there is to to an RRG taxonomy is your slides from the recent meeting, but as I noted in msg06373, this is plain wrong in some important respects, just at a first glance. With little help from you, and frequently in spite of your instructions - and with more help from Lixia (who contributed to proposals, wrote critiques and was generally more supportive of debate) - the RRG has developed a number of architectural approaches. Still, as noted by k claffy and Eliot Lear: http://www.ietf.org/mail-archive/web/rrg/current/msg06054.html there is a regrettable lack of proposal submitters (myself excepted) providing critiques of other proposals. With your help, these proposals are now presented in a summarised form, with some brief but constructive discussion, in the RRG Report. In the future I intend to list or compile all the critiques and responses which didn't make it into the RRG Report. I think anyone interested in Core-Edge Separation architectures, including LISP and Ivip, should take a look at the recent discussions between Fred and me regarding IRON-RANGER. I consider it to be a better architecture than LISP-ALT or any other form of LISP. > - Aggregation in Increasing Scopes [I-D.zhang-evolution] The later stages of this look highly complex and likely to be fragile. In the context of the need to provide scalable portability, multihoming and inbound TE for ~10^7 non-mobile networks, and mobility for up to 10^10 devices, AIS provides only marginal benefits to adopting networks . It does nothing to provide a new form of address space which can be used to scalably provide portability, multihoming, inbound TE or mobility. > - Identifier/Locator Network Protocol (ILNP) [ILNP Site] ILNP is one of the four CEE architectures - the others being RANGI, GLI-Split and Name Based Sockets. These can only work for IPv6. They require changes to all host stacks - including (msg06423) for ILNP, to the transport protocols. There remain various questions about the operation of all these architectures - e.g. (msg06432). Some CEE architectures require application changes. Those which don't (such as ILNP) face challenges ensuring the assumptions about the IP addresses at the app level are maintained in actual communications. For instance, with the current two-level naming model used in IPv4 and IPv6, in which the roles of "Identifier" and "Locator" are both performed by the IP address, the network provides apps (and the TCP and UDP layers) with an assurance that a packet sent to IP address XXX will either be delivered to the host with that identity, or will be dropped - it will never be delivered to any other host than XXX. This model offends architectural purists, but it is more efficient - which can best be appreciated when it is fully realised what ILNP, GLI-Split etc. require all hosts to do in order to adopt Locator / Identifier Separation. None of them are suitable for mobility. > - Renumbering [I-D.carpenter-renum-needs-work] Renumbering can never be an acceptable approach for any but the smallest networks choosing a new ISP. This is because the IP addresses used by the network frequently appear in many places outside its control and outside its knowledge. Even if the network administrators knew all occurrences, there is no acceptable, practical, means by which they can have those IP addresses changed at the instant they switch to the new ISP. To do so would involve inconvenience and costs to other organisations, including sometimes the customers of the network. A more detailed analysis of all the proposals is here: http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html When people look at the discussion of Ivip, I hope they will realise that in early March I replaced its previous mapping system with a new approach - Distributed Real Time Mapping. This overcomes many of the critiques made of the earlier system, including some in Lixia's critique which is in the RRG Report, which was written before I developed DRTM. DRTM is completely decentralised and involves early provision of scalable routing benefits without any significant investment or involvement of ISPs. No single device is required to handle the full mapping database. I think the new ivip-arch ID contains the only statement of goals and non-goals of any of the proposed architectures. Contrary to your misstatement in the meeting slides, Ivip does not require upgrades to any routers. I hope people will read the Ivip-arch ID, the new, diagram-based introduction to DRTM, the DRTM draft and then the material on TTR Mobility: http://tools.ietf.org/html/draft-whittle-ivip-arch http://www.firstpr.com.au/ip/ivip/drtm/ http://tools.ietf.org/html/draft-whittle-ivip-drtm http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf As far as I know, you have not read any of this. As far as I know, you have not taken much interest in any architectures other than ILNP and its predecessor GSE. You have never articulated why you believe Core-Edge Elimination (Locator / Identity Separation) is superior to Core Edge Separation, despite me arguing against CEE due to the burden of extra packets, processing and delays it places on all hosts. You tersely stated, and then never seriously debated, your complete disregard for the IPv4 Internet. http://www.ietf.org/mail-archive/web/rrg/current/msg06192.html I want nothing. IPv4 is done. Over. Cooked. Fully toast. It will either enter a black market where we deaggregate and no proposal will help, or we shift to v6 and v4 is irrelevant. In either case, we're not in time to do anything significant for v4. And we still need a v6 solution, that's clearly higher priority. There's nothing about such disregard for the IPv4 scaling problem in the RAWS material, or in the RRG Charter. Many RRG folks have indicated they consider the IPv4 Internet important and that its scaling problem needs to be tackled. Lixia took an interest in Ivip and went to the trouble of writing at least one critique. AFAIK, you didn't contribute to any critiques. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
