[rrg] Aggregatable EIDs

heinerhummel@aol.com Wed, 13 January 2010 22:24 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 9BDF73A68AC for <rrg@core3.amsl.com>; Wed, 13 Jan 2010 14:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Level:
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 WOKTiuI5Gdmq for <rrg@core3.amsl.com>; Wed, 13 Jan 2010 14:24:04 -0800 (PST)
Received: from imr-ma02.mx.aol.com (imr-ma02.mx.aol.com [64.12.206.40]) by core3.amsl.com (Postfix) with ESMTP id B27243A688B for <rrg@irtf.org>; Wed, 13 Jan 2010 14:24:04 -0800 (PST)
Received: from imo-da01.mx.aol.com (imo-da01.mx.aol.com [205.188.169.199]) by imr-ma02.mx.aol.com (8.14.1/8.14.1) with ESMTP id o0DMNtJA005845 for <rrg@irtf.org>; Wed, 13 Jan 2010 17:23:55 -0500
Received: from HeinerHummel@aol.com by imo-da01.mx.aol.com (mail_out_v42.5.) id 9.d67.53bafc62 (34911) for <rrg@irtf.org>; Wed, 13 Jan 2010 17:23:50 -0500 (EST)
Received: from smtprly-db02.mx.aol.com (smtprly-db02.mx.aol.com [205.188.249.153]) by cia-da02.mx.aol.com (v127.7) with ESMTP id MAILCIADA028-5c394b4e47ed177; Wed, 13 Jan 2010 17:23:45 -0500
Received: from magic-d06.mail.aol.com (magic-d06.mail.aol.com [172.19.180.72]) by smtprly-db02.mx.aol.com (v127.7) with ESMTP id MAILSMTPRLYDB027-5c394b4e47ed177; Wed, 13 Jan 2010 17:23:41 -0500
From: heinerhummel@aol.com
Message-ID: <81ed.422aa895.387fa1ed@aol.com>
Date: Wed, 13 Jan 2010 17:23:41 -0500
To: rrg@irtf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_81ed.422aa895.387fa1ed_boundary"
X-Mailer: 9.0 SE for Windows sub 5021
X-AOL-ORIG-IP: 95.91.134.11
X-AOL-IP: 172.19.180.72
X-AOL-SENDER: HeinerHummel@aol.com
Subject: [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: Wed, 13 Jan 2010 22:24:05 -0000

 
Darrel,
A second response with respect to the partitioning issue:
Assume geopatch xyz is partitioned.
For a TARA-router which is far away from xyz it may be  appropriate to 
offset a 64800 elements sized table and retrieve the next hop  info (although 
xyz is partitioned) right away. 
A neighboring geopatch however may have several links into xyz: subsets  
thereof may lead into different partitions of xyz.
For a TARA-router of this neighboring geopatch, by square-degree  xyz  
offset an indication might be retrieved which refers to  some  other table which 
might have to be offset by the destination's square  minute # as to 
retrieve a proper next hop towards  the right  partion. 
 
Will say: The problem is to be and can be solved. Wrt the precise solution: 
 We should at first get to the bridge, before we cross it.
 
Heiner