[RAM] The mapping problem: rendezvous points?

Iljitsch van Beijnum <iljitsch@muada.com> Tue, 08 May 2007 16:53 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlSvt-0007K9-RM; Tue, 08 May 2007 12:53:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlSvs-0007K1-4M for ram@iab.org; Tue, 08 May 2007 12:53:00 -0400
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlSvr-0001yx-Ph for ram@iab.org; Tue, 08 May 2007 12:53:00 -0400
Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] ([IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l48Gq0ng008678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ram@iab.org>; Tue, 8 May 2007 18:52:00 +0200 (CEST) (envelope-from iljitsch@muada.com)
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Transfer-Encoding: 7bit
Message-Id: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
To: ram@iab.org
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Tue, 08 May 2007 18:52:56 +0200
X-Mailer: Apple Mail (2.752.2)
X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,ILJQX_SUBJ_HUH autolearn=no version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Subject: [RAM] The mapping problem: rendezvous points?
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

We basically have two choices for the mapping mechanism: work on- 
demand and cache the result for some time, or flood everything ahead  
of time. Both approaches are problematic: caches are vulnerable to  
sudden changes in the mix of destinations in the traffic, and there  
is a delay between the moment routing information is needed and the  
moment it becomes available. Then again, BGP shows that flooding  
everything everywhere isn't so great when you can't control the size  
or volatility of the underlying data.

An analogy in the real world: large stores carry very many items by  
way of many distributors. Rather than have every store maintain a  
direct relationship with every vendor and suffer a huge information  
explosion on both ends, there is stuff in the middle that handles  
distribution so each vendor and each store only deals with a limited  
number of other organizations.

Something like that may be useful in our problem space, too. The way  
I imagine this is by having rendezvous points where the reachability  
information for subsets of the network comes together. For instance,  
as a large ISP, I could have a small number of routers handle a  
certain /8 out of IPv4 space. All the other routers route their  
traffic for this prefix to the closest one of the rendezvous routers  
in question. These then forward the traffic as per more specific  
routing information if possible, or encapsulate it if necessary.

The rendezvous point is where traffic and routing information all  
come together.

Compared to an on-demand model, this has the advantage that there are  
no delays and no caching issues. Compared to a flooding model, it has  
the advantage that the full specific information is only required in  
relatively few places. This can work with both a very small number of  
very large routers, or a much larger number of much smaller routers,  
as long as the aggregate capacity in routing table size and bandwidth  
is adequate.

The downside is that not having the same information available  
throughout an AS increases operational and/or protocol complexity.

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram