Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]

Iljitsch van Beijnum <iljitsch@muada.com> Fri, 21 April 2006 14:50 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWwxS-0003DD-GP; Fri, 21 Apr 2006 10:50:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWwxQ-0003D8-TG for ietf@ietf.org; Fri, 21 Apr 2006 10:50:04 -0400
Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWwxQ-0004Rr-HW for ietf@ietf.org; Fri, 21 Apr 2006 10:50:04 -0400
Received: from [IPv6:2001:1af8:6::20a:95ff:fecd:987a] (alumange-giga.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k3LEnIWQ095005 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Apr 2006 16:49:20 +0200 (CEST) (envelope-from iljitsch@muada.com)
In-Reply-To: <4448E25F.6010109@zurich.ibm.com>
References: <09a401c664a7$c7ce9b40$d447190a@tndh.net> <4448E25F.6010109@zurich.ibm.com>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <5FB0BBE8-0F95-4D1D-97D0-50479E165521@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Fri, 21 Apr 2006 16:49:49 +0200
To: Brian E Carpenter <brc@zurich.ibm.com>
X-Mailer: Apple Mail (2.749.3)
X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,ILJQX_SUBJ_AT, ILJQX_SUBJ_DOTINWORD,ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: 'IETF Discussion' <ietf@ietf.org>, Tony Hain <alh-ietf@tndh.net>
Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

On 21-apr-2006, at 15:47, Brian E Carpenter wrote:

>> If we abolish that myth and look at the problem we are left with
>> an answer where BGP passing regional aggregates is sufficient.

> I'm sorry, I don't think I've ever seen a convincing argument how such
> aggregates could come to pass in the real world where inter-regional
> bandwidth is partitioned at link level or dark fibre level. There just
> isn'tany forcing function by which mathematically close prefixes
> will become topologically close, because there's nothing that
> forces multiple providers to share long-distance routes.

Obviously it would be tremendously helpful if ISP A would handle  
region X, ISP B region Y and ISP C region Z, so it's just a matter of  
dumping the traffic for a certain region with the ISP in question but  
for various reasons this will never work, if only because the whole  
point is that multihomers have more than one ISP and each of their  
connections to their ISPs may be down at any point in time.

Let me try out a new analogy. There are many languages in the world,  
and most international businesses have to be able to work in more  
than one language. Now wouldn't it suck if in a business that has  
customers in 25 countries with 20 languages, EVERY office would have  
to have people that speak EVERY language? Fortunately, although there  
is no fixed relationship between language and geography, in practice  
there is enough correlation so that you can have the office in Sweden  
handle all Swedish speaking customers and the offices in Portugal and  
Brazil the Portugese speaking customers.

Back to networking: send the packets to the place where all the more  
specifics are known. If the place where all the more specifics are  
known is close to the places where those more specifics are used,  
that works out quite well. If the more specifics are used randomly  
all over the place then this technique adds detours, which is  
suboptimal.

>> The point that Scott was
>> making is that there are proposals for non-random assignments  
>> which could be
>> carried as explicit's now and aggregated later.

> I understand his point very well and I'm even in favour of it, because
> statistically it can only help aggregation and certainly not damage  
> it.
> But I think that without some radically new principle it will at best
> very slightly reduce randomness.

I guess I'll work on my simulations...

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf