Re: [rrg] IPv4 & IPv6 routing scaling problems

HeinerHummel@aol.com Sun, 14 February 2010 10:29 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 0A9B728C0D6 for <rrg@core3.amsl.com>; Sun, 14 Feb 2010 02:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 H366LahTQJkt for <rrg@core3.amsl.com>; Sun, 14 Feb 2010 02:29:50 -0800 (PST)
Received: from imr-mb02.mx.aol.com (imr-mb02.mx.aol.com [64.12.207.163]) by core3.amsl.com (Postfix) with ESMTP id 34FF13A7960 for <rrg@irtf.org>; Sun, 14 Feb 2010 02:29:48 -0800 (PST)
Received: from imo-da01.mx.aol.com (imo-da01.mx.aol.com [205.188.169.199]) by imr-mb02.mx.aol.com (8.14.1/8.14.1) with ESMTP id o1EAUjhu028431; Sun, 14 Feb 2010 05:30:45 -0500
Received: from HeinerHummel@aol.com by imo-da01.mx.aol.com (mail_out_v42.9.) id o.c3f.68c79a57 (37134); Sun, 14 Feb 2010 05:30:42 -0500 (EST)
Received: from magic-d01.mail.aol.com (magic-d01.mail.aol.com [172.19.161.129]) by cia-ma02.mx.aol.com (v127.7) with ESMTP id MAILCIAMA028-910e4b77d0cfbe; Sun, 14 Feb 2010 05:30:39 -0500
From: HeinerHummel@aol.com
Message-ID: <15eb9.d3ac338.38a92ace@aol.com>
Date: Sun, 14 Feb 2010 05:30:38 -0500
To: morrowc.lists@gmail.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_15eb9.d3ac338.38a92ace_boundary"
X-Mailer: 9.0 SE for Windows sub 5021
X-AOL-ORIG-IP: 95.91.134.11
X-AOL-IP: 172.19.161.129
X-AOL-SENDER: HeinerHummel@aol.com
Cc: rrg@irtf.org
Subject: Re: [rrg] IPv4 & IPv6 routing scaling problems
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: Sun, 14 Feb 2010 10:29:51 -0000

 
In einer eMail vom 14.02.2010 07:46:03 Westeuropäische Normalzeit schreibt  
morrowc.lists@gmail.com:

On Sat,  Feb 13, 2010 at 5:03 AM,  <HeinerHummel@aol.com> wrote:

>  loop: from PG1 to PG2 back to PG1. Today I see opposition against TARA
>  because the network inside a geopatch might partition. Yes, this may  
happen.
> But dealing with partitions starts with getting from one  partition to the
> other. And I can only offer a loop: out to some  neighbor geopatch, from
> there back to the other partition of the own  geopatch.

if all you know is PG1, no subnets/sublocators/identifiers,  how does
pg2 know not to send traffic back the same link it came  from?

(note this all seems pretty far out of rrg  though)



So let me answer your question just in the context of a Topology  
Aggregating Routing Architecture:
Each TARA-router would realize that its geopatch is partitioned by  
receiving BGP-UPDATE's containing TARA-links of some upper zoom into the own  
geopatch which it wasn't able to produce itself.
Loopfree, minimally detouring routes via neighboring geopatches can be  
determined and can be enforced for being taken.
 
Heiner