Hi Tom, In the thread "Re: [rrg] Pumping IRON" you wrote, quoting Tony Li, you wrote:
>> Note that it is the responsibility of the shepherd to get the document to >> the state where the RG gives consensus that it should be published. This >> applies to all of the documents that we have started, not just Fred's. >> >> I'm concerned as I've seen no action from shepherds or membership on any of >> the proposal-specific documents. > > Robin > > I would urge you to progress some of your ideas towards RFC, especially the > one > on CEE-CES split that you have explored on this list several times. Thank for your interest in this. I agree it would be good to document this in an RFC. A very short version of the distinction is at the end of section 17.3.3 of: http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html and is quoted below. In greater detail: http://www.ietf.org/mail-archive/web/rrg/current/msg06250.html http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html CEE (Core Edge Elimination) involves hosts doing more work than at present, which requires more packets, longer packets and frequently extra delays establishing initial communications. CES (Core Edge Separation) involves no changes to host protocols. The work is done by new elements in the network, such as "Ingress Tunnel Routers", "Egress Tunnel Routers" and various mapping servers. I believe it is possible to do CES with initial communications delays which are generally minimal enough not to be a concern to anyone. > I think that that idea is an important contribution to routing architectures > and > may well be significant when most of what we have discussed here has been > forgotten. OK - its not my idea, but I tried to document it clearly and resolve some problems I perceived in the terminology. I can't imagine ILNP or LISP being widely adopted and so I guess the whole question of scalable routing, mobility etc. will be revisited in five or ten years. Then, the CEE/CES distinction and some approaches which are currently not widely favoured will be of interest. (Alternatively someone will develop a commercial service based on TTR Mobility and DRTM - and IETF standards will have to catch up.) I assume the RRG archives will remain as they are, in perpetuity. My Ivip pages are there for keeps and archive.org will eventually catch up with the current contents. archive.org doesn't cover the RRG archives. > One caveat; I think that any such RFC would need to make sense to > those who have never heard of hIPv4, NOL, RANGI, NMS, TIDR, EEMDP etc. We who > have followed this list have a knowledge that noone else will ever acquire and > so any I-D that depends on that knowledge will generally be unintelligible. I agree. I think the messages mentioned above achieve this. However, they tend to assume a particular understanding of the problem and goals - something the RRG has never agreed on. To see my attempt at describing the problem/goals, please see section 17.2 of: http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html > Rather, I would like to see CEE-CES presented in the more commonplace concepts > of address, headers, tunnels etc, perhaps with reference to the specific > instantiations discussed here as appendices, as opposed to starting off by > saying 'these are CES, those are CEE', which will lose most of the audience:-( In 2015, 2020 time-frame, I agree. For RRG readers, I think it makes sense to list the various proposals first. From msg06219, here is the very short version, which doesn't refer to any particular architectures: = = = CEE Core-Edge (address) Elimination: A class of scalable routing architectures in which the Locator / Identity Separation naming model is introduced, replacing the current IPv4/v6 model in which the IP address plays both the Identifier and Locator roles. Hosts have portability of Identifiers and are able to do multihoming and inbound TE on IP addresses derived from two or more PA prefixes from two or more ISPs. These addresses are conventional PA "core" addresses and each such PA prefixes for an end-user network is fully aggregated into a shorter prefix the ISP advertises. Therefore, this use of address space is regarded as scalable. (This doubling or more of each end-user network's address requirements is one of the reasons CEE architectures are impractical for IPv4.)* Therefore there is no need for any "edge" addresses - the unscalable PI addresses which are currently the only way of achieving portability, multihoming and inbound TE. A fully adopted CEE architecture therefore eliminates the need for "edge" addresses, and so for the distinction between "core" and "edge" addresses. The full sense of "Elimination" in this term is "Elimination of the need to distinguish between core and edge addresses, since there is no longer a need for edge addresses." CES Core-Edge (address) Separation: a subset of the global unicast address space is separated from the remaining "core" global unicast addresses and is supported by the CES system (ITRs, mapping system and ETRs) to be used as a new form of address space by which end-user networks can obtain the benefits of Portability, Multihoming and inbound TE in a scalable manner. This space is used in a manner which involves far less impact on the DFZ control plane per end-user prefix than than current PI techniques. The full sense of "Separation" in this term is "Separation of the global unicast address space into a scalable 'edge' subset, with the remainder being 'core' addresses". Since Portability, Multihoming and inbound TE can be provided with this new scalable "edge" space, there is no longer any need for the unscalable PI edge space. = = = * Since I wrote this, ILNP for IPv4 has been proposed, with a new, longer, header to accommodate a separate Identifier, and use full IPv4 addresses as Locators. This doesn't have the same attraction (architectural "cleanliness" or "elegance") as ILNP for IPv6, because it requires upgrades to DFZ and other routers, longer packets to hosts etc. > The other idea of yours that I think will be of long term benefit is real time > mapping. It does set your ideas apart from the others, and if and when the > others find they need it too, then having a well-documented scheme will prove > a > valuable starting point. OK - thanks for your interest in this. The documentation at present should be read in this order: 1 - http://www.firstpr.com.au/ip/ivip/drtm/ (Color diagrams.) 2 - http://tools.ietf.org/html/draft-whittle-ivip-drtm 3 - http://www.ietf.org/mail-archive/web/rrg/current/msg06128.html (Please read only the section on "DNS-based system so TRs can find DITR-Site-QSDs.) Unfortunately, in the foreseeable future, I don't have time to work on any of this, including writing RFCs. I worked pretty much full-time on RRG things, analysing all the proposals and developing DRTM, in the first 3 months of this year. Now I need to catch up on paying work. If anyone else wants to work on an RFC on these, I would be greatly encouraged and will do my best to help. - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
