Re: [rrg] Aggregatable EIDs
HeinerHummel@aol.com Tue, 29 December 2009 12:06 UTC
Return-Path: <HeinerHummel@aol.com>
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 E0BDF3A63EC for <rrg@core3.amsl.com>; Tue, 29 Dec 2009 04:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.431
X-Spam-Level:
X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6]
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 DChMsTD808hG for <rrg@core3.amsl.com>; Tue, 29 Dec 2009 04:06:05 -0800 (PST)
Received: from imr-ma04.mx.aol.com (imr-ma04.mx.aol.com [64.12.206.42]) by core3.amsl.com (Postfix) with ESMTP id 726883A6828 for <rrg@irtf.org>; Tue, 29 Dec 2009 04:06:04 -0800 (PST)
Received: from imo-ma04.mx.aol.com (imo-ma04.mx.aol.com [64.12.78.139]) by imr-ma04.mx.aol.com (8.14.1/8.14.1) with ESMTP id nBTC5A40008764; Tue, 29 Dec 2009 07:05:11 -0500
Received: from HeinerHummel@aol.com by imo-ma04.mx.aol.com (mail_out_v42.5.) id i.d1e.53b69b4b (29672); Tue, 29 Dec 2009 07:05:08 -0500 (EST)
From: HeinerHummel@aol.com
Message-ID: <d1e.53b69b4b.386b4ac0@aol.com>
Date: Tue, 29 Dec 2009 07:06:24 -0500
To: tony.li@tony.li
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1262088384"
X-Mailer: 9.0 SE for Windows sub 5021
X-AOL-SENDER: HeinerHummel@aol.com
Cc: rrg@irtf.org, zhangwei734@gmail.com
Subject: Re: [rrg] Aggregatable EIDs
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: Tue, 29 Dec 2009 12:06:07 -0000
In einer eMail vom 28.12.2009 19:18:33 Westeuropäische Normalzeit schreibt tony.li@tony.li: Hi Heiner, Tony wrote:How does routing work entering and within the geo-patch? Traffic arriving into the geo-patch must be routed to one of possibly many local ISPs from one of possibly many long-haul transit ISPs. For this to work, there must be some interconnect between local and long-haul. This implies that there must be an exchange point, and that it needs to be geo-patch specific. Tony, each TARA router should have a (flat) TARA-map which consists of TARA-nodes and TARA-links. A TARA-node is a TARA-aware router which has its TARA-locator (these 5 octets), assigned by GPS if you want. Host-users shall have assigned an IP-address+some TARA-locator of one (in case of multihoming severals) TARA-node. A sending source needs to know not only the destination IP address but as well the respective TARA-locator. Eventually, especially during the incremental deployment phase, some early TARA-router has to be proxy i.e. has to look-up by means of the dest.IP address the respective TARA-locator. A TARA-router shall stop advertising prefixes wrt its EIDs but should advertise prefix of length 0 (like the LISP default mapper) so that a TARA-router nearest to the source will attract the flow to the “unknown” dest. A TARA-router will have a TARA-map which consists of TARA-links each of which is confined by two TARA nodes. A TARA-link is either strict or loose. A loose TARA-link is the concatenation of strict and/or other loose TARA-links and/or GRE-tunnels across non-TARA-aware classical internet. Each strict/loose TARA-link has a weight value which reflects the number of hops. Hereby some approximation-algorithm is required to determine the adequate weight value for the inter-domain-GRE-tunnel, somehow derived from the TARA-locators of its end nodes, or it may be well-known from OSPF if the GRE-tunnel is intra-domain. Though normally the viewed strict TARA-links are expected to be from the own geopatch, they may as well, in single cases, cross have of the globe. The big deal is to provide algorithms such that each TARA-router ( particularly a geopatch-border node) can compute the identical set of (mainly looser) TARA-links which form a skimmed representation of the geopatch’s topology and which has to be disseminated in a larger scope i.e. into the surrounding geopatches. This is not an easy task to do or to describe by few lines, especially when you envision maybe about 5 recursive repetitions, and that each TARA-router within the same geopatch shall get the same complete TARA-map with the own geopatch in the center (no Istanbul effect !). Furthermore, not only remoteness but also the density of some “area” shall affect the scale ratio to be applied in order to select a subset of TARA-nodes (partially by computation) plus the computation of TARA-links which are to interconnect them. Different from former descriptions: If there is at least one TARA-router within some geopatch, then there should be at least one TARA-router thereof be communicated worldwide together with at least one TARA-link to it. The TARA-router computes a best next hop towards each of the viewed TARA-nodes of his map and stores this information such that it can be retrieved by either one (if in a different geopatch) or by three table lookups (if within the same geopatch). > And my point is that EIDs shouldn't have to be aggregated at all, > neither now nor ever in the future. Tony wrote: Please read Joel's posting again. At the very least, ANY large name space needs to be managed, and that management needs to be hierarchical to scale. No: The geographical coordinates don’t have to be managed. We may need a very local negotiation protocol in case two TARA-routers are inside the same square-second. We may of course also add a height-component (see RFC1712) and/or extent the scheme to consider fractions of square seconds. That is all. Heiner
- Re: [rrg] Aggregatable EIDs HeinerHummel
- Re: [rrg] Aggregatable EIDs Xu Xiaohu
- Re: [rrg] Aggregatable EIDs Brian E Carpenter
- Re: [rrg] Aggregatable EIDs tvest
- Re: [rrg] Aggregatable EIDs HeinerHummel
- Re: [rrg] Aggregatable EIDs HeinerHummel
- Re: [rrg] Aggregatable EIDs Peter Sherbin
- Re: [rrg] Aggregatable EIDs tvest
- Re: [rrg] Aggregatable EIDs Tony Li
- Re: [rrg] Aggregatable EIDs Xu Xiaohu
- Re: [rrg] Aggregatable EIDs HeinerHummel
- Re: [rrg] Aggregatable EIDs HeinerHummel
- Re: [rrg] Aggregatable EIDs Tony Li
- Re: [rrg] Aggregatable EIDs HeinerHummel
- Re: [rrg] Aggregatable EIDs Tony Li
- [rrg] Aggregatable EIDs hummelresearch
- Re: [rrg] Aggregatable EIDs Tony Li
- Re: [rrg] Aggregatable EIDs heinerhummel
- Re: [rrg] Aggregatable EIDs Lixia Zhang
- Re: [rrg] Aggregatable EIDs Noel Chiappa
- Re: [rrg] Aggregatable EIDs heinerhummel
- Re: [rrg] Aggregatable EIDs Darrel Lewis (darlewis)
- Re: [rrg] Aggregatable EIDs heinerhummel
- [rrg] Aggregatable EIDs heinerhummel
- [rrg] Embedding geo info in PA addresses=>A compr… Xu Xiaohu