Short version: The fact that the co-chairs considered Slide 19 to be a reasonable account of Ivip shows that they completely misunderstand Ivip and its related TTR Mobility architecture.
Their Recommendation will be judged according to whatever justifying arguments they supply for it and according to how well they apparently understood all the proposals. They clearly do not understand Ivip or TTR Mobility. Classing GLI-Split as a CES "map-encap" architecture indicates they misunderstand this architecture too. There is no encapsulation. GLI-Split is a Core-Edge Elimination (Locator / Identification Separation) architecture, as is ILNP. Likewise referring to Name Based Sockets as simply a mapping system indicates they do not understand this architecture either. Both GLI-Split and Name Based Sockets are CEE (Loc/ID Separation) architectures. I think they are both at least as well documented as ILNP. I don't support any of these CEE architectures, but the fact that the co-chairs didn't consider ILNP, GLI-Split and Name Based Sockets to be even in the same class is further reason to believe that their Recommendation is based on an inadequate understanding of the architectures. My previous message was based on what I heard on the audio feed. Now I can see the slide with which the co-chairs presented Ivip. BTW, to call the meeting a "discussion" seems to be inaccurate. Brief and at times misleading summary material was presented, followed by a simple Recommendation, without sufficient explanation of what was wrong with architectures other than ILNP or AIS. As far as I can tell, what anyone from the floor said in response to this did not affect the view of the co-chairs or what they will write in their Recommendation. This does not resemble a "discussion". Lixia, I appreciate you recognising my hard work on Ivip and the RRG in general, but its just plain misleading to present the following text as some kind of analysis of Ivip. I don't understand how you and Tony could be so uninformed about Ivip and TTR Mobility up to the last month or so, or Ivip in the last month with Distributed Real Time Mapping (DRTM), to think this text was accurate. Slide 19 in: http://www.ietf.org/proceedings/10mar/slides/RRG-0.pptx is: Ivip Map-n-encap edge to edge Mapping changes are flooded globally and instantly The changes include those due to host mobility feasibility is a concern Requires all routers be modified Here's what's wrong: Map-n-encap edge to edge Broadly true, but in the future, whenever all DFZ and some other routers can be upgraded, transition to Modified Header Forwarding, which avoids encapsulation, its overhead and its PMTUD problems. This is for 10 to 20 years in the future, and is not at all necessary for Ivip to deliver immediate and lasting benefits to adopters and to scalable routing in general. Mapping changes are flooded globally and instantly With DRTM - which replaces the earlier mapping system - each DITR network only "floods" a subset of the mapping for the subset of MABs (Mapped Address Blocks) this DITR network handles, to the small number of DITR sites in each such DITR network. There would be a few dozen such sites at most. Each DITR network involves one or at most a handful of organisations - so this is surely practical per DITR network. There can be large numbers of DITR networks - dozens to thousands in principle, though no more than a few dozen is likely due to economies of scale favouring the use of an established network rather than building another one. To the extent that there are scaling problems in any one DITR network due to this real-time propagation of mapping this does not present a scaling problem for the whole Ivip system, because there can be large numbers of such DITR networks. So it is not true to say the mapping is flooded "globally". Each DITR network has at most a few dozen widely (globally) distributed sites, and each such network does involve what is arguably "flooding" of all mapping changes to these sites. But there are only a few dozen sites and each DITR network need only handle a small subset of the total set of "edge" address space in the entire system. With DRTM, ISPs run ITRs and QSR Resolving Query servers. These are both entirely caching devices - but they get updates to mapping if they need them, which is not "flooding". The changes include those due to host mobility In a very broad sense this is true, but given that most people assume a mapping change every time the MN gets a new address, this statement is completely misleading. Ivip uses TTR Mobility (which could also be used by LISP): http://www.firstpr.com.au/ip/ivip/#mobile Mapping changes are not absolutely required no matter what new address the MN gets, or where it connects to the Net. Mapping changes are desirable, but not urgently required when the MN moves some distance such as 1000km or more. Then, it tunnels to a new, nearby, TTR and after that is done, the mapping can be changed to the new TTR. Delays in finding and tunneling to a new TTR or in changing the mapping to the new TTR do not disrupt communications at all. Many MNs which don't move outside a given city or region would probably use the same TTR year after year - so there would be no mapping changes. feasibility is a concern Feasibility of all the proposals is a concern. You provide no explanation of your concerns about the feasibility of Ivip with DRTM. Requires all routers be modified This is completely untrue. In the long-term future, if and when DFZ and some other routers can be upgraded, then Ivip will transition from encapsulation to Modified Header Forwarding. But even if that never happens, Ivip with encapsulation forever would be far superior to any other architecture, for the reasons argued here: http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html 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 I haven't looked at the other slides yet, but I think many of them contain similarly serious errors. For instance you class GLI-Split in the CES "Map-and-encap" section - but it does not involve encapsulation and it is a CEE architecture, since all hosts adopt Locator / Identifier Separation. The fact that you consider this completely misleading slide 19 as a reasonable account of Ivip indicates your misunderstanding of this proposal is far more significant than whatever it is you do correctly understand about it. The Recommendation you are writing is yours alone. It does not come from the RRG as a Research Group. Anyone who wants to estimate how well informed you were when you made your decision can see that you were completely misinformed about Ivip, despite Ivip being very well documented. - Robin _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg