[rrg] RFCs for CEE/CES and DRTM real time mapping?
Robin Whittle <rw@firstpr.com.au> Mon, 07 June 2010 16:49 UTC
Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C5E28C7F3 for <rrg@core3.amsl.com>; Mon, 7 Jun 2010 09:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.705
X-Spam-Level:
X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQE9MHZsMSfy for <rrg@core3.amsl.com>; Mon, 7 Jun 2010 09:49:24 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id C38523A7B55 for <rrg@irtf.org>; Mon, 7 Jun 2010 05:15:07 -0700 (PDT)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 72C21175FDA; Mon, 7 Jun 2010 22:15:06 +1000 (EST)
Message-ID: <4C0CE2CD.4050605@firstpr.com.au>
Date: Mon, 07 Jun 2010 22:15:09 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <C82E58BE.12C59%tony.li@tony.li> <002d01cb0615$2bb5b680$4001a8c0@gateway.2wire.net>
In-Reply-To: <002d01cb0615$2bb5b680$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] RFCs for CEE/CES and DRTM real time mapping?
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jun 2010 16:49:25 -0000
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] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Ruediger Volk
- Re: [rrg] ILNP q1: Scalability mohamed.boucadair
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Christopher Morrow
- Re: [rrg] ILNP q1: Scalability Fred Baker
- Re: [rrg] ILNP q1: Scalability Fred Baker
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Toni Stoev
- Re: [rrg] ILNP q1: Scalability Christopher Morrow
- Re: [rrg] ILNP q1: Scalability Fred Baker
- Re: [rrg] ILNP q1: Scalability Fred Baker
- Re: [rrg] ILNP q1: Scalability Steven Blake
- Re: [rrg] ILNP q1: Scalability Fred Baker
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability Fred Baker
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Christopher Morrow
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Christopher Morrow
- Re: [rrg] ILNP q1: Scalability Dae Young KIM
- Re: [rrg] ILNP q1: Scalability Toni Stoev
- Re: [rrg] ILNP q1: Scalability Lixia Zhang
- Re: [rrg] ILNP q1: Scalability Noel Chiappa
- Re: [rrg] ILNP q1: Scalability Patrick Frejborg
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability Joel M. Halpern
- [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] Pumping IRON Tony Li
- Re: [rrg] ILNP q1: Scalability Toni Stoev
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability Toni Stoev
- Re: [rrg] ILNP q1: Scalability HeinerHummel
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability Lixia Zhang
- Re: [rrg] ILNP q1: Scalability Joel M. Halpern
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability Flinck, Hannu (NSN - FI/Espoo)
- Re: [rrg] ILNP q1: Scalability Tony Li
- [rrg] RFCs for CEE/CES and DRTM real time mapping? Robin Whittle
- Re: [rrg] ILNP q1: Scalability Christopher Morrow
- Re: [rrg] ILNP q1: Scalability Patrick Frejborg
- [rrg] IETF78? Templin, Fred L
- Re: [rrg] ILNP q1: Scalability Toni Stoev
- Re: [rrg] ILNP q1: Scalability RJ Atkinson
- Re: [rrg] ILNP q1: Scalability RJ Atkinson
- Re: [rrg] IETF78? Tony Li
- Re: [rrg] ILNP q1: Scalability Noel Chiappa
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability Toni Stoev
- Re: [rrg] ILNP q1: Scalability Noel Chiappa
- Re: [rrg] (no subject) Toni Stoev
- Re: [rrg] ILNP q1: Scalability Patrick Frejborg
- Re: [rrg] ILNP q1: Scalability Patrick Frejborg
- Re: [rrg] ILNP q1: Scalability Noel Chiappa
- Re: [rrg] ILNP q1: Scalability Patrick Frejborg
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] multi-homed site issues RJ Atkinson
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] multi-homed site issues Templin, Fred L
- Re: [rrg] ILNP q1: Scalability Patrick Frejborg
- Re: [rrg] ILNP q1: Scalability RJ Atkinson
- Re: [rrg] ILNP q1: Scalability Patrick Frejborg
- Re: [rrg] ILNP q1: Scalability RJ Atkinson
- Re: [rrg] ILNP q1: Scalability Tony Li
- Re: [rrg] ILNP q1: Scalability RJ Atkinson
- Re: [rrg] ILNP q1: Scalability Patrick Frejborg
- Re: [rrg] ILNP q1: Scalability RJ Atkinson
- Re: [rrg] DNSsec & privacy RJ Atkinson
- Re: [rrg] DNSsec & privacy Steve Crocker
- Re: [rrg] Pumping IRON Wesley Eddy
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] ILNP q1: Scalability Patrick Frejborg
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] multi-homed site issues Patrick Frejborg
- Re: [rrg] multi-homed site issues RJ Atkinson
- Re: [rrg] multi-homed site issues Templin, Fred L
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] Pumping IRON Robin Whittle
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] Pumping IRON Robin Whittle
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] multi-homed site issues Patrick Frejborg
- Re: [rrg] multi-homed site issues RJ Atkinson
- Re: [rrg] multi-homed site issues Patrick Frejborg
- Re: [rrg] multi-homed site issues RJ Atkinson
- Re: [rrg] multi-homed site issues Patrick Frejborg
- Re: [rrg] multi-homed site issues RJ Atkinson
- Re: [rrg] multi-homed site issues Patrick Frejborg
- Re: [rrg] multi-homed site issues Shane Amante
- Re: [rrg] multi-homed site issues Tony Li
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] multi-homed site issues RJ Atkinson
- Re: [rrg] Pumping IRON Tony Li
- Re: [rrg] Pumping IRON Robin Whittle
- Re: [rrg] multi-homed site issues Patrick Frejborg
- Re: [rrg] multi-homed site issues RJ Atkinson
- [rrg] ILNP and MPTCP [was multi-homed site issues] Brian E Carpenter
- Re: [rrg] multi-homed site issues Patrick Frejborg
- Re: [rrg] ILNP and MPTCP [was multi-homed site is… Scott Brim
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] ILNP and MPTCP [was multi-homed site is… Joel M. Halpern
- Re: [rrg] Pumping IRON Robin Whittle
- Re: [rrg] Pumping IRON Tony Li
- Re: [rrg] ILNP and MPTCP [was multi-homed site is… Tony Li
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] Pumping IRON Templin, Fred L
- Re: [rrg] Pumping IRON Tony Li
- Re: [rrg] ILNP and MPTCP [was multi-homed site is… Brian E Carpenter
- Re: [rrg] ILNP and MPTCP [was multi-homed site is… Tony Li
- Re: [rrg] ILNP and MPTCP [was multi-homed site is… Tony Li
- Re: [rrg] Pumping IRON - steps to making Experime… Robin Whittle
- Re: [rrg] Pumping IRON - steps to making Experime… Tony Li
- Re: [rrg] Pumping IRON - steps to making Experime… Robin Whittle
- Re: [rrg] Pumping IRON - steps to making Experime… Tony Li
- Re: [rrg] Pumping IRON - steps to making Experime… Templin, Fred L
- Re: [rrg] ILNP and MPTCP [was multi-homed site is… Scott Brim
- [rrg] Pumping IRON - LAST CALL (ends 17:00PDT on … Templin, Fred L
- Re: [rrg] Pumping IRON - LAST CALL (ends 17:00PDT… Templin, Fred L
- Re: [rrg] Pumping IRON - LAST CALL (ends 17:00PDT… Tony Li
- [rrg] Pumping IRON - LAST LAST CALL (ends 17:00PD… Templin, Fred L
- [rrg] IRON last call deadline extended to 17:00PD… Templin, Fred L
- Re: [rrg] IRON last call deadline extended to 17:… Templin, Fred L
- Re: [rrg] IRON last call deadline extended to 17:… Tony Li